Friday, June 29, 2012

NaGaDeMo2012: My Experience

June 2012 marked the first National Game Development Month - aka NaGaDeMo.  The idea was to take the energy and interest behind the various game jam events happening worldwide, and change the format from the typical 48-hour ironman rush to a more inclusive, self-directed pace, not unlike the NaNoWriMo event, which was another direct inspiration.

What really appeals to me is the way this event embraces the idea that anybody can participate, thanks to a low barrier of entry and ample time.  People who have never made games before can learn to use a tool like Twine or Gamemaker,  professional devs can build something in their limited spare time, and everyone can avoid the faux-crunch of a shorter jam.

So I went into June excited to contribute to NaGaDeMo. At the end I came away with a crappy game, but I'm still glad I did it, and took away a lot of lessons.

How it Went Down

Before getting into the details, you may want to play the game.  You'll need two players at the same mouse/keyboard to experience it properly, but take a look for context, even if it's just you.

I had somehow never played Rampart until late May, when I was visiting Portland and saw the game in an arcade there.  I thought it was completely fascinating, and with June just a few days away, it was the perfect inspiration.

I exchanged a few emails with my would-be collaborators.  The plan was to spend the first part of the month building a simple game which cloned the most interesting parts of Rampart, and to then experiment with gameplay mechanics to figure out what made the core game compelling - and what elements were simply trappings of the bygone coin-op era.

I ran into my first obstacle early. Both of my partners had to bail on the project due to obligations beyond their control.  This marked what would only come to light later as my first big mistake.

Constantly Evaluate and Adjust Plans

When my team size went from three to just-me, I didn't really re-evaluate my plans.  I was still very interested in exploring Rampart's mechanics, and simply chopped features that I knew were beyond my ken, like online multiplayer.  I still had a slew of features I was interested in - way more than I'd be able to implement in time.

In hindsight, I should have scrapped the Rampart concept and spent a day or two coming up with an idea better scoped for a solo project.  Instead, I hopped straight into Unity and started building, picking off problems one at a time, chasing down whatever seemed to be missing at the moment.

Halfway through the month, I had the most basic elements established.  Two players could play, and turrets could be built, aimed, and destroyed.  At this point I thought I could use those building blocks to experiment and try several different ideas out.

What followed was a week where I never touched my project.  I realized after several days that it was because I hadn't actually committed to any ideas I was interested in chasing down.  I finally took one ("It might be fun to push a physics object around, rather than just shoot the other player") and ran with it, forgoing the vague notion that I might experiment with several ideas in my remaining time, casting about for something special without a roadmap.

Tools Really Matter

Unity was a great tool to work with.  For anybody who has worked with a mainstream level editor, it feels instantly comfortable.  What makes Unity special, however, is the fact that it can empower both the code illiterate and an experienced programmer. I am neither, so it was especially good for me, as I could hack functionality together in Javascript where needed, and work in-editor everywhere else.

Having worked on large-scale games for years, it's a unique thrill to dig into fundamental issues like player controls, rules code, UI building, or in-editor gizmos - all of which I usually take for granted on larger-scale projects.
While Unity itself was great, I did establish a whole new appreciation for some of the expensive software I have access to at work.  I had resolved to only use freeware for my NaGaDeMo assets.  Gimp is a fantastic piece of software, but lacked the familiarity of Photoshop.  3D models were a bigger problem.  I searched for a workflow to create and texture simple 3D, and tried everything from Blender to iPad apps, with little luck.

I ended up doing very little art as a result, and what I did make was created with Sprite Something and Gmax - a combination I would never have expected.

Good Controls are Fucking Difficult

I've already mentioned how much I enjoyed learning about low-level implementation details which I normally have nothing to do with - such as player controls.  Turns out that this stuff is really, really hard, though.

Unity comes with a lot of pre-packaged control systems - so if you're doing an FPS, for example, you can get up and running in minutes.  I wanted a point-and-click interface, however, so I thought it would be easy to roll my own.  And it was pretty simple to get a rough system working.  I had to learn subject matter I've never had to deal with before, though.  Just building and using a raycast took me a couple of slow nights to understand and implement.  Let's not even talk about converting worldspace to screenspace and vice versa...

In the end, my controls are inaccurate and buggy, and hacking them in stymied me for a few days.  I moved on once I had something roughly functional, but it's clear that if I wanted this game to be truly enjoyable, I'd have to put a lot of time into developing controls that weren't just functional, but felt great.

The 90/10 Rule

Building my control system was a good proof in the dev adage that the last 10% of any task accounts for 90% of the effort.  My whole month was characterized by quickly identifying and tackling problems.  In the final week, for example, the game was just a playfield with one mode, and I assumed it would end that way.  One evening of weekend coding, however, and I was able to tack on scoring and win conditions, as well as some basic GUI, menu-transitions, and little touches like resetting an out-of-bounds ball.

It's very gratifying to rapidly move through problems like this, but if this game were to go further, I'd have a lot of hard work to do.  The game I created in June would be nothing more than a prototype, and much of my code would be thrown out and re-factored if I wanted to make something "real" based on it.  Going through the motions of actually putting a game together reminds you of the myriad elements we hardly notice as gamers.  This is all stuff that needs to get built, and it isn't always the sexiest work.

Good Craft is not Great Art

Perhaps the most meaningful thing I realized during NaGaDeMo came in two parts.  Even though I sometimes avoided working on the project, or had to gnaw at difficult or boring problems, whenever I sat down and dove into it I would enjoy myself.  At nearly every development session, this thought would enter my head:

"Making stuff is fun. I need to be doing this all the time."

It's easy to forget how gratifying the act of creation is.  It didn't matter what I was working on - the process of solving a problem and seeing the results on-screen is fantastic.  It's something I experience regularly in my everyday job, and working on my NaGaDeMo game brought me even closer to that sensation, because I was very rapidly finding and solving new problems.

Yet - I was also aware that my game wasn't good.  I don't just mean it was buggy or ugly, though it is both of those things.  It's just not a game with great potential, which I blame on the aimless meandering I did throughout June.  Despite that, however, I still took an immense amount of joy in working on it. It didn't matter if the end result was trash.  The game itself would only be worthwhile, then, if I made a conscious effort to pour thoughtfulness and expression into it.

There's a duality here which I think describes many good game developers.  Game development is a distilled form of creation, and many aspects of development give the same edifying pleasure of working with your hands.  There's a craftsmanship to well-built design, code and art, and great developers take pride in their work being executed at a high level.

Likewise, a great developer also needs to think about the impact their work will have on the player. What will they learn, and how can it make this person's life better for having played the game? This kind of vision is what allows us to transcend simple assembly, and begin making art.  It's the difference between a world of straight-backed chairs and a world where beautiful design like the Eames Lounge Chair exists.

So, although I may have reached the end of NaGaDeMo with only a poor game, I still feel I got a lot out of the process, and look forward to applying these lessons to my future work.

No comments: