Home Tom's Sailboat Tom's Clan

July 26, 2006

Contract Mumbo Jumbo 101

Filed under: Game Law Articles — Tom B @ 4:38 pm

The vast majority of the work I do for developers involves contracts - reviewing proposed contracts, analyzing contracts, discussing contracts, drafting contracts, negotiating contracts and, sometimes, litigating contracts. All sorts of contracts - contracts for leases, licenses, publishing, distribution, employment, termination, confidentiality, non disclosure, non circumvention, consulting, development, buy outs, asset sales, asset purchases, stock sales, IP transfers…like I said, all sorts of contracts. Contracts are at the core of most of the good and the bad stuff that goes with running a successful studio. A significant part of the time I spend on these agreements is with clients helping them understand what different contract provisions mean and their potential impact on the deal and the studio might be. So, I though it might be good to provide a little basic “Contracts 101″ for developers to provide a little insight into the basic elements of any contract to help demystify them a little.

Basic Elements

A contract is basically an agreement between two or more parties. It can be to do or to not do something and sets out the duties and responsibilities of each to the other. It is the common agreement between the parties, what is referred to as the “meeting of the minds” that establishes the contract. Once this “meeting of the minds” occurs, the contract is formed. In general, oral contracts are just as valid and enforceable as written ones, though certain types of contracts must be written. The term “hang shake” agreement reflects the tradition of confirming the “meeting of the minds” by the mutual acknowledgment by the parties by the parties shaking hands to seal the deal. At the core of every argument is this acknowledgment, though we usually see it in the form of a signature on the bottom line.

“Consideration” is a term used by lawyers to describe the subject matter of the contract. By that I mean whatever of value that is being delivered or exchanged. The dollar for the candy bar or money for the source code are the easiest examples. It is basically what the contract is really about and is a necessary part of any contract. Without mutual “consideration” it’s not really a contract, it’s a gift and as such may not be enforceable. Finally, the parties to the contract also must have the legal capacity to enter into the agreement. That means that they are competent to know what they are getting into. This goes back to the whole “meeting of the minds” thing…no mind, no meeting.

Evolution and Iteration

That’s it. Pretty simple huh? So, how do we end up with a 24 page written publishing contract with over 200 pages of attachments? No, it’s not just because all of us lawyers are out here making things more complicated in order to make a living off of all your hard work. Well, maybe some of it is…but the real reason is that most industry business relationships are complicated and not merely a simple bargained for exchange of goods for dollars. Even the basic employer/employee relationships often involve multiple issues that ought to be considered and resolved in advance. This is especially true in an industry based on intellectual property like ours. And since these are not simple purchase and sale agreements, the relationships that most industry contract addresses are ongoing over time and involve numerous mutual duties and obligations.

In effect, they describe the parameters for these ongoing business relationships ands attempt to account for all of the foreseeable issues that may arise so that the parties’ expectations are met and there is a minimum of unknown risk throughout the relationship. We have all heard stories of the early days in the industry when a publisher would give several million dollars to a developer along with the simple directive, “Make us some cool games.” Now there’s a publisher contact any developer can live with. Unfortunately, those days are gone. And we all know why. Unforeseen events occurred in the course of the performance of these contracts and just like the way a game design iterates over time, the contracts in our industry have iterated as well. It is probably just a natural part of the maturation process of our industry.

Things to Watch

The problem for developers is that most of the folks we do business with, especially publishers, have just done so many more deals that developers do. That means that they have been able to address more problem issues that negatively affect them in these deals. However, they have not addressed the issues that have negatively affected developers. Why should they, that’s not their job. That’s your job, or mine. For example, contract provisions addressing what happens if the developer goes into bankruptcy or receivership are in every contract. What happens if the publisher goes under is never addressed. Publishers go out of business all the time. And no business person should want to get tied up in a bankruptcy proceeding, especially someone else’s. It’s always a good idea to shoot for mutuality throughout these various contract provisions. After all, “what’s sauce for the goose is sauce for the gander.”

It is also important to realize that these complex ongoing contracts are not static. They represent the agreement regarding the ongoing relationship between the parties and just as things changed in the industry over time, thing change in any individual working relationship over time as well. The business relationship is an organic one that by necessity adapts to changes. Unfortunately, most written agreements are static and do not account for these changes. Keep in mind that even after the contract is signed, the deal is not done. The deal is just starting. Make sure that at the end of the relationship the contract accurately reflects that actual relationship, not the one you planned at the beginning. And since virtually all of these written contracts can not be modified by an oral agreement, make sure this gets done by memorializing any significant changes in the performance of the contract through written addenda signed by both parties.

Cowboy up!

Everyone has to deal with contracts, both inside and outside of our jobs. Try to keep the basic elements in mind any time you make an agreement. Cowboy up and accept responsibility for making sure that you understand what you are getting into. Don’t get so involved in performance that you forget to keep the terms of the contract in mind throughout the entire term of the agreement. Ultimately, there is no such thing as a good contract with a dishonest person, or a bad contract with an honest one. But even in the best situations, things come up that need to be dealt with. The more forethought you put into the process in the beginning and the more vigilant you are throughout the performance, the better off you’ll be.

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney © 2006

April 28, 2006

Everybody Conga…Well Maybe not Everybody!

Filed under: Game Law Articles — Tom B @ 4:09 pm

Remember those old movies with the long conga line in them? Well, imagine that the line is a line of gamers. But some of the gamers can’t dance. So, no conga for them. They’re just watching their friends have fun while dealing with a frustrated desire to dance themselves. That is what it is like for an estimated 20-25% of the population over the age of 17. This is because these potential gamers have one or more physical or cognitive disabilities. And the games most of us make do not provide a means for these folks to access them.

Awareness is Job #1

I was asked to participate in the IGDA’s “Game Not Over: Expanding the Market through Accessible Games” full-day tutorial at GDC. And I guess, like most of those reading this article, it was not something I had thought much about at all. And to a great extent, that is the first problem - awareness.

Certainly, no developer would intentionally decrease their potential user base by 20%. And I doubt anyone who makes games, even the most callous among us, would intentionally exclude anyone from getting enjoyment out of the fruits of their labor. Most likely it is simply a lack of awareness or an understanding of the issues involved and how to address them. And, of course, that damned “allocation of resources” issue that impacts every proposed gameplay feature.

Disabilities Come in Several Flavors

Rather than speaking of games for the disabled, it is better to think of it in terms of making games that are “universally accessible.” Disabilities can generally be divided into four basic types; visual; auditory; mobility and cognitive. And the extent of the disability in each type varies. For example, visual disabilities range from total blindness (where all game information needs to be conveyed through sound and touch) to color blindness.

This is similar with all the different types of disabilities. And the result is not just a single solution. But in many cases, a different solution is required for each variant. Now, instead of a single gameplay feature to factor into the cost-benefit analysis, it becomes a bunch of gameplay features. Some very difficult and expensive to implement. Fortunately, others are fairly simple to set up.

Some Simple Examples

Some of the more basic features that can help make your game “universally accessible” include closed captioning for the hearing impaired. This means be more than just dialog. It also needs to include all game cues, including gameplay hints that might be being delivered through sounds effects or even music. (Valve did this with Half Life 2 and there is a Doom 3 closed-captioned mod as well). Many mobility issues can be addressed with a single switch system like the one in Strange Attractors, one of the IGF Innovation Award nominees, or by a modified one-handed controller set up. Cognitive disabilities might require a slower pace or much lower difficulty level.

Hey, wait a minute! Difficulty levels are already in most games. Talk about your “low-hanging fruit.” Just make a special difficulty that is a lot easier! The odd this is that studies show that people who are not disabled also access and use these features when present in games.

Where’s the Game Law?

This is all interesting…but I am sure by now someone is wondering, “Where’s the Game Law?” Well, my part of the tutorial was about applicable US law. And there are a few things to be considered. Although US discrimination laws do not extend to products sold to individuals, they do apply to government sales.

