1

\documentclass[a4papre,12pt]{article}

     2

     3

\usepackage[utf8]{inputenc}

     4

\usepackage[english]{babel}

     5

\usepackage{listings} % For listing code

     6

     7

% Fancy headers

     8

\usepackage{fancyhdr}

     9

\fancypagestyle{plain} {

    10

    \fancyhf{}

    11

    \renewcommand{\headrulewidth}{0.4pt}

    12

    \lhead{\textbf{Group 66}}

    13

    \chead{\textbf{Kishna Glista - liero clone}}

    14

    \rhead{\textsl{AS-0.1102}}

    15

    \cfoot{\thepage}

    16

}

    17

\pagestyle{plain}

    18

    19

% Paragraph formatting

    20

\frenchspacing

    21

\setlength{\parindent}{0pt} 

    22

\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}

    23

    24

% Title information

    25

\title{Kishna Glista - Liero Clone}

    26

\author{\normalsize{\begin{tabular}{lll}

    27

Atle Kivelä & 79171V & atle.kivela@tkk.fi \\

    28

Eric Malmi & 80351A & eric.malmi@tkk.fi \\

    29

Tero Marttila & & \\

    30

Marko Rasa & & \\

    31

\end{tabular}}}

    32

    33

% The document begins

    34

\begin{document}

    35

\maketitle

    36

    37

\section{Instructions for compiling and use}

    38

These should be pretty straightforward.

    39

\subsection{Basic usage}

    40

Starting. Default Keys. Starting the server. Connecting. etc.

    41

\subsection{Configuration}

    42

How to make configuration changes.

    43

    44

\section{Program architecture}

    45

A brief description of the program architecture.

    46

    47

\section{Data structures and algorithms}

    48

    49

\subsection{World and Objects}

    50

    51

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.

    52

    53

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.

    54

    55

\subsection{Collision Detection}

    56

    57

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.

    58

    59

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.

    60

    61

\subsection{Physics}

    62

    63

Vectors, lists, collision detection, runge kutta, something network related?

    64

    65

\section{Known bugs}

    66

A lots of them (or maybe not).

    67

    68

\section{Tasks sharing and schedule}

    69

Hectic ass hell. Communication worked pretty well but we weren't as systematic

    70

as we should have been.

    71

    72

\section{Differences to the original plan}

    73

The plan was loose enough to let us make decisions during development. 

    74

    75

% References

    76

\begin{thebibliography}{99}

    77

\bibitem{foo} Foo reference

    78

\end{thebibliography}

    79

    80

\end{document}