You heard it right, game number two is complete! If you have no clue what I’m talking about, you might want to read the previous post first. While there are a lot of features which I had to unfortunately leave out, I’m pretty pleased with the final product. Mirrors is a tile-based puzzle game, you can see read more about it and download a copy to try out yourself here.
I have to say I learned a lot of things that will certainly make my next game a lot better, and make the development of it much more streamlined. Here are a few notable things I discovered:
Instead of implementing every idea you come up with right away, make an idea list. You will almost invariably throw away at least 80% of those ideas, whether because of time constraints, technical constraints, or simply because it turns out to be a bad idea. Jotting ideas down as a note allows you to remember good ideas so you can implement them later, without becoming distracted from whatever you’re working on at the time. I suggest you also extend this method to writing down bugs you want to fix later. Most popular IDEs have a task tags feature, which allows you to view all of the places a certain keyword is used in a comment. Typically the default keywords are TODO, and FIXME. I’ve added a task tag in my Eclipse settings called LATER. Using these three tags I can categorize tasks in order of importance. One of the main reasons why this is a much better solution than simply writing your ideas and bugs down in a separate text file is that you can open the task window and be taken to the line where the comment is. This saves a lot of time searching for the right file, and the right line.
Work on a feature until it works, then move on. If it requires more work later, then you’ll work on it later. I think this is similar to the methodology behind the popular software development strategy, SCRUM. At the end of each “sprint” (typically lasting between 1 and 4 weeks), the product should be ready to ship. This ensures that at almost any point, if you run out of money, or time, you will still have a product, maybe lacking some of the features which you wanted it to have, but at least you have something. Now, I’m not suggesting you write poor quality code that is hacked together and just barely works, because that is never a good idea. What I am suggesting however is that you resist the temptation to perfect any part of your code base, at least until you have your MVP, or minimum viable product. I have fallen into this trap before, and it usually results in is a really great feature, and not so great other features. And honestly, how fun is a game that has an amazing achievement system, but awful controls? Or a game that looks spectacular, but only has one boring level?
Things come up, aim to finish projects before the deadline arrives. You may have noticed that I’m posting this on March 5. The game was essentially done by the time February ended, but I still hadn’t exported it, started to write this blog post about it, or start to make the project page for it in my portfolio. All these things take time, and while it seemed like I was done, I still had a few hours of work ahead of me. Now, if I wasn’t so busy near the end of the month, I would have probably been able to truly finish by the time March rolled around, but of course that didn’t happen. And now I have five less days to work on my next game. Unfortunately the same thing could definitely happen again this month as I predict I’ll be just as busy.