Changeset 135

Show
Ignore:
Timestamp:
04/23/2012 04:52:50 PM (2 years ago)
Author:
acarter
Message:

Added brief overiew document

Location:
LaTeX
Files:
1 added
1 modified

Legend:

Unmodified
Added
Removed
  • LaTeX/CodeDocumentation.tex

    r134 r135  
    3737 
    3838\section{Major Classes and their functions} 
     39To make game design easier, we have designed the code to do a lot of work behind the scenes. 
     40    Thus some classes automatically drive a lot of the game logic. 
     41    Therefore when we are making mini-games we can think about the mini-games and not worry about the game logic. 
     42 
     43The downside of this is that the uninitiated may be surprised by some events. 
     44    Thus we recommend getting a good grasp on the overall control flow, 
     45        and to look over current mini-games to get a feel for how they should be implemented. 
     46 
    3947\subsection{GameDriver} 
     48This classes handles the control logic for the game. 
     49    If programmers wish to add sequences, or change the actions for moving between windows such as 3D world to anywhere, 
     50        or in and out of mini-games, this would be the class to change. 
     51    We recommend no matter the edit of getting a good feel for how this class runs. 
    4052\subsection{GameObject} 
     53This class is the super class of all game objects. 
     54    It handles a lot of the behind the scene code that makes actual game objects so easy to handle. 
     55    We highly recommend reading through this class before making any changes to any code. 
     56\subsection{Minigame} 
     57This class is the superclass of all mini-games. 
     58    Some behind the scenes magic occurs 
     59 
     60\section{Programming Mini-games} 
     61We recommend to think of the mini-games from the programmer end as a Finite State Machine. 
     62    More importantly its important to realize that even if the screen gets update a few panels later its still going to be under a tenth of a second. 
     63    Currently children update after their parents, 
     64        we have thought about having a pre-update and a post-update, 
     65            but this means that children cannot count on their parent's being updated before they are updated. 
     66    Thus if the parent requires the child to have been updated, 
     67        we recommend instead of trying to work around it, to just wait until the next update step to do the update of the parent. 
     68    We mention this, only because it seems to be a recurring theme among other groups of having awkward logic to support 
     69        instantaneous updating.      
     70 
    4171\end{document}