47

\begin{itemize}

    48

\item Network

    49

\item Graphics

    50

\item Input etc.

    51

\item Physics

    52

\end{itemize}

    53

    56

\subsection{Basic data structures}

    57

    58

\begin{itemize}

    59

\item Vector

    60

\item List

    61

\end{itemize}

    62

    65

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

    66

polygon. This allows us to implement collision detection and bouncing

    67

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

    68

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

    69

game and therefore we represent the terrain as a large array of

    70

pixels. These pixels are, however, abstract pixels, i.e. they are not

    71

necessarily in the same scale than the physical resolution. In other

    72

words, the server has an abstract resolution, which is the same for

    73

all clients, and the clients can visualize this abstract array of

    74

pixels in any resolution they wish.

    76

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

    77

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

    78

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

    79

the terrain and the objects with each other.

    83

\begin{itemize}

    84

\item Polygon collision detection

    85

\item Pixel collision detection

    86

\end{itemize}

    88

Collision detection takes care of the objects not moving inside the

    89

terrain nor inside each other. These two types of collision are

    90

different since the data structures are not the same. In the

    91

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

    92

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

    93

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

    94

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

    95

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

    96

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

    97

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

    98

little bit different.

    99

   100

We come up with the following algorithm for calculating an

   101

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

   102

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

   103

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

   104

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

   105

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

   106

vectors. The resulting vector will point approximately along the

   107

normal. Picture explains this a lot.

   110

runge kutta, something network related?