[ENet-discuss] Shooter Game

Wed Apr 15 04:47:35 PDT 2009

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>:
>>>>
>>>>>
>>>>> 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
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>