After spending some time on the ERGo implementation, meaning a ramped activation model using an agent-based simulation I got different results for my model in Unity, as expected.

First a little rant. After using UnityVS as a trial I was super happy with my workflow. It is a lot easier to find small issues and despite the good effort people put into Xamarin, it is still some time before it is as user friendly as VisualStudio. Same applies to Debugging in Monodevelop vs. debugging using UnityVS.

Due to some unfortunate timing Microsoft saw the potential of UnityVS and bought it, see here., directly after my trial was running out. So I am unable to use or buy, which I actually wanted to, UnityVS until the whole take-over is done. I was told that Microsoft might plan to release UnityVS for free which would be great as the cheapest license was $99.

I spent the whole day yesterday debugging in Monodevelop and reading forum post how to use to debugger more efficiently. It is such a hassle compared to UnityVS and VS. The main issue is that stepping into code and stepping over some statements does not work properly. Sometimes you are not able to step into some code, which seems arbitrary. Also it takes a long time to start the project and coding in Monodevelop is not as nice as in VisualStudio, if you like auto-complete and proper search and replace throughout the whole project.

Enough ranting I am being overly German again.

I now use compile-time statements to turn off/on logging using log4net as it does not work in the webplayer. The bots are cloned at startup and each one is running with the same agent plan and ERGo implementation but different instances. It is amazing how the ramp makes the behaviour switching more fluid without loads of additional work. The behaviours are super simple and I will upload a demo soon to be available on my side. The models are still all the Stealth demo models but their behaviour is different.

Here a small screen shot from the current level:

UnityRoboGuardPatrol0.png

The impact on the CPU when using POSH# is not really visible to me and I think there are some things which need optimisation. If I get a chance to use a profiler I will have a closer look but I already found loads of funky ideas on optimizing the slip-stack which contains the tree elements. The POSHTree is currently small but processing it is super cheap anyhow as all computation is done in parallel outside the tree. The tree only looks up changes in memory this way computation and logic are separated.

I also used the Unity plug-in Loom for the first time and its great if your code runs in a separate thread and Unity is complaining about access and multi threading ;)

The next things I want to do are hot-swapping actions using my POSH versioning system which I neglected a bit. The idea behind it is super simple you start of developing primitive actions and senses and create the structs for using them inside the POSH tree so that the designer can create and experiment with the system. After that you not simply hack those primitives but you use a versioning mechanism to develop different versions of the same primitive without replacing the first one. POSH is able to pick those up and allow you switch between those at run-time. Currently this is disabled and the highest version number is chosen but the hot-swapping has some neat principles like having a simple agent with the same POSHtree and then a sophisticated version of the same tree with more advanced actions and senses.

Argl... and I still need to focus on the Genetic Programming stuff. So much to do so few clones...

I wish I was a Unity Asset ;)

Ohh ... a great papere and Behavioral GP:

Krzysztof Krawiec and Una-May O'Reilly (2014) Behavioral Programming: A Broader and More Detailed Take on Semantic GP. In Proceeding of the sixteenth annual conference on Genetic and evolutionary computation conference. New York, NY, USA. ACM. (URL)