User Tools
This is an old revision of the document!
Page Contents
Game Code Overview
The Cafu Engine can be used both for developing single- or multiplayer games that ship as individual products, as well as for products that support multiple, independent games in a single program that the user can select from at runtime.
For example, after starting the program, the user might choose from a list of online game servers (each possibly running not only different game maps, but entirely different games), or a list of available single-player games, and join one seamlessly without restarting the program.
In order to achieve these goals, and to maintain a good organization of the Cafu source code, game implementations are designed modularly in Cafu, such that all the specifics and implementation details of any game are kept separate from any other game, and cleanly encapsulated and independent from the core engine.
One directory and DLL per game
All data and code of a game is stored in a common subdirectory of Games/.
For an example, see directory Games/DeathMatch/ that ships with Cafu.
In each such game directory, the Cafu engine looks for directories and files that, per convention, have fixed names.
That is, in each game directory, Cafu expects to find the definition file EntityClassDefs.lua,
the implementation in Code/, GUIs in GUIs, world files in Worlds/, and so on.
Regarding the code, each game is implemented in it's own DLL/SO that can be dynamically loaded and bound to at runtime.
The DLL is expected to have the same name as the game, and thus expected to be found in
Games/DeathMatch/Code/build/.../DeathMatch.dll (Windows) Games/DeathMatch/Code/build/.../DeathMatch.so (Linux)
where ... is a path that is automatically created by the build system according to your platform,
compiler and build variant.
The ... path is also known to the Cafu engine so that it can load the library.
The game source code
The source code for the DLL is in Code/, inside which you can organize and arrange the source files at will.
The first function that the engine calls in the game DLL is GetGame().
For our example game DeathMatch, we have defined this function in file
Games/DeathMatch/Code/DeathMatch.cpp.
Please check out this file for more information on the function signature and documentation!
The next steps to get more familiar with the code is to check out the
cf::GameSys::GameI interface,
and its implementation in GameImplT.
The core engine will call the methods of the cf::GameSys::GameI interface, e.g. those to have new entities created after a map file has been loaded or when another player joins the game, and it's the job of the game code to provide implementations for these methods.
See the code for class GameImplT in order to see how it was done for the DeathMatch game.
With the BaseEntityT pointers to newly created entities, the engine will also call the virtual methods in the BaseEntityT interface, in order to let entities know about events or to have them carry out tasks.
These methods too are supposed to be overridden by the concrete entity implementation, and are in fact the essence of implementing a game:
An entity is considered a state machine that lives in a virtual world, interacting with the world and other entities, and for example its BaseEntity::Think() method is expected to update it over a small amount of time whenever the method is called (by the server code inside the engine).
Exploring the code
This document is not complete, and we will continue to improve it.
The class hierarchy is shown in
but these two documents need to be merged and updated and completed, where necessary.
If you have questions about anything that is mentioned in this document (or is missing and should be mentioned), please let us know! We will be happy to answer you questions and use the answer to improve this text.