Digging into the Solo Mechanics of Space Marine Adventures

So, before I lose you because you don't like Games Workshop, Warhammer 40,000 (WH40K), or the space fantasy genre in general let me just say that this is not so much about those subjects, but how Games Workshop approached solo and cooperative play in their board game (with miniatures) Space Marine Adventures (SMA). It is my intent to dig into the solo game mechanics and show how you can apply it to other genres and historical periods, even without buying the game.

Overview of the Game

The U.S. bookseller Barnes & Noble has licensed a few Games Workshop properties for sale in their bookstores and online store exclusively. (Some titles may also be exclusively in the U.S.) Most of these games are very simple "gateway" games designed to introduce young players to the miniatures gaming hobby by providing the board, terrain pieces, miniatures, tokens, dice, rules and scenarios all in a book shelf-sized box. In the case of SMA it is intended to introduce new players to the world of WH40K in a format simpler than even Kill Team. Games Workshop has done this before with a number of boxed games, such as Space Crusade, Space Hulk, and others this format is definitely more compact and simpler. Further, this is not a competitive game but rather a co-operative game for 1-4 players, with all of the players playing Space Marines. The enemy, in this case the Necrons (killer zombie robots), are programmed completely, and thus is ultimately a solo game system.

The goal of the game is for the player to progress through a series of three missions, each progressively harder than the previous, with a roster of five Space Marines. Each scenario follows the same basic pattern: the Space Marines enter the game board and have to reach a specific square or eliminate a specific enemy, at which point an exit from the board will be revealed, which the Space Marines will need to pass through in order to win the scenario and progress to the next mission. While the players are attempting to accomplish this more enemies will appear on the board in an attempt to wound and ultimately stop the players from accomplishing the mission.

Solo Game Mechanics

For me, When I evaluate a game's "programming" for the enemy side I look at how do the rules answer the following questions:

1. How do I (the player) determine which side has the next turn?
2. How do I determine which unit on the enemy (programmed) side acts when it is their turn?
3. How do I determine what action(s) the enemy unit takes when it is their turn (or if the rules allow it, reactions the unit takes when it is not their turn)?
4. How do I determine how the enemy unit executes the action(s), e.g. which path it moves along, which target it shoots at or charges, etc.?

Which Side Acts Next

In SMA order of acting is determined by a deck of cards. There are two cards in an activation deck for each individual Space Marine and six cards for all of the Necrons. Each round the player draws a card to determine which side acts next, Space Marines or Necrons. Once all cards are drawn a new turn starts.

