Lessons in Failure - A Post Mortem of "Necromancer Cheatcode"

A game made for the game jam "Jamepecticeye", where the theme was "Death is an Opportunity"

Screenshot from Necromancer’s Cheatcode

This last weekend, I joined a game jam. It didn’t go too well. As is tradition, I’m going to do a post mortem—or an analysis of how the jam went, and what lessons I’ll be taking into the next jam I do.

So let’s dive right in.

Quain, What’s A Game Jam?

Game jams are where game developers, whether programmers, artists, designers, musicians, or anything in between, get together to make a game over a short period of time (usually a weekend). Jams can have thousands of participants, competing either solo or in teams, to create a game that is then judged and ranked by other participants and/or community judges.

Some jams have more rules than others, like specifics on which engine, genre, or game mechanics the participants must use. Almost all of them, at minimum, have a central “theme” that the teams can interpret as they will, often with a grading criteria on how well the theme was incorporated. The theme is almost always kept secret until the day the game jam starts, making sure every team starts at the same time.

This particular jam was put on by a YouTuber by the name of Jacksepticeye. The jam, Jamsepticeye, had the theme of “Death is an Opportunity.” It lasted 5 days, with game submissions due by October 5th at 9pm.

Our Game: Necromancer’s Cheatcode

We batted quite a few ideas around when the game jam started. My personal favorite was a reverse murder mystery called Grim Reaper’s Assistant where you played as Grim and were secretly interviewing dinner party guests to see who you should kill to make your assistant, but ultimately we steered away from that to a more action-oriented game.

In Necromancer’s Cheatcode, you played as a necromancer who has been barred from the Wizard Library because “ew, necromancy? That’s not a real magic discipline.” To get inside, you had to defend yourself from the Library’s defenses (orcs) while raising and using minions (skeletons) to solve platforming puzzles to reach graveyards, where you would raise more minions until you had enough undead wizards to open the Wizard Library’s doors.

As a concept, this is a relatively simple game. You command units to do things for you, including keep you safe from enemies, so you can earn more units to do more things until you can do the ultimate thing.

In execution, this is a lot of work. A player character with quite a bit of functionality, environment puzzles and design, enemy AI and combat, resource management, and more. To make the game functional would take quite a bit of time. To make it FUN would require even more time.

That isn’t to say it was impossible. In fact, if we had planned better and had one or two more people, I think we could have put something really special together.

In the end, the skeleton movement was our downfall. We had designed enough of a game to be playable, but to send skeletons to certain points on the map to interact with puzzle pieces required what’s called a “navigation mesh”, which is video game speak for a flat plane the AI could use to find a path from point A to point B. We managed to get the AI functional in a test level, but we couldn’t get the nav mesh to work in the actual level before the deadline, which meant you could summon minions, but you couldn’t tell them to go anywhere, which made puzzles impossible to solve.

Things didn’t fall apart at the end, though. They fell apart long, long before then.

In fact, they fell apart right from the beginning.

Pre-Development

When it comes to game jams, I am notorious for—what’s a way I can frame this while still making me look good?—taking a leadership position. I blame my production background and my time at Full Sail University, where I learned that if I don’t put in the work to finish something, it will never get done.

In the past, this hasn’t been too much of a problem. Almost every game jam I’ve been a part of before this has been one I’ve put together myself. The game’s design, such as its mechanics, player actions, and core gameplay loop, would often fall to me because I put the group together, so people generally expected me to continue leading the project once the jam started.

After several jams, I started getting a good sense to what needed to be done on my end to make sure we could have a game. Choosing a game engine, getting “version control” up and running so everyone could work on the game, establishing roles and production schedules, making builds for the game that could be submitted to the storefront, etc. A lot of the stuff that isn’t actually developing the game, but that needs to be taken care of by somebody.

However, the last jam I was a part of (A narrative adventure called “Arctic Jam”) ran into some conflicts with this methodology. For the first time, other people wanted to head the design, narrative, and production of the game, while my role was entirely programming and implementation based.

I was happy to “relinquish control,” but then things fell apart. Several of those who wanted to head production, design, and even help with narrative, were either unable or unwilling to do the things they needed to do, which resulted in me picking up the slack of design, narrative, production, and pretty much everything else except art and audio.

I don’t blame anyone by any means, I just mean to say that it was a lot. So, going into this jam, I forced myself to take a backseat. I said I would help with level and narrative design, and let the other developers interested in design and programming take over their roles.

Development

Necromancer’s Cheatcode was a 5 day jam, and we had 5 people: an artist, an audio person, a programmer, a designer (me), and a programmer/designer split. This was my second time working with this team, but they’d worked together several times previously. This was about half the people they usually had, and a jam less than half the length that they usually go for (most of their jams have been 2 weeks long).

