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

[Jeffrey Kesselman]

Oh boy, this so wrong in SO many ways....

On Wed, Apr 29, 2009 at 10:22 AM, Matt Cruikshank
<mattcruikshank at gmail.com> wrote:
> 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.

Then explain some? I saw ZERO information on how they are defeating
network latency.
Given that many others have treid and failed (MPATH any one?) that
claim REALLY needs to be backed up.

>
> 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.

This is "solving" a solved problem.

No major MMO today does game critical claculation or state storage on
the client.

What they DO do on the client is all kinds of latency hiding through
such things as
dead reckoning.  In the online model this is not possible.

>
> 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.

You are ignoring that the cycles of the users machine are free to the developer
The server costs us.

There is nothing more cost-efficient then free computing power.


>
> 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.

That is hidden by the game client.

> In the OnLive case, yes, the most
> likely result is frozen video.

Which is unacceptable.  A user cannot plame a game with the kind of random
indeterminate latency the internet provides today.  Thats why its hjidden from
the user by thick game clients.

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

Noone has EVER shown a way to magically make net latency disappera and as
I mentioned above, many have tried.  IF they can do this then its a FAR bigger
discovery then remote system virtualization... which was well solved
problem before
they ever showed up.

>
> 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.

How?  With freezing, halting video?  And a massively over-loaded server trying
to do everything the serve AND client do?  How is this better?

As already mentioned properly written MMOs today already split the
work in an *intelligent* way between
client and server.  How is removing the client's CPU form the equation
anything but a
loss??

>
> 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.

This sounds well like it might be marketing flack.

I'm sorry, but it does.  Having been involved in something in the past that
actually worked doesn't mean they can make this work.  George Bushw as  involved
in one (arguably) successful war.

And the fact that they fiat and handwave key issues makes it look
pretty vapor to me.

>
> 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.

No.  In OnlIve the creator dedicates expensive server room resources to
doing what a cheap client did before.  The operator then virtualizes the
server resources, reducing their total efficiency by a minimum of 10%.

And the comparison is a fallacy anyway as you are trying to sell an
economic model to
developers and, for the developer, the model makes no sense.

>
> 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.

Oh PLEASE.

have you EVER written a game that plays over the internet?

The answer is clearly no.
>
> 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.

It moves it from a free computer to a computer that costs.

It then virtualizes which ALWAYS has an impact.

So your wrong in two ways.

Tune your marketing, Matt, this one is a no-sale.

JK