Designer Blog 1 - The Warfront From Intercepts

Hi Everyone,

I’m Justin Lam, the lead designer of The Warfront From Intercepts (working title: Project Messages). In this WWII-inspired game, the player plays as a general of the country of Fenrir. The player spends most of their time in The War Room. The War Room is a mess of intercepted messages from the Gorik Empire. These messages contain a lot of misinformation, but hidden amongst them are the real plans the enemy has for an upcoming battle.

Our dev team is comprised of 10 members headed by Natalie Hoffmann as producer. I recommend seeing the team’s work so far in Natalie’s blog. As the lead designer, a lot of my focus on these blogs will be on the design of this game and the process of sharing my vision with the team. This first post is focused on the overall design and vision of the game, pre-production, and the first sprint.

I spent a lot of the summer working on the pre-production for Project Messages. I got as much into the Game Design Document (GDD) as possible to help explain my vision to my team. If you’re interested in looking at this GDD, click here: Project Messages GDD. I admittedly focused a lot of my time on game systems due to my background in game design and programming.

The core idea for this game was based on how important intelligence was in WWII. I wanted a game where players had to deal with the fog of war and make decisions based on the limited information they had. The player has to deploy a limited amount of main and sub units to each battlefield on the war map. Main units can only be 1 of 3 types (Tank, Plane, or Anti-Air) for each battlefield. These types can have an advantage depending on which type of unit they are battling against. However, due to the fog of war, the player can’t see what the enemy is deploying. To know what the enemy is deploying, the player has to go through a pile of intercepted messages. Similar to the game Papers, Please, some of these messages are fake based on the discrepancies within the messages, but the real messages are vital to deploying the right units at the right location. Finally, there is only a limited amount of time to read through messages and deploy units, so the player has to balance between being through with messages and going through them fast to get as much information as possible. Once the time ends, the enemy units are revealed and compared to determine if the player or enemy gains, loses, or keeps territories. This repeats as the core gameplay loop until the player or enemy captures the other’s capital.

While this was the core of the game, there was a lot more I added to the GDD to add more challenge and complexity. This included keywords, offensive and defensive deployments, infantry, and more. I left these elements out when I pitched this game to not bore everyone. However, after I was selected, I was told my game was very under-scoped. While I did feel like there was more to my game than the professors realized, I also felt like I should scope up to ensure everyone had work for the whole semester. 

When scoping up, I first looked into some cut ideas. Originally, this game was going to have more of a focus on using cryptography and ciphers as puzzles, but I didn’t like the idea when trying to flesh it out. Thinking about how I can add cryptography back into this game, I thought of using a machine to decrypt encrypted messages over some time but finding the key for the encryption would allow the machine to decrypt faster. This adds another thing the player has to look out for when reading messages, but if the player doesn’t want to deal with that, they can let the machine take more time decrypting messages. I liked this idea and called the mechanic the AT Machine (AT stands for Alan Turing for a history easter egg).

Another cut idea I wanted to add back was invisible ink and chemicals. The idea I came up with was similar to the AT Machine where there is information hidden in messages and the player had to soak the messages in chemicals to reveal them after some time. However, players have to pay attention to how long they soak the messages since prolonged exposure to the chemicals will ruin the whole message. This mechanic is much simpler to do and gain more information, but also if the player doesn’t pay attention, then it has consequences.

There were a few smaller things I added to the GDD. I added different kinds of sub units. The sub unit originally was just infantry and was supposed to be a neutral unit to help boost the strength score of the main unit. Now there are different types of infantry to support the player and/or the main unit they are attached to in different ways from debuffing enemy units to scouting locations. I also fleshed out how I want battles to be shown. The animations should still be simple so programmers can handle them, but I added more details to add more suspense for the player. Overall, I don’t think this was scoped up enough, but it was a start and I had other work to do.

The next thing I worked on was the UI/UX wireframes for all the screens. These were simple layouts for all the screens to help visualize what would be going on on each screen. This game has a lot of screens due to the tools available to the player for sorting the messages. The amount of screens increased with the new chemical station and AT Machine. If you're interested in seeing the wireframes, click here: UI/UX Wireframes.

The main thing I worked on this sprint was a paper prototype. This was a paper prototype to simulate one day of this game. This prototype’s primary goal was to make sure our producers and programmers understood the basic idea of this game and what they were going to make. I also playtested it with random people to get an idea of how other people thought of it and what potential problems to look out for. If you're interested in the prototype, click here: Paper Prototype.

The overall feedback for the game was positive with a bit of confusion. The team members that playtested the prototype got a good understanding and feel of the game and I was able to answer any questions they had. All the playtesters liked the prototype and were excited for the electronic prototype. 

Being a prototype, it didn’t come without problems. The biggest challenge is going to be explaining rules and procedures to players. Almost everyone missed something in the rules that led to them playing the game poorly or wrong from not understanding how they were allowed to deploy units to thinking the messages were from their side. There are various reasons the playtesters gave like how I laid out the rules and how I worded them. This game is going to get more complex, so it’s good to know that this is something to focus on. 

The other main challenge we found during playtesting was the messages themselves. There were some aspects of messages that made them confusing for playtesters like all the messages were from the same day to 2 true messages conflicting with each other unintentionally. This showed me that we have to be careful in how we write our message templates and how we generate them. Overall, I felt confident after the playtest with the positive feedback and knowledge of what we need to be careful of.

This sprint was full of questions, self-doubt, and learning for me. In the next sprint, I’m planning on writing out a lot of the templates to use for generating messages and maybe cleaning up the paper prototype with the new information. I feel like we are off to a good start, but it’s still going to be a long way to go.