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

[Matt Cruikshank]

Hi Jeffrey,

I really disagree with you.

> It makes NO accommodation for latency which is your number one design
> issue in MMOs today.

There's several forms of latency, and I believe OnLive is almost
uniquely situated to several of them.

A) The client's computer can't be trusted to handle the real game
mechanics because of cheating, so the client has to communicate with
the server.  OnLive solves this - the OnLive computer can absolutely
be trusted to handle the real game mechanics, and simply inform the
servers about the result.

B) The client's computer is of unknown manufacture.  John Carmack
famously said that with a known platform, you can double performance.
If OnLive minimizes the number of variations of computer platforms
they use *for a given MMO*, then they can take advantage of this fact.
 I know I'm overstating it, but the effect is real.  An increase in
performance translates to lower latency.

C) You're right that in an intermittent communications dropout, a
local computer can entertain the user with extrapolated data, but this
only goes so far.  Once the communications are re-established, the
local computer has to be informed of world state again.  There's
latency involved in that, too.  In the OnLive case, yes, the most
likely result is frozen video.  But once communications are
re-established, there's only video synchronization that has to happen
- no world state synchronization.  Basically, you're one I-Frame away
from perfect video again.  I believe that a re-synch of world state is
inherently more costly.  This one's probably a tie, in my opinion.

The leap of faith is video latency.  Yes, the burden of proof rests on them.

But my point is, IF (and yes, ONLY IF) they pass that hurdle, I
believe it's brilliant for MMO development.

Also, the neat part, is that IF they have done that, it's At Least As
Good as the MMO on your desktop, but has the potential to be far
better.  Wow.

And yes, this is a giant "IF."

Looking at the founder's track record, it's a good one, though.
Quicktime architect.  That's some street cred.  Face capture for
"Benjamin Button."  That's some more street cred.  The game companies
that have signed on.  This looks like it might well be real.

>  the client where you have the full rich
> and more importantly *local* computing environment that your plyer
> brings with him or her and you get for
> free.

The game developer gets it "for free."  The consumer gets it at high
cost.  In OnLive, the consumer gets it at a steady cost, and doesn't
need to worry about hardware failures.

But your point about *local* computing is moot.  It's nearly as
*local* in the OnLive server room as it is in the consumer's home.
It's a dedicated computer - or at least core or set of cores - for the
player's game state.  In short, it's THE SAME COMPUTER that you're
talking about, except it's on the other end of a video feed.  You
haven't gained or lost anything.

> So your instinct that you need server side logic to prevent cheating
> is a good one, but this is a silly technology
> (if it is a technology, and i have my doubts) to apply to this. It
> buys you nothing and costs you much processing power, plus it makes
> latency hiding impossible.

It costs you zero processing power.  That's a complete lie.  It moves
the processing power from a computer in front of you, to a computer in
a back room.  If anything, it increases your processing power,
because, as I said, known platforms can more easily be targeted.
Development costs go down, testing is easier, bugs specific to that
specific platform are more readily identified.  Since the OnLive
computer is trusted, you can actually put MORE of the processing power
on the OnLive computer than you can on the local computer.

-Matt