[vworld-tech] Ultimate MMO Platform

Crosbie Fitch crosbie at cyberspaceengineers.org
Thu Apr 1 03:05:22 PST 2004


> From: Jim Purbrick
> > From: ceo
> > and believes it's possible to do on a p2p 
> > basis. He's been saying this for quite a few years, and a lot 
> > of people have tried to explain why the things he believes 
> will soon be 
> > possible are inherently unlikely materialize (and I've seen 
> it put rather
> more 
> > forcefully than that).
> 
> I'm not convinced by his punk rock p2p approach either, 
> although it has a
> lot of nice aspects. The real issues with his ideas are those 
> of trusting
> the stored persistent state. If you pay Verant £10/month you 
> expect them to
> store the world data responsibly, if you pay no one who do 
> you trust? Having
> said that the huge connected NWN worlds out there seem to be finding a
> social answer to some of the problems by promoting trusted 
> players to GMs.


'punk rock' eh? Sounds like a politer version of 'brute force & ignorance'. ;-)

As you've intimated, it's a matter of getting the 'ball rolling'. It's not a matter of making a perfect system on day one.

Let's not get bogged down by itemising all the reasons why manned flight is impossible and why velocities in excess of 35mph will cause brain damage, etc.

If we were proposing a mechanism whereby people could share their CD collections online, I daresay many people would say it would never work because you couldn't trust people not to corrupt the data, nor could you guarantee that a particular CD that was entered into the system would always be available. Moreover, you'd get a load of people suggesting that such a system would be unviable because you couldn't charge for it.

You only worry about trust when you have something to lose.

Be careful of applying the same values and expectations that you may have from existing game genres and reapplying them to p2p based games.

All existing games (apart from say, Diplomacy or table-top RPGs, or other games where people can make the rules up as they go along) have a cast iron ruleset at their heart, and we find that the computer is a perfect match, indeed, a better than human invigilator of games. It is part of the sacred unwritten laws of games development that a game must have an uncorruptible ruleset or the game isn't fun. Ipso facto nothing can be entertaining that isn't such a game.

I appreciate that a 'virtual world' kind of thingy that is run on a p2p infrastructure is inherently unable to enjoy perfect invigilation. Indeed, I never try to say that without perfect invigilation entertainment will be unachievable. Instead, I try to persuade you that a p2p type world isn't necessarily going to be a 'game' as we know it. I also try to persuade you that nevertheless, what is created on this imperfect distributed modelling system will indeed be entertaining.

For comparison, the Internet is entertaining/useful, nevertheless it is still prone to spam, pop-ups, unwanted advertising, corruption, scams, viruses, porn, DoS attacks, phishing, and anything else that naysayers might suggest it would be subject to prior to its creation. We still see great value in it. And yet it is free - or rather, people only pay their ISPs for a network connection and bandwidth.

The biggest problem with an 'unowned' p2p virtual world is that it is difficult for anyone to monetise it. Business models rely on control, and how can you do business without control? Who will invest in the p2p infrastructure on a purely philanthropic basis? That's the key problem. Otherwise, we'll just see corporations like IBM working with ring-fenced MMOG farms like Butterfly.Net. They feel that they have to control it to make money.

So, probably even before you worry about the technical details, it may be best to confront this business dilemma first: Do you want to control access to this platform/technology/environment?

Will it be like Gnutella? Cool software, but no-one owns it? Or will it be like Quazal/Eterna - proprietary middleware available under license? Or perhaps one can develop p2p software that is never expected to remain viable in the wild, but can be viable if it is run on a ring-fenced distributed-CPU-farm a la Butterfly.net?


There is a clear progression (in my mind) for many of the contemporary games development problems we're facing:

1)	Development of large scale virtual worlds (even for single player games)
		Managing larger scale content - storage, pre-processing, format conversion, optimisation, etc.
		NxN Alienbrain type version control/asset management, etc.

2)	Assisting content creators in creating this content
		Rules based scenery generation/placement/assembly
		Computer assisted manipulation
		Scenery editors for larger virtual worlds
		Intelligent scenery (not just dumb geometry)
		Live access via diverse task specific editors, e.g. Max, Maya, Photoshop, Game editors, etc.
		
3)	Collaborative editing
		Larger worlds require simultaneous modification by large teams
		We'll already see a demand for concurrent access to scenery databases via a LAN
		The next step is a little more distributed
		
4)	Multiplayer
		One day, the game editors that often accompany games, will become collaborative game editors. One day, they'll be scalable. One day players will realise they're having more fun with this virtual lego construction set than they are with the game that utilises it.
		One day the collaborative editing tools will be so responsive, someone will wonder "Why not release this as a game client to a virtual world???" without necessarily worring about how to make money out of it or whether it will quickly descend into anarchy given its hackability.


Let's just start with a very simple (UNAMBITIOUS) set of requirements:

1) Use of BerkleyDB/MySQL/PostgreSQL to store a 3D world. It doesn't matter what is used for storage really, even a 64K RAM implementation will be valid, but let's just aim for scalability.
2) A fairly efficient API on this scenery store for 3D visualisation clients to modify this store, and receive notification if any other client modifies it.
3) A network abstraction API, something a bit nicer than sockets, perhaps more oriented to the needs of distributed systems, e.g. JXTA, GnucDNA, etc.
4) A synchronisation system to synchronise these scenery stores. The easy part ;-)
5) A virtual machine to enable objects in the scenery store to do more than just 'sit there'.


Even this crude sketch is probably far too ambitious. So, one day I tried to figure out what one could do with barely no programming. Simply bung Quake files into Gnutella and hook up Quake to it. You gotta start somewhere.


So really, we can start producing useful systems (to the games industry) and get benefit from them even before they're viable as a games platform for the great unwashed public.


Something I've concluded about a 'public cyberspace' is that it's not the technology that's a problem, the problem is that it's a proposition with a severe 'business case' deficit. However, it's not that "It's impossible to retain control of the system and thus make money" it's that "Why would anyone want to produce a system, if one can't make money out of it?"

Why would anyone want to create the Web if no-one can control it and charge for access?

In spite of the lack of a business case, somehow these ludicrous things happen.

It just needs the right person(s) to be in the right place at the right time and have the right resources.



More information about the vworld-tech mailing list