Quantum Game Initialization

The following is an excerpt from a conversation between Artūras Šlajus (arturaz), Erick Passos (erickpassos) and Fredrik Holmström (fholm):

arturaz

I'm gonna lay out how I think Quantum works now, correct me if I'm wrong.

You start a Quantum session, you give it a maximum number of players. If mode is local, quantum does not do any networking, if mode is multiplayer - it uses photon to communicate between other quantum instances. I am not sure how it identifies the other Quantum instances, but I imagine it uses the Photon room you're in. Not sure what replay does.

Once quantum is running, the Frame.playerCount is ## to maximum player count you gave Quantum.

If you are in local mode, all players are immediately connected and f.GetPlayerInputFlags(idx) will return Repeatable. If you are in multiplayer mode, until a player connects to the room and starts his quantum session, player input flags will return PlayerNotPresent. After connecting it will start returning Repeatable or ReplacedByServer for that player.

I am not sure what assigns photon clients quantum player ids and is it possible for quantum player id to become free once it has been assigned. I would guess that it is always locked to allow a player to reconnect to same slot in case his connection drops. Not sure if there is leave functionality.

Now after being connected, the player is always free to send quantum.SetPlayerData(quantumIdx, player); which can happen any time during the session. As I see it, it's just an RPC method, which uses the underlying synchronized RPC mechanism, which you have said will expose to us later in development as well.

am I remotely right? :smiley:

erickpassos

You're about right.

About ID assignment... If you look carefully, there's a GUID that each client sends... this is used to "hold" assigned player indexes, so in the case that client reconnects, same indexes will be reassigned to him

The server callbacks will let you overhaul that behavior...

You can also control to some extend from the basic photon room functions... For example, to lock a room only for reconnects, keep it OPEN, but make it VISIBLE = false

So no NEW client will connect to it, and it will be still available for one that needs to reconnect

That is interesting because it doesn't require a CUSTOM plugin (you can close, make invisible from the client who created the match)

But again, you can also have control of who's allowed to join the deterministic session from the server with the new server callbacks (We'll release a custom quantum server plugin project with 1.2.1)

I have it here running for a few days already, server side sim and all...

It is possible to call SetPlayerData multiple times AND there's a server callback if you want to control that..:)

You were basically spot on, I'm just explaining what kind of control you have over all this

Cool example:

• buy this item sent from client... server intercepts and don't let it go to clients...
• server uses that info to call backend server;
• when backend answers, server code injects SetPlayerData with the bought item...

arturaz

Question: if I want to pass stuff to quantum upon session start, should I use runtime config?

I see runtime config is being serialized. However all clients run it locally, why does it need to be serialized?

erickpassos

yes

it's serialized, sent to server on session join (server uses the first one), all other receive this one from server and deserialize

fholm

for a lot of games (competitive, etc.) you want to send both RuntimeConfig and RuntimePlayer from the server/plugin, which you can do now

and not let the players assign slots themselves ro send data up, etc.