saiam@238: \documentclass[a4papre,12pt]{article}
saiam@238: 
saiam@238: \usepackage[utf8]{inputenc}
saiam@238: \usepackage[english]{babel}
saiam@238: \usepackage{listings} % For listing code
saiam@238: 
saiam@238: % Fancy headers
saiam@238: \usepackage{fancyhdr}
saiam@238: \fancypagestyle{plain} {
saiam@238:     \fancyhf{}
saiam@238:     \renewcommand{\headrulewidth}{0.4pt}
saiam@238:     \lhead{\textbf{Group 66}}
saiam@238:     \chead{\textbf{Kishna Glista - liero clone}}
saiam@238:     \rhead{\textsl{AS-0.1102}}
saiam@238:     \cfoot{\thepage}
saiam@238: }
saiam@238: \pagestyle{plain}
saiam@238: 
saiam@238: % Paragraph formatting
saiam@238: \frenchspacing
saiam@238: \setlength{\parindent}{0pt} 
saiam@238: \setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}
saiam@238: 
saiam@238: % Title information
saiam@238: \title{Kishna Glista - Liero Clone}
saiam@238: \author{\normalsize{\begin{tabular}{lll}
saiam@238: Atle Kivelä & 79171V & atle.kivela@tkk.fi \\
ekku@269: Eric Malmi & 80351A & eric.malmi@tkk.fi \\
saiam@238: Tero Marttila & & \\
saiam@238: Marko Rasa & & \\
saiam@238: \end{tabular}}}
saiam@238: 
saiam@238: % The document begins
saiam@238: \begin{document}
saiam@238: \maketitle
saiam@238: 
saiam@238: \section{Instructions for compiling and use}
saiam@293: 
saiam@293: You can compile the program by going trough the following procedure:
saiam@293: \begin{itemize}
saiam@293: \item \textsl{cd build}
saiam@293: \item \textsl{./mkcmake.sh}
saiam@293: \item \textsl{make install}
saiam@293: \end{itemize}
saiam@293: 
saiam@238: \subsection{Basic usage}
saiam@238: Starting. Default Keys. Starting the server. Connecting. etc.
saiam@293: 
saiam@293: Controls are currently liero default controls.
saiam@293: \begin{center}
saiam@293: \begin{tabular}{l|l}
saiam@293: \textbf{Action} & \textbf{Default key(s)} \\
saiam@293: \hline
saiam@293: Move left & Arrow left \\
saiam@293: Move right & Arrow right \\
saiam@293: Aim up & Arrow up \\
saiam@293: Aim down & Arror down \\
saiam@293: Shoot & Right CTRL \\
saiam@293: Jump & Right shift \\
saiam@293: Change weapon & Enter \\
saiam@293: Shoot rope & Change weapon + jump \\
saiam@293: Change rope length & Change weapon + aim up/down \\
saiam@293: \end{tabular}
saiam@293: \end{center}
saiam@293: 
saiam@293: \subsubsection*{Starting the game}
saiam@293: Somekind of intstuctions on starting the server, connecting etc...
saiam@293: 
saiam@238: \subsection{Configuration}
saiam@238: How to make configuration changes.
saiam@238: 
saiam@238: \section{Program architecture}
saiam@301: 
saiam@301: TODO: A nice image here would probably do the job.
saiam@301: 
saiam@238: A brief description of the program architecture.
saiam@278: \begin{itemize}
saiam@278: \item Network
saiam@278: \item Graphics
saiam@278: \item Input etc.
saiam@278: \item Physics
saiam@278: \end{itemize}
saiam@278: 
saiam@238: \section{Data structures and algorithms}
ekku@269: 
saiam@301: 
saiam@278: \subsection{Basic data structures}
saiam@278: 
saiam@278: \begin{itemize}
saiam@278: \item Vector
saiam@278: \item List
saiam@278: \end{itemize}
saiam@278: 
ekku@269: \subsection{World and Objects}
ekku@269: 
saiam@301: % COMMENT: I think these should be in a very basic level and they
saiam@301: % shouldn't discuss too much about the game itself. The idea is just
saiam@301: % to explain different kinds of structures and algorithms.
ekku@269: 
saiam@301: % Terrain
saiam@301: The terrain is an important part of our game. We represent our terrain
saiam@301: as a large array. Each shell of the array has a type that tells what
saiam@301: is in that position. Currently, possible terrain types are EMPTY, DIRT
saiam@301: and ROCK. 
saiam@301: 
saiam@301: % Usually, in side view 2D-games, the terrain is representated as a
saiam@301: % polygon. This allows us to implement collision detection and
saiam@301: % bouncing rather easily, and it is also a very compact way of storing
saiam@301: % the map. In our opinion Liero, however, is fundamentally a pixel
saiam@301: % based game and therefore we represent the terrain as a large array
saiam@301: % of pixels. These pixels are, however, abstract pixels, i.e. they are
saiam@301: % not necessarily in the same scale than the physical resolution. In
saiam@301: % other words, the server has an abstract resolution, which is the
saiam@301: % same for all clients, and the clients can visualize this abstract
saiam@301: % array of pixels in any resolution they wish.
saiam@301: 
saiam@301: % Objects
saiam@301: In our physics simulation the shapes of the different elements in the
saiam@301: game are represented as polygons. A polygon is a vector of points that
saiam@301: define the edges of the shape.
saiam@301: 
saiam@301: % On top of the terrain, the world also includes a list of all objects
saiam@301: % in it (players, projectiles and ropes). The objects have a polygon
saiam@301: % shape which is used in the collision detection between the objects
saiam@301: % and the terrain and the objects with each other.
ekku@269: 
ekku@269: \subsection{Collision Detection}
ekku@269: 
saiam@278: \begin{itemize}
saiam@278: \item Polygon collision detection
saiam@278: \item Pixel collision detection
saiam@278: \end{itemize}
ekku@269: 
saiam@301: Collision detection algorithms check if objects in the physics
saiam@301: simulation are colliding with eachother. Because our terrain is
saiam@301: represented as an array and objects are represented as polygons we
saiam@301: have two different kinds collision detection algorithms.
saiam@301: 
saiam@301: The pixel based collision detection used to check collisions with the
saiam@301: terrain is quite simple. It ``draws'' a line between two points A and
saiam@301: B. The algorithm iterates over the line from point A to B and on each
saiam@301: iteration it checks if theres a collision (i.e. the type of the
saiam@301: current point is ROCK or DIRT).
saiam@301: 
saiam@301: In the
saiam@278: terrain-object collision the collision part is rather easy. When a
saiam@278: object is about to move point A to point B we draw a line between
saiam@278: those points. Then we iterate over that line and check that none of
saiam@278: the vertices of the object's shape are inside the terrain. However, we
saiam@278: have to be able to bounce the object from the terrain and in order to
saiam@278: do that, a normal for the collision point needs to be calculated. For
saiam@278: a polygon this would easy, but for a discrete array of pixels it's
saiam@278: little bit different.
saiam@278: 
saiam@278: We come up with the following algorithm for calculating an
saiam@278: approximation for the normal. Take the collision point and the point
saiam@278: before the collision and consider a 3x3 array of pixels which has the
saiam@278: collision point in the middle of it. Then, do sort of an bredth-first
saiam@278: search from the previous point to get all the empty pixels. Take the
saiam@278: vectors from the collision point to the empty point and sum these
saiam@278: vectors. The resulting vector will point approximately along the
saiam@278: normal. Picture explains this a lot.
ekku@269: 
ekku@269: \subsection{Physics}
saiam@310: 
saiam@310: The fourth-order Runge-Kutta method is a numerical method for
saiam@310: approximating the solution of an ordinary differential equation. In
saiam@310: our game the Runge-Kutta method is used to calculate positions and
saiam@310: velocities of physics objects when we apply forces to them.
saiam@310: 
saiam@310: % TODO: Here we could write the runge kutta method mathematically
saiam@310: % (copy paste from wikipedia or something)
saiam@310: 
saiam@310: something network related?
saiam@238: 
saiam@238: \section{Known bugs}
saiam@238: A lots of them (or maybe not).
saiam@238: 
saiam@238: \section{Tasks sharing and schedule}
saiam@238: Hectic ass hell. Communication worked pretty well but we weren't as systematic
saiam@238: as we should have been.
saiam@238: 
saiam@238: \section{Differences to the original plan}
saiam@238: The plan was loose enough to let us make decisions during development. 
saiam@238: 
saiam@238: % References
saiam@238: \begin{thebibliography}{99}
saiam@310: \bibitem{gaffer} Gaffer on games. Game
saiam@310:   Physics. 2006. http://gafferongames.wordpress.com/game-physics/
saiam@310:   (read: 2008-12-08)
saiam@238: \end{thebibliography}
saiam@238: 
saiam@238: \end{document}