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

[Matt Cruikshank]

I'll try to lay out the terms as I see them, again.

Traditional MMO:

A - B

A is the servers they maintain, B is your local machine.

What does A do?

- all of the game logic

What does B do?

- graphics
- latency hiding

On-Live enabled MMO:

C - D - E

C is the servers your MMO maintains, D is the servers at OnLive, E is
the dumb terminal at the player's house.

What does OnLive offer?

Well, for one, C could be identical to A and D could be identical to B.

Yes, there's a HUGE leap of faith that OnLive has solved the problems
of communication between D and E.  And I agree with everyone here that
it's a **HUGE** leap of faith.  But, I'm interested in what the
consequences are if it turns out they've really solved the D - E
communication problems.

My assertion is that an MMO could be designed along entirely new lines:

What does C do?

- pretty much, it's a database

What does D do?

- all of the game logic
- graphics

What does E do?

- dumb terminal

I think that moving all of the game logic onto D provides some
fascinating opportunities.

For one, I would think it would reduce the costs of C compared to A by
a huge margin.  This reduces the barrier to entry for the game
developer by a lot.

For another, since the end-user has no access to D, their
opportunities to cheat are greatly diminished.  This is a huge concern
in most games.

Also, since all of the graphics are happening on D, and it's
potentially a known configuration, the developer can focus on
rendering on exactly that platform.  They don't need to gracefully
degrade the look of their game depending on how many MB of RAM and
VRAM, how many CPUs, is it even a Windows box and which version of
Windows, etc.  Theoretically, OnLive can offer to the game developer,
"Okay, we'll only spawn your game on computers configured exactly like
this."  Fewer configurations to test lowers the cost **dramatically**,
for the developer.

I would guess that one of the appeals is that the connections between
the various D computers (and from them to the C computers) are really
nice.  Also, since the D computers are located all around the country,
the MMO developer doesn't have to locate the C computers as close to
the E computers as they'd have to locate A close to B...

I think there's even an opportunity to reduce the sharding that
happens.  Since D is a trusted computer, the computation of game logic
can be much more distributed.  In the words of Jeffrey Kesselman, it's
FREE computing to the MMO developer - and better, it's secure and they
can fully trust it, and they didn't have to pay a dime for it.

It feels like a hugely disruptive technology, to me.  I somewhat feel
like I'm learning about BitTorrent for the first time, and people keep
saying that FTP can do the same thing.  I feel like I'm hearing about
Google for the first time, and people are saying it's absurd that they
could have a local copy of the whole internet.  Or hearing about GPUs
for the first time, and people are saying there's nothing that a CPU
can't do better.

I totally, completely get that there's a huge burden of proof for
OnLive, and that there are existing solutions to a lot of the problems
I've highlighted.  But I think that BitTorrent and Google and GPUs
shook things up dramatically, and I think that if OnLive delivers what
they're promising, that they'll shake things up dramatically, too.

To respond to Jeffrey Kesselman's comments:

> Given that many others have treid and failed (MPATH any one?) that
> claim REALLY needs to be backed up.

Couldn't agree with you more.  Moving on...

> This is "solving" a solved problem.
>
> No major MMO today does game critical claculation or state storage on
> the client.

Right.  But gee, what if they could?

The problem is that the costs of the MMO servers, that I labeled A,
are very high; there are wasted cycles on the gamer's computer, that I
labeled B - because they can't be trusted; gamers can crack open any
of the graphic and sound resources on the B computer and cheat that
way; gamers can sniff data going to the B computer and gain "extra
senses" that the game would like to prevent them having...  There are
negative consequences to what you're calling a "solved problem."  In
short, it's a "solved problem" with a lousy solution.

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

It's not possible on the E computer, you're right.

It's absolutely still possible on the D computer.  In fact, the D
computer could be identical to the B computer, so your argument here
is predicated on the entirely reasonable suspicion that the D to E
connection won't deliver.  Granted.  But if OnLive DOES deliver on the
D to E connection, then it's a whole new ball game.

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

The cycles on the D computer are just as free to the developer.  And
since they're trusted, I believe it's possible that the developer can
actually push MORE of the computation onto the D computers, lowering
the costs of the C computers, which the developer does pay for.

Also, the problem is that the cost of the B computer is a barrier to
entry for consumers.  The cost of the E computer is much, much lower.

Nothing is more costly to developers than consumers who never buy
their products.

If the consumer already has the E computer set up, each additional
game they play has zero install, zero set-up costs, zero HD overhead,
zero delay for them to try...

In short, a game developer can get the consumer to try their game -
INSTANTLY, the moment it is released - at zero risk, zero cost to the
consumer.

> How is removing the client's CPU form the equation
> anything but a
> loss??

As I've said again and again, the D computer could be identical to the
B computer.  You're simply restating your reservations that the D to E
connection will deliver.

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

No, you're wrong.  In OnLive, OnLive dedicates D computers.  The
developer only dedicated C computers.

The D computers could do the same thing the B computers did before.

Whether they are virtualized or dedicated hardware, the cost is on
OnLive, not the game developer.

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

If the developer can reduce the cost, from the A computers, to instead
the C computers, then the model makes a lot of sense.  OnLive pays for
the D computers.  If the developer can reduce the cost of developing
for all of the random configurations of B computers, and instead
target the select few configurations of D computers, that is an
enormous win.

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

Your point was that the B computer can do a lot of work.  My point was
that the D computer can do the same work.  And again, you are simply
restating your doubt that the D to E connection will deliver.  I get
it, Jeffrey, you don't think OnLive can make D to E work.  I'm trying
to engage in a conversation where we presume it does work, and then
look at the consequences.  You don't need to respond to every single
point I bring up by saying that the D to E connection won't deliver.

So, I say again, if the D to E connection does deliver, then the D
computer could do the same things the B computer did.

>> 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 costs OnLive, not the game developer.  It indirectly costs the
consumer, too - but they are essentially sharing the cost of a
computer capable of playing the game with other people who play the
game, too.  If the game-time that was logged on the B computer was
10%, then essentially OnLive is going to get to share that D computer
with 10 users (not at the same time.)

Also, that "free computer," as I've stated above, is a barrier to
entry for players.

> It then virtualizes which ALWAYS has an impact.

Granted, but it's a known configuration, which always has a benefit.

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

It's absolutely a no-sale if they fail to deliver on the D to E connection.

But if they do deliver on it, then it's a win-win.  Lower costs for
the developer and for the gamer.  More people trying more games.
Fewer opportunities for the gamer to cheat.

-Matt