Postmortem: Armourgeddon

My name is Ben Roye and I am the Producer on Armourgeddon, a steam-punk-esque, shoot many robots, third-person action game. In this game, the player assumes the role of Amanda Morris, a Welklandish special forces unit dropped behind Schwartzweltian enemy lines to rid the world of the evil robot regime. The player has access to ten different weapons, each with their own unique super-attack. The game also contains an Arena mode where the player can work their way through 20 waves of enemies before finally unlocking an endless "Armourgeddon" wave.

Project Summary

I came onto Armourgeddon at the beginning of the Vertical Slice sprint. It was immediately apparent that there were a few issues with the project. The team lacked vision and there seemed to be some team dynamics issues because of it. I sat down with all of the team members and asked what had happened. Many team members felt that the game was going in different directions. I decided to address the issues by calling a meeting with all team members. I asked the team what game they really wanted to make. Everyone agreed that the soul of the game was frenetic combat with many on-screen enemies. We decided to refocus the game to highlight the game's combat.

In the process of refocusing the game to highlight combat, we made a few large design changes to compliment the combat. We changed the game from a very linear game with platforming elements to an open-world game that was more-or-less flat. Since the player now the ability to go back and forth between areas, we could continually respawn enemies; this gave players a chance to continue playing the game as much as they wanted before continuing on to complete objectives. We created three districts for players to explore: industrial, residential, and government. Each district has a distinct personality; the industrial district contains factories that pollute the sky, the residential area is cleaner, beautified area, and the government area climbs from waterside docks up to the top of a hill overlooking the city.

The game had performance problems that persisted throughout the project. Performance issues were caused by many on-screen enemies, highly detailed art, and occlusion calls. Throughout development, we had at least one team member working solely on performance at any given time. However, we had chosen to do an open-world game and we needed to keep pursuing our game vision. Going in, we knew that performance was going to keep being an issue until the end of the project.   

What Went Right

1. Focus on Performance throughout Entire Project

After changing the level to an open-world map, we knew that we need to keep a close eye on performance when making any iterations to design, art, or code. Like I mentioned previously, we kept at least one developer on performance throughout the entire project. The final project performs at a level that we feel was a success internally.

2. Art Passing the Level / Art Optimizations

We began to have an artist focus solely on level design and art optimization in the Alpha sprint. The level's visuals improved with each day that the artist worked inside the level. He researched ways to increase performance in the UDK engine so that the art would both look great and not bog down the player's experience. Art optimizations included everything: simplifying geometry, exporting many meshes and reimporting them as singular meshes, and optimizing particles to a point where they looked representative of the first pass of particles but performed significantly better in-game. Towards the end of the RTM sprint, every artist and even some level designers were optimizing art to increase our game performance. 

3. Improving Lighting / Contrast of the Level

Throughout the project, we set up playtests and collected data from testers via an evolving questionnaire. One of the chief complaints among playtesters was that the level lacked contrast or that the lighting was poor. For most of the game's development, the level occurred during daytime hours. We had many streetlamps in the level that were casting light but not creating very noticeable shadows. We made the decision to change the level to a night level so that the lights being cast by streetlamps would create better contrast against the darkened level. In addition, night lighting let the level design team better guide the player by alternating between blue and orange light hues. People are intrinsically drawn to warmer orange hues and push away from colder blue hues. The level design team lit streetlamps and the factory in orange to create contrast from the blue skylight. This one change greatly improved the atmosphere of the level and we never received the poor lighting feedback from testers again. 

4. Changing the Upgrade System to a Super Attack System

There are ten different weapons in Armourgeddon. Some weapons are ranged, some are melee, and some are support-types such as proximity mines and turrets. During the Alpha Sprint, we implemented an upgrade system where players could unlock better versions of their weapons by purchasing them with collected currency. It gave players a sense of progression in our game and was very fun. However, we found that the mechanic added a RPGish element to our game that had previously not existed. The core of our game was dispatching many enemies quickly; our game was very arcadey in nature. Ultimately, we felt that adding an RPG element to our game went against the soul of the game's design. Therefore, we repurposed our upgrade system to a super attack system. As players kill more enemies, they collecting energy that filled the super meter. Upon filling a super meter, players could then use any super attack they wanted. We feel that the implementation of the super attack system was one of the highlights of the game's development. 

5. Adding an Arena Mode

Throughout the Alpha and Beta milestones, we toyed with the idea of adding an Arena mode to Armourgeddon. It was clear that battling in an endless arena with the game's combat system would be fun. We did not have the foresight early on to know if we would have time to implement it, however. Towards the end of the Beta sprint looking into RTM, one of the level designs freed up some time and began implementing the Arena mode. We agreed that if the mode was not as polished as the rest of the game, we would cut it. Fortunately, he finished the Arena mode in time and to our internal quality standards. The mode is very fun as a standalone experience and compliments the campaign nicely. It is addicting to try to beat your own kill count once reaching Wave 21, the endless wave called "Armourgeddon".

What Went Wrong

1. Refocusing the Game Gave Us Less Time to Build the Game to the Size We Wanted

We knew that if we refocused the game to move away from platforming and to focus on combat that we would be sacrificing completed work. The finished product contains a campaign that takes 30 minutes on average to complete and an Arena mode that could take from ten minutes to an hour depending on player skill level. At the conclusion of the project, however, the team is happy with the quality of the project and feels that the product is better than what it would have been without refocusing the game's vision.

2. Passionate Developers Fought Too Long for their Ideas

We all know that in a creative environment, passionate people tend to fight for the ideas that they think further their projects. In this case, some developers fought too long before finally giving in to what is best for the player experience. We lost some time in all departments due to developers fighting not to iterate on art, sound, level design, and functionality. Nevertheless, we got from point A to point B and have a product that we all are proud to say is fun and high quality.

3. Open-world Game Design Required More Effort than Linear Design

Both a blessing and a curse, our decision to make the game open-world necessitated that the team work harder to research how to optimize UDK to better handle our art and enemy spawning systems. The good news is that we knew these were going to be issues going into our decision. We tried to keep developers focused on performance throughout the project and we believe that we succeeded in that.

4. Voice Acting Came in Late in Alpha

We started setting up and managing playtests in the Alpha sprint. One of the questions on our questionnaire asked testers to rate the game's story. Our voice acting was outsourced; we waited to put voice acting in until we had done many passes on the writing of the game's dialog. Since our voice acting did not come in until after many of the playtests had occurred, story was consistently the lowest rated item in our game. We realize that in high-budget, large-scope game development, paid voice acting goes in late in the project to ensure minimal reworks. However, we could have put in developer-created placeholder voice acting so that we could iterate before finally receiving the external voice acting. Eventually, our voice acting did come in and it was iterated upon until it was a high quality.

What the Team Learned

1. The Team Learned to Work Together to Create a Focused Experience for the Player

As I stated earlier, when I came onto the project, many developers did not have the same vision for the game. After the game became more focused, many developers began to buy-in to a unified game design. However, it was not until we started vigorously playtesting that developers began to design for the end user in mind. We need to remember to make games that we want to play. We also need to remember, though, that we need to make games that our target audience wants to play.

2. Autonomy is a Great Tool - Many Developers Began to Individually Research Avenues to Increase Performance

I have already mentioned performance a few times during this article. Since performance was such a persistent issue, there was no getting around the fact that we needed to optimize the game across the board. There was no single member of the team that knew more than anyone else about optimization for an open-world game design. We all began to go research optimization techniques online. We all began looking for similar games with similar issues to see how those teams solved them. We became very good at researching issues and attempting to implement solutions ourselves instead of waiting for one person to come up with the answers. Had we not done this, our game would not perform at the quality we have today.

3. Create Builds Regularly to Playtest Early and Often

We gained a plethora of valuable feedback from our playtesters. In order to get more playtest feedback and data, we made ourselves more disciplined in sticking to asset locks and build schedules. We improved our game's Heads-Up Display, conveyance of minor game information, and feel of combat strictly from our testers' feedback. We believe that responding to playtest data helped improve our game enormously. 

4. Iteration is Key to Great Quality

In-line with some of the previous examples, we felt that got more comfortable iterating based on player feedback. While we did not always iterate on something just to appease testers, we did sometimes deduce that there was an underlying problem in a certain aspect of the game based on tester feedback. We poured over every aspect of the game, from reducing tri-count in meshes, to solving small but hard-to-get bugs so that we could lift our game up to a quality that was internally successful.

Thanks for reading!

To try the game out for yourself, you can visit Armourgeddon's website.