For the last several months, until I graduated in June, my focus has been a lot more on completing my degree in Computer Science then it has been on working on game development. At the same time, I had just gotten a job as an android developer, so you could safely say I was always on the go. For that reason, Pitchfork Kingdom received hardly any of my attention from March to just recently in July. Now, having successfully completed my degree and becoming more settled in my “work life”, I have found the time and motivation to jump back into creating Pitchfork Kingdom; But the motivation didn’t happen right away. In fact, after returning from my hiatus as an indie dev, I had to start with a new project because I every time I opened the Editor to being working on Pitchfork Kingdom, I felt dread.
I started Pitchfork Kingdom as a totally different entity quite a few years ago. It wasn’t until the last year and a half that it really began to take the shape of what it is today. Of course, one of the biggest contributors to that was finding the right artist, something I am grateful for. Some of the code and architectural designs for that project are more then 4 years old, which is before I even started going to university. While I did know how to program somewhat competently, I have a lot more knowledge and skill for programming and design then I did when I wrote those old scripts. So, when it came to getting back work, the first thing I would do is see a huge codebase that needed a dramatic refactor. This realisation ultimately overwhelmed me every time I thought about it and created a major roadblock to making any progress on the project at all. And that’s where I was at for most of July, limbo.
There is one piece of advice that is common to any new game developer, Start Small! This is an important piece of advice for a few reasons:
- You don’t want your game to get to big that you can never finish it.
- You learn more with every release.
Pitchfork Kingdom isn’t a small game, but it isn’t some massive MMO that will never get finished either. Feature Creep (adding more and more features to the game increasing its size until it its fate is that of the first point, or close to it), is a hurdle that we always must be aware of while developing this project. At least for now, the size of the game feels like its in a good place.
Something similar to the second point, “you learn more with every release”, is what plagued my development of Pitchfork Kingdom. That’s not to say I think Pitchfork Kingdom was a bad idea or that I wish I was working on a smaller game (I had made lots of smaller games already), only that I understand why that piece of advice is so relevant. As developers, I think we are always learning, not just with every release but with every hour spent developing our product, which was the case for Pitchfork Kingdom.
After sitting with the feeling of being overwhelmed by the work ahead, I finally motivated myself to take a deeper look and come up with a gameplan for the next steps. As I went through a lot of the game’s codebase, some of the architecture was in desperate need of changes, some was okay but working, and some was good. Almost all of it I could redesign and rework if I wanted to but that would be almost like starting from square one. If I started a new game today, of course I would do things differently; I am a more experienced developer then when I started. In fact, every day I spend writing code, you could say I am smarter then yesterday (okay, maybe not every day). I finally decided that I could either spend all my time constantly refactoring with endless iterations as I continue to find better ways to do things, or I could just refactor the parts that show potential issues down the road and get to work on the more important stuff sooner. This was the solution to pull me out of limbo.
Software development is and ever-changing field as developers are always learning new tricks and working with new technology. Eventually, you have to decide that something you did is “good enough” and move on, or you won’t get anywhere. There will still be cases when refactoring is necessary to accommodate the changing software because most games aren’t completely laid out at the start and even if they are, they will probably go through several design changes or iterations during development. It’s also important to remember that the player of your game isn’t going care which framework you used, as long as it works and has good performance. In the case of Pitchfork Kingdom, I came to the conclusion that a lot of the code was good enough , because it met both those criteria. My massive refactor has now shrunk to a manageable size and I am excited to be back to working on the most important part of the game, the player experience.
Pitchfork Kingdom 