Go! Save the Queen! Postmortem

When the lead programmer and I started work on Go! Save the Queen! It was a very different game. Originally it was a game where you controlled a queen ant with a group of ants around you, enemies would spawn in from all around and it was your job to send your ants out and kill them before they got to the queen and did damage, basically a mix of Pikmin and a bullet hell.

Very quickly we found this system to not work the best. Players could not handle controlling the ant hoard with the mouse, and the queen with WASD at the same time, the required management was too much. Funny enough I created a prototype a few weeks earlier that had the same issue, it was an FPS demo with areas that could affect the gravity of the bullets and it required too much from the player.

Instead of scrapping the gravity mechanic, I changed the game to be a puzzle game demo about bouncing a ball and not allowing it to hit any walls, you would do this by changing the gravity on your “paddle,” and whenever you hit the ball it would go in the direction you had set. Control over the ball’s spawn was completely removed. This play tested well, and people loved it, finding it highly addictive. While I would eventually shelve the concept to start work on this project, a lot of what I learned from that demo came into designing this game.

Back to the initial concept, to fix it I just did what I did for gravity manipulation, made it simpler to control while keeping the same concept. This is when the Queen started to move on its own, changing from a queen ant to other things, and the escorting aspect of our game was created, as a way to remove that requirement from the player and allow them to focus on the hoard of ants. We also decided during this time that instead of throwing ants out, you would control the hoard of ants with WASD, and what you could do with them would be based on the shape of the hoard. For example, you could get your ants in a sword shape, and they would swing around like a sword. During this time I created a document with 50 ideas for the game, I have the document linked for your pleasure, but one last thing I would like to note, is that all the enemies in this document, made it into the full game; Some are even the exact same design-wise with no changes. Even the armor and shield mechanics made it into Go! Save the Queen! but were never used due to a lack of art assets.

However, despite the growth of this concept, it wasn’t meant to be. Our program had 2 bullet hells in production, and the higher-ups decided that, Go! Save the Queen! would have to change, saying that the gameplay wasn’t unique enough or didn’t make much sense. While we had a hard time with that feedback (it really felt like they just didn’t want 2 bullet hells made in the same program) we went back to the drawing board and eventually decided that instead of the shape of the ants determining what they would do, instead it would be down to the individual ant and you would draw them onto the field instead of controlling a hoard. This got through the higher-ups and during a practice pitch it was received extremely well.

Eventually, after many months, it was time to truly pitch it and see if development would be allowed to continue. Below is that pitch which you can watch if you want.

The pitch went really well! Actually, better than well, it went amazingly. The industry professionals we pitched to really liked it and had many positive things to say with a few suggestions. After this, we took the suggestions and decided to pivot away from a bullet hell to a tower defense game, even if it still had heavy bullet hell inspirations. After this point, the main design of Go! Save the Queen! was decided and the concept was created. While development for this game had many flaws, the first chunk was not one of them, it went really well. It had some standard issues like working out the differences between the lead programmer and I, and we both weren’t happy where the game was being pushed at points, but it all worked out really well and I don’t think anything that happened in this phase harmed the development of the game

When designing this game, there were 4 phases, the first few months I just talked about, then there were another 4 months where it was me, the lead programmer, and the lead artist, then after that there were around 8 months where up to 10 people worked on the game, with the first half being phase 3, working on content creation while phase 4 was preparing the game for launch.

Now onto phase 2, this time was detected to figure out what made a good level/gameplay loop and designing all the systems. Starting with the system design, I spent about 2 months total designing all the enemies, ants, queens, obstacles, environments, etc for the game. At the time, this was great, we had everything mapped out quickly, in hindsight though, what a waste of time. Don’t get me wrong, having things designed out ahead of time is good… If you use it. I created way too many ideas that just never had the chance to see the light of day, way too overscoped. Overall I made 87 design briefs for this game, however, we only ended up using 56 in the end, which means over 1/3 of the design briefs (31) were a waste of time, time i could have used to start on level design earlier.

Speaking of level design, the first goal was to figure out, what made a good level and what the gameplay loop would be. I hoped to have 3 levels done by the end of this phase. This ended up taking way longer than we expected and I only had one done. While at the time this wasn’t a big issue at the time, with how development went later on, this stings looking back. Skipping ahead a bit, the number of levels we made was one of the biggest disappointments in my opinion. Even ignoring the horrible over-scope the original pitch of 35 was (dear god), we only made 12 when we really should have made more, in my opinion around 18. As the level designer, too many things pulled me away from hitting this goal and it pains me to look back.

Looking at the rest of the team, the biggest mistake we made early on was with the art style. Our artist did not properly set up an art bible so when we commissioned an artist, the assets did not end up looking right at all and all had to be scrapped. This was the start of the single biggest disappointment of this game, the art. Our artists had life issues that took them away from the game and any attempt to get outside help through commissions did not work. Without money, we had to really on other means to get art assets and they did not work. This hurt the game so much, but I will go into more detail on that later

So yeah, that was a sad phase. The misses of a few amateurs really came into force during this period. While I might have been a bit of a downer this phase, I’m still so happy with how the game turned out, and that is all thanks to the work done in phase 3.

Once we had all finished our break over the summer and got the skeleton of the game set up, it was time to get new team members. 4 programmers permanently joined the team (1 left after a few months), we commissioned 2 people to make sound effects, and we got a composer to make music.

Looking at level design again, things at first looked good. In about a month, I had made 3 more levels on top of the original from the phase before. Afterward, however, the speed came to a crawl. We as a team decided to make the ducklings the next queen, seems easy enough, but that was a mistake. The work to get 3 queens working at once was a nightmare, it took so much time and bugfixing. This builds into the biggest flaw of this entire phase, doing big things last.

Certain things, such as how enemies would move, hadn’t been decided yet. Instead of working on these systems first, we made all the enemies and then updated how they moved. This meant we would be constantly going back to old things and fixing them and not just the enemy, because new movement systems required updates to level design as well, meaning all levels would also need constant updates.b Now all this sounds bad, and it is, but thankfully programming would be the biggest strength of Go! Save the Queen! Was it the most effective way to do things? No, but with half of the team having some knowledge of programming, we made it work out well and by the end of phase 3, almost everything had been made to some extent.

Without the programming skills of this team, Go! Save the Queen! would have been impossible to make. Many things had to be meticulously optimized to even get the game to run well enough to play, for example, there are actually 2 enemy movement systems in the game. Most enemies use a flowfield to move to the queen, while any enemy that has to move to something else has to use a navmesh agent. The reason for this is that if too many enemies are using the navmesh, it breaks, and with how many we spawn in, it causes a lot of issues. At the same time though, not all enemies can use a flow field (which is much more optimized than a navmesh) due to needing to go anywhere but the queen. So the solution was to use both, with what the enemy uses being based on what they need to do. While it is complex it was the only way to get the game to run well at all.

Moving away from programming, sound work also started during this phase. Our audio director and his support spent a lot of this phase simply figuring out what sounded good and which techniques to use, while the actual implementation of the sounds came in the next phase. Meanwhile, our composer did A LOT of work this semester. Early on it was decided to make the music ramp up as the intensity of the level went up, either getting closer to the end or as the queen’s health dropped. He also decided that he wanted to make a unique version of each track for each level, and he did! Over the course of 4 months, he made 3 tracks with 5 variations each for 15 levels. While this is amazing work, looking back it was another waste. We eventually only ended up using 2 of these tracks due to level cuts and our audio director struggling to get them to work properly.

As for art, this is when the cracks really started to show. Our artist started having horrendous luck, hand injury, illnesses, etc. Because of this things ended up being extremely behind. As I said earlier, we tried to get commissioners, but without money that didn’t work out. At least with this semester we really nailed how to set up the art in the game, what size everything should be, what should be tilemaps vs single sprites, etc.

The final phase of development was all about polishing the game up or playing catch up in the case of art. However, before looking back on everything we did, we need to look at a major point in this phase that shook up the game’s development, cuts.

As I said before, my goal was to have 18 levels for Go! Save the Queen! but as the release came ever closer, we realized we weren’t going to hit that target. Too many things had stopped me from making levels and by the time phase 4 started, I only had 9 final levels complete. Because of this, it was decided to cut the final 3rd of the game to give art, sound, and level design, the chance to catch up to programmers. As I kind of hinted before, this change made a lot of previous decisions worse, such as time spent designing the systems for the final 3rd, or the extra music that would go unused. Despite this though, the team truly pulled through in all aspects and made this work.

Starting with programming, they were already ahead, so having less work meant they finished way earlier than expect, so they spent their remaining time polishing the game. Stuff like AI saw further optimization, ranges were made to match the game’s art style better, now being ellipses instead of perfect circles, visual effects, controller support, and more.

Another thing I’ve said before is that art really struggled during this project, and that was still true this semester. Our artist still had life get in the way, such as getting pregnant. Unlike phase 3 though, they pulled through. While not as many assets were made as I would have hoped, we got what we needed to make the levels work and this is on top of another issue that caused delays, the redo of assets. Our higher-ups weren’t happy with the art style, saying it wasn’t close enough to the original goal, because of this, all (yes all) art assets had to go through 1 or 2 revisions, limiting how much we could do even further. Again then, despite the issues, the art made it.

Finally, our entire sound team, the audio director, the sound designer, and the composer struggled to get things done this semester due to having busy lives or personal issues. But just like our artist, they pulled through in the end. Our composer made 2 final tracks that we needed, while the rest of our audio team got the sound in just in time. The story of this final phase was about everyone coming together to finish this game, despite the struggles, and as the producer for this game, I couldn’t be more proud of everyone on the team and all the love and sweat they poured into this game when it needed it most.

Go! Save the Queen! had many issues through development, due to the team being new at making games. Despite these issues, the team came together and made a great game. Was it perfect? No. Was it exactly the way we wanted? No. But I still am so proud of what the team did. To summarize the ups a downs of this project:

Pros:

• The game had a strong foundation – Despite issues during development, the core of the game was strong thanks to the work put in during phase 0. One thing we focused on during that phase was making sure our game could easily fit our changing vision and be scaled up or down according to our needs, and that came in so handy as issue struck, as it made sure no issue could truly kill the game
• An amazing programming team – Every programmer on this team had something to bring to the table, progression programming, AI programming, Visual effects, etc. Because of this, Go! Save the Queen! was able to come to life. Without these members, the game would have been laggy, unpolished, and not very fun to play due to the technical issues that would not have been solved without their hard work.
• A team that pulled through – While programming was our golden child, other parts of the game struggled. Despite these issues though, team members pulled it together in the end and made everything work. I can go on and on about how I wish this was made our I got the chance to do that, but I can’t deny the results are great and even exceeded my expectations at points.

Cons:

• Art – Our art did not work out the best. While I’m happy where it ended up even with the difficulties, if I had the chance to do this project again, I would have just gone for a pixel art style instead. It is faster, easier to make, would not have had to go through multiple revisions, and we probably would have been able to get outside help of some kind even with the lack of funding.
• Bad prioritization – As I said before in my recap, we did not prioritize everything properly, and this caused issues. While we worked through them, I can’t deny that the game could have been even better if we had prioritized properly (even with the cuts) or not wasted time on things that weren’t going to happen. We could have had more features and more levels even with no extra art or sound.