Archived

This topic is now archived and is closed to further replies.

Peer-to-Peer as alternative for client-server ?

This topic is 5598 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The cheapest solution for a massive multiplayer game for now is a distributed server system, am I correct? For example, 50 players on each server, or 1000, whatever, and if you want to go to another server, you just exit this one and navigate in your in-game build server browser, select another one and you''ll enter it. This way you can spread your servers easily around the globe. Is it possible to replace that server-client community from let''s say a 100 players with a peer-to-peer solution? If people want to go to another place they just quit this persistent peer-to-peer session and select another peer-to-peer session. This way your massive multiplayer game costs nothing to run. No servers needed. What more peer-to-peer solutions do there exist for high latency games, like fps. I know quazal, any others?

Share this post


Link to post
Share on other sites
Interesting idea, but consider this: In massively multiplayer games, you''ve usually got a persistent world. With persistent worlds, cheating is a much more significant problem than it is with discrete game sessions.

Basically, you''d open the door for a great number of cheats. Plus, you''d surrender control of the online world, so you couldn''t really influence it once the game has begun.

Maybe there are solutions to these problems, but running a server farm is probably cheaper than fighting an uphill battle against exploits and other problems in the long run. Who knows...

cu,
Prefect

Share this post


Link to post
Share on other sites
Crosbie Fitch wrote a series of remarkable articles concerning the future of peer-to-peer networks.(at gamasutra)

Somehow there must be a system to minimalize that hacker problem but for now I just want to know whether there are peer-to-peer systems in development, comparable with quazal.com products, open-source or commercial ? (to make Massively Multiplayer Games)

Share this post


Link to post
Share on other sites
If you were to implement this system it would still cost you to run.

You need a way to lcoate all the peer to peer networks, and for that a central server will be needed (a common address).

Another thing you must think about is the storage of data. If all players in one peer to peer network (of up to 100 people like you say) were to leave the session, there would be no-one to store the game information and noone to connect to, thus the game is lost.

Bottom line is, you need a server for *something*, if only to help fight cheating or locate a network.

Dachande

[edited by - dachande on March 24, 2002 6:56:19 PM]

Share this post


Link to post
Share on other sites
I have thought about a scenario like this a lot lately. It is true that you would need a server, but the reality is that it's possible to set up a MMORPG using a free (or cheap) host. Just make a CGI script to hold game data on a server like Tripod and give out everyone else's IP when you log on. Doing so, it is possible to run a MMORPG for free.

[edited by - rjahrman on March 24, 2002 12:06:18 AM]

Share this post


Link to post
Share on other sites
I did alot of research studying just such an implementation for MMORPGs. I envisioned a central State server where state was persisted but the actual gamestate would be running in various peer-to-peer sessions that would update the main server''s persisted state every so often. As people moved around the game world they would move between different peer to peer sessions. The holy grail of MMORPG''s I suppose. A virtually Unlimited Scalability model.


There was one problem, however, no way to guarantee security. I explored various solutions. Having each session be a simultaneous simulation (like AOE) where clients were validated against each other. The only problem with that is someone is bound to find out the validation mechanism and then they and a group of their friends could hijack a section of the game state and make all the changes they wanted, which would then be persisted to the main server.

I though of ways to make this more difficult, like randomly hosting small portions of a games state on the state server to make sure that none of the clients in a peer to peer session were cheating, but even then they could detect when the server made a connection and give it the responses it was expecting, while having their way with the game state.

What I came to realize is that a MMORPG system must be two things, it must be Secure, and it must be scaleable in that order. Any time you trust clients with a portion of the gamestate, like in a peer to peer environment you are no longer secure. The more popular your game becomes the more motivation people will have to hack it, it''s only a matter of time. Once people have hacked your game and you have uber characters walking around who cheated to get there, no one will want to play your game. All your scalability is for nothing if no one will play your game. Thus scalability is second only to security.

