Anomaly Postmortem

Blog Header Image

Anomaly is a prop hunt/hidden object game developed for the 2018 Epic MegaJam. Visit the game jams page for more details and gameplay videos.

Purpose

I’m writing this postmortem as a personal reflection on what went right, what went wrong, and what could be improved about the development of Anomaly. I’ll be inviting team members to add to this post, but it’s primarily my own thoughts and shouldn’t be taken any other way. As the saying goes: hindsight is 20/20, so let’s put on our glasses and take a look back!

What Went Right

Finding a Team

In the summer I entered a game jam as a solo dev. The resulting game was very lopsided making heavy use of premade models and boring level design. I spent a majority of my time trying to do tasks I was not skilled at. At the last minute for this jam I decided to find a team even if it meant giving up some creative control. Luckily I was able to find a team started by another developer that I was familiar with from the summer game jam. The entire team ended up being pretty well rounded:

Member Area of Expertise
PartlyAtomic (Landon Fowles) Programming
PenToe (Piotr Tylus) Level Design
GoldShay (Shay Malol) UI
ImagineGames (Reinaldo Vieira) Programming
TheMooseman (Skyler Moosman) Sound

Each member was skilled in their own area and we were able to efficiently relay requests for assets between each other while knocking out our own tasks. The only major improvement I would make is adding a member dedicated to 3d modelling tasks.

The minimum team I would consider for future jams consists of:

  • A designer
  • A programmer to support the designer

Organization

Shortly after the theme was announced we gathered on the team Discord to start bouncing ideas. Before the night was over we had a game design document (GDD) up on Google docs. By the first full day of the jam a Trello board was created. Each of these were essential for organization! Once the GDD was in place, we were able to achieve consensus on a basic idea very early in the jam. At that point we could easily iterate on the idea in a document the entire team could refer to. The Trello board helped us break down the GDD into user stories and tasks. Without the board we would have been constantly stepping on each other’s toes … it didn’t stop us completely though! Now looking back, you could ask why create a Discord server and not just a group chat? With our own server we were able to create a channel for each of our Trello user stories limiting the overall spam in #general.

To repeat, the essentials I will take with me for future jams are:

  • Discord server - Broken down into user story channels
  • Google docs - A shared GDD for team reference
  • Trello board - List of user stories and tasks to complete

Thorough Quality Testing

One issue I see with a lot of jam entries is they leave some parts unfinished. While it’s fine to not finish, the game looks 110% if every piece included feels like a finished component. This even means dropping features that are visibly buggy and incomplete. However, some features can be buggy and incomplete AND stay in the game as long as they feel that they were designed that way. My example for this is the upside down sign UV map from This Side Up.

Yes, it is a bug. Yes, it is very visible. But, it could be thought of as thematic!

For every feature implemented, I tried to polish it to 100% or find a way to remove it and replace with a simpler alternative. This process worked well up until the final day.

Testing recommendations:

  • Drop or replace features that feel unfinished.
  • Some bugs can be features, but only if they feel like features.

Finishing Early

Early on I was very insistent on having a whole day to polish and do QA on the game and getting it submitted the day before the jam ended. The QA day was meant for the team to playtest and fix any bugs as well as finish implementing incomplete features. This worked very well and gave the team soft deadlines for adding new features. We were able to submit over twelve hours before the jam ended.

Recommendations for setting a schedule:

  • QA day with no new features allowed.

Timezones

Usually timezones cause issues in teams as distributed as us (members from Poland, Israel, and the USA). However with the way work was distributed it strangely worked out. I would finish developing a feature, go to bed, and then while I was asleep or waking up Piotr would take over and start designing with that new feature in mind.

My future recommendations:

  • I don’t know. We got lucky.

Player Feedback

Piotr was the most proactive on getting player feedback and every little bit of it helped us guide development. With the laser focus we needed to finish a game in 7 days there was very little time for us to take a step back and think about how players will actually experience the game. Even after the jam it was useful to watch streamers play the game.

To get the most useful feedback, wait until you have a prototype with the rough edges sanded down. If it’s not polished, then the player will likely give you feedback that you already know. Yes… the menu is unfinished and some buttons don’t work and the dev and player both know that. But you don’t want the player too distracted by the menu buttons to mention that it’s too easy to skip the initial scanner pick up.

Recommendations:

  • Start getting feedback once you have a polished prototype.
  • Keep getting feedback post-jam.

Leaderboards

These were a cool feature implemented by Reinaldo using a free plugin. It took almost no time and the only downside is that the widget that ships with the plugin doesn’t scale with screen size very well. If the game has any kind of score or timing or way to compare two players then go ahead and add this plugin!

Recommendation:

  • Do it, but don’t forget to customize the leaderboard widget to match the rest of your menus.

What Went Wrong

Note: Nothing went completely wrong. These are just parts of development that could have gone better!

Save System

Overall I would estimate the save system took 2-3 developer days to implement between the whole team. For a 7 day jam this was a lot of time. Looking back, it’s also completely unnecessary for a game with a 20-30 minute scope. We could probably knock out a save system much quicker now, but I would only do it post-jam and only if I was going to continue development on the game. It introduced a lot of complications and several unfortunate bugs. For example, without any save files hitting Continue on the main menu will spawn the player outside the map. Attention also had to be paid to having doors and voice triggers keep their state between reloads.

Recommendations:

  • Just assume players will play the game in one sitting.

Settings Menu

It’s fine if your game is only tested and shipped with graphics quality set to Epic. I promise. But don’t add a settings menu without testing that the game works on all of the settings exposed. We found out post-jam that setting graphical quality to Medium or lower would result in refraction effects being disabled. This made several of the anomalies invisible!

Recommendations:

  • Test any settings that the user can tweak!
  • Or just don’t allow the user to tweak settings.

Using a Newly Released Engine Build

We used the newly released Unreal Engine 4.21 which unfortunately introduced several editor crashes related to Widget Components that we had to figure out how to work around. Nothing in our game required updating to 4.21.

Recommendation:

  • Stick with what you’ve tested.

Last Minute Fixes

On the last day of the jam we had a few outstanding bugs and features we wanted to get fixed. These changes introduced their own bugs and features and added stress as we tried to get new builds submitted before the deadline. Stick to Thorough Quality Testing and Finishing Early so you can have a stress free day of playing other jam entries!!

Recommendation:

The Team Has This to Say

Reinaldo:

When introducing a new task mid-project: Make sure everyone is on board with that idea and that they understand WHY you want to implement it. They can add their point of view to oppose/accept/or even change the idea for the better of the project. For example:

  • I added a save system mid-project without consulting the team, and that led to a lot of re-work and even more work from other team members.
  • Added a leaderboard system without explaining how names are added to the leaderboard, and that I wanted player names to be added. That let to some design inconsistency when we switched working on the Main Menu between multiple team members…

Piotr:

  • We lost some focus midway so we should motivate each other more. Check status of tasks, ask for help, and ask if anyone needs help or opinions.
  • Focus more on quality than quantity. The game probably should have been left at tutorial + two levels rather than add in a third boss level.
  • Focus on flawless first impression.

That’s All Folks

P.S. Be sure to check out some of the other amazing jam entries! I haven’t played all 200, but I can personally recommend the following: