1 October 2000

Last January, before this esteemed web site got on the air, I wrote an article describing ten easy ways to wreck a perfectly good game startup without even really trying.

I expected that particular piece to incite at least a few death threats, which would have cemented my status as Respected Author (tm). No such luck; the response was almost unanimously positive, leaving me immensely disappointed. However, there was so much response from all over the business that, in good game industry fashion, I just had to churn out a sequel.

Here it is, then: ten more ways to run your very own studio into the ground and, if past history can be trusted, get a better paying job in the process.

A couple of years ago, I learned a little bit of trivia that scared the bejeezus out of me:

There are more practicing lawyers in the United States today than there were in the entire history of the World up to 1970.

But here's the real kicker:

There are more students in American law schools today than practicing lawyers.

It's hard to imagine what society could possibly do with so many attorneys. (Soylent Green comes to mind, but for some reason I don't think it would fly.) However, legal counsel becoming dirt cheap and/or having to create their own jobs in the near future is a distinct possibility, with the result that more and more companies of questionable ethics will be trying to weasel you out of your hard-earned money in the courts instead of doing real work.

Even today, errant wording in Article 32b) of a publishing contract can cause irreparable damage to your company. Talk to a good lawyer early and often and don't assume anything. If Clause A is not in the writing, you can bet your last dime that the other guys will deny agreeing to it verbally if circumstances change and it's no longer in their best interest. A competent lawyer will make sure that:

• Milestones are clearly and unambiguously defined in the text, so that you will be on solid ground when it comes to demanding those payments. Some publishers have been known to drag payments (and starve developers) until they could squeeze an extra concession or two in mid-project.
• The publisher's right to demand changes is strictly limited, especially when work that has already been approved is concerned, so that he can't drag development for an extra 6-8 months at your expense. As long as cost is yours to assume, the other guy will feel free to run it up.

Play it safe. When you write the publishing contract, add a clause listing, in great detail, what absolutely has to be in the final product and what can be taken out without penalty in cases of force majeure, if the publisher pushes up deadlines, demands last-minute changes or refuses to give you an extra month when your entire programming team comes down with mononucleosis. Trust me: it's worth taking less money now to reduce your risk, because you can be darn sure that failing to meet signed requirements will cost you a lot more down the line.

In this case, the further into production you get before signing the contract, the better: if 80% of intended functionality is already implemented and tested, there won't be much in the "if we have time" section and you can demand more cash up front.

If you followed my advice in areas #1 and #2, this shouldn't happen... But it will.

It's one of this industry's dirty little secrets that some publishers promote their "internal producers" according to how much of their input makes it into the final product (i.e., how many useless changes they push through) or how much money they save the company (i.e., how many extra features they cajole or threaten the developer into adding at no charge.) Again, being extra careful with the contract's wording will limit the risk of aggravation.

Conversely, if your publisher acts in good faith, it is your job to keep them happy. Be forthcoming with information; talk several times a week, every day if necessary, to keep them abreast of your progress. This way, you will build up their confidence in you, and they will be more likely to let you deal with problems your own way instead of parachuting one of their trouble-shooting experts into your studio at crunch time.

Some licenses come with enormous libraries of music, cut scenes, characters, etc. Use this stuff; it'll cut your costs and speed up delivery. Obscure licenses may be worth picking up on the strength of these ancillary assets alone, even though they might not generate much in the way of extra sales. For example, if you are producing an adventure game set in Chicago in the 1930's, you might be able to acquire dozens of hours of music for a few thousand dollars if you license an old gangster TV series to which composers sold all of their rights. Might be worth investigating.

You may also save a nice chunk of change if you buy second-hand assets: 3D libraries, second-run music, etc. Movies do it all the time; I have heard one of my favorite pieces from the Bruce Lee biopic "Dragon" in at least 3 other films. Remember: the perfect song for your game is just as valuable even if it wasn't written specifically for you.

#5. Hoard Information Like It's Worth Millions (Cuz It Is)