So, if there is any potential government sale of your game or technology in your business model, you had better pay attention to making it universally accessible. Section 508 of the Workforce Investment Act of 1998 requires accessibility on all electronic media sold to the government. So, it may be something you need to consider. For more information, see: http://www.section508.gov/.

That’s the “stick” side of the equation. On the “carrot” side we have the 8826 Tax Credit to small businesses that implement accessibility into their games. Small businesses are defined as businesses with 50 or fewer employees or whose annual revenue is less that $1M US. You can recover up to 50% of the expense of the implementation of accessibility up to $10,000.00. That is a total tax credit of up to $5,000.00. And a tax credit is deducted from your taxes, not merely expensed out.

I’m no tax lawyer, but $5K tax credit to closed caption your game, especially for small casual game studios, could be well worth the effort. Here’s the link to the form - http://www.irs.gov/pub/irs-pdf/f8826.pdf. Pass it on to your accountant!

Some Resources

Here are a few more links to additional information on these issues:

IGDA Accessibility SIG - http://www.igda.org/accessibility/
The Bartiméus Accessibility Foundation - http://www.accessibility.nl/games/
UK Accessibility Site Article on Games - http://www.bbc.co.uk/ouch/closeup/gaming.shtml

So, there is an untapped market here, financial incentives, government pressure…and most important, it’s the right thing to do. Let’s all start thinking seriously about making games universally accessible to everyone.

Till next time… Good luck, have fun, and I’ll see you at E3!

March 1, 2006

The Good News About Digital Distribution

Filed under: Game Law Articles — Tom B @ 4:06 pm

Last year at GDC, I met the guys from Tripwire Interactive. They had just put their studio together from the team that created the Red Orchestra mod that won the “Nvidia $1,000,000 Make Something Unreal” contest. Their mod had also garnered a bunch of “Mod of the Year” awards. Since they needed my legal help, but were tight on cash, we worked out a deal where I agreed to represent them for a percent of revenue. Sort of like an agent, but at a much lower percentage.

I do this from time to time with teams that I really believe in. And, I had even done a similar deal with Trauma Studios, the creator of Desert Combat, the prior year’s “Mod of the Year.” So, it seemed fitting. (Hmmmm…I wonder who got “Mod of the Year” for 2005?)

There was a great deal of interest in the commercial version of the game from several publishers including Midway. And we worked for months trying to close a deal. But eventually it became apparent that even though the folks on the product acquisition side were very interested in the game, the marketing folks were not going to green light the deal because their retail buyers had not heard of the game and would not put in significant initial orders necessary to minimize their risk. So, no deal.

The Red Orchestra Deal

Fortunately, as part of the contest winnings, Tripwire had an Unreal Engine 2.5 license. So, although they did not get the whole million dollars for winning (the total prize money in products, engine licenses and cash totaled $1,000,000 over the entire contest), they had an engine and some cash. So, they put what they had into finishing the game however they could. We continued to look for a publishing partner and began discussing the digital distribution possibility.

We looked into a bunch of digital distributors including IGN Direct 2Drive, Trymedia’s Digital River Distribution network, GarageGames and Valve’s Steam. I assumed that Steam was limited to only Source Engine games and that there was no way the Valve would want Red Orchestra, a WWII FPS game made with Unreal technology, competing against Valve’s own Day of Defeat. But to his credit, John Gibson, the head of Tripwire got in touch with Valve anyway. To my surprise, the folks at Valve were not only interested, they were straightforward and easy to work with. A real pleasure. So, in short order we had our digital distribution deal in place.

Of course, with a digital distribution deal, there is usually no big marketing push from the distributor like there is with a big publisher. But, through Steam we would be selling into the hardcore FPS gamer market. And as a result of the Valve deal, Red Orchestra got solid editorial exposure in major PC game publications, including two page “preview” articles in PC Gamer US and UK. The buzz from the Valve deal resulted in a retail distribution deal with Destineer as well. No advance. But access to the retail distribution channel and a solid chance to succeed. And most important, no need to give up the IP rights to the game.

