Double Dodge is a procedurally generated dodge 'em up which challenges players through multitasking objectives. The player controls multiple characters as they avoid obstacles to reach the innermost depths of an ever-changing dungeon. I have been working on this game for over a month and have just released my first playable demo. This multi-part devlog covers my design process to date. 

In Part 1 I discussed my history of bouncing between projects and how being more intentional in the design process has helped me stay focused and be more effective.

In this part I discuss how I went from a game jam prompt to designing a core game loop and its mechanics.

In Part 3, I cover how I designed the procedurally generated level as well as the game’s current content.

Now that I had some parameters set for starting my next project, it was time to actually design the game!

Starting with a prompt.

For this project I chose to use a prompt that I chose somewhat arbitrarily. The prompt was “create a game where you control multiple player characters at once”.

I knew this would present a good design challenge. As a player I tend to shy away from games where you have to control multiple characters. These games tend to stress me out rather than be fun. They naturally have a high cognitive load because you are forced to multitask. This is compounded if the game also has complex game systems. For instance, StarCraft requires you to control A LOT of units at once and also happens to be one of the more complex strategy games out there. I realllllly don’t enjoy StarCraft. On the other hand, I do really enjoy twitchy platformers and dodge ‘em ups like Super Meat Boy or Disc Room. StarCraft and Disc Room are, on the surface, polar opposites. Where StarCraft is about multitasking, resource management and competitive strategy over a long game instance, Disc Rook is about focusing on a single character on micro-tasks for very short durations (often 10 seconds). However, the more I thought about it, the more I realized that there are commonalities between the two genres. While you only control one character in Disc Room, you still have to focus on the numerous obstacles that could destroy you. In essence, both of these games require a high level of multitasking. So what makes StarCraft feel overwhelming for me while Disc Room was an addicting blast! My guess is it’s their primary differences:

1. StarCraft has an incredibly deep system design that requires a lot of patience and planning to master whereas Disc Room has barely any systems.
2. StarCraft has long game instances. Unless you are me. Then you lose quickly. For everyone else, it takes awhile to get feedback on whether the choices you made under pressure early in the game were the right ones. Disc Room requires very short-term planning (more like reactionary planning) and gives near instant feedback. If you mess up, you're dead!
3. There is a significant visual/spatial disconnect between the units you control in StarCraft. Units are scattered across the map, continue to carry out actions even when offscreen and require a high degree of context switching because each unit may be working toward a different long-term goal (one is gathering resources, one is fighting). Also there is a high degree of uncertainty because you don’t know what your opponent is doing. In Disc Room, every obstacle is on-screen and moves in a very predictable pattern. Moreover, tracking multiple enemies may require multi-tasking but ultimately this is for the same short-term goal of staying alive. It’s much easier to build up “muscle memory” for how to dodge two objects moving in different patterns than it is to control two units in completely distinct planning objectives.

From this analysis, I decided that I wanted to build a game that was a lot closer to Disc Room than StarCraft, while incorporating some of the more “heavy” cognitive tasks from StarCraft like a bigger visual/spatial disconnect. This is what led to the eventual 

At this point I had a vision of a game with a dodge ‘em up core gameplay loop, but where the player controlled multiple characters. I imagined multiple variations of this, but eventually decided to split the player’s characters across two physically separate game spaces (as in the current demo). The mechanic is a bit “gimmicky”, but for a one month game jam it’s been a fun experiment.

Defining a core experience.

The next step to designing my game was to hammer out a core experience. I’ve seen a number of definitions floating around, but the one I like is: “the way the player should feel when playing the game”. This is a holistic approach to creating a rubric that can evaluate whether the game or any of its mechanics “feel” right. If I was making a Batman game my core experience would be something like: “to feel like a vigilante badass with a strict moral code”. Building a feature where you have to make moral decisions (a la Bioshock) might feel pretty out of place in a Batman game. Having to safely disarm a gang of thugs in a dark warehouse using a number of non-lethal gadgets would feel much better.

In the context of my game, I started by writing down some of the adjectives I’d use to describe the vision in my head:

• Twitchy - I find this to be the defining characteristic of the dodge ‘em up genre. It’s about building up your muscle memory to perform brief, repeated actions in the game space. When you watch someone who is better than you at a twitchy game, it can seem almost incomprehensible that they are able to react so quickly to stimuli (think about someone who is insanely good at Beatmania).

• Periodically Intense - Multitasking requires a high degree of concentration and being in a state of “flow”. If there are too few tasks, the player will not be engaged and will get bored. If there are too many tasks for too long the player will become anxious and want to stop. I wanted to design the game so that the player would come in and out of brief, but intense moments to experience challenges without burning them out.

• Progressively Challenging - As the player builds muscle memory, the challenge needs to increase to match their skills, in order to stay in a state of flow. This also builds a sense of mastery of the game’s mechanics. Everyone likes to get better at things!

• Dynamic - The recent surge of procedurally generated Rogue-like games have shown how important having constantly shifting game environments can be for keeping engagement and making a game replayable. Contrast this to a game like The Impossible Game, which is extremely twitchy, but is completely static. It can be fun to master the course, but also it can get really tedious to play the parts you’ve mastered already over and over. Games like Super Meat Boy find a middle ground by creating a series of extremely short, but varied sections of content. I wanted to lean toward a more dynamic game, largely due to personal preference.

This lead me construct the following core experience: 

“Double Dodge is a game that creates a sense of mastery over action-oriented multitasking objectives in an intense, dynamic environment.”

