Some thoughts/reactions,
"Client sees all messages",
Let''s see what we can do that does not care whether the client sees the communication then. Use only immutable variables to decide a peer''s place - IP address is probably a good choice (I *know* it can be faked - but what good is it to fake your return address when ordering stuff to be sent to you? The remaining problems with this are all standard networking issues and don''t belong here). Making the algorithm retain memory may also be a good choice - if your selected spot does not change more than once every hour, it becomes impractible to reattempt until you get a desired placement.
Having the network migrate the voting load may also make it a lot harder to band up for vote cheaters.
"Bandwidth",
Naw. Today''s MMORPGs fit in a 28.8 pipe (although that''s changing). If you make the client handle two areas instead of one, that means we''ll have to assume double downstream bandwidth and an additional upstream bandwidth roughly equal to the downstream bw of one area (as the policed area may need substantially larger output than the "played" area). Obviously, there''s a case for games requiring much bigger bandwidth than that.
The major hurdle should be latency, not bandwidth. If decisions have to be sent back and forth and coordinated between peers, that will kill latency in a traditional online "real-time" game.
So, deal with it. First, don''t try to make Planetside or EQ with this technology. A game with discrete moves, moderate pace and no rushes will be most promising of course. (The note about micromanagement and fire buttons by 5010 above is probably sound advice)
"9999 ACKs",
So structure the topology of the network to avoid having those 9999 ACKs sent from everyone to everyone. Brute force is rarely a very good strategy, after all. Show some creativity.
---
The blanket statements that P2P MMOs "can''t be done because of security/storage/bandwidth" are mostly saying "you can''t make EQ like this using brute force". Big surprise there. They''re just pointing to things that need to be dealt with.
...my 2p for today...
P2P design for MMOG's
quote:Original post by Teodric
"9999 ACKs",
So structure the topology of the network to avoid having those 9999 ACKs sent from everyone to everyone. Brute force is rarely a very good strategy, after all. Show some creativity.
Yeah I didn''t give that enough thought. I can think of some much better protocols than "assume you didn''t get it till you say you did" so my point is mute. Just a simple sequence number in each message opens up all kinds improvements.
I agree that topological solutions can minimize bandwidth. And as you mentioned, you might get increased latency but you can live with it if you take micro-management out of the design.
"Show some creativity"... wise words! So if the P2P self-organizes such that members with high bandwidth can act as hubs, then the P2P starts looking like a nomadic C/S. Hubs with spare CPU can also monitor sectors and bring cases to each other when cheating is discovered, which looks a little like a C/S with redundency built in. If the game is popular, then there is a very good chance you will have plenty of monster machines to take on those roles at any time. If the game is unpopular, then your activity will be low and you won''t need monster machines
Safety net: Cheaters will still manage to circumvent the public system, so design it to allow subcultures that act like private clubs (membership controlled by the leader and those placed in power by the leader). Subcultures would play on their own world(s), completely separate from the public world(s). Allow the subculture''s leader to turn on or off the redundant policing if the members can be trusted. Some subcultures will turn off enforcement in order to promote cheating... in other words... they are trying to see who is the best cheater! Hopefully this will attract cheaters away from the public system, but that violates Murphy''s Law.
Man this thread is interesting!!
-solo (my site)
I have been trying to implement something similar to this. The first problem is that you cannot trust any single client. There is no mechanism for executing secure code on a PC. There is always the potential for manipulation if you rely on any client side code.
One way to combat this is to maintain multiple concurrent user-side servers. Each one can maintain its own sanity and answer queries from a secure central server. The central server could check the sanity of various items in each of the concurrent user-servers. It would also check clients and do critical checks. These checks could be cross referenced with the user servers to see if something is fishy. The operations are probably going to be somewhat CPU intensive. But the bandwidth needed for a central server is greatly reduced.
An added benefit would be the switchover ability. Since the user-servers should each be in sync and maintain the same environment there should be no perceived glitch by the user. The client should just go to the next user-server.
Also it would be needed to develop a method for planning and plotting out network capacity. You don’t want some guy with a 56K connection hosting 30 guys. Also if some guy is playing at work on a T3 you don’t want to saturate his CPU with server tasks. Also it would be unreasonable to have him soak the bandwidth for a whole load of clients.
One way to combat this is to maintain multiple concurrent user-side servers. Each one can maintain its own sanity and answer queries from a secure central server. The central server could check the sanity of various items in each of the concurrent user-servers. It would also check clients and do critical checks. These checks could be cross referenced with the user servers to see if something is fishy. The operations are probably going to be somewhat CPU intensive. But the bandwidth needed for a central server is greatly reduced.
An added benefit would be the switchover ability. Since the user-servers should each be in sync and maintain the same environment there should be no perceived glitch by the user. The client should just go to the next user-server.
Also it would be needed to develop a method for planning and plotting out network capacity. You don’t want some guy with a 56K connection hosting 30 guys. Also if some guy is playing at work on a T3 you don’t want to saturate his CPU with server tasks. Also it would be unreasonable to have him soak the bandwidth for a whole load of clients.
Thinking on this more, I see that for most game types it is a possible solution. One small problem I do see, however, is anything random. In a typical FPS game now, your machine-gun type weapons have a semi-random firing pattern(or fully random, I don''t know, still working on my engine...) So, You tell each client to take given information, and play it out on it''s own processor power as opposed to sending it out over your limited bandwidth. But if it is random, and with a decent area sensitive damage system, each client will come up with a different amount of damage.
Making random things like this be calculated by one client and then sent out to the rest would be a beautiful way for some jerk to lag the hell out of an otherwise good game. "Just wait till I grab the ''fire 1000 shots a second-o-matic! I''ll lag you all since it''s got a random fire pattern!'' Even making whoever fires the weapon the law on this would suck, "No, it didn''t do only 45% damage, it did 50% because these hit here, here, and here!"-Let''s mess with our client sourcecode and tell it no matter where it hit, it did 100%.
Or maybe I''m worrying about nothing in particular. Random fire-patterns don''t seem very important, and aren''t incredibly impressive to the average player anyways. I''ll flog the dead horse with this one, how about the /random system in EQ? Could get painful to go P2P with that.
Sorry for all the questions and stuff, I''m just trying to design a system to allow 32 players to fight at once in a "camp", which is only a segment of the entire world. I thought perhaps P2P would work for this, with the server playing mediator here, "Client 1, clients 2, 3, 4 and 5 are in camp 7, you all can talk directly to each other now." Since I haven''t got access to large server banks at all. Maybe P2P will work, any more insight here?
Making random things like this be calculated by one client and then sent out to the rest would be a beautiful way for some jerk to lag the hell out of an otherwise good game. "Just wait till I grab the ''fire 1000 shots a second-o-matic! I''ll lag you all since it''s got a random fire pattern!'' Even making whoever fires the weapon the law on this would suck, "No, it didn''t do only 45% damage, it did 50% because these hit here, here, and here!"-Let''s mess with our client sourcecode and tell it no matter where it hit, it did 100%.
Or maybe I''m worrying about nothing in particular. Random fire-patterns don''t seem very important, and aren''t incredibly impressive to the average player anyways. I''ll flog the dead horse with this one, how about the /random system in EQ? Could get painful to go P2P with that.
Sorry for all the questions and stuff, I''m just trying to design a system to allow 32 players to fight at once in a "camp", which is only a segment of the entire world. I thought perhaps P2P would work for this, with the server playing mediator here, "Client 1, clients 2, 3, 4 and 5 are in camp 7, you all can talk directly to each other now." Since I haven''t got access to large server banks at all. Maybe P2P will work, any more insight here?
You can sync random numbers between peers. Just construct the seed out of numbers that can be syncronized. Perhaps seed=getseed(x,y,z,t) for an object acting at position (x,y,z) at timeframe t. Then when you tell your peer "I was here and did this at this time" then your peer can calculate the result itself by finding the same seed and feeding it into the same random function.
-solo (my site)
-solo (my site)
Ahh, I see, solves that problem easily.
So, what I have thought out is this: We have a "world", which contains many "camps" individual to players(ie, start the game and choose a camp to defend and live on) Using a sort of hybrid networking scheme where the server only needs to save player data on logoff and do the occasional cheat check or whatever. And then the clients connect on a P2P system after first logging into my server through my client(Prevent some of the not-so-great cheaters by doing a quick check of the files) The server would then say that since Player 1 is in his camp 1, and player 2 is in camp 20(I''m saying it''s geography independant) these two can then send information back and forth to each other, for example "Player 1 moved 2 units, at a x angle, so update your screen" Of course we have player 2''s client check to make sure that was a fair move on Player 1''s part, and we should have a system that makes interaction on my part limited to database storage and player grouping off into P2P sessions.
Any corrections?
So, what I have thought out is this: We have a "world", which contains many "camps" individual to players(ie, start the game and choose a camp to defend and live on) Using a sort of hybrid networking scheme where the server only needs to save player data on logoff and do the occasional cheat check or whatever. And then the clients connect on a P2P system after first logging into my server through my client(Prevent some of the not-so-great cheaters by doing a quick check of the files) The server would then say that since Player 1 is in his camp 1, and player 2 is in camp 20(I''m saying it''s geography independant) these two can then send information back and forth to each other, for example "Player 1 moved 2 units, at a x angle, so update your screen" Of course we have player 2''s client check to make sure that was a fair move on Player 1''s part, and we should have a system that makes interaction on my part limited to database storage and player grouping off into P2P sessions.
Any corrections?
quote:Original post by Revelations
Any corrections?
Sounds about right.
some challenges:
- peers disagreeing
- too many peers in a zone
- peers behind firewalls
-solo (my site)
Yup, I know this is a rather late addition, and maybe of no help to the guy writing his thesis - but the ACM had a whole conference on networked games, and the papers are available in their online library.
Drawback - you actually have to be an ACM member. It''s not quite cheap, but definitely worth the money.
- Robert
Drawback - you actually have to be an ACM member. It''s not quite cheap, but definitely worth the money.
- Robert
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