Organizational behavior scientists all agree on this: employees who feel that their work is making a difference will be far, far more productive. Once a week, maybe during the Friday afternoon beer-and-pizza party, you should update everyone on the projects' progress. Sounds simple, right? You would be surprised at how many managers don't bother. Even if it has been proven that productivity starts to tail off after about two weeks without any reinforcement.

On a related note, short milestones equal frequent small victories, which are great for morale. Don't overdo it, though; I once spent a few months at a software company which released a version of its flagship package just about every day, so after a while nobody cared anymore. Reaching a minor milestone every 5 to 10 working days is about perfect.

#6. Take Too Many Risks At Once

Among science fiction writers, there is a concept called the "Tooth Fairy Rule", which states that you can only invoke a mysterious outside force (i.e., the Tooth Fairy) to explain the unexplainable once in a story. Otherwise, you can't really expect to maintain suspension of disbelief.

In game development terms, the rule translates into this: Only promise (at most) one feature which you have no idea how to implement. Do not assume that your R&D team will miraculously come up with a sentient AI and true holographic 3D in the next four months. Not even if it's the only way to get a particular contract. If that's what the client demands, walk away and survive to fight another day.

Knowledge is our business. Protect it. Budget an extra 10% to give your programmers time to study each other's code and establish redundant expertise. This way, if one of them leaves your company for any reason, you won't suddenly find yourself stuck with 100,000 lines of quaternion code written in Linear B.

This is equally true of your clerical staff. Imagine the horror if your accounts payable clerk designs a clever new spreadsheet to track down expenses and quits before explaining to anyone else how to recover the past five years' worth of invoices.

Let's face it: we game developers don't have much to be macho about, so when we have a reason to brag, we do. And more often than not, that reason is our endurance in front of the computer.

Recently, someone told me that the typical amateur attendant at last year's XGDC boasted of his 48-hour-straight coding binges as if he had single-handedly bagged a T-Rex with a Super Soaker. Well, that type of stamina doesn't last. It won't be there past 30, it won't survive the first serious relationship trouble, you can't count on it once you have a baby, and it will break down after about 4-6 weeks of non-stop overtime even if nothing else does.

Know how many hours you can work on a regular basis, and how many you can put in during a short crunch period. Don't sign up for more. For example, I know that I am very easily bored, and that spending more than 25 hours a week on the same project tends to grow real old, real fast for me. That's why I remain a freelancer and turn down full-time jobs at four times the money every month. If you own a company, don't assume that your entire staff can and will work 50-60 hours a week for long periods; some people will do it cheerfully, some can't handle it, and some just have other priorities in life. (And those who will turn out to be the most cost-effective over a given year are not necessarily those you think.)

#9. Always Go For The Big Buck

Sometimes, establishing a long-term relationship with a client is worth more than a quick profit.

In this day and age, the game publishing industry is consolidating at Warp speed. There are fewer and fewer (major) potential clients for a new development house, each of which is becoming bigger by the minute. And like any of us, these guys prefer to deal with developers they know and trust.

Build a strong relationship with a company like that, and you can count on steady (and increasingly lucrative) work for a long, long time.

Here, I am specifically thinking of one company, which I have slammed in the past because of what I felt were some grievous mistakes. If anyone had a right to call it quits, it's these guys: they had been in business forever, had tried several business models, and ended up with very little to show for it. But they picked up the pieces, rolled up their sleeves and tried again.

And you know what? This time, it worked. They are now a respected mid-range publisher with several critically acclaimed titles and talented internal development teams.

So if you fail once and still feel the urge to try again, do it. The taste of success will be that much sweeter.

>>> 20O2 UPDATE!

Bio
François-Dominic Laramée is a freelance interactive game designer, developer and producer.  He has been involved in one form or another of the game industry, whether PC, console, online, set-top box or even play-by-mail, for the past decade, including more than 8 years of experience as Head of Studio, Game Designer, Software Engineer, Producer and Quality Assurance Manager in the interactive entertainment and spoken dialogue interfaces industries.  Learn more on his website at: http://pages.infinit.net/idjy/ 

GIGnews is a publication of GIGnews.com, Inc.
"Get In the Game" is a registered trademark used with permission.
© 1999- 2005 GIGnews.com, Inc.
Legal