Scoping down practice

This month I want to show part of my personal exercises for analyzing and practicing scoping down.

One of the things I do when applying this for games is that I look at already existing games and try to answer the question “What feature can be cut or changed while still keeping the game interesting?”. This is less difficult to do for games I don’t like, so to make it more challenging and encourage some deeper thought, I mostly do this for games I enjoy playing.

Here are a few examples, where I also explain the reasoning behind my choice -

Rocket League:

I didn’t just want to pick the ‘easy answer’ of just removing some of the later game modes that got introduced after a while. I wanted to look at more core elements and consider how different elements being changed would change the game.

The first I looked at was the ability of players to destroy opponents by driving into them at top speed. This is an element that then respawns the car in one of the corners of the player's team. This also resets the player to their starting amount of nitro, and while there is nearby nitro to get, this can feel very troublesome for newer and more inexperienced players. This makes me wonder if the destruction and reset is strictly necessary or if the nudging of opponents cars that happens when driving at a slower speed should carry over into the top speed hits.

While I was considering the above, my thoughts drifted towards the nitro pickup spots. There are two types spread across the playing field. Most of these are smaller amounts, while a few grant full nitro. This is another spot where a change could potentially be made. I have noticed that one of the main differences that show when someone is new to the game, is that they focus too much on the full nitro spots, and if an opponent gets there first these players often try to go out of the way to get to another full up spot or try to play on with little to no boost.

The more experienced players will adjust their driving across the field to constantly pass over the smaller spots and in that way keep their nitro topped off as much as possible. I would love to see how newer players would approach and learn playing the game if there were no full nitro spots.

Most of the nitro spots visible are of the small amount kind, each corner and halfway point along the sides have the full up. One full up is visible on the image with a floating sphere over it.

Minecraft:

This was also a difficult one as there are quite a bit of systems interacting with each other, so messing with one would likely affect one or more other systems. Every time a new version of the game is released, it comes with new blocks, new mobs and other additions. This also invariably leads to praise from some players and disgruntled complaints from others. In my case I often see many of them as ‘quality of life’ improvements, which is part of why I found the exercise difficult in this game. 

I decided to approach the exercise for this one differently by not focusing on something as mechanic related and lean more into what the overall feedback from players seemed to be and that ultimately led me to taking a look at the Phantom mob. This mob was introduced as the winner of a vote that Mojang held, but has mostly been considered an annoyance by players when playing. The mob will spawn at night if a player has not slept in a bed for several nights, and the more nights without the player sleeping, the more phantoms spawn. The best way to keep them from spawning is therefore sleeping almost each night. This leads to some play patterns where players will be bringing beds in their inventory to be able to sleep. But this ties into the respawning mechanic as this will be the location of the latest bed slept in if it has not been broken, and if it is, it respawns the player at the spawn point of the map. That is why I think this is one of the features/elements of the game I would look at first, should I ever get to be a designer on Minecraft.

The not much liked Phantom dive-attacking me at night.

No blog this month

Due to health issues, both own and a more serious one of a family member, I decided to not expend the last parts of my energy on a blog post this month. See you again sometime during February if things improve.

2024 retrospective

Another year has passed and it is yet again time to take a look at what I have been up to and what I am planning.

During spring I had a position as a game designer in a startup game company. Due to technicalities it was defined as an internship, but considering that there was nobody above me in design, I see it more as an unpaid position. Being thrown into things from the get go is definitely a way to learn while doing. This provided a good opportunity for me to apply some of the knowledge I have in the field as well as help the company in the right direction. It unfortunately didn’t pan out with regards to getting a full time paid position, but the experience was more than welcome.

Other than that I have my personal projects which have gotten some time put into them. For the 3D platformer idea I have been slowly cultivating in my mind, I hope that I will be able to dedicate more time and effort to it in 2025. I am at the point where I have a bunch of the world setting ready to be expanded upon in my head, as well as starting to mess around with playtesting the abilities in Unreal that I want to be in the game.

The other hobby project, the board game, has undergone a few iterations, as well as having been tested several times now. I am at the point where I need to start polishing up the rules to fix a few issues that were encountered. I am also starting to consider getting some help in fine tuning numbers as well as taking the first steps towards either seeking out a publisher or what is needed to self publish.

For 2025 specifically, I will start off with doing another testing event and potentially one or two game jams in January, and beyond that I do hope that I manage to land a job. Preferably as a game designer with focus on gameplay, but I’ll be open to level design and QA positions too, and doing some smaller projects on my own to help increase my skills for those options. If you’re a recruiter please reach out if you have an open position. 

