Do you think that bullet messages should be guaranteed ? to note in forsaken bullet messages are sent and then the player updates the missile location locally.
On Wed, Apr 15, 2009 at 10:23 PM, Lee Salzman <[email protected]> wrote: > No, it does not echo stuff back to the sender. > > It only sends updates for what it has during that period. If it receives > more than one position update for a given player during that period, only > the last one is stuffed into the bulk update. > > Lee > > ingmar wirths wrote: >> >> 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]>: >>>>>> >>>>>> > > _______________________________________________ > 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
