On 10/24/05, Andrew Sayers <address@hidden> wrote:
On Mon, Oct 24, 2005 at 09:35:50PM +0200, Martin Voelkle wrote:
> > You
forgot that the salvage proposal uses a central server where
> the game
> > runs. The model can therefore be extremely simplified:
>
> Yes, but I still believe the peer-to-peer nature of the game can work,
> and that if it can work, it's a better solution than a central server.
>
> For example, memory would be a very serious issue on a central server.
> The map code alone will take more than (21 * number_of_teams * map_width
> * map_height) bytes of data per game. For an 8 player 512*512 map,
> that's 42 megabytes of data - manageable for one game, but do you want
> to donate the server that could be asked to run a dozen of them at once?
>
> It doesn't need to be like that. The server would be the machine of one of
> the players. Many games work like that. There is a host player which
> creates the game. The other players join it. When the host player starts
> the game, a server is started on his computer and the other computers just
> act as clients. The host player runs both the server and his own client.
> The server and the client can be embedded in the same executable. If they
> are splitted, you can run a standalone server, which is very convenient if
> one of the players has a spare machine to run it.
That's true - although a client with no state information would have to
get updates about every movement of every glob, which would take
significantly more memory, and be significantly more susceptible to
network instability.
It would take way less memory than the pathfinding stuff (gradients,
etc.). Network latency would be much better with this design, and
that's the problem with the complexity of having every player running
the game: synchronization of orders needs high latency. And that is
incredibly more susceptible to network instability: dropped packets
lead to multiplying the latency you have with optimal conditions.
Running the clients asynchronously frees us from this high latency and its terrible fragility.
The only loss with the server design would be the higher network
bandwidth, which is every day less of an issue. Additionally, we could
use very simple bandwidth adaptation techniques, like only sending
information about the displayed portion of the map which would only
impact the update of the display when scrolling. And glob's movements
are very lightweight: they only change when the glob is on a new cell,
which occurs every 20 ticks (I'm not sure about this number).
Ressources growth information is also very slim.
This solution would still benefit from our own protocol stack, so that
the game server didn't have to deal with all the bandwidth of every game
of Glob2.
>
> > -
The only good way to prevent spoofing is to use some lightweight
> digital
> > signature
(encryption). Here the metaserver can act as a trusted
> server to
> > establish
a secure connection between the client and the server.
> While
> > encryption
might be too heavyweight for the server, it can easily
> be run
> > in
parallel to the game to take advantage of multiple processors or
> > HT-like processors.
>
> The real question is: why prevent spoofing? What do people have to gain
> by attacking a game of Glob2? The most likely outcomes are to make the
> game desynchronise or insert orders that shouldn't be there. While
> annoying, these are hardly a major threat.
>
> I agree with you. It's just a possibility to consider.
> I remember back in ye olde days when there was a bug in glob2 that allowed
> to restore a building's HP by upgrading and cancelling the upgrade.
> Gentlemen's behaviour said we shouldn't use this trick, but some people
> where doing it anyway... They will recognize themselves, as they will
> probably read this.
I don't remember back that far, so it's useful for me to hear about
these sorts of things. I've been brushing up on my security knowledge
while writing these messages :)
At any rate though, securing communication strikes me as something that
can be bolted on to the game at a later date if needs be, so it's safe
to ignore it for now.
I completely agree.