Greg's Design Blog

A collection of posts by game designer Gregory Carslaw, including mirrors of all of his blogs maintained for particular projects. A complete index of posts can be found here: https://boardgamegeek.com/blogpost/58777/index
Recommend
3 
 Thumb up
 tip
 Hide

Action Programming and Navigation

Greg
United Kingdom
flag msg tools
designer
Avatar
mbmbmbmbmb
Original Post

404: Law Not Found (as it's currently being called, looks like it will stick unless there's a sudden massive support for one of the other names) uses an action programming system. If you've not come across this mechanic before, it describes a situation in which players select several concurrent actions and commit to them, before the resolution of the first action. As actions resolve they change the situation, but players are not permitted to change their decisions in light of this new information. I first came across this approach in Robo Rally, in which all of the actions are forms of movement and being pushed even a space off course was often enough to cause you to drive into a laser, off the board or into a pit.



The joy that comes from the action programming mechanic seems to be split between watching a complex plan execute flawlessly and seeing everything go horribly wrong. The latter benefits a lot from a spatial dimension, having characters navigate an environment and taking actions that will have different effects in different locations means that the plan (and its success or failure) become meaningful. Robo Rally manages this by having the consequences of an action depend on the robots position (moving forward one space has a very different effect on the space before a pit, compared to the space before the finish line). Space Alert goes a step further and has an A, B and C button in each room, with actions explicitly pressing a button which will have a dramatically different effect depending on the room that the player is in.

These games take different approaches to navigation. In robo rally navigation is relative to your facing, you play "rotate right" "rotate left" and "move forwards" to reach your destination. As such, you tend to be able to progress towards your objective most turns; even if you do something inefficient like using several left turns to simulate a right turn. In space alert movement is relatively to the station, with actions like "move towards starboard" "move towards port" and "take an elevator". These make it much easier to become stranded, as you could end up at the right of the station with only "move right" cards. However this doesn't cause problems for the game, as it is a cooperative game and there's normally something useful to do anywhere. Instead of being a frustration such situations become something to strategise around.

In 404 I didn't want players to have to maintain facing, the ship is supposed to feel claustrophobic so there aren't many long straight lines. As such if players had to rotate they'd be doing it every other step and a lot of game time would go into a relatively uninteresting action. This lead to me adopting Space Alert's system of having players moving towards the left or right of the ship. However this lead to problems with players getting stuck and unlike Space Alert this meant that someone could reasonably have a turn in which they can achieve literally nothing. Obviously this is frustrating and didn't make for a fun game. My initial solution was to allow a mulligan, in which a player surrendered their hand of action cards to draw a new, smaller, hand increasing their odds of doing something worthwhile at the risk of doing something that they don't want to (having a meaningful impact on the game either way). The problem with that solution was that with a sufficient number of players someone would redraw their hand every turn, leading to the game slowing down and becoming less interesting for anyone who wasn't a fan of shuffling.



Eventually I hit on the solution of having context dependant movement cards. These cards will always produce movement, the direction of which depends upon the room that you're in. The action programming mechanic benefits from actions being context dependant, so it helps that mechanism and it becomes impossible to be stranded. The solution was a hit with playtesters, after playing a game in which only two mulligans occurred (and both for convenience rather than necessity) I felt able to drop the hated mulligan rule and everything was wonderful forever.

In this case "everything was wonderful forever" means "things improved by a small iteration but there are still complications". The placement of the movement icons on the board caused a number of issues, they took up space on an already crowded board, they were often eclipsed by the door counters so players didn't know where to go and people found having doors marked X, Y and Z ugly for various reasons (Ranging from there being too much text on the board to getting confused thinking about coordinates).



Come next Monday, most of these problems should be solved. We'll have a final board, which will combine our awesome art with a healthy dose of graphic design to produce a snazzier board that overcomes these issues. The movement icons will be extended so that they cannot be eclipsed by the door counters. The board will get 20% bigger and become less crowded. X, Y and Z will be replaced by stylised shape icons so that they look prettier and don't text up the place. Then everything will be wonderful forever.

Which is to say that there's still a minor bug. There are a few different ways that the movement icons can be organised. One system is to have it such that a particular icon will always move the player right if there's a right move available and a different one that always moves left. Another is to set up doors to match, so that if you need a given icon to move through it in one direction you generally need that same icon to move through it in the opposite direction. Both have their advantages and disadvantages, I've tested both and the game works with both, but I've had testers with strong preferences for one over another and whichever version I play with I always end up thinking "but the other version could handle this situation more elegantly." Generally the situations that they influence are uncommon, for instance the first system is preferable whenever a player draws a hand that contains only one type of move (in the second system this just leads to them walking in and out of the same room) but this is a pretty rare draw.

Given that the feedback is generally excellent and my observation is that people have a lot of fun with the game as it is, perhaps I have reached the point that I've dealt with all of the major problems and am just looking at tiny things in unnecessary detail. I knew when I started on this project that it would never feel "done", I'll always see something I want to improve. Pretty much every major project I've ever worked on has been the same way. How do you know when you're finished?
Twitter Facebook
5 Comments
Subscribe sub options Tue Jul 9, 2013 11:38 am
Post Rolls
  • [+] Dice rolls
Loading... | Locked Hide Show Unlock Lock Comment     View Previous {{limitCount(numprevitems_calculated,commentParams.showcount)}} 1 « Pg. {{commentParams.pageid}} » {{data.config.endpage}}
{{error.message}}
{{comment.error.message}}
    View More Comments {{limitCount(numnextitems_calculated,commentParams.showcount)}} / {{numnextitems_calculated}} 1 « Pg. {{commentParams.pageid}} » {{data.config.endpage}}

Subscribe

Categories

Contributors