After loosing this blog entry for three times in a row due to the fancy new firefox I hope the post makes still or now even more sense.
As part of my PhD I researched biomimetic models which could be useful for game applications as well. During my reserach I found that the Basal Ganglia and specially a bunch of cell groups (dopamineric cells) showed some fancy behaviour when pursuing goals. I started building a model in Mason to see how it affects the action selection and it proofed to present interesting and stable results. Basically I went away from binary triggers to use a ramp for the selection and activation of behaviours. From my point of view and supported by the results of my agent simulation this could be interesting for games as you would be able to specify needs or motivations in a BehaviourTree(BT) or dynamic plan instead of using complex triggers which are initially easy to set up but with a growing complexity of the agent get harder to maintain.
I submitted a paper about this to CIG2014 and because I think this could work in industry I proposed a talk at the AiGameDev Conference. If you read a couple of research papers which are published you see that some things are not applicable and sometimes even totally made up. So trust and good faith are generally low if you have no name and no proof. It seems that a game-like real-time agent based simulation is not enough to support my idea so I was asked to present a demo in an actual games environment, which I thought was a great idea.
... Yepp the idea is great but it took me far to long ...
I migrated POSH to .NET to be able to use managed code in all kinds of devices and it seemed a good choice to leave JAVA (no rant here though I really want to). Using managed code you can basically use it freely in Unity and develop for Web, Standalone and Mobile. I need to still test mobile though. AngryAnt has a great post on how managed dlls work in Unity, see here.
Unity is a great IDE for games and speeds up loads of things but some things are odd, at least for me. When you develop your project you can test the execution in the IDE but pressing PLAY and STOP does not actually start or stop your code if you use your own threads. My idea was to use Update() and Application.isPlaying to see if the game has started to run or still runs but if you stop it in the Editor Update will not be called for a final time your for me POSH kept running and I had no way of stopping it other than closing Unity, which is a pain.
Debugging Unity is still not nice but maybe I am just to pampered from Java debugging. As I am developing in Visual Studio my debug statements and symbols are inside the pdb files. To use MonoDevelop for debugging I used pdb2mdb which works like a charm. Still Monodevelop is not yet a great IDE though it is getting better and better. After a couple of hours of hanging and missed debug steps in Monodevelop I switched to UnityVS which is great as you can use VisualStudio for debugging. It is still somewhat painful and a couple of things do not seem to work properly in UnityVS but I still have hope!
After searching and testing I found that using MonoBehaviour.OnApplicationQuit() and OnApplicationPause() are the right place to stop or pause POSH. This is super helpful as mobile devices generally do not simply close games but put them on pause for a while before closing them.
To integrate POSH now into a project you only need to create a script extending POSHController and attach it to a GameObject. This will be your POSH "brain". The Controller has a simple API to start stop and connect behaviours. All behaviours as well as the AI Design plan (similar to a visual BT) need to be connected to the brain to work. The behaviour integration is still a bit messy as you'll need two classes one is extending POSHInnerBehaviour and is responsible for wrapping the actual actions and senses to be used by POSH. The other is POSHBehaviour which is attached to a GameObject and contains the actual actions and senses. Those will be wrapped by the InnerBehaviour and called from within POSH. At a later point this should be simplified using class inspection but that is a bit tricky with Unity and the limited API, I guess.
So everything is settled for getting the demo working now I only need a couple of actions and senses to move the bots and re-create the agent simulation in a game setting.
All of this plus recording the demo and doing slides in three days ... piece a cake ... really!!! *cough*