Mode Switching Revisited

Hey Folks! Spent most of the day looking into mode switching on items, as the current problem of switching items on and off involves that system.

Up until now, I've been handling an object's mode switch by making a new object for the new mode, removing the old item from the ship, and adding the new one in its place. For the most part, this just works. Air pumps, alarms, and doors all use this regularly without issue.

However, while working on the reactor, I noticed a couple of problems.

The biggest one is that changing objects like this wipes out certain bits of important info when the old item disappears to be replaced by the new one. We lose certain conditions which have been set on the old one, such as "IsSwitchedOff." We also lose the interaction queue that was ongoing between the crew and the reactor, which is what caused the UI to appear. And that UI stores a reference to the game object it represents, so we lose track of that, too.

The lost conditions were a pretty simple fix. I added a "bPersists" field to conditions to signify that they should carry-over to the new object in a mode switch. And that worked well enough.

However, the problem of the lost interaction queue and lost object references still remains. So I started looking into leaving the original game object around, and just copying the new data into it to replace the old data. This way, we can maintain important data that should remain, and update the rest, without losing any references.

The down side here is that game objects are extremely complex, with lots of data and references. There's a lot of room for error here, and I don't particularly want to rewrite the data population code for this.

About halfway through writing code to copy properties over one by one, I started to wonder if it might be easier for me to use the existing code for loading an object from json data. I mean, that's basically how the new object gets created in a mode switch anyway. We just spawn a new object based on json data. Can we use the SetData(Json) function again to overwrite the existing object's data?

Perhaps. It'd set all the necessary data, for sure. And it might not be too hard to keep track of some important bits before wiping out the old data, so we can reapply them later. We do, however, have to account for any data on the old object that needs to be cleaned up. Like removing any gas container or power components that are no longer applicable.

It can probably be done. But it'll be a complex task. And one I couldn't get near done before the end of the day. So I'll likely resume looking at this Monday. Or, if I'm lucky, think of an alternative that's simpler and more reliable!

In any case, hope everyone has a good weekend!

Tags: Ostranauts

Comments

Rovlad's picture
Rovlad

Hey, take a look at Objects in Space (that's a game, recently went from early access to full release) whenever you have time, unless you already have.

It does nifty things as far as "believable starship controls" goes, which I think you could nick, I mean, get inspiration from. Best part is: different ships look and feel different. You'll see what I mean by just playing through the main story up to the point when you're off the Leo station.

It's not a whole lot aside from that though; no crew management, or satisfying ship-to-ship combat. But damn, it revels in its attention to minutae (reactor load vs drain, switchable modules, downloading latest comm codes from a station you're docked at, enabling/disabling IFF, etc).

dcfedor's picture
dcfedor

I have! It was a while back. Maybe close to a year ago. But I definitely liked where it was going. Now that they're out of EA, I'll have to give it another go!

Dan Fedor - Founder, Blue Bottle Games

olsonjeffery's picture
olsonjeffery

The reference/expiration issue you describe is something that ECS systems implicitly resolve. Instead of holding an actual object reference, what if your objects just held an entity-id and they could query a relevant system data provider(eg the reactor sub-system or person behavior sub-system, etc) for the latest and greatest system-related data assocaited with that entity id?

You can also sidestep all of these marshalling issues (restoring from JSON.. where does that JSON come from?) when you instead think of some centralized, lifetime-bound data provider/warehouse holding all of the data that your game code has to interact with for a given system. Anyways, it's a big topic. Good luck!

dcfedor's picture
dcfedor

Thanks! And yeah, there's a good chunk of ECS architecture that I didn't "get" when I started, so a lot of the code isn't taking advantage.

In the case of object references, I fortunately do have a means of reacquiring the object by ID if the old version gets destroyed. (The save/load system needed it to reattach broken relationships, like container/contents, or sensor/listener pairs.) I just got lazy over time and started to rely on acquiring the reference once, and using that.

Ultimately, I'm a mediocre programmer with occasional good ideas, who still has a lot to learn :)

Dan Fedor - Founder, Blue Bottle Games