Design Phase 0
In the initial design phase of the UI component of the SDK, we initially planned on creating an drawing api similar to the graphics api – that is, if you wanted to draw a menu, we needed to provide an api to create the menu. Thus, addon authors were limited by the apis available; it didn’t really follow the spirit of Project: Smallworld.
So we switched to the idea of a implementing an xml-based language that would decided what went where, how it would look, and when it would be displayed. Then we could theme the UI as well – xml would be the same, but we’d have another file deciding the color scheme; players could swap out one theme for another!
Rather than reinventing html and css, we decided to embrace it. Not only does it allow for exactly what we needed, it also has a huge developer base.
Bridging the Gap
Project: Smallworld handles this problem by making sure that addons on the .NET side handle everything in a static manner, and performs the serialization and deserialization from scripts in a fairly straightforward way.
Addons register for the events that will be sent and the events that will be received. Later, on the scripting side of the addons, those events will be registered to be received and registered to be invoked, all the while verifying that the events being registered actually exist.
Addons never deal directly with untyped objects (instead using typed objects that are “safe” for serialization/deserialization to the script), and the scripts use the data from addons as simple data objects. Events from one side cross the bridge to the other side, where the event is just handled via callback on the other side. It’s as seamless as registering for hooks or slots.
More to Come
Our hope is that both the addon side and the scripting side will look and feel as naturally as their environments normally are (static or dynamic, respectively).
If you’re interested in seeing what the api will look like, stay tuned – we’ll be releasing more specific details about the UI api soon.