If you’re going to build a persistent world, start with a secure model e.g. Client Server. Obey all the rules. Never trust the Client with anything. Assume that hackers have the source code for your client and that they can see everything it can. After you''ve dealt with security, you can start with scalability. A O(n) scalability factor is pretty good under these circumstances.

Share this post


Link to post
Share on other sites
I''m not sure I agree with your assumption that an MMORPG must be secure. I don''t think this has been absolutely proven.

I think an interesting idea for an MMORPG that hasn''t been implemented yet is security through complete openness. Save all the character data in easily-viewed (and modified) XML or similar scheme on the client end. If a user wants to give himself a +5000 longsword and max out every stat, so be it... no serious gamer will want to play with this perosn. My theory is that removing the challenge from hacking the game (in effect, removing the "hacking" from hacking) will pretty much drive off all the would-be cheaters. The only people who will be interested in the game are the ones that want to *play* it.

Did you play the Dungeon Siege beta? There is no security model for Dungeon Siege... it''s basically wide open, and will even provide an editor for you to muck with anything you want. Of course, it''s not really a persistent-world game either, so the analogy doesn''t fly. Alo, Microsoft will probably take a lot of heat for the lack of security in Zone games, but it was probably the right decision in the long run ($$$).



Share this post


Link to post
Share on other sites
When you’re talking about persistent state worlds Security is an absolute must! You’re expecting your players to invest time and energy to build up their characters and possessions in this world. If some hacker starts on Monday and is level 200,000 on Wednesday and killing all the people who have invested weeks/months/years acquiring their skills and items in the traditional manner, all your traditional players are going to quit in disgust.

The motivation for hackers to hack persistent state games is much greater then in games where the gamstate is session based, like a starcraft or AoE. If someone hacks the gamestate in an RTS match, the other players can just quit and go join some other game. The hack does not result in any lasting benefit to the hacker. Not so with persistent state games like today’s MMORPGS. Once a hacker has hacked the system his changes to the gamestate are permanent. He will have a continuing advantage over all the other players he is competing against. Thus his motivation to hack is much higher.

People quit playing Asherons Call in droves after the “GEAR” hacks game some player’s ridiculous competitive advantages on the PvP servers. If you think that no one will hack your persistent MMORPG world because you make it really easy to do so. You’re sadly mistaken. What will happen is that people will all max out their levels and experience, play for a few days and get bored because there is no inherent value in fighting monsters or leveling up. Why work up the hard way when everyone else is just modifying their characters in the editor you shipped with the game. It is this whole concept of building your characters faster then everyone else that drives people to play these MMORPGS for countless hours. It’s because of their belief that everyone must follow the same rules of progression that their advancement even has value. If some newbie can just get to the same level by editing his character then advancement will be meaningless and no one will play for longer then a week.

If I haven’t convinced you go ahead and try to implement a persistent state massively multiplayer game with absolutely no regard for security. I think you’ll soon understand what I’m talking about

Share this post


Link to post
Share on other sites
Security _CAN_ be implemented through the client! I''m not completely sure on this idea (so correct me if I''m wrong), but consider this: when a user logs on, the program could randomly check how far different players have gotten since last time. If a stat is obviously hacked, the hacked player could be ignored by that computer. It could then "warn" other computers. The hackers would then be playing only with other hackers!!!

Share this post


Link to post
Share on other sites
That’s fine for if a client changes his information while offline. (although this situation would likely never occur because the Client''s stats and inventory are populated from the server when they connect) But consider this, and this is what I was referring to above. What if the client changed his stats while playing the game, or perhaps gave himself some uber items. When the user logged out of the game, his new stats and items would be saved to the server. The server would have no way of knowing if the client achieved those stats and items legitimately or by hacking. Sure you could set limits on how many levels you could gain in one session, but hackers would rapidly figure out the levels, and how to max them out every time they played. Once you trust the gamestate to live on the client, you are no longer in control, the server is at the mercy of the clients.

Share this post


