Decentralized real-time network games

Networking & Multiplayer
#1

What is the general opinion in the game developer community on decentralized solutions for network games (e.g., MMOG, FPS etc.)? I am convinced that there are viable solutions and that large-scale online games wouldn’t require a high-end central mainframe with such a solution.

The biggest challanges as I see it would be:

[]Cheat-proof. How do we detect and prevent cheating players?
[]Persistence. Even with a smaller server for storing offline players data, how do you ensure that the world is indeed persistent, or at least experienced as such?
[*]Synchronization. How do we ensure that player A sees the same world as player B?

Preventing cheaters is more about making cheating cost more than its worth, than actually making cheating impossible. So this problem is probably the easiest to solve.

Persistence could possibly be solved by looking at how modern P2P-systems work. This might also solve the synchronization problem.

So what do the rest of you think? Most of the server-architecture for online game out today are centralized. Would a decentralized solution be worth looking into?

#2

Hybrid would appear to be the best solution. Bits that the whole community shares constanly are run centrally. Bits that only a few people share (quests for instance) are palmed off to the players machines.

Also, most FPS games don’t require massive servers to run a single game. Hosting on your own machine isn’t that unusual.

Kev

#3

[quote]What is the general opinion in the game developer community on decentralized solutions for network games (e.g., MMOG, FPS etc.)?
[/quote]
From those who’ve researched the issues: For practical use it sucks; don’t go there.

From those who “just like the idea of p2p”: it must be possible, why is everyone so negative? (and, frequently, “Why does everyone keep telling me to learn more about the subject?”)

There are a few people living in la-la land who are convinced that it’s the way forward despite absolutely zero evidence after years and years of going on about it. Sadly, that hasn’t stopped them from getting prime-time coverage in mainstream game press, but it’s still BS.

They don’t. Don’t take this personally, but … who cares about your convictions when you haven’t yet done the basic investigation of this stuff? Example number 1 of your lack of research: todays online games are generally run on commodity intel boxes (some older ones run on DEC Alpha’s, but of course those don’t even exist any more, and have been superseded by desktop AMD’s).

Again, don’t take it personally, but you missed most of the big problems. You didn’t mention bandwidth and latency. You didn’t mention inability to upgrade the code. Etc etc. I strongly suggest that if you really care about this then you go and do some extensive research into pre-existing p2p systems (they’ve been around for 20 years at least - there’s really no excuse for not being able to find lots and lots of information).

No, it’s not about that. The majority of first-wave and second-wave cheaters don’t care about cost, they just want to cheat (or, more usually in a persistent game, to grief). Once a critical mass of those two groups is obviously cheating and the tools are easy to download a critical mass is achieved and the majority of all players cheat because they have to or just because everyone else is doing so, and what you’ve outlined becomes relevant - but it’s often too late by that point anyway. There’s tonnes of evidence on this - entire websites are devoted to tracking the cracking and cheating in online games - so again you just need to do some background reading using google.

There are no problems with persistence.

Surprisingly enough, there’s good reason for that! Of course, there is the old adage about cows and grass from Larson: cow stands up and says “Hey! We’re eating grass! Why are we eating grass? This tastes awful”. i.e. just because it’s been done that way for a long time doesn’t make something the best way. But on the other hand you’re looking at 30 years of research and development and many many people who’ve lots and lots of experience, and for some strange reason almost all of them come to the same conclusions? That’s pretty convincing to me…

#4

First off all, I’m talking about decentralization, not P2P. P2P sucks and is probably only suitable for file-sharing and community systems (e.g., IM, groupware etc.).

Decentralized systems, where computations doesn’t have to be performed at the central server, is different and would solves alot of problems existing in centralized systems with high real-time requirements (like MMOG servers).

Cheating, in the sense of manipulating the local computations, can be solved using code mobility. I proved this in my master thesis (sorry, no online reference). Basically, what you do is to distribute a new, slightly modified, game-rule component at irregular intervals to prevent players from patching the local application. There are more problems with cheating also (bugs in code, etc.), but these also exist for centralized solutions.

The problems with bandwith and latency as you mention it are at least partially solved using a decentralized solution. The bandwidth usage is reduced since computations are performed locally, then distributed to the necessarry player-clients and the result doesn’t need to be confirmed anywhere. Latency is always a problem, regardless if you use a centralized, decentralized or P2P solution.

Persistence is a problem in decentralized environment since a computation isn’t performed where the persistent data is stored.

However, I do agree with your last statement. But that doesn’t prevent the idea of a decentralized solution to be explored. It is always easier to write a centralized solution, and hardware is cheap (compared to development costs).

#5

Sorry for not noticing the distinction.

I still don’t see things that are currently problems that this might solve? FYI I work on building MMOG servers, so feel free to get as technical as you want… Perhaps if you could be more specific about the precise problem seen on a server based system, and quantify the improvement from your idea, then it might penetrate my skull ;D and I’d have a better idea what you’re aiming at.

How does that prevent patching? I know of several ways of detecting-and-correcting local manipulation, but they all rely on a nebulous notion of trust, and that’s why they cannot beat a server: fundamentally, distributed computation requirs you to make choices about which players you trust (instead of whether or not to trust the game developer), which is imperfect because it can never be truly secure (you can’t even trust your best friends in online games - a known fact amongst MMOG admins who see some startling demonstrations every week).

Usually, they are also a bit too computationally intensive to be worth it in any complex game. They are not, for instance, cheap enough to do in a realtime UT fire-fight. The best workaround I’ve seen for this is computations that are never checked, but always could be. The basis there is that the player only thinks they might have been cheated rarely - so the check can be done offline hours in arrears. It’s cunning, but a bitch to design your game around, and it only takes a gung-ho attitude amongst players to break completely (by initiating a check every second, for instance!)

You’re in danger of sounding like a typical P2P-apologist here: you are glossing over the detail and making a hand-waving statement about “reduced” without any logical argument nor any figures to back it up. I don’t believe you at all on this point, so you’ll need to actually provide some reasoning rather than hand-waving.

Again, glossing over the problems: non client-server systems inherently increase the system’s overall latency, usually by large amounts. Simply saying “latency is always a problem” is to ignore the fact that server-based designs have latency below a tolerable threshold and all the others usually don’t. Who cares if it’s always a problem? What matters is exactly how much of a problem it is!

Shrug. I don’t think you have real difficulty there if your game has a significant number of players. Distributed state can be persisted on “1000 player’s PC’s in RAM” at least as reliably as on “1 hard disk”.

#6

Ok, now you’re just being offensive. I resepct your authority on the subject and will keep your arguments in mind while I look into this a bit further on my own.

Regarding my suggestion for preventing local state manipulation I’ll see if I can get my thesis online so you can have a look at it if you’re interrested.

#7

Not at all. Hence the smiley. Hence the self-deprecation.