Added random stuff to documentation. Time to go to sleep.
authorsaiam
Mon, 08 Dec 2008 01:31:09 +0000
changeset 278 2b856bc88e6d
parent 277 40f4a03917e2
child 279 e36f5e1a1c8d
Added random stuff to documentation. Time to go to sleep.
doc/kishna.tex
--- a/doc/kishna.tex	Mon Dec 08 01:12:00 2008 +0000
+++ b/doc/kishna.tex	Mon Dec 08 01:31:09 2008 +0000
@@ -44,23 +44,70 @@
 \section{Program architecture}
 A brief description of the program architecture.
 
+\begin{itemize}
+\item Network
+\item Graphics
+\item Input etc.
+\item Physics
+\end{itemize}
+
 \section{Data structures and algorithms}
 
+\subsection{Basic data structures}
+
+\begin{itemize}
+\item Vector
+\item List
+\end{itemize}
+
 \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.
+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.
 
-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.
+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}
 
-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.
+\begin{itemize}
+\item Polygon collision detection
+\item Pixel collision detection
+\end{itemize}
 
-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.
+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.
+
+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.
 
 \subsection{Physics}
-
-Vectors, lists, collision detection, runge kutta, something network related?
+runge kutta, something network related?
 
 \section{Known bugs}
 A lots of them (or maybe not).