Link to post
Share on other sites
I feel I need to elaborate on this more. First of all, data could be stored on BOTH the client and the (cheap) server when they log off. If a hacker is changing stats, they''re either going to do it while the are not playing or while they are.

If they''re not, they would eventually log on. The CGI could compare stats before "letting them in" and not give them the IPs of the honest players.

If they are logged on, other computers in the peer-to-peer network would "see" the instant change in stats when the hacked program sends them out. When an honest client "sees" it, that system could "inform" everyone else to ignore that client.

I''m just coming up with these details off the top of my head, so please correct me if I''m wrong.

Share this post


Link to post
Share on other sites
quote:
Original post by Ironside
If some hacker starts on Monday and is level 200,000 on Wednesday and killing all the people who have invested weeks/months/years acquiring their skills and items in the traditional manner, all your traditional players are going to quit in disgust.



I don''t think you''re following the logic all the way through... someone who modifies their character in this context isn''t really a "hacker" per se. First of all, this system definitely isn''t geared toward PvP play... there''s just no two ways about that, I won''t argue with you there. Second, if someone DID kill you, all you have to do is open up your own text editor and restore whatever settings you like. Or, preferably, the game master goes into the editor and edits your character online.

quote:

Why work up the hard way when everyone else is just modifying their characters in the editor you shipped with the game. It is this whole concept of building your characters faster then everyone else that drives people to play these MMORPGS for countless hours.



haha... well, some people actually like the ROLE PLAYING aspect of these games. I think your assumption that building up your character is the only reason to play is a little bit narrow. Why do people play Dungeons and Dragons (non online) then?

Clearly this is a different type of game I''m talking about here. It would be much closer to the pen-and-paper type of game. Think about this... what stops someone from just writing down on his paper character sheet whatever stats and gear he wants? Nothing, really! But the other players aren''t going to want to play with him, and the game master (who is really just another player) isn''t going to allow the character in his campaign. Such a system could work ONLINE also... there''s no reason it couldn''t. In fact, this is very much like what Dungeon Siege and Neverwinter Nights are doing, but without the persistent backend.

quote:

You’re sadly mistaken. What will happen is that people will all max out their levels and experience, play for a few days and get bored because there is no inherent value in fighting monsters or leveling up.



Good! Let those people go! I certainly won''t miss them.
I think you are correct here for the most part... but what you are missing is that some people WILL want to slowly build up their characters within the confines of the game rules, and the adventuring campaigns, and THOSE PEOPLE are who this game is for -- the people interested in role-playing games for the sake of the game, not just getting the best equipment they can get.




Share this post


Link to post
Share on other sites
quote:
Original post by rjahrman
If they are logged on, other computers in the peer-to-peer network would "see" the instant change in stats when the hacked program sends them out. When an honest client "sees" it, that system could "inform" everyone else to ignore that client.

I''m just coming up with these details off the top of my head, so please correct me if I''m wrong.


The problem here, is if me and my guild all croud into one spot in the game, say way out in a field in the middle of nowhere, and we are all members of the same peer to peer group. In fact we make up all the members of the peer to peer group. Then if we all run a hack at the same time, none of the peers will disagree. Even easier, we can just run a program that blocks the packets that alert the server or the other peers of misconduct by one of the peers. If all the peers in a gorup were running such a program they would be free to hack all they wanted.

Share this post


Link to post
Share on other sites
quote:
Original post by Pyabo
I don't think you're following the logic all the way through... someone who modifies their character in this context isn't really a "hacker" per se. First of all, this system definitely isn't geared toward PvP play... there's just no two ways about that, I won't argue with you there. Second, if someone DID kill you, all you have to do is open up your own text editor and restore whatever settings you like. Or, preferably, the game master goes into the editor and edits your character online.



The MMORPG implementation I was thinking of was like the current stock of MMORPG's EQ,AC,UO,AO etc. I think your referring to multiplayer RPG's that are more closely related to tabletop RPG games, where there is a dungeon master and the gameplay is very story driven. I really doubt that this style of game play could support a 3000 player persistent world. But I’d be happy to be proven wrong


