December 13, 2013

A Layered Game Architecture III - Scenes and Directors

Scenes and Directors

Apart from actor AI, states and physics as describe in the first backend post, there is much more to be controlled in a game like:
  • handling collision events
  • watching actor's life power
  • collecting visible actors for each player
  • using gadgets like invisibility, super speed, damage doubling, etc.
  • walking upon special tiles for powering-up
  • opening and closing doors
All this is controlled by various directors. A director is the controller counterpart in a MVC architecture. Its models are actors and scenes.

Scene directors control game scenes. A scene is the model of one part of a running game. Games can have one or multiple scenes.
Examples for scenes are:
  • a shop to buy new weapons 
  • the battlefield where the action takes place
  • a screen to switch levels 
  • a built in mini game
  • an underground dungeon as opposed to the day light world
Now, just like in the real world, directors like to delegate work. Here, there are various sub directors, each specialized for one kind of task. For all the listed tasks at the beginning of this post, there is one sub director.
There are two given abstract implementations of sub directors:
  1. Directors that operate on a (dynamic) list of actors of one defined type, like for example:

    BlackHoleDirector - for droids and bullets
    Loops through its actors and drags them into nearby black holes if applicable.

    ActorLifeDirector - for droids
    Removes droids with a power of zero.

    PhysicsDirector - for droids, bullets and level gadgets
    Listens for added and removed scene actors and notifies the physics module about it. Creates appropriate events for actor collisions.
  2. Directors for tasks that are not bound to given actor lists, like for example:

    Does not work on a list of actors, but on incoming collision events between droids and bullets detected by the physics director.

    Does not work on a list of actors either, but on incoming player requests to become invisible. Activates and publishes according looks and disables invisibiltiy after a given time span.

    Does not work on a list of actors but on the list of current players. Each player gets a personal list of currently visible actors.
If neither AbstractSubDirector or AbstractActorsSubDirector suits a given task, ISubDirector can be implemented and plugged in as well.

Some important characteristics of sub directors:
  • They allow to modularize game control into smaller maintainable tasks.
  • They are invoked one after another from the game loop.
  • They can be invoked for each game frame or after a defined time span, like every 100ms.
  • They realize a plugin concept for the whole game direction sub system.
  • They can be enabled and disabled at runtime.

December 11, 2013

A Layered Game Architecture II - Backend AI

The first part of A Layered Game Architecture gave an overview of frontend, backend and shared packages. Here, we continue with a look upon the backend components for actors and AI:


Each interactable game object is represented as IActor. Actors are controlled, influenced, directed, moved, created and removed by states, goals, game physics and directors.
Actors are the central object in each game. To avoid dependencies to concrete behavioural implementations, each actor has only a IActorBehaviour reference and does not whether it is controlled by states, goals or in any other way. This allows to plug in, for example, your new sophisticated almighty AI controller instead of using goals, or to switch from Box2D physics to any home brewn physics algorithms without affecting other framework and game parts.


States offer separate representations of, for example, moving and waiting actors. Furthermore, game events of all kinds like input and collisions events can be sent and received. Typical events are BulletHit, BulletMissed, DesiredHeading.
States could also be used to implement a (primitive) AI. Then, actors would not get a GoalBrainAndStateBehaviour but a simpler StateBehaviour.


The game physics makes sure that actors move and behave according to the physics rules of the game world. It takes care of collisions between multiple actors as well as between actors and the environment. Collision listeners get notified to initiate appropriate reactions. Velocity and acceleration is calculated from given player input and AI events.
Source and target for game physics is IMovable where data for positions, forces, velocities and acceleration is stored. Because a multiplayer client/server game architecture requires to move actors on server as well on client side, movables are parts of the shared base class ICharacter which resides on both client and server side.
The game physics takes desired actor movements as input and applies them to the game world model. Whether movement commands origin from player input or from AI thoughts is of no interest and simply unknown.


Actors can try to achieve goals like finding level items, following and shooting the player or fleeing and hiding. A typical output of a goal is a new heading direction which is handed over to the physics components. Actor velocities or positions are not directly manipulated from goals to let the physics module handle and watch the complete game physics of all objects together once per frame.
Like states, goals can also send and receive game events of any kind.

Goals are a part of an actor's brain which is supported by its memory where recent observations, events and all kind of AI important information is stored and used for subsequent decision finding. Naturally, a brain has an assigned actor, but, to get back to the previously introduced behaviours, actors don't contain references to their brain.

The goal sub system was inspired by the great book Programming Game AI By Example from Mat Buckland.