I get a lot of questions about how we make all of this work, and I would like to share that with you. Although this article will likely be of most use to other small, outsource-heavy studios like ours, managers in larger traditional studios may find some useful information here as well. But first, I’d like to explain why we do business the way we do, and what the benefits of a work-from-home, distributed business model are:

• Access to the Best Developers in the World: We can hire anyone anywhere, and not worry about relocation, visas, etc. And our employees don’t have to uproot and leave their communities to work with us. In fact, we have people happily working for us hundreds of miles from the nearest game studio, in places other game developers would not think of living.
• Lower Labor Costs + Cost of Living Adjustments = Happy Developers: While wages in Asia are not as low as many North American developers would hope, our staff costs are certainly competitive. But for us, instead of seeing this as a chance to get dirt cheap labor, we see it as a chance to create a competitive advantage in our development environment. Rather than adjusting our salary rates down in those countries where we could get away with it, we peg all of our company compensation to Singapore wages, regardless of location. While this policy may not be best for developers in the US or UK, it makes our staff in places like Russia, Malaysia, and the Philippines some of the best paid developers in their local communities. This allows us to hire the absolute best in those regions—and keep them very happy.
• Lower Support/Overhead Costs: We don’t pay for office space, computers, electricity, coffee machines—or even paper clips. We do pay a little more to our developers to make sure they can afford the equipment they need, but come on—they are game developers; they are going to have the best machines they can afford at home whether we pay for it or not. We just avoid unnecessarily duplicating that cost at the office, and let them put that savings in their pockets as compensation.
• Freedom to Efficiently Mix Personal and Professional Time: Our model allows everyone in the company to adjust their work schedules to mix with their personal schedules in the most efficient manner for them. This not only saves time that might otherwise be wasted on commuting (for example), it also allows our staff to do things that they couldn’t easily do in a more traditional office—like go to school part time, teach a class, or whatever. The value of that freedom—and the happiness it creates—cannot be overstated. It points out that the benefits of working for an organization like ours extend far beyond time and money.
• Work/Life Balance + $$$ = Loyal and Dedicated Staff
  To be clear, the end effect of this is that our staff loves working for Boomzap. Any manager knows that retaining good staff is one of the keys to growth, and our structure not only allows us to pick the best staff from around the world, it helps us retain them. In fact, since 2005 we have not had a single staff member leave voluntarily.

Ten Commandments

#1: We Don’t Track Hours—Ever

The economics of this are simple: If you want to reward the staff for working quickly, you can’t make “hours worked” a constant, because then only quality and quantity remain variable. In a traditional situation where “hours worked” is a constant, the reward for working quickly and efficiently is just getting more work. Worse yet, in that traditional model you end up offloading work from crappy workers to top workers since the top workers are going to be chewing through more tasks in the same time. Thus, you inadvertently create a “do less work” reward for crappy workers while punishing the good ones in direct proportion to their efficiency. That really sucks.

Instead, at Boomzap we hold quantity and quality as a constant, and allow the staff to use time as an adjustable variable: They have a set task list and a minimum standard bar, and they set their own schedules for completing their work. If they can get good work done faster, their reward is that they get the rest of the time off, and if they can’t, they will quickly find that they are working a lot of weekends. In this model, inefficient workers self-select for removal from the team, as they will end up working a lot of overtime (and probably leave). At the same time, efficient workers find themselves with more free time—in direct proportion to their efficiency—and free time is a form of additional compensation. Having your best workers compensated daily results in good juju.

#2: We Do Daily Builds

#3: We Mix Full-time Contractors with Project-based Contracted Specialists

The key is that we’re not outsourcing so that we can pay our outsource partners less. In fact, some of our contractors are much more expensive than our core staff. We’re outsourcing to move the risk of idle time out of our studio. For instance, we outsource all web work, all sound, and all bulk production of hand-painted backgrounds and portraits. This is all work that specialists can do quickly to a high level of quality, and work that we only need for certain stages of production. We pay more for them when we use them, but we make that back in savings by “firing them” when we don’t need them.

#4: We Hire Full-time Staff Primarily Based on Character

We do this by having a full-month test followed by a three-month probation period before anyone enters the studio—even developers we know well. The month test is skill-based and answers the core questions about whether one is capable of doing the work or not. The three-month probation is personality-based, and answers questions about self-management abilities. In the few cases where we shortened that three-month period, we regretted it. We have even started lengthening that period for people who we don’t actually know personally.

The bottom line here is that if you are going to have people working within this model, recognize up front that some people—including some great people—just won’t work out. But for those who are independent and self-motivated, our model works very, very well.

A side note on this: some people have interpreted this issue as “virtual studios cannot hire young or inexperienced developers” – which we categorically disagree with. Some of our best workers are young, highly motivated interns, and some of the people that didn’t work out were highly trained professionals who had long since gotten used to the old way of doing things in a game studio, and were unable to adapt. The issue here is less about experience and more about motivation and personality.

#5: We Delegate Authority to a Project-based “Confederation” Structure

This functions much more like a confederation of independent projects than the more centralized structure of many other studios. Each team has the independence and authority to make large changes to the design and product without having to check with the “central powers” and as a result, the central overhead becomes much smaller. To be clear, in a system with strong project teams, this works great. In a system with weak teams that need more oversight, this system would likely fail. So knowing your staff capabilities is key.

That being said, it is important to note that key to doing this well is being able to accept good work you didn’t expect. All too often studios spend a lot of time chasing a single vision-holder’s dream for a project, and they end up in an endless cycle of revisions trying to perfect that vision. The trick to delegation and empowerment is being able to look at work that is not completely what you expected and/or wanted and objectively judge whether it is good work. Doing so has two great effects: 1) Your staff will really feel empowered when they see that the work they are doing gets put in the game without constantly being retooled to fit someone else’s vision; and 2) Sometimes you’ll get stuff that is actually better than what you had in mind.

Remember, delegation is not just the delegation of work, it is the delegation of responsibility. If you want a team to truly start taking some responsibility for their work, you cannot constantly undermine their efforts by forcing them to revise work just because it’s not what you would have done. “Is this what I wanted?” is not the question. You’re better off asking: “Is this something the customer would enjoy?”

#6: We Hire Managers Who Can Actually Do Things

#7: We Depend on the Three P’s: PowerPoint, Prototypes, Photoshop