Note that neither side gets to react (act during the other's turn), so this question does not need to be considered.

Which Unit Acts Next

As indicated above the activation deck determines order. The card drawn indicates either a specific Space Marine that is to act or all Necrons.

What Actions do the Units Take

I will ignore the player's units for the moment and focus on only the Necrons, as that is what is part of the enemy "program". As I said earlier, SMA is a very simple game. Unlike Arcadia Quest (which I reviewed its solo rules in a previous post) the enemy does not move and attack in their turn. A Necron's turn consists of drawing a card from the mission card deck (called the Labyrinth deck) and following the instructions written there.

Scattered on the boards included with the game are six spawn points (called "translocation squares") numbered one through six. On some of the mission cards it indicates which spawn points new Necrons will come in at, as indicated in the image above. In that example by the red arrow, it instructs the player to place a Necron at translocation square "1".

In the image below, the player has drawn a card indicating that Necrons should be placed at squares "1" and "3".

When Necrons are placed, they are placed in the order indicated on the card (typically from the lowest number to the highest). A counter is placed on the translocation square if it is empty of Necrons. If it is not, it is placed on an adjacent square if that is empty of Necrons. If that is not you look at the next adjacent square, and so on, until it is placed. Additionally, if the translocation square already has a counter, you place one Necron in each direction adjacent to it.

In the example above, when it comes to placing the Necron on "1", because that square is empty the counter will be placed on that square.

For "3" however, there is already a Necron there so there should be one Necron placed in each adjacent square, labeled "A", "B", and "C".

Because "A" has a Necron you then check square "D", which is empty, so the Necron is placed in square "D".

For square "C" there is no Necron, so the new Necron is placed there also.

Finally, in square "B" there is a player's Space Marine. Because the square is empty of Necrons it would normally be placed there, but because there is an enemy, that placement is considered an attack. The new Necron is eliminated and the Space Marine player takes a wound.

Coming back to the question: what action(s) do the programmed unit(s) take? The answer is "placement". Placing a unit essentially indicates where future enemy units can be placed and which player units can be attacked.

How Do the Units Execute Actions

As indicated above, placement is the only "action" allowed to the enemy program. If the placement is on the same square as a player's unit, it is considered an attack. The strict placement rules define how the units execute those placement actions. Thus the decision is taken away from the player.

Application to Other Genres

Okay, so now you have the basics of the solo gaming mechanism, how can you apply this to other genres?

The Board

The first component to consider is the game board or tabletop. There are three elements to account for:

1. The paths that the player's units can take and the enemy unit's can be placed.
2. The points where the enemy's units can enter the board.
3. The locations of the objectives.

Personally I think this system needs a grid, whether square or hex, in order to constrain the player's movement (no geometry tricks in order to avoid an enemy attack) and control the enemy placement.

The Reinforcements (Labyrinth) Deck

To recap a little, each round a card is drawn from the activation deck to determine which side - and in the case of the player, which unit - acts next. When it is the enemy's turn to act, a card is drawn from the labyrinth deck, which acts as a reinforcements and events deck, to determine which enemy reinforcements come on and where they enter.

Researching out, say, a historical battle you could use the orders of battle and the arrival schedule of units to create the values in the reinforcement deck. As a variant, you might even not randomize the order of the cards in the deck in order to reflect the historical order of appearance of units.

All each card need do is indicate the reinforcement point(s) where reinforcements will enter. How many will enter can either be dictated by the position of existing friendly and enemy units on the board, as it is with SMA, or it could be stated on the card.

The Reinforcement Pool

One aspect of SMA that I glossed over is which specific unit type is deployed to the spawn point when the labyrinth deck indicates new units are arriving. Each scenario defined the number of types of units that are in play, e.g. 10 Necron Warriors and 10 Necron Immortals. These units are tossed into a bag and when the card calls for a unit to be deployed, one is randomly pulled from the bag and deployed on the board at the location specified by program.

The same sort of concept could be employed in other genres, of if playing a historical scenario, you could combine the reinforcement location and unit composition in the reinforcements deck.

The Units

The Necron units in SMA really only differ in their defense values. As there is no movement, and attacking is by placement automatically inflicting a single wound to the player's unit, the only values a Necron unit has are its type and its defense value. When a player's unit attacks the player rolls a D6, adds or subtracts modifiers, and is looking to equal or exceed the Necron unit's defense value. If it does, the unit is eliminated.

All units of the same type have the same defense value. Some cards in the labyrinth deck will temporarily modify that value for all units of the indicated type, generally making them tougher to kill.

The two elements of combat, that an enemy unit inflicts one wound 100% of the time and that a player unit that inflicts a hit on the enemy will destroy it in a single hit, can easily be changed. Both sides' attack and defense values could be created and used, with die rolls determining the outcome of hits and damage for both sides.

Summary

The basic structure of SMA provides for an interesting method of programming opponents. In turn, there are a number of variations you can consider.

• If you don't like making cards you can easily convert the deck to a table where you make rolls. It does change the dynamics some as, once a card is played it cannot be played again. (Once the deck is played, the game is over, so all cards are only played once, at most.)
• Some people do not like deterministic combat so you can inject any sort of chance element you like, or even your favorite combat system.
• There is another variation of SMA called Space Marine Adventures - Rise of the Orks, which allows the enemy units to move by program, so this is an obvious change that can be made, rather than having reinforcements reflect "movement" of sorts.

The final point is that a good programmed opponent takes work. It is basically a game in and of itself. I think the more you write these programs, the easier the next one becomes.