game design 099: the don'ts (SOGO week!)

Starting on the 12th and ending through the 16th, it's Speak Out with Your Geek Out week! Which means that there will be a post every day! Which means that, for the entire week, we'll be covering the general gaming pizazz: favorite non-casual/more hardcore titles, reasons why we geek out over games, whether or not games adapt well to other media environments, and so forth and so forth. All that Noriko Matsueda jazz. Thursday's flavor of the day: chances are if you like games, you've thought about making your own. From someone who's tried multiple times and miserably failed, here's what not to do.

First off, a very important disclaimer: I haven't made an actual game. I call myself a game designer, just as an unpublished novice calls himself an author to start getting into that mindset that Bob-the-Builder "yes we can!" mindset. Or is that from Barack Obama? Anyways, I should warn you that my primary experience comes from three attempts at game design I've made over the past two years:

-a JRPG-style story I created with my best friend. We got as far as writing fanfiction for the possible "shipper" permutations among the main characters, which is to say we were perpetually stuck in the pre-production phase.

-a horror/survival FPS set in a stereotypical zombie apocalypse, however using what we considered unique mechanics and character stories. "We" were a group of online writers who had crafted a dedicated collaborative novel and a video game seemed like the perfect outlet for that story. At the last moment, a lack of time and resources combined with an increase in interpersonal team drama put an unoffically-declared end to our endeavor.

-my attempts to go solo by attempting to learn Python, Visual C#, ActionScript, and HTML at various times. I'm still somewhat in the middle of this haphazard experimentation, however I think I've found a stable solution for the meantime (read on).

1. The story is EVERYTHING. Worship the Story. It's what the player remembers most, after all, right? Without a Story, there is no game. The Story can justify even the crudest and cheapest of gameplay because it's part of the Theme. The Story is how you get a fanbase with fanfiction, etc. However, even the Story cannot get rid of the fact that a hastily thrown-together Garageband sample-loop soundtrack will suck away the mood, or that an average sophisticated-looking PC title owes its thanks to some sharp C# plus C++. If you're simply in love with the Story but lack the energy to do the other things—go write that story, get a literary agent to sell it somewhere, and be a novelist.

2. Jump on the first resources you find. Assuming that you actually remembered there was more than just a Story, chances are you quickly figured out that there are one or two things you enjoy (i.e. eating chips at the "team meetings" and doing the character voices), and the rest can go die in the Pit of Carkoon. But since you can't do much more than metaphorically decapitate these important tasks, you or your co-workers will have to do them anyway, so you skim a few message boards and solo indie dev websites for fast and free resources. 3D Animation and game engine together on the fly? Bam, Blender. Audio mixing? Awesome, Audacity. A word processor that automatically puts everything in a clean script format? Gotcha Celtx. Now don't misunderstand me—I've downloaded all of these particular applications at one point or another; I've played with all of them at least a few times, for fun or for work; I consider them very high-quality programs, not just for their price economy but also just as solidly-constructed, thoughtful and efficient task assistants. But are they the best in their fields, or more specifically, for your game's intended design and function? Are they good tools for your particular level of expertise (i.e. you should really be fluent in Python to actually use Blender's game engine)? Mine the most optimal resources for your game, free or commercial. I'm still trying to figure out if it's more ethical to let only your imagination limit the tools you use, or if the tools you use should be able to modify and limit your imagination as appropriate.

3a. The best way to make a game is with your friends. No. You will fight and squibble and squabble and scrabble like you're bent over a Risk gameboard during the set-up phase, when you're taking turns setting down pieces on the regions of the world you want to claim. By the time it's your move, all the powerful key positions are taken. Unless one of your party has a natural love for code, or a natural gift for art, or a natural talent for focusing and leading a group without stepping on anyone's toes, the coding will never get done and the overarching story will change at every meeting as everyone tries to squeeze in their own "what-ifs," creating utter chaotic procrastination. Make a team if you will, but unless your friends are as dedicated to learning the skills and making the project work as you are, look outside your immediate social circles.

3b. The best way to make a game is to just do it yourself. No. Actually, no with reservations. In the next few months I'll be putting together a browser-based choose-your-own-adventure piece a la the good old days. This automatically eliminates the need for art, sound or music design; the coding is minimalistic and perfect for my level of programming knowledge; the story's not too complicated; and the hosting/publishing can be provided by the company who came up with the coding script I'm using. This is an ideal size for a solo project when game design isn't your full time occupation. And there's certainly nothing stopping you from taking advantage of indie resources like the ones above or learning from scratch the skills you need to make that game a finished package, but you'll need a lot of patience and perseverance. Start with something small if it's your first attempt.

4. You don't have time to play games. This is infinitely more important! In the time I spent planning and imagining various game projects, at one point I had trouble recalling what a game actually was. But even if I didn't own Portal, I could watch walkthroughs on Youtube. Even if I only had a few minutes to kill, that was enough to play a Kongregate piece and just remember what a game is supposed to look like: different gameplay modes, atmospheric music, appropriate art (not everything has to be fancy-pants CGI), etc. I started keeping a design journal so I could remember what I liked or didn't like about the games I played. If you've never seen something, you can't mimic it, much less make any improvements on it. Don't go overboard and kid yourself that you're doing "research" as an excuse to play more games (a double-edged benefit of writing this blog), but don't neglect their value either as brainstorm resources.

 

Next time: ARG—a pirate's vocalization, as well as an acronym for a new viral species of gaming.