For starters, we do the initial design for a game by using short PowerPoint presentations full of diagrams, scanned-in drawings, references from other games, and Google images. (That’s right: Not a Word document.) The PowerPoint is generally a mockup of every major screen in the game—with minimal text callouts—describing what the game will look like and how it will play. Next, we let the programmers build a rough prototype version of the design using a bunch of grey boxes and placeholder art cut from the PowerPoint slides. When this is playable, we have something to reference in our notes and MSN discussions. The prototype and a daily sheet of notes referencing it and suggesting changes becomes the “design document.” When we finally have the prototype really fun and playable, the artists take screenshots of the demo and attack them in Photoshop, creating mockups of the final screens as they will look to the player.

When we have all of that, we go into full production. Usually someone will sit down with the PowerPoint and the prototype and create a series of simple lists that defines the tasks to be done to complete the production of the game—which is as close to a design document as most of our games ever get. Most of our games have shipped with less than 20 pages of documentation, and we still wonder if that’s too much.

#8: We Use “Producer-Programmers”

#9: We Create An “Idiot-proof” Pipeline

Our biggest tool for this is Excel, which we use to generate any script in the game including sprite lists, sound files, level design variables, object variables, localization strings, etc. The Excel sheets have a big EXPORT button that spits out a script, and nobody has the ability to break anything in script. Remember, automization means that all errors are systematic errors, and those are easier to both find and fix. And because anyone can read an Excel sheet and fill in variables, most people can figure out how to get their assets into the game without ever talking to a programmer.

Our level design tools are similarly simple. They are all WYSIWYG mouse-driven editors that are directly accessible from within the game engine—which allows our designers to get in and effectively build and test levels within a few minutes. Because the producer who defines what datasets are going to be manipulated in the game is also the one making the export sheets and editor, this process ensures a high level of idiot-proofing.

#10: We Hire Only Technical Artists

Nine Essential Tools for a Virtual Studio

1. CVS: If you aren’t using some kind of online source control and backup system, it’s just a matter of time before you will deal with some HD-crash-induced or file-swapping nightmare scenario that will cost weeks or months of manpower. While this is true for any studio, the odds of file management disasters are much higher in a virtual model. Which software you use is unimportant, but you really should be using something. We use CVS, but that’s just a personal preference from our technical director. Whichever one works for you is fine.
2. Basecamp: A nifty online team collaboration tool that we use for our projects. A cheap $25-a-month subscription gives us the ability to create as many project groups as we need, giving our publishing partners direct access to our daily project management and creating a single record of all design/production conversations. For things like posting the daily builds/notes, this is simply invaluable. The best part of it is that it can be configured to send email out when messages are posted, and you can reply directly to messages in your mail client and have them posted to Basecamp without opening a browser. Very cool.
3. MSN Messenger: Our studio lives and breathes on MSN. We require all staff to be online and on MSN when they are working. In addition, they must set it to “auto-select away” when they are AFK so we know when they are available during the day to talk. We also ask them to set the “personal note” to let us know what they are up to. So if they go to the doctor, they add “at doctor until 3:00,” or if they are working on a particular part of a project they might add something like “drawing backgrounds.” Now everyone knows what everyone is doing without anyone needing to bother anyone. Also, if people want to be left alone, they set their MSN to busy. We have a strict “don’t bug busy workers unless it’s an emergency” rule, so people who want to really concentrate on their coding without constant interruption can keep focused, but they are still available if we have some kind of serious issue that’s stopping other workers.
4. SkypeIn and SkypeOut: Aside from the free Skype-to-Skype calls we do between staff regularly, SkypeOut will let you call a real phone anywhere in the world from any internet connected computer. With a decent headset the connection is usually better than a cell phone, and at two cents a minute, its darn near free. Better yet, you can set up a SkypeIn number that lets people call your Skype account as though they were making a local call. We have ours set up in Seattle, since most of the distributors we work with are there, and dialing a 206 number makes them feel warm and fuzzy. Better yet, you can have your SkypeIn calls forwarded to any phone anywhere, including your cell phone. And it has voice mail! The end effect? People in the states can call you for free at the same number, regardless of where you are in the world, and you can call anywhere for two cents a minute. There—your telecommunication problems are over.
5. Earth Class Mail: How do you keep publishers from sending checks and contracts to the wrong address? First of all, push them to do everything electronically. Automated Clearing House (ACH) is free, and pretty much any contract can be scanned and PDF-converted. As for the few Luddites who feel the need to write checks and send snail mail, set up a mailbox at Earth Class Mail. They’ll scan the envelope of any incoming mail, and send you an email about it. You can then forward it, shred it, or have them open and scan it for you – all from a web browser. It’s not free, but for the few mails you have to get, it’s pretty cheap. They have sites around the states (ours is in Seattle, perpetuating the pleasant illusion that we have a Seattle office). Be careful, though: When you set this up, choose the non-PO-box option, because sometimes you’ll deal with people or services that won’t deliver to a PO Box.
6. MyFax: If you have a scanner there is no reason on earth to have a fax machine. Set up an account at MyFax, and have all of your faxes delivered to your email. It’s simple, clean, and dirt cheap. And more importantly, you end up with a permanent, US-based, toll-free fax number that never changes, regardless of where you go.
7. PayPal: I don’t need to tell you that if you need to pay people internationally, PayPal is the only way to go. We use this for all of our contractors in the US and Europe, and not only does it get them paid immediately, it creates a great record of all payments out. Also, since you can use a number of different solutions for paying into your PayPal account, you can play with this to create short-term credit for cash-crunch situations at relatively low cost.

8. NOTE: The author has dropped usage of PayPal since the service added a "rather onerous" international payment fee to a lot of countries, including those in which BoomZap operates. They are currently looking for an alternate solution, however until now PayPal has served them well and could still be considered for your individual needs

9. Your Mailing List Provider: if you are running a casual game studio, you’re going to be sending a lot of emails. There are a lot of solutions, but cost for value, we’ve had pretty good luck with YMLP.com. It has good tools for importing addresses from various sources and collecting addresses from our website. Most importantly, you can get to your entire mailing list from anywhere, without even needing access to your laptop. It’s also useful when you are sharing mailing responsibilities, so you can have different people working with your mailing list without anyone swapping files, and with everyone being able to see a clear record of what was sent when.
10. Portable Equipment: Last but not least, make sure when you are buying equipment, that you consider portability. My home work station is an Acer laptop with internal camera and a small second flat-screen monitor with a folding base. I also have a portable USB-powered flatbed scanner, a mini-printer, and a headset for Skyping. The whole lot of it fits in a single carry-on suitcase (though I am not a popular guy at the security stations at airports!). I can pack my entire “development studio” in about 3 minutes and take it anywhere. My office is anywhere there is an Internet connection and a table. A note: Try to buy only peripherals that power off the USB. This is super useful when traveling overseas, allowing you to essentially use your laptop as a power converter for everything else.

Conclusion

Alright, you've got a game company up and running and you've got a good number of investors and resources at your disposal. What are you going to do now? Well, there are many possibilities but all of them share common mistakes that startup companies make in their first year. I will discuss in this article the 7 things a company should consider and work on, from personal experience working at a startup company for nearly 2 years.

Know your Limits.

I think that the number one issue we had was a team of 5 (well paid) employees with a solid game idea that was unfortunately way too costly and lengthy. I think it is a common thing to see start ups always wanting to jump on the big MMORPG bandwagon because they have played games like World of Warcraft, EverQuest, Dark Age of Camelot, and found flaws and mistakes that they think they can fix or make better. This is admirable, but unless you have a huge team and a huge budget it's not very feasible. Just a side note on this issue: World of Warcraft took $200 Million to create, and if you have that kind of capital to spend on one single game, go for it. But the fact of the matter is, World of Warcraft worked off an already pre-existing IP, with a huge fan base, and a strong reputation for making top-quality games. What does your company offer?

So you might ask me: well, why did you join a company that didn’t know its limits? I will be brutally honest when I say I was a naïve, recent graduate with a bachelor’s in game design, a twinkle in my eye, and a huge desire to get a job, any job, in any company. I was promised more employees would be hired and I thought, that’s wonderful, that means I’d be senior over them. Unfortunately as the months waned on and the bottlenecks began to appear, it became more and more unlikely that we would ever finish the game we started.

If you are a startup, you have no games under your belt as a team. Start with something small, something you can easily distribute, and begin a cash flow. A flash game is a very good way to start. Try to create a goal, such as finish the game from start to finish by 6 months. If you can do that, you can potentially get a revenue stream after 6 months of expenditure.

Buy That Engine!

Probably one of the more annoying things was that our programmers were working on an engine from scratch, because in their college days they found they could make one in a few months. The engine was in development for roughly two and a half years and there was very little to show for it. Not to mention the backup idea was to sell the engine if the game didn’t work out; no one ever mentioned that they had to compete with a huge array of other professionally-built engines. I believe, to this day, we could have actually finished something if we had a pre-made engine that they invested some of their money into, and used that to build on top of. Believe it or not, for the year and a half that we sat there working on the artwork, on the animation, and on all the artistic creative aspects of the game, our programmers sat working on an engine. They didn’t even touch the basic mechanics of the game. Our character can be imported, it can run, and it can move, but it can’t attack, it couldn’t interact with anything; it was an empty, void world.

I admit though, we had some really great and innovative ideas, and actual things built which I think would have made our engine stand out a bit more, but the truth is spending a month to try to apply depth into your speed trees isn’t worth it. Especially if you have a tight budget and no game or IP under your belt.

And if for some reason you do not heed this warning and decide to build your engine from scratch then I will give you one last bit of advice on this particular subject: Please, please, get the basic components in first, and THEN perfect them. When all was said and done, we didn’t have much in the engine, but what we did have was very well crafted to its final stage. But this made us lose a lot of things in the process as well. For example, although we had a great bloom affect, we lacked any way of making water…Though we had a great shader, we couldn’t even make basic particles until way down the line.

Design Document: Without It You’re a Blind Man Hunting.

Ours was not finished. Ever. There was only one paragraph in it when we started, and we had to take time from all the teammates just to sit down and concept out the general game play. Though eventually we learned from our mistake and tried to fix it for the second title, it was still one of the bigger draw backs to work with. I remember sitting in a meeting room for 5 hours straight, while everyone debated over the smallest little details at how the town progression would develop, and in the end it was entirely scrapped.

The Design Document is one of the first and most important documents you should have. It should be 80% finished by the time you begin your actual artwork and production stage. The 20% head room should be for any changes or sudden limitation you receive through the production progress. On this note, make the design document concrete, easily read and understood. Include a section of what must be in the game, and what is optional.

The design document is also a great way to speed up production and lift morale. There was many a time where I finished an asset and wasn’t sure what I needed to work on next. I was always encouraged to take initiative and work on assets without always needing to consult the art director. But this was virtually impossible when you don’t really know what is going to be in the game and what is not going to be in the game. And there is nothing more annoying or painful than seeing something you put 10-15 hours worth of work into being thrown away because it didn’t fit.

Art Concepts for Artist’s Sake!

As an environment artist, I cannot stress this aspect of the pre-production, and production stage, enough. There needs to be concept art, always, for the things you make, and if there isn’t a concept art piece for the particular asset, it better be a mundane asset like a particular flower or tree, something I can just as easily Google.

I model, I texture, and I love coming up with my own little buildings and my own style. I love the creative process when it comes to designing something from scratch, but that isn’t my job. My job is to take a concept and turn it into a 3d object for the game to use. So if you’re going to ask your modelers to work on things, give them the courtesy of providing adequate concept art.

The last few months as I spent time working with people on 3d assets and models, one of the biggest draw back was that no one had any concept art. It would take me more time to create things and, hence, at a higher cost. This isn’t to say that when I worked at the said startup company we lacked concept art. We did have concept art, but here’s the kicker: It came from China.

Yep, we outsourced our concept art to China, which was a huge mistake. Out of all the things you don’t want to outsource it is concept art. A concept artist is supposed to work closely with the director and the producer. They have to draw dozens of pictures a day, with different variations, and out of those dozens only a tiny select few will ever see the light of day. The concept artist has to know what the target audience is, what their cultural background is, what they can put into the game, and what they cannot. They are a walking encyclopedia of random facts and snippets of information.

It would take us at times 3 weeks to get anything good out of a concept art piece, and in those 3 weeks there would be countless hours spent arguing about what we do and do not like. At one point our art director took some of the concept art we got and had to draw over it, just so we could all agree. That wasn’t his job, and for a while that was our biggest bottleneck.

Being Anal!

Perfectionism. Perfect Quality. These are the signs of someone who doesn’t know when to just say “it’s good enough”. When you are working with a schedule, and hundreds of assets to manage, and even more hundreds of lines of code to look over, you cannot be anal about every small detail. Your game will simply never be finished.

It is alright to go back and touch up some assets, but to completely remake them? That is hours wasted. Our boss was that type of person, who came into our office one day and said “we are going to delete the trees we made a few months ago and start over with this new way and idea”. Sure, I am all for having a beautiful game, with beautifully crafted high quality artwork…But this? When you don’t even have an IP to work with? When you are being hassled by the investors on a weekly basis asking you, like some child in the backseat, is it finished? Are we there yet? You are asking us to go back and erase hundreds, literally hundreds, of hours spent on assets.

Touching up assets should take no more than 2 hours at most, if it’s a texture change then it shouldn’t be too drastic. If you are the type of person that knows you're going to go back and make massive changes to your artwork then design the workflow so it can be done extremely easily.

If one is to go back and play World of Warcraft, and run into Ironforge, the dwarven capital city, you will find that the floors do not always align perfectly, and that there are UV maps which are upside down on some of the columns. And this from a game which took $200 million to create, from a company which is known for some of the highest quality games?

Be the Leader!

We had very little leadership. Nothing was accomplished unless everyone had a consensus on the subject at hand. If one person disagreed, it would mean we would spend hours upon hours trying to convince them or negotiate. In the end, this took away time from building the game. In the end, very little was actually made. Sometimes it's great to hear what your employees have to say about the game, as an employee and a creative person I loved giving them my opinions, and where I thought the game should go. But I sincerely wish someone would just say "No, this idea is good, we are going to go by it, end of story", even if the majority believes otherwise. Leadership is pinnacle.

A game company is not a democracy. It is a business. It has a boss, a hierarchy of employees, and each one has their share of responsibilities. It might seem cruel, and it might seem like “Oh I don’t want to be like ______ company and not care what my employees say”, but you are in every sense of the word: the boss. And despite what you think, when you make a hard decision and stand by it, through thick and thin, your employees will feel more confident. They will feel confident in the entire enterprise, the company, and in you, and that’s key for a high level of efficiency.

Publishing and Recognition: Everyone has something at stake!

I've always said it's better to publish a shitty title than to go entirely bankrupt trying to make the next Halo. This held so true in the company I worked for. When we canceled the first project and started on the second one, we got very far, and many times I said we really should Publish it as is and add patches, add fixes, add things for free if need be. To publish it and to see profits roll in, even small ones, would have been unbelievably wonderful. Even if we published as a free-ware game, something people can download and play free of charge, it would be out there, we would have recognition, and a growing community.

If at one point your gut instinct tells you “This game will not be finished in the time allotted” redesign your design document to make it so the game can be finished. Even if you only have 2 weeks of funding left, try to figure out a way to make it so no matter what your game is released. You might not sell many copies, you might even lose money on the whole process, but you have a game out and you can always release patches and updates when needed. Nowadays more and more games come out only 95% finished. Some don’t even finish the quality assurance stage, yet are released; the reason for this is much tighter schedules by big name companies like EA.

Last year I bought a game, Sim City Societies, which initially was extremely awesome, but it was incredibly buggy and it took a good whole month and a half before they released a major patch to fix the bugs. It sold fairly well, despite the bad reviews. Because you know what, in a year or two no one is going to remember those reviews at all, and when you have something out, people can Google it, and say “Ahh they made that game ok”.

But did you know your staff benefits from a released title more than the game company? I will explain in the conclusive statement below:

It's hard for a start up to get started. I know this, we all know this. Some of us will get very lucky and make the next big hit. But one thing a lot of startups forget is their own employees. I have worked for this company for nearly 2 years, I made a lot of friends, I learned a lot, and I made a lot of good money. But now I am on my 4th month of unemployment, due to the fact that I am still considered an entry level artist even though my artwork does not show that at all (Or so I quote my agent).Talent goes a long way in the industry, but it is secondary only to experience, and experience is one of the hardest things to prove unless you have a title under your belt. Talent get’s you in, but to move up, get newer, better positions, there is nothing more valuable than to say that you worked on a title, or two, it shows you know how the process of development is. Only rarely do companies ask for you to have worked on titles that were big hits, and sometimes working on a more well-known title, than a title that was excellent or good is more valuable.

In an industry where the product can take anywhere from a month to a couple of years to create, reputation is key to attaining new investors, and maximizing your base. Start small, plan ahead, grow a reputation, grow a steady income of wealth, and grow your IPs. It is a long climb up, but if you try to shortcut it, you’re going to turn a hill into a mountain, and I’d rather climb a hill than a mountain.

-Roman Lembersky-
http://3dsphere.net/
Chewybunny On GameDev.Net

Sitting at the table were, on one side, a casually dressed young man and woman who looked like budding game developers. On the other side of the table was a nice looking fellow, not much older, wearing a suit, but no tie (publisher informal I presume). There were papers on the table and it appeared that tieless publisher’s representative was going through the document and explaining the elements of the contract to these rookie developers. It had 1st deal written all over it. It also had disaster written all over it as well.

I was horrified. I wanted to get up, go over there and make them stop. “What’s the big deal?” you say. After all, they weren’t signing the deal. There was no indication that they even believed what he was telling them or trusted what he was saying. They could have a decent lawyer or business agent at their disposal and were really just having a little discussion so that they could get clear on the deal terms. Besides, the suit seemed like a decent enough guy and for sure knew way more than they did but this sort of thing. Who better to ask? No harm, no foul . . . right? Wrong!

Certainly anyone new to the business end of the games can gain a great deal from talking with folks with experience in the industry. And who does more deals than a publisher’s rep anyway? There is for sure a big difference between making a great game and making a great game deal. So, it’s natural to want to acquire as much information as possible when looking at getting that first deal. It’s just that the publisher’s representative that you are looking to get a deal with is the last person you should be getting this information from, even if he or she is a great person and being really straight with you.

