\documentclass[a4papre,12pt]{article}

\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\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 & & \\
Marko Rasa & & \\
\end{tabular}}}

% The document begins
\begin{document}
\maketitle

\section{Instructions for compiling and use}
These should be pretty straightforward.
\subsection{Basic usage}
Starting. Default Keys. Starting the server. Connecting. etc.
\subsection{Configuration}
How to make configuration changes.

\section{Program architecture}
A brief description of the program architecture.

\begin{itemize}
\item Network
\item Graphics
\item Input etc.
\item Physics
\end{itemize}

\section{Data structures and algorithms}

\subsection{Basic data structures}

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

\subsection{World and Objects}

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.

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 takes care of the objects not moving inside the
terrain nor inside each other. These two types of collision are
different since the data structures are not the same. In the
terrain-object collision the collision part is rather easy. When a
object is about to move point A to point B we draw a line between
those points. Then we iterate over that line and check that none of
the vertices of the object's shape are inside the terrain. However, we
have to be able to bounce the object from the terrain and in order to
do that, a normal for the collision point needs to be calculated. For
a polygon this would easy, but for a discrete array of pixels it's
little bit different.

We come up with the following algorithm for calculating an
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 explains this a lot.

\subsection{Physics}
runge kutta, something network related?

\section{Known bugs}
A lots of them (or maybe not).

\section{Tasks sharing and schedule}
Hectic ass hell. Communication worked pretty well but we weren't as systematic
as we should have been.

\section{Differences to the original plan}
The plan was loose enough to let us make decisions during development. 

% References
\begin{thebibliography}{99}
\bibitem{foo} Foo reference
\end{thebibliography}

\end{document}