Development of Selenite began in Jan 2009, so that makes it officially 1 year old; having already written and released a game with it (STATIC: Investigator Training www.staticgame.com) I consider it a success, many of you reading this, myself included have taken years developing engines that never led to a game.
Revision of original plans and expectations
When I began designing and writing Selenite, I had some notions which proved useful, but have since needed to be revised; in short, plans have changed.
What has changed?
Licensing
Originally I had no plans of licensing Selenite, however we've had some interest. The key significance of this is that it must be really really good, but this has benefits as community feedback will drive fixes and changes.
Control
I designed in some pre-fabricated systems in the interest of simplicity; e.g. fixed GUI systems, fixed menu system. Though as time rolled on it became clear that if I wanted to approach different game designs it would be very helpful to have more flexibility in how the interface worked. So steps have been taken to remove these pre-fab systems, and allow creation of them through scripts.
Multiple Platforms
When the idea of multiple platforms became intriguing it required me to re-factor the editor and some of the engine significantly to allow for multiple build targets and varying media depending on platform restrictions. The only obstacles that exist now are keeping the engine small (it is currently around 6,000 lines of code) so that porting it from platform to platform is easy.
The revision process
Through revisions of the engine/editor to meet the above goals, several changes have come about which are very positive.
Unlocking the event system
In selenite you can create a specific set of events on objects, where you can write Lua code; and the engine can call these events. While a limitation of how the original event information was stored; I recently realized that I was unnaturally restricting a feature of custom events. You could only create events of specific names for certain object types; but with this change you can now create developer specific event names. To finish off this feature an API script command 'raise' was added so that the developer can call any custom or built-in event manually; this opens up the system to creation of other systems, which will be very important given that some built-in systems have been removed.
Creating the new GUI system
Those who follow my journal will no doubt remember my entry on GUIs and why implement GUI systems yourself is suicide -- unless you must.
It became apparent, slowly over time that developers are going to want the ability to create custom GUI; inventories, minimaps, equipment windows, chat windows, yada yada
there are ways in Selenite to creatively achieve these things without a generic GUI system, but overall it isn't flexible enough to do all of them really well.
The main draw to adding a GUI system, was not only that people are going to want it, but it would allow me to get rid of the built-in systems, reducing engine complexity.
Approaching the design
In designing a flexible GUI system for developers I had a major benefit; the UI class which I posted the code for previously; would work well as the seed for a new object type; the 'GUI'
I knew that if i was going to make a custom GUI system then GUIs would been to be first class objects, like game, rooms and actors; so this meant the dreaded re-factoring of the game-state.
The original model of Selenite looked like this:
Classes
StateClass::GameClass
StateClass::DisplayClass::RoomClass
StateClass::DisplayClass::ActorClass
Instances
StateObject::Game
StateObject::DisplayObject::Room
StateObject::DisplayObject::Actor
This was a very neat and clean arrangement, but adding GUI and GUIClass threatened to mess it all up; thankfully after long last I managed to figure out the new hierarchy:
Classes
StateClass::GameClass
StateClass::DisplayElementClass::GUIClass
StateClass::DisplayElementClass::SceneElementClass::RoomClass
StateClass::DisplayElementClass::SceneElementClass::ActorClass
Instances
StateObject::Game
StateObject::DisplayElement::GUI
StateObject::DisplayElement::SceneElement::Room
StateObject::DisplayElement::SceneElement::Actor
The GUI game-state
Previously with Selenite the game state worked as follows:
Game is the root of the state, a Game contains Rooms, a Room contains Actors
In the new model:
Game is the root of the state, a Game contains GUIs and Rooms, GUIs contain GUIs, a Room contains Actors
As you can see the original model had a fixed amount of levels; but in the new model, GUI objects contain child GUI objects, so the levels of that portion of the tree is unbounded; this is so that GUI elements can be composed of others.
That's all for now, I will try to go into other enhancements and implications of decisions for changes I am making.
