You say the server is a broadcaster, does this mean you send to clients back their own data?
You said the position data is send unreliable. How does the server react when there isn't a position update for each player, when time has come to send this bulked packet you mentioned? Cheers, ingmar 2009/4/15 Lee Salzman <[email protected]>: > Cube 1 had no authoritative server whatsoever - a result of trying to write > something as quickly and dirtily as possible - but which strangely worked > out pretty well in the end. One client (the shooter, who determined whether > he actually hit the target) sent his shot message to the other client, and > that other client (the target) damaged himself once he got the message, and > sent back a message whether he died and what his health was back to the > shooter. Cube 1 used a standard client-server model, although the server was > little more than a dumb re-broadcaster. If it was peer-peer this would have > effectively cut packet travel times in half, but on the other it might have > caused a nightmare in terms of ensuring all clients can connect to one > another, since in the strange world of the internet routing A -> B -> C does > not necessarily imply A -> C. Though, some hybrid where by default things > are sent through the server to some set of other clients until the the > server knows the client has a direct peer-peer connection to those other > clients might be cool. Thankfully Cube 2 now does the damage determination > on the server, although the server still does not do any physics simulation > at all, so the client is still determining where it moved, sending to > server, and server broadcasting that to other clients. > > You do leave open lots of opportunities for cheats, but no matter how much > you push onto the server, there is always opening for cheats - aimbots, > wallhacks, etc. plague every FPS game known to man, no matter how "secure". > So if you can just get rid of the more annoying cheats, like Cube 2 did by > moving the damage calculations and firing rate validation (not the hit > determination or movement position stuff, though), you can reduce the burden > enough that something like Cube 2's system of moderators (though you do need > a lot of sanctioned player moderators for this to work) who can kick > cheaters on any game server they log into can weed out the rest of the > idiots. :) To some extent, by allowing easy cheats, you also make cheating > easier to spot because people don't try to be very subtle with their cheats > when its possible to make bigger, more grandiose cheats that are easy to > spot and kick people for. > > Regardless, the biggest consumers of bandwidth and perhaps the most latency > sensitive data is position packets. In Cube 1/2, each position packet runs > about 20 bytes for each player (since it carries position, velocity, any > physics/animation state, etc), and it is sent unreliably at a fixed rate of > 30 times a second. So you end up with a situation where the bandwidth usage > is (for N=number of players): N*(N-1)*20*30 bytes per second, since each > player must send its position to every other player. Now, in Cube 2, the > server aggregates these into one packet spanning that 1/30th second > interval, such that each player is getting a bulk packet containing > positions updates from every other player - vastly saving on the overhead of > individual UDP packets, since N-1 position updates are grouped into one > single ENet packet. If you went with a peer-peer scheme, the individual load > per peer would then only be (N-1)*20*30, but with greater overhead in > packets/headers, since they can't be bulked together into a single packet - > each update goes to a different client. But for each peer, this is all > upstream bandwidth. > > Looking at the bandwidth, in client-server situation, each client is pulling > down (N-1)*20*30 bytes of data to get the updates for all other players, but > these are bulked into a smaller number of individual packets, and its all > downstream bandwidth, which is generally much higher than upstream > bandwidth. So the bandwidth situation, although requiring a much beefier > server to handling all the re-broadcasting, is very much better for > client-server when thinking of individual clients. You have larger round > trip times for the position data (the shot data however only goes to server > and back to shooter, never to target client in Cube 2 - so peer-peer would > not help there), but this is combated by the fact that the position data is > unreliable, sent extremely frequently, and that shot determination is done > on the client (client determines if it hit someone, server just determines > how much damage was actually done). So net effect is just that positions are > maybe 100-200ms behind where they might be otherwise, but bandwidth usage is > much better and connection hassles are much less. > > YMMV. :) > > Lee > > Daniel Aquino wrote: >> >> Yea, Forsaken has been p2p since the beginning and it simply has >> "shooter perspective" or "target perspective" meaning you either play >> with the shooter deciding if you were hit or the target deciding if >> they got hit... >> >> Normally we always play with target perspective cause nobody likes >> putting in effort to dodge and then still getting hit... >> >> I wrote a small p2p prototype on enet and I'm just wondering how well >> it could scale in the end... I found some old posts saying that enet >> was able to handle 8000 incoming packets. But network programming is >> really a new ball game for me. >> >> Down the road I might attempt to implement a server/client setup but >> as one of you already stated I would have support for any client to >> act as a server. >> >> Another options is to have support for a pseudo host which would be >> the first person to connect to the server and would have control over >> setting up the game. >> >> On Tue, Apr 14, 2009 at 9:31 AM, Philip Bennefall >> <[email protected]> wrote: >> >>> >>> I don't really agree here. P2p would work very well for shooter games, >>> you >>> simply use the person who starts the first connection as the server or >>> implement some other way of choosing who deals with what tasks, maybe >>> even >>> split it over the different players to save each individual user's >>> bandwidth. One player could handle judgements and timing, another could >>> handle the player stats etc etc. >>> >>> If I'm not mistaken, ENet was created for these exact purposes to begin >>> with; fast action games. >>> >>> Regards >>> Philip Bennefall >>> ----- Original Message ----- From: "ingmar wirths" >>> <[email protected]> >>> To: "Discussion of the ENet library" <[email protected]> >>> Sent: Tuesday, April 14, 2009 2:36 PM >>> Subject: Re: [ENet-discuss] Shooter Game >>> >>> >>> >>>> >>>> A shooter game needs a judge, thus someone to decide who got >>>> hit and died etc. This judge naturelly is the server in a client/server >>>> architecture. I doubt that a peer-to-peer protocol makes sense for >>>> a shooter game. >>>> >>>> cheers, >>>> ingmar >>>> >>>> 2009/4/13 Daniel Aquino <[email protected]>: >>>> >>>>> >>>>> How well do you guys think a basic shooter game can scale with a >>>>> peer-to-peer protocol ? >>>>> _______________________________________________ >>>>> ENet-discuss mailing list >>>>> [email protected] >>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> ENet-discuss mailing list >>>> [email protected] >>>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>>> >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.0.238 / Virus Database: 270.11.55/2057 - Release Date: >>> 04/13/09 >>> 17:56:00 >>> >>> _______________________________________________ >>> ENet-discuss mailing list >>> [email protected] >>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>> >>> >> >> _______________________________________________ >> ENet-discuss mailing list >> [email protected] >> http://lists.cubik.org/mailman/listinfo/enet-discuss >> >> > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
