[ENet-discuss] Shooter Game

[Lee Salzman]

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 <lsalzman1 at cox.net>:
>   
>> 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
>>> <philip at pbsoundscape.net> 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"
>>>> <ingmania at googlemail.com>
>>>> To: "Discussion of the ENet library" <enet-discuss at cubik.org>
>>>> 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 <mr.danielaquino at gmail.com>:
>>>>>
>>>>>