[edited by - ironside on March 28, 2002 8:50:06 PM]

Share this post


Link to post
Share on other sites
What if...

Rather than randomly checking the stats of all the game''s players, it only checked those in the current peer-to-peer (P2P) group. If stats were fake, it would notify only those in the player''s P2P group.

Secondly, the model of a P2P group would be different. There could (in theory) be up to 20 or so players in one group. The group would have a "leader computer."

When players move enough so they switch groups, the leader of the new group would check with all the other leaders to see if they''ve ever hacked.

As for a hacker claiming that another person is cheating, I think I figured out a solution to this. When a computer is accussing another of cheating, it could request a list of every place the player got gold, hp or anything else lately. Depending on how you set this up, it could solve the problem.

Then there''d be the problem of a hacker becoming a leader. However, the "leader computer''s" only powers are to let people into a group and say whether or not a person has hacked. In terms of letting people into a group, the solution could be to give a client the ability to "protest" a leader not letting them into the game. The client could notify every leader and send them the list of data, and if a majority of the leaders say the leader is unfairly stopping them the other leaders could instruct every player to ignore that member (or better yet tell the cheap server to delete them).

See if you think this will work.

Share this post


Link to post
Share on other sites
quote:
Original post by rjahrman
What if...

Rather than randomly checking the stats of all the game''s players, it only checked those in the current peer-to-peer (P2P) group. If stats were fake, it would notify only those in the player''s P2P group.



The real problem here is being able to prove if stats are fake. Without an absolutely trusted version of the gamestate (like on a server) there is no way to conclusively prove if stats are fake or not.

quote:

When a computer is accessing another of cheating, it could request a list of every place the player got gold, hp or anything else lately. Depending on how you set this up, it could solve the problem.



The hacking client could spoof the list, generate a list of random places where it acquired the stats. The underlying assumption here is that the Client must tell you the truth about something. In actual fact the client can and will lie about everything if necessary.

quote:

The client could notify every leader and send them the list of data, and if a majority of the leaders say the leader is unfairly stopping them the other leaders could instruct every player to ignore that member (or better yet tell the cheap server to delete them).



Again here you still have to trust the other leaders. Say the hackers got to be in leadership positions in a majority of the peer to peer sessions? they would again have full access to the gamestate. Also these decisions are very difficult to make, typically they require human supervision, as in the leaders actually voting, as opposed to the leaders clients making an automated decision. If you do rely on player run security your game becomes unscaleable again, because for every 20 players you add to your game, you need to have another "trusted" leader, like a GM or someone employed by to keep things "fair"

There''s a reason the big Online game makers use Client Server. They are very smart guys, you can be sure they considered the peer-to-peer model and found it wouldn''t work.

One thing I would like to say is that you absolutely could implement a massively multiplayer game with the methods described above. It would be playable and scaleable but it wouldn''t be secure. If your implemented a more prose focused game, or story focused game then this may be acceptable for you. But you could not implement a game like AC, UO,AO, EQ in this fashion because players invest so much in building their stats and characters and hacking would absolutely undermine the value of advancing your character which is predominantly what these games are about.


Share this post


Link to post
Share on other sites
Why not check the increases in stats against the game itself?

If you say, have 15 monsters, who give 1 exp * level, and the player suddenly jumps 5000 EXP.. you just have to check..

if(newexi > possibleExp) { ignore client; }

And if the client kills a monster, worth 14 exp, they''d gain the actual exp.

You could implement the same thing for levels and stats.

