Pyrogenesis HEAD
Pyrogenesis, a RTS Engine
CCmpAIManager.cpp File Reference

Player AI interface. More...

Include dependency graph for CCmpAIManager.cpp:

Classes

class  CAIWorker
 AI computation orchestator for CCmpAIManager. More...
 
class  CAIWorker::CAIPlayer
 
struct  CAIWorker::SCommandSets
 
class  CCmpAIManager
 Implementation of ICmpAIManager. More...
 

Macros

#define REGISTER_FUNC_NAME(func, name)    ScriptFunction::Register<&CAIWorker::func, ScriptInterface::ObjectFromCBData<CAIWorker>>(rq, name);
 

Functions

void QuitEngine ()
 

Detailed Description

Player AI interface.

AI is primarily scripted, and the CCmpAIManager component defined here takes care of managing all the scripts.

The original idea was to run CAIWorker in a separate thread to prevent slow AIs from impacting framerate. However, copying the game-state every turn proved difficult and rather slow itself (and isn't threadable, obviously). For these reasons, the design was changed to a single-thread, same-compartment, different-realm design. The AI can therefore directly use the simulation data via the 'Sim' & 'SimEngine' globals. As a result, a lof of the code is still designed to be "thread-ready", but this no longer matters.

TODO: despite the above, it would still be useful to allow the AI to run tasks asynchronously (and off-thread). This could be implemented by having a separate JS runtime in a different thread, that runs tasks and returns after a distinct # of simulation turns (to maintain determinism).

Note also that the RL Interface, by default, uses the 'AI representation'. This representation, alimented by the JS AIInterface/AIProxy tandem, is likely to grow smaller over time as the AI uses more sim data directly.

Macro Definition Documentation

◆ REGISTER_FUNC_NAME

#define REGISTER_FUNC_NAME (   func,
  name 
)     ScriptFunction::Register<&CAIWorker::func, ScriptInterface::ObjectFromCBData<CAIWorker>>(rq, name);

Function Documentation

◆ QuitEngine()

void QuitEngine ( )