Discuss these changes in this thread in the General Discussion forum.
The time has come for another weekly update!
This week’s agenda for me largely revolved around finishing my Open Water Scuba certification. As of now, I’m officially certified! The downside is that I didn’t get quite as much done this week as I’d hoped. Since there isn’t really anything in the way of pics to post, I thought I’d let you guys in on what I’m working on right now.
When we first set out on this iteration of SS13, we very quickly put together a system of representing objects in the game as a big tree of related objects. Each item, such as a welder, a helmet, or a human mob descended from a single base object we were calling an Atom. This system worked really pretty well for a while, and could have gone on working for a while longer, with some serious babysitting.
Here’s kind of what it looked like (simplified):
[Atom]----------------
/ \ \
[Item] [Mob] [Object]
/ \ \ / \
[Tool] [Light] [Human] [Firealarm] [Door]
/ \ \
[Flashlight] [Welder] [WallLight]
Each of these items would inherit the properties and functions of the parent object. This way, we could build objects with lots of functionality without rewriting lots of code.
Now, you can probably already see a problem with this. Because of the way C# and really, Object Oriented Programming, works, we can’t make child objects with multiple parents. So what if I want to have a Fire alarm that is also a light? I’d have to duplicate the code for the light, or I’d have to make some workaround system. Definitely not an ideal or practical way of doing things for a game with this much content!
So over the past 2 weeks, I’ve been working on a new way of representing objects, usually referred to a component object model.
In this model, we represent objects as parameters and behaviors.
A Fire alarm, for example, is a stationary object that attaches to walls, that we must be able to draw to the screen, must be able to emit light, and should emit sound, and respond to triggering events.
Therefore, the new system will represent it as follows:
|---------------|
| FireAlarm |
|---------------|
| Renderable |
| SoundEmitter |
| LightEmitter |
| Triggerable |
| WallMountable |
| Clickable |
|---------------|
This is far simpler than having to manage an unwieldy inheritance tree just to implement a fairly simple object like this.
A huge benefit of the new system is that once it is done, we’ll be able to greatly simplify object creation, allowing us and modders to build new object templates in XML, like so (this may not be the final specification):
<xml>
<Template name="FireAlarm" fullname="Fire Alarm">
<Components>
<SimpleSpriteComponent>
<State name="on" filename="fire_alarm_off" />
<State name="off" filename="fire_alarm_on" />
</SimpleSpriteComponent>
<SoundEmitter active="false">
<State name="on" filename="klaxxon" repeat="true" />
</SoundEmitter>
<LightEmitter color="#FF0000" active="false" />
<Triggerable />
<Clickable />
<Destructible health="100" />
<WallMountable height="36" />
<FireAlarmComponent />
</Components>
</Template>
</xml>
You can see a sort of special purpose component in there, the FireAlarmComponent, which will basically just connect up the various components.
This, at least, is the goal of the work I’m doing right now. Things like user input are already wired up with the new system, and we’re working on porting over all of the existing functionality. In the coming weeks you should start to see new content screenshots, but it might be kind of dry from the coding department for a while.
Questions? Come talk to us on the forums!