That means Tripwire has a chance, maybe not a big one, but a chance to retain the IP to a franchise that they built. And that means long term IP value to the company. And it was the digital deal that made it all happen. So, Tripwire Interactive’s Red Orchestra: Ostfront 41-45 is set for release in March 2006 via digital distribution on Steam followed by retail as soon as the media gets manufactured, through the retail pipeline and into stores. Wish them luck!

The Digital Distribution Advantage

Once the digital deal is in place, a retail publisher is in a much less advantageous bargaining position, especially where it comes to IP ownership issues. Digital distributors, at least for the present, have no interest in obtaining IP ownership for the games they distribute. The so-called casual games, or “Pop Games” as I like to refer to them, have been building this model in the PC market for several years. And with the present broadband penetration, the download of full-blown PC games is a reality. I recently purchased F.E.A.R. digitally, and that’s an over 1GB game, unzipped. And we all know of Valve’s success with distributing its games via Steam.

Digital Distribution for Console Gamers

Up until now digital distribution has been something unique to the PC market. But the Xbox Live Arcade (“XBLA”) is changing all that. The size of the game that can be downloaded on XBLA is limited to the size of the 64MB memory card, which limits things somewhat when compared to PC downloads. But it is a huge potential market. Of course, access is also an issue.

If access to the XBLA pipeline gets clogged with aggregators who are already XBLA certified, we could potentially end up with some of the same issues we have now with the retail channel. For example, although MS has no interest in game IP ownership, at least one of the XBLA aggregators is looking to acquire IP rights to the games it distributes through XBLA. But hopefully this one distributor is an aberration and there will be enough less greedy options for developers to just go elsewhere. After all, the marketplace is a great influencer of predatory policies like this.

The big question is, will the PS3 and Nintendo Revolution also have a digital distribution capability? I suspect they are considering this right now since XBLA is doing a brisk business and leaving this potential market open to a fierce competitor like Microsoft could be a huge blunder. So, it is at least possible that Sony and Nintendo will also do some sort of digital distribution in their next gen consoles. And they may even do it better that MS.

The Bottom Line

So, I have become a believer in the digital distribution of games. The developer’s royalties are usually two to four times greater than what they are in a traditional publisher deal. This means you can sell fewer units and get by and if you get a hit, you get much more return, even at a significantly lower price point. Also, in most cases the developer retains the IP. This help builds long term value in the studio, something you cannot get otherwise unless you develop some sort of patentable technology or other licensable tools and technology while your making your game.

The digital distribution model also opens the door to pure funding deals that do not involve publishers who, frankly, charge much more than the value of the money for the funding they provide. But most important, digital distribution means more ways to get your games directly to the players with as little “middle man” action as possible. That has always been the great promise of the Internet and it’s great news for developers. Heck, higher royalties, you get to keep your IP and direct access to your user base. It’s hard not to believe.

Till next time, good luck, have fun and I’ll see you at GDC!

January 19, 2006

Prior Restraint in Games

Filed under: Game Law Articles — Tom B @ 4:03 pm

When I first agreed to do these Game Law columns, I told the editors of Gamasutra.com that from time to time I would like to have the opportunity to rant about issues beyond the straightforward legal issues that I have been addressing to date. This is the first time I have taken the opportunity to rant on a little bit and I hope you find it both thought provoking and informative.

The Backstory

I recently did an interview for GameCloud.com. There were a bunch of questions about a whole variety of issues. Everything from why and how did you become a Game Attorney to specific problem issues that a lot of developers face. Among the questions asked was a question concerning some of the recent moves to regulate the industry and I responded by referencing a fellow Miami attorney named Jack Thompson. Jack Thompson being the self-appointed defender of the moral standards as they apply to everything from “Hot Coffee” to violence in games.

As a Miami attorney, I am well aware of Mr. Thompson in that he has been in and out of the local news for over 15 years. In my opinion, he is sort of a laughing stock and nobody in the legal community here takes him very seriously. However, as a result of some grandstanding on hot button topics, Mr. Thompson has once again come to the forefront in the general media, now attacking all sorts of games with all sorts of arguments. Anyway, in the interview I mentioned the possibility of debating Mr. Thompson but also stated that I did not want to validate his position by making any efforts to do so.

