Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

P.S. Next "hmm, wonder if I can...?": Port my favorite slaves of my current game into a fresh game via manipulating save files.  I've put a lot of work into a handful and would prefer not to just abandon them...

Yes, it is possible to move slaves between progresses, but there are a few data points to be careful of duplicates. Newly generated persons are simply assigned an ID number from a the counter "globals.state.slavecounter", which then increments. Some functions search for slaves by ID, which would only be capable of finding the first slave in the list with that ID. There is also the 'unique' data which identifies starting slaves and quest slaves, which could have similar problems. Finally, any relations data or data involving interactions with other slaves would be incorrect.

Hmm, interesting.

So the fact that the ID is so high is because I caught and sold a bunch of slaves in between finding ones I liked.

Does the unique ID stay with sold slaves (until they presumably vanish from the market), or are they given a new ID when you buy them back?  I've been using a sell-and-buyback strategy to get Mansion Upgrade points and a brand.

If selling slaves gets them out of the pool but maintains a higher slave counter, would it be possible to change my preferred slaves to the IDs e.g. 12, 13, 14, 15?  I could either ignore the relations/interactions data, or figure out how to swap a few numbers around.

I wouldn't be messing with the unique/quest slaves, yeah.  I pretty much always use the same starting slave specs anyway (I found a nice setup that works with my overall story concept, and gives me a neat pun, so it'll be a while before I tire of that specific character).

The ID increments any time a person is generated, so every step of your exploration that generates an encounter with persons in it increases the counter even if you choose to ignore or evade the encounter. The ID and 'unique' data stay the same for a person for their entire existence until they are deleted. This means that even if you sell and re-buy someone they maintain all their relations and relatives data with other persons. I mention the 'unique' data entry because some people like the idea of having multiple custom starting slaves.

A safe approach is to change a transferring slave's ID to be the current value of "globals.state.slavecounter" and then increment that value manually. It may also be safe to change IDs to be negative for transfers, though I haven't checked this thoroughly. However, if you are moving multiple slaves and want them to maintain a friendship, rivalry, or family status, then the corresponding ID values have to be changed to match the new IDs. The rest of that data should be deleted or not transferred to the new progress otherwise a transferring slave may have some preconceptions about slaves they have never met before.

Hmmm.  Sounds like suboptimal code, the idea that characters get created before the game knows whether they even matter (whether the player will in any way get to see the details).  It would make more sense to say "There's two bandits over there, do you want to engage?" and then, if you engage, generating characters.  This problem would be even worse for those giant packs of bandits I've seen (but not yet engaged with).

Actually, optimal code would likely generate a full character only upon capture, and generate a partial (necessary stats only) character for combat, then generate the next partial bit at the end of combat (when you get to see a few new stats), and finally transferring the partial character into a fresh full character if you capture them.

It's good to know that the uniqueness sticks around even if you sell them, though.  That does avoid some issues.

Indeed, fortunately these sorts of sub-optimal code are rarely a significant problem in a game without real time events.