# HG changeset patch # User ekku # Date 1228796550 0 # Node ID 1b87b1e0ae1d1b65d82fcc9acea7f16897be2a5d # Parent 359c80ebd9643ac0d0efc24b7993cbcf5820186d network move diff -r 359c80ebd964 -r 1b87b1e0ae1d doc/kishna.tex --- a/doc/kishna.tex Tue Dec 09 04:14:55 2008 +0000 +++ b/doc/kishna.tex Tue Dec 09 04:22:30 2008 +0000 @@ -148,6 +148,58 @@ are some nice diagrams about the program structure in the doxygen documentation. +\subsection{Network} + +The network code is implemented as separate NetworkServer and NetworkClient modules, which use a common high-level +network interface, NetworkSession and NetworkObject. + +The low-level details are implemented using ClanLib's CL\_IPAddress (referred to as NetworkAddress) and CL\_Socket. +NetworkUDP provides an interface to send and receive NetworkPackets to/from specific NetworkAddress's across a +NetworkSocket. NetworkTCP provides a NetworkTCPTransport interface, which can send/receive NetworkPackets on a +NetworkSocket (using NetworkBuffer to buffer socket I/O). NetworkTCPServer is a listen() socket which accepts client +connections as NetworkTCPTransports, and NetworkTCPClient is a NetworkTCPTransport that's connect()'d to some address. + +NetworkSession encapsulates some simple application server/client behaviour, it can function as both a server, and +represents remote NetworkSessions (either clients or servers) as NetworkNode objects. These then provide an interface +to send and receive NetworkPackets on specific NetworkChannelDs, using either TCP or UDP as a reliable/unreliable +transport. + +NetworkObject then implements a kind of object-oriented network protocol. A NetworkObjectController (with specific +subclasses for server/client behaviour) uses a NetworkSession to send messages on a specific NetworkChannelID. This +controller then creates and looks up NetworkObjects (again, with specific subclasses for server/client behaviour). +Clients and servers can then communicate by having the server construct new NetworkObjects (which are allocated an +unique id), and then sending NetworkPackets with a specific NetworkMessageID type on a specific object. The message is +then delivered directly to the NetworkObject instance on the remote end of the connection, or a new NetworkObject is +constructed using the data in the NetworkPacket. This enables an easy way to send events for specific objects, and +referr to other objects in these messages. + +NetworkServer then implements a core NetworkServer class which has a NetworkSession and a +NetworkObject\_ServerController. Players that connect are represented as NetworkServerPlayers, which inherit from +LocalPlayer and NetworkObject\_Server. This class then overrides methods in Player to deliver messages on the Player +object to the clients, or to create new NetworkServerProjectiles. NetworkServerProjectile inherits from Projectile and +NetworkObject\_Server, and sends messages when constructed, upon hitting a player, and upon being destroyed. + +NetworkClient is a bit more complicated as it must handle both the LocalPlayer, and a number of RemotePlayers. Again, +NetworkClient has a NetworkSession and a specialized NetworkClientController, which then creates objects of various +other NetworkClientClasses upon receiving messages from the server. + +Two of these classes are NetworkClientLocalPlayer and NetworkClientRemotePlayer. Both inherit from +NetworkClientPlayerBase, which inherits Player (virtually) and NetworkObject\_Client. NetworkClientLocalPlayer and +NetworkClientRemotePlayer then also inherit LocalPlayer and Remote player virtually, respectively. +NetworkClientPlayerBase contains the common methods that update the Player's state in response to messages received +from the server. NetworkClientLocalPlayer overrides handleInput to send the input mask to the server, and +NetworkClientRemotePlayer can handle remote clients disconnecting from the server. + +In addition, there is a NetworkClientProjectile class, which inherits from Projectile and NetworkObject\_Client. +this is created when a Player fires a Weapon on the server, and handles events received from the server like the +projectile hitting a player (inflicting damage), or being destroyed (by hitting the terrain or something similar). + +When the player first connects to the server, the server sends a large packet containing the terrain array to the +client, which updates its own GameState world's terrain array with the received data. + +Currently, the client only sends handleInput using unreliable UDP messages, and the server only sends position updates +(as sent in response to handleInput events) unreliably. All other events are sent using reliable TCP. + \section{Data structures and algorithms} \subsection{Basic data structures} @@ -290,58 +342,6 @@ Since some inputs like walking, aiming and moving up and down the rope are time-dependant, the InputHandler also tracks how many milliseconds the input mask has been held, and this time delta is applied by LocalPlayer. -\subsection{Network} - -The network code is implemented as separate NetworkServer and NetworkClient modules, which use a common high-level -network interface, NetworkSession and NetworkObject. - -The low-level details are implemented using ClanLib's CL\_IPAddress (referred to as NetworkAddress) and CL\_Socket. -NetworkUDP provides an interface to send and receive NetworkPackets to/from specific NetworkAddress's across a -NetworkSocket. NetworkTCP provides a NetworkTCPTransport interface, which can send/receive NetworkPackets on a -NetworkSocket (using NetworkBuffer to buffer socket I/O). NetworkTCPServer is a listen() socket which accepts client -connections as NetworkTCPTransports, and NetworkTCPClient is a NetworkTCPTransport that's connect()'d to some address. - -NetworkSession encapsulates some simple application server/client behaviour, it can function as both a server, and -represents remote NetworkSessions (either clients or servers) as NetworkNode objects. These then provide an interface -to send and receive NetworkPackets on specific NetworkChannelDs, using either TCP or UDP as a reliable/unreliable -transport. - -NetworkObject then implements a kind of object-oriented network protocol. A NetworkObjectController (with specific -subclasses for server/client behaviour) uses a NetworkSession to send messages on a specific NetworkChannelID. This -controller then creates and looks up NetworkObjects (again, with specific subclasses for server/client behaviour). -Clients and servers can then communicate by having the server construct new NetworkObjects (which are allocated an -unique id), and then sending NetworkPackets with a specific NetworkMessageID type on a specific object. The message is -then delivered directly to the NetworkObject instance on the remote end of the connection, or a new NetworkObject is -constructed using the data in the NetworkPacket. This enables an easy way to send events for specific objects, and -referr to other objects in these messages. - -NetworkServer then implements a core NetworkServer class which has a NetworkSession and a -NetworkObject\_ServerController. Players that connect are represented as NetworkServerPlayers, which inherit from -LocalPlayer and NetworkObject\_Server. This class then overrides methods in Player to deliver messages on the Player -object to the clients, or to create new NetworkServerProjectiles. NetworkServerProjectile inherits from Projectile and -NetworkObject\_Server, and sends messages when constructed, upon hitting a player, and upon being destroyed. - -NetworkClient is a bit more complicated as it must handle both the LocalPlayer, and a number of RemotePlayers. Again, -NetworkClient has a NetworkSession and a specialized NetworkClientController, which then creates objects of various -other NetworkClientClasses upon receiving messages from the server. - -Two of these classes are NetworkClientLocalPlayer and NetworkClientRemotePlayer. Both inherit from -NetworkClientPlayerBase, which inherits Player (virtually) and NetworkObject\_Client. NetworkClientLocalPlayer and -NetworkClientRemotePlayer then also inherit LocalPlayer and Remote player virtually, respectively. -NetworkClientPlayerBase contains the common methods that update the Player's state in response to messages received -from the server. NetworkClientLocalPlayer overrides handleInput to send the input mask to the server, and -NetworkClientRemotePlayer can handle remote clients disconnecting from the server. - -In addition, there is a NetworkClientProjectile class, which inherits from Projectile and NetworkObject\_Client. -this is created when a Player fires a Weapon on the server, and handles events received from the server like the -projectile hitting a player (inflicting damage), or being destroyed (by hitting the terrain or something similar). - -When the player first connects to the server, the server sends a large packet containing the terrain array to the -client, which updates its own GameState world's terrain array with the received data. - -Currently, the client only sends handleInput using unreliable UDP messages, and the server only sends position updates -(as sent in response to handleInput events) unreliably. All other events are sent using reliable TCP. - \section{Known bugs} \begin{enumerate} \item If player dies while rope is attached the rope will still be @@ -377,11 +377,12 @@ code ended up being a fair bit more simple-minded due to lack of time to implement more UDP-based behaviour. +Currently, the program lacks an AI which was in the original plan and most of the optional features were also omitted. Liero clone proved to be, however, a very interesting software project and we are hoping to release Kishna Glista 2.0 one day. + % References \begin{thebibliography}{99} -\bibitem{gaffer} Gaffer on games. Game - Physics. 2006. http://gafferongames.wordpress.com/game-physics/ - (read: 2008-12-08) +\bibitem{gaffer} Gaffer on games. Game Physics. 2006. \\ + http://gafferongames.wordpress.com/game-physics/ (read: 2008-12-08) \bibitem{fractal} Terrain texture generation. http://www.gameprogrammer.com/fractal.html \end{thebibliography}