Commands and timing

Not much to show this week due to I3D/GDC trip planning, along with trying to approach the problem of commands, and related issues.

As a header, I’m using variant of ECS, where the Systems don’t really do mass processing as usual, but are rather logic hubs, emitting/receiving events, and storing unique data. I also want the player and non-player characters and creatures to use the same underlying machinery for performing actions, using abilities, etc. The difference would be that the player needs to choose an available action and set the parameters via a UI (e.g choose ranged attack, select a tile), whereas the non-player entities would need to run some AI code that figures out what to do and how it should set the parameters. So, the common resulting part, which is the parameterized action, is the command.

An entity command  is the most basic bit of logic that does something, operating on an entity. A player can build a command via UI, while all other entities build them using AI. An entity command holds no state – it reads/writes state from/to the entity – therefore one of each is stored in the registry and are retrieved and used as flyweights. Such commands just return a bool that indicates if the command actually did something.

A timed entity command is a composition of a reference to an entity command plus some timing information. Now this bit is important, as I believe it will give some flexibility and increase the potential for strategy in the game. An entity command can be in 3 stages:

  • Inactive
  • Pre-Execution
  • Recovering

When the command is started, the stage switched from inactive to Pre-Execution and we wait for some time. The execution happens instantly after the pre-execution time has expired, and the entity immediately switches to the Recovering stage, regardless if the execution succeeded or failed. Also, while in the pre-execution stage, the command can be interrupted.  This requires the following additional information:

  • Pre-Execution duration
  • Recovery duration
  • Interrupt recovery duration
  • Interrupt difficulty class (DC)
  • Interrupt strength

So, if an entity can execute a command that, if applied to another entity, can interrupt it if it’s in the pre-execution stage. To check for successful interruption, the strength should exceed the difficulty class.

Some commands should be instant. In that case, all durations are set to zero.

That’s it for now – next time I’m going to describe how such timed commands fit together with a finite state machine (for simple AI) and a game turn manager.

One thought on “Commands and timing

  1. Pingback: “AI” Part One | Age of Transcendence

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.