GamePolitics.com reviewed the Gamecloud article and posted a news story entitled “Hey - a Florida Attorney Who Loves Gamers!” and referring to me as the other game-crazed Miami attorney. The piece mentioned that I had expressed a willingness to debate Jack Thompson. I came into work the day that article was posted not knowing that it had been posted or even that the GameCloud interview was up yet. First notification I got that anything was amiss was an incoming email with the subject message “Just say when and where, Tom” and the body of the message was Jack Thompson’s name, address and office and cellular telephone numbers. The message was also cc’d to Dennis McCauley.

Being a cautions man, rather than me responding to Thompson directly I assumed that this was some sort of prank or something. So, I sent a quick “WTF?” to Dennis McCauley over at Game Politics to figure out exactly what was going on. To make a very long story short, I became aware of the article and responded to Mr. Thompson’s challenge by giving him a date, a time, and location. After much huffing and puffing he ultimately declined to meet and debate. Too bad, but not a surprise.

The Response

I received a large number of emails from gamers praising me for being someone who could stand up to Jack Thompson. And there is no doubt that I could. But that is not the point of this article. The point of this article is that gamers and game developers need to become a politically active force if they want to effectuate change. And talking to each other about what a (fill in your own expletive here) Jack Thompson is does not get anything done.

The Point

The recent efforts by Senator Hillary Rodham Clinton (D-NY) and Senator Joseph Lieberman (D-Conn.) to present the Family Entertainment Protection Act before Congress shows exactly how volatile the political situation concerning the game industry is. These extremely powerful people are advocating putting restrictions on the game industry that do not exist in film, literature, or even television. This sort of prior restraint on free speech rights guaranteed by the First Amendment is extraordinary and is something that should be opposed by anyone who loves or makes their living from games, regardless of their feelings about violence in games. Because even if you oppose violence in games, that sort of government regulation of the industry is really not the way to address it.

Therein lies the power…

So what do gamers or even most developers do about this? They complain. They whine. They praise anyone who says something that they agree with and jeer anyone who says something they don’t like. But they do not organize and more importantly, they do not bother to vote. Rough estimates are that there are upwards of 145 Million gamers in the United States . This number far exceeds the number of people in the Christian right or moral majority. However, those minorities vote in a block they have an excessive amount of power in the political marketplace. If even 10% of active gamers voted in a block on specific issues, politicians like Hilary Clinton would be very weary to take positions opposed to our industry. Heck, if she got “back off” emails from even 1% of gamers she would have never offered the bill in the first place. After all, it’s no good to pander to one organized minority voting block at the expense of another larger organized minority voting block.

Other industries spend millions of millions of dollars on lobbying and on organizing voters. And while the ESA does a good job, its power is significantly limited by simple economics. And no one seems to be making any effort to organize and mobilize gamers as a political force. Mobilizing the people that play the games that we make could easily generate the amount of politic leverage that we need to protect our industry from unwanted interference and regulation by this government or any other elected government.

So treat this as a call to arms. Get out and vote. And when you vote, make sure that you learn the position that the candidates that you are considering take concerning freedom of speech and how it implies to computer and video games. Otherwise, you may end up working in an industry that is significantly handicapped due to restraints on

December 7, 2005

To Sue or Not to Sue…That is the Question

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

So, you got that game done and everything is going great. Except for the fact that based everything you can figure, by now you should have received several fat royalty checks. Instead, no one at your publisher is returning your phone calls. Your requests for sales info on the game are falling on deaf ears. In spite of your written request, you can not even schedule an audit. But the game reviews are great and, at least according to the NPD figures you got from a friend of yours, sales are beyond your best expectations. The question arises - to sue or not to sue?

The harsh reality is that litigation has become a normal part of business in the modern world. Disputes occur that can not be resolved no matter how hard people try and ultimately the good offices of the court system is required to resolve these matters. Of course, it would be naive to think that the only matter to be considered when deciding whether to institute a lawsuit is whether you’re going to win or not. Game developers are especially susceptible to the perception that they do not have the power or the ability to litigate, especially against publishers. Let’s take a look at the components of a cost-benefit analysis that a developer should be considering when a question of filing suit against a publishing partner occurs.

