(longer term issue) instance lifecycle

[pshaughn]

What creates instances? Can an instance transition from one playset to another, and if so what objects make that decision? How should users interact with the concept of instances?

[pshaughn]

Here's one possible model:

• the main client.html goes to a hardcoded main instance; other instances are for debugging and testing, not production.
• the main instance is running a metagame playset, the state of which holds a little metagame information, a playset name, and a complete gamestate of that playest name.
• game states can mark themselves as requesting a transition-out; this does nothing if they're top-level, but if they're inside a metagame the metagame advances to the playlist item, starts a vote for next game, etc.

I am not sure I like this model; it's more the smallest delta from what I've already coded than it is something I'd come up with from scratch.

[pshaughn]

Here's a user story pointing at another model:

• When you connect, you enter an overworld in a 2d rpg-like environment. Near where you come in, there is furniture to edit your avatar, change account settings, and enter game lobbies. Further out, there are entrances to personal areas, and you can claim one or move your existing one to a new spot.
• You can edit your personal area, and the overworld near your personal area's claimed entrance. Your personal area can contains an entrance to your personal game lobby. You can manage an invite list for your personal area, and set it to invite-only. You can manage a blacklist for your personal area (kicking people who are in it or in your game lobby). The server will not forward communications within a personal area to users who aren't there.
• Admins can edit the entire overworld and all personal areas. Admins can cause more game lobbies to come into being off the overworld, or remove them.
• You can teleport to any personal area you're on the invite list for, and to the world entrance. From inside a game, this exits the game.
• If a game lobby is already playing a game when you enter, you either enter as an observer or spawn into the game, as determined by the game rules. If it's your personal game lobby, you can force the game to end and return to the vote screen.
• If a game lobby isn't already playing a game when you enter, you go to a vote screen. If it's your personal game lobby, you can set it to only give yourself a vote. A game countdown starts when there is a majority vote, or when there is a plurality vote large enough that no other one choice can beat it; if that condition stops being true during the countdown then it's canceled.
• During a game, you can vote to cancel the game, which happens immediately if there's a majority or if as the owner you choose to force it. This UI is game-independent.
• There's always a chat pane up. In personal territory, the same chat group is shared between game lobby and overworld personal area. In overworld, each game lobby has a chat group, and overworld-not-in-game-lobby has a chat group. Whispers are also allowed.
• If the server shuts down, games can just be abandoned entirely, as can the positions of players within the overworld. Persistent changes to overworld maps need to be kept, as do player avatar edits.

[pshaughn]

On further consideration, the above seems too heavy and monolithic. Better to take a simpler approach first.

[pshaughn]

What are the really important things?

• If I want to drop in on a game and don't care which, I can find one, assuming there are users on at all.
• If I want to play a specific game and so do other people, we can play it.
• If I drop in and people haven't decided on the game to play yet, we can talk it out and decide.
• I have an avatar that works across games.
• There can be persistent areas with room for player customization.

User story with this in mind:

• Create self-serve account.
• On first log in, go to avatar config. Subsequent logins go to a main lobby zone.
• Within a zone, the zone is responsible for its own controls. Many zones can share a control scheme. A zone can have exits to other zones, and those can connect to specific entrances of those zones.
• Generically exiting a zone via menu is always possible. This goes to the main lobby; if the zone being exited is enterable from the main lobby, then exiting goes there, otherwise it goes to the main lobby main entrance.
• Generically chatting within a zone is always possible, as is viewing the list of players in the zone. Whispering to a player in another zone is possible, as is checking if a player is logged on and getting their zone name.
• Some zones are games that reset between rounds, others aren't.
• On server reset, things in zones that don't reset between rounds mostly stay in place, as do player avatars.

[pshaughn]

Observations for what's needed to support the above user story:

• While logged in, a user is associated with one instance or special mode. Special modes are things like avatar editing and password changing that don't have an instance chat, game state, or input broadcast.
• An instance's state is replicated to associated clients, with rollback and prediction. This includes the instance-specific state and those portions of user state that the playset has an interest in.
• The serialize-game-state operation that's used for replication to clients is not the same one that's used for disk writes; a playset has a function to turn a game state into persistent data, rehydrate it from same, and initialize a new state in an absence of persistent data.. These latter functions don't have to be deterministic.
• Creating a new instance should be possible at runtime (for an admin).
• Editing a lobby-type instance's persistent map, including exits, should be possible at runtime (primarily for an admin, but claim-staking mechanics could exist too).
• When a user enters an instance, the user's entry and relevant state is replicated to associated clients.
• Exiting to another instance asks the instance whether it's actually legal to enter the new one; for example, a spaceship instance might not let you in if your spaceship avatar config is unset.
• Whenever a playset causes a change of user state, this affects the actual underlying states of users in server ram. Client RAM doesn't actually care about that fact; its sense of user state is limited to what the current instance cares about. The API by which user state is loaded and stored needs to be slightly clever.
• Time is lockstep across instances. An playset with no users may, knowing this about itself, reset to a neutral state and return without doing any heavy state updating, but that's technically up to the playset. All instances optimize performance-wise is that network packets other than point-to-point whispers won't be relayed across them.
• The default behavior of a playset is to have no exits to other instances defined in its game state, and not to respond to named entrance locations. For these things to exist, the playset needs to set them up, possibly informed by persistent state it rehydrates from. There seems to be no architectural reason they couldn't be dynamic at run time.

[pshaughn]

continuing from the above post, comparing them:

• There are still instances with names, and these names are still user-facing (you can query which instance another user is in, and you should be able to see your own instance name). Special modes also have names even though they don't have a playset.
• There are still playsets as distinct from instances; there might e.g. be a room in the overworld that has 6 distinct foosball tables, and the overworld itself might consist of several instances.
• The controller/user distinction is not important. A user is in a maximum of one place at a time. A game state has read/write access to its connected users in an ordered list; the client's awareness of these user states is subject to prediction and rollback, while the server's is kept only at past horizon and is persisted.
• For a user to successfully move from one instance to another, the server needs to let the user's disconnection from the first instance flush beyond the past horizon, then pass the user's state into the new instance. This means there are some frames during which the user is "between" instances from their own client's perspective.
• There is no reason why a playset needs be aware of an input "event" as a distinct entity; since the playset is aware of users, it can just be aware of input fields on the users. Similarly, commands can appear to the playset as fields on the users.
• Playsets can attach fields to users that won't persist, just by picking a name that isn't a name the playset has requested for persistence. It is important that this doesn't create namespace collisions; if soccer is using jerseynumber as non-persistent and writes to it, this shouldn't affect the persistent jerseynumber that basketball cares about. By attaching fields in this way, a playset can tell whether a user is newly connected without needing an event handler and set up their initial state. Since disconnecting players will vanish from the user list, attaching their sprite properties to their user list entry can set up a sprite to vanish when they disconnect without needing a disconnect event.
• Connects, commands, and disconnects still should be exposed to event handlers on the playset, even though they're not formally necessary.
• Persistence has a synchronous step of packing the users and the persistable parts of game states into resting data (not necessarily "immutable" at a data-type level, but not pointed to by anything that would mutate it), and an asynchronous step of writing all that data to disk. It seems reasonable to always write JSON for this, but to let in non-JSON Javascript literals with a warning (to make hand editing easier).
• When serializing a game state to send to a client, there's no need to force the serialization to a string data type. If the playset doesn't define a packer to network form, the game state could just be included directly in the object that forms the JSON message holding the state, instead of escaping it. This could make some debugging easier and potentially save a lot of network bytes (though not as many as defining a binary serialization protocol, of course).

[pshaughn]

It seems like it may be time to start code over almost from scratch! The existing proof-of-concept doesn't point in the right direction for some desirable behaviors, and the playset API has gotten a bit crufty due to past decisions.

[pshaughn]

ditch "commands" entirely, replace "input strings" with json-serializable input objects. ditch rate limits as a playset-independent concept, instead the playset can just validate an input object if it wants to

[pshaughn]

various rewrite considerations in progress now, things are shifting around away from the above and will need documentation when they settle