[MUD-Dev] Object Models

[John Buehler]

Russ Lewis writes:

> msew wrote:

>> I am not advocating the uber tool of doom that knows about
>> everything and never needs to be changed, but instead advocating
>> making tools PART of the development of the game.  The tools should
>> be just as important as the graphics engine or the network code.
>> The tools get updated as new features are incorporated.  Yes this
>> will slow down the project at some points but the over all net gain
>> is immense.

> In addition, tools lets the balance of labor shift.  w/o tools, you
> must have someone who really knows the guts of the engine make the
> modifications.  That means either the programmer, or someone trained
> by the programmer.  w/ tools, the programmer just writes a program
> (he likes that right?  that's what he does...) and then
> untrained/quickly trained users can contribute most of the labor.
> That means that the programmer can do what he does best, and level
> design can be done by interns...or, better yet, but designers hired
> specifically for that job.

If you are going to build tools for a certain problem, that problem
had better be around for a while.  In the world of games, that means
that the game environment needs to be extant long enough to make those
tools worth building.  Either the game environment needs to be around
or the systems/technology that makes up the game environment.

Said the other way around, it's difficult to make tools for a moving
target.  As technology keeps changing, the state of the art for this
genre of games keeps moving around.  That means that building tools
for that changing genre can be a huge sinkhole for a company's money.

That's the caution statement about tools.  I'm a big fan of tools, but
it's impossible to get the tools built unless the people funding them
are going to get significant bang for the buck.  To their thinking,
you're asking to not only get paid for making the game in the first
place, but to also get money for creating more software that just lets
you change the game.

Where I'm going with this is that only systems that show significant
promise for use for a long time will be worthy of tools.  Such systems
are either in games that have significant longevity, or they have a
life of their own by being reused across game boundaries.  When you
have a system like that, it can make sense to invest in tools for it.

JB

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