Slashdot Mirror
On the Process of Creating a Game...
jsager asks: "Can anyone tell me the process of creating a video game? I'm not talking about technologies, but about the business. Suppose you were a small successful consulting company and have an idea for a game that you would like to try to create. How do you go about the process? Do you try for funding like any other venture? What kinds of documentation do you need before you approach a game investor (as opposed to 'regular' investors)? Do you have to finish the game first? If not, how far along do you need to be?" This is a companion Ask Slashdot to the one we did earlier on
learning to be a game designer. So, after designing that game, just what would you be getting into if you wanted to make that game a reality?
First of all, this process is what I've seen in console development, not PC games...it may very well be different.
First of all, since this is your first game, you need a lot more than if you were an established developer. If you're looking for money, that's where the publisher comes in. Warning, publishers are a different breed of people, somewhat like Music Execs. Since, again, you're new to the "game" game they'll want a lot to even speak of you. You should have at least:
1) A full game design doc. This should cover the game, it's design, it's basic functionality, as well as other key points such as style, what it will "feel" like when playing, what technology you are using, and most importantly, why it will be fun and sell LOTS of copies. If a publisher isn't impressed with this, most likely you can say goodbye. And honestly, be as buzzword compliant as you can with these, because lets face it, lots of long words DO impress suits, as sad as it sounds.
2) A game. Have your game with you, playable, and as full featured as possible. Having recently been to e3, I heard too many horror stories of people with great ideas for games, full documentation and everything, shot down. My friend on the other hand goes up to a publisher with a game they (publisher) can play, and he walked out with 3 or 4 offers from publishers to buy it. You really should have the game atleast 75% done and as "wow-worthy" as possible. Let's face it, these days tech and looks sell a game more than gameplay, and while gameplay is important, your game has to look good to be bought.
Talking with friends who try to start up game companies, or just want to sell a game they've made, this is all they had, in the past...a nice design document, and a more or less finished product, and they've had luck with finding publishers, and therefore money.
And a hint: If you're going to talk to a publisher, make sure that you get money on signing, as well as on completion, and your royalties. Money on signing is a great way to stay motivated enough to finish a game...trust me.
Having recently escaped the gaming industry with my sanity barely intact, let me tell you how you "develop a game", from a business/marketing point of view.
First off, get an idea. Doesn't even have to be good or well thought out, just have an idea that gets other people excited. Then convince a bunch of your friends to come work with you on it, all on their spare time, of course. Develop a presentation proposal. How far you want to go is up to you. You can take it as far as a very descriptive design document with artwork, or a working prototype.
Now you decide if you want to become a slut or a whore. If you want to become a slut, you will go around to a lot of sleezy people trying to raise funds, get marketing contracts, etc. This is a lot of hard work, and a very chancy proposition.
If you want to become a whore, which is easier, you sell your game proposal to a publisher. If you're lucky, one of these publishers will like your game idea and give you a pot of money and a contract. If you look at the fine print, you will see you've sold your body, soul and first born for the next three generations. Invariably, you give up some to all of your creative control (depending on how good a negotiator you are), agree to ridiculous schedules and features and agree that in exchange for this nice pot of money up front, you won't see a dime in royalties unless the game becomes a f---ing big hit. The publisher takes care of publishing the box/CD, marketing and distribution. Also, the publisher is the one taking the financial risk, not you.
So now, you've got a pot of money, with promises of more if you can hit those milestones every month, your team and your game idea. Now you can form a company. If you're smart, you find a low-rent office that's not that trendy (looks like something from Dilbert, say) with basic amenities (like a fridge, water and coffee maker). You and your friends then buy appropriately priced hardware and furnishings and spend your days working on the game.
Now if you're dumb, which would include almost all of you fools who want to go into game development, you'll find a trendy office in a renovated industrial part of town with a cost per square foot that makes a downtown penthouse look cheap. You'll then spend most of your money creating the "coolest place to work ever with free pop!" You and your friends will come up with some fucked-up ideas on how to run a company (let's all go to Episode I two days before a major milestone! YAAAAY!). The technical architecture of the game will look elegant and amazing on paper; the art design and direction looks promising. You start hiring people like crazy by either paying over-market for experienced people or under-market for inexperienced fresh-out-of-school graduates then let them at it.
If you were smart, the next 6 months are quite fun. You and your friends work long hours, but have a good time with each other. Sure, the office is a little drab, but it encourages each of you to go home and have a life. You come back the next day refreshed and able to solve those hard bugs.
You chose simple, workable solutions over over-engineered work of art solutions. Your artists are all capable, creative people who really want to do good work and you appreciate them. Your programmers work very hard to create tools that support those artists and what they really want to do. You buy off-the-shelf tools and libraries rather than write your own. Your architecture is data oriented, not code oriented, so you can create tools that let the game designers and artists directly build their worlds and test out game designs. Sort of like how Doom, Quake and Unreal work.
You have the weird notion of hiring game testers early and having them intimately involved in QA and game design feedback. By having an engine, it simplifies the coding work so you can spend more time making sure your code works. You also save optimization until after the bulk of your game architecture is in place. Game logic changes are easy to implement with the engine scripting language enabling you to experiment with alternate ideas. You set realistic goals for each milestone and hit them on time. The milestone money seems to last till the next one. You buy a fooz-ball table.
If you were dumb, you find you're running out of money before your first milestone hits, that elegant technical architecture has turned into a white elephant. The artists never really got the idea and have created something else you didn't want so you yell at them, they go back and produce crappier and crappier art no matter how loudly you humiliate or degrade them. The experienced programmers sit on their butts all day playing Quake occasionally doing 4 hours work around midnight. Oh, on occasion they will do an all nighter, but after the deadline, it's back to Quake. The inexperienced programmers are introducing more bugs than they are fixing and their output is not "state of the art". The art is the wrong size, format, color for the game, but you've hard-coded all your parameters so you have to go in by hand to re-write pieces of code, change constants, re-compile, test, go back to the artists, etc.
An artist accidentally adds an extra vertex to a polygon and it crashes your game. Don't laugh; this happens. Everyone works insane hours as the Milestone deadline approaches. You burn and burn CD's and you test and test, but you keep finding bugs, or the bugs you thought you fixed came back, or they were never fixed in the first place. ARGH! Midnight comes and goes, and as per your contract, you loose half the promised money. You then work for another two weeks just to achieve the goals you promised 6 months ago, but find you promised too much. You finally get a semi-working version and send it into the publishers. You last payroll bounced, so you desperately need the money.
As the game progresses, all your code is custom. One of the programmers complained he didn't like the CD code for Windows so he's now writing his own. A junior programmer is trying to figure out how to create a custom movie player format for your game, and how to convert AVI's to this new format. Your experienced programmer swore to you the two weeks spent optimizing the vertex transform engine will double the frame rate. Instead, it drops from 15 fps to 12 fps everytime someone sneezes. You test this, and find it's true.
Your testers complain the game isn't that fun to play, but you ignore them because they still haven't found out why the sound is skipping during Quizle's leap from tree to tree. One of your programmers quits for health reasons, another for "family" reasons. They controlled vital sections of the project, so you assign to junior programmers to their old positions. Your money is running out faster now. You sell your fooz-ball table to the game company down the street.
The year is up. If you were smart, your game still has some playability issues and bugs, but it's only 2-months extra work. Your publisher has no problems giving you the time and money because the game looks so good and you've proven you were responsible enough to deserve it. Sure, it's a lot of work, but everyone's happy. The game is fun to play, no one's burnt out or snapping at each other. You ship it out, and it's better than you expected. The game testers gave you great ideas. The data-oriented and engine based architecture allowed you to radically change elements of the game without a huge overhead in re-programming. The game sells a 100,000 units and you're comfortably well-off.
If you were dumb, the game ships out a year after it was due. You've missed payroll so many times, you can't remember if this paycheck is for the missed 3rd or 6th paycheck. You've had to cut back on the free pop. You've laid off staff. Moral is low. The game looks terrible and is unplayable, but you ship anyhow. You get savaged in the media, and made fun of on the game sites. The publisher pays you your last installment knowing that's the last money you'll ever get for this game. Two weeks later, you walk into EB and see it in the remaindered bin for $5. You never got a copy of the game yourself, but you think $5 is too much for it anyhow.
That's how you do it, Sparky. Don't say I didn't warn you.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
- Budgeting and Scheduling
- Go here and punch in "Post Mortem"... they contain a lot of useful info about starting up.
- Creating a Design Doc... there are tonnes more like this there.
- Creating a business plan
- And finally the one you probably really want: Birth of a Game Studio
and it just goes on and on and on. GamaSutra is your friend.Ryan T. Sammartino
Ryan T. Sammartino
"Ancora imparo"