[ENet-discuss] unsubscribe

John Viniski jpviniski at DRPA.ORG
Wed Apr 15 11:17:55 PDT 2009


 

-----Original Message-----
From: enet-discuss-bounces at cubik.org
[mailto:enet-discuss-bounces at cubik.org] On Behalf Of Lee Salzman
Sent: Wednesday, April 15, 2009 10:24 PM
To: Discussion of the ENet library
Subject: Re: [ENet-discuss] Shooter Game

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


More information about the ENet-discuss mailing list