Behind the Curtain:
Who's Gonna Pay for all This?

By Matt "Thraka" Gilbert

"Pay no attention to the man behind the curtain!"
The Wizard, The Wizard of Oz

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.

.