This is a pretty lofty experience goal. The current iteration of the game has a long way to go before it hits on that sense of “mastery”, but I do feel like I’ve built a foundation that can eventually succeed in this.

Constructing a core game loop.

At this point, I worked to define the core game loop. I’ve been reading up on game design (Specifically, Advanced Game Design: A Systems Approach- highly recommended) in parallel to my work. As a result, what I’m presenting here is much more systematic then what I actually was thinking about the first week working on the project. I don’t want to give the impression that this just fell out of my brain.

In its most abstract form, my core gameplay loop looks something like this:

The components in green reflect the player’s short-term interaction with the game world. It’s intentionally simple. Based on my past experience, I needed to really focus on creating a minimal core loop before thinking about any deeper systems. 

The gameplay can be summarized as follows: the player avoids obstacles in order to progress through the current section of the game world, at which point they will enter a new section and repeat the process. In order for this game to be fun, avoiding obstacles needs to be adequately challenging and varied enough to stay interesting. Additionally, completing a section needs to feel like a worthwhile goal. Any systems I add beyond that must reinforce that feedback loop. 

Drilling down, the items in blue represent subloops of the core loop which comprise what is actually happening on a fine grain level. The act of “avoiding obstacles” can be broken down into a sequence of in-game actions (meaning the player directly interacts with the game world through input) and out-of-game actions (meaning the player is doing something in their physical/cognitive world like ‘thinking’ or ‘tracking an enemy). A mechanic that reinforces this loop might be an obstacle that is hard to track because it temporarily becomes invisible. This also ties in nicely to the core experience because tracking an invisible enemy feels like something that requires mastery over the game’s mechanics. Conversely, adding randomness to an obstacle’s movement trajectory could make things less fun, because the player simply can’t build the skill of predicting it’s trajectory. Too much randomness would reduce the player’s path planning to arbitrary guessing. This would certainly eliminate any sense of “mastery”.

On the other side of the loop, the “complete section” acts as a feedback mechanic. It gives the player a sense of accomplishment by incrementing their score as they progress. It also acts as a balancing mechanic because the game gets progressively harder over time (more on this in part 3). In my opinion, this is one of the areas that is most lacking in the current iteration of the game. The existing score system doesn’t really give the player a strong goal to progress towards nor does it convey a sense of mastery. How does score relate to mastery? Is 15 a good score? How about 30? As is, the mechanic puts the burden on the player to define what their objective should be. Should I play until I get a high score of 30? In future iterations I intend to focus on creating a more compelling feedback system for player progression. However, for now I’m intentionally not doing that because it would violate one of my design process constraints, specifically “build as few mechanics as possible”. I have been able to create a fun, playable demo without needing to improve on this system. I’ve left enough space in the short-term game loop that it can easily be iterated on without dramatic redesign of the rest of the loop.

Stepping out a level, I have my “mid-term” loop:

In my level design process (see part 3) I’ve defined a chunk as a series of interconnected sections with progressive difficulty. The main thing here of note is that each chunk will end with a section that has no obstacles, effectively resetting the players cognitive load and giving them a break. This felt like a necessary component to me because without it I fear my loop would cause more anxiety than fun. The “pause” function in They Are Billions immediately made this RTS accessible to me despite actually having more systems than Starcraft. The player can take as much time as they need without penalty, but of course the game doesn’t progress until they continue moving forward.

That is pretty much my entire game loop. There is a lot of opportunity to add new and interesting systems to the game, as well as adding a long-term loop. For example, in the mid-game loop I could add a shop where the player can spend some in-game resources that they collect to get a power up that directly ties into the “avoid obstacles” mechanic. An obvious idea would be adding a power-up that lets you slow down time, which would temporarily make each out-of-game action easier for the player. Similarly, a long-term mechanic could be adding a boss-like encounter after a handful of chunks, or a system of permanent progression that affects future runs. Skies the limit!

The last thing to note is how the “control multiple characters” integrates into the loop. As I mentioned above I had decided to opt for a split screen approach because I wanted to take advantage of the spatial and visual separation of the player. As a consequence, I only really had two options for how to actually move the characters. Either they both followed the same movement pattern or they were controlled independently via separate inputs. I opted for the former because it aligned more with my “as few mechanics as necessary” constraint. Moreover, I actually think it forces me as a game designer to focus more on what I consider to be the main challenge of my game: the player’s out-of-game skills of perception, tracking and prediction. Having to physically control multiple character inputs adds more cognitive load. By streamlining motion through a single input system, it frees mental capacity to focus on those cognitive tasks, allowing me as a designer to add more challenge in those areas.

Conclusion

And that’s it for game mechanics. Short and sweet, as my design constraints required. There were definitely times along the way where I felt myself drifting towards a lateral or supplemental system. I have a few written down to revisit! This time however, I didn’t get distracted by them. Also, learning how to diagram my game loop and break it down to this level of detail has really made the design process easier. I’ve struggled in the past to come up with interesting enemy types. In fact, I’d go so far as to say failure to come up with “content” for my game ideas has killed a number of projects. For me, this systems approach helps me to understand what I should be designing for, which in turns narrows down the possible ideas I should explore. Instead of needing to “design an obstacle” I can now “design an obstacle that is hard for the player to identify”.

In the final part of this series, I really get into the meat and potatoes for how the “content” was built, starting with the level design. To be fair, there isn’t a ton of content yet, but there is a really good framework for adding content quickly in the future. Can only do so much in a month!