The concept for this week’s game came from a conversation I had with my brother-in-law about wanting to make a click/idler game, but wishing that they had more substance. There were a lot of grand aspirations, but I kept narrowing the scope of the project until it became something resembling a space-themed shoot-em-up.
All the names still reference the original “clicker” theme, though, so you can play it at http://game-a-week.problematic.io/starship-clicker/
I had a lot of fun with this one. I mean, a lot of fun. I stripped my original, nebulous idea down to the very minimum I could be happy with: a ship that you can fly sound the screen, and bad guys that you can blow up.
I should pause right here and point out that the fancy artwork (and sounds and fonts, actually) for the ships flying around the screen are free (CC0) stuff from the extremely talented Kenney, without which, the game would really consist of boxes flying around the screen. I know my strengths, and art is not one of them! Working with preexisting art assets was a really refreshing change of pace, and I think it made an immediate and significant contribution to how enjoyable it felt to play the game.
At any rate, version 1 of the game was exactly that. The enemies moved toward you, but didn’t fire, and you had to click directly on them (echoes of the original theme, again) to make them explode. But, I sat down with my brother-in-law and made a Trello board (which is actually open to the public, if you’re interested), and added bits one at a time for what would help make the game actually, y’know, fun.
I think that was actually the single greatest thing I did for the development process: being able to move development tasks around and see a roadmap one piece at a time was invaluable in being able to stay on task and keep delivering… I might even venture to say that it was my most successful use of “agile methodology” to date, and it just happened, rather than being a strict thing that I sat down and planned out in advance. There’s probably a lesson to be learned there.
I read an article recently about having a “forever project,” one that you never call done, but keep adding to and learning from indefinitely. That really resonated with me, and I think I could see this game as mine… within the week, I didn’t even scratch the surface of the things I wanted to accomplish with it.
I mentioned in my last postmortem that I was going to have to pay more attention to architecture to keep making good use out of Phaser with more complex projects, and that came true here. Earlier revisions of the code show a cursory attempt on my part to break things up into separate classes, but toward the end of the week, I found myself hitting a wall where the way the code was structured was preventing me from adding the features that I wanted. So, I stopped adding new features and refactored everything to be much cleaner. In software development, we call that “paying off technical debt,” which is a topic I’d like to write more about in the future. Suffice it to say, in a business environment, reducing technical debt can be one of the hardest sells a dev has to make to management, because it’s pretty much what it sounds like: “we want to stop making new features for a while to fix the way we wrote the old features.” Generally not a very popular request.
Anyway, game development is not (yet) a “business environment” for me, so I got to make that call. It was a blast. I got to see where some of my quick hacks, made with the future in mind (“I’m going to write this as an ugly hack now, but I’m going to write it like this so it’s easier to fix later”), paid off, and some where I just didn’t have a clear idea of what a well-architected solution would even look like. Let’s be honest, maybe I still don’t, but now I’ve been there and done that at least once!
The flip side to the thrill of refactoring everything is that it did just what it sounds like it would do: it killed momentum. I’ll be honest, I had that “forever project” article in mind when I made the decision, and while I don’t regret it from that and a personal enjoyment perspective, I don’t think it was the right call for a week-long development sprint where the project gets set aside afterward. It does reaffirm the idea I had with last week’s game that I should earmark some time for polish and refactoring and all the things I wish I could have gotten to before the week was up. Maybe I’ll dedicate a week to that instead of a new game sometime soon.
Once again, you may notice that the game is lacking both start screen and a victory/loss condition. This is a great testament to how well postmortems can work as a tool, because if I’d completed the Bubble Popper postmortem in a timely manner, I would have focused on those two things. Well, there’s always next week.
The Ugly Conclusion
I wanted to write more in the “Bad” section, but honestly, I think this week was a strong success. I’d like to keep working on the game, but I’m going to shelf it for now and keep momentum going in the game-a-week challenge. I had a blast creating this game, and it was encouraging that I was able to build it up starting from very simple steps. That’s a tactic I’m going to try to keep replicating.