J'ai vu beaucoup de jeux qui définissent les composants d'entité dans des fichiers de script, mais lorsqu'ils configurent chaque entité et spécifient quels composants elle possède, ils utilisent un autre format de fichier (comme XML). Pourquoi font-ils ça?
Je demande surtout à voir quelle était la justification des autres pour cela. Je configure également mes entités en dehors des scripts (même si j'ai choisi JSON et non XML). Mes raisons pour cela sont de me faciliter l'implémentation des sauvegardes et aussi parce que je pense que ce type de configuration est mieux organisé en quelque chose comme XML ou JSON.
@ Réponse de Christopher Larsen: Trop long pour poster un commentaire
Je crains que vous ne vous soyez un peu écarté du sujet de la question. Les problèmes que vous décrivez sont davantage liés aux entités basées sur la hiérarchie; note dans ma question, j'ai mentionné que je parlais d'entités basées sur les composants.
Voici un exemple de ce que je voulais demander. Vous trouverez ci-dessous deux façons alternatives de configurer une entité: via le script et via un fichier JSON externe. Ma question était, pourquoi tant de gens préfèrent-ils configurer l'entité en dehors des scripts?
Une classe d'entité de base:
class Entity:
def __init__(self, name):
pass
def addComponent(self, comp):
passL'approche script:
orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))L'approche JSON:
{
"name" : "Orc",
"components":
{
"PositionComponent": {
"x" : 3.4,
"y" : 7.9
}
}
}J'ai déjà indiqué mes raisons pour utiliser cette approche, qui sont techniques et organisationnelles. Je voulais savoir pourquoi tant d'autres (d'après ce que j'ai vu) utilisent cela.
la source
L'une des raisons pour lesquelles j'utilise généralement un fichier de configuration plutôt qu'un script pour cela est:
La seule façon de vérifier l'exactitude d'un script, par exemple en spécifiant toutes les valeurs, est de l'exécuter.
Écrire du code pour permettre aux scripts de configurer les valeurs signifie écrire du code pour créer des objets squelettes pour que les scripts remplissent les valeurs, puis valider que le script a fait telle ou telle chose. C'est plus de code et de code plus bogue que de charger à partir d'un fichier de configuration plat, en utilisant souvent une bibliothèque qui prend en charge une sorte de mécanisme de validation.
la source
La configuration d'entité peut être simplement une sérialisation d'une entité spécifique. Cela vous permet de gérer la sortie des outils d'édition et de modification de jeu à peu près de la même manière que pour une sauvegarde. En particulier, pour les jeux où vous ne pouvez pas prédire dans quel état une entité donnée sera pendant la sauvegarde du jeu - par exemple à cause de leur IA ou parce qu'ils sont générés partiellement de manière procédurale en premier lieu - il est utile de pouvoir vider l'ensemble des données définissant ce qu'une entité "est" (par opposition à ce qu'elle "fait") en tant que flux d'octets à enregistrer.
la source
Le modèle que vous décrivez est une implémentation d'un système piloté par les données.
Les systèmes pilotés par les données sont couramment utilisés dans le développement de jeux car ils permettent de définir le contenu à encapsuler à l'extérieur de la source. Cette représentation externe peut ensuite être facilement modifiée (et même mise à jour en temps réel par une application surveillant les modifications) pour changer le comportement d'une entité.
Une fois que les données sont définies en externe, vous avez toutes sortes de possibilités dans la façon dont les concepteurs interagissent avec elles, allant de l'édition directe de fichiers texte (ugh!) À des interfaces utilisateur sophistiquées qui guident les choix du concepteur de manière logique, cohérente et même vérifiée pour l'exactitude (de la perspective de l'équilibre du jeu).
Si les données étaient intégrées directement dans le code, toute modification nécessiterait une reconstruction de l'application qui, pour les grands projets, prend un temps modéré ainsi que le temps requis pour le déploiement des binaires (par exemple, de nouveaux binaires doivent être déployés et installés sur le serveur).
Prenons un exemple d'entité stéréotypée "l'orc" ...
Une façon de mettre en œuvre notre orc serait d'écrire une description complète en code de toutes les caractéristiques et de la logique de l'orc.
Lorsque nous instancions des orcs, toutes leurs valeurs sont initialisées exactement de la même manière (ou sont peut-être statiques). Le problème qui se pose est qu'un concepteur va venir et dire "Nous avons besoin d'un type d'orc différent pour les zones de débutant, qui a moins de santé, ne s'enfuit jamais et n'est pas agressif. Cela permettra aux nouveaux joueurs de s'habituer au combat sans difficulté et confusion accrues lors de l'apprentissage du système de combat ".
Très bien, maintenant vous avez besoin d'une classe différente ou (peut-être que nous étions tournés vers l'avenir) ajustez les valeurs que nous introduisons dans la «fabrique» qui crée des orcs lors de leur création dans une zone «débutant». Nous faisons donc les changements, déployons de nouveaux binaires. Seulement pour que les testeurs reviennent et disent que les nouvelles valeurs de santé sont trop faibles alors que nous tuons les orcs en un coup.
Si nos systèmes étaient pilotés par les données (et des points bonus pour les applications qui prennent en charge le rechargement lorsque des modifications sont apportées), alors les modifications nécessaires pour satisfaire le concepteur et les testeurs de jeu sont de simples changements de données sans recompilation / déploiement requis. Cela rend les concepteurs heureux car ils ne sont pas coincés à attendre les changements de code, et cela rend les programmeurs heureux parce que nous modifions constamment le code source pour ajuster les valeurs.
Amener les systèmes pilotés par les données à l'extrême permet de tout mettre en œuvre, des niveaux de jeu, des sorts et même des quêtes, en modifiant simplement vos données sans aucune modification de code. En fin de compte, il s'agit de faciliter la création, le réglage et l'itération du contenu du jeu.
la source
Dans votre exemple, vous utilisez déjà deux langages de script. C'est la façon dont je dirais qu'à long terme fonctionne mieux, mais je vous suggère d'unifier le langage de script que vous utilisez. Si l'exemple de script que vous avez donné a été fait dans Lua, au lieu de Json, je dirais utiliser les tables de Lua pour construire votre objet. La syntaxe serait en fait similaire et vous permettrait de prendre en charge une seule interface pour exposer vos composants.
Pour expliquer pourquoi les gens choisissent de le faire habituellement en XML, puis en script en logique, c'est que cela a du sens lorsque vous le dites. Voici ma définition de l'objet dans les données, qu'est-ce qu'un bon format de stockage de données? C'est presque toujours XML (bien que j'utilise également JSON;). Et puis quand ils veulent ajouter de la logique, eh bien c'est soit codé, soit mis dans un fichier script.
Ce n'est pas une mauvaise pensée, mais à mes yeux, les gens ne vont tout simplement pas à l'étape suivante. Regardez n'importe quel langage complet, c / c ++ / c # ,. Vous pouvez définir les objets et leur logique dans un seul langage, pourquoi ne pas faire de même dans votre interface de script ... C'est presque comme dire que l'on devrait définir nos classes en XML et nos méthodes en c # quand on y pense. Peut-être que les anciens langages de script de jeu n'étaient pas assez puissants et ils se maintiennent toujours comme ils l'ont fait.
la source