It’s Oz again with more thoughts on the process of making LEVEL 7 [ESCAPE]. In the previous LEVEL 7 [ESCAPE] developer diary entries I explained some things about the tiles and how events work. This time I’m going to discuss how the enemies and the systems that control them were created.
The LEVEL 7 setting is inspired by modern UFO conspiracy mythology. LEVEL 7 [ESCAPE] specifically tells the story of people being held against their will in a secret research facility the government built for alien use. We wanted to explore the differences and relationship between the human and alien populations of this base.
One of the most interesting aspects of the situation at Subterra Bravo is the tension between the two groups. The base was built at the beginning of the collaboration. Over the following decades the relationship has slowly broke down. The story in LEVEL 7 [ESCAPE] starts when tension is high but for the most part the parties are still cooperating. As you progress through the game things gradually break down until there is open conflict between the two sides.
The most important early decision we made was to automate the enemies instead of having a player take on the role of a game master. That decision was made to reinforce the semi-cooperative aspects of the game. Without one player running the enemies, all the players have interesting options for what they want to accomplish and everyone is on an equal footing for helping or hindering each other. Directly connected to the decision to automate the enemies was the idea that the human and alien enemies in the game would work in similar ways but their actions would be driven by the separate stats of fear and threat.
Decisions made about the map directly influenced further design elements of the enemies. At first the game was going to include multiple types of both humans and aliens. As things started coming together though, it became clear that an all-purpose Guard was the only human we needed. More of the alien types survived the development process, but the final three kinds of aliens have only names in common with the early concepts.
Once we had the types of enemies determined, we needed to give them stats and a system for activating. Normal enemies have only two stats, attack strength and toughness. We considered other stats, but core game rules took their place. For instance, a player can try to outwit an enemy on the same tile in order to leave it. Instead of the enemies having an Intelligence stat that determines how hard the outwit challenge would be, the difficulty is controlled by how many enemies are on the tile. Rules like this help keep the game fast while making sure enemies remain relevant.
The core of the enemy automation system is on the event cards. At the top of the card is a section that controls what enemies spawn and where. In early playtests enemies only spawned on a tile when it was explored. This meant that every time you found a security tile, you also found a guard. We wanted things to be a bit more unpredictable than that. In the final design, exploring a tile with a security or fear icon forces you to draw an event card, and that card could spawn a guard or a clone. If a guard spawns, it appears on the security tile closest to the player resolving the card, and if a clone spawns, it appears on the fear tile that’s closest. This means you could find a guard on a tile with a security icon when you explore it—or he could spawn halfway across the map, perhaps even on the same tile as another player.
The bottom of each card controls activations. We talked over a number of different systems and tried several before we came up with the final version. The goal was always to make the enemy activations random so they were more unpredictable; this meant there would be turns where nothing activated and the players would feel safe. In the finished system, the number of players that started the game determines the frequency of enemy activations, allowing us good control over how dangerous the environment is. The first draft of the cards created an environment that was very similar to what the three-player game uses in the final version. That frequency of activations in a four-player game results in a lot more player death than we wanted.
The final element of the enemy activations is one of my favorite parts of the game. Each guard and clone has a number that determine their spawning and activation order. This is important because when an enemy activates it will try to attack a target on the same tile, and if there’s no target on its tile, it will move toward the closest target. Dictating the order and placement of the enemies makes that matter more. As an example, let’s say you are on a tile with Guard #1, and Guard #2 is on an adjacent tile. When a guard activation is drawn, Guard #1 attacks you, then Guard #2 moves onto your tile. Since enemies either move or attack on a turn, Guard #2 can’t attack you yet. If the numbers on the guards are the other way around, though (so that Guard #1 is the one on a tile adjacent to you and Guard #2 is the one sharing your tile), your situation changes quite a bit. Guard #1 activates first and moves onto your tile, then Guard #2 activates and attacks you. Because there are two guards on the tile, that attack is stronger. This simple activation order can sometimes make it feel like the game is doing things very purposefully, and that makes me happy.
Next time we’ll wrap this series up with a look at the scenarios.