martin/fysxasteroids
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

initial commit

Browse Source
This commit is contained in:
martin
2010-04-05 23:38:59 +02:00
commit e7e0b39e82
150 changed files with 28636 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
engine/doc/Mainpage.h
+96
View File
@@ -0,0 +1,96 @@
/** \file documentation.h \mainpage Main Page
*
* This is the documentation of Engine -- a game engine without a name.
*
* \section General Information
*
* To get an overview over the most important functions and classes have a
* look at Engine. For the structure of the Engine look at Engine::Engine. In
* \ref usecases you find documentation on how things are supposed to work and
* what the ideas behind certain designs is.
*
* \section Physics
*
* So far we only use a very simple physics system which is mostly defined by
* the Engine::Physics class. It uses the coll2d collision library. Collision
* response so far only tries to prevent interpenetration.
*
* \section Networking
*
* For easier networking it is assumed that everything runs over a network.
* The game itself is rather a smart client to a simple synchronization
* protocol. What is being synchronized is the game state and the client
* simply displays the current state it knows. The client is "smart" as it
* tries to guess what the next state will be.
*
* For networking we want to use Enet http://enet.bespin.org/.
*
* Notes for networking: At
* http://www.gamedev.net/community/forums/topic.asp?topic_id=550962 is an
* interesting thread about modeling the updates. Especially the answer of
* Antheus at http://www.gamedev.net/community/forums/viewreply.asp?ID=3546077
* describes two fundamental models:
*
* Level Triggering (GoF Observer Pattern): Entity A sends its changes to the
* Observer pattern and all objects that are interested in the state of Entity
* A get notfied by the observer.
*
* Edge Triggering: For each Entity A the Observer B is interested, it stores
* a flag for a value it is interested in (e.g. one for position, one for
* velocity, etc.). When Entity A modifies one of the values it notifies the
* observer that its current state has changed and the Observer sets the flag
* to "dirty". Anyone interested in events polls at the Observer and decides
* what to do with it. When the value is queried, the Observer reads the value
* from the Entity and clears the flag.
*
* For networking a combination can be used: During the simulation loop only
* Edge Triggering is performed and at the end of it, all dirty States get
* sent over the network.
*
* When notifying events such as "Add new Entity X" the user tomv describes at
* http://www.gamedev.net/community/forums/viewreply.asp?ID=3545586 a method
* to circumvent these messages. Instead, the server simply sends out updates
* about the Entities around a player where close Entities are updated more
* frequently than ones that are further away. It simply sends "Entity X
* changed by D". If a client does not know what the Entity X is, it queries
* the type and current state of the Entity X and therefore reconstructs the
* surroundings step-by-step. It is also robust against dropped messages of
* the form "Add new Entity X".
*
* At tomvas model there are some problems: How are events "Delete Entity X"
* handled? How to handle malicious clients that request the state of all
* Entities? (Solution for the last question: Request Queues).
*
* Kylotan cals tomvas model as a unreliable system for generic state
* [synchronization?] (http://www.gamedev.net/community/forums/viewreply.asp?ID=3548662).
* Additionally he mentions that it can increase occurences of short term
* unsynchronous states and reccomends using some reliable message passing.
*
* \section ToDos
*
* This is a loose list of items that are to be implemented. For a list of all
* todos within the code have a look at the \ref todo.
*
* \todo [high] Create a simple racing or asteroids game
* \todo [med] Clear all references of EntityVisualState and EntityGameState
* \todo [med] Clarify functionalities of CreateEntity, KillEntity, RegisterEntity, UnregisterEntity (which frees memory, which does only change the state of the Model?)
* \todo [med] Add basic networking
* \todo [med] Add serialization
* \todo [med] Add cal3d support
* \todo [med] Smooth Physics at convex collisions (somehow there is jitter)
* \todo [med] Create better collsion response
* \todo [med] In rare cases two Actors can penetrate each other (probably at slow velocities)
* \todo [low] Add a timer object to keep track of what is sucking performance.
* \todo [low] Add a inspector widget that shows information about a selected Entity
* \todo [low] Use a std::map<string, string> as initialization parameters for
* Engine::Module::Init()
*
* Done:
* - [high] In Physics remove dependancy on the Model to pass on collision
* events
* - [high] Fix Physics bug when two actors collide actively (i.e. velocity
* towards each other)
* - [med] Better Game Input so that each Entity has its own ControllerState
* that can be modified
* - [med] (31-01-2009) Add support for loading levels (and saving!)
*/
engine/doc/Usecases.h
+114
View File
@@ -0,0 +1,114 @@
/** \page usecases Usecases
*
* This page contains some information on how various tasks are supposed to be
* performed with this engine. It should help understand how the internals
* work and how to avoid certain pitfalls.
*
* \section entity_management Entity Management
*
* Entities have to be created with Engine::CreateEntity() Factory Method.
* This will also cause the correct registration in all modules (especially in
* the Engine::Physics module). And create the registrations for it.
*
* Once an Entity is no more used, one has to call Engine::DestroyEntity().
*
* \section entitiy_drawing Drawing of an Entity
*
* Aim: The visual state must always represent the visual state of the game
* state.
*
* To do this we always have to update the visual entity from the game state
* entity.
*
* \code
* View::DrawEntity (Entity* entity) {
* // if this entity has no visual part we don't need to draw
* if (! entity->mPhysicState) return;
*
* // update entity->mVisualState based on entity->mGameState
*
* // perform positioning based on entity->mPhysicState
*
* // perform drawing based on entity->mVisualState
* }
* \endcode
*
* \section game_input Game Input
*
* Each Entity has a ControllerState which keeps track on how the Entity is
* currently steered. This is then processed by the model each frame for each
* entity and updates the velocities / orientations etc. before the physical
* simulation is started. The player input simply forwards its input to the
* Entity with the Player Id and updates the ControllerState of the Entity
* with the Id.
*
* To add a new key state one has to follow these steps:
* - add a new EntityControllerKeyState e.g. EntityKeyStateCrouch (must be added
* above EntityKeyStateLast)
* - define the behaviour of the control in Entity::ProcessController() which
* updates the EntityPhysicalState of the Entity
* - add a command to be able to bind a key to the EntityControllerKeyState
*
* \section console_input Console Input
*
* Since it could be that the key being pressed has to be forwarded to another
* system such as the Menu or the Engine::Console system, we have to query the
* Engine::Model whether it is active and forward the input if it is the case.
* Otherwise we just execute the binding for the key (if it exists).
*
* \code
* Controller::OnKeyDown (SDLKey key) {
* if (mConsole->GetActive ())
* mConsole->OnKeyDown (key);
*
* if (mBinding[key].size())
* mCommands->QueueCommand (mBinding[key]);
* }
* \endcode
*
* \section addcommand Adding a Command to the Command System
*
* For the various Modules such as Engine::Controller, Engine::View, etc.
* separate files exist in which commands are defined. The filename pattern is
* usually [ModuleName]Commands.cc and contains the function
* \code void ModuleName::OnRegisterCommands () \endcode which is run during the
* initialization phase of the Engine in Engine::OnInit.
*
* Commands themselves have the signature:
* \code bool Cmd_CrazyCommand (std::vector<std::string> args) \endcode
* and return true on success and error if some error has happened. The
* prefix \e Cmd_ is not mandatory but keeps things clear.
*
* Please make sure to call Engine::CommandSetErrorString in such a case. The
* message itself will be automatically reported to the Engine::Logging system
* as a warning since Command errors are hopefully not that important that
* they can crash the whole Engine.
*
* To register a Command to the Engine::Commands system you have to call \code
* AddCommand ("crazycommand", Cmd_CrazyCommand); \endcode in
* ModuleName::OnRegisterCommands. With this the Command is accessible through
* the Command system.
*
* \section addvariable Adding a Variable to the Engine::Variable System
*
* To register a variable to the Engine::Variables Module one \e must use a
* static variable of type Engine::Variable and use a special constructor:
* \code
* static Var_Variable PlayerSpeed ("playerspeed", "1.25");
* \endcode
* This constructor takes care of registering the Variable PlayerSpeedVariable
* and its value to the Engine::Variables Module. The first argument is the
* name of the variable which can be used to retrieve a pointer to the
* Variable with Engine::GetVariable, Engine::GetVariableString, etc. The
* second argument is the value which the system will automatically try to
* convert to a float. This float is then returned if Engine::GetVariableFloat
* is called.
*
* The prefix \e Var_ is for readability in the code.
*
* The keyword \e static ensures that the lifespan of the variable is not only
* in a local function environment and thus mandatory. However it is
* registered at that time the program executes the first time the line in
* which the definition was made. To be safe define all your variables in the
* global scope of te source file of your Engine::Module.
*/