I’ll be honest, when people ask me what it is I do for a living, I take a small amount of pleasure in seeing their response when I say: “I make video games and teach game design”. Even though it is 2015, I still – more often than not – get the look from someone like my career is akin to what the people in the below video do. This is most likely due to their lack of understanding behind the process behind game dev, and not necessarily the lack of respect for the medium (although the two can be connected, of course).
Game development is very similar to any other field of design or development – there is a problem or challenge put in front of the designer, and it is their job to solve that issue in the most efficient and interesting (and in my case, aesthetically pleasing) way. People do it everyday. Product Designers make objects. Architects make spaces. Graphic Designers make images. Engineers make bridges. Game Designers make experiences. Some of those experiences can be profound and life-changing, while others are as shallow as the money it earns is deep.
I frankly don’t know where my game stands on that spectrum I outlined above, but I’d like to think it leans closer to the profound than the profitable. The challenge I gave myself was fairly straightforward: I wanted to design an experience that incorporated my interests in history and the environment into a digital 3D world that could be experienced by nearly anyone (including the 6-year old digital native that is my daughter, the 20-year old twitch-gamer that is my student, and the 70 year old tech-challenged person that is my mother). While it might be straightforward, it isn’t necessarily an easy “I can design that sucker in a day” sort of project. This was going to take time, and I discovered that it was going to take more and more time the further I dove into the research, ideation, and game engine.
With this in mind, I wanted to outline a few key stages I went through in the beginning (and still am returning to), as a way to explain my process a bit better. None of these are inventions by myself or new elements to the game dev world – in fact, one would probably be hard pressed to find a single successful game without these elements embedded into its process, so for any experienced game designers out there reading this, I hope you’ll be patient during this primer.
The Game Design Document
Simply put, every game needs some sort of game design document (GDD or design doc for short). Some take the form of wikis, others a google doc, others a pile of papers, while others are through a slideshow/PDF. This doc is essentially the “manual” for the developer(s) to reference and use throughout the process. Due to a game being so freakin’ huge and bridging across so many disciplines, this document is literally the 10 (plus a few hundred more) commandments brought down from the mountain (and heaven help the person who decides to stray from those commandments!). This doc includes objectives, mechanics, narratives, level layout, game flow, playtesting, sound info, and dozens of other things pertinent to the game’s functionality and playability. To use one more analogy – this document literally is the blueprint for the entire game. The more you can solidify this document in the beginning, the less likely there will be issues like crunch, communication breakdown, or feature creep, later on.
I decided to go with a powerpoint/google slideshow for my design doc, so that I could rearrange the doc easily, integrate a large amount of media, and have it easily transfer into a pitch doc when speaking with others about my game. In what started out as a relatively thin manual, my design doc grew into quite a large digital tome. Perhaps this was due to my academic background of insisting on references and footnotes, or my artistic side wanting to see big, beautiful images throughout the doc. Regardless, I’ve been able to cull it down to about 70 slides now, which feels like a good number. While the initial work went into putting it together last summer during my Pine Needles residency, I’ve spent time over this past year refining it, largely based on the research and playtesting I’ve been conducting.
Map Making & Level Design
If one’s goal is to create an environment for a player to explore, a birds-eye view map to visualize that overall experience is probably a good way to start. I have two environments to explore in Tombeaux (and the player continually returns to both of them): an outdoor river level and an interior cabin level. While I went through a bunch of different iterations, I decided to move in to 3D with two sketches I had made early in the process.
I was aware that my vision might be larger than what was possible for making this game, so you can see that I immediately sliced off about a quarter of the cabin interior space (above), as I know that virtual spaces always feel larger than they actually are in the engine. While you can’t necessarily see it in the river map, I also ended up squashing down that entire level too, to make the overall exploration area like that of a square shape, rather than a tall rectangle like it is below.
From this point, it was time to jump into the game engine to get a feel for the virtual space I had envisioned. Using my maps as blueprints, I dropped down various boxes and other primitive 3D shapes, so that I might begin exploring the pixelated, lo-poly beginnings of the world of Tombeaux. Normally, this is called grey-boxing, and while I basically did that, I went a bit further with some shapes, as well as colors and shaders, so that I could begin to envision sillhouettes and color palettes into the game (which quickly became much more muted and less Minecraft-y, after seeing them in engine!).
It’s my opinion that one of the biggest mistakes that game developers make is that they push playtesting back too late in the pipeline. Picture this: near the end of the game development process, your game is like a giant, 15-ft tall snowball careening down a mountain at 250 MPH. It is a lot easier to stop that snowball and rebuild it when it is near the top of the mountain, before it has gotten too big or started going too fast. Playtesters – people who aren’t associated with your game who could play it and provide you with some feedback – will help you avoid those last-minute snowball messes.
I’m a firm believer in playtesting your game from day one, which means you must have outside people play your game. From those first playtest sessions, I learned about how to change the levels, tweak controls, reconfigure narrative, and even slightly change the direction of the game’s objective. Those first two weeks of playtests were crucial to a smoother development pipeline down the road (and a big thanks to Emily, Josh, Simon, Amy, and Mitch for your help!). I’ll return to speak more about playtesting in a later post, in which I’ll dive into my reasoning, inspiration, and approach to the playtesting process.
Hopefully these short summaries about specific elements in my process have helped you grasp a bit more about the game dev process. Before one can start actually playing the game as it was meant to be played, there is a great deal of research, design, iteration, and testing involved (not to mention all of the coding and art!). If only it was as easy as those guys said earlier, and I could just “tighten up the graphics a little bit” – but what’s the challenge in that? 😉