Finish up incomplete serialization work

[patowen]

I'm filing a separate issue from #397 for this to better track the work I have left for later while working on inventory code.

• Use the term PlayerId instead of Name when identifying player-controlled characters (as suggested in Load character entities from the save file #414 (comment))
• Move inactive players to a separate redb table so that they can remain unloaded
• Consider reorganizing Character and InactiveCharacter components to avoid needing duplicate logic to extract PlayerId from both (as suggested in Load character entities from the save file #414 (comment))
• Serialize player inventories when saving and loading (inventories are currently skipped in the save/load logic)

I plan to try to keep the below sections up-to-date to serve as a living design document that I or someone else will be able to reference while implementing the above.

Decision status

Disconnection vs deactivation

The concept of "player disconnecting" and "player character becoming inactive", while generally simultaneous, should not be baked in as fundamentally the same in the engine. Keeping them separate would allow for more options, such as a "battle royale" game mode, where disconnected players stand there doing nothing (like a sitting duck) to prevent cheating while also preventing disqualification from accidental disconnection.

Whether a player is active or inactive is included when serializing. Although all active players will be immediately logged out if a server is rebooted, we don't necessarily want to enforce that their characters should be deactivated as well.

Serialization of inactive characters

Each inactive player should have its own EntityNode-like data structure but keyed by their player ID instead of NodeId (in a different redb table from the EntityNodes in the graph). The inactive players can keep track of where they would be in if they were active (probably with a new component than the way position is tracked for active entities), but since they're inactive, they're not part of the Graph at all.

This way, they would only need to be stored in disk and never loaded into memory until they log on. An EntityNode that is part of the Graph will only contain active players, so with this idea, it would be safe to save changes to it without taking inactive players into account.

Deactivating entities not associated with players is not handled by the above logic if the key is PlayerId, but there is no clear use case for this, and we should be able to support it with some adjustments if it comes up.

Open questions

How to better represent characters in ECS

The current split between Character and InactiveCharacter is a little clunky. For instance, some existing code has to extract the name field from both for serialization.

I had expressed uncertainty about this in #414 (comment).

I'm hopeful that we will be able to bypass this issue completely and get rid of the InactiveCharacter component after we update the way InactiveCharacters are serialized to no longer be part of the Graph. Since there will be no clear reason we need inactive characters to be loaded into memory at all, we might not need to have any way to represent that active/inactive state.

[Ralith]

CharacterId

A more apt name for this might be PlayerId, since what we're really using this for is identifying the player who gets to control the entity.

[patowen]

A more apt name for this might be PlayerId, since what we're really using this for is identifying the player who gets to control the entity.

Oh, thinking about this again, I think there might be an even stronger reason for saying PlayerId instead of CharacterId.

It would probably be good ensure that the abstraction we choose is powerful enough to handle the possibility of a player trading characters with another player or a player having multiple characters in the same server.

Going this route, there is effectively both a "character identifier" and a "player identifier". Fortunately, with this line of reasoning, the "character identifier" can simply be EntityId, basically saying "this player controls that particular entity".