ezEngine  Milestone 9
ezGameStateBase Class Referenceabstract

ezGameState is the base class to build custom game logic upon. It works closely together with ezGameApplication. More...

#include <GameStateBase.h>

Inheritance diagram for ezGameStateBase:

Public Member Functions

virtual void OnActivation (ezWorld *pWorld, const ezTransform *pStartPosition)=0
 When a game state was chosen, it gets activated through this function. More...
 
virtual void OnDeactivation ()=0
 Called when the game state is being shut down.
 
virtual void ProcessInput ()
 Called once per game update. Should handle input updates here.
 
virtual void BeforeWorldUpdate ()
 Called once each frame before the worlds are updated.
 
virtual void AfterWorldUpdate ()
 Called once each frame after the worlds have been updated.
 
virtual ezGameStatePriority DeterminePriority (ezWorld *pWorld) const =0
 Called by ezGameApplication to determine which game state is best suited to handle a situation. More...
 
virtual void ScheduleRendering ()=0
 Has to call ezRenderLoop::AddMainView for all views that need to be rendered.
 
virtual void RequestQuit ()
 Call this to signal that a game state requested the application to quit. More...
 
bool WasQuitRequested () const
 Returns whether the game state wants to quit the application.
 
- Public Member Functions inherited from ezReflectedClass
virtual const ezRTTIGetDynamicRTTI () const
 
EZ_ALWAYS_INLINE bool IsInstanceOf (const ezRTTI *pType) const
 Returns whether the type of this instance is of the given type or derived from it.
 
template<typename T >
EZ_ALWAYS_INLINE bool IsInstanceOf () const
 Returns whether the type of this instance is of the given type or derived from it.
 

Protected Attributes

bool m_bStateWantsToQuit = false
 

Additional Inherited Members

- Static Public Member Functions inherited from ezNoBase
static const ezRTTIGetStaticRTTI ()
 

Detailed Description

ezGameState is the base class to build custom game logic upon. It works closely together with ezGameApplication.

In a typical game there is always exactly one instance of an ezGameState derived class active. The game state handles custom game logic, which must be handled outside ezWorld, custom components and scripts.

For example a custom implementation of ezGameState may handle how to show a menu, when to switch to another level, how multi-player works, or which player information is transitioned from one level to the next. It's main purpose is to implement high-level game logic.

ezGameApplication will loop through all available ezGameState implementations and ask each available one whether it can handle a certain level. Each game state returns a 'score' how well it can handle the game.

In a typical game you only have one game state linked into the binary, so in that case there is no reason for such a system. However, in an editor you might have multiple game states available through plugins, but only one can take control. In such a case, each game state may inspect the given world and check whether it is e.g. a single-player or multi-player level, or whether it uses it's own game specific components, and then decide whether it is the best fit for that level.

Note
Do not forget to reflect your derived class, otherwise ezGameApplication may not find it.

Member Function Documentation

◆ DeterminePriority()

virtual ezGameStatePriority ezGameStateBase::DeterminePriority ( ezWorld pWorld) const
pure virtual

Called by ezGameApplication to determine which game state is best suited to handle a situation.

The application type is passed along, such that game states that cannot run inside the editor can bail out (or vice versa). If the application already has a world that should be shown, the game state can inspect it. If the game state is expected to create a new world, pWorld will be nullptr.

Implemented in ezFallbackGameState.

◆ OnActivation()

virtual void ezGameStateBase::OnActivation ( ezWorld pWorld,
const ezTransform pStartPosition 
)
pure virtual

When a game state was chosen, it gets activated through this function.

Parameters
pWorldThe game state is supposed to operate on the given world. In a stand-alone application pWorld will always be nullptr and the game state is expected to create worlds itself. When run inside the editor, pWorld will already exist and the game state is expected to work on it.
pStartPositionAn optional transform for the 'player object' to start at. Usually nullptr, but may be set by the editor to relocate or create the player object at the given destination.

Implemented in ezGameState.

◆ RequestQuit()

void ezGameStateBase::RequestQuit ( )
virtual

Call this to signal that a game state requested the application to quit.

ezGameApplication will shut down when this happens. ezEditor will stop play-the-game mode when it is running.


The documentation for this class was generated from the following files: