A journalist’s adventures in game development

I will never forget the moment I got the physics to work. I was using a rather poorly written tutorial for creating a bare-bones puzzle-platformer level in Unity and I had been at it, on and off, for weeks. Every time I looked at my code and tried hitting the play button at the top of the screen, I was bombarded by errors in my little console. Then, my hastily drawn stick figure of a character disappeared. Then, the jump command didn’t work.

But after 6-ish weeks of debugging and rewriting and tearing my hair out, something finally clicked, and my crappy little character was running, jumping, and generally, behaving like a platform character should. I wanted to throw myself a party.

Game development is equally frustrating and exhilarating, and, oddly enough, one of the most addictive gaming experiences you can have, once you get the hang of it. I’ve only just starting exploring this side of the world in earnest, after years of dipping my toes in every now and then. I’ve had a longtime on-again, off-again affair with the Unity engine, along with a non-committal past with other tech – a few flash game experiments in grad school, a dalliance with simple HTML5 browser games, and a very brief (and fiery) fling with Akihabara one weekend, which ended poorly.

I’ve been writing about games professionally for a few years now, but the development bug didn’t really bite me until around 2010. Until then, I considered my math-averse brain completely incapable of anything as technical as game development. The idea of learning programming (well, scripting) seemed about as feasible as building my own rocket to the moon: appealing, in an abstract way, but not likely to happen in any permutation of reality.  

My first foothold came from an unexpected place: I ended up learning JavaScript for a web development project at my day job. I spent a solid year learning the ins and outs of scripting for the web, and I fell in love with the feeling of empowerment. In some small way, this was like being able to see that the stuff under the hood wasn’t scary at all, but a wonderful, logical, and infinitely configurable puzzle. The desire to start making my own games wasn’t far off.

After a few Amazon shopping sprees for good game development texts, I spent countless hours getting boring little test games to work. I experimented with shooters, puzzle games, card games, bizarre little physics experiments – ugly little games with crappy assets and awful sound effects. You know, precisely the sort of fodder I was used to blasting in reviews, only here I was, cursing at code and rejoicing when my dummy-level projects functioned.

One day, after playing Dear Esther, of all games, I decided I would finally try to buckle down and make something decent. Good, even.

Dear Esther was a revelation for me, at least in the technical sense. While I certainly enjoyed the game, what really got me going was the slowly dawning sense that, after two years of experimenting with Unity, I actually possessed the knowledge to recreate something a little bit like TheChineseRoom’s experience. A real game! It would be uglier, no doubt, but it might – just might – actually function. I started to “see” the audio listeners, sense the scripting beneath the gorgeous veneer, count the permutations of grass on the plains. I felt like a low rent version of Neo, seeing the true nature of The Matrix for the very first time. It was intoxicating.

The decision to go with a 2D platformer for my first “real” game was an easy one, since it’s about the only genre I have any real skill in, and I figured the level design lessons would be invaluable. Plus, I could replay old Super Mario Bros. levels for “research purposes”. Of course, it also meant a whole lot of physics scripting, along with a little “light” puzzle design. A fun fact – puzzles are approximately two to three times as hard to design as they are to solve.

Game development is one of the most addictive gaming experiences you can have, once you get the hang of it.

It’s strange on the other side. Often, what I thought would be the easiest things are the hardest to implement, and vice versa. It’s ridiculously easy, for example, to string levels together, to make menus that make sense, and to make 3D cameras that behave (I know, believe me), but just try and make a simple card game, and all hell breaks loose. And don’t even get me started on the trials and tribulations of Raycasting, which may have cost me a couple of years of my life. 

It’s immensely satisfying, however, when things do work, and some tiny fraction of my grand vision is sitting there before me, playable. When the physics started to work, for example, or when my very first experiment with parallax scrolling didn’t break the screen – and even looked halfway decent. It’s in those moments that I understand why developers – indie and AAA alike – put up with the crazy hours and the endless frustrations inherent to software development. It’s a truly addictive grind, like nothing else in the world, and the satisfaction of creating something whole and interactive is unparalleled.

One day, I’ll get to the point where I feel comfortable sharing my creations with someone other than my girlfriend (who also acts as my primary playtester). The work I’m creating now is akin to still life doodling – starting to show competency, but not originality, and none of the personality and spirit I’d ultimately like to be able to show off. Until that day I’ll keep soldiering on, prototype by prototype and game by game.