--- a/doc/kishna.tex	Mon Dec 08 18:12:43 2008 +0000
+++ b/doc/kishna.tex	Mon Dec 08 18:17:37 2008 +0000
@@ -70,8 +70,10 @@
 How to make configuration changes.
 
 \section{Program architecture}
+
+TODO: A nice image here would probably do the job.
+
 A brief description of the program architecture.
-
 \begin{itemize}
 \item Network
 \item Graphics
@@ -81,6 +83,7 @@
 
 \section{Data structures and algorithms}
 
+
 \subsection{Basic data structures}
 
 \begin{itemize}
@@ -90,21 +93,36 @@
 
 \subsection{World and Objects}
 
-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.
+% COMMENT: I think these should be in a very basic level and they
+% shouldn't discuss too much about the game itself. The idea is just
+% to explain different kinds of structures and algorithms.
 
-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.
+% Terrain
+The terrain is an important part of our game. We represent our terrain
+as a large array. Each shell of the array has a type that tells what
+is in that position. Currently, possible terrain types are EMPTY, DIRT
+and ROCK. 
+
+% 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.
+
+% Objects
+In our physics simulation the shapes of the different elements in the
+game are represented as polygons. A polygon is a vector of points that
+define the edges of the shape.
+
+% 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.
 
 \subsection{Collision Detection}
 
@@ -113,9 +131,18 @@
 \item Pixel collision detection
 \end{itemize}
 
-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
+Collision detection algorithms check if objects in the physics
+simulation are colliding with eachother. Because our terrain is
+represented as an array and objects are represented as polygons we
+have two different kinds collision detection algorithms.
+
+The pixel based collision detection used to check collisions with the
+terrain is quite simple. It ``draws'' a line between two points A and
+B. The algorithm iterates over the line from point A to B and on each
+iteration it checks if theres a collision (i.e. the type of the
+current point is ROCK or DIRT).
+
+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