Skip to main content

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

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.