[MUD-Dev2] [DESIGN] OnLive might make MMOs much easier

[John Buehler]

Matt Cruikshank writes:

 

> What, in this situation, does the MMO server really
do?  Record the

> character's inventory changes and the experience
points gained.  What

> else?  It's a
database - it might not do hardly ANY game physics or

> simulation, any more...  Wouldn't that dramatically decrease the cost

> of running an MMO?

 

MMOs can revert to structuring the hardware and software
any way they want to with a system like OnLive. 
The client/server distinction can be tossed.  Now, you've got a bunch of hardware sharing
data to make sure the environment operates properly, with a certain amount of
hardware responsible for processing user requests on that environment and for
generating the video frames that go back.

 

The advantages that you described are all very nice to
have.  It should permit MMO designers to
focus on the operation of the game environment instead of the constant effort
of how to effectively split the software across the network.  OnLive simplifies the whole thing by saying
"The client sees video".  From
there, it's a matter of how the game software generates the video.

 

As an aside, consider that OnLive will enable new
hardware such as PhysX's physics processors to be adopted much more
quickly.  If PhysX can go to one or two
major game companies and OnLive and convince them of the value of going with
the upgrade, it's done.  That, as opposed
to the chicken-and-egg problem of getting millions of individual customers to
buy into new hardware before a major game company will write a title for it.

 

> Or am I over-inflating the costs of security, and
the benefits of more

> TRUSTED computing horsepower right at the game
client?

 

I'd say that the real savings is in ignoring the
development costs of client/server computing and instead being able to
structure the hardware any way the MMO wants for most effective use of the
available hardware.  Mind you, without a
client to do the job of display, that means that much more hardware on the
'server' side.

 

I wonder if we'll see mega-GPUs that maintain the display
information for a huge area and render views of it for the thousands of
'cameras' that would be moving around within it.  That's something that certainly isn't of any
value with clients doing the display generation.  It would mean having only one copy of all the
display information, with thousands of renderers drawing from it.  A database of visuals, if you will.

 

An architecture that I always wanted to fool with
involved assigning worldwide cross-sections of game data on different
machines.  So blacksmithing operations
would take place on a machine that only cared about blacksmithing.  Fishing on another machine.  Perhaps the sense of smell on another
machine.  Worldwide collision detection
on still another.  I wonder if that becomes
more practical/applicable with the display-generating machines on the 'server'
side.

 

JB