This weekend I’ve loaded up the reactive teaming agents again, and confirmed that the simple version still works– in retrospect, I probably could have loaded them up for the demo on Friday after all. To see them in action, just run Memstore, FI3RST, and BEHAVE with no arguments (though FI3RST needs a pointer to its base directory). Only one agent has a pick up object behavior defined; the others “learn” this behavior from the “Janitor Agent”. In addition, I’ve added some simple testing for failing behavior layers which will deactivate behaviors which have failed too often. This is a key aspect of more advanced teaming, which will be smarter about choosing which layers to transfer, and when to request layer transfers. I’ll drop a video on youtube once I’ve got something a little fancier together.
I tracked down the issue that was causing agents to stop, and it comes down to synchronization. Essentially, an agent could come back around to its next iteration and attempt to resolve actions before all of its behaviors had run, since they are running in separate threads. I’ve tested this by doing the dumb thing: I fixed the number of threads at run-time (the code is set up to allow the creation of more threads on demand), and dropped a barrier wait into the worker threads, so that the threads essentially run in lock-step: all agent controllers run, then all behaviors run. There’s only one barrier, so it really just requires the agent controllers to run before the behaviors.
The barrier wait is not a good solution. I’ve come up with a few different possible fixes, but I think the most logical is to just assign behaviors in the same thread as the agent controller runs. There are potential balancing issues with this, but those exist at the moment anyway.
Lighting? Check.
New building block models? Check.
Holodeck skybox? Check.
I need to modifying the logger to implement this:
Use STL streams for easy C++ thread-safe logging
This hadn’t occurred to me. It’ll be less efficient, but properly thread safe. It’s rare that messages actually get mixed up by the logging system, but it does happen.
BEHAVEngine and FI3RST are now talking, and movement/speech requests are tested. Action requests are not yet tested, but should be smooth. I’ve set up an action framework in FI3RST; to add an action, create a new FI3RSTAction class and make sure it gets instantiated in the FI3RSTAction::initializeActions() method. The following must be written for a complete action:
- name : this is the name of the animation to use for this action. it may be a fake animation, but it must be defined in the character description file (walking-guy-jump-idle.xml)
- interruptible : true if this action may be interrupted before it is complete, false otherwise. This is independent of whether the animation is interruptible (though it would probably be sensible if they match).
- duration : how long after the action animation is started that the action should take effect. for example, for the “pick-up” action, the object should not disappear until the animation has put the character within reach of the object. Value is in milliseconds.
- loop : set to true if the action should repeat, false if it should just run once. usually should be false. This is independent of whether the animation will loop.
- checkRequirements(ActionInformation &, std::string &) : This takes the request for the action, checks that it is possible (the character and objects exist and are capable of the action), and returns true or false. If it returns false, the “reason” string must be filled in with information about why it failed– this string is printed directly to the console.
- reserve(ActionInformation &, std::string &): This takes the request for the action and marks all objects that will be used for it. We do this to make sure that the objects are still available when the action itself executes. If any objects cannot be reserved, it must fill in the reason string with information about why it failed.
- executeAction(ActionInformation &, std::string &): This executes the action, and will be called no sooner than gTime->getTickTime() + duration, but may occur slightly after. It should call checkRequirements again to be safe. If the action fails at this point, reason must be filled in with information. If the action succeeds, reason should be filled in with a feedback message.
- cleanUp(ActionInformation &): This method must clear any flags set in the reserve method.
Note that only one instance is created of a FI3RSTAction, so it must not be used to store state. If any state beyond what is present in ActionInformation is needed, and there is absolutely no way to work around it, then we’ll deal with that later. No additional state should be necessary, though.
Organized by major items..
AAMAS 2010 Paper
- Reactive Teaming for Intelligent Game Characters
- Outline is more complete; my ideas for the technique are solidifying.
- Can’t use BEHAVE/FI3RST yet for any experimental work, unfortunately. I’m not quite sure what I can throw together outside of this though.
- I’m concerned about getting this out on time, but not despairing so far…
FI3RST
- Waiting on SSPS data; Hunter stated this is his primary concern at present
- Need a camera
- I should apply more checks to the basic “pick up” action
- Sounds like Goa has managed to pull in animations, though I haven’t seen his new model. He asked about how to modify the animations, and I told him this is where he’s largely on his own. He’s coming by tomorrow morning again.
BEHAVE
- Not even going to try doing integration with FI3RST until I have SSPS data
I hate Java. In many ways, it is an irrational hate, or seems so. Some of it is probably just the way of the world, given that I love scheme and I love C++; in order to love these languages, I necessarily must despise all that is Java.
I love this blog post because it helps to rationalize my hate. Also because it makes excellent points and explains them very well.
Was thinking about the equation for the expressiveness of our interface that Dr. K came up with, and it seems like pursuing this a little further could provide a nice comparison of the complexity of graphically editing a FSM vs. graphically editing a subsumption architecture.
As I think about it, while we typically talk about the number of transitions between states as being the big issue, the complexity of the individual states of an equivalent HFSM is going to be bad. The inhibition/resolution aspect of subsumption makes this a non-issue.
Dr. K asked what the options are generally: my quick answer was that the last (non-classical planning) approach is connectionist. ANNs have their big problems, but there may be a case to be made for Maes nets. So this should probably be checked out at some point.
I also found, with some quick googling, this white paper.
Anyway, things to think about, and relevant both to chapter 2 and the journal paper.
