Skip to content

Postmortems

A Postmortem on My First Game Jam

Howdy! My name is Jake and I was lead programmer, project manager, and lore master, I guess, on the Wraiths of Dumra. I have quite a bit of dev experience, though not in game dev and this was my first real end-to-end game I've completed. I couldn't have picked a better team to do it with either!

I'd like to start with some general information about the game then move into what went right and what went wrong.

For more detailed breakdown of the whole process (at least from my perspective) feel free to browse through the dev logs I've been writing throughout the process.

The Team

The team consists of three of us: Andrew, Terra, and me. We've all known each other for a long time but have never really worked on a project like this together. We were sharing what we were individually working on with each other and the idea of doing a game jam came up. None of us had ever done one before but hey, isn't that the point of game jams? Dip your toes into chaos to see if you like it?

We found the Themed Horror Game Jam #22 and thought it sounded interesting. It's spooky season and that was a spooky jam. It was running for 40 days, so we thought that would be great since we all work full-time and we'd have lots of time to casually work on the game. Heh...casually...how optimistic we were!

tl;dr - Key Takeaways

Overall, I'm incredibly proud of our team. I think for our first game jam, and our first "real" game, we did really well. It's definitely rough around the edges and would need more work to make it feel really good but it far surpassed my expectations!

What went right:

  • I love the atmosphere
  • Teamwork really made the dream work
  • Rapid learning of lots of different disciplines

What went wrong:

  • Scope, of course
  • Inexperience with Web Builds, or builds in general
  • Learning to avoid or mitigate merge conflicts
  • Not enough time to polish

I enjoyed my time participating in the game jam, though it did seem to consume almost every non-working hour during those 40 days. That was brutal. I don't think I will participate in another game jam any time soon but glad I did this one. I have a way better idea of what to expect and to look out for moving forward, not just for game jams but also in my own games. I really liked working with Andrew and Terra and can foresee working on games with them in the future, though without the deadline!

Check out the rest of the postmortem below, if you are curious. It goes more in-depth regarding all of this. Regardless, we appreciate you taking the time to check it out!

The Initial Pitch

As part of our initial planning, we each brought some ideas to the table, pitched them, and decided on which one to pursue. One of my ideas was chosen as the starting point and this is what it looked like after some refining from the Team. It is based on a myth from Plygith Dune, our worldbuilding project. Most of the terms are more for internal use and reference different places and things within Plygith Dune.

The game is set out in the wilderness of Dumra, a country continually covered in permafrost due to the presence of a large Soulshard. The main gameplay takes place along a well-worn, snow-covered dirt road, just big enough for a sled. The road is surrounded by forest and mountains. Overall, the Player is part of a supply caravan heading between the Frostwood Conclave and the Dumran Soul Shard along the Soulshard Passage. It is a multi-day trek and the caravan is almost at the halfway point, which is Outpost #4.

The Player escorts the caravan through the night to the next Outpost. The caravan moves at a constant rate. The Player can ask the caravan master X times to stop the caravan. The caravan will stay stopped for X seconds before moving on again.

The Player must keep the other characters warm, along with other tasks. When the Player runs out of energy, they can scrounge in certain patches of snow to get a small amount of energy back. Periodically, a patch of snow infused with more soul shard dust can be found, which greatly increases the amount of energy recovered this way.

As the caravan progresses towards the next Outpost, the glimmerstalker events/actions will escalate. Sometimes, (possibly due to hypothermia) the caravan members will wander. The Player will have to go retrieve them, leaving the light of the caravan. The Player has a faint light that they emit and can cast a spell to increase the brightness and radius of that light. If they don’t find the character in time, the character will be killed with a screech and a flash of light.

Once the caravan is within a certain distance of the Outpost, the sky will start to brighten the closer they get.

Once the caravan reaches the Outpost, the game ends and the Player is scored on their performance.

I was extremely excited about the game idea. While I wasn't sure how much fun or horror-y it would actually turn out to be, it was the first real project being made set in the world that Andrew and I have been building off and on for over a decade that had the intent of being available to the general public. That was something that we've wanted to do for a long time but it just kept getting pushed off. It also gave me an excuse to build out Dumra more and explore more details about it.

Here is where the game takes place in the wider world of Plygith Dune.