First - the obvious. No matter how much he may love your game (he would not be talking to you about a deal if he didn’t), this guy works for the publisher. That means that at the core, he is on the other side of the deal and has substantial responsibilities to their employer that he must honor. More importantly, unless he has experience on the developer’s side of game deals (and some publisher reps do have this experience) even if he really wanted to help you out he still doesn’t have the developer’s perspective on a deal. The reality is that a publisher’s rep will not give you anything in a deal that you are not savvy enough to ask for, even if he or she could deliver it as part of the deal if you did ask.

Second, you immediately make the publisher’s rep the authority on this deal. He’s the one who “knows” and you are the ones who don’t! You see, even if your publisher’s rep is a great person and wants to help you, you have giving up your bargaining position by revealing your lack of experience relative to the business of games. Once that impression is made on a potential business partner, it will stick for the duration of the relationship. Moreover, even if they do not want to intentionally take advantage of your relative naiveté, once they know that you do not have a solid handle on the process or what to expect, they will be in the position to dictate the entire deal. There is really no need to let a potential publishing partner know exactly how green you really are. After all, many new developers have folks on board with business experience and the more competent the publisher rep believes you are, the less likely they are to take advantage and the more likely they are to accept provisions favorable to your interests.

This does not mean that you should misrepresent your level of business acumen. Just don’t broadcast your lack of it. Stay cool and take your time. Don’t spill your guts and try not to go all giddy just because someone who can help get your work to market actually likes it. After all, you are in the dream business. Making your dreams into reality is what developers do. So, don’t go all “school girl” if someone takes a shine to your work and you begin to succeed. It happens. Maybe not as much as we would wish, but it happens every day. Play your cards close. Don’t jump at the first indication of a deal. Do not let anyone push you into or through a deal. If you are lucky enough to get into a negotiation, take your time and go slow.

There is a scene in the film adaptation of Steinbeck’s “Cannery Row” where Nick Nolte’s character Doc, a marine biologist working on the cannery row, takes Suzy DeSoto, a hooker from the local brothel played by Deborah Winger, out to a fancy dinner. She has never been to a place like this in her life and is worried that she will not know what to do as the meal progresses, what with all the numerous different forks, spoons and such. As Suzy narrates the experience, she gets through by making her moves mirror Doc’s and always stays a little behind him, going slowly move by move through the entire meal. And in the end, she pulls it off and it worked out fine. No one even suspected that she was in way over her head the entire time. Similarly, when you move into a deal scenario, take your time. Don’t broadcast your inexperience. Everyone naturally assumes that those they deal with are as competent as they are. So, don’t show them different. And for someone starting out in this business, that just may help get you a deal that is better than the one that might otherwise have been offered.

The assumption that every developer gets screwed in their first deal need not apply in all cases. It sure doesn’t have to. So, take your time Suzy . . . and things may just work out all right. I sure hope it did for those folks at the Marriott!

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney © 2007
www.gameattorney.com

A Rather Extreme Example

Several years ago I was working with a team that had done a very successful PC Mod who were transitioning into an independent development studio. Their agent had contacted the Publisher of the game they had done the Mod for, trying to get its OK to commercially release the Mod. The publisher would not allow it. But, in order to keep upgrades to the Mod coming out to help drive sales of their game, the publisher agreed to pay the team to continue developing the Mod. The new Studio retained the IP rights, but gave up control over the release dates of its updates to the Mod. This allowed the publisher to time the update releases for the free Mod so they would not compete with the publisherÆs own expansion pack release dates. Overall, it was a pretty good deal for the Studio. Not as good as a separate commercial release of the Mod. But, certainly enough to help them get their team together and start acting like a real studio.

With all the deal points in place, the Publisher sent over the contract for my review. I was dumbfounded. The written agreement they send was a ôwork for hireö subcontractor agreement; the type of contract publishers use with outside individuals or companies that they hire to work on their own games. It transferred all IP in the original work to the Publisher and did not have one single element of the deal that the agent and PublisherÆs representative had spent months working out. My first reaction was to throw up my hands and send it back to them, asking for the correct contract because, obviously, there must have been some clerical mistake. I was told that I should work from this model and modify it to comport with the terms of the deal. That meant that I would have to basically redraft an entirely new agreement from scratch because, except for the ôboilerplateö (the General Conditions at the back of the contract) everything else was wrong, wrong, wrong!

So, I dug in and pretty much rewrote the entire agreement, even correctly renaming it ôMod Development Agreement.ö When the Publisher saw it they refused to even review it because I had removed the PublisherÆs name from the Agreement and they said they could only use their own form contracts. So, I did the only sane thing I could...I pasted their name back on the top of the contract and sent it back. That seemed fine with them and we got the deal with the correct terms. But, it would have been a disaster if the Studio had just signed the first written agreement the Publisher sent. You have to wonder why, after two or three months of negotiation, the Publisher would send a contract that did not even vaguely resemble the deal they had cut. Well in practice, this is not at all an uncommon scenario - just a rather extreme example.

ItÆs the Nature of the beast

I rarely see an initial written contact that accurately reflects the actual negotiated deal points, especially when the deal is at all different from the standard deal offered by the Publisher. The reason is that in most publishers the product acquisition team has little to do with the detailing the written contract once the deal is negotiated. The product acquisition lead is already on to the next deal, after telling the contract person that they have a deal to acquire a game and to get the written contract done. The folks who do the contract work are usually in the legal department if itÆs a large publisher, or one of the business leads in smaller ones. The person handling the written contract may not even have been briefed on the deal points. Or maybe they just think itÆs easier to send the standard base contract and let the developer fix it, if they have the patience and skill to do so. So, the contact person usually just sends out the standard agreement for publishing deals to start the process. And these base publisher contracts range from extremely publisher friendly to darn right predatory.

The results are things like the publisher presenting the development studio with a ôwork for hireö agreement when itÆs a license deal with the developer is retaining its IP rights, missing participation in movie and other ancillary revenues or a deal with no escalating royalties, even though they have been agreed to early on in the negotiation process...little things like that. These may be classic examples of one hand not knowing, or not caring, what the other agreed to. But remember, it is not the publisherÆs job to make sure you get the deal you negotiated. That is your job. ItÆs the publisherÆs job to get the most out of every deal for the publisher. The publisher may not even intend to cheat the developer out of the deal they agreed to verbally. It may just be their administrative overhead getting in the way of a written contract that actually reflects the original deal discussed and verbally agreed to. But be sure, if you sign a written agreement with the wrong terms you can and will be legally bound by it. Because, all of these agreements have a standard ôincorporationö clause that says that the written agreement is the final agreement and any verbal representations made in the negotiation process, not in the written agreement, donÆt count.

Patience Pays

So, after you verbally negotiate the best deal you can, be ready to start the process all over again in the written agreement. It helps to do summary emails to the publisher representative during throughout the negotiation process, summarizing the deal points as they are agreed to. You may need these emails later to remind the person doing the written contract what was discussed and agreed to already. When you get that first proposed written contract donÆt be offended by it, or take it personally. Like the mob boss says in the movies, itÆs nothing personal, itÆs just business. Besides, they donÆt really think you are that stupid (though they can always hope!). It is best to just look at it as the clumsy way things get done around here. If you are at all unsure of what you are doing or just donÆt want to deal with the hassle, get professional help. Be patient and never sign a written contract that does not accurately reflect the deal you made. Most of all, remember, ôillegitimus non carborundumö- donÆt let the bastards grind you down!

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney
www.GameAttorney.com
¬ 2007

_{[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 200_, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere.]} ]]> Tue, 07 Aug 2007 22:16:13 +0000 aa49af1072b367b0a3342314401297a9 http://www.gamedev.net/page/resources/_/business/business-and-law/the-good-news-about-digital-distribution-r2384 In 2005 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.

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, Trimedia'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 WW II 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 hard core 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 build. 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 Orshestra: Ostfront 41-45 is set for release in March 2006 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 a 1gig plus 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. And Sony and Nintendo are not far behind. The size of the game that can be downloaded on XBLA is limited, which limits things somewhat when compared to PC downloads. But it is a huge potential market. Of course, access is also an issue. AS access to the XBLA pipeline gets clogged with legacy titles from publishers who are already XBLA certified, we are seeing 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 and both Sony and Nintendo have different models.

The big question is, will the PS3 and Nintendo WiiWare digital distribution garner the same level of success at XBLA has thus far? I suspect that they both will meet or exceed the relative penetration that MS has. NintendoÆs open marketplace without reserved slots and SonyÆs recently announced ability to allow console and PC gamers to play on the same servers with access to user generated content (thatÆs right kids û user created mods on a console!) will give each a significant discriminating USP (Unique Selling Point) in the market. So, now that Sony and Nintendo are doing digital distribution in their next gen consoles, who knows? 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 youÆre 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.

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney
www.GameAttorney.com
¬ 2007

_{[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 200_, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere.]} ]]> Tue, 07 Aug 2007 22:02:22 +0000 20d534ef3fe79831c525d1a218cc2818 http://www.gamedev.net/page/resources/_/business/business-and-law/audit-rights---use-em-or-lose-em-r2383 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, if a discrepancy of more than typically 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 fill on the publisherÆs end. You see, if developers donÆt enforce their audits 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.

I was on a panel discussion at the Microsoft Meltdown in Seattle a few years ago where we were discussing publisher deals. This was a ôpre contract through gold masterö sort of discussion and prior to the presentation I asked the panelists 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 - 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.

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 anyone elseÆs.

Til next time, GL & HF.

Tom Buscaglia
The Game Attorney
www.GameAttorney.com
¬ 2007

_{[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 200_, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere. The sale or any other commercial exploitation of this article, in whole or in part, is strictly prohibited.]} ]]> Tue, 07 Aug 2007 21:58:25 +0000 47e03d48d5f53f03563daa7f1373fb09 http://www.gamedev.net/page/resources/_/business/business-and-law/to-sue-or-not-to-suethat-is-the-question-r2382 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 law suit 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 cost-benefit analysis that a developer should be considering when a question of filling 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 law suit to recover their loses. 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.

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 law suit? Can you afford the costs of the law suit 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 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.

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 under 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 he can not afford the $60,000+ in attorneyÆs fees it is going to take to fund the law suit. 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. And the additional gratification of knowing that you didnÆt just lie down and take it again can be very gratifying as well.

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.ö

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney
www.GameAttorney.com
¬ 2007

_{[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 200_, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere.]} ]]> Tue, 07 Aug 2007 21:54:45 +0000 9a1d8e7dcd9cc4fd0e9806ea87e3105f http://www.gamedev.net/page/resources/_/business/business-and-law/a-case-for-flexible-milestone-deliverables-r2380 Introduction

ôMilestone Deliverablesö are interim and final assets delivered to the Publisher by the Developer throughout the term of the development agreement. The approval of the ôMilestone Deliverablesö by the Publisher triggers the payment of the ôAdvancesö that fund the ongoing development process. These Milestone Deliverables are defined in the Publisher/Developer Agreement, often in minute detail. This article 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 $5mil - make me some!ö

As the stories go, in the wild and wooly early days of the Video Game Industry, Developers were funded by Publishers by 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 top 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 most 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 and 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), 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 for an evolving industry, as our industry matures we need to find ways to accommodate this disparity. Not just because of the unreliability of the deliverable schedule, but because great games require iteration. And iteration can not 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,Æ that is, 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.

Til next time, GL & HF!

Tom Buscaglia
The Game Attorney
www.GameAttorney.com
¬ 2007

_{[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 2007, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere. The sale or any other commercial exploitation of this article, in whole or in part, is strictly prohibited.]} ]]> Tue, 31 Jul 2007 21:03:30 +0000 ab9a3f4c92c0f50204a1fe6dbf2e1d0a http://www.gamedev.net/page/resources/_/business/business-and-law/women-in-game-development-part-6-r2270 Attracting Women Into Game Development," brought up a wellspring of discussion and, as co-moderator, I had a front row seat I'd like to use this column to explore the topics on my mind. It's good timing because of late there seems to be much more activity and interest in women's issues. GDC05 even had a suggested Women's Track that covered such disparate areas as sexuality in games, recruitment, female game players, and quality of life issues.

I recently spoke to Tammy Yap, the Midway programmer profiled in the July AP article "Programmers: Video Games Need Female Touch." She elaborated on her thoughts concerning women in the industry. Noting the need to reach the younger generation, she stressed the importance of good role models for girls and young women interested in technology. She cited an MSNBC report that stated that college women have shied away from computer science and, despite the fact that more than half of the college population is female, their enrollment numbers in computer science are as low as they were in the 1970's. That's alarming, considering programming and other game development skills figure greatly in what the 2004 IC² Institute research paper, "Gaming: A Technology Forecast," termed 21st Century science.

How can we interest girls and young women in computer science? We need role models that are visible and approachable. Indeed, during the GDC05 roundtable discussion, one woman remarked that she felt more comfortable applying to her current company after she learned that the President of the company was a woman. She felt assured that her concerns would be taken seriously. That's why I am so thrilled about the formation of Women In Games International (WIGI), a new organization for women in the game industry. I think such an organization is an important step in the maturation of our industry.

Groups like Women in Technology (WIT) and the Society of Women Engineers (SWE) already exist, so this isn't a foreign concept. They are, however, too broad or too limited to encompass all that amounts to the game industry. Programmers are necessary, but so are animators, producers, designers, and various multi-talented folk who can do more than one job function. The game industry has its own specific issues. Certainly, the IGDA has been supportive of the Women in Game Development SIG and its active mailing list. Still, when I visit local chapters around the country, I wish there were more women in attendance. More outreach would be helpful. A professional women's organization could benefit both the industry and its membership.

A professional women's organization, if it had local or college chapters, could rally interest in game development careers and try to break down the misinformation. In the public's perception, games are viewed as the pastime of young men or children. Plus, the games that are publicized have violence and controversy. A young woman interested in making games faces a hurdle: society has an image of women as caregivers and this cultural image doesn't include a PS2. Moreover, a professional women's organization would give a public focus to women's issues in the industry.

Ultimately, a young woman would know that this is a community where she could learn more about the experiences of women working in the industry. Through local chapters, she would meet like-minded others and learn more about game companies in the area. Perhaps she would find a mentor. While there are well-known female game developers that serve as role models, what is great about an official organization is that all of its members can be mentors and role models. It is this personal connection to the community that will make the difference. With that, she has the self-confidence and support to forge ahead. Perhaps now she will get that job referral or advice on putting together a portfolio.

On the flip side, for companies, this organization might be the ideal place to find qualified female applicants, thus increasing diversity in the workplace. We are all interested in industry growth. The game industry is banking on female buyers to sustain its growth. Will increased diversity lead to more products with universal appeal? That's the theory. Girls find products that appeal to them and in turn, more of them become interested in game development. Our industry becomes more mainstream and even bigger.

Furthermore, I believe that a professional women's organization in the industry would give us the opportunity to get real stats on the table. Are women only 10% of the game development community? Or is this number based on anecdotal evidence? By polling its members, the organization could find out what its membership cares about and suggest ways to improve industry practices. These numbers would give weight to these recommendations, especially if we find out that there's a lot more women in the industry than we thought!

For a lobbying effort, a collective voice is always louder than a single one. In 1994, women professors at MIT banded together to compare awards, titles, grants, laboratory and office space given to men and women. The MIT administration was forced to concede that discrepancies existed. Subsequently, the women received higher salaries or other perks.

I look forward to seeing WIGI's progress. Already, over 450 people have registered for its inaugural Women in Games International event, "Advancing Your Career in Game Development: The Women's Perspective." Sessions include "Breaking In: How to Acquire The Skills and Get That First Job" and "The Executive Perspective."


Need more information? Look here:

• The Women's Game Conference (WGC) will happen on October 26 - 27, 2005 in Austin, Texas. Microsoft is holding a scholarship contest targeted towards female students in computer science who are interested in attending the WGC. Deadline: September 30, 2005.
• Find these links and more on the newly redesigned IGDA - Women in Game Development SIG page!

Today's question comes from Soren Dreijer as follows:

Question: Protecting game ideas
Soren Dreijer

I have something I've given a bit of thought lately. Say you have this brilliant idea for a game or some software but you need a publisher or someone who can finance your project. You then setup a meeting with an interested company. How can one assure that when you've told the the other party about your great idea that they won't just "steal" it (in the sense that they some months later release an almost identical product)? How can one make sure the other party won't just take your idea?

Answer:

While the content of your game is protected by copyright, the ideas and other aspects of your project and company are not. Under the laws of copyright it is only the expression of an idea that is protected by copyright, not the idea itself. So, Soren correctly wonders, how does he talk about the ideas behind his game without putting his entire project in jeopardy?

Let's start with a little general background on this type of intellectual property (IP). Confidential information is technically referred to as Trade Secrets. And any information, including ideas for games and gameplay, are protected as Trade Secrets so long as these ideas took special talent and time to develop and the company treats them as secrets. Information released to third parties or to the public is not protected under Trade Secrets law, but information that is treated as secret is. When this confidential information is revealed to a third party its status as Trade Secret information is jeopardized. So, it is not just concerns about the trustworthiness of the person that you want to talk about your game to that is the issue here. In order to protect your confidential information from losing its status as Trade Secret or from unrestricted distribution it is important that developers use a Non-Disclosure Agreement (NDA) anytime that they communicate with third parties. It is also just as important that they treat the ideas or other materials that they think are confidential as such internally by treating them as secrets. This means that you don't make public posts about your confidential materials and that you and everyone else who is involved in your project sign contributor agreements acknowledging that fact that this stuff is secret and agreeing to keep it secret.

There are different types of discussions that will occur in the life of any developer. So, there are different types of NDAs. When a developer is discussing his game with a third party that is not in the game industry, such as potential investors, or non-creative employees, a Unilateral NDA is appropriate. A Unilateral NDA protects the developers creative materials that are retained in a confidential environment from being divulged by any third parties not within the scope of the developer's business. The signatory acknowledges the confidential nature of the information being provided and agrees not to disclose it to anyone else without the Developer's written permission.

While a Unilateral NDA is great for dealing with people outside of the industry, they are of little use when dealing with publishers or other developers. That is because publishers and other developers have their own confidential information that they need to protect in conjunction with their discussions with the developer. The solution to this dilemma is the Mutual NDA. The Mutual NDA allows for the exchange of confidential information between developers, or between developers and publishers in a manner that allows both of their property to be protected and still revealed to specific individuals on a need to know basis.

It is not unusual for a publisher to provide their own special Mutual NDA for execution prior to talks with any independent developer. But be sure to read what you are signing. At times publishers will use these agreement to shield themselves from exposure while at the same time stripping the developer of any real protection. For example, I reviewed a Mutual NDA from one publisher that included language that while acknowledging the confidential nature of the materials provided to the publisher by the developer, stated that any discussions between the publisher and developer were not confidential. This additional provision pretty much gutted the developer's protection. If you are that close to a real deal take the time to carefully review the NDA you are being asked to sign. Or better yet, pay a competent lawyer to review it for you. That way, at least you understand fully what you are signing before you take the plunge.

That's the legal advice. Now for some practical advice. When you are pitching your deal to potential investors you should endeavor to instill in them a sense of value in you and your game project. After all you are asking them to invest their money in you and they need to achieve a decent comfort level before they will consider doing so, unless they already know and trust you. Presenting a potential investor with a unilateral NDA before you discuss the details of your project, or give them a business plan or design document to review, shows them that you are serious about what you are doing and competent enough to protect your and their financial interests. So, do not look at asking a potential investor to sign and NDA as a burden. It is actually a great opportunity to show them you are serious and competent.

Publishers are used to Mutual NDAs and usually have their own ready for you. Though some publishers don't like to sign them at all. Sometimes this is because they have so many internal projects in the works that they feel the risk of signing an NDA and then releasing a game similar to yours and incurring possible exposure is not worth it to them. Sometimes it is because they are looking for free ideas! If a publisher does not present you with their mutual NDA, give them yours. If they say they do not sign NDAs, try telling them that you need it because if you tell them your super secret idea without one it will no longer be a secret and anyone, including your employees who you made sign confidentiality agreements, could use the idea with impunity. If that does not convince them to sign your NDA then you have to simply decide how desperate you are to show your stuff and take a shot or walk.

In reality most legitimate publishers see so many ideas a year (literally thousands) that they could care less about your idea no matter how cool you think it is. But without the legal protection of an NDA you leave yourself open to the unscrupulous quasi publishers that often prey on start up developers looking to take advantage of them any way that they can. And that does include poaching ideas if they are good enough. So go for the NDA and if they are refusing to sign one, check them out before you show your stuff by searching the game development forums or even ask for references from other developers who have dealt with them to make sure that they are worth dealing with. After all, there are worse things than not getting a deal with a publisher. One is getting a deal with a publisher who takes advantage of your passion to make games by stealing your work! So, be careful out there....

Until next time - GL & HF!

Tom B

BIO

Tom Buscaglia - Lawyer, Game Industry Evangelist, and Hardcore Gamer.

Tom Buscaglia is an attorney practicing technology law in Miami, Florida. In addition to obtaining his Law degree from Georgetown University in 1985, he holds a B.A. degree in Philosophy from S.U.N.Y., Buffalo, with honors in Phenomenology and the Philosophy of Law. Tom is a principal in the law firm T.H. Buscaglia and Associates in Miami, Florida, where he practices law for a living and plays computer games and philosophizes on the side. Tom's firm's web site is www.gameattorney.com.

Tom is dedicated to the computer and video game industry, assisting developers in all aspects of their legal and business needs and has been representing game developers since 1991. Tom was the main business and legal presenter at the 2004 Indie Game Conference in Eugene, Oregon, speaking on Effective Developer Contracts as well as Legal Issues to Consider When Starting a Game Development Studio. He presented again this year at the Game Developer's Conference in San Jose on developer/publisher deals and contracts in a presentation called The Negotiation and a round table discussion on the Publishers "Rules of Acquisition". Tom was on the Game and Simulation panel at the The Interservice/Industry Training, Simulation and Education Conference (I/ITSEC) and was the Keynote Luncheon Speaker at the 2003 Summer Simulation Multiconference in Montreal, Canada, sponsored by the Society for Modeling and Simulation speaking on The Game and Simulation Industries: Convergence or Collision. He wrote the chapter entitled "Effective Developer Contracts" for the book, The Secrets of the Game Business. He is a contributor to numerous International Game Developers Association, Business and Legal Committee, publications including: the Publisher Contract Walkthrough white paper, on Game Documentation and Trade Show Demos and Termination Provisions; the Game Submission Guide on Legal Issues and the soon to be released Intellectual Property white paper on IP Contracts Independent Developers Sign. Tom published a series of online articles on www.GIGnews.com to assist "rookie" game developers on the legal issues they should consider when starting out in the game industry entitled Initial Legal Issues, What are these games made of…legally speaking and Completing your Contract Arsenal. Tom was a presenter at the 2002 Game Developers Conference, in San Jose, California, on  the topic of "The Phenomenology of Game Design". Tom has been a guest lecturer at Full Sail in Orlando, Florida, giving a presentation to the Game Programming students on Intellectual Property and what to look for, and look out for, in their first employment agreement.

Tom is the Founder and Executive Director of Games-Florida, a non-profit committed to building the Computer and Video Game development industry in Florida by bringing Florida to the Game Development industry and bringing the Game Development industry to Florida. www.games-florida.org He also sits on the Advisory Board of the Digital Media Alliance of Florida www.dmaflorida.org recently participating in a DMAF Panel Discussion with Florida game industry leaders at Full Sail in Orlando on The Future of the Game Industry in Florida." Tom has been the Chapter Coordinator for the South Florida Chapter of the IGDA since its inception, and is a moderator for the Business and Legal forums on IGDA web site, www.igda.org.

As FaTe[F8S] Tom is the founder and Supreme Warlord of FaTe's Minions, an online gaming "clan" that has been competing in various online competitions since January, 1998. www.f8s.com As a "hard-core" gamer, Tom plays online on a regular basis and has a gamer's appreciation and understanding of the game industry.

• www.deviantart.com is a resource for artists, though it can be difficult to find what you seek at the sight, it is well worth it.
• www.modarchive.com for MOD/MO3 music. MOD music is a popular indie choice for music, since it is easy to find someone willing to do it cheap or free, and it takes up far less space than an OGG or MP3. I used their chat room and was able to get a great deal of interest from the people there.
• www.igda.org and www.gamedev.net for programmers and technical personel.
• www.dexterity.com/forums is an excellent resource to meet other indie developers as well as www.gamasutra.com and if you are a member: www.asp-shareware.org/
• josh@gametrailers.com gave me permission to post his contact info. He is a go to guy for having a game trailer custom made for a very reasonable price (Mention VGsmart and/or this article for a special discount).
• www.vgsmart.com A shameless plug for my own company, which specializes in marketing for indie video games.