Shifting Priorities

This post is copied from its original publishing in the A.V. Development Blog (http://devblog.avthegame.com/).

Though I know this isn’t really the place for this sort of thing, I would be remiss in my duties if I didn’t mention that A.V. is currently running a Kickstarter campaign.  So I’ll mention that A.V. is currently running a Kickstarter campaign.  Please stop by and at least give us a look. (https://www.kickstarter.com/projects/378545559/av)
or tiny.cc/av_kickstarter

Thank you.  That is all.  Normal service will now resume.

The Way of Things

I’m very pleased to have grown up in an age when I could earn a college degree in game development.  Two of them, in fact.  The fact that game development exists as an academic curriculum is immensely satisfying.  If the traditionalists had had their way, I would have become a scientist.  Instead, I’m in the business of entertainment.  Take that, progress!

The trouble with an industry like game development being an academic curriculum, though, is that academic curricula tend to be focused on establishing conventions and standards.  After all, if you want to teach people how a system works, you need to have a clean example of what that system is.  Game development isn’t quite so clear-cut.

My education, for instance, made me aware of the numerous business models and methodologies that game development can follow.  Waterfall follows a different style and scheduling system than SCRUM.  But in the midst of this, there are supposed to be commonalities as to the definition of what constitutes a game’s Alpha version, or a Beta, or a Gold Master.

Prototype: Display the game’s core mechanic.

Alpha: A version featuring the preliminary layout of the full game structure from beginning to end.  Levels are boxed or filled with placeholder art.  Core mechanics are in place, along with any features necessary for completion of the game.

Beta: An asset-complete version of the full game.  All final game artwork and sound is in place.  All design mechanics are laid out in a functional form.  The game world is complete.

Gold Master: All mechanics are fully-functional and inefficient or incomplete code has been cleaned up.  The game is in its fully-completed, sales-ready form.

Post-Release: Additional material, such as DLC or patches, is released to further enhance the original game experience.  Also, you’re rolling around in gigantic piles of money.  This is what the "Gold" in "Gold Master" means.

Using the System

To that end, I’ve always tried to look at a schedule, no matter how open, in terms of how each of these states can be reached.  “Okay…we need to have all of our art assets in the game by the Beta…because that’s what a Beta is.  When do all of the art assets need to be completed?  When do they need to be in the game?  When do we need to work out the exact pipeline for putting them into the game?  When do we need to realize that everything in the art pipeline is going horribly wrong?”

If you always make the same type of game, this process can work pretty well.  However, from what I’ve been able to work out, most developers don’t operate under the hope that they’ll spend their whole lives making the same game over and over again so they’ll have an easy time with scheduling.  Rather, people like to work on something new and exciting.  The problem with a new and exciting project is that it’s…well…new.  It carries a different set of requirements than the project before it, and a different ordering of priorities needs to be considered in order to make the game as complete as possible.  This is especially tricky in the sort of clever, genre-bending indie games I’ve heard the kids talk about so much these days.

What, for example, goes into a prototype?  It’s supposed to be a piece of the game you want to make – a representative for the larger product.  A stranger should look at the prototype and say, “Ah, yes…I appreciate the entertainment value of this product.  I would be inclined to invest monetary units into the development and/or playing of the larger product upon which this work is representative.”  Or something along those lines.  Generally, you should hope for something a bit more enthusiastic.

Putting It into Practice

Okay.  Good.  So how do you actually make people say that?  Do you fill it with pre-existing placeholder art and focus on programming a mock-up of your core mechanic?  Do you design a really clever world, build it out of primitives, and use pre-existing scripts that only allow you to move around?  Do you make some customized art assets and particle effects to sell the environment, then go bare-bones with everything else?  Keep in mind, you don’t have long to do it.

It’s a question of what really “makes” your game.  If your game is largely about indulging in the epicness or quirkiness of the game world, the game’s art will be extremely important in selling that concept.  If your game is built around a new mechanic that no one has seen before, a correctly-designed test level and precisely-programmed actions and responses will take precedence in demonstrating the fun factor.  If you’re working on a follow-up to last year’s big online FPS war game, you’ll want to show that the system no longer boots you off the server if your name starts with “J”.

In developing A.V., we found ourselves running across a similar problem.  According to what I’d been taught in years past, the development process was supposed to look something like this:

Ideas -> Concept/Pitch -> Documentation -> Box Out Levels -> Test Core Mechanic -> Add More Mechanics -> Add Art Assets -> Clean Up -> Profit

This is the basic structure we initially tried to work from.  Very simple.  Very functional.  Easy to follow.  Okay, so we threw our ideas at the wall.  We came up with a concept and started to document it.  And around the same time, we started the prototype.  That’s when it became clear that things were going to have to be a little bit different.  Our structure has been a bit more like this:

Treachery and Lies -> Ideas -> Concept -> Sketch Levels -> Pitch -> Concept -> Pitch -> Documentation -> Sketch Levels -> Make Scripts Do -> Make Art Assets -> Make Level -> Make Scripts Do -> Make Art Assets -> Make Tutorial -> Hate Everyone -> Make Tutorial -> Make Tutorial -> Success! -> Make Level -> Fix Scripts -> Make Art Assets -> Make Level -> Stop Everything to Make Kickstarter -> … -> Profit??

Breaking the Process

The problem lies in the nature of the concept itself.  A.V. is a game concept built around an overall experience – being part of a musically-based computer world in which you can only interpret your world through the use of sound.  The mood and feel of the game are its key selling points.  Getting the correct mood across is dependent on capturing the right art style, the right sound effects, and on generating a successful musical structure in the game’s actions. 

At this stage, design and programming resources would normally be coming together to determine the best statistics to be associated with player actions.  How far and high do we want the player to be able to jump?  What does this upgrade need to do, and how can we implement it?  In our case, those elements had to become side thoughts and new priorities came in to take their place.

Since the core of the gameplay was focused around the idea that the player could only “see” sound, it was important to make sure the player realized the correlation between sound and the amount of light generated in the game.  First priority, therefore, went towards finding a good way to synchronize sound and light.  After all, if the player is supposed to be seeing sound, the game’s visual elements need to be based around the game’s audible components.  Otherwise, you just have a bunch of lights that simply happen to be near objects that make noise.  Synchronizing light intensity to the game’s audio doesn’t necessarily guarantee that the player makes that connection, but it goes a long way.

Another priority arises from the game’s focus not just on sound, but specifically, music.  Every action within the game that produces sound is supposed to tie together to form a component in a musical track.  This means that, a.) sound effects need to have a musical quality, b.) game sound effects need to synchronize with a master tempo, and c.) on that note, game actions also need to synchronize with a master tempo.  Incidentally, there’s also point d.) do we know anyone who knows anything about composing music?

Because this issue clashes with other, more basic game design, art, and programming concerns, it wasn’t able to be resolved all at once.  It’s been popping up again and again throughout the development process.  It’s not until now that all of the different pieces of this issue have begun to come together.  As a result, the feel of the game is finally starting to coalesce.  There’s still a way to go with the music and sound effects, but with the main “musical” systems coming into play, the game is finally starting to achieve the feel envisioned by the core concept.

The trade-off for this, of course, has been the time taken away from refining the design and execution of actual game mechanics.  Some systems aren’t yet as clear as they could be, many assets still aren’t in place, and a number of scripts aren’t as clear-cut and efficient as they should be.  But for us, it’s been a question of where to focus our time.  What’s the most important element of the game experience?  Is it the act of playing the game, or the act of living within the game world?  We’ve been jumping back and forth between these two priorities a bit, but ultimately, our preference has clearly been for the latter.

Well, actually, right now, our focus isn’t on either of those.  We’ve got a Kickstarter to run.

Doing Whatever Works

Ideally, none of these issues should clash with each other.  If you’re dealing with a large enough team, you’ll have a squadron of engineers to deal with different coding priorities, a small cadre of game and level designers to make sure the game is laid out correctly, a battalion of artists to pump out assets, and a token force of producers out there winning the hearts and minds of the public, leaving the creative, artistic, and technical directors to maintain the overall mood and vision for the game.  But when you’re stuck with just two full-time developers, it quickly becomes clear just how much prioritizing has to be done.  That’s where you start to realize the importance of those questions about “what makes your game your game.”

Even in the larger team settings, these are key questions to be asking right from the beginning.  Knowing the key takeaway of the game helps you to know your priorities, and knowing your priorities helps you to better organize the whole development process, which makes it more and more likely that those priorities will actually be met.  I hate to sound boring about it.

The real point, though, is that unless you’re working on a fastidiously-maintained franchise or you’re making the same sort of game over and over again, you can’t really operate under the assumption that the development cycle should be structured the same way for each project.  Whatever milestones you put in place need to be based around what you want the world to see.  What I’d like to do is come up with alternate, more generalized definitions for what entails an Alpha, Beta, or Gold Master, but given the amount of variability in play here, it’s not a simple task.  Here’s the closest I can come:

Prototype: Here’s the key selling point of our game.

Alpha: Here’s our key selling point, but now placed within a larger context of a game world.

Beta: Here’s a more or less complete vision of our main selling point, along with the other key mechanics associated with it.  Here’s how the game world ties together with the core concepts.

Gold: Here’s the completed vision for our game world and design concepts.  Our main selling point is now so integrated with the game world that we’ve created a new reality for you to engage in.

How your game is built should be based on how you want your game to be presented to the world.  What you should present depends on the type of game you’re creating.  As for what type of game you’re creating, that’s up to you.

But this is all coming from some indie developer off in the wastelands of Upstate New York.  Really, what do I know?