A map of Dumra showing the route the caravan is traveling on

The map was also created by Andrew!

We created a project in Azure DevOps to hold the code repository, a wiki, and the board items/tasks that we needed. After getting the pitch down, we took some time to lay out what tasks we thought we would need and made a first pass at prioritizing them. Along with this we assigned "soft" roles to each team member, based on what things we were interested in.

  • Andrew wanted to do some coding, audio, UI, modelling...really a little bit of everything
  • Terra wanted to do some coding, modelling, and effects/atmosphere
  • I wanted to mainly do the coding while jumping in where needed

With the tasks and general roles defined, we got to it!

What went right

Atmosphere

I think one of the things that went the most right was the atmosphere of the game. We wanted it to be a dark night in the wilderness and I think we captured it really well!

Screenshot of the starting outpost to show off the night atmosphere

Terra had a major part in defining the visual atmosphere of the game and Andrew contributed greatly to the UI and audio atmosphere. I mainly just help nudge things along where I thought they needed to. I guess I did model/texture most of the key art, so there is that!

Terra worked really hard to bring the night feel to the game and to make the snow piles stand out in the darkness. I think she did a great job on it! It was amazing playing the game for the first time after her changes and seeing the massive difference it made. Here is a before and after of the changes. Incredible! And it got even better once she redid the terrain and populated the trees and such.

Comparison of the game before and after Terra added the atmosphere

On the audio-side, Andrew is not an experienced composer but he really brought it with the sound. He made several music tracks, as well as almost all of the sound effects (I snuck a few in...). While we didn't end up using all of them, the ones we did use really add to the atmosphere. The main song that plays when someone is being stalked is amazing. That deep cello really fits the mood that Terra set up. By far my favorite track.

Another aspect that Andrew knocked out of the park was the icons. We went through quite a few iterations on the icons and most of them didn't feel right. He was working on redoing the spell energy display (the crystal on the right side of the screen) and he did these sketchy lines and I was hooked. The sketchiness of it, the imperfect lines, it all felt like it matched the overall aesthetic and vibe of the game. He then presented the Warmth spell icon (bottom left corner, 1st box) with the dark background and the white line work and that became the standard for the other icons. Once we had a direction, Andrew was able to quickly do up the other icons. They look consistent and they look great!

Screenshot showing the icons Andrew made, in-game

Teamwork Makes the Dream Work

For never having worked together directly on anything like this before, we ended up working really well together (at least, I think so). As mentioned earlier, we kind of fell into different roles so most of the time we weren't stepping on each others toes.

We had some growing pains, as expected. While Terra and I had some experience with Unity, we'd never worked on a Unity project together, let alone with version control. Luckily, we are both familiar with git from our day jobs, so we weren't going in completely blind. In fact, it was way less complex (git-wise, at least) than my day job where I am dealing with a old, gnarly mature codebase with lots of binaries that don't play well with version control.

Andrew did not have any experience with either git nor Unity, nor professional software development, nor some of the other programs he ended up using...but he is a sharp cookie and picked it all up pretty well! I had to ride the (very fine) line between trying to teach him good coding practices and crushing his soul with feedback. Sometimes, I felt that I was going too far but he kept asking for more. So many tutorials teach you bad practices in the name of simplicity and I wanted to make sure that Andrew avoided a lot of the pitfalls I've seen junior devs make. He made great strides in using all of those programs and I'm really proud of him. I learned that I may also have some control issues regarding code consistency and such...I think it bleeds over from my day job where I work in a very messy legacy codebase and just have to deal with jank!

Learning New Things

Andrew wasn't the only one learning new things during this game jam. We all were. And while I am putting this in the "What Went Right" section, it is not without its costs. We attempted many things that we had not done before. Some were exhilarating while some were just straight up frustrating.

I feel like we all have a way better idea of what goes into making a "complete" game now and the different workflows involved along the way. We got to work with new tools, learn new skills, and learn the process of publishing a game on Itch. Overall, I think the net positive means it deserves its spot in the "What Went Right" section.

However, the dark side of a lot of learning is that there is so much to learn for each given task. Normally, this isn't as much of an issue, because you can just take the time you need to learn it to the level you want. Don't know what the topology of a goat should be? Find some tutorials and play around with retopologizing until you get something that looks right and animates properly!