May the new year bring opportunities for us all. :)

Back to the boardgame

I have been spending some of this month exploring TableTop Simulator as an option for testing the boardgame. Since I still don’t have that up and running yet, I figured I instead would shine some light on some of the feedback I have received so far.

The total amount of feedback at the time of writing has been 12 people filling out the form with a split of 5 female and 7 male players. The age range of testers so far has been from 24 to 36 years old, mainly due to the age range of the testers at the events I have brought the game to. Nationality wise, there have been 2 from North America, with the rest split evenly between Danes and Europeans. This is one of the reasons I want to put it on TTS for further testing as that enables a better reach with both nationalities, age ranges, and the overall amount of testers I might have access to.

The positive part of the feedback is that the game is quick, simple enough to pick up and play. It offers a good amount of tactical decision in the 1v1 version where the main goal is only to outsmart/outplay the opponent.

On the less positive part of the feedback the testers have pointed out some issues that I need to figure out if I want to change up or keep as specific features. Amongst these are that the starting positions are random. That the game feels like it can snowball for a player if there is a high enough difference in luck with the cards drawn and being able to build one's own path faster.

I have a few ideas about what I can try to change up and test to mitigate some of these. It has been on my mind for a while to try and work in “map overlays” that would decide both fixed starting positions, but also add in more unmovable obstacles, forcing the players to path around those. This is another reason that I am looking into TTS for further testing, since I have mainly done 3D printing of the physical version and having a digital version allows for faster iteration on visual elements.

An initial analysis - Penny’s Big Breakaway

Due to some health issues at the beginning of the month I decided to not do Blocktober this time around.

Instead, in this post I will go through some of my notes for the first few levels of playing through Penny’s Big Breakaway. I have collected a list of 3D platformer collectathon titles that I am going through and analyzing to see which things I think work in the different titles and which things might not work, and why it is so.

Since this is a collection of notes taken while playing it might not seem as coherent as previous blog posts, but it should highlight some of the stuff I look for when analyzing this type of game.

First impressions

Game uses lots of brighter colors and silly looking characters. Very common for the genre.

Opening sequence

Game very quickly goes from intro screen into an animated intro, which then progresses through some gameplay footage showing in-game situations, including different player character movement which helps to inform the player beforehand about these, provided the intro is watched. The game still introduces those abilities nicely later on, so it is not a must watch.

Main menu

The menu navigation felt a bit too sensitive using the controller.

In-game

Controls – feel very responsive, which both feels great and comes with a minor issue. The button that activates the yo-yo the player character uses controls several abilities and even a slight mistiming or too long a press can lead to some accidental movement. It is not a big issue, but does take some getting used to for the player.

Camera – The view is almost fully locked to the players viewpoint and only allows for slight angling with the d-pad. It also feels slightly more zoomed in than is usual for the genre. The locked in view does prevent issues with walls getting in front of the camera which also auto rotate the view depending on where in the level the player is.

Level design — The levels I have played so far flow well. They don’t have any big route splits at the point in the game. The setting in these first levels uses buildings and walls to segment off and limit the view. There is also a good amount of verticality as is common for 3D platformers. The 2nd area introduces the main player abilities as you have to find an alternate way to “enter Emperor Eddie’s audition”. The levels do have a bunch of places where it’s possible to fall off and lose a life. There are plenty of checkpoints spread throughout the levels. There are also a few areas that require more specific movement, but rewards the player with collectibles, which is also very common for this genre.

Gameplay – The game so far feels like it is intended to induce a sense of urgency. This feeling comes from a combination of the mentioned stuff, the sensitivity of the menu, and the responsiveness of the controls. The fact that as you enter a level a timer starts right away, and the main enemies so far have been the emperor's penguin guard, which, if they overwhelm you will capture you and send you back to a checkpoint, both help to make the levels feel more hectic.

That’s all for this post. I might return to posting more notes from this game after playing more of it, or do the same for other games and genres.

Patterns start to emerge

This month brought more testing of the board game with it.

This time I managed to get 4 games tested while observing the players during their games, and noting down potential pressure points and issues that could lead to stalled games. One such issue being the ability for a player to ‘undo’ the move another player has made just before them. Having this be possible leads to a feeling of what the first player did, didn’t actually matter. And since I want the player to feel a certain level of agency during the game, this has had to be solved. Currently my choice is to do what a lot of other games do, and make it so that specific reactions can not be done in the turn immediately after. This situation is very similar to a situation in the classic game GO, where a move that leads to an immediate repetition of the board state is considered an illegal move.

With the playtests done during this session and the ones from the session in July 2024, I am starting to get a better sense of the strengths and weaknesses of the current iteration. In the end the addition of using cards to guide the players options have proven quite popular, even if the numbers I have initially gone with are not fine tuned. I used the previous amount of board pieces I 3D printed to be a limiting factor for how many of a specific piece is available, and this is also a point where adjustments need to be made. For the next test I am considering limiting the options of some of the more open-ended options like the 4-way and 3-way connecting pieces that often gets picked over other options when adding to the players own path, as this allows them to keep their options more open, and I need to test if having less access to them influences the players’ decisions.

This time around the cloud pieces, I added the last time, actually saw play, and the players seemed to enjoy them, although some wordings I had put in the rules were confusing and needed rephrasing. This is a minor issue and a simple fix for now. But it will be interesting to see if the clouds continue to be used by the players. I do need to remake the pieces to be more transparent as even though the rules say the piece below is ‘inactive’ for pathing when the cloud is present, it is still important for the players to know the connections the piece offers, as the validity of an adjacent piece needs to still be matching in case the cloud piece gets moved away.

The next update might be level design focused as I am heavily considering doing something for Blocktober this year.

A new challenge approaches

Today's post is going to divert a bit from the previous ones.

I have, together with two friends, a programmer and an animator, begun the process of trying to make a small demo of a game to put on Steam. Besides allowing us to gain more experience doing stuff within our specific realms, we also want to try to go through the process of what it’s like to get a game on the platform without just letting someone else handle that part.

As a chosen genre/type of game, we have settled on a rhythm runner style game, partly because this allowed us to split the game up in levels, as well as build it in a way that is expandable, just in the eventuality of the game suddenly taking off on the platform.

We are still at the early development and prototyping stage, focusing on making an mvp version where we can test the barebones. For my part, I have been writing a short music piece for the initial level as well as looking at and analyzing the games already out there in that genre.

Games like Geometry dash, Rayman Legends, Bit-Runner, etc.

Part of my role will be to plan and develop how playing a level can make the player quickly enter a flow-like state while playing, and try to keep them there even when they start hitting the obstacles. This entering of the flow-state seems to me, after analyzing games in the genre, to be one of the things that really separate the good games from the less good ones, and I find this to be an interesting challenge from a game design point of view, as it incorporates making audio, graphics and gameplay all come together to such a degree that this becomes achievable.

This is of course not to try and say that is not important for other games. But for rhythm games this seems to be paramount.

Board game, now with cards

The board game I am working on has undergone the slight redesign.

Where it previously was only tile based I have now designed and printed cards to decide/limit players in what option they have for interacting with the game. Previously players would pull a tile from a bag and then place it, whereas now they keep a hand of 3 cards, on which they can pick 1 out of 2 options. The following issues led to this decision as it helped solve them.

Issue 1: Previous variants of the prototype have mostly offered up a random way for players to interact, as it was based around drawing a tile and then deciding on where to place it.

Issue 2: This was a more hidden issue, but the above tended to add a slight amount of extra time to each turn as players did not have time to plan ahead and had to think more on the spot.

How do cards solve issue 1? Because players keep a hand of cards with multiple options on them, a player will have up to 6 options to choose from, depending on any options reappearing amongst the cards on hand. While there is still an element of randomness due to the nature of having to draw cards, this offers more control for the players.

How do cards solve issue 2? By using cards and having the player draw back up to 3 cards at the end of their turn, they are provided with enough information to try and plan their next turn. This makes each players turn progress slightly faster on average compared to previous versions of the prototype.

I did another test with players at the start of July and the feedback has been mostly positive. The above changes were very well received.

The setup step. Players roll their dice to randomize starting positions that need to be connected. On this image left to right is the player whose cards are on the left and top to bottom is the player whose cards are on the right.

The end of game. The player whose cards are on the left placed the final piece to connect their two starting points.

I decided to also add a new special tile, a storm cloud, which can be placed and controlled via playing cards with the cloud symbol on them. This did not get played much during the playtest games, as players reported back that they didn’t quite see the reason to use it, and it seems like this may be another layer of play/tactics that would work better as ‘optional rules’.

Development continues, and I am now considering trying to learn how to use Tabletop Simulator to try and test with people not physically located in the Copenhagen area.

Decked out

Lots of messing around with numbers on sheets this month. I’ve been working through the cards needed for testing with the board game idea. It took some trial and error to make the numbers make sense to me, but it will be interesting to find out through playtest which ones might need further adjustments.

As I wanted to provide players with choices on their cards I had to set up some constraints, so for the first round, or multiple rounds, of testing the cards out, each card will have two options. The first option will always be one the player can pick to progress their own plan on the board, while the second option is the one that most of the time offers ways to put up blocks for the other player. As such, each round the player will have 3 cards with those 2 possibilities.

I almost missed posting this post as I have been focused on preparing the things needed to make the cards, as well as learn NanDECK, a free program that seems quite useful for quickly prototyping up cards for game ideas.

I have also joined up with two former classmates from uni for a hobby project on the side. The overall plan is to make a tiny game before the end of the year that allows all three of us, a programmer, a 3D animator and me, the game designer to ‘flex’ our game dev skills, as well as put the game up on Steam to be able to cross that off our checklist too. Future posts might delve more into that game, what it is about and what issues I had to find solutions for design wise.

A quick update

This will be less about game design specifics and instead be an update on where I am jobwise and with my personal projects.

I am no longer full time with the company that I worked with for the last few months, but that is ok as it was the agreed upon timeframe from the beginning. This does however mean that I am now open for game designer positions again. I am also applying for positions as level designer as I feel the amount of overlap will still allow me to broaden my skills in game design as well.

This month I was fortunate enough to be able to experience the Nordic Games convention in Malmö, due to winning a ticket through a giveaway on LinkedIn. It was an interesting experience to move outside of the usual area of Copenhagen, and seek out inspiration from people I don’t normally run into at events here.

Amongst the things I took with me were a few ideas for character abilities for my own 3D platformer idea, as well as several notes on both prototyping and marketing from the talks that were held, some of which I am already trying to apply for the platformer project. Hopefully now that I have more free time again between jobs, I can progress a bit with this and test some things out.

With regards to the board game idea, I am trying to come up with ways in which I can offer the correct mix of randomness and control to the players. I have currently landed on them being able to have a hand of three cards with two options on each card. The difficult part currently is trying to figure out which options make for good combinations and which should not be on the same card. I foresee a whole lot of testing on this in the future, so it might be time to do this as quickly and scrappy as possible, so iterating on it becomes easier.

A partial design process

This month will be a brief post focusing on a gameplay question and how I have gone about coming up with an answer.

Setup and initial question

The game involves 4 teams of 4 players fighting to eliminate the other teams bases. The shape of the map is based around a central area surrounded by a circle of 8 areas. Those 8 areas are split between team starting areas and neutral areas alternating between those 2 types. As we want to discourage a specific tactic where a team goes very defensive in their starting area, we are looking to implement map elements that encourage teams to leave their base. There are more than one element we have added to push a more expansive playstyle, but the one I touch upon today is very much based around one of the design pillars being the risk/reward play we want to encourage.

First draft

Since we want teams to not be too defensive, but also potentially engage more than one enemy team at a time, the focus was on the central area of the map. I looked through what the objective of the game was (destroy the enemy bases) while also wanting to still encourage teamplay. This led me to decide on suggesting a map wide blast that is going to kill every player not inside their starting base, while also damaging all bases except the one belonging to the team activating it. Upon activating a console in the middle area, a map wide alert will go off and alert all players and provide an active countdown timer showing them their window for stopping the blast.

Second Draft, and a potential third.

The idea needed further tuning. I still wanted to push the teamplay aspect so I added the more risky requirement of needing two players from the same team to activate the console. Since the teams are 4 players each, a team going for this plan now has to get at least 2 players to the center console, leaving them to only have 2 defenders at their base. For initial tests, the deactivation will probably be limited to only 1 from an opposing team needing to get to the console, but I would love to test how it changes the players approach if it requires two players to deactivate too, but those 2 players don’t have to be playing on a team together, as long as they’re both on opposing teams to the one that activated the console.

See ya next month. :)

The many hats of indies

I am still doing work as a game designer, as described in my last post. As of posting this, I have been at it for approximately 1½ months, give or take a week. So today I will go over some of the things I have done and how they illustrate that in smaller teams, one often has to wear more than the hat that was the focus to begin with.

