\documentclass[a4paper,12pt]{article}

\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage{amsmath}
\usepackage{listings} % For listing code

% Fancy headers
\usepackage{fancyhdr}
\fancypagestyle{plain} {
    \fancyhf{}
    \renewcommand{\headrulewidth}{0.4pt}
    \lhead{\textbf{Group 66}}
    \chead{\textbf{Kishna Glista - liero clone}}
    \rhead{\textsl{AS-0.1102}}
    \cfoot{\thepage}
}
\pagestyle{plain}

% Paragraph formatting
\frenchspacing
\setlength{\parindent}{0pt} 
\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}

% Title information
\title{Kishna Glista - Liero Clone}
\author{\normalsize{\begin{tabular}{lll}
Atle Kivelä & 79171V & atle.kivela@tkk.fi \\
Eric Malmi & 80351A & eric.malmi@tkk.fi \\
Tero Marttila & 79849E & tjmartti@cc.hut.fi \\
Marko Rasa & 78726L & morasa@cc.hut.fi \\
\end{tabular}}}

% The document begins
\begin{document}
\maketitle

\section{Instructions for compiling and use}

\subsection{Configuring CMake}
You must first generate the project's CMake configuration inside of \textsl{build}. A simple script is provided to do
so with some default settings. It will configure the install path as \textsl{~/opt}.

\begin{itemize}
\item \textsl{cd build}
\item \textsl{./mkcmake.sh}
\end{itemize}

\subsection{Compiling and Installing}
Once you have the CMake scripts in place, compiling should be as simple as running make:
\begin{itemize}
\item \textsl{make}
\item \textsl{make install}
\end{itemize}

This will build the binary, and then copy the binary and data files to the install path configured above.

\subsection{Command-line Arguments}
Running the game is done using command-line arguments to the executable
\begin{center}
\begin{tabular}{l|l|l|l|l}
\textbf{Short} & \textbf{Long} & \textbf{Value} & \textbf{Description} & \textbf{Default} \\
\hline
-p & \verb|--port| & PORT & Set server TCP/UDP port & 9338 \\
-s & \verb|--server| &  & Run as a network server & false \\
-c & \verb|--client| & SERVERHOST & Run as a network client on given server & false \\
-g & \verb|--graphics| & & Enable graphics rendering & * \\
\end{tabular}
\end{center}

* = true, except false when --server is given

The options \verb|--server| and \verb|--client| are mutually exclusive, and both cannot be selected at the same time.

\subsection{Keyboard Controls}
The default controls are identical to the origional Liero default controls, with some additions.

\begin{center}
\begin{tabular}{l|l}
\textbf{Action} & \textbf{Default key(s)} \\
\hline
Move Left & Arrow Left \\
Move Right & Arrow Right \\
Aim Up & Arrow Up \\
Aim Down & Arror Down \\
Dig & Move Left + Move Right \\
Shoot & Right Control \\
Jump & Right Shift \\
Change Weapon & Enter + Arrow Left / Arrow Right \\
Throw Rope & Change Weapon + Jump \\
Release Rope & Jump \\
Change Rope Length & Change Weapon + Aim Up / Aim Down \\
Suicide & Left Control + K \\
Exit Game & Esc \\
\end{tabular}
\end{center}

\subsection{Running the game}
To simple start a local singleplayer game, just run `kg` without any arguments.

To start a network server on the default port, run `kg --server` (`kg -s`). You may optionally also specify the
`--graphics` argument to have the server passively draw the graphics.

To start a network client, connecting to a server running on the default port, run
`kg --client=ADDRESS` (`kg -c ADDRESS`).

To use a non-default port, simply specify `--port=PORT` (`-p <port>`) on both client and server.

\subsection{Configuration}
All global game constants are defined in `src/Config.hh`, and may be experimented with. Weapon parameters are defined
in `src/Weapons.cc`.

\section{Program architecture}
Execution starts in Application, which parses the command-line arguments, and then invokes methods in Engine. Engine
creates the GameState, and then Graphics, SinglePlayer, NetworkServer or NetworkClient objects.

GameState contains PhysicsWorld, which inherits from Terrain and contains a list of PhysicsObjects.

GameState then contains Player objects and Projectile objects, both of which inherit from PhysicsObject.

Player objects have a list of Weapon objects, and can use these to create Projectiles. Every Player also has a Rope
object, which is in itself a separate PhysicsObject, and is either folded away, being thrown, or attached to the
terrain.

The network code is a bit more complicated, with several layers.

NetworkAddress and NetworkSocket are ClanLib's Socket/IPAddress types. NetworkPackets provide a mechanism to read/write values from/to a byte buffer, and NetworkBuffer is used for buffering socket I/O.

NetworkUDP is an UDP socket. NetworkTCPServer is a listen() socket, which spawns NetworkTCPTransports when clients connect. NetworkTCPClient is itself a NetworkTCPTransport with a connect()'d socket.

NetworkSession can have a NetworkTCPServer socket, and both client and server NetworkUDP sockets. Connected clients are
represented as NetworkNodes.

NetworkObjectControllers can be attached to a NetworkSession on a specific NetworkChannelID, and they then manage
instances of NetworkObjects, which have NetworkObjectIDs that can be sent across the network. NetworkObjects can be
used to send messages with a specific NetworkMessageID.

NetworkServer then has a NetworkSession and NetworkObject\_ServerController, and then creates NetworkServerPlayer and
NetworkServerProjectile objects (that are NetworkObject\_Server's).

NetworkClient then has a NetworkSession and a specialized NetworkClientController (NetworkObject\_ClientController) that
creates NetworkClientLocalPlayer/NetworkClientRemotePlayer/NetworkClientProjectile objects when they are received from
the server.

Graphics has an Input object, which contains InputHandler objects for various classes of input, such as PlayerInput (which affects the GameState's LocalPlayer), and GuiInput (which just modifies what the GUI looks like on the client side).

TODO: Replace the above with some nice diagram, and make the text more brief

\section{Data structures and algorithms}


\subsection{Basic data structures}

\begin{itemize}
\item Vector
\item List
\end{itemize}

\subsection{World and Objects}

% COMMENT: I think these should be in a very basic level and they
% shouldn't discuss too much about the game itself. The idea is just
% to explain different kinds of structures and algorithms.

% Terrain
The terrain is an important part of our game. We represent our terrain
as a large array. Each shell of the array has a type that tells what
is in that position. Currently, possible terrain types are EMPTY, DIRT
and ROCK. 

% Usually, in side view 2D-games, the terrain is representated as a
% polygon. This allows us to implement collision detection and
% bouncing rather easily, and it is also a very compact way of storing
% the map. In our opinion Liero, however, is fundamentally a pixel
% based game and therefore we represent the terrain as a large array
% of pixels. These pixels are, however, abstract pixels, i.e. they are
% not necessarily in the same scale than the physical resolution. In
% other words, the server has an abstract resolution, which is the
% same for all clients, and the clients can visualize this abstract
% array of pixels in any resolution they wish.

% Objects
In our physics simulation the shapes of the different elements in the
game are represented as polygons. A polygon is a vector of points that
define the edges of the shape.

% On top of the terrain, the world also includes a list of all objects
% in it (players, projectiles and ropes). The objects have a polygon
% shape which is used in the collision detection between the objects
% and the terrain and the objects with each other.

\subsection{Collision Detection}

\begin{itemize}
\item Polygon collision detection
\item Pixel collision detection
\end{itemize}

Collision detection algorithms check if objects in the physics
simulation are colliding with eachother. Because our terrain is
represented as an array and objects are represented as polygons we
have two different kinds collision detection algorithms.

The pixel based collision detection used to check collisions with the
terrain is quite simple. It ``draws'' a line between two points A and
B. The algorithm iterates over the line from point A to B and on each
iteration it checks if theres a collision (i.e. the type of the
current point is ROCK or DIRT).

In order to implement bouncing from the terrain we have to have a way
of calculating a normal for the slope of the terrain in the collision
point. We came up with the following algorithm for calculating the
approximation for the normal. Take the collision point and the point
before the collision and consider a 3x3 array of pixels which has the
collision point in the middle of it. Then, do sort of an bredth-first
search from the previous point to get all the empty pixels. Take the
vectors from the collision point to the empty point and sum these
vectors. The resulting vector will point approximately along the
normal. % Picture would explain this a lot. 

\subsection{Physics}

The fourth-order Runge-Kutta method is a numerical method for
approximating the solution of an ordinary differential equation. In
our game the Runge-Kutta method is used to calculate positions and
velocities of physics objects when we apply forces to them.

The mathematical formulation of the Runge-Kutta method:
If we have an initial value problem of the form
\begin{equation*}
y' = f(t, y), \quad y(t_0) = y_0.
\end{equation*}
The we can describe the RK4 method for this problem by equations
\begin{align*}
y_{n+1} &= y_n + \tfrac{1}{6}h\left(k_1 + 2k_2 + 2k_3 + k_4 \right) \\
t_{n+1} &= t_n + h \\
\end{align*}
where $y_{n+1}$ is the RK4 approximation of $y(t_{n+1})$, and
\begin{align*}
k_1 &= f(t_n, y_n) \\
k_2 &= f(t_n + \tfrac{1}{2}h, y_n + \tfrac{1}{2}h k_1) \\
k_3 &= f(t_n + \tfrac{1}{2}h, y_n + \tfrac{1}{2}h k_2) \\
k_4 &= f(t_n + h, y_n + h k_3) \\
\end{align*}
The next value $(y_n+1)$ is determined by the present value $(y_n)$,
the product of the interval $(h)$ and an estimated slope that is
defined as $\frac{1}{6}h\left(k_1+2k_2+2k_3+k_4\right)$.

% TODO: something network related?

\section{Known bugs}
\begin{enumerate}
\item If player dies while rope is attached the rope will still be
  attached when the player spawns.
\item Collisions with the terrain are only tested for the edgepoints
  of the polygon.
\end{enumerate}

\section{Tasks sharing and schedule}
We could have followed the schedule a lot better. Now we basically
forgot the whole schedule and did things always when we had some spare
time. And still we were late of the schedule. The good thing was that
almost always all team members were doing things at the same time and
communicating, either we were at the same place or everyone was on
IRC.

Tasks sharing worked pretty much as planned. Tero did all the network
code and everyone else did everything that had something to do with
physics and graphics. Most of our eye candy is done by Marko who was
the responsible person for graphics. Marko, Eric and Atle made
basically everything physics related. Most of the time every team
member was working together so most of the code has been written as is
as a result of a common agreement.

We feel that the workload was shared quite even. % Or does someone disagree with this?

\section{Differences to the original plan}
The original plan was quite loose and it let us make decisions during
development, which was a good thing. The basic structure of the
program is pretty much as the one we thought about while
planning. Though, many parts of the game have many levels of
abstraction (of course).

% References
\begin{thebibliography}{99}
\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}

\end{document}