By Matt "Thraka" Gilbert
attention to the man behind the curtain!"
ey, thanks for the response on the emulators, guys! Likewise, for the thoughtful comments about PC vs. console development. A number of PC programmers mentioned that they actually considered console programming easier, and cited the volumes of now outdated material they had once had to learn. Donít get me wrong, guys: I know youíre earning your money thatís for sure. We just differ on our views here of how much misery is involved in various aspects of the profession. The grass is always greener, right? There are still a few of you who sent insightful comments on this issue to whom I havenít gotten around to replying, but youíre on my list, so donít think Iím blowing you off: you know how the schedule is, right?
Contrary to my ĎNest Timeí comment last time, this is not a hack job on publishers. Thatís next issue! Okay, no, not really. The blurb was in reference to the feature creep that can plague projects without clear direction. I had intended to talk about that in this issue, but it occurred to me that a number of my readers would be a little confused when I started talking about milestones and various other aspects of working with a publisher. Therefore, in my great wisdom, I have decided to talk a little bit about the money aspect of the business, how projects are financed, and what the ground rules are. Next week, Iíll pick up the thread I dropped and we will continue down that dark tunnel. Bring a flashlight.
Whoís Gonna Pay For all of This?
"Glittering prizes and endless compromises shatter the illusions of integrity" -Rush, "Limelight"
Itís a fact of life that creative types hate rules. It is also a fact of life that bean counter types live by them. The creative fellow thinks rules cramp his style; the money guy has plenty of reasons to believe that there are specific patterns to making more money. And, finally, it is a fact of life that these two personality types must get together to make a game, even if that means the creative guy has to find some bean counting skills on his own. In the end, somebody has to pay for the work involved.
You have two choices: you can pay for the production yourself, which is not all that complicated a proposal. In fact, itís really simple: you donít get a paycheck. Get a group of your really talented, dedicated friends together and build something. Hopefully, you donít sleep, since you wonít be quitting your day job; youíre as talented as you think you are; and youíre lucky enough to convince people your product is worth buying, etc. In short, you spend a year working your ass off, living on ramen noodles and sharing a flat with your teammates, hoping this thing pans out. If it doesnít, youíve lost a year of your life. The rewards for doing this successfully can be substantial, but the risks are equally daunting. If youíre young and single, you might be inclined to try. Hey, some people spend a year being beach bums, right? Taking your best shot and missing probably wonít kill you, and you just might make it. If you think you have what it takes, go for it. But donít make the mistake of thinking there wonít be rules. Theyíll be your rules, but without them, youíre doomed. Better hope you make the right ones.
If youíre married and/or have kids, or just not willing to take the risk, trying to do this on your own is a lot less attractive. Your second choice is to get someone else to pay for it. That someone else turns out to be a publisher. Hereís the low down on how this sort of thing shakes out.
The publisher makes a living selling games; some, he may do himself, with in house development teams. Some, he contracts out. In this sort of arrangement, the publisher agrees to finance the project, and it pretty much becomes his baby, with him making the final decisions on content. Thatís not universal; people negotiate various deals, and the better the product your house has turned out previously, the more leverage you probably have. Still, itís good for a general model. I am certain I will get mail from developers saying, "hey, thatís not how it worked for us," and thatís cool; I like mail. But bare in mind this is just a general summary, and you may well have negotiated a better (or worse) deal.
Probably, you made a pitch to the publisher, and he found it interesting. You presented him with a concept, with sketches and mockups, some estimates of how long the project will take to complete, how much youíre expecting to be paid, and some breakdown of those costs. The usual deal is that the money the publisher will pay is doled out in stages, known as milestones. These milestones are plotted out in the early stages of the project, argued over, revised, argued over again, and revised again, ad infinitum. Developers always want more money up front as a cushion; publishers would always rather have more at the end to use as a carrot. Like any deal, you meet somewhere in the middle.
The developer will also have a certain royalty claim on future profits from sales, a highly variable figure. However, before the developer can claim any of these royalties, he must earn out his advances. In plain English, that means his share of the royalties must exceed the amount paid to him in milestone payments over the course of the project. If the project is wildly successful, you will wind up with less than you would have gotten if you had gone it alone, but if it bombs, you lose nothing. Projects bomb for various reasons: marketing, timeliness, content, etc. As long as the reason isnít Ďthe developer suckedí, itís not so terrible; the publisher knows that this is all a gamble, and sometimes the best ideas just donít catch on. If he thinks you did a poor job, however, youíve lost a client, and there are only so many of them to court. The moral is, donít screw up: deliver what you promised when you promised if at all possible. The corollary is not to promise what you canít deliver. The time to establish these things is now, at the beginning, when the milestones are being nailed down.
The first couple of milestones are often paperwork. You create firm game design documents, and technical design documents. These are submitted to the publisher, who, assuming youíve done it well, signs off on them, and you begin the actual creation of material.
The milestones to follow will often be separate for art and programming. In general, art milestones require that you actually have in hand the artwork that you said you would have at the time. Programming milestones center around demonstrating that the code has been written to handle various features that you are to implement. As you get further into the project, milestones begin to include playables, i.e. mini versions of the game. These will be expected to have the most current artwork and code available.
The last few milestones have specific names. They may vary a bit, but most projects end with Alpha Milestone, Beta Milestone, and Master milestone. Alpha, to most publishers, means all gameplay is complete. Some cut scenes or glue screens may still be missing, but the game is expected to be in its final, playable form. It is, of course, not expected to be bug free, either, but it is expected to be as clean as possible, with any bugs that you know about having been fixed: the publisher will not look kindly on an Alpha submission which crashes so often that it canít be evaluated. Beta is the next step: it is supposed to be feature complete, and except for the inevitable bugs that will be found, you consider the product finished. Testing goes into full tilt at Alpha, and you donít get out of Beta until itís pretty much done. Finally, there is the Master milestone. Youíve fixed all the bugs that have been found during testing, and you think your product is ready to ship. Generally, publishers have some final frenzy of testing on your Master Candidate, such as saying that it has to pass through two hundred man hours of testing with no reported bugs, or something similar; it varies. Once the candidate is accepted, youíre clear, and the publisher starts cranking out the copies. And youíd better pray to whatever gods you believe in that you remembered to get rid of that Spirit of Christmas mpeg and the pr0n pics that you were using for temp art nine months ago!
Thatís not a joke, by the way.
"Well, gee, Thrak babe, whatís the downside?" youíre asking. Simply, you sold your baby. Once you made a deal with the publisher, itís his. He has the final calls on content and direction. If youíre looking at this as a business, thatís not so bad, but no one ever looks at it like that all the time. Inevitably, youíre going to do something you think is really hip and crucial, and be pissed off when it gets axed by the publisher. Some weasel eyed, politically correct whiner is going to object to some term you used in the dialogue, and youíll be told to change it. The licensor will object to the liberties you have taken with your remix of his trademarked character, and demand it be cut.
Thatís how it goes.
Next Time: Go ahead! Make one more change!
- Matt 'Thraka' Gilbert is a console programmer, currently working at StormFront Studios. These are his own ravings, and have nothing whatsoever to do with his employer.
|Credits: Beaker's Bent logo illustrated by and is © 1999 Dan Zalkus. Behind the Curatain is © 1999 Matt Gilbert. All other content is © 1999 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't do it. And ignore the man behind the curtain. He's just got a shotgun aimed at your head...nothing to get alarmed about.|