LD41 Postmortem Part 1: The Games I Didn’t Make

Ludum Dare 41 was my first game jam, and I was determined to produce a complete concept. I’d read some horror stories about developers who overscoped their games and couldn’t really finish them by the deadline, and I wanted to avoid that. Unfortunately, I also had a minor cold, so I knew my productivity was going to be hampered. Oh, and my wife was working night shifts at her job during the week, so our sleep schedules would both be thrown off. Hooray!

One of my design skills that I’m most proud of is the ability to model game systems in my head and find problems quickly. This can be dangerous, of course, because if I use it during brainstorming it can hamper creativity by closing doors too quickly. But when brainstorming ideas for a game jam, it’s actually perfect because I don’t have a lot of time to work out design problems; I need a concept that I can for sure build, and that satisfies the criteria I laid out for myself.

Oh, it’s also worth mentioning that I wanted to make a game for the Compo, which allows for 48 hours and has strict “make everything from scratch” policies.

So, here were my criteria:

• The idea needs to be simple enough to be a “complete thought.”
• It needs to fit the theme – “Combine two incompatible genres”
• I need to be able to execute thoroughly on both genres so that the concept doesn’t feel like a cop-out
• It needs to be something that I can pull off with my very limited art skills
• It needs to be in Unity, because that’s the engine I know best at the moment and I need to be productive
• Preferred: I want to make something 3D.

So, let the brainstorming begin.

Idea 1: Roguelike Walking Simulator

This is the discarded idea that I spent the most time on. One of the things that appealed to me about it was that I could use my voice and build a narrative. I enjoy both voice acting and writing stories, so this would seem to be a good choice. I also enjoy weird narratives, and nothing could be weirder than a randomly generated narrative.

As I pursued this idea, I thought about how silly I could make it. I wanted to create a bunch of rooms, and then fill them randomly with objects. The objects would be silly too – my brainstorming list includes “Disco ball, flan, cactus, suitcase, giant sausage, large orange, and dais.”

Finding an object would trigger narration tied to that object which would contribute to a larger story. But I would also make the game shorter than the length of the story, so that the only way to get the whole story would be to play through the game multiple times and try to figure out how all the elements fit together.

But then I started to have second thoughts. Roguelike implies more than just procedural content generation; It also implies things like permadeath, and an actual challenge. I considered changing the genre definitions to “procedural generated walking simulator,” but procedural generation is a method, not a genre.

I also considered adding some challenging elements or some kind of death mechanic, but nothing made sense with the rest of the concept.

So I moved on.

Idea 2: GUNBALL

It’s a pinball shooter! The idea here is simple: Spacebar controls the flippers, mouse aims, mouse click shoots.

At first, this seemed like a perfect fit. Neither of those mechanics seem especially hard to build. Unity comes with enough built-in physics that I could probably make a pinball game pretty easily.

But… could I? In theory, maybe. But game physics are full of gotchas, and I don’t have enough experience Unity’s physics to confidently make a game based entirely on physics.

There’s also the problem that a good pinball game actually has a lot of moving parts, and I’ve never made one before. I would have to build out curves that would work properly with the physics to move the ball around, bumpers, and those things that hold the ball for a second and then spit it back out again…

On top of that, I would need shooter mechanics.

I also explored how a level would be designed. A single board may not be enough fun or enough gameplay; Multiple boards would require a lot of design work.

At that point, I couldn’t see a way forward that wasn’t altogether Way Too Much Work. And so, onto the next idea.

Ideas 3-X: Brain Dump Time!

It was after dinner – several hours had elapsed since the theme was announced, and I still didn’t have an idea. At this point I decided to just start trying to metaphorically stick my finger down my brain’s throat and vomit out as many ideas as possible.

I thought, what have other people made with Unity? I remembered all those tiny horror games made with Unity that are basically “don’t let the monster get you,” and I thought – what if when the monster gets you, he asks you questions? Hey, it’s a horror/quiz game!

But then I remember that there’s an entire game in one of the Jackbox Party Packs that is literally a horror quiz game, which made my idea feel less interesting. Also, I felt like if I was going to go to all the trouble of making a game, I should probably find a more interesting concept than “avoid a thing and then take a quiz.”

Next up, a match 3 platformer! I’m a huge fan of games like 10000000 and You Must Build a Boat (okay that’s basically the same game) where there’s a match 3 mechanic and action/RPG mechanics. (I also think Puzzles and Dragons is utterly brilliant.) I considered a more deliberately frustrating, troll version of a match three game, where the match 3 part of the game is in the middle of a platforming level, and the player has to walk around the level picking up colored bubbles and dropping them on top of other ones to match.

I just wasn’t that excited about it though. It seemed more like a “hey look at this goofy concept” than something that could actually be a fun game. I mean hey, a game that’s basically 100 fetch-quests, right?

And finally, a stealth physics game. I thought about taking two concepts that are completely opposed to each other: Games where you have to break as much stuff as possible (like Angry Birds) and games where you have to break as little stuff as possible (stealth). So, I imagined building structures out of physics objects and letting the player fling their stealth agent around, over, and through them while causing as little destruction as possible.

But that would present one of the same challenges that caused me to rule out pinball: I don’t know enough about Unity physics to confidently build that game. And I know that Angry Birds, in order to offer as much destruction as possible at 60fps, has finely tuned physics code. And that’s something I had neither the time nor the expertise to manage.

Final Idea: FPS Cooking Simulation

The pitch I wrote down on paper is simple: “Shoot enemies, push their corpses into stew.”

I wrote down the major tech requirements, and it was only two bullet points:

• FPS controller
• Camera facing sprite script

In truth, that wasn’t actually the full list. I also realized I would need to learn and use something to build level geometry, so I picked ProBuilder (which is now officially a Unity product, and free).

There’s also the fact that I’ve wanted to build my own FPS for years, literally since I was in third grade and played Doom for the first time. My notebooks from then until age 12 are full of sketches of levels, monsters, and weapons for an imaginary FPS. (That wasn’t my only imaginary game – there were many others!)

And my plan as an indie developer is to eventually build a fully featured FPS inspired by Doom 2, Quake, etc.

So this felt like a good start.

Before I close out Part 1, let’s see how the concept fits my requirements.

• The idea is definitely simple enough to be a complete thought. The shooter mechanics can be simple, and the cooking just needs to be “include the correct ingredients or you lose.”
• It fits the theme.
• Given the simplicity of both genres (IE the requirements for a game to fit the genre are simple, unlike, say, Roguelike) I can execute on both fully enough
• I can pull it off with my limited art skills by using billboarded sprites in a 3D world.
• It can be done in Unity
• It’s 3D

So, at that point, I had chosen a concept I was 100% sure I wanted to execute on. In part 2, I’ll explain how I did it, and where I made mistakes.