Postmortem: Go! Make Your First Game!

1: Don’t Be Afraid to Learn New Things

One of my biggest challenges was being too afraid to learn new things. I constantly found myself making workarounds for systems that I didn’t quite know how to program. I paid dearly for it with a system for flags in our game. Essentially the lead designer tasked me with creating a list of searchable boolean flags to handle progression. Seems easy right? Well the particular way that he wanted it was difficult for Unity. He wanted to be able to interact with the flags in the inspector which also isn't a problem. We all learned this in our university’s equivalent of data structures right? Use a hashset! It’s simple, efficient, elegant, and exactly what we need! WRONG. In Unity, Hashsets cannot be represented in the inspector. So what else can we use to represent these string, boolean pairs? My immediate solution was to create a boolean variable for each different flag and the name of the variable was the name of the flag. It shows up in the inspector, is searchable with a function, and stores booleans. For more experienced developers out there, it’s easy to see this caused a lot of problems. Everytime I needed to search up a flag? Massive switch statement. Need to toggle a flag? Massive switch statement. You can tell where the rest of this is going. Each switch statement couldn’t be copy and pasted and needed to be written out by hand and I wasted a lot of time going back and forth and rewriting what felt like the same code over and over again.

Eventually enough was enough and I refactored it to be a list of custom objects that held the data I needed. I originally didn’t do this because I had trouble representing an object like that in the inspector but that’s when I learned that an object denoted with: [System.Serializable] will allow a custom object to be represented in the inspector and I happily deleted all of my switch statements and in the end deleted around 500 lines of code! Efficient!

2: Don’t “Go Rogue”

I constantly found myself looking at a design brief where I just had no idea what it meant. I was mainly a menu developer and would get tasked with things like “Add resolution controls” or “Add an easy mode” which didn’t really make sense to me. Which resolution? How do you want them to be selectable? An entire easy mode? While these are easy examples because a simple question or 2 can clear them up, One situation I found myself in definitely sucked. When I first made the options menu I decided I was going to work ahead a bit and make some animations for the menus without getting any of the designer’s specifications. I don’t really know anything about animation and made a simple slide up and down animation for opening and closing the menu. This ended up being the only animation made for the menu really should’ve been approved first because how I programmed it really only made it able to have that one animation.

This issue persisted and the menu had a really slow open and close time for most of the games development until I was working on a menu refactor and finally put the old animation out of its misery and that code I thought I was doing for the greater good of my project was entirely unusable.

3. Don’t Volunteer a Change Until You’re Fully Aware of What it is

Near the beginning of my time on the game, I was in a separate class at my University learning about VR development in Unity and the professor showed us Unity’s “new” input system that has been around for a decade. This input system is really great in some ways and I was very easily able to refactor our existing input system fairly easily to use the new system. The problem soon to come was non-existent on my radar because I didn’t really know much about it but hey, it’s going to be standard sooner or later so let’s adapt early right? Not even close. While I do enjoy using that system, as the menu and persistent storage developer, my life soon became a nightmare as someone that didn’t really know how to use this system. The designer wanted me to add in a rebinding system that could save so users didn’t have to put in the same key bindings every time they played. This is easy for someone that knows how to but as someone who was learning on the fly, I made a lot of mistakes. I was constantly lurking in old Unity forums and reading documentation that I didn’t understand. By the end of this process I was wishing I had never even volunteered to adapt to this new system.

This isn’t to say that we shouldn’t have used this system, I love it and find it much more flexible and easier to use than the old system, but my life would have been so much easier had I really delved into this before I even volunteered to implement it rather than just see the tip of the iceberg and think it’s perfect. Remember, if you volunteer to implement a feature, that feature needs to be FULLY implemented.

4. Have Fun With It

My last bit of advice is to really enjoy it. Making games can be just as fun as playing them especially with the right people. This game started as a University project and I really enjoyed meeting my team and I consider them close friends even outside of this project. Remember that if you’re with a team, you’re gonna be with them for a long time. Sometimes there are issues and sometimes you all are going to be the best of friends but don’t forget that you’re all working together to make an amazing product.

I didn’t really want to be a menu and persistent storage programmer when I first started around a year ago, but ultimately, I’m so happy because I learned a lot and got to be an invaluable member of the team and had a lot of fun doing so. You have to enjoy making a game if you want you’re players to enjoy playing the game!