[ENet-discuss] Shooter Game

Tue Apr 14 19:52:50 PDT 2009

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>:
>>>       
>>>> How well do you guys think a basic shooter game can scale with a
>>>> peer-to-peer protocol ?
>>>> _______________________________________________
>>>> ENet-discuss mailing list
>>>> ENet-discuss at cubik.org
>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>
>>>>         
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> 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
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>     
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>   