Well, that is all fine and dandy until you slap a deadline on it. Now you feel pressure to get the thing done and it is incredibly frustrating to not be able to take the time you need. Oh, that's a 2 hour long tutorial? I guess I'll skim through it because I can only spend like 5 minutes on it. Hope I'm not missing something important! Spoiler, you are. While we all felt that pressure, I think Terra felt this the most. She really likes digging into different topics to get a better understanding of them. She is very passionate about learning and that passion was just constantly being suppressed in the name of progress.

What Went Wrong

The Cliché...Scope

Would this even be a game jam postmortem if we didn't bring up that the scope was too large

We tried to be very conscientious of scope when we were planning out the game. We initially got all of our ideas out into the DevOps board and spent quite a bit of time designating which ones we thought were the core game and which ones we thought would be stretch goals.

Looking back, I think we actually did a really good job on defining what the core game would need to be and to get through all of it, while managing scope creep. Terra did a really good job of reigning in scope creep whenever she saw it. Advocating for simple, practical solutions to problems, even if there were some corners cut. This is a game jam after all and not a product that needs to be maintained long term that people are paying for. Here is where we ended up at the end of the submission period, as far as our board items went.

Category Board Item Count
Total (Completed or not) 195
Completed 119
Core - Not Finished 12
Stretch Goals - Not Finished 64

That means we got 91% of the core board items done before time ran out. The majority of those are small things that if we had like 3 more days we could knock out. Amazing! Well, it is amazing until you realize that this game jam became an all consuming void that stole almost all of the time we weren't working our full time jobs. The occasional day off here and there but right back at it as soon as possible.

That is where I think the scope was too big and why it is in this section. Going into this, I think we thought that we would be able to work on it a couple of days a week and still get through the scope. This was a fantasy, plain and simple. When I put on my project estimating cap, I was thinking in terms like I would at work...you know, where you are working on this for 8 hours a day with a team of people who know what they're doing, not three amateur game devs trying to build it in their off-time. It should have been half the size that it was, though it sounded small when we were talking about it!

Several other choices made the tasks even harder, which contributed to the amount of time each task took. We wanted to do a first-person 3D game. None of us are 2D artists and I really wanted to work in 3D to gain more experience for the types of games I want to make. However, 3D is a lot more involved up front than 2D. You've got to model things, then unwrap them, then texture then, then animate them. A lot of work with workflows that we are not familiar with!

We also wanted first-person because, being a horror game, we wanted the player to feel more immersed and in danger when they are playing. This brings its own challenges though. Every model/texture/particle system needs to have higher fidelity (assuming you want to avoid the low poly/Synty-style aesthetic). This meant spending more time to make things look good where you wouldn't have had to spend that time if it were a top down game where the models are farther away from the camera.

The Grind™ definitely lead to feelings of burnout throughout the project. The light at the end of the tunnel was the only thing keeping me going towards the end. One last push! It was brutal though, and not something that I'd like to repeat any time soon. In some ways, doing a week game jam would have been preferrable. Even if it was way more chaos/stress, at least you only have to sustain it for a week. 40 days, plus the pre-planning, is a long time to be hyper-focused on one project.

I think focusing on the "finding the fun" first would have helped with this because we could have pushed it out the door if needed. We did try to structure everything to where we were building the most important stuff first, in a way that we could push it out but we didn't account for the follow up work once you got a new big feature in. Take the glimmerstalker for instance, the main antagonist of the game, I got the system in to control it and have it affect the crew but there was so much follow up work that was needed to make it actually decent to play with. Sure, the code was there but what about the sounds, the visuals? These things took a lot longer than expected and made it so we couldn't really push out the game because the overall feature was half finished.

Web Build Woes

Going into the game jam, I think we all had envisioned "making a game and submitting it on Itch". None of us actually knew what that would entail. I've never really used Itch for games before, just for purchasing some assets, so I had assumed that it would be like Steam. Obviously, that isn't how it works. We had originally intended to do an .exe that people could download and play. After seeing some of the other submissions, we felt that a web build would be better instead. We thought that it would make it more likely for people to play it, and therefore rate it. It was more of a hassle to download a game to play it, we saw that in our own behavior towards the other game submissions.

