[MUD-Dev] Jeff's Rant: A World Full of Wheel-Makers

[Bruce]

An old list member, Jeff Kesselman wrote:

http://www.javagaming.org/WeeklyRant/weeklyrant.html

Thanks to Greg Munt for tossing this my way. :)

I couldn't find a archival URL for this, so here it is in its entirety:

=== begin quote ===
Jeff's Rant: A World Full of Wheel-Makers


Since Chris has given us this chance to rant I thought I'd share my 
views on the industry as an ex game-programmer.

Nothing frustrates me more then the amount of duplication of effort 
going on the in games industry.  Its still true today that if you talk 
to most game developers they are convinced that their problems are 
somehow unique and that all their solutions are going to be better then 
anyone else's. Given all of this incredibly talented and creative effort 
you would think that the game industry would be full of wildly different 
products, yet if you walk around E3 you inevitably see a floor full of 
virtually identical product.

What gives?

In engineering in general there is a real tendency to towards NIH or 
"Not Invented Here" thinking.  This is driven by the honest effort to do 
our best work on everything and the irrational fear that others haven't 
had the same drive.  Guess what guys, **everyone** who is any good at 
all feels this way but you cannot possibly do your best effort on 
everything. You just don't have the time or resources.

We can learn a lesson for the economists.  In Paul Samuelson's 
Economics, 10th edition he provides a mathematical proof that even if I 
produce both bicycles and coat hangers cheaper then you do, if I produce 
bicycles cheaper then coat hangers and your produce coat hangers cheaper 
then bicycles, then we both win if we specialize in our locally maximal 
production and freely trade. I do the bicycles and you do the coat hangers.

What does this have to do with us? The same math applies-- even if in a 
perfect world with an infinite amount of time you can do everything 
better then anyone else, in a fixed time effort you will get better 
results through specialization and trade.  Given the complexity of 
modern games this kind of approach has never been as necessary as it is 
today. Creativity is being drowned in the sheer volume of work necessary 
to realize creative visions.

The answer has been known for a long time, reuse of code and 
component-ware. Unfortunately the cards are all stacked against such 
approaches today. You would think that at least within a shop there 
would be code reuse. However my experiences in the industry suggest that 
this almost never happens.  Why?  Ironically the reason I've seen has 
nothing to do with engineering.  It has to do with bookkeeping.

The typical accounting model for game projects looks at each game 
project individually as a profit/loss center.  A given producer is 
responsible for tracking the costs of producing the game and seeing that 
it ultimately earns more then it cost to produce and market.  A producer 
who consistently generates profit will do very well in the industry. A 
producer who produces a string of losses will soon be looking for a new 
job. As such it behooves the producer to keep his costs down.

You might think that reusable code would reduce costs, and it would, but 
that code has to come from somewhere.  Reusable code initially costs 
more to produce then one-off problem-specific hacks.  There is no 
incentive in the system for the producer to spend a penny on future 
games, and every reason not too if it will impact his current game's 
budget. As a result, game engineers are directed and scheduled to 
produce only what is needed for the current project and not a line of 
code more. The reason is that there is no global accounting that credits 
people for doing work that helps the company produce multiple products.

Some game companies attempt to solve this be creating separate "R&D" or 
"Tool" engineering groups.  The role of these groups is to think further 
ahead then just the next game and produce technologies that will benefit 
many game projects. Unfortunately these groups still often fall prey to 
the balance sheet.

I worked for one such group where where our operating budget was paid as 
a fixed charge to the budget sheets of all the in-house game projects. 
Inevitably when game projects ran over estimates and the producers 
started examining their budgets for ways to reduce costs, they wanted to 
know what we were doing for their immediate needs. The end result was 
that we were pushed to act as a direct extension of the game projects' 
engineering staff and all the strategic advantage of having our group 
were lost.

The other way of budgeting such a group is to call it "overhead" like 
the lights and office space.  This keeps the R&D group off of the game 
producers' balance sheets and out of their lien of fire. Unfortunately 
it moves the group directly into the line of fire of higher level 
executives trying to trim costs during downturns. Lights and office 
space they understand, but "R&D" sounds to these generally 
non-engineering types as a "frill" like free-soda and something that can 
be cut with even less complaints from those who "produce the  real 
product."  As the game industry is a boom/bust industry such downturns 
are inevitable and, once the forward planning has been eliminated it 
becomes very hard to bring it back into the system.

So what are the solutions? If I had a 100% sure fire fix this would be 
an MBA thesis, not a rant.  I do have some suggestions though:
Stop thinking in terms of individual products and start thinking in 
terms of suites of products built on top of generic engines.  I don't 
mean very game specific engines like the Quake engine, but rather game 
genre and or functional engines, such as Sierra Online used.  (Very 
successfully, I might add, until they were bought out by someone who 
didn't understand their business model.)

Fight the NIH complex. There are specialists out there who want to write 
components for us. Lets try to encourage that by looking for external 
solutions first and only engineering either the core unique parts of our 
games or places where the externally available components can't be 
reasonably made to fit. At times this may mean diverging slightly from 
our original game designs but the payoffs are well worth it.

Industry Standards!  The best way to encourage both the development and 
sue of component ware is through the development of industry standard 
APIs and data formats.  These allow code to be easily separated while 
still communicating closely in the final application.  Furthermore they 
reduce the risk of using third party components by providing the 
possibility of plug-replacing those that might not live up to our hopes 
or needs.

Number One above is a change that has to happen in game production 
management.  I'd call on those in such management positions to consider 
this and discuss it with your technical experts.

By contrast Two and Three are things engineers can directly address and 
make happen.  We ARE the technical experts and these are choices we can 
make or at least strongly encourage our management to make. A focus on 
Java API's for gaming seeks to address these very problems.
==== end quote ====

Enjoy

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev