Alright. Over the course of this column I’ve dropped hints that the members of Coding and Concept should a) communicate, so they know where each other are, and b) pretend that an asteroid has struck the Earth in precisely the spot where the other team is, and not talk to them at all.
It turns out that about the biggest mistake you can make early on in creating your game is not understanding the dynamics of these two teams. I was planning to leave this particular column for a little bit later, but the segue from the last column was just so pretty I had to take advantage of it. So, let’s look at the teams, shall we?
Concept: These are creative people. They’re thinkers and problem solvers, and they enjoy creating things, like your game. Every concept designer in history has been underpaid, because without them doing their jobs there is no game! It doesn’t matter how pretty the engine or the graphics or music are, if there’s nothing to do with them.
Coding: These are highly intelligent people. This is not to say that coders are not creative, or that concept developers are not intelligent; the features are just more prominent in this way. The coders are the people who make the game run. If Concept is the bread, Coding is the buttery goodness. Coders are highly analytical, and tend to keep highly random hours… it doesn’t matter how I know this.
The biggest difference between the two groups is that Concept looks at the game creation in terms of “wouldn’t this be cool?” and Coding looks at it as “how can I make this work…” At first brush, this doesn’t look like anything that should make a difference; one group is coming up with ideas, and the other is figuring out how to make them work. Indeed, in an ideal system, this is exactly how things would work.
Unfortunately, especially in the game design world, there is absolutely no such thing as the ideal system. Remember the three Laws of Thermodynamics?
[*]You can’t win
[*]You can’t break even
[*]You can’t quit
Game design takes on a remarkably similar structure. People will disagree, refuse to compromise, and refuse to quit. The biggest problem with having the two groups in constant contact is something that actually started happening in my own company, when a coder began hanging out at Concept meetings. Here is what should happen in a Concept meeting, followed by what can potentially happen when a coder is present:
1. An idea is thought of. The idea is ridiculous, off-the-wall, and absolutely unimplementable. Coders have actually died while trying to get this to work. Concept, however, having no knowledge of this, does not care. They discuss the idea from every angle, and from this insane idea comes two hours of conversation, during which five other ideas are generated, all of which end up having a place in the game. The insane idea (let’s suppose it’s a sink lined in purple fur that glows in the dark and releases ginger ale) is discarded as the total and utter crack that it is, and balance is returned to the Force.
2. An idea is thought of. The idea is ridiculous, off-the-wall, and absolutely unimplementable. Coders have actually died while trying to get this to work. Before anyone can say anything, a coder pipes up and says “It is not possible to do that, no matter how many of us sacrifice our lives.” The idea is discarded without any further conversation, and five great ideas that have nothing to do with purple fur or ginger ale never see the light of day.
Believe you me, this is a very real problem that exists within these two groups of people. On their own, they can accomplish wonderful things, but the two worlds just weren’t meant to coexist in this way.
In fact, something I keep suggesting to other game developers is to keep the two departments entirely separate, because of something I said in an earlier column: the coding job does not begin until the Design Document has been finished. I’m pretty sure I said that somewhere; it seems like something I’d say.
Basically, coders can’t start working on the game until they know exactly what’s going in to it; logically they couldn’t possibly start coding it until the Design Document is finished. Oddly enough, that’s not entirely true.
While Coding can’t work on anything that will be detailed in the Design Document, there are several things that don’t require any input from Concept at all. For instance, Concept doesn’t care how users log in to the system, as long as they can do it. Concept really doesn’t care what formulae are used in the engine to calculate gravity, nor how the client communicates with the server, nor what type of database is used to store stuff.
There is a definite line between the things Coding needs to wait for, and the things Coding can do at any time. While there’s no reason for Coding to start plugging numbers in to the engine until the numbers have been finalized, there’s also no reason at all why Coding can’t be active during the design process, working on things that don’t rely on input from Concept.
Let me give you an example, from my own company’s main project. At a point in time, Concept still had six months to go before being ready to produce the Design Document. Being our first project, our Coders did not have any other games to work on. Instead of twiddling their thumbs, or going out to find a social life, they worked on the login server, physics, fire, and displaying cubes on the screen in interesting ways, creating our very own CubeZilla. The servers were coded with random data to make sure things worked, and the coders were happy.
Believe it or not, it is relevant for Concept to know what progress Coding is making in these items. Timelines are always good, and if Coding can say “we’re three months from a working engine, how far away are you?” and Concept’s answer is six months, then Concept needs to pick up the pace.
Similarly, the opposite is also true. If Concept comes to Coding and says “We’re ready for the Design Document’s first revision process,” and Coding is still five months from having a working engine, then Coding had better be very good at finding flaws. The pieces of code that do not rely on Concept must be finished by the time the first draft of the Design Document is written, or else much time will be wasted.
Coding will also sometimes request dummy numbers to plug in to the engine. If the engine is at the point where it should be able to handle skill trees, for example, Coding should request of Concept a potential number of trees to provide support for. Ideally, Concept will be able to say “we’ve already discussed this, and the number of skill trees will be ‘n’.” More likely the “will be” will be a “should be,” but either way Coding gets a useful number that could very well be the right one, and the engine gets one step closer to completion.
So just like any other relationship, the Coding/Concept relationship is one of space. Too much interaction causes problems, but a little bit is just the right amount. Down the line, when the Design Document has been completed, there is quite a lot of (heated) interaction between the two factions, but during the pre-document design process a simple messenger will do just fine.
So there you have it, the entire relationship between Concept and Coding presented in a few short paragraphs, and a handful of lists. Not a topic I was expecting to cover so early, but still some necessary background for later on. The departments being separate but still communicating will become highly relevant when we reach the completed Design Document phase of the game.
I actually get a reasonable amount of email from you, my readers, and I read each and every one. Needing some spare time, I’m going to spend the next installment answering and responding to a few of these, and then we’ll get right back in to some more design issues in the following column, when I’ve had more sleep.
Disclaimer: Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.