[MUD-Dev] Online Games Fighting Terrorism

[Marc Hernandez]

From: <amanda at alfar.com>
> Raph Koster <rkoster at soe.sony.com> wrote:

> Indeed.  This may not be a bad thing, though.  For example, we've
> already reached the point where it can be more economical to buy
> than build (3D rendering engines, for example).  We may well reach

I am not sure this is true at the moment.  Certain pieces of 3d
engines are good to buy, such as a skeleton system (like Granny) or
a movie system.  This is assuming games that rendering boundaries.
Games that do not can do almost anything they want.

While working on Munch's Oddysee we used NDL and essentially rewrote
major sections of it.  For our next (current) project we rewrote
from scratch.

Scene graphs do little for games.  The structures they need are more
specific and specialized.  While at WildTangent I saw a lot of games
get built internally by our game teams.  Most basically used the
scene graph as a flat list (ie, having a top node that holds most
renderable nodes).  It was used in small short trees (for say 4
tires connected to car body), but that is super easy to build
without having a fully generalized scene graph.  Then if the
middleware optimizes the scene graph for adding and deleting nodes,
but you need a huge number of walking etc etc.

Additionally most people try to shoehorn in collision and other
things into the rendering heiarchy which is typically an orthogonal
problem.

> the point where it's not feasible to build a new game's
> infrastructure from the ground up any more.  Rendering and scene
> graph management has already split off.  How about networking
> (both

> server-client and within a server cluster), state management, and
> so on.  I think this all makes for great opportunities for
> standardization of already-solved problems, simply because no one

The currently standardized problems look to be Skeleton rendering,
movie decompression and rendering.

In talking with Dave Moore (exDynamics) it looks as though game
networking (user client to server) is still very sensitive and game
specific.

I have little experience with server backends, so maybe there are
good options there.

>> Nichification is definitely coming with further games, but at the
>> current economics of the biz, it won't help that much, given that
>> a from-scratch competitive product is going to require a pretty
>> large niche.

> I think that the time is coming when a from-scratch product won't
> be competitive, simply because there won't be enough time to
> reinvent enough wheels.

> Let's say I was designing a game today.  I wouldn't even consider
> writing my own 3D engine or database management back end, and I'd

With middleware the options seem to be to use it and take a
rendering penalty (from anywhere of 25% to 75% of what you could be
doing).  Additionally you buy a bunch of work that will probably not
get used.  We had a full max exportable particle system and we got a
few smoke stacks out of it.  Pretty easy to write ourselves really.

Then if the middleware developer decides to do something crazy like
oh put the skeleton heiarchy into the scene graph <shudder>.  So now
you have a massive rewrite of the skeleton system.

Or say they use a particular way of updating matrices that make it a
pain to do other things.  Game X might work well with this way of
updating matrices, but Game Y is broken with it.

> really rather buy more of the middleware if I could manage it.  I
> want to spend my development capital on what makes my game
> *different*, not on all things that are basically the same as
> other games.  The marketplace doesn't care whether I write my own
> renderer or buy NetImmerse orr Renderware.  It doesn't care if I
> wrote a really nifty object management system.  It cares if the
> game is playable and engaging.  Effort is irrelevant--the end
> result is what people buy.  Yes, perhaps I could do better than
> the middleware--but I can't do better than it in zero time.

Not perhaps, will; and probably by a good margin.  Middleware is not
some magical thing that immediately takes care of rendering.  There
will be bugs in the middleware, you will have to get up to speed
with the middleware, you will need to get around things the
middleware does for you that you do not want it to.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev