Loading Snag, Fixes, Art Help, and OOO

Hey Folks! Bit of a mixed bag today, split between fixing some smaller bugs, discovering an iceberg of a bug, and looking for artists.

Most of the morning was spent looking at artists, for a change. I'm still toying with the idea of contracting an artist to help with that side of things. The art style I have in mind is fairly close to what you see already, but I think it could be improved. So part of what I'm looking for is someone to help be figure out how. And, ideally, to do some of that work in an ongoing capacity as more assets are needed. E.g. more ship parts, items, face sprites and animations, etc.

I'm also expecting to need some more traditional art in the form of illustrations like we saw in NEO Scavenger encounters. So bonus points if that artist can do both pixel art and traditional art. (Extra bonus points for rigging and facial animation, which I realize is a stretch, since we're getting into a wide range of skills.)

It's been something I've occasionally researched, and today was one of those days. I'm super picky, though, and rarely reach out to anyone. A lot of folks have actually offered to help, but usually their style isn't what I'm going for. The search continues...

Back on the dev side, I warmed-up by solving a few minor issues after playtesting a bit. Trimming down the spam in the AI messages, fixing the missing benefits of defecating...you know, important stuff like that :)

But that's when I ran into the snag. I thought I was going to fix a minor bug of missing food packets in fridges loaded from save files. But as it turns out, it's one of the tricky bits related to that ID issue I solved the other day.

Basically, when you spawn a new ship in the game or load from a save file, it uses the same saved ship format. And this causes problems when you want to spawn multiple ships from the same template (e.g. a standard station I'm using). If you try to load the same thing twice, both end up having components with the same unique IDs, which means two ships end up having shared pieces. Anything that happens to one will happen to all other copies. And worse, the geometry ends up being invisible for all copies except the first.

So the obvious solution would be to generate new copies of all the ship pieces when cloning a ship from a template, right? Which works, but only kinda. There's a lot more to a ship than just individual pieces. A lot of the more complex stuff cross-references other items on the ship, and that relies on these unique IDs.

Case in point, items with UIs often specify which shipboard piece the UI refers to. So if you have a UI showing a battery charge remaining, it needs to know you've cloned that old battery and point to the new one instead.

So the copy of the ship needs internal ID references updated, too.

Plus, anything with a standard loot definition will need a decision made: do you want an exact copy of the current loot in the item? Or do you want to re-roll the loot for that item? For something like a fridge, re-rolling makes more sense. But if you carefully designed a military ship to have specific loadouts per-locker, for example, you'd want each copy identical. Not random locker contents.

Of course, maybe that's a moot point. If you want consistent copies, maybe use consistent parts. E.g. a military locker always has the same loot?

Or, maybe you never need to generate a copy of a ship? I sort of assumed you would, since there are going to be standard ship types in the system. Or put another way, I'm not going to hand-craft every ship in the universe in advance :) So yeah, we'll need re-rolled copies to be possible.

I dunno. There are definitely some questions to be answered here, and I might benefit from a bit of time to think on it. Fortunately, the weekend is here!

And speaking of which, Monday is a holiday here, so I'll be out of the office. Hope everyone has a good weekend, and see you Tuesday!


Rovlad's picture

I thought the whole point of unique IDs for every item/room cell/crew member was that you wouldn't have to rely on copies etc. from programming standpoint?
Well, I realize of course that some degree of copying is necessary by design, most programs being mostly a bunch of inheritable classes by their own and all that. I just thought UUIDs were supposed to mostly dissuade the problems you're describing.

matsy's picture

I guess the issue he is facing fundamentally comes down to trying to use a type id also as a instance id.

So if the ship is just defined as type ids when you create a new ship it will have the same ids. As the id is unique for data storage look up of that type but not new instances of it. So when you update one object it will update both instances as there is look up code to update objects of that id.

This is where he needs the instance id to identify which ship he should be updating and what fridge should be updated. As you May not want to update all the fridges of that type.

ra1's picture

What you could do is verbatim copy the ship, and then use a "randomize" process after the fact to scramble the contents of those objects which you wish to scramble.

dcfedor's picture

@Rovlad, the UIDs were meant to solve the problem of entities needing a way to refer to each other reliably, even if there are multiple instances of that entity type around.

In a running game, this is fairly trivial. You can literally assign a direct pointer or handle to the desired object anywhere you want. It just gets trickier when the game state has to be saved out to a text file and then later reconstructed from that text file.

With UIDs for each object, the save/load process actually works fine in this regard. I can use it both to save ship layouts, and to save whole game state. The trouble comes in when I need two ships based on the same layout.

E.g. The template might have something like "nav console ABC points to reactor DEF", and that's fine if I only make one ship from it. But if I wanted a second ship like that, I'd need a new console GHI to point to a new reactor JKL. And to do that, either I manually create an exact copy of the layout, or I write code to clone the layout into a new ship.

I thought I was cloning ships correctly, but instead, I end up with two ships both using console ABC and reactor DEF.

@matsy, close, but not exactly. Basically, there is only one instance of a loaded object, but two ships point to it. The side effect is pretty similar, regardless.

@ra1, that's what I'm thinking, too. Probably not unlike the NEO Scavenger modding system, where there's an ID remapping table to keep track of how the "old" copy was linked, and the "new" copy can have a parallel set of links just with different UIDs.

Dan Fedor - Founder, Blue Bottle Games