Hello Mr. Shane… I’m calling to propose a computer game to you… Yes, well it’s a fantasy RPG with revolutionary gameplay technology and an entirely new map structure, and it’s… Yes… No, I can’t…
This is one end of a mythical telephone conversation that has probably happened, in one form or another, countless times in the past. It began with the best of intentions, providing some game mogul with a new game to develop, and ended in total rejection without the publisher even hearing about the game. So what was the other side of this fictitious conversation?
Hello… Alright, can you tell me about it?… I take it you’re confident about this game… Can you give me something to read quickly about it?… Do you have a demo you can show me?… I’m afraid I can’t help you.
To be honest, this is a very optimistic conversation that probably wouldn’t happen under the best of circumstances; it’s far more likely a budding designer would be turned away after saying hello, as most game developers are far too busy to spend time on the phone discussing a game they know nothing about. If all you have is an idea, you’re not going to get very far.
As you know from reading the last six issues of this column, it takes more than just brilliant ideas to create a computer game. Over the past 18 weeks I’ve told you about money, people, design and code, without really getting in to the guts of anything. Starting with this column I’m going to tackle different aspects of game creation in roughly the order they’re likely to occur, starting with the documents.
So why am I talking about documents first and not money or people? Because the odds are that you’re going to start coming up with the game on your own, or with friends who will help for free because they share your love of gaming. You don’t really need large amounts of money until you have something cohesive with which to get it. It’s like a catch-22, only without the blue cover; you need money to make the game, but you need the game to get the money.
Back in column 4 I talked about the Design Document. In column 5 I talked about the Technical Document. This time, I’m going to discuss the Design Treatment, or “Sell Document”. This is the third document I was talking about at the end of the last column, and it might be the most important of the three.
In 1999, when Peter Jackson was casting Frodo for his Lord of the Rings trilogy, Elijah Wood decided he’d do whatever it took to get the role. He made some phone calls, and spent some money to make an audition tape as a Hobbit. This was Elijah Wood selling himself for the role. His audition tape was his Sell Document, to get Peter Jackson to invest in him. Similarly, if you want anyone to invest time or money in your game, it needs a Sell Document.
The Sell Document is what you show your potential investors and publishers. It’s what proves you’re serious about making your game, and that their time and money will not be wasted. You’re trying to convince them that you and your team know how to make this game, and that it will earn money after it’s launched.
So what goes in this document? About 5-10 pages of summary. The content varies depending on what type of game you’re making. An MMORPG includes many concepts and ideas that a game like Space Quest simply doesn’t have. As a minimum, it should have the following (based on a list found in Developing Online Games: An Insider’s Guide by Jessica Mulligan and Bridgette Patrovsky):
Genre: Is it fantasy? Science-fiction? A race to blow up the centre of the Earth?
Engine: Are you creating a new engine, re-using an existing one, or licensing one from, say, Quake?
Database: Are you using Oracle, mySQL, or creating your own? Do you need a database at all?
Audience: Who are you trying to addict? Hardcore or casual gamers? Under 20 or over 65? Male, female, or other?
World: Are you licensing an existing world, like Star Wars, or are you creating your own?
Graphical content: What will the game actually look like? Anime, photorealistic? 2D, 3D or 4D? Can you choose? Does the game require a graphic accelerator card?
Interface style: What user views will be available? This one’s less than intuitive, so here’s an example: An interface description for Diablo II might read: “A full-screen God’s-eye view with the player’s character centred, with full mouse control and user-configurable keyboard control.” …it’s not a very good interface description, but hopefully it gets the point across.
Platform: What Operating Systems are you designing the game for? What OSs do you plan to port your game to in the future? Will you support console gaming, especially since the PlayStation2 and Xbox are both online in a big way? If it’s an online game that people connect to, what’s the host platform?
Gameplay experience: What will the user do while in your game? This is where you get to describe the gameplay and player interface elements, how they will work together, and what will make your game stand out from the crowd.
Competition: Who else is making a game similar to yours? What makes you think you can compete with them? How much money are the other games making, and why will your game put that to shame?
Staff and qualifications: How many people will you need, when will you need them, and what will they need to do?
Core design team: What small group of people are in charge of everyone else, and why are they the right people for the job? There are usually six names and positions attached to this list:
[*]Producer/Project Manager: The (wo)man in charge. This is the person who keeps everyone else doing what they’re supposed to be doing.
[*]Lead Programmer: The codemonkey all the other codemonkeys throw bananas at in hopes of getting a raise.
[*]Lead Server/Network Engineer: The person in charge of making sure the network lines don’t explode. If you’re not doing an online game, you may be able to leave this one out, depending how your game works.
[*]Lead Database Designer/Administrator: The person who decides how data gets stored and accessed, and who sleeps in the office in case something goes wrong.
[*]Art Director: The person who auditions concept art and animations. Sound and music often fall in to this category as well. Take it from me, it’s harder than it sounds.
[*]Lead Designer: The person who heads up the concept team, and makes sure things like sinks lined in purple fur don’t make it in to the game.
Schedule: What do you think the development and testing schedule will look like? This will probably not end up being even close to accurate, as there are very few games that launch within six months of their projected release date with even 75% of the intended feature set. The reason you include this is that executives like being able to run figures on when they’ll get their money back, so you need to stick something semi-reasonable in here. If you’re smart, you’ll add at least six months to any estimate you offer.
Budget: What will it actually cost to make your game? At the very least, you want to include salaries, and software and hardware costs through the entire creation process. If you’re designing a game that must be supported after launch, like an MMORPG, you also need to add launch costs that take in to consideration things like server hardware, bandwidth, and network costs. If you can make a reasonable estimate at the player/Customer Service costs, do this too. You don’t have to worry about marketing costs, as that’s both not your current concern, and almost certain to change by the time your game is released. As you’ll recall from column 1, the first version of Shadowbane was dropped when the executives found out how much it would cost to launch and support an online world. Don’t be surprised if your calculations run you up over ten million dollars.
Even if you only plan to work on the game yourself, and release it online for free, this is a very good document to write. It will let you look at a few pages to see what you want to do with your game, without having to go through the detailed Design Document. It will also give you an ego boost to see your name in all six important positions of the design group. Now that you’ve encapsulated your entire game in to ten pages, next column we’ll start talking about the design process itself.
[B]Disclaimer:[/B] 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.]]> Related to this article