Player AI interface. More...
#include "precompiled.h"#include "simulation2/system/Component.h"#include "ICmpAIManager.h"#include "simulation2/MessageTypes.h"#include "graphics/Terrain.h"#include "lib/timer.h"#include "lib/tex/tex.h"#include "lib/allocators/shared_ptr.h"#include "ps/CLogger.h"#include "ps/Filesystem.h"#include "ps/Profile.h"#include "ps/scripting/JSInterface_VFS.h"#include "ps/TemplateLoader.h"#include "ps/Util.h"#include "scriptinterface/FunctionWrapper.h"#include "scriptinterface/JSON.h"#include "scriptinterface/Object.h"#include "scriptinterface/ScriptContext.h"#include "scriptinterface/StructuredClone.h"#include "simulation2/components/ICmpAIInterface.h"#include "simulation2/components/ICmpCommandQueue.h"#include "simulation2/components/ICmpObstructionManager.h"#include "simulation2/components/ICmpRangeManager.h"#include "simulation2/components/ICmpTemplateManager.h"#include "simulation2/components/ICmpTerritoryManager.h"#include "simulation2/helpers/HierarchicalPathfinder.h"#include "simulation2/helpers/LongPathfinder.h"#include "simulation2/serialization/DebugSerializer.h"#include "simulation2/serialization/SerializedTypes.h"#include "simulation2/serialization/StdDeserializer.h"#include "simulation2/serialization/StdSerializer.h"
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 | ( | ) |