The plan was to spend the first day (Wednesday) brainstorming, defining an idea, and getting everyone a scope of work heading into the weekend where most of the team could work.

Short of a general idea of what the game was going to be, and a quick bullet point list of features, that first day didn’t get us very far.

Thursday came and went without much progress, either, short of sitting down and defining some of the features we wished the game to have.

By the time Friday came around and I could devote a full day’s worth of work to the game, we had close to nothing. The best we had was a test level with a playable character with a really wonky control scheme, like a fireball attack and unique mouse movement modes—neither of which were part of core functionality.

I quickly discovered the culprit: Our design for the game. It looked like this:

Player character:

1. WASD to move

2. Mouse to look around

3. LMB to attack

4. RMB to control skeletons

And that was it.

Here’s the problem with designs like this: my idea of what “WASD to move” means vs. someone else’s idea of what “WASD to move” means can be completely different. It isn’t specific enough. And for more complex ideas, like “LMB to attack”, it’s too many questions. What does attacking look like? What does it do? Who are you attacking? How much damage should you do? When should you attack? What gets interacted with when you attack?

It’s questions like this that led to a character who had fireball attack in a game about summoning skeletons and moving them from point A to point B.

It’s here, halfway through Friday, that I sunk into my usual role. I went in and actually defined what these features meant, including examples, tutorials to follow, specific button presses and initial values, and what NEEDED to be done for there to be a finished game, vs. what were considered “stretch goal features.”

For context, here’s the first design for “summoning skeletons”

Press Tab to summon skeletons.

Here’s the updated design:

Press Tab to Summon Minions

• Pressing Tab anywhere will spend a “bone” (currency) to summon a minion. The minion will follow close behind the player by default and follow where you tell it to go (Left Mouse Button).

  • You have a maximum amount of minions you can summon at a given time. Increase the maximum by interacting with Graveyards.

Now, this design works off of other designs defined in the doc. If I had more organization and clarification, a lot of this info would’ve actually been placed in a “Minions” section of the design document, but I didn’t have time.

In addition to this, I wrote out the game’s core design (that “you’re a necromancer barred from the Wizard Library” bit I gave at the beginning of this post mortem) and a core gameplay loop.

If you’re interested, here’s the core loop:

You are a necromancer who has been barred access to the town’s Wizard Library because of your dark ways. To gain access, you’ll need to collect the bones of other fallen wizards at graveyards, summon them as minions, and use them to unlock the Wizard Library.

Here’s the gameplay loop:

1. Kill enemies and non-hostile NPCs (non player characters) to collect bones.

2. Spend bones to Summon a minion

   1. Minions die if hit by hostile NPC or fall off the map

3. Send minion to locations on the map to solve puzzles. Minions can be hopped on to aid in platforming, and can stand on pressure plates to open doors.

   1. Some pressure plates require multiple minions.

4. Finish puzzles to access a graveyard.

5. Use graveyard to increase the maximum number of bones you can hold at one time, and the maximum number of minions you can summon.

6. Rinse repeat until you can summon enough minions to unlock the Wizard Library door.

I encouraged everyone to read this and get on the same page for what the game was about.

I finished out the day by separating features into what would be required to create the gameplay loop (often called the minimum viable product, or MVP) and what would be additional stretch designs, such as being able to sling your minions across gaps with a Catapult Spell. Then I relayed the info to our designer/programmer including a prioritized list of what should be worked on first.

On Saturday, I personally wasn’t able to contribute much. When I hopped in at the end of the day, I found out something depressing:

Almost nothing had been done.

So, I did what has been instilled in me by my years of production and project management. I cut. Relentlessly.

The rest of that evening, I spoke with the other designer and programmer and told them the news: There would be no more enemies, no more extra spells, no more UI, no more economy management, no more recalling minions. We reduced the game to: summon minions, use them to solve puzzles, summon more minions, unlock the final door and win.

Saturday evening saw some progress, like getting graveyards and pressure plates, doors, and elevators working.

Sunday, the day the jam was due, was when we made the most progress. Individual unit management, tutorial messages, puzzle design and creation, bug fixes, etc.

We also lost a ton of work. Features that should have been cut but weren’t, like death zones and respawning, were instead worked around and led to some blocks that ate away at time we should’ve spent on things like the nav mesh.

By Sunday evening, we had almost everything functional. Which means, even if we had solved the nav mesh problem, we wouldn’t have had time to test, bug fix, iterate on design, or make any improvements.

The Post Mortem (Or The Lessons I Learned)

The best part about game jams is they’re an opportunity to learn. A lot. Whatever you choose to improve on, be it art, programming, or design, you’ll almost always learn something new. You’ll improve.

And, I’m happy to report, the same holds for games you don’t actually finish.

