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 (this part) I discuss 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 Part 2 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.

When I set out to make Double Dodge over a month ago, I decided I needed to set some rigid boundaries for myself. Prior to this game, I had spent about a year and a half bouncing between ideas and projects that never really came to fruition. I always had a grand idea in my head for what a finished game would look like. I’d sit down, spec out some broad strokes like what the world would look like, the narrative context or a core mechanic or two. Then I’d get to work. A month later, I’d get stuck. Sometimes, I’d lose steam on an idea and a new idea would feel more attractive. Maybe I’d realize a certain mechanic I was prototyping wasn’t fun. Other times, I just didn’t feel like making a game for a while. Regardless of the reason, each hurdle would lead to starting over and starting over would lead to a mounting belief that maybe I was just not cut out to do this. A year and half later, 5 prototypes and numerous never started game specs, I finally reached my tipping point.

Now, to be clear, I am generally opposed to the idea that we should place value on how we spend our time based on the end results. I enjoyed (for the most part) making those “failed” prototypes, and I learned a lot in the process. I genuinely enjoy the process of learning new things, often more than I enjoy actually being good at them or building “deep knowledge”. It’s the journey, not the destination, etc. However, making a game has been a dream of mine since I was a kid, and I wanted to actually achieve that goal, even if the only person who ever played my game was me. 

I decided I’d give it another go, but this time I’d approach it differently. I had previously stumbled upon this gem of a talk by Charles McGregor where he details his (remarkably similar) journey from being a hobbyist game developer to actually finishing his first (later commercialized) game. In the talk he proposes a few ideas that, when he finally listened to, helped launch his career. The first was to give himself a time limit to make a game. The second was to commit to sharing the game with someone at the end of that time period, regardless of how “good” it is. These are of course suggestions I had heard numerous times and thought I had been putting into practice. Most (not all) of my prototypes were pretty reasonable in scope. Still, watching this video caused me to reflect on my approach and how I could adapt. 

Ultimately, I realized that my issue wasn’t that I was overscoping my game (i.e. biting off more than I could chew), I was just not focused when designing it. Imagine you set out to build the best pizza delivery app. You have all the core components: the user can find a restaurant, place an order and someone (who is paid well and given health insurance!) would deliver it to you. You come up with two new features you think would be great. The first is to build a “passport system” where each time you try a novel pizza creation you get a stamp. The other is to add a section for all the cheeseburger joints in the area. The passport system is almost certainly much larger in scope. You can reuse all the code you wrote for the pizza section to build the cheeseburger section, so it would be quick to build. But the cheeseburger section doesn’t help you build the best pizza delivery app. This feature lacks focus, as it doesn’t reinforce the core experience of your app. I realized I was continuously adding cheeseburgers to my games and never building the passport system. I’d get to a point where my core mechanic would be prototyped and I wouldn’t know what to do next to make a game around it. Don’t know how to make combat fun? Rather than revising the core game loop, I’ll add a new weapon type. Struggling to think of a way to test the player’s mastery over a mechanic through level design? Build a new mechanic.

Looking back, I think that these habits were coping mechanisms I had built up to avoid facing the fact that I was a experienced programmer and a novice game designer. It was easier to build laterally (i.e. creating cheeseburgers like new weapon types) because I’m good at building an abstraction in code and rapidly generating content through variations of that abstraction. For instance, I can easily create an abstraction for a gun and rapidly prototype different shooting mechanics. I have a much harder time analyzing why a game mechanic is or isn’t fun and designing content that adds depth to a single mechanic. Since the latter is hard for me, I lean on the former. That is, until I get bored or run out of ideas. Then it’s off to the next spec I can turn into code!

Now that I had ascended to the very peaks of novice game design enlightenment, I was ready to stop making cheeseburgers and start creating stamps for ordering pickled rhubarb pizza! So I designed a challenge for myself modeled off of Charles’s suggestions, adapted to challenge my specific weaknesses. I decided that I would commit to doing a one month game jam and at the end of the time period I would put my game on Itch. Even if I hated it. These acted as motivations to keep my scope and focus narrow, but also to satisfy my long term goal of finishing a game! I decided I would use an arbitrary game jam prompt as an inspiration for what type of game to make. My prompt ended up being “make a game where you have to control two characters at the same time.” Why? Because I had a dream about that prompt early that week. *Shrug*

In addition, I added the following two constraints:

1.  Everything must reinforce the essential experience - If I can’t explain why a mechanic or game system reinforces the essential experience, I’m not allowed to add it. The essential experience I landed on as part of the initial design process was “a game that creates a sense of mastery over action-oriented, multitasking objectives in an intense, dynamic environment.”
2. Build as few mechanics as possible - Design some core mechanics and don’t add any supplemental mechanics or systems until I have a playable game, even if they reinforce the essential experience. The idea is I wanted to build the simplest fun game that I could. My first playable demo only has one in-game player mechanic: moving. There is a second out-of-game mechanic which is the player keeping track of their position in addition to multiple enemy movement patterns. At one point I designed a risk/reward system where the player could opt to rush through the level to grab an expiring health container (thus risking taking more damage along the way). I believe this reinforces the essential experience because it adds a level of multitasking. In addition to tracking the immediate threats (like the enemies on screen) the player has to weigh whether the bonus health is worth the risk of rushing through those enemies. This is a decision a new player will struggle with because too much of their attention is focused on those immediate threats. I decided to cut this feature because it wasn’t necessary to make my core game loop work. My game could still be fun without it, and I can always add it in a future version of the game without having to redesign everything. Hooray! 

In the end, this approach worked wonders for me, as evidenced by the fact that you can actually play my game! Really though, the intention I put into building a simple, focused game helped me identify where the fun was and how to build on it. Every time I came up with an idea for a new mechanic, I wrote it down but didn’t let myself get distracted by it. I came up with reasons why I was adding things and had a clear rubric for evaluating whether those reasons were compelling. Perhaps surprisingly, I felt more creative then I did in my previous attempts where I had no constraints added to my design process. By being more systematic, it was easier to see what might be effective, and my brain was able to more easily narrow down the “idea space” I needed to explore to come up with an idea. 

Up to this point, I’ve been fairly hand-wavy about how I actually designed the game. In part 2 of this series, I go into more depth on how I went from prompt to core experience to core game loop. Part 3 will talk about how that shaped my level and enemy design.

Overall, I’m extremely happy with what I was able to accomplish over the last month. I had fun making the game and I have fun playing it as well! I wouldn’t expect anyone to engage with it for very long, as it is not very deep (yet) and needs a lot more content and difficulty balancing. However, it's clear to me that there is a foundation upon which to build. For the first time in my short game development journey I have a playable game! 

Head on over to part 2 if your interested in seeing how I designed the game's core mechanics. And Charles, if you’re out there, thanks!

-Kyle