J'ai un jeu en ligne où les joueurs peuvent façonner le monde d'une manière ou d'une autre - par exemple. Le logement d'Ultima Online, où vous pouvez construire vos maisons directement sur certaines parties de la carte du monde. Ce sont des changements qui devraient persister au fil du temps dans le cadre d'un monde persistant.
Dans le même temps, l'équipe de conception ajoute du nouveau contenu et modifie l'ancien contenu pour améliorer et étendre le jeu aux nouveaux joueurs. Ils le feront d'abord sur un serveur de développement pendant les tests et devront ensuite fusionner leur travail avec le "travail" des joueurs sur le serveur en direct.
En supposant que nous résolvions les problèmes de conception de jeu - par exemple. les joueurs ne peuvent construire que dans des zones désignées, de sorte qu'ils ne se heurtent jamais géographiquement aux modifications du concepteur - quelles sont les bonnes façons de gérer les données ou d'organiser les structures de données afin d'éviter les conflits lorsque de nouvelles données de concepteur sont fusionnées avec de nouvelles données de joueur?
Exemple 1: un joueur fabrique un nouveau type d'objet et le jeu lui attribue l'ID 123456. Les instances de cet élément se réfèrent toutes à 123456. Imaginons maintenant que les concepteurs de jeux aient un système similaire et qu'un concepteur crée un nouvel élément également numéroté 123456. Comment éviter cela?
Exemple 2: quelqu'un crée un mod populaire qui donne à tous vos dragons un accent français. Il comprend un script avec un nouvel objet appelé assignFrenchAccent
qu'ils utilisent pour attribuer les nouveaux actifs vocaux à chaque objet dragon. Mais vous êtes sur le point de déployer votre DLC "Napoleon vs Smaug" qui a un objet du même nom - comment pouvez-vous le faire sans beaucoup de problèmes de service client?
J'ai pensé aux stratégies suivantes:
- Vous pouvez utiliser 2 fichiers / répertoires / bases de données distincts, mais vos opérations de lecture sont alors considérablement compliquées. "Afficher tous les éléments" doit effectuer une lecture sur la base de données du concepteur et une lecture sur la base de données du lecteur (et doit toujours faire la distinction entre les 2, d'une manière ou d'une autre.)
- Vous pouvez utiliser 2 espaces de noms différents dans un même magasin, par exemple. utiliser des chaînes comme clé primaire et les préfixer avec "DESIGN:" ou "PLAYER:", mais la création de ces espaces de noms peut être non triviale et les dépendances ne sont pas claires. (par exemple. Dans un SGBDR, il se peut que vous ne puissiez pas utiliser efficacement des chaînes comme clés primaires. Vous pouvez utiliser des entiers et allouer toutes les clés primaires en dessous d'un certain nombre, par exemple 1 million, pour être des données de concepteur, et tout ce qui est au-dessus de ce point doit être Mais ces informations sont invisibles pour le SGBDR et les liens de clé étrangère traverseront le «fossé», ce qui signifie que tous les outils et scripts doivent explicitement contourner ce problème.)
- Vous pouvez toujours travailler sur la même base de données partagée en temps réel, mais les performances peuvent être médiocres et le risque de dommages aux données du joueur peut être amélioré. Il ne s'étend pas non plus aux jeux qui s'exécutent sur plus d'un serveur avec des données mondiales différentes.
- ... d'autres idées?
Il me semble que même si c'est principalement un problème pour les jeux en ligne, les concepts peuvent également s'appliquer au modding, où la communauté crée des mods en même temps que les développeurs corrigent leur jeu. Des stratégies sont-elles utilisées ici pour réduire les risques de rupture de mod lorsque de nouveaux correctifs sortent?
J'ai également étiqueté cela comme "contrôle de version" car à un niveau c'est ce que c'est - 2 branches de développement de données qui doivent être fusionnées. Peut-être que certaines idées pourraient venir de cette direction.
EDIT - quelques exemples ajoutés ci-dessus pour aider à clarifier le problème. Je commence à penser que le problème est vraiment celui de l'espace de noms, qui pourrait être implémenté dans un magasin via des clés composites. Cela simplifie au moins la stratégie de fusion. Mais il y a peut-être des alternatives que je ne vois pas.