First of all, I am still doing game design focused tasks. With the design pillars in place, I focused slightly more on getting a simpler version of the map ready for testing with players. I created a document for what I considered a minimum viable test for this game. Due to me joining the team on something that was already ongoing, it will be slightly more than minimal. Getting to a state where we are ready to do the test has been progressing in cooperation with the programmer as we focused on getting abilities and items to work as intended, and we seem to be close to being able to run the first test with players. I have also been working on different templates for team members to use in case they come up with ideas they would like to implement. This is to make sure that we don’t just add anything ‘cool’ we come up with, but put thought into how the suggestion would fit into the existing parts.

On top of that I even prototyped both a dashing ability and a way to do two-way teleporters in Unreal Engine. Using the teleporters didn’t even crash the editor after some rework.

That was some of the game designer stuff. I have also done a bit that would cross over into QA/Testing territory. First of all I created documentation to keep track of what the test is intended to actually be testing for. This is to make sure that once the test has been performed, we can direct our focus to analyzing those parts first. Secondly, I put together a quick template for bug reporting. I don’t expect players to be using it at this point, but it will be a nice thing to have both for internal tracking, and further into production it should provide a benefit by already having been used and accustomed to. Making it this early also allows iteration on that itself, should it turn out to need that.

Level design wise I stared with a partial version of an already existing map layout. My focus was less on creating anything from scratch, but rather use parts that were already in place and adjust for potential gameplay. As this game involves players harvesting ressources, I focused early on on the placement of the spots in which that is possible. I also planned where the teleporters I prototyped will be placed, and currently they add some tactical depth to the gameplay. This is one of the things I am excited to see via the test if players will be using and how. As an added bonus I also started implementing some parts to the map where players can control if those parts stay or not, adding to the tactical depth. The control panels for those will not be in the bases though, but require the players to venture out into the map

I think this will be all for this month's post. For April, preparing for the test will take a bit of a backseat as other things have taken priority, but I do hope that we will be able to progress enough that we will be able to run the first one at the start of May by the latest.

A new journey

Some things have changed since the last blog post. About a week ago I started a temporary 3 months position as a game designer in a smaller company. As such a lot of my focus and energy has been diverted towards that.

With regards to my own projects this means that both the board game and the 3D platformer collectathon will progress at a slower pace during that.

For the board game I am heavily considering prototyping up a version that involves drawing cards, and potentially giving the player multiple choices of actions to pick from via this. I keep having a hunch that this might be a better fit for the idea, but there is only one way to find out.

For the digital game, I am carrying a notebook with me everywhere I go and trying to get into the habit of writing down every little single snippet of idea I have. As I decided I wanted to create this project in Unreal Engine, getting the current position is actually extra beneficial for me as their game project  is currently being worked on in that engine and I am trying to both get used to the engine and learn as much about it as I can to then be able to start prototyping up mechanics that I’ve already noted down. 

With regards to the job position, to describe some of the stuff I’ve been doing for the one and half week I’ve been there so far, during the first week I sat down with the team and we went through and updated 5 design pillars with 3 player experience goal descriptions for each. We will be using those 15 descriptions to evaluate both current ideas, mechanics and features, as well as any future ones, to make sure that we stay within scope for the feel and gameplay the team hopes to achieve. I am now in the process of trying to create an initial and very rough version of the main level of the game in which we can implement the most core of the mechanics and features to enable the team to move into a very early testing phase with players to help us analyse what works and maybe doesn’t work gameplay wise at this point.

I am very much looking forward to where the journey with this team takes me and their project and the next update might have more focus on my process within that than on my own projects, depending on how those progress. I will still be trying to stick to the initial blog schedule I set for myself when I began writing these, and keep posting at least once per month.

First game jam of 2024

This month had the Global Game Jam 2024 happen, in which I participated with three other people. This time the team had two programmers and two game designers. The other game designer agreed to work on level design part for this one, which meant that I focused a bit more on finding the right sounds and other assets for the game.

Unfortunately my health wasn’t really on top of things this time and I had to cut the big workday of saturday short during the afternoon. But this is the sort of thing that happens in the workplaces too and you just got to roll with it, adjust, and try to get the best out of the situation. Thankfully my teammates were excellent and managed to do all we planned the day before and after I got home and got some rest in, I managed to get most of the sounds ready for implementation.

