Offline/SinglePlayer mode

[dpogue]

It would be great to have an offline-capable version of the Plasma client to allow for much easier local testing of content by Age creators without needing to run their own local test shard or deal with SDL issues on public test shards.
I've been thinking recently about how to accomplish this, and have a few ideas to present.

Updates to existing code

plNetClientComm

In the UU/PotS days, almost all of the communication with the network went through methods on the plNetClientComm class. In MOUL, these were extracted into top-level functions outside of any class, leaving plNetClientComm as a shell that exists without much purpose.

I'm proposing moving those functions back into plNetClientComm in a 2-step process:

1. Add methods to plNetClientComm that call the existing global functions, to allow a gradual transition.
2. Move the implementation from the global functions into plNetClientComm and delete the global functions.

The plNetClientComm methods would be virtual, to allow a single-player subclass to override the implementation.

plVaultClient

Similarly, the Vault system was changed between UU/PotS and MOUL to use global functions rather than a class for access. I propose making a plVaultClient class and moving the functions into there as virtual methods, as described above for plNetClientComm.

TBD whether plVaultClient should exist as a member on plNetClientMgr, or as its own singleton.

plNetClientMgr

plNetClientMgr currently has a plNetClientComm member. I propose making that a pointer, so that it could point to either plNetClientComm or a single-player subclass.

Currently, some of the global functions that would move to plNetClientComm are called from the launch/login window, before plNetClientMgr is initialized. I'm proposing that we create the plNetClientComm instance in winmain.cpp as needed for patching/login, and then add a setter to plNetClientMgr to set its member to that instance when starting the client.

pfSinglePlayer

Create a new pfSinglePlayer module in FeatureLib to hold the implementation of the offline-related code.

pfOfflineDatabase

This would be a singleton class providing read/write access to a SQLite database containing the players table and Vault nodes/refs.

The database file would be stored in the existing per-user game data folder (%APPDATA%/Uru Live I think?), which would allow each user on a computer to have 5 single-player avatars.

pfSPClientComm

A single-player subclass of plNetClientComm that handles player lookups from pfOfflineDatabase and fakes message routing for offline functionality.

pfSPVaultClient

A single-player subclass of plVaultClient that performs all node lookups using pfOfflineDatabase.

CMake Configuration

Single-player functionality would be a build-time CMake option that defaults to OFF. This would probably remain OFF for client distributed with shards, but could be turned on for H'uru development builds on GitHub Actions.

It would be interesting to see if it's feasible to have a single-player only build option that would disable the network and skip the login dialog, but that's probably not necessary.

[Hoikas]

At one point, I was working to implement something similar to your plVaultClient. The delta quickly became huge and was difficult to make progress on due to the sheer volume of work required to get to a usable state. I feel like the best way to accomplish this goal would be to work as incrementally as possible, making the smallest changes possible. So, to my mind this leads to a different order of operations.

Global Functions

Most of the MOUL-era functionality, as you point out, is implemented as global functions. The problem with this, however, isn't that the vault itself is composed of global functions. Rather, that the vault is using global functions that assume a connection to the auth server is active. I think these could be fairly trivially abstracted away into a plVaultDatabase singleton with both a net and offline backend.

Offline Database

We already have a great tool in VaultShop, so I think the serialized vault format should be very similar to the one from TPotS so we can continue to use this excellent tool.

Migration toward offline mode

I would really like to allow a single build of the client to function in both online and offline mode so that Age creators can test both online and offline from the same install. As we are beginning to flesh out this offline mode, I think we would probably trigger offline mode via commands in the server.ini file or command line argument.

[dpogue]

We already have a great tool in VaultShop, so I think the serialized vault format should be very similar to the one from TPotS so we can continue to use this excellent tool.

Fair enough, I just don't know the details of how queries to that Vault file worked. Was the whole thing just loaded into memory at game launch and put it a nodeID-based lookup table?

I think we would probably trigger offline mode via commands in the server.ini file or command line argument

I was thinking a command-line flag, at least initially. I guess a console command would be fine, as long as it were handled before the client started and we didn't allow changing at runtime.