Home Tom's Sailboat Tom's Clan

October 27, 2005

A Case for Flexible Milestone Deliverables

Filed under: Game Law Articles — Tom B @ 3:51 pm

“Milestone Deliverables” are interim and final assets delivered to a video game publisher by the developer throughout the term of the development agreement. The approval of the “Milestone Deliverables” by the publisher triggers the payment of “Advances” that fund the ongoing development process. These milestone deliverables are defined in the publisher/developer agreement, often in minute detail. My latest ‘Game Law’ article for Gamasutra addresses the fallacy of detailed “Static Milestone Deliverables” and discusses a preferred methodology involving “Flexible Milestone Deliverables.”

“I hear you know how to make games… here’s $5 million - make me some!”

As the stories go, in the wild and wooly early days of the video game industry, developers were funded by publishers via the delivery of rather large checks. These funds were dispersed solely on the developer’s representation that they could actually make games. Sadly, publishers eventually realized that they needed some form of control over the developer, or there would be no way to assure that the publisher would ever receive a game for their investment. So, milestones were born. Instead of a single check to pay for the entire game, the funds were delivered over time, with the developer being required to show the publisher that progress was being made on the development of the game.

At first, a few milestones with general descriptions were given, such as, 1.) the signing of the contract, 2.) a playable alpha, 3.) fully completed beta, and 4.) delivery of the gold master. Except for the first milestone, each of these deliverables would have to be accepted by the publisher before the correlative advance payment was made to the developer to continue the funding of the development of the game.

As this milestone process evolved, publishers began to add more milestones into their contracts and put more detail into each milestone to better manage the process and reduce their perceived economic risk. Often, the details of the deliverable were derived from the design document supplied by the developer. As deliverables became more and more defined, developers became less and less likely to meet them as required under their agreements. Eventually, “Milestone Deliverables” became a running joke in many studios, because as long as the publisher was satisfied with the actual progress of the game, compliance to the details of what the contract defined “Deliverables” was, in practice, not much of an issue. But it should be.

Feature Creep, New Technologies, Iteration vs. Static Deliverables

The simple reality is that things change throughout the development process. Even the best planned development cycles do not go as expected. Of course, the creative process in developing games gives a solid justification to this fact. After all, games are the result of a creative process and often rely on emerging technologies. They are also the product of a group effort with many cross dependant assets. This already complex process is complicated further by the fact that developers and publishers often attempt to define all the deliverables over a 24-30 month project before the project has even begun based on a design document. Then new technologies emerge, designs change (hopefully for the better), and cross dependent elements fall off track because other parts of the game are simply more difficult to implement that anticipated.

Quite frankly, some times developers pitch games too zealously and end up over-promising in the process. All of these complications, and more, end up with developers making commitments to milestone deliverables that they can not and do not keep. And most developers and publishers know this fact when they sign their contracts.

“Developer is in default from Milestone 2, or maybe 3…?”

There is an inherent risk to the developer in this process. It puts the developer in technical default under the contract because of a failure to provide the deliverables called for in the contract. As a result the publisher can terminate the contract “for cause” at any time, rather than exercising the “for convenience” termination. Under these contracts, a “for cause” termination is inevitably less advantageous to the developer than a “for convenience” termination. A “for convenience” termination often requires the publisher to pay out a portion of the remaining advances to get out of the contract where the “for cause” termination does not. No developer should put itself in a position where it is in breach of contract within a few months of signing with their publisher.

As you probably know, certain elements in the asset pipeline are expected to occur at certain points, and certain elements are necessarily dependant on the pre-existence of other elements. Other elements are completely independent and due to personnel issues, allocation of resources, or a myriad of other things that may not occur exactly when you anticipate. These matters often result in an actual delivery schedule that does not even vaguely resemble the milestone deliverable schedule in the contract.

Just like when milestones were first implemented to accommodate an evolving industry, as our industry matures we need to find ways to accommodate this disparity. This is not just because of the unreliability of the deliverable schedule, but because great games require iteration. And iteration cannot be written into a hard milestone deliverable schedule. Most importantly, milestone deliverables need to reflect what is actually occurring in practice. The inclusion of flexible milestone deliverables in the contract recognizes these facts, builds this flexibility into the contract to create a more organic relationship throughout the development process.

A Fixable, Flexible Solution?

Here is how it works. The initial milestone deliverable is, of course, defined. That’s easy, as it is usually the signing of the contract itself. The next full deliverable in the contract is also fairly simple and straight-forward in that it is invariably based on the first iteration of the existing project, whether it is a partially completed game, proof of concept or technology demo or even a completed design document. From there on, the publisher and developer agree to confer periodically throughout the development of the game to set the deliverables. In this manner flexible deliverables allow the developer and the publisher to continue to write the specifications for each deliverable based on the prior deliverable. So, the second deliverable is based on what was delivered in the first deliverable. The third deliverable on what was delivered in the second, the fourth on the third and so on.

In addition, if there is a departure from the original design that requires substantial additional work by the developer; the developer has the opportunity to “up-sell” the publisher. Then modifications can be negotiated to the advances due under the contract to facilitate additional funding to compensate the developer for approved additions to the game. That way, the additional enhancements are not done at the developer’s expense. They can be factored into the deliverable and also added into the advanced payments that accompany it. Of course, this process does require a close working relationship between the publisher and the developer. But the benefits to both are well worth the effort.

Conclusion

So, while some of the best developer war stories come out of discussions regarding the difference between the deliverable and ‘the deliverable,’ meaning, the deliverable in the contract and the deliverable delivered, this is really no laughing matter. Often with static deliverables, the developer finds itself dependant upon the good graces of the publisher to accept a deliverable that in no way resembles what is called for by the contract. It is hardly a decent position to be in when the advances tied to those deliverables could mean life or death to your company. It is bad enough when there are a few items missing from the list of deliverables in the first few milestones.

However, the problem exacerbates exponentially as the project moves from milestone to milestone, due to the interdependency that naturally exists among the deliverables. So, let’s make the deliverables in the contract match the deliverables in practice. Sure, there will be fewer war stories to tell. But it will be better for everyone involved, both developer and publisher. After all, static milestone deliverables have been a joke in the industry for years and it is time we stop laughing and started doing something about it.

______________________________________________________

October 26, 2005

Whew….

Filed under: Thoughts and Rants — Tom B @ 12:48 pm

W I L M A ! ! ! ! Fred Flintstone’s voice is ringing in my mind.

It sure is sobering to have your house shaken to the rafters and see cars and tress tossed around like a kids toys. And electricity. Man oh man…is that something we take for granted. So, it’s Wednesday and I have been without power since early Monday morning at home. And even the Cingular network is AFU. So, no GPRS access to my email through my good ole PocketPC. But we still have analog via the telephone. Of course my beast of a portable graphics workstation I use to show off my client’s games has a battery life of about 40 minutes. So, trying to get through the volume of email (and spam) I get every day is not something I can do more that once or twice a day.

Fortunately, I have power and internet access here at the office. So all I need do it wind my way through the debris to get here to check my email and do my usual internet stuff. And to be honest, we are having our first cold front of the season with temperatures in the mid 70’s days and down into the 60’s at night. So, the lack of power is bearable and it’s even sort of fun to be making all our meals on the propane grill, and being away from the day to day din that modern life has become. So, I spent a few days playing with my chainsaw and packing away some of my own wood for future projects on my lathe. Having the doors open and actually talking to my neighbors. It ain’t so bad after all….

October 17, 2005

Why is “union” a dirty word?

Filed under: Thoughts and Rants — Tom B @ 8:14 am

Among the many forums and mail lists I subscribe to is the IGDA Quality of Live Committee list (QoL). Since I have a background in employment law as well as game stuff, it was a natural. I presented last year as the IGDA think tank at GDC and have been interviewed frequently for comment on everything from the EA class action suit to employee exploitation in the game industry. And one thing I have noticed…people who work in the game industry think that unions are a “bad” thing.

Sure unions can and do become as corrupt as any other institution in American society. But certainly they are no more corrupt than say your average municipal government. And they certainly did not begin as corrupt organizations. That only happens when the rank and file lose interest and allow others to take over their union. After all, unions are run by their members through a group of elected representatives.

But no one argues that all of the line employees in a company can’t negotiate better working conditions that individual employees can. Of course they can. So, organizing would get a good result. Better working conditions, vacation time, health and retirement benefits, even profit sharing are just a few benefits that collective bargaining could get for employees. So, I gotta wonder…why is there so much hostility toward even discussing the idea of some of the bigger studios becoming union shops?

I have a few ideas…possibly it is snoberism. Being in a union is considered working class and most developers consider themselves to be “above” that. Though it is difficult for me to see much of a difference between making chevies on an assembly line and making Madden 2007 on an assembly line. Sure I get it for small creative teams. But not for a line workers and they are the ones getting screwed the most, with the least power, at a time in their careers when they are most vulnerable.

Too bad that senior developers don’t take a bit more responsibility for those on the lower tiers of the industry. I suspect that if Will Wright asked management at EA to please treat those working on his SIMS games a little better, EA would do it. Especially if Will said that if they did not he’d take his next game to Midway!

October 8, 2005

Coolaid anyone?

Filed under: Thoughts and Rants — Tom B @ 1:28 pm

Well here I am at the Indie Game Con in Eugene Oregon. Home of the indie games poster child and facilitator catalyst Garage Games. The place where the last of the hard core independents gather to commiserate and execute their plans of world domination from outside the system through ingenuity and alternative distribution models. I come here every year to preach the “Game Attorney” gospel to the congregation.

And what am I doing right now you ask… sitting in the main conference area leaning against a table that has a half dozen X-Box 360s - fully functional, and listening to a Microsoft X-Box evangelist preaching X-Box Arcade as a solid viable portal for independent games. Wow this is great…or…run for your lives it’s a Borg invasion!!! Well it is probably a little of both. Certainly for those indies making relatively small footprint it will mean access to a relatively huge installed user base. At launch the installed base will be small…but the opportunity will be there. Certification remains an issue and I’ll try to make sure that I teach the submission process so that I can help “my people” through the process.

As for the whole “cool aid” thing. Well if we want to make a living at this stuff we will have to make some compromises. Maybe it will work. Though access to the channel will be very limited for the first year at least. And after that…well - We’ll see. Talk is cheap and the proof is in the pudding.

October 2, 2005

I feel like a hot blond at the singles bar…

Filed under: Thoughts and Rants — Tom B @ 10:43 pm

Well, maybe not like a Hot Blond at the Bar, but certainly desirable. You see over th e past few weeks I have been contacted from two different sources who know of a developer who recently sold off some technology and is about 1/3 done with their game. I told them both to have him contact me. This is the sort of developer who I can usually help a great deal…long on talent but short on business savvy.

Let’s call them Dev1…had been looking for some funding and had valued their company way too low and were looking for equity funding and offering nearly half their stock to get it. Heck, they probably could have brought in the funds they needed on a publisher deal instead of selling off a big part of their company for less than 1/4 it’s worth, not including the game they are making.

I heard they were going to a meeting where they were seeking equity funding from another developer, let’s refer to them as Dev2. Probably a decent way to go…certainly better than some other options they were considering. But still no call from the Dev1. Well, taking your company to a funding meeting is fine…but I would recommend talking to legal counsel BEFORE the meeting…not afterward. Well apparently the meeting went well because the Dev2 called to hire me to represent them in the transaction.

When contacted, the head of Dev1 said he was planning to call me, but had not got around to it yet….well I sent word to him not to bother. At least not on this deal. You see, my dance card is full. This is the first time in my career as The Game Attorney that I have had developers on both sides of a deal wanting to hire me…and man that felt sweet. Thus the Hot Blond at the Bar comment….the one every guy wanted to dance with!


Powered by WordPress. Theme by H P Nadig