The problem is, WebGL (that the Unity web builds use) has some restrictions on top of just differences in expectations of web games. I had to completely redo the particle systems because the Unity VFX Graph runs on the GPU and WebGL doesn't support that. We also ran into major problems with build sizes (though we should have been more conscientious of that anyway) due to the (sensible) limitations that Itch puts on web builds. Crazy how much space textures can take up. If we had been targeting web builds the whole time, we would have been able to catch these things way earlier and hopefully could have avoided redoing a bunch of work. Live and learn!

Speaking of living and learning. Another practice that we should have implemented earlier was to make a web build on our branches before completing the Pull Requests and verified that everything is still working as expected. There were some big discrepancies between running it in the editor vs doing a web build and running it. Like the aforementioned particle systems, or the major hiccup we had on release day where the web build was completely broken but it worked flawlessly running in Unity. We would have been able to avoid the release day fiasco altogether and so much work would not have had to have been done twice.

Merge Conflicts

As none of us have ever worked on the same game before, there were growing pains when it came to merging in changes from the other team members. We generally tried to avoid working in the same areas at the same time, which helped a lot, but the one area we kept running into conflicts was the Main Game scene. Most of the features touch that scene in some way and we were constantly having to manage merge conflicts on it. While the scene files are stored as text (which helped) it was very easy to accidentally mess up the merge and have things go missing. And you may not even know they are missing until later. Merging code conflicts was easy and straight-forward but the scene and asset files were troublesome.

I looked around online for tips to avoid merge conflicts and a couple people mentioned creating more prefabs. The idea being that when you make changes to it, those changes are stored in the prefab files instead of the main scene file. As long as you aren't working in the same prefab, life is good because the reference in the scene doesn't change, so no conflict there. I'd like to give that a shot next time.

The two biggest causes of conflicts were the menus/UI and the characters (crew, glimmerstalker, player, etc). We didn't have any of the menus prefabed so anytime we made changes on them there was a high probability that something would go wrong. If we had been using prefabs, there would have been fewer changes being made in the actual Main Game scene and a lot less to fix. For the characters though, they were all prefabs already but because they had so much functionality in them, there wasn't much we could do. I do think we could have been better about "applying" the changes to the character prefabs though, so the changes actually lived in the prefab file, instead of the Main Game scene.

We're still figuring that workflow out.

Polishing Some Areas

While I think the game overall looks really good (way better than I could have hoped for) there are definitely areas that could be polished. The main areas that I see could be improved are: tuning, audio levels, UI, settings.

  • Tuning
    • I think we could have spent more time (if we had it!) tuning the game. Things like the spell costs, the scoring at the end, energy rates, snow pile spawn positions, number of tiles, etc could all be tweaked to give a tighter game feel. One good example is the crew dialog. They are quite chatty and the text sometimes overruns each other on screen. There probably could have been more we could have done to make that nicer to read
  • Audio Levels
    • I think Andrew did a great job on doing the audio. However, one thing I noticed is that there is some inconsistencies in the volume levels between different tracks and different sound effects. You might go from a quiet song, so you turn up your volume and then the Attack song plays and it is very loud, comparatively.
      • I am also guilty of this on some of the sound effects I added in. The bird flutter/flee sound effect especially. It is way quieter than the others, though I had tried to fix it
    • It also seems like the audio overall is a lot quieter compared to other games/applications. I had to turn up my volume quite a bit but then a notification would come in and be very loud.
    • I am not really sure what the process is to normalize all of the volumes of everything is. I am not very skilled at audio stuff and didn't have time to research it during the jam.
      • I also found out that I don't particularly care for doing audio work, for whatever reason, so I'm happy to leave that to Andrew!
  • The UI
    • Again, overall I really like the UI and think we did a good job. There are just inconsistencies within it that I think could have been avoided if we had done some design work as a team before creating everything
    • For instance, the Main Menu is light text on dark background elements but the pause menu is dark text on a light background. These probably should have been the same pattern across all of the elements.
    • The tutorial screens also suffered from this, though they were made up as the team directed. The actual screens look really awesome in isolation but they don't quite fit the vibe of the rest of the game. I think the icy background fits but the buttons are my main points of contention. Looking back, we should have used the existing buttons from the other menus instead of the arrows. The arrows were a suggestion I had but I think it was the wrong call.
    • We did try to combat this part way through by setting up a Figma project to figure out how to make them more cohesive but we didn't have the time to actually rework anything
  • Settings, or lack there of
    • I think more settings needed to be added. At the bare minimum, a brightness setting should have been added. The game is dark, and is meant to be dark, but darkness is hard to account for on different screens and different eyes. I think it would have made the game more accessible to a wider range of players.
      • If you brighten it too much you lose the sense of being out in the middle of nowhere with your dark vision blown out by the lantern light. But too dark and people can't play it. A very delicate balance that is highly player dependent