If((level == 1) && (hp > 30) { ignore client; }

Why wouldn''t you just have a legitimate check against the stats that are changing, etc.. Especially if the stats / skills are allocated in a Diablo 2 style. Obviously the total amount of stats shouldn''t exceed the amount alloted per class, per level, and if it does... then boom, you have a cheater.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

Good! Let those people go! I certainly won''t miss them.
I think you are correct here for the most part... but what you are missing is that some people WILL want to slowly build up their characters within the confines of the game rules, and the adventuring campaigns, and THOSE PEOPLE are who this game is for -- the people interested in role-playing games for the sake of the game, not just getting the best equipment they can get.



Yes, and that is why only 5-10% of the EQ population actually roleplays. Unfortunately these 5-10% aren''t gonna get the bills paid. You have to cater to the lewt hungy whores as well.

In any event, I dont care who your end audience is, cheating must be prevented. Persistent world or not. If you release a game that everybody cheats in and no body wants to play, do you really think they''ll buy your next game the next time around? Is your company going to stay in business?


-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
quote:

Good! Let those people go! I certainly won''t miss them.
I think you are correct here for the most part... but what you are missing is that some people WILL want to slowly build up their characters within the confines of the game rules, and the adventuring campaigns, and THOSE PEOPLE are who this game is for -- the people interested in role-playing games for the sake of the game, not just getting the best equipment they can get.



Yes, and that is why only 5-10% of the EQ population actually roleplays. Unfortunately these 5-10% aren''t gonna get the bills paid. You have to cater to the lewt hungy whores as well.

In any event, I dont care who your end audience is, cheating must be prevented. Persistent world or not. If you release a game that everybody cheats in and no body wants to play, do you really think they''ll buy your next game the next time around? Is your company going to stay in business?


-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
Well, 5% of EQ players is around 20,000 players. You don''t think 20,000 paying players could support a game financially? I think you''re wrong there. No, they probably couldn''t support a 400,000-player system, but that''s not what they''d need to do.


Well, to those pie-in-the-sky dreamers starting their P2P MMORPG, Ironside is completely right. There is just no way to make that system secure. Period. That''s why I proposed the Zero-Security system... but really, it *is* a different kind of game from EQ, AC, and UO.

(If you could create a secure p2p system though, then I think you''d have some fundamental new concept that previous generations of Computer Scientists had overlooked. Hey, more power to ya)

Share this post


Link to post
Share on other sites
Ok, lets put this in perspective:
You write the server software.
The hacker writes the client software.
Make sure he can''t cheat.

You need a central server to maintain and authenticate the state of the game, but I think you may be able let updates propagate via a peer-system. It would be important that such a system had good failure detection and was able to establish alternative routes quickly, with a default back to the main server always available.

What would instantly be nice about such a system, is that you could have master-server replicas in different RL geographical areas that are peer-updated from The One True Master - very similar to NDS (Novell Directory Services).

All the The One True Server must do is store state information, to prevent binary hacking of the data files (which is far too easy, even with encryption, think DVD). All the clients that connect directly to the TOTS are verify that they are reasonable, and the client is kicked, killed, or klined if not. The reasonably successful approach EQ has taken, is not to prevent cheats; but to detect them, and suspend or eradicate offending accounts.*
In order for the peer-distributed, server traffic-cop model to work, you have to trust the information sent by the peers; but we know we can’t trust them – or rather, we can’t trust all of them. For now, we shall assume that we can trust the majority of them. So everything is sent and calculated twice, or even thrice or more, across the peer-network. Every client is also a server, capable of validating player actions like The One True Server.
Your PC is not responsible for delivering authoritative information about your actions to the peer-network – you will send information packets to other clients in the surrounding game region so they may update with less latency. TOTS tells your PC which other client(s) to establish a connection for validation of the authoritative packets, and it changes the validation PCs at-random. The validation PCs propagate your updates up to TOTS after they validate them, and report any discrepancies directly to TOTS. To prevent hacked abuse of the kkk (that’s kick, kill, kline) regulation, before a player is instantly kkk’ed another random client (or two) must also report discrepancies. Long-term statistics are stored to catch the impulse cheater – and the hacked kkk’er, indexed by IP node, installation GUID, and player ID. The assumption is, the majority of the players don’t cheat.

We cannot allow circular validation (even though it would be more efficient), because then we cannot enforce the rule that you never relay your own authoritative packets up the peer-network to TOTS. For this reason, it’s important that the authoritative connections form a tree with no cyclic links. Validation PCs are only allowed to be higher (towards TOTS) than you are, and if you’re at the top, then you validate to TOTS (or one of his replicas, which is close enough). There will be a separate set of peer-connections for rapid informational updating to peers in the game vicinity; these node connections can be further optimized by IP locality and latency**. The authoritative ones must be random (subject to the restrictions above).

Someone could still defeat the system by hacking the validation code of the client, and sending a message between the all the validation nodes to detect that all your validation PCs are hacked clients (perhaps on a separate UDP/TCP port from a separate process). If all the validating PCs are hacked as well as the users, they can freely cheat – until the TOTS randomly switches their validation PC(s) to a non-cheater at least. Still, with enough infected nodes, you could take over the network, and/or cause false kkk hack detections of clients that are in-fact valid! Again, this is why long-term statistics are important. We need to keep statistics on who supposedly detected the discrepancy, and who supposedly caused it. We need to verify the sender as well, to prevent kkk hack spoofing.

The next check, is to have each group of peers, its validation PCs maintain a short circular buffer of original peer’s actions and results. At any time, TOTS can request that buffer be sent to it from those sources – and they had all better synchronize. With a lossy UDP based system you need to allow for holes, but all updates shall be time-stamped, so while the buffer may not all be perfect replicas, they should contain identical redundant information. This check would be triggered by a peer discrepancy detection.



* True, some “cheats” still exist in the form of mappers and spawn-locators. The effects of which can be minimized by building that capability into the game (like AC or AO), or don’t use such a special-spawn-centric game that EQ does (some EQ classes have tracking ability too, so while the mappers are an advantage, it’s generally not huge since NPCs are generally visible anyway.) The biggest problem is in-game exploits, taking advantage of bugs and unintended circumstances.

**For information packets, we can detect machine on the same subnet or LAN, and only send peer updates once across that connection, then let the local machine relay the data on the faster LAN or MAN(e.g. cable network).

Share this post


Link to post
Share on other sites
I hate to play the role of the nay-sayer because predominantly my perspective is that one can accomplish anything if they set their mind to it, spend enough time, and make enough sacrifices.

Magmai Kai Holmlor:
Your system has potential and you acknowledge that there are some assumptions being made for peer validation. I would like to present some counter point as to why this implementation may make the game "harder" to hack, but is still not as secure as a client/server model.

Firstly, in a peer-to-peer model the bandwidth requirements are actually greater per client. Instead of just communicating with one other machine on the network, like client/server. Any action a client takes must be sent (as a general rule) to all the other peers in the peer-to-peer session. So say your client initiates attack on a monster in the game, he must send that attack initiation packet to all the other peers. So say there are 20 clients in the peer-to-peer session, the bandwidth requirements are 20x more then just sending that packet to a server and having the server re-broadcast it to other clients.

This limits the size of your peer to peer sessions to about 20-25 (Table 4-1 in "Networked Virtual Environments") members (if you want to support dialup) There may be other ways to group these peer to peer groups. But typically you''d group them according to proximity in the game world. In this circumstance it''s very likely that a group of 10-20 players could go out in the middle of a desert or some other place with low player density and be in control of an entire peer to peer session. In this case they could bypass validation. Even if your server checks binaries, clients could fake the response. Also checking binaries doesn''t stop clients from hacking code execution in memory to skip the validation code.

There are solutions... I thought of a few, like the server would randomly join various peer-to-peer sessions and become the validation for that session. But this isn''t really a solution, because clients need to synch up with the peer to peer group when they join; it would be pretty easy to detect when the server was entering and leaving your session. Also, the purpose of using a peer-to-peer model was to avoid the server having to participate in the gamestate, if it''s roving around joining peer to peer sessions, the game might as well have been client server to begin with.

Share this post


Link to post
Share on other sites
Why couldn't you split the world up into blocks, and then make some randomly chosen "n" clients in charge of maintaining each block? There would be no locality to destroy things in this case.

If a player moves into an area where his computer is the server, the central server can force him to handoff server responsibilities to some other computer.

"n" could have a minimum value of say 3, so each area of the world is minimally covered by 3 different servers. Those 3 servers could trade checksums and other validation settings, for "just in case"(tm). If too many players enter the area, the area would have to be dynamically split.

Yes, the problem now is that each client has to act as a server for 3 different areas and do the processing for those areas plus the bandwidth increase of servicing all the players in that area. I don't see this being possible until quite a few years into the future.

EDIT - Then again, the server doesn't actually do that many calculations in MMORPGs, and the additional bandwidth isn't that large. So maybe it is possible today.

[edited by - Z01 on March 30, 2002 3:03:58 PM]

Share this post


Link to post
Share on other sites
In traditional MMORPG''s the server actually does alot of calculations, it decides which packets need to be sent to which clients. It also validates all the client actions to see if they fall in a reasonable scope. It is also responsible for collision detection. For instance if there was a locked door and a client was trying to move through it, if the client was responsible for the lock or the collision detection on the door, then it could be hacked and the locked door wouldn''t be useful. Thus the server must validate the locked door, and even if a client says it''s moved through the door, if it was locked the server must move the client back to the last known valid position. The server does alot of work.

We could continue this process for quite some time. People could suggest more and more elaborate plans on how to make something secure that can never truly be secured. I can continue to point out flaws with these plans. Someone might even come up with one that I would have a hard time figuring out how to hack. The point is, after all these elaborate security mechanisms are in place, your still not really going to be secure. Even if you were able to implement some elaborate security measure that was almost as secure as the client server model... you''d still have to implement it. Why not just start with a simple well understood architecture that has some inherent security built in?

Securing a client server architecture is no easy thing to do either. One must religiously follow the golden rule of client server security. Trust nothing that comes from a client, and never trust the client with any critical information.

For example, in UO, there was hiding skill that made players be invisible while they were standing still. Unfortunately the server still sent the player data to the clients if a hidden player was somewhere on the screen, it just set a little bit flag so that the client wouldn''t draw the player. Hackers soon found out this little slip up (trusting the client not to render hidden players) and ran a hack that would make all players visible. All of a sudden the hiding skill was useless because players could see hidden players if they were using the hack.

That just one example of a small slip up in a client server model that almost seriously destabilized the game. Just think of how hard it will be to secure games when you have to trust the interactions between un-trusted clients?


Share this post


Link to post
Share on other sites
The server does collision detection? Thats something I''ve never been sure about. I guess thats why EQ turned off collision detection between mobs and mob-environment testing outdoors... because it was too much processing and they couldn''t shift client-side easily. I thought they typically offloaded as much collision detection as possible to clients.

Even when I''m lagged in EQ, I can''t walk through walls and whatnot. Maybe they do collision detection in the client and then verify it on the server, to make the client more responsive. If I''m lagged I can''t walk through doors either, I''ve notice. The state of the door(open/closed) and the fact the door exists is clear stored on the server though... the EQ-server emulator doesn''t have doors.

You know, if you think about it, take away collision detection and a MMORPG doesn''t have to do much more calculations or send much more information than a MUD. Sure, you have to send period packets containing the NPCs position, velocity, and state, but because of client-side vector prediction this isn''t a large chunk. I remember they tested AO up to latencies of 2 or 3 seconds and it was running well. I think they even took it to 5-6 seconds and it was still playable.

A MMORPG isn''t a FPS, its more like a MUD. I remember talking about this with some Imms on a MUD I used to play on and I was suprised how many MUDs they could run on one server. MUDs actually use very little resources on the machine they are on.

Share this post


Link to post
Share on other sites