maximinus-thrax Posted November 17, 2010 Report Share Posted November 17, 2010 Tonight I went through the code in /binaries/data/mods/public/simulation/componentsUnitAI.js to see what what was needed in maing the AI better (or at least having an AI).I see that basically a simple finite state engine has been coded (good, since that was where I was going to start anyway). It contains a few things that should be perhaps moved somewhere else (animation details, for example) but that's not a big thing.What I'd like to know is, before I start to tinker:Has there been any discussion so far on what direction to take this code, or handle the AI?Has anyone got any input they'd like to make anyway regarding this issue?And, on a more practical note:Is there an easy way to log some output when the game is running?That's all for now, more as i delve into the code more Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted November 17, 2010 Report Share Posted November 17, 2010 Simulation scripts can use print() (goes to stdout - not very useful on Windows) and warn() and error() to log messages.I think UnitAI probably doesn't need any significant changes in direction - the HFSM design seems to work okay so far and the code just needs incremental fixes and features. But "okay" isn't "great" and there may be better ways of doing this Player AI is independent of that, and the technical design hasn't really been discussed at all. What I imagine is that it would be entirely script-based, and each AI player would run in an isolated script context (potentially in a separate thread), using something similar to what the GUI uses (components/GuiInterface.js etc) to query the current simulation state and then output a list of commands to run. This new AiInterface thing would be more powerful than GuiInterface since it needs to return details about terrain etc, and needs to provide efficient access to large amounts of data. The internals of the AI script would be entirely dependent on what the AI scripter chooses to do, so we can let people experiment with that once the basic interface is sorted out and we probably don't need to decide on a single way of doing that - it would be good enough to start with just some predefined build orders and some timers to trigger an attack on the enemy, to get the system tested and running. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.