This interface is used by the application to delegate decisions and routing to game-specific logic. More...
|virtual||~ClientGameLogic (void) throw ()|
|virtual void||setHost (ClientGameLogicHost *host)=0|
|virtual bool||localPlayerJoined (int playerId)=0|
|virtual void||localPlayerLeft (int playerId)=0|
|virtual void||notifyInput (int playerId, const event_t &event)=0|
|virtual void||tick (float dt)=0|
|virtual void||appendGameData (xdrbuf::Output *outbuf)=0|
This interface is used by the application to delegate decisions and routing to game-specific logic.
A user of this library must provide an object that implements this interface.
This means that client game logic depends somewhat on client-specific implementation details such as input events! But practically, that is going to be true of any game.
This interface breakdown (Application vs ClientGameLogic) is intended to keep the coupling to a minimum, and to allow people to override the reference game logic and provide their own, without having to change the Application.
Developers needing larger changes (different rendering/input libraries entirely) may want to override behavior at the Application level (or even the aesop::ClientHost interface), in which case they may not need this interface at all.
What does client-side game logic do? After all, a lot of game logic should actually run on the server.
Client-side game logic will:
|aesop::ClientGameLogic::~ClientGameLogic||(||void||)|| throw ()
|virtual void aesop::ClientGameLogic::setHost||(||ClientGameLogicHost *||host||)||
|virtual bool aesop::ClientGameLogic::localPlayerJoined||(||int||playerId||)||
|virtual void aesop::ClientGameLogic::localPlayerLeft||(||int||playerId||)||
|virtual void aesop::ClientGameLogic::notifyInput||(||int||playerId,|
|const event_t &||event|
|virtual void aesop::ClientGameLogic::tick||(||float||dt||)||
|virtual void aesop::ClientGameLogic::appendGameData||(||xdrbuf::Output *||outbuf||)||