For my part, a lot of what I learned was process and design principles, and the opportunity to work in the Godot game engine for the first time.

What went wrong?

As we just talked about: a lot.

1. The biggest issue was a failure of production: not having a realistic understanding of skillsets and availability. For instance, if we had a more experienced team, or we knew that our designer/programmer was more interested in programming than designing, then we could have gotten a lot more done.

2. The lack of a plan, or deadline, was another failure. One of the best game jams I’ve done was for Creature Comforts last year. Stressful and a lot bigger scope than we had initially planned for? Yes. But we had development deadlines that allowed us to have regular builds of the game and keep a realistic timeline. A good plan is something we really lacked in both Arctic Jam and now Necromancer’s Cheatcode.

3. Too little design too late. But the time I went in on Friday to clarify the game’s design, our programmer had already spent quite a bit of work on the player character, giving them functionality that we didn’t need and movement that felt all over the place.

4. No communication. Games live and die by their ability to be defined, communicated, and iterated upon. Even after defining the game, telling everyone about it, and writing out a gameplay loop that takes less than a minute to read, I was so disheartened to hear our programmer on Sunday afternoon ask “Does anyone even know what this game is supposed to be about?”

What went right?

There are SOME things that went well.

1. Experience in Godot Engine. I really enjoyed Godot’s workflow, and more experience inside of another game engine is always a good thing in my book.

2. Design principle reaffirmation. I’ve generally not been the biggest fan of big, long, game design documents, but this time around, I wrote out a game design that was basically playable in the document, and could be worked off of programming-wise without me having to be there every single minute of the jam (as long as the programmers, you know, read the document).

What’s next?

What lessons am I taking forward? Well, first and foremost: a plan. If I were to split it up into another 5 day jam, here’s how I would do it:

• Day 1 — Define the game, including engine, genre, and initial design. Communicate that initial design to everyone from the get go so they can begin exploring the game in their own way. Spend the rest of the day paper designing the entire game. Character inputs, environments, obstacles, economy, enemy AI, everything. Finish the day by finishing the document, seperating it into must haves (MVP) and bonuses, and prioritize design elements (IE: it’s more important to have nav mesh than to have a death zone, since death zones can be designed around).

• Day 2 — Program all high priority designs. Player character, button inputs, environment interactions, etc. Paper design levels other things outside of the engine, and help playtest programming features as they come in to identify bugs and help iterate. Work with artists and audio to iterate and create base assets.

• Day 3 — Implement paper designs, art, audio, and set up the base gameplay loop and functionality. Continue refining programming bug fixes and (if possible) start working on stretch goal designs. Put in a game start and game over/game complete screen to signal to the player the start and end of the game. End the day with a complete game that can be built and playtested.

• Day 4 — Refine core designs and implement stretch designs. Find the fun. Make new levels, new music, new mechanics, refine economy, etc. Day 4 is all about adding content to the game. If it’s a puzzle game, Day 3 is about making the first five puzzles. Day 4 is about making 10 more. End the day with the “Release Candidate”—a version of the game that can be submitted to the competition in case of catastrophic failure on Day 5.

• Day 5 — Continue adding and polishing. Things like camera sway, special effects, particle systems, lighting tweeks—things that are often defined as “juice” in games: the extra stuff that adds to the experience, but isn’t necessary for the game. Write submission copy, finalize main screen and game over screen, and make a build. End the day by submitting a build of the game a minimum of 1 hour before the gam jam’s deadline.

If the game cannot be completed in this timeline, then the idea is too big. If not everything can be designed by the end of Day 1, then the design is too complicated. If it can’t be programmed by the end of Day 2, then the design is too complicated. The scope is too big. It needs to be scaled back.

The only other thing I’m taking with me in the future is in choosing my team: If I’m going to work on a game jam with someone, I’m going to work with people who communicate, which means people who read the designs, who look for feedback, who ask questions.

Having our programmer ask “Does anyone even know what this game is about?” hours before we’re supposed to submit the game is actually unacceptable to me.

Do I expect everyone to know everything about the game? Of course not. Do I expect everyone to take literally 1 minute of their time to read the core game design to understand the game at the highest level? Yes. Because if the programmer didn’t read the core game design, I can be sure as shit they didn’t read how things like graveyards and summoning minions worked. They’re not communicating, and when things fall apart, they’re deflecting blame.

Conclusion

Whether this game was finished or not, I was going to write this post mortem. I find a ton of value in these, both as a tool to understand my own thinking and development, and also as something I can look back on before starting the next game jam to refresh my memory and make goals.

The game might have “failed,” but that doesn’t mean I didn’t learn a ton.

More than anything, I learned the value of communication, early design, and a game plan.

Thanks for reading.

With A Smile,
Quain Holtey