Pourquoi est-il mauvais de coder en dur le contenu?

41

Je sais que la plupart des jeux stockent du texte de dialogue dans des fichiers, mais j'ai également vu quelques jeux à base de texte programmer le contenu (carte, choix, commandes de lecteur possibles, texte d'histoire) dans le code du jeu.

Je peux penser à plusieurs raisons, mais quelle est la principale raison pour laquelle même les jeux de texte conservent tout dans des fichiers en dehors du programme?

Les détails de la mise en œuvre diffèrent peu entre la conservation du contenu dans quelque chose comme le format XML populaire, son analyse, puis le rendu des mappes / l'affichage de texte en fonction des variables créées à partir d'un fichier XML et le simple fait de renoncer au fichier XML. Tous deux se retrouvent avec des chaînes qui sortent à l'écran. La différence n'est-elle pas juste une notation?

Certains jeux contiennent même les graphiques (art ASCII?) À l'intérieur du code. Je sais que ce n'est pas correct et je peux deviner quelques raisons pour lesquelles c'est mauvais, mais je ne sais pas pourquoi.

Il est très populaire d’avoir la plupart du contenu en dehors du programme. Même la forteresse naine n'utilise pas les caractères ASCII réels, mais les images de caractères ASCII chargées en mémoire.

Je demande principalement parce que c’est un peu un PITA pour créer, analyser et travailler avec des fichiers XML. Vous savez ... comparé à l'alternative paresseuse consistant à faire de chaque donjon (contenu) unique sa propre classe.

utilisateur50286
la source
9
Les jeux basés sur du texte codent beaucoup de contenu, mais je pense que c'est simplement à cause de l'époque où ils ont été développés et de leurs choix de conception médiocres. La même chose pourrait s'appliquer à la forteresse naine. J'ai personnellement pris tous mes jeux à base de texte et déplacé le contenu en dehors de la source dans une base de données. Cela m'a rendu la vie tellement plus facile.
Glen Swan
7
i18n serait très difficile à faire avec du contenu intégré dans la source.
Pllee
5
Pas si sûr que ce soit spécifique au développement de jeux. À l'avenir, envisagez de demander aux programmeurs SE ou stackoverflow.
MichaelHouse
13
just making every unique dungeon (content) its own class.Cela m'a fait frissonner. La séparation des données de la logique est un principe tellement fondamental pour moi que je suis surpris qu'il y ait encore des développeurs qui la violent.
Lilienthal
4
Quoi que vous décidiez, sachez que le contenu codé en dur permet de gérer beaucoup plus de cas particuliers. Vous voulez qu'un certain patron n'apparaisse qu'entre minuit et 7 heures (en temps réel)? Il est beaucoup plus facile de coder en dur que de créer un moyen générique pour que les monstres n'apparaissent qu'à certains moments.
user253751

Réponses:

85

