--- 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}