The theme of the jam was “Make me laugh”. The other game designer had the main idea of an endless runner where the player was controlling a dinosaur and to that we added some janky ragdolling to make it look silly and by adding a design pillar of exaggeration, we achieved a game that made every tester laugh when they played it. I think we can call that a success with regards to the theme.

Since this is the 2nd jam in a row where I have ended up with making a runner type game, I think I’d like to try a non-runner next time. I am also working on putting together a “jam kit” as a game designer so I can quickly do different basic game type setups for testing, which should help in future game jams.

Our game for GGJ2024 runs on windows pc and can be found at a teammates itch, on https://salomes-crescent.itch.io/walkythedinosaur

A 2023 retrospective

This post will not be about any of the specific game design projects I have going, but more a look back at the year that has been and what is to come.

I began this blog in the early spring, after having just begun on writing my Master’s thesis project with a programmer. I did not cover the following in the blog as I started writing it afterwards, but I lost my father in February and this of course had an impact on things, amongst others it caused us to reevaluate the thesis project and apply for a month extra time. Regardless, at the end of August the exam was passed and I could claim a Master’s in Games - Design degree after studying at the same University for 5 years in a row, the first 3 being about digital design and interactive technologies, and the last 2 having games as the focus.

I have since then been applying for jobs and internships, a process which I am still doing, while also focusing on the two game projects that I have mentioned in previous posts, rounding it all out with the game jam win just before christmas.

Going into 2024, I do hope to land a position in the industry, preferably in a game design role. So if you’re a recruiter reading this, please do not hesitate to reach out, even if you just have some feedback on or questions about the portfolio. I am very flexible with regards to meeting up for a talk about potential positions, and while I prefer Copenhagen, Malmö is also a possibility. I even come with some financial benefit to your company for up to a year, should they be the first to hire me.

As for the more specific plans, I will be trying to delve into Unreal Engine, and some of the future blog posts might deviate into some of the processes, results, and learnings from that journey. I am also considering adding more level design knowledge to develop that further as an extra layer on top of Game Design, as it seems that is often one of the extra hats that game designers wear on smaller teams.

May your 2024 be a wonderful journey, and see you out there. :)

A Game Jam Win

About halfway through December I participated with 3 others as a team in a game jam centered around creating a mobile game for a specific type of controller. I went into it with a focus on Game Design, but ended up also building level segments for the game, and creating some of the sound fx used. A limitation for this jam, besides having to use the controller, was that we had to use Unity as the engine for making our game.

Game design:

I focused on what the controller provided with regards to affordances and limitations. As we had access to registering how the controller got tilted from side to side, and when the controller was moved, the short time a 48h game jam offers meant that the decision ended up being a runner type game where the tilting would then translate to how far sideways from the center the character could move, while swinging the controller would signal the character to attack. A personal goal for me, regardless of how our game placed, was that if the testers and judges ended up with a big smile on their face while playing the game, I would count that as a success.

Level design:

For the level itself, I decided to build three segments that could then be used in both directions, basically allowing us 6 different looking segments. We initially wanted to make the game endless by making it procedural, but this was one of the features that we ended up cutting due to the timeframe. To save on time, the houses are from an asset pack.

At the end of the jam we not only took 1st place, but there were big smiles and grins from the testers and judges who tried the game, making it the personal success I had set initially.

Below should be a video of a teammate playing the game.

Water everywhere.

As mentioned in the previous post, I keep testing the board game idea variants.

This month I did two different tests with a version where all the pieces were water only. This led to a few interesting discoveries. I also removed the dice element again, as I wanted to test this version without that added element first.

Some of the takeaways:

1: The game seems to play faster. Since teams just have to make a connection between starting points and they can use the opposing teams laid out course, there is a closer inevitability built into playing now. Especially with the “if a team has no legal connection possible, the game is a draw” rule that encourages teams to not fully block each other.

2: The edge of the board is still tricky and at one of the tests there was what I would describe as a corner case with regards to how I’ve phrased the rule about placing pieces at the edge. Some slight rewording is needed to fix that, but it seems fixable.

3: I also included “stop pieces” where the connection gets broken. These brought some interesting tactical plays for the players, but the random pull of pieces means that a team can get several of those in a row. There were no complaints from the players as they said they liked the challenge of figuring out if they had a good place to put them, but this is something where I will have to keep an eye on it.

4: I do now want to test with a version where the gameplay mechanic is based on cards drawn and keeping a set amount on hand at all times. This does require planning and production of cards, so it might take a while before I am ready to test that. The potential advantages I see is that by using cards I can give the players the ability to always have multiple cards to choose a play from, and the cards themselves would allow for options as they can show more than one type of piece at the same time, and even include some types I have not implemented/tested yet.

The overall feedback on the game is still that players really enjoy playing it, so that has been and is still very motivating for continuing to develop it.

More testing

This post is about the second test of the board game.

This test was performed with players being students and alumni from the university at one of their playtesting days. Based on some of the feedback and notes I had from the first public playtest, I tried to implement the following changes:

The amount of pieces with both team’s connections on them was increased. These were both the straight and curved pieces that covered both teams’ connections. The intent here was to keep the board from hitting too many ‘one team only’ areas. This worked to some extent as teams attempting to disrupt the other team mostly drew these and it kept options more open.

I added the following rule: “If a piece has a non-connected side on it, it can not be placed at the edge of the board so a connecting edge leads away from the board”. This eliminated some of the issue, but the pieces with turns on them for both teams could still be used to end that route for the opposing team.

An extra rule I implemented, both to lessen the impact of the above, but also to add more interactivity to the board, was to add a D6 dice roll at the start of each player's turn. On a roll of 6, a player can choose to swap any two pieces, except the starting pieces, on the board, as long as both can be placed in a position that makes them both legal. This drew mixed feedback. Players liked the interactivity, but it led to a sharp increase in board complexity as many pieces are now potential future swap setups to take into account.

Overall feedback was that players still like the core idea and that “there is something there”.

Next steps >>

Testing some ‘extreme’ options to get a feel for what happens and how the player feedback is on those. I will be testing a version that is only one type of connection to get a feel for how that plays out for the teams. The 3D printer has been warmed up and I will be making a new round of pieces on another base color plastic to be able to keep this variant separate from the two distinct routes one.

Boardgame - First public playtest

At the beginning of this month I went to an event in Copenhagen where developers could show up with a game mockup/prototype and meet people willing to playtest.

For this playtest there were some questions I needed answers to:

Q: How does the core gameplay feel?

A: The playtesters who did get to try the game told me that they really enjoyed how the playing felt, despite the hiccups they encountered and which I had expected. The core seems good, now I need to tune that towards a basic version that deals with some of the issues it currently has.

The result of the 2nd game. The river team managing to narrowly win in a very close game as both teams ended up fighting over making a connection in the top right corner of the board.

Q: There were some issues with “blocking moves” where placing pieces in a certain way makes it impossible to place one of the current tiles on a specific adjacent space.

A: I managed to host 2 test games. For the first one, all the different types of pieces were split evenly between the two team bags. This I adjusted for the 2nd test game, so the 4way and 3way pieces for a team were only available in that teams own bag. I will be printing more of the pieces that have connections for both teams on them, and try a version where each team only has a few turns and straights for their own team in their bags. This is intended to make the routes on the board less blockable. I might need to come up with another type of piece that allows for special ruling near the edges, as there will still be turning pieces that can block opponents.

Q: The edges of the board is an issue with the current rules, as it was too easy if a player pulled a turning piece for the opposing team from their own bag.

A: This is a problem that is partially connected to the above one. I willl be trying out two ways of approaching a solution. The first will be as mentioned above, with changing the numbers of the specific tile types. The second will be including some kind of randomized way in which it becomes possible to turn a piece on the board.

I will be returning to the event again with changes to try and test out how they play, and potentially try to figure out rules for if people want to play a 1v1 variant.

Board game continued

There will be an upcoming playtesting event in central Copenhagen early in September, which I plan to participate in. So I went about creating a quick and simple mockup of pieces and a grid for the board. I currently have the tiles 3D printed and very quickly given them a tiny splash of color to make it easier to tell which pieces are which. 

Working title is “Rivers n Rails”. 

Some of the things I need to figure out through testing will be ways in which to randomize certain elements of the game, and if these actually need to be randomized or not. For this test I plan to try out pulling the pieces from a bag vs how it feels for the players if they receive specific amounts of each piece. I expect the second option to make the players think more tactically and try to keep track of what other players have already played from their own pieces.

There is a slightly higher amount of pieces where both teams have a connection. This is intentional as some of the even earlier testing showed that players tended to focus more on trying to block or divert the other team, more than they did on progressing their own. This is an issue I am constantly watchful about, and I hope in the end to reach a solution that is both easy to explain rules wise, but still feels engaging to the players.