[Bot]

Bonjour,

J’ai trois questions par rapport à mon architecture pour un serveur de jeu multiplayer state-sync dans le cadre d’un jeu de cartes. Le langage est typescript.

J’ai deux objets centraux : l’objet World qui est l’objet qui produit la simulation et l’objet State pour l’échange et la sérialisation de l’état de mon jeu. Le but n’est pas de manipuler directement State, mais simplement de l’utiliser pour calculer le delta et pour garder l’état envoyé (snapshot). World est mutable tandis que State serait immutable. Dans cet architecture, je fais l’impasse sur les dirty flags et préfère garder des snapshots.

Mon protocole de communication est binaire sur websocket.

Est-ce qu’il vaut mieux organiser l’object State en Entity ou Property ?
– Entity : utilisation des objets javascript (ou un identifiant unique) comme clé pour l’état interne de State
Question annexe : identité de l’objet vs identifiant unique
– Property : utilisation du chemin de propriétés comme clé pour l’état interne de State
Dans les deux cas la table des propriétés existantes sera fixe et non dynamique (structure figée).

Dans les deux cas j’ai prévu d’avoir l’état interne sous forme de tableau plutôt qu’un objet dynamique complexe qui conserve la hiérarchie de l’objet World, est ce une bonne décisions ?
– L’objet State ne sera jamais manipulé directement, seulement le World.

Est-ce mieux de gérer l’état interne de State avec un objet ou directement avec un buffer ?
– Dans les deux cas je peux copier facilement l’état via stucturedClone ou slice.

Note : la simulation sera à 5 Hz voire moins.

——————–
xenohim – Envoyé depuis le Discord : Culte du code

Sujet

[Bot]

Sans forcément répondre à mes questions, si vous avez de déjà fait un serveur multiplayer.

——————–
xenohim – Envoyé depuis le Discord : Culte du code

[Auteur]

Réponses