Many developers say that even though a publisher had cheated them out of royalties or residuals, they were not willing to institute a lawsuit to recover their losses. The reasoning? Quite simply, they believe that in a buyer’s market with only 30 or so viable publishing partners available, developing a reputation as a hard-nosed developer willing to sue to enforce his contractual rights would, ultimately, have a chilling effect on the developer’s ability to get business. This may be true. However there are other things to consider.

The Cost-Benefit Analysis

First, you have to ask yourself a few questions. Is it really a bad thing if by asserting your rights, you eliminate from the list of potential publishing partners those who intend to cheat you? Are there a number of viable alternative publishing partners available to you? And whether you have a single-title shop or have several projects in the pipeline with different publishing partners. What is the projected return on investment in the lawsuit? Can you afford the costs of the lawsuit or find an alternative way to make it happen?

Underlying this decision is also another consideration. In a real sense, a successful developer-publisher relationship should be a peer relationship, even though there is a disparity in the relative bargaining positions of the parties. So, you have to consider whether you can maintain a solid peered business relationship with a publisher if you continually view yourself in a submissive or subservient posture. The sad reality is that a lot of publishers view developers as spineless weaklings when it comes to their business dealings. This image has been perpetuated by the conduct of developers for years. While most developers seem too interested in making games to want to hassle with being hard-nosed business people. So, it’s easy to understand why a hard-nosed Ferengi publisher would look at most developers like a wild dog looks at raw meat.

I Don’t Get No Respect…

I can’t tell you how many times I have been involved in situations where in an effort to settle what ultimately turned out to be a litigation matter, a publisher has offered as a proposed settlement offer another deal just as bad as the one that got the developer and the publisher in the dispute in the first place. “Oh, I am sorry you got screwed in the last deal. Let’s resolve this whole thing by getting you into another deal where I can do it again.” Amazing! I do think that developers need to be careful when they decide whether they should litigate or not. However, this certainly does not mean that there are situations where litigation should be seriously considered.

Lawyers Cost Money

As I mentioned, one factor that should be factored in a cost-benefit analysis for developer is the cost. Frankly, lawyers are expensive. However, there are lawyers who take on a business dispute based on a contingency fee agreement where in the attorney advances the cost of litigation in exchange for a proportionate share of the recovery. It is not a small share but generally less than half. So, let’s say a developer is hit for $400,000 in back-end royalties based upon his understanding of the sell-through on his game and his royalty schedule. But money is tight so they can not afford the $60,000+ in attorney’s fees it is going to take to fund the lawsuit. Then, giving a contingency fee attorney 40% of the recovery gives the developer a choice of getting 60% of something, rather than a 100% of nothing. That, and the additional knowledge that you didn’t just lay down and take it again which can be very gratifying as well.

Never Say Never

Overall, it’s probably not a good idea to litigate every dispute. In fact, I generally counsel against it in most cases. However, it’s also not a good idea to assume that you should not litigate every dispute. So, take the time to talk to somebody who knows, get a realistic cost-benefit analysis, and then make the decision whether “to sue or not to sue.”

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.

______________________________________________________

September 19, 2005

Audit Rights - Use Em or Lose Em!

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

I was approached a few weeks ago about doing this regular monthly article for Gamasutra and thought it would be a good thing. So, then I began mulling over what sorts of topics would be fun for me to do and of value to the readers. Well, with all that’s been going on lately such as Hot Coffee and the Jack and Hillary show, I was tempted to use the opportunity to rant on about lawyerly things like the Bill of Rights (the first ten amendments to the U.S. Constitution) and the potential impact these present issues can have on free speech - or possibly a rant about the desperate need for our industry to make a conscious effort to present games as a valid “art form” just as the film industry has done with its commercial medium. These are, for sure, issues I have something to say about and that I believe need to be voiced… but instead I decided to save my rants for future articles, and make my first one about helping developers deal with one of the more knotty business issues they face - royalty audits.

Audit Basics

Most publisher contracts contain a provision that provides developers a right to periodically audit the publisher’s financials related to their game in order to verify that the royalty credits and payments due the developer are properly calculated and accounted for. The audit is usually at the developer’s expense. But, typically, if a discrepancy of more than 5-10% is discovered, the cost of the audit is paid by the publisher. This protects the developer from any mistakes on the part of the publisher in determining the “net proceeds” from which royalties are set or inadvertent miscounting of units sold. It seems really simple, and certainly sounds like a good thing for any business to do. There are few, if any, developers who would sign a publishing contract without an audit provision - at least none of my clients would.

Here’s the odd part… the exercise of audit rights by developers is, in reality, fairly rare. I have asked developers about this. Even in cases where they felt that they were due royalties, I have had developers express a strong reluctance to exercise these rights, because they think that to do so might create the perception that they didn’t trust their publisher. Of course, this is not really a matter of trust - it is a matter of business sense. The continuing failure of developers to routinely exercise their audit rights creates a void into which the most lax accounting practices can easily fall on the publisher’s end.

You see, if developers don’t enforce their audit rights, there is no incentive for the publishers to use the necessary high degree of care in determining the appropriate royalties. This level of care takes time, and time is money. So, if no one is going to audit, why bother? Not surprisingly, any slop usually lands on the publisher’s side of the balance sheet. If any accounting errors do occur, it is unlikely that they will result in a higher net revenue figure or more units sold.

Let’s be serious here. Developers fortunate enough to make a game that puts them in a position to receive back-end royalties should be sure that they get every single dollar they are entitled to, because it is an all too rare occasion. Sure, for most developers, it’s a buyer’s market and there are more developers looking for publishers than there are publishers looking for developers. So this may not seem like an easy decision, at least politically. But it sure is a simple financial one. Audits cost several thousand dollars. Compared to the budgets of most games, it is a small price to pay to make sure that you are getting everything you are due.

Besides, it seems to me that the only publishers who would be offended by a developer enforcing its audit rights are probably not ones you should be doing business with in the first place. Developers can do worse than have publishers believe that they are competent business people willing to enforce their contractual rights. For example, they could be viewed as incompetent business people that are easily taken advantage of.

The 6 Million Dollar Game

I was on a panel discussion recently at the Microsoft Meltdown in Seattle where we were discussing publisher deals. This was a pre-contract through gold master sort of discussion, and prior to the presentation, I asked that we go past the delivery of the game and include audits in our discussion. I almost forgot about it, but one of the panelists, a top-tier developer, reminded me about this last topic of discussion as we were about to close. I soon found out why he remembered because numbers like these are hard to forget. At first I was a little surprised to hear him say that his studio always audits every publisher deal. Why? Because when they audited their first major deal they found 6 million dollars (yes…that’s $6,000,000.00) in royalties due them that had not been paid. Apparently, the issue there was the manner in which the publisher had been calculating net proceeds rather than the number of unit sales. But, whether it is the methodology or simple accounting of units sold, an audit should reveal any errors.

Sure, there are only a few games that hit numbers like that, and there are only a few developers in the top tier. But mid-level independents that live from one game to the next are even more thinly capitalized, and for many, a few hundred thousand dollars in inadvertently omitted royalties could make the difference between success and survival.

Audits Make Business Sense

Like a close friend of mine who does product acquisition for a major publisher says about dealing with a publisher, “It’s not my job to protect your financial interests and if the developer does not have the business sense to ask, then I’m not going to offer.” Just as this basic business principle applies to the negotiation of publisher contracts; it also applies to developer audits. If you don’t ask, they will not offer. So, while the exercise of your audit rights is certainly an expense, it can often be money well spent.
Review your contracts so that you are well aware of what your audit rights are and how to exercise them. Then, any time you are in a situation where you believe that you have reached, or are rapidly approaching, recoupment of advances under your publisher contract, you should consider calling an audit. Unless and until developers start asserting their rights in their business relationships with publishers, they will continue to be perceived as business softies who are easily taken advantage of, and this isn’t helping your business, or, indeed, anyone else’s.

« Previous Page

Powered by WordPress. Theme by H P Nadig