Il y a plusieurs raisons à cela. Je vais juste en aborder quelques unes:

  1. Cela rend votre code source un désordre. Si vous avez beaucoup de dialogues (arbres), une grande partie de votre base de code est juste un texte qui n’a rien à voir avec votre code de jeu réel.
  2. Vous auriez besoin de recompiler chaque fois que vous changez autant qu'un seul caractère.
  3. Le dialogue lui-même est difficile à naviguer. J'imagine qu'essayer d'implémenter tout un arbre de dialogue, et encore moins plusieurs, complètement à l'intérieur de votre source entraînera un désordre imbriqué de spaghettis et des éléments imbriqués if, switchetc. Il en résulte un code sujet à des erreurs, difficile à lire et à déboguer.
  4. Si vous voulez permettre aux gens de modifier ou d’élargir votre jeu, c’est beaucoup plus facile s’ils n’ont pas à gérer le code source pour changer quelque chose.
  5. Le point ci-dessus est encore plus important si vous travaillez en équipe. Vous ne voulez pas que votre auteur doive manipuler le code simplement pour entrer dans un morceau de dialogue.
  6. L'analyse de XML ou d'autres formats de fichiers standard est assez facile à utiliser si vous utilisez des bibliothèques existantes. Son coût de mise en œuvre de cette manière est très économique, tout en vous offrant de nombreux avantages et en évitant les problèmes mentionnés ci-dessus, et bien plus encore.
  7. Comme @MiloPrice l'a souligné ci-dessous, il est également beaucoup plus facile de localiser le jeu si votre texte est dans des fichiers externes. Vous pouvez ajouter une langue en ajoutant un fichier, votre équipe peut s'occuper de la traduction sans avoir à toucher au source (ce qui est particulièrement important si vous laissez des personnes traduire qui ne sont pas censées voir tout votre code - pensez aux pigistes, communauté qui n'appartient pas à votre équipe, etc.).
Christian
la source
10
Je ne dirais pas que cela ferait de votre code un gâchis. Sinon, contenu ou non, tout peut être considéré comme un gâchis en bloc. Vous pouvez structurer le contenu dans une bonne structure, tout comme le code. Mais le reste des points reste solide.
Glen Swan
28
La facilité de localisation / traduction est un autre gros avantage.
Milo P
2
@Christian: Vous pouvez avoir un programme piloté par les données dans lequel les données sont incorporées dans un format où elles sont directement utilisables sur place (par exemple en C ou C ++, grandes constbaies avec une durée de stockage statique). Cela vous évite tout le code et le coût en mémoire d'exécution du chargement / conversion d'une représentation de données externe au moment de l'exécution. Bien entendu, toutes vos autres raisons de conserver des données externes s'appliquent également.
R ..
2
Personnellement, je suis favorable à une approche encore plus forte pour les mêmes raisons que celles énumérées ici: Déplacez également la majeure partie de votre code dans un langage de script. Construisez un noyau en C / C ++, intégrez un langage comme Python ou Lua et exportez-y une API. Don't Starvesuit cette approche et c'est l'un des jeux les mieux écrits que j'ai vus. De nombreux autres jeux passés et présents le font également, ainsi que des applications (et rarement des utilitaires). Je dirais que dans l'ensemble, en dehors des petits projets et des petits utilitaires, la superposition en couches et la séparation sont toujours vos amis.
mechalynx
30

Le fait de mettre les données du contenu du jeu dans le code signifie que pour voir tout changement ou itération potentiel de ces données, vous devez recompiler le jeu lui-même. C'est mauvais pour deux raisons:

  • De nombreux langages dans lesquels les jeux sont écrits ont de longs temps de compilation. C ++ est particulier peut être très mauvais à cet égard, et C ++ est un langage très commun pour les grands jeux commerciaux. C’est moins un problème avec des langages tels que C # et Java, mais pas aussi rapide que de pouvoir stocker des données de jeu dans des fichiers externes qui peuvent être rechargés à chaud pendant que le jeu est en cours d’exécution pour voir les changements.

  • De nombreux jeux sont développés par des équipes composées souvent de développeurs non techniques (concepteurs et artistes) produisant du contenu. Non seulement les non-techniciens ne veulent pas avoir à recompiler le jeu, ni à faire face à des "outils de programmation fastidieux", pour itérer sur leur contenu, il peut être souhaitable de minimiser l'exposition du code source aux seuls programmeurs (parce que moins de personnes avoir accès au code source, moins il y a de personnes qui peuvent le divulguer - accidentellement ou non).

Je pense que vous surestimez la complexité du chargement de données à partir de fichiers texte ou XML. La plupart du temps, vous devriez utiliser une bibliothèque pour ce faire, ce qui facilite beaucoup le processus d’analyse XML / JSON /. Oui, l'écriture d'un système de chargement par niveaux basé sur les données représente un peu des coûts initiaux, mais cela vous fera généralement gagner beaucoup de temps à long terme par rapport à des tonnes de classes uniques représentant chaque niveau.

Des jeux plus petits ou plus simples n’auront peut-être pas autant à gagner de l’investissement à long terme d’une approche basée sur les données. Par conséquent, à moins que les développeurs n’utilisent les frameworks / moteurs existants qui les prennent en charge, il sera peut-être plus efficace de simplement coder les données. le code du jeu.

Il y a bien sûr une foule de raisons pour lesquelles un jeu donné peut choisir de mettre ses données dans des fichiers externes (ou non); il n'est pas possible de toutes les énumérer. À un certain niveau, ils se résument généralement à la vitesse d'itération supplémentaire ou à la flexibilité que peut offrir l'absence de reconstruction du jeu.

Josh
la source
Je ne pense pas que les temps de compilation soient vraiment importants, mais en tant que développeur, nous nous efforçons toujours d'obtenir du "code soigné" ... c'est une très bonne raison de séparer les choses en elles-mêmes ... le contenu devrait être du contenu, pas du code!
Guerre le
4
@Wardy Les temps de compilation sont vraiment importants en C ++. J'ai travaillé avec des solutions qui ont nécessité plus de 15 minutes de création, en raison de la taille du projet, de l'utilisation agressive de modèles ou même de la paresse des développeurs (y compris les en-têtes inutiles). Et je suis sûr que c'est le cas avec d'énormes jeux commerciaux.
concept3d
1
@ concept3d: Je souhaite que mon projet dure 15 minutes. Une nouvelle génération sur un serveur de génération dédié prend environ 50 minutes.
Mooing Duck
moins il y a de personnes qui ont accès au code source, moins il y aura de lésions cérébrales causées par le C ++. : P
Sarge Borsch
Je pense que certaines personnes risquent de manquer le point d'une relance à chaud - personne ne s'en soucie s'il faut 30 secondes pour recompiler le jeu, les artistes ne veulent pas recommencer le jeu, ils veulent un raccourci clavier pour pouvoir tester différentes animations. et textures à la volée. En fait, c'est l'une des choses qu'ils veulent le plus. Voir l’aspect extérieur du jeu est une chose, mais ce qui compte, c’est de les voir jouer.
Wolfdawn
7

Comme toujours, comme toujours, cela dépend. Mais d’abord, je voudrais dire que le codage dur n’est pas mauvais en soi.

J'ai du contenu codé en dur, en particulier du texte de dialogue, dans certains jeux simples, et le monde ne s'est pas terminé. Nous, les programmeurs, adorons résumer les choses, mais rappelez-vous que chaque couche d’abstraction que vous créez rendra votre programme plus complexe et plus difficile à comprendre.

Si votre jeu est assez simple pour que vous puissiez coder en dur un contenu, je le considérerais certainement pour des raisons de simplicité.

Ceci, cependant, n’a pas vraiment d’échelle. La raison la plus courante de placer du contenu dans des ressources externes est certainement de simplifier le travail d’équipe, car une personne ou une équipe peut se consacrer à la rédaction du jeu, tandis qu’une autre peut se concentrer sur la création et le polissage du contenu.

Toutefois, tracer une ligne de démarcation entre le programme et le contenu n’est pas toujours trivial. On pourrait dire que les textures sont à 100% de contenu; mais qu'en est-il des textures générées procéduralement? Le texte du dialogue peut être considéré comme contenu à 100%; mais qu'en est-il lorsque le dialogue change en fonction de vos actions précédentes? D'autres éléments que l'on peut considérer comme faisant à 100% partie du programme, tels que les scripts ou les shaders, pourraient également être considérés comme faisant partie du contenu du jeu. Devraient-ils être codés en dur? doivent-ils être chargés en tant que ressource externe?

Rappelez-vous cependant que chaque type de contenu que vous supportez dans votre jeu doit être associé à un code de chargement et d'interprétation. Par conséquent, en cas de doute, je vous recommanderais de coder en dur le contenu et de ne le transmettre à une ressource externe que lorsque vraiment besoin de cette flexibilité (pas quand vous pensez peut-être besoin, mais quand vous en avez réellement)

Enfin, l’un des avantages du stockage des données dans les fichiers de ressources est que vous ne pouvez les charger que lorsque vous en avez besoin (donc accélérer le chargement des jeux), et les décharger lorsque vous n’en avez plus besoin (vous permettant ainsi d’avoir plus de contenu). que peut tenir dans la mémoire). (Le coin Nitpickers: les DLL de ressources pourraient sans doute être considérées comme des ressources externes)

Pyjama panda
la source
7
"Mais souvenez-vous que chaque couche d'abstraction que vous ferez rendra votre programme plus complexe et plus difficile à comprendre." Je ne serais pas d'accord, l'abstraction peut simplifier un programme et devrait certainement le rendre plus facile à comprendre.
NPSF3000
1
Les abstractions @ NPSF3000 vont ajouter de la complexité, mais peuvent en éliminer plus qu'elles ne le font.
user253751
2
@immibis, la somme totale de la complexité d'un projet après la mise en œuvre d'une abstraction doit donc être inférieure à la précédente.
NPSF3000
3
@ NPSF3000: Mon point est que vous ne devriez pas créer d'abstractions simplement parce que vous le pouvez. Parfois, les données codées en dur sont plus simples, plus compréhensibles et plus faciles. Plus souvent qu'autrement, j'ai vu des jeux s'engager dans la voie du codage logiciel , ce que je trouve regrettable. N'oubliez pas non plus que l'ajout d'abstractions est toujours plus facile que de les supprimer. Je suis donc un ardent défenseur de l'ajout d'abstractions uniquement lorsque vous en avez besoin.
Panda Pyjama
@PandaPajama faire quelque chose 'simplement parce que vous le pouvez' est susceptible de causer un problème, peu importe ce que c'est. Cela ne signifie pas que ce quelque chose est intrinsèquement complexe, ce qui était mon sujet de préoccupation. Aussi, pourquoi pensez-vous qu'il est plus facile d'ajouter des abstractions que de les supprimer? De prime abord, je penserais autrement - ajouter une abstraction tardivement peut signifier une refactorisation importante, mais je ne peux pas penser immédiatement à un cas où la suppression d'une abstraction inutile serait complexe. Passer de XML à des chaînes codées en dur devrait être simple.
NPSF3000
3

La réutilisation est une raison importante pour stocker dans des fichiers texte. La création d'une structure de jeu de texte qui lit vos cartes, votre boîte de dialogue et d'autres ressources à partir d'un fichier texte vous permet de réutiliser votre structure pour d'autres jeux. Aller au-delà des jeux de texte, voilà comment des titres à gros budget comme Call of Duty lancent un nouveau jeu chaque année.

Une autre raison est la portabilité. Vous pouvez utiliser les mêmes fichiers pour le Web, les ordinateurs personnels, les ordinateurs Mac, les ordinateurs Android, etc.

Lorsque vous allez au-delà des jeux basés sur du texte, un script et des données stockées dans des fichiers réduisent les temps de recompilation et vous permettent de créer une interface facilitant la manipulation des données.

Ted Wagner
la source
1
Bien sûr, avoir la plupart des éléments réutilisables vous oblige à éviter de faire quelque chose de "spécial", en dehors des règles que vous avez déjà. Je ne préconise certainement pas les gros jeux codés en dur, mais cela est extrêmement utile lorsque vous prototypez ou écrivez des jeux expérimentaux - cela vous donne beaucoup plus de flexibilité. Bien sûr, cela vient avec un prix, donc c'est généralement une bonne idée de tout reformuler une fois que le gameplay fonctionne réellement. Le gameplay est la partie la plus difficile. Assurez-vous de pouvoir le tester sans vous plonger dans un enfer architectural: D Il est généralement plus facile de trouver la forme générale après avoir obtenu les bétons.
Luaan
3

Afin d'accélérer les changements, il accélère le développement de tonnes de grandes productions.

Vous n'avez pas besoin d'apprendre à tout le monde à apprendre à entrer et à modifier le code source pour effectuer des modifications simples. En le faisant glisser hors du code réel, plus de gens ont la chance de s'amuser, il est plus facile de savoir quelles options vous pouvez jouer et le processus entier d'optimisation de diverses parties de votre jeu prend beaucoup moins de temps. Même les questions-réponses peuvent aider à cela.

John Cobalt
la source
3

Je ne peux pas croire que personne ne l’ait mentionné pour le moment, mais une grande raison est de rendre la localisation beaucoup plus facile. Si vous avez besoin de supporter l'anglais, le français, l'allemand, l'espagnol, le portugais, l'italien, le russe, le chinois et toute autre langue que vous visez, codé en dur, vous devez disposer d'un code séparé pour chaque langue. Cela signifie également que si vous devez supprimer certains contenus (lire: censure), vous devez modifier votre code lui-même pour l'éviter, au lieu de dire "remplacez simplement ce mini-jeu de sondage anal par cette bannière passive-agressive qui explique graphiquement ce qui se passe. ". C'est également plutôt hostile pour les consommateurs, car il est probable qu'ils devront redémarrer le jeu pour changer de langue, car vous devez charger d'autres bibliothèques. Finalement,

D'autre part, si vous utilisez des ressources externes, prendre en charge différentes langues signifie simplement charger un fichier de ressources différent. Cela peut facilement être fait pendant que le jeu est en cours d'exécution. cela signifie que vous pouvez avoir une seule base de code, ce qui simplifie grandement le développement. Et cela signifie également que vous pouvez facilement ajouter une prise en charge après publication pour d'autres langues. Enfin, cela signifie que vous pouvez laisser l’utilisateur désactiver l’installation de certaines langues (une fonctionnalité qui n’arrive pas souvent dans les jeux, mais qui est toujours possible) pour économiser l’espace disque et la bande passante.

