(or: How I Learned to Stop Worrying and Love the Bad Code)

So I’ve mentioned previously that the single greatest setback in the development of this game has been my continued desire to wipe out everything I have and start from scratch over and over again.  I get so frustrated with my current code base that it seems to me that the best thing I can do is scrap what I have and start over. I’m not sure if this is a common problem among developers or just my own annoying quirk but I’ve come to realize it’s preventing me from ever getting anywhere. In all my iterations of this game I have never once had a version that I can call a playable prototype.

So starting a few of months ago I had a massive change in how I was looking at things. Instead of trying to make everything perfect right from the start, I decided to make everything super rough, and to be ok with that.  What I mean is I don’t have to worry about all of the complex systems in the game in my first pass. I’m giving myself permission to do everything the easy way first.  Until I have the simplest playable prototype working I shouldn’t worry about all of the little details I inevitably get caught up in as I go.

What I did wrong

The first few takes (and by few I mean like 10) I had at making this game never got any further than the algorithm I was using to generate the map the game takes place on.  Looking back at this I feel like an idiot. I was so wrapped up in a portion of the gameplay that actually mattered very little that I never got to anything important. I came up with all kinds of ideas about how I wanted to generate roads and buildings and terrain. Did I want city roads to be splines contouring to the landscape or would a more grid like dense urban area work better? I tried recursively splitting rectangles for city blocks. I tried tree structures for roads. I was using different noise algorithms to simulate population density and worrying that intersections didn’t look correct. But none of that was important.

I got wrapped up in GUI implementation as well. It made sense to me, at that time, that I would need to start with the main menu. I guess my reasoning was you needed to start developing with that because that is where you start when playing a game. I started using chromium to show user interfaces and then I got wrapped up in figuring out which MVC library worked best and which CSS pre-processor I liked and I started looking at coffeescript to handle all the scripting.  Before I knew it I had created this monstrosity of a UI that DIDN’T DO ANYTHING! Zero game play elements.  I’m honestly getting furious with my past self just typing this but it’s all true.

It’s not just feature creep that killed me either. I tend to get really anal about my code. I need it to look good and I need it to be as clean as possible. Everything has to be as efficient as possible. My classes have long lines of inheritance and anything that can be broken out into a function is. As I was writing I was constantly re-factoring code I had just written because I felt it was neater this way.  The problem was that I would travel so far down one path only to realize that this path would not work or I preferred to do it another way and thus not only the time spent originally writing the code was lost but also all the time spent re-factoring that same code was lost.

How I’m fixing that now

Dynamic map generation is an important part of Project Zeds. At least it will be one day, but right now I just need to be able to play a game. I don’t need that map to change every single time I play, and honestly for debugging purposes it’s probably better that it doesn’t change every time.  So I’ve created a static map that has that basic game-play pieces I need to play a game. It’s small and it’s ugly but it works, and it lets me move on to the next big piece. Eventually I’ll work on making maps dynamic, but that’s not important now.  An added advantage is that by making maps by hand for now I get a better insight on what makes a map good or bad. I get a better feeling for how the map maker should work when I eventually get around to that. This is the type of information I was just guessing at on my previous attempts.

 

UI’s aren’t really necessary right now either. There is very little UI functionality I can’t replicate by either printing directly to the screen or assigning a hot-key that I have memorized. It’s a solution that I’ll have to fix before the game will make sense to anyone else but for right now it’s all that I need and it allows the prototype to be playable.

I’ve also managed to keep my code re-factoring to an absolute minimum. I still break things out into functions but only when I feel it’s necessary to use in multiple places. I’m keeping my code to an absolute minimum until it becomes apparent that it will have to be upgraded for the next basic prototype task. For instance I was working on moving pawns around the map. My initial instinct was to spin up an AI controller with a behavior tree, black board, and custom behavior tree tasks , because I knew I will need that framework eventually, but I was able to stop myself, and on my first pass just used the Unreal move to function already built-in to the character class.

How its working out for me so far

It’s working out amazingly. Since I stopped getting hung up on every little detail on my first pass I have been able to get a lot of the main game play mechanics into the game.  I haven’t wanted to start from scratch even once. I’m the closest I have ever been to having a playable prototype and it makes me happy.  Once I have something I can play, then I’ll work on going back and flushing out a lot of the systems I have and re-factoring the code in a way that I like but for now I’m OK with it being the way that it is.