I think OpenTNL would be a good choice for the new protocol.
( -> http://opentnl.sourceforge.net/doxydocs/simpletutorial.html )

We should also think about preventing sending unnecassary information. For example the clients will probably do also the physic-simulation theirself (which is needed to provide a smoother game-feeling for them). Then they could send sort of a checksum over the physics-world and if this is to different from the correct one they will get an update.


-----------------------------

It is still not sure, which parts we should made client-side and which server-side. It is clear, that if we make everything server-side, we cannot gain such a smooth game feeling as we have with LX56 protocol.

Also the design itself is not sure yet.

An overview what features a new protocol should be able to handle:

- force random weapons ( or predefined special set of weapons )
( -> server should be able to update clients weapons )
- in-game joining of clients
- in-game adding/removing of worms to any client
- allow clients with 0 worms (spectators)
( -> on a connect, the client always has 0 worms first and can add the worms then )

- it should be easily checkable for a client, if a server function is available or not
( for example on a client: user clicks on 'add new bot worm', server says 'unknown command' (or other message), client makes message 'not possible on this server' + server msg )

- see others correct health

- client can request current state of worm ( is dead, position, current weapon, whatever)
- client can also have state: is_typing
- server can update clients worms states
- server should inform about respawn time when worm is waiting for respawn

- use different physics engine ( so the server has to tell which one is used )
[ - physic engines that are not present on client ?? ]

- server should inform about gametype name (like DM or whatever)
- though all the handling of gametype is done server side, this includes:
	- counting points
	- finishing game + show results
	- defining teams

- special game-objects should be handled by server, that includes position-updates, behaviour and graphics
( Therefore a server could have some new game-objects and clients don't have to know about them. Usefull for modding. )

- set control to other object ( like remote projectile; but could be abstracted to control also other vehicles )


------------------------

As said, still some things have to be made client-side.

Here some ideas for security against cheating when handled client-side:

1. Health
Clients can collect information where the projectiles have passed and what damage they made. Server will calculate the health based on that information and handle the deaths. Server can also check if the damages and the behaviour of the projectiles are sane/correct. <- Doesn't this go under the checksum for physics? If the client is kept up-to-date with the server, then this would be obsolete as the server knows who got hit and who didn't?
