Mark One Postmortem: An overview of my first game

Intro

In the past I created several different tech demos in order to get hands on experience with various aspects game development and gain an insight into the different systems that Unreal Engine had to offer. In August 2019, I decided that I wanted create a roguelike shooter game which would ultimately become Mark One.

Project overview

When I started my game development journey in 2015, I imagined that at some point in the future I would like to create my own game and publish it on Steam. Since I anticipated that I would be working on this project as a solo developer and considering that I cannot create any art by myself I ended up purchasing some asset packs from Unreal’s marketplace from time to time, whenever I found something that I liked (whether that was complete environments, particles, sounds or 2d art). By doing so, I ended up having a lot of asset packs in my library which would ultimately be included in my game.

At some point near the end of August 2019 I decided that I would start working on my game in September 2019 during my free time since I also had a day job. Originally, I was planning to release the game about 9 months after the start of development (since I was planning the game to be really short in duration).

The main purpose of the project was to gain experience from publishing a complete game that people can play on Steam. In order to identify what exactly I wanted to build, I created a list of all the assets that I had in my library and wrote down several different ideas about how to utilize them. Since the programming part was my strong suit, I created a game design based on the assets that I had in hand.

After this process was over, I ended up designing a roguelike shooter game (to achieve some kind of replayability), however this presented a lot of unanticipated problems which will be listed below.

What went wrong

Let’s start by listing the things that went wrong. After taking a few afternoons to program the basic movement and interaction functionality for the game, I decided the next step would be to create the world generation and the AI functionality.

Initially, for the world generation part, my plan was to create several different “mini – levels” that would connect with each other in order to create the world for the game. This idea has been used in several games (most recent game that comes to mind is Dead Cells) and seems to be working great.

While the implementation of the procedural generation was straight forward, what I didn’t expect was that it would take literally weeks (for me at least) in order to create 6 different “mini – levels” even with game ready assets. To build on top of that, the balancing of the AI was quite difficult since it required too many iterations based on the generated world. To sum up, it was crystal clear that this system wouldn’t work in my case since it would take too much time to make it “right”. Thus, I stepped back and re-designed the game completely by removing the roguelike element and building a story, with a start and finish.

Another thing that went wrong (which is similar to the previous point) was that even if I removed the roguelike element and the world generation it would still take too much time to build all levels by hand (because as it turns out I’m horrible at this), something that I didn’t anticipate in my original planning phase.

To build on things that went wrong, I also encountered several days that I was demotivated to continue working on the project, which resulted in a need to take several brakes during the development here and there.

The combination of these unexpected problems, plus having day job resulted in a huge delay of about 9 months, which was 100% of the original planned development time!! This would be completely unacceptable if this wasn’t a hobby project.

So, to sum up this section:

• The procedural world generation method I originally chose required too much work in the level design side
• Procedural world generation made balancing the game quite difficult
• My level building workflow was too slow
• Original scale was too large for a solo developed project
• Due to the game redesign, I spent time building tools and systems that didn’t make it to the final game (such as fog of war, mini level generator and a few other test systems)
• Random demotivation periods

What went right

When it comes to things that went right, I was able to produce clean and reusable code that allowed me to build additional systems that I hadn’t initially planned. Moreover, I was fortunate enough to have 10 beta testers which provided invaluable insight which helped me identify what was working well and what was problematic during the game’s development. For instance, originally, the camera was hard attached to the player and didn’t allow any user input to slightly modify its camera angle. A tester, suggested to make the camera more dynamic by letting the user slightly offset the camera based on the mouse location on the screen which ultimately had a huge positive impact in the game’s user experience.

Additionally, I had the chance to test out various AI implementations and build several different systems regarding boss fights, which I really enjoyed.

When it comes to the AI in particular, during the early days of development I had to implement a custom EQS system for my game since the built-in system for the engine was a bit unstable and raised crashes that I wasn’t able to pinpoint or reproduce. As it turns out a few people had that problem as well and to be fair, the system in my engine version is marked as experimental. However, the good news is that EQS is no longer marked as experimental in the latest version of the engine! This system can become quite complex but I was fortunate enough to have a straight forward implementation that didn’t cost too much development time.

Last but not least, it seems like my QA was decent, in some ways at least, since only 2 out of 10 testers reported bugs or game crashes.

So, to sum up this section:

• Clean and reusable code saved me a lot of time in the long run
• Beta testers played a huge role in identifying areas of the game that needed improvement early on
• Various AI implementations (which remained unchanged from the first game design) worked out great
• My QA process seemed decent enough for the game’s scale

Conclusion

At this point I have to congratulate you for making it this far and thank you for reading this post.

Fortunately, even with the complete game redesign things turned out great! I learned a great deal about a lot of different aspects of game development while being able to focus on the programming side of things. Here is a list of my conclusions from my experience with my project:

• My original game design was too large
• Procedural world generation was a terrible idea for my case
• I’m terrible at building levels, even with game ready assets
• Splitting the game’s code into small, independent parts allows you to build complex systems unexpectedly fast
• When demotivation occurs, just open up your project and make at least a single change, even if it’s the background color of the main menu. By performing this sometimes you tend to clock in longer hours than originally expected (which gives you the opportunity to do or at least test more stuff). Even if you don’t end clocking longer hours, at least by the end of the day you’re not on the same spot you were yesterday so this is progress!
• Take screenshots or videos during the development phase. You will get blown away from your progress when you’re constantly working on the same thing after a period of time
• If the project is too large, just downscale. Rinse and repeat until the project is doable and don’t give up.