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
<[email protected]> 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"
<[email protected]>
To: "Discussion of the ENet library" <[email protected]>
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 <[email protected]>:
