[ENet-discuss] Shooter Game

[Daniel Aquino]

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