The Wraiths of Dumra — A Reflection

by Andrew T.

Intro

Hi there. I'm Andrew. I haven't introduced myself before, and Jake has been awesome enough to set up this blog to allow us to post updates. Towards the end of the Jam, I've had a lot of self-reflection about Wraiths, and game development in general.

A bit about myself beforehand: I've made a couple minor games in the past (they do not really count as full games—no lead or project management, though one was published to the iOS store). I've also dabbled in c# here and there over the years but mostly work in VBA at my "day job." So, to start using Unity and working on complex c# systems was a learning experience to say the least.

It Has Begun

We started off in the concept phase mostly knowing what we wanted to do, and all of us were excited about having the setting be in a fantasy world we've been working on for decades.

We paid careful attention to scope creep, knowing that 40 days would fly by faster than we expected. We wanted to have a tutorial intro, random events, and multiple different tiles. Early on, we realized that it was still outside our scope.

Even as we tried to slim it down, as the weeks went by, we realized we still dreamed too big. We had to knock a few things off the board to allow us time to finish the game from A to Z. In hindsight, trimming earlier and harder might have given us more breathing room.

Team of Three

Collaborating with each other has been our dream for years. We each have our own disciplines, strengths, and weaknesses.

I feel like we naturally fell into a rhythm that worked really well for us. Terra knocked it out of the park with the scene design and the Gaquk (the goat). Jake has been wonderful as a project manager, senior dev, and approval man.

He was very patient with me while I worked through a lot of coding conventions (I still have a lot to learn!). At one time, with 20+ comments on a PR, I said "release me."

Overall, I’m pleased with the way we were able to complete our goal.

Scope Versus Reality

There were so many times I really, really wanted to “finish” a few textures and songs. I kept thinking “It’s not good enough!”

That, in turn, was the hardest part of it all—deciding what good enough meant for a game jam, and when to call it done.

Towards the end, as our board dwindled down, I noticed I wanted to just get it over with. It came to that point where I said, “I'm good. This element is good enough.”

Forty days was a great timeline to work on everything (even while juggling my full-time job), but it definitely had an all-consuming effect. A lot of things in real life were put on hold because of this. At that point, we’d already cut a lot of items, and the dreaded deadline was fast approaching.

For instance, we had some issues with our latest build on submission day, and the blood decals had to get removed. I had to accept that certain things take priority when you’re racing the clock to finish.

The Software Gauntlet

Most of my day-to-day work lives in VBA, inside Excel spreadsheets. Stepping into a full IDE and starting fresh was disorienting at first. It felt like I've been working in a cubicle and suddenly got thrusted into a spaceship.

Let alone coming from Unreal, Unity’s workflow felt like learning to speak the same language with an entirely new accent.

During this jam, I juggled a lot of different programs. I know Photoshop decently enough to do what I want, but I was also able to play with 3D Coat and Substance Painter. That came with it's own challenges with an entirely new set of hotkeys to learn. I had to stop myself from watching 4 hour long youtube videos so I could finish my board item.

Learning the hotkeys between just those three was challenging enough; adding Blender, 3ds Max, Cakewalk Sonar, and Git on top made for some serious mental gymnastics.

I ended up creating a document to house useful hotkeys, shortcuts, and coding conventions. That helped a lot. I still had plenty of muscle-memory keystrokes that almost sent me into a stroke.

There were moments I enabled some mysterious feature and had no idea how to turn it off.

Despite the chaos, it reminded me how powerful it is to know a bit of everything, and how humbling it is to realize how much there always is to learn.

Learning Curves

This project really made a jack of all trades out of me. From sound design to modeling, animating, UX/UI design, and everything else, it was a challenge trying to do them all.

It was fun and interesting, but I can see why solo devs take a long, long while to create anything meaningful. I think the thing I struggled with most were Unity-specific issues like, “Where is this located?” or “Why is it doing this?”

Learning best practices with Unity was tough at first too, but toward the end, I really got the hang of it.

Ink-ing Around

Ink. Inky. Inkle.

I’d heard about it a few times, seeing it in games like Dear Esther. I always liked the storytelling aspect and how "easy" it seemed to be able to incorporate stories with branches.

While this project was small, I thought Ink would be a perfect fit for some of the dialogue. In fact, it turned out so well I used it for all the different endings, stats, and NPC dialogue.

This was a bit of a learning curve too, because I was just getting started with c#, and switching over to Ink was extremely different.

I really love narrative games, and as mentioned, the game I'm working on happens to be like that too. I appreciate this jam as it gave me an excuse to put Ink to use and see how it blends into game engines and the game itself.

The “It Clicked” Moment

The first couple of weeks for us went well. We were excited, churning out code and items fantastically. A lot of grayboxing was involved.

For myself, I had my own scene where I put galaxy-textured cubes in which acted as snow piles. From simple planes and boxes, Terra arrived with the terrain. And wow. With that, she did the lighting, snow, and overall feel of the game.

For me, that moment loading into the stage and just being there while the snow came down around the player really made me say, “Yep, this is our game.” I was so proud of all of us, and we still had a long way to go.

The next moment was the audio. I created all the songs and sound effects (minus an edit of the healing spell) and was able to throw them all together. I can't take credit for the Glimmerstalker audio, Jake did that!

Getting those in there really made the game feel alive.

I believe the overall consensus is that the Stalking Theme is our favorite.

Emotional Lows

Coming from a very inexperienced dev background and working with two people who have years of experience humbled me a bit. I’m not used to being in that position and haven’t been in many years.

While I took everything in stride, there were times where I just couldn’t get it, or I felt extremely incompetent. It made me frustrated that a lot of the work I did had to be redone. Not because it was bad, but because how we implemented it changed.

So, it wasn’t like I was doing anything wrong, but it still felt bad. Jake and Terra were great and able to reassure me I was doing well.

Then came submission day.

We had everything hooked up, wired, dialed, and tuned. As we were getting the latest build up to the web, it turned out it was broken!

Jake spent a good amount of time trying to figure it out, and I couldn’t either. With about eight hours left before submissions were due, we decided to call it and pull the last best branch we had that we knew worked.

So, in crunch time, I had to redo everything I’d done in the past week—as did Jake. That definitely put a damper on the spirits.

And as of right now, our web build still isn’t complete how we had it before. I am currently working on it, but as I’ve often said…

Good enough.

In the end, I realized that being part of a dedicated team means trusting the process, and that even setbacks can lead to better versions of your work.

Reflection and the Next Horizon

While we had to restart a bit, it still felt surreal to see it working and public. It felt raw, and I felt a great sense of pride in it.

I looked at it and said, “I built that.” Not the whole thing, but collectively, and that was emotional for me. It’s been a long 40 days, let alone having work and life in the middle of it all too.

Having finished everything felt really nice.

I still want to make games. I still want to explore multiple pipelines and tools, to continue my learning. Naturally, I do feel some burnout. I’d like to be able to relax, recover, and take a breather before continuing my own journey.

I am pleased with the team we had and would love to participate in another Game Jam…though perhaps next year.

A lot of this has been a learning experience, and now that I have one game under my belt—officially—it won’t take me as long to understand the core concepts behind all these different toolkits.

And hey, I have my shortcut sheet now too!

So, after all that, in short: I enjoyed myself. I love my friends. Nothing catastrophic happened (until the end), and we still came out on top. We finished a game from start to finish, and I couldn’t be prouder. Plygith Dune has been a dream of ours. A world we’ve been shaping on and off for years and we finally brought a piece of it to life.

That accomplishment alone feels rewarding enough.

Game development is hard, messy, and deeply rewarding, but seeing something you’ve only ever imagined come to life makes it all worth it.

Every snowflake we placed, every sound we mixed, every bug we chased. It all added up to something real. And that, for a first full game, feels like magic.