[MUD-Dev] [BIZ] TEN MORE EASY WAYS TO SCREW UP YOUR GAME COMPANY

[Michael Tresca]

From: http://www.gignews.com/fdltenmore.htm

Mike "Talien" Tresca
RetroMUD Administrator
http://michael.tresca.net

--<cut>--
TEN MORE EASY WAYS TO SCREW UP YOUR GAME COMPANY
by Francois Dominic Laramee

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.

#1. Merrily Sign Under-Specified Contracts

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.

#2. Promise The World And Fail To Deliver

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.

#3. Fight, Fight, Fight With Your Publisher

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.

#4. Grossly Under-Utilize Assets

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.

#7. Underestimate Your Staff's Importance

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.

#8. Overestimate Your Strength

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.

#10. Give Up Too Fast

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.
--<cut>--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev