doc/kishna.tex
author nireco
Mon, 08 Dec 2008 21:49:54 +0000
changeset 315 fe9da2d5355e
parent 310 7e0cfc5f0944
child 323 a17043af6995
permissions -rw-r--r--
better colors on downbar
\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}

You can compile the program by going trough the following procedure:
\begin{itemize}
\item \textsl{cd build}
\item \textsl{./mkcmake.sh}
\item \textsl{make install}
\end{itemize}

\subsection{Basic usage}
Starting. Default Keys. Starting the server. Connecting. etc.

Controls are currently liero default controls.
\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 \\
Shoot & Right CTRL \\
Jump & Right shift \\
Change weapon & Enter \\
Shoot rope & Change weapon + jump \\
Change rope length & Change weapon + aim up/down \\
\end{tabular}
\end{center}

\subsubsection*{Starting the game}
Somekind of intstuctions on starting the server, connecting etc...

\subsection{Configuration}
How to make configuration changes.

\section{Program architecture}

TODO: A nice image here would probably do the job.

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}

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

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.

% TODO: Here we could write the runge kutta method mathematically
% (copy paste from wikipedia or something)

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{gaffer} Gaffer on games. Game
  Physics. 2006. http://gafferongames.wordpress.com/game-physics/
  (read: 2008-12-08)
\end{thebibliography}

\end{document}