1

\documentclass[a4paper,12pt]{article}

     2

     3

\usepackage[utf8]{inputenc}

     4

\usepackage[english]{babel}

     5

\usepackage{amsmath}

     6

\usepackage{listings} % For listing code

     7

     8

% Fancy headers

     9

\usepackage{fancyhdr}

    10

\fancypagestyle{plain} {

    11

    \fancyhf{}

    12

    \renewcommand{\headrulewidth}{0.4pt}

    13

    \lhead{\textbf{Group 66}}

    14

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

    15

    \rhead{\textsl{AS-0.1102}}

    16

    \cfoot{\thepage}

    17

}

    18

\pagestyle{plain}

    19

    20

% Paragraph formatting

    21

\frenchspacing

    22

\setlength{\parindent}{0pt} 

    23

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

    24

    25

% Title information

    26

\title{Kishna Glista - Liero Clone}

    27

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

    28

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

    29

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

    30

Tero Marttila & 79849E & tjmartti@cc.hut.fi \\

    31

Marko Rasa & 78726L & morasa@cc.hut.fi \\

    32

\end{tabular}}}

    33

    34

% The document begins

    35

\begin{document}

    36

\maketitle

    37

    38

\section{Instructions for compiling and use}

    39

    40

\subsection{Configuring CMake}

    41

You must first generate the project's CMake configuration inside of \textsl{build}. A simple script is provided to do

    42

so with some default settings. It will configure the install path as \textsl{~/opt}.

    43

    44

\begin{itemize}

    45

\item \textsl{cd build}

    46

\item \textsl{./mkcmake.sh}

    47

\end{itemize}

    48

    49

\subsection{Compiling and Installing}

    50

Once you have the CMake scripts in place, compiling should be as simple as running make:

    51

\begin{itemize}

    52

\item \textsl{make}

    53

\item \textsl{make install}

    54

\end{itemize}

    55

    56

This will build the binary, and then copy the binary and data files to the install path configured above.

    57

    58

\subsection{Command-line Arguments}

    59

Running the game is done using command-line arguments to the executable

    60

\begin{center}

    61

\begin{tabular}{l|l|l|l|l}

    62

\textbf{Short} & \textbf{Long} & \textbf{Value} & \textbf{Description} & \textbf{Default} \\

    63

\hline

    64

-p & \verb|--port| & PORT & Set server TCP/UDP port & 9338 \\

    65

-s & \verb|--server| &  & Run as a network server & false \\

    66

-c & \verb|--client| & SERVERHOST & Run as a network client on given server & false \\

    67

-g & \verb|--graphics| & & Enable graphics rendering & * \\

    68

\end{tabular}

    69

\end{center}

    70

    71

* = true, except false when --server is given

    72

    73

The options \verb|--server| and \verb|--client| are mutually exclusive, and both cannot be selected at the same time.

    74

    75

\subsection{Keyboard Controls}

    76

The default controls are identical to the origional Liero default controls, with some additions.

    77

    78

\begin{center}

    79

\begin{tabular}{l|l}

    80

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

    81

\hline

    82

Move Left & Arrow Left \\

    83

Move Right & Arrow Right \\

    84

Aim Up & Arrow Up \\

    85

Aim Down & Arror Down \\

    86

Dig & Move Left + Move Right \\

    87

Shoot & Right Control \\

    88

Jump & Right Shift \\

    89

Change Weapon & Enter + Arrow Left / Arrow Right \\

    90

Throw Rope & Change Weapon + Jump \\

    91

Release Rope & Jump \\

    92

Change Rope Length & Change Weapon + Aim Up / Aim Down \\

    93

Suicide & Left Control + K \\

    94

Exit Game & Esc \\

    95

\end{tabular}

    96

\end{center}

    97

    98

\subsection{Running the game}

    99

To simple start a local singleplayer game, just run \verb|kg| without any arguments.

   100

   101

To start a network server on the default port, run \verb|kg --server|

   102

(\verb|kg -s|). You may optionally also specify the \verb|--graphics|

   103

argument to have the server passively draw the graphics.

   104

   105

To start a network client, connecting to a server running on the

   106

default port, run \verb|kg --client=ADDRESS| (\verb|kg -c <address>|).

   107

   108

To use a non-default port, simply specify \verb|--port=PORT|

   109

(\verb|-p <port>|) on both client and server.

   110

   111

\subsection{Configuration}

   112

All global game constants are defined in \textit{src/Config.hh}, and may be

   113

experimented with. Weapon parameters are defined in \textit{src/Weapons.cc}.

   114

   115

\section{Program architecture}

   119

   123

   128

   133

   143

NetworkAddress and NetworkSocket are ClanLib's Socket/IPAddress

   144

types. NetworkPackets provide a mechanism to read/write values from/to

   145

a byte buffer, and NetworkBuffer is used for buffering socket I/O.

   146

   147

NetworkUDP is an UDP socket. NetworkTCPServer is a listen() socket,

   148

which spawns NetworkTCPTransports when clients

   149

connect. NetworkTCPClient is itself a NetworkTCPTransport with a

   150

connect()'d socket.

   151

   152

NetworkSession can have a NetworkTCPServer socket, and both client and

   153

server NetworkUDP sockets. Connected clients are represented as

   154

NetworkNodes.

   155

   156

NetworkObjectControllers can be attached to a NetworkSession on a

   157

specific NetworkChannelID, and they then manage instances of

   158

NetworkObjects, which have NetworkObjectIDs that can be sent across

   159

the network. NetworkObjects can be used to send messages with a

   160

specific NetworkMessageID.

   161

   162

NetworkServer then has a NetworkSession and

   163

NetworkObject\_ServerController, and then creates NetworkServerPlayer

   164

and NetworkServerProjectile objects (that are

   165

NetworkObject\_Server's).

   166

   167

NetworkClient then has a NetworkSession and a specialized

   168

NetworkClientController (NetworkObject\_ClientController) that creates

   169

NetworkClientLocalPlayer/NetworkClientRemotePlayer/NetworkClientProjectile

   170

objects when they are received from the server.

   171

   172

   173

TODO: Replace the above with some nice diagram, and make the text more

   174

brief

   175

   176

\section{Data structures and algorithms}

   177

   178

   179

\subsection{Basic data structures}

   180

   181

\begin{itemize}

   182

\item Vector

   183

\item List

   184

\end{itemize}

   185

   186

\subsection{World and Objects}

   187

   188

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

   189

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

   190

% to explain different kinds of structures and algorithms.

   191

   192

% Terrain

   193

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

   194

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

   195

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

   196

and ROCK. 

   197

   198

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

   199

% polygon. This allows us to implement collision detection and

   200

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

   201

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

   202

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

   203

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

   204

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

   205

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

   206

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

   207

% array of pixels in any resolution they wish.

   208

   209

% Objects

   210

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

   211

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

   212

define the edges of the shape.

   213

   214

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

   215

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

   216

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

   217

% and the terrain and the objects with each other.

   218

   219

\subsection{Collision Detection}

   220

   221

\begin{itemize}

   222

\item Polygon collision detection

   223

\item Pixel collision detection

   224

\end{itemize}

   225

   226

Collision detection algorithms check if objects in the physics

   227

simulation are colliding with eachother. Because our terrain is

   228

represented as an array and objects are represented as polygons we

   229

have two different kinds collision detection algorithms.

   230

   231

The pixel based collision detection used to check collisions with the

   232

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

   233

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

   234

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

   235

current point is ROCK or DIRT).

   236

   237

In order to implement bouncing from the terrain we have to have a way

   238

of calculating a normal for the slope of the terrain in the collision

   239

point. We came up with the following algorithm for calculating the

   240

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

   241

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

   242

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

   243

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

   244

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

   245

vectors. The resulting vector will point approximately along the

   246

normal. % Picture would explain this a lot. 

   247

   248

\subsection{Physics}

   249

   250

The fourth-order Runge-Kutta method is a numerical method for

   251

approximating the solution of an ordinary differential equation. In

   252

our game the Runge-Kutta method is used to calculate positions and

   253

velocities of physics objects when we apply forces to them.

   254

   255

The mathematical formulation of the Runge-Kutta method:

   256

If we have an initial value problem of the form

   257

\begin{equation*}

   258

y' = f(t, y), \quad y(t_0) = y_0.

   259

\end{equation*}

   260

The we can describe the RK4 method for this problem by equations

   261

\begin{align*}

   262

y_{n+1} &= y_n + \tfrac{1}{6}h\left(k_1 + 2k_2 + 2k_3 + k_4 \right) \\

   263

t_{n+1} &= t_n + h \\

   264

\end{align*}

   265

where $y_{n+1}$ is the RK4 approximation of $y(t_{n+1})$, and

   266

\begin{align*}

   267

k_1 &= f(t_n, y_n) \\

   268

k_2 &= f(t_n + \tfrac{1}{2}h, y_n + \tfrac{1}{2}h k_1) \\

   269

k_3 &= f(t_n + \tfrac{1}{2}h, y_n + \tfrac{1}{2}h k_2) \\

   270

k_4 &= f(t_n + h, y_n + h k_3) \\

   271

\end{align*}

   272

The next value $(y_n+1)$ is determined by the present value $(y_n)$,

   273

the product of the interval $(h)$ and an estimated slope that is

   274

defined as $\frac{1}{6}h\left(k_1+2k_2+2k_3+k_4\right)$.

   275

   276

% TODO: something network related?

   277

   278

\section{Known bugs}

   279

\begin{enumerate}

   280

\item If player dies while rope is attached the rope will still be

   281

  attached when the player spawns.

   282

\item If rope is thrown without releasing it first, rope will pull worm

   283

  when midair

   284

\item Collisions with the terrain are only tested for the edgepoints

   285

  of the polygon.

   286

\end{enumerate}

   287

   288

\section{Tasks sharing and schedule}

   289

We could have followed the schedule a lot better. Now we basically

   290

forgot the whole schedule and did things always when we had some spare

   291

time. And still we were late of the schedule. The good thing was that

   292

almost always all team members were doing things at the same time and

   293

communicating, either we were at the same place or everyone was on

   294

IRC.

   295

   296

Tasks sharing worked pretty much as planned. Tero did all the network

   297

code and everyone else did everything that had something to do with

   298

physics and graphics. Most of our eye candy is done by Marko who was

   299

the responsible person for graphics. Marko, Eric and Atle made

   300

basically everything physics related. Most of the time every team

   301

member was working together so most of the code has been written as is

   302

as a result of a common agreement.

   303

   304

We feel that the workload was shared quite even. % Or does someone disagree with this?

   305

   306

\section{Differences to the original plan}

   307

The original plan was quite loose and it let us make decisions during

   308

development, which was a good thing. The basic structure of the

   309

program is pretty much as the one we thought about while

   310

planning. Though, many parts of the game have many levels of

   311

abstraction (of course).

   312

   313

% References

   314

\begin{thebibliography}{99}

   315

\bibitem{gaffer} Gaffer on games. Game

   316

  Physics. 2006. http://gafferongames.wordpress.com/game-physics/

   317

  (read: 2008-12-08)

   318

\bibitem{fractal} Terrain texture generation.  http://www.gameprogrammer.com/fractal.html

   319

\end{thebibliography}

   320

   321

\end{document}