Over Then Under: After Action Review

During the month of Spooktober, I set out to participate in 3 overlapping game jams that each had different end dates. The plan was to create an open world horror in VR. I had 4 weeks to do it and I had to do it alone. It was an interesting journey, mostly a mental one and it resulted in my growing more competent and confident in my solo development abilities. In this review, I hope to share some insights into my challenges, successes and shortcomings so that others might learn from my experience.

Okay, so now lets address the elephant in the room quickly. Why the heck am I calling this an after action review instead of a postmortem? 

The first reason is that a postmortem implies the subject of discussion is deceased- or at the least is a finished product. But that's not always the case with some games and really, we shouldn't wait until the end to review our process and divert course when necessary. These reflections can be part of the ongoing development journey. If you're a software developer, or familiar with Agile development methodologies as it relates to a software development life cycle (SDLC), you'll be familiar with "sprints" and "sprint reviews" anyways.

The second reason is that it's actually a structured review process that I first learned during my time in the US Army. It's also used widely throughout enterprises, corporations and other entities that might just give it a reskin, but follow a similar formula. So what's that structure and how the heck does it relate to my game?

#1. What was the plan/expectation?    #2. What actually happened?    #3. What went well?    #4. What can be improved and how?

Without further delay, here's how it applies my time solo developing Over Then Under:

The Infallible Plan

The plan was to create an open world, psychological horror in VR using Unreal Engine 5.01. Yeah, I know. But these things always seem like a good idea when you're just smart enough to talk yourself into something stupid. So I cooked up this idea about a player sailing through dark a beautiful clouds at night, on an airship they could navigate themselves around an open world. The airship would be separated from the open world by a thick layer of clouds. The player would have no sense of direction above the clouds and would need to lower themselves to the ground using a rope. The same rope could be used to climb back up to the airship from the ground. The airship would act as a safe haven from the open world horror of darkness and shadows below- and the rope would be their lifeline, something that could be easily lost or taken away in order to create anxiety within the player. Traversing the ground would be the meat of the game, revolving around exploration and narrative discoveries about what had happened to the land and why. I started writing a backstory to explain who the protagonist was and why they had to press further into darkness instead of just flying away on their airship. The ground would be haunted by creatures that stalked you only when you weren't looking at them. They would be designed to create a fear of turning your back to them and also a paranoia to constantly check that none are behind you. The player would have to avoid these creatures to "find some stuff" that would essentially gatekeep the ending of the game and give them reasons to explore. There was to be a health system, an inventory system, climbing, melee and projectile weapons... I think you can see what's happening here. Feature creep. But that was my plan. And off to execute that plan I went...

The [3, 2, 1, lets] Jam

The first week of the jam went great. I think I was even ahead of schedule by the end of the week. I setup a new character class that needed player locomotion , gripping, and room scale. I added the overworld and started finding assets paid and free that would support my development.

For the art, I found some assets on the Unreal Engine Marketplace, and even one that I was willing to drop $15 for, the airship. The volumetric clouds were free on the marketplace as well. I used Mixamo for the creature and its one animation. I only needed one animation since the creature didn't move when you looked at it, so the player was never intended to see a movement animation. Apparently this is pretty common, but it's an understandable workaround to not having an animator (or maybe my opinion is biased now, haha). The monster would twitch rapidly with its head tilted as a callback to Silent Hill and OG psychological horror film, Jacob's Ladder, which used the effect for its uncanniness and slightly-less-human qualities. A simple blueprint controlled the monsters movement, which really freaked me out to playtest. I found it quite stressful to have strange creatures suddenly appear behind me.

The audio was easy and fun to make. I used Audacity to record and edit my own voice acting. I distorted and reversed my voice for the monster, using different speeds and pitches to make my voice less recognizable. I had enough fun doing it that I think I'll continue to do my own audio. I setup some voice clips to some in-game triggers, monsters and level blueprints. That was it. E-Z P-Z.

The open world idea was a f***ing trainwreck, though. I severely underestimated the amount of work that would go into optimizing an open world environment in VR. I knew that keeping the framerate high was a challenge for VR development, but this project really drove it home that I needed to stay focused on framerate from the beginning and with every single feature I add to the build. When one thing starts to hurt the FPS, I need to immediately work to resolve it before adding more to the build that will detract from the FPS even further. Going backwards and optimizing after everything is already added is a huge pain and unnecessarily reduces quality as I sloppily just hack away at trying to get the FPS back up. Because of this underestimation , I had to redesign the whole game loop on the fly in order to make the deadline with a reasonably completed game.

If you've played the final game, you can see how much was changed from the original vision to what it is today. But I'm happy with what exist today. What I imagined would take a lot longer or a team to produce. I have neither the team, nor the desire to get locked into long development cycles as an indie. I think it's better to fail fast and then take notes.

It doesn't mean the realization that I failed my open world design wasn't hurtful, though. I spent days distressing, trying to figure out how to shift gears and what kind of game I was really trying to make. I was trying to make a spooky Morrowind when in reality I should have been making a VR Slenderman.  Most of the concepts that survived into the final game were born during this crisis and very real limitations that were being set before me. So I countered scope-creep by embracing those limits and establishing a minimum level of features I needed to make a solid game loop happen in the next 24 hours. That was basically all the time I had left, anyways.  I changed nearly everything about the original design, keeping only what was working and already contributing positively to the build.

I was pressed until the last few hours when I attempted to package the game... and of course ran into packaging issues. My deadline should have been a day or two sooner to account for this- but I was confident I could fix it quickly if I had an issue. It took about 3 hours to resolve all the issues and I only made the deadline by submitting a place holder zip at first, then swapping it out with the legitimate build a few hours later. 

Whew.

What Went Well

I recognized and addressed scope creep during the game jam instead of after the game jam.
I rescoped the game to an appropriate size.
I developed my own audio assets this time and grew in confidence with regards to making more of my own.
I made a horror game, so I've officially got that notch on the belt.
I included narrative elements in one of my games for the first time and used voice acting to help direct the player's objectives and expectations.
The game actually scared me when I played it, so I think it does what it was designed to do- create fear and paranoia.
Confidence as a solo developer went up. Yes, I can actually make something interesting without a ton of support.
Survived another development cycle, producing something that can be expanded upon after the jam if desired.
Gained additional mental fortitude through solo development. It's stressful and lonely managing all these problems and expectations alone- so making it out the other side I consider a form of mental strength and conditioning. 

What Can Be Improved? How?

I didn't really market the game or its development -> I could make posts more frequently showing features as they are added and live-stream development to Twitch. I could post to Reddit and in Itch.io communities to get more feedback.

Scope Creep happened. -> I could have more realistic limitations on the game designs I come up with. Starting with the minimum features required to hit the core game mechanics. Elementary design practices, but if I'm going to design my own games, I need to employ these thought exercises and self-limitations more often. I can also do more research on features before I commit to implementing them and more quickly identify when the estimated work is too large and when to shift-gears, exploring a different solution.

I worked alone. -> I kind of wanted to work alone, so I ignored others looking to team up. Next time I should seek to recruit developers I can build a working long-term rapport with.

The game was limited to PC VR users. -> Next time we're going to include non-VR users to expand gameplay to all PC players. Additional support for Quest2 if bandwidth allows (tougher hardware restrictions on Q2 mean more design and time considerations to manage).