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

    39

You can compile the program by going trough the following procedure:

    40

\begin{itemize}

    41

\item \textsl{cd build}

    42

\item \textsl{./mkcmake.sh}

    43

\item \textsl{make install}

    44

\end{itemize}

    45

    46

\subsection{Basic usage}

    47

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

    48

    49

Controls are currently liero default controls.

    50

\begin{center}

    51

\begin{tabular}{l|l}

    52

\textbf{Action} & \textbf{Default key(s)} \\

    53

\hline

    54

Move left & Arrow left \\

    55

Move right & Arrow right \\

    56

Aim up & Arrow up \\

    57

Aim down & Arror down \\

    58

Shoot & Right CTRL \\

    59

Jump & Right shift \\

    60

Change weapon & Enter \\

    61

Shoot rope & Change weapon + jump \\

    62

Change rope length & Change weapon + aim up/down \\

    63

\end{tabular}

    64

\end{center}

    65

    66

\subsubsection*{Starting the game}

    67

Somekind of intstuctions on starting the server, connecting etc...

    68

    69

\subsection{Configuration}

    70

How to make configuration changes.

    71

    72

\section{Program architecture}

    73

    74

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

    75

    76

A brief description of the program architecture.

    77

\begin{itemize}

    78

\item Network

    79

\item Graphics

    80

\item Input etc.

    81

\item Physics

    82

\end{itemize}

    83

    84

\section{Data structures and algorithms}

    85

    86

    87

\subsection{Basic data structures}

    88

    89

\begin{itemize}

    90

\item Vector

    91

\item List

    92

\end{itemize}

    93

    94

\subsection{World and Objects}

    95

    96

% COMMENT: I think these should be in a very basic level and they

    97

% shouldn't discuss too much about the game itself. The idea is just

    98

% to explain different kinds of structures and algorithms.

    99

   100

% Terrain

   101

The terrain is an important part of our game. We represent our terrain

   102

as a large array. Each shell of the array has a type that tells what

   103

is in that position. Currently, possible terrain types are EMPTY, DIRT

   104

and ROCK. 

   105

   106

% Usually, in side view 2D-games, the terrain is representated as a

   107

% polygon. This allows us to implement collision detection and

   108

% bouncing rather easily, and it is also a very compact way of storing

   109

% the map. In our opinion Liero, however, is fundamentally a pixel

   110

% based game and therefore we represent the terrain as a large array

   111

% of pixels. These pixels are, however, abstract pixels, i.e. they are

   112

% not necessarily in the same scale than the physical resolution. In

   113

% other words, the server has an abstract resolution, which is the

   114

% same for all clients, and the clients can visualize this abstract

   115

% array of pixels in any resolution they wish.

   116

   117

% Objects

   118

In our physics simulation the shapes of the different elements in the

   119

game are represented as polygons. A polygon is a vector of points that

   120

define the edges of the shape.

   121

   122

% On top of the terrain, the world also includes a list of all objects

   123

% in it (players, projectiles and ropes). The objects have a polygon

   124

% shape which is used in the collision detection between the objects

   125

% and the terrain and the objects with each other.

   126

   127

\subsection{Collision Detection}

   128

   129

\begin{itemize}

   130

\item Polygon collision detection

   131

\item Pixel collision detection

   132

\end{itemize}

   133

   134

Collision detection algorithms check if objects in the physics

   135

simulation are colliding with eachother. Because our terrain is

   136

represented as an array and objects are represented as polygons we

   137

have two different kinds collision detection algorithms.

   138

   139

The pixel based collision detection used to check collisions with the

   140

terrain is quite simple. It ``draws'' a line between two points A and

   141

B. The algorithm iterates over the line from point A to B and on each

   142

iteration it checks if theres a collision (i.e. the type of the

   143

current point is ROCK or DIRT).

   144

   145

In the

   146

terrain-object collision the collision part is rather easy. When a

   147

object is about to move point A to point B we draw a line between

   148

those points. Then we iterate over that line and check that none of

   149

the vertices of the object's shape are inside the terrain. However, we

   150

have to be able to bounce the object from the terrain and in order to

   151

do that, a normal for the collision point needs to be calculated. For

   152

a polygon this would easy, but for a discrete array of pixels it's

   153

little bit different.

   154

   155

We come up with the following algorithm for calculating an

   156

approximation for the normal. Take the collision point and the point

   157

before the collision and consider a 3x3 array of pixels which has the

   158

collision point in the middle of it. Then, do sort of an bredth-first

   159

search from the previous point to get all the empty pixels. Take the

   160

vectors from the collision point to the empty point and sum these

   161

vectors. The resulting vector will point approximately along the

   162

normal. Picture explains this a lot.

   163

   164

\subsection{Physics}

   175

   176

\section{Known bugs}

   177

A lots of them (or maybe not).

   178

   179

\section{Tasks sharing and schedule}

   180

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

   181

as we should have been.

   182

   183

\section{Differences to the original plan}

   184

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

   185

   186

% References

   187

\begin{thebibliography}{99}

   191

\end{thebibliography}

   192

   193

\end{document}