Ironseed is built on several layers, giving us more flexibility and abstraction.  Nothing talks directly to the implementation, only though interfaces.  We can easily swap out one engine for another if we want to later on.  The diagram isn’t 100% accurate since there’s a lot more going on here than can fit into a simple picture.  The actor component system is very similar to Unreal’s system but with a number of changes.  The concept is the same however since it really is a good idea to associate graphics, sound, physics together into a single unit.  Ironseed itself is broken down into data manager, ship, UI handling, and contexts.  Data managers deal with the static data like the 30 odd crew members, descriptions, portaits, and initial stats.  The ship object is your basic save game with all the instance data such as the crew members you’ve chosen and their current level and experience points.  The UI handlers deal with mouse and keyboard input and window management (mostly handled by Qt).  And finally contexts are various mini worlds in the game.  Each screen is a little world with current state.  Only one context receives input and draw requests at a time.  And finally, there is the scripting engines handled by Golem and a new-undetermined scripting engine.  I’m personally leaning towards AngelScript at this time.  The scripting will be built on top of Golem and the ship/data managers.

In an ideal world, there will be no code in the contexts.  The contexts will be a combination of layout scripts (XML), golem scripts (called from the game logic scripts), and game logic scripts.  The game logic scripts will be able to manipulate actors in the world, run animations, play sounds, access data managers, etc.  Complex animations will be golem scripts.  Any long running operations will also be golem scripts – I don’t want the scripting to block.

As much as I hate scripting, scripting gives us so much more power.  We can reload a context layout on the fly, modify scripts, run scripts from a console, whatever, while the game is still running.  So compile, link, execution time unless we need to add some new data manager or engine code.  I’ve already got the rewrite version automatically reloading the layout XML and recompiling shaders whenever the data files are modified.

As I mentioned, there will be a console window to execute script commands, reload scripts, and view script debug logs.  There is also a “debug buddy” window.  The debug buddy provides additional game control and diagnostics.  You’ll be able to jump to any context, edit the ship and events, enable/disable features, and anything else I can think of to add.  You shouldn’t have to watch the intro every time or navigate through the menus to get to a context you’re testing.  That can be disabled for debug mode.  Debugging is going to be a major focus and rapid prototyping.