Added an object manager which takes care asynchronously of creating new objects.
It makes sure that the constraints of the class diagram are met and makes casts to classes possible.
Provided enter and exit actions support
Decent support for embedded python code in the XML files.

Added input and output handling with ports. One class-diagram now runs in one thread. All thread-safeness taken care of.
Throwing the base code mostly overboard and trying to code in a way which makes it easy to port to C#. (Not pythonicand responsibility separation by classes.)

Added a controller independent from DEVS. (While syntax support for ports has been added, the controller doesn't take in mind the timing of input events yet.)
Added local cast and broadcast. Added syntax support for narrow cast.
Fixed orthogonal states, which work a bit different due to the different syntax of SCXML compared to the one used in AToM.

Started working on a statechart compiler prototype in python.
It's based on a compiler of Reehan Shaikh which transforms a statechart model in AToM to code that runs on top of DEVS.
I changed the input method now to use XML files. I've made my own standard to format class diagrams to XML, and each of these class diagrams can have one statechart expressed in SCXML.

All risks have been researched.
Code-generation is possible, as well as communicating from the game to the statechart editor and vice-versa for debugging purposes.

Small prototype of the statechart editor has been build in Unity.
We will be using C# as target language and are planning to use SCXML to define the statecharts.

Currently decided to take Unity as architecture. Risk analysis started.

Contacted Gino Wuytjens, read his paper and experimented with his framework. Researched which options we have. As for the architecture we will work in, we have 3 options :

• Building our own game architecture
• Use an existing game-engine
• Use the architecture provided by an AI competition

A self-made architecture gives complete control and allows you to do basically anything, which is interesting for the evaluation process. Using an existing game-engine however will more likely convince the game-industry of our technique. I researched a number of game-engines :

• Source
• Unity
• CryEngine
• UDK
• Panda3D

Which resulted in Unity and Panda3D being the most suitable.

Using the architecture of an AI competition would provide us with lots of example AI which is interesting for evaluation purposes. Entering such a competition (and obtaining a good result) would also help in convincing the game-industry.

• AI Sandbox (Killzone)
• Tank Wars (EA)
• AI Challenge Ants (Google)

Here the AI Sandbox is the most interesting, as it provides an environment for very complex AI and Killzone announced to redo the competition.