Nzall
la source
3

Je pense qu'une phrase clé est la séparation des préoccupations .

Si votre code n'inclut pas le texte, il sera moins complexe. Le programmeur qui écrit le code n'a pas à penser au texte spécifique et peut se concentrer sur le code.

Il n'a pas à penser à la localisation. La personne qui effectue la localisation n'a pas à s'inquiéter du code.

Christian
la source
3

Je pense qu'il est trop facile d'être le gars "flou que blanc" et recommande vivement d'utiliser un fichier de ressources texte externe.

Pourquoi? Parce que vous avez le choix entre équilibrer les coûts, les problèmes et les avantages de chaque solution.

Lorsque vous utilisez un fichier externe ... Eh bien, je suppose que les autres réponses expliquent assez bien les avantages. Mais qu'en est-il des coûts? Vous devez définir un formalisme valide, créer un interpréteur, vous mettre d'accord sur un format de fichier et, pire encore, créer une autre application (un éditeur). Ce qui est un problème de 0,00% si vous êtes membre d'une équipe de 50 codeurs construisant un grand projet. Mais si vous êtes seul: vous êtes bloqué.

Encore une fois, je ne sous-estime pas les énormes avantages d'une ressource externe en termes de flexibilité: la programmation basée sur les données me semble être la voie à suivre pour les jeux vidéo. Mais n'oublions pas le coût.

D'autre part, le fait de placer le texte dans le code permet un prototypage rapide, il devrait donc être préférable dans un premier temps. Mon conseil serait alors, au fur et à mesure de l'avancement du projet, d'analyser le type de données nécessaire à la modélisation des dialogues (humeur / historique-état / ...). Ensuite, à un moment donné, vous décidez de certaines classes / règles / formats de fichier et optez pour la réalité, permettant à d’autres personnes de modifier / découpler le code du contenu, etc. OU pour un jeu avec des dialogues simples (Mario ...), vous considérez simplement le coût trop élevé et vous conservez les quelques chaînes / comportements codés en dur.
Ton appel.

(Remarque sur la localisation: c'est juste une table de hachage, donc c'est un problème indépendant et facilement résolu.)

GameAlchemist
la source
Certaines de ces choses sont toujours vraies si vous mettez le texte dans le code. Vous avez toujours besoin d'un certain format, d'un moyen de naviguer dans l'arborescence, etc. Dans cette optique, les coûts supplémentaires liés à la mise en œuvre d'une source de contenu externe semblent relativement peu importants, d'autant plus qu'il existe des bibliothèques et des éditeurs matures pour l'analyse, l'écriture, l'édition et la création de ces fichiers. En fonction de la complexité de vos dialogues, vous pourriez même vous passer d'un éditeur spécialisé et utiliser un éditeur de texte standard.
Christian
1
Bien sûr: peut-être que je n'étais pas assez clair, je voulais dire que ce n'est qu'après quelques itérations que vous savez quelle est la forme de vos dialogues (d'une simple ligne droite à une arborescence complexe ou à une machine à états). Dans les premières étapes, quelques ifs (les plus faciles) et une chaîne codée en dur sont ok Ensuite, lorsque vous pourrez clairement identifier vos besoins, faites votre choix, après avoir évalué le rapport coûts / avantages de chaque solution.
GameAlchemist
Un moyen terme que j'utilise dans mon projet de jeu solo consiste à avoir un contenu codé en dur qui est généré à partir de fichiers analysés avant la compilation. Dans beaucoup de cas, ce serait une solution du pire des deux mondes, mais pour ce dont j'ai besoin, c'est en fait assez bon.
glenatron
2

Je suppose que les licences peuvent également être une raison pour ne pas inclure de contenu dans le code.

Par exemple,

  • votre code pourrait être FLOSS libre, mais vous ne souhaitez pas du tout autoriser votre contenu (vous souhaitez peut-être publier votre code de jeu afin que d'autres puissent l'utiliser pour créer des jeux similaires avec un contenu différent)
  • votre code est peut-être FLOSS, mais vous souhaitez utiliser une licence Creative Commons pour votre contenu (les licences de logiciels ne fonctionnent pas très bien) pour le contenu et inversement)
  • votre code est peut-être propriétaire , mais vous réutilisez du contenu gratuit
  • votre code peut être propriétaire, mais vous voulez publier votre propre contenu sous une licence libre / libre
unor
la source