It's a time-honored television tradition: a holiday arrives or the budget dries up or the writing staff just can't be bothered to put together a new episode, so they write a few minutes of setup and run a clip show featuring bits and pieces from earlier episodes. In many ways, that's what this long-overdue SummerJammers (a Giant Bomb themed WindJammers homage) update feels like. About a month ago, I finished up the last work on building the basic rendering and timing framework for SummerJammers, and around that time, I, exhausted by the process and struggling to change gears from technical design to gameplay implementation, took a few weeks mostly-away from the project to work on a few other things (writing comics, designing a board game, and (barely) working on that job situation). As a result, there's not a month's worth of new stuff to talk about here, so instead I'd like to look back at what I've learned since I started this thing in November and cover whatever other small miscellaneous fun facts have either popped up in the last month or slipped through the cracks in previous updates.

If At First You Succeed, Try Again Anyways

For me, working on SummerJammers is about two things. First, it's about creating a finished product, a well-produced and well-designed game where Brad and Vinny throw frisbees at each other (if you'll allow me to borrow the ontological argument here, such a game is the best possible thing, and a good thing is better if it exists). Second, it's my attempt to learn how to make a computer game, to take my modest but non-zero knowledge of computer science and programming and stretch it to a meaningful level. That second point is why I've chosen to shoulder such a large part (all, so far) of the coding and design burden despite being knee-deep in talent here at Giant Bomb.

It's also why progress is slow. Someone somewhere probably once said "amateurs practice until they get it right, professionals practice until they can't get it wrong," and if they did, then they've pretty much summed up my experience so far. It's not enough for me to write code that works; I need to understand why it's a good (November 2013 would have demanded "perfect," but more on that later) solution to the problem at hand, and that can be a lengthy process. It usually entails trying a different approach, even when I've got something that already works. It's sort of a "breadth first" approach to programming; I try two seemingly viable paths until one of them presents a massive issue, at which point I look back and say, "oh, right, that's why I liked it the other way." It's no way to make a game, but it's a hell of a way to learn. I've developed a much better eye for potential roadblocks as a result, and that's exactly what I'm looking for in this - a chance to learn my shit while I'm not necessarily on the clock or the payroll.

That'll Do, Pig

I've definitely toned it down in the months, though. On day one, I was satisfied with nothing less than the One True Design that would make everything as elegant as possible. However, the thing about working on a big program like this is that there are so many moving parts that no one solution will be universally optimal. Understanding -- or rather, accepting -- this has been the slowest and most painful part of this for me, and if it weren't for the constant reassurances of ol' college buddy, computermancer extraordinaire, and all around decent guy Adrian, I probably never would have accepted that something, somewhere, will inevitably have to give. A corollary of this is that the most exhausting problems for me are the "easy" ones with plenty of good solutions because I'll invariably dissect each and every implementation thinking that one them must be a magic bullet.

The good news is that I've loosened up a bit in this regard, and I'm far more comfortable hacking together a quick solution and refining it as I go along. I still do the occasional bit of pre-optimization (a cardinal programming sin), but overall I'm OK saying "I want this thing to do that," writing some code to make it happen, and then just fixing whatever other code I just broke until everything compiles again (the magic of a strong compile-time language like C# is that 99% of the time, just getting the code running will also get it doing what you intended). I've moved away from spending hours of planning before coding (and remember, we're just talking about software design here, not even game mechanics) and have largely moved to an on-the-fly iterative process. It's great. Do that.

Git On Up

It's also helped that (at the behest of, and with much help from Adrian) I've set up my first-ever version control repository. I'm doing all the things the cool kids do. I commit and I push and I oh holy hell I just borked my program, revert, revert! In addition to being a good thing to know about if you want to do big-time game making, getting acquainted with version control has actually helped me focus on smaller goals while I program. What would I like to put in today's commit notes? Great, start working on that. It also gives me an excuse to more frequently check in with myself and assess what's getting done and where I'm over-thinking things. And now there is a permanent record on the internet of how I've implemented and removed the Avatar class at least three times. Yeesh.

Learning, remember. Learning.

Also, all this Gitting nonsense has made me realize that, hey, fuck it, lets get some more hands on this project. I originally planned to do an overwhelming amount of the SummerJammers code on my own, outsourcing just the asset creation and a few tasks like networking and AI. However, now that I have a better big-picture view of the whole process, I feel a lot more ready to have folks contribute more of the nuts-and-bolts code. I've learned a hell of a lot, almost enough for one project, so I'm looking forward to rallying the troops, putting together something we can be proud of, and playing that young SummerJammers, son. After all, the first thing I'm going to do once SummerJammers is done is make another game, so there's no point in holding up production in the hopes that if I do enough of it on my own that I will become a Master Programmer/Designer/Casnova.

So give me a month or two (let's aim for two final solo updates in March) to tie up some loose ends and clean up... well, a lot of code, and we'll put this thing into overdrive. Considering that I've already written most of the collision detection, animation, and player input frameworks, there's only so much that could go wrong from here. Right? Right? I mean, come on, it's already a thing where circles throw a smaller circle at rectangles. And in a way, isn't that all we are? Just circles throwing circles.