Un millier de lignes de code sont utilisées pour créer mon propre jeu spatial 2D, qui crée des réseaux de systèmes d'étoiles générés de manière aléatoire et les remplit d'une sélection aléatoire de planètes, de stations, de navires et d'armes.

Il y aura potentiellement des centaines de stations / navires / etc. que le jeu devra utiliser - alors voici ce que je me demandais. Devrais-je passer du temps à créer un chargeur de données 'softcodé', qui stockerait toutes ces informations dans (par exemple) des fichiers XML, et serait donc un peu plus facile à modifier plus tard, ou devrais-je simplement aller avec ce que j'ai déjà fait actuellement - coder en dur tous les objets dans le moteur principal du jeu.

Je suis la seule personne impliquée dans le projet et, comme je l'ai dit, ce n'est qu'un truc d'amateur que je fais pendant mon temps libre, loin de l'université. Mais la communauté recommanderait-elle d'investir dans la création d'un système supplémentaire complet de stockage de données dans des fichiers supplémentaires?

Quels sont les avantages du codage logiciel des données de cette manière, par rapport au simple codage en dur via des constructeurs? Y a-t-il un avantage à long terme à pouvoir modifier les fichiers externes? Si je ne cherche pas le jeu avec des "mods", est-il nécessaire d'avoir des fichiers externes? Si c'est juste un truc d'amateur auquel je pourrais renoncer dans quelques semaines ou quelques mois, devrais-je perdre du temps là-dessus?

Oui. Vous devez implémenter un système pour charger le contenu en dehors de votre moteur principal.

En-têtes de réponses succinctes.

Non, cela ne prend pas trop de temps.

Je pense que la question de savoir si c'est une allocation valide de votre temps limité est sans objet; même si ce n'est que pour le fait qu'il s'agisse d'une petite partie du temps total du projet.

Vous passerez des centaines (milliers) d’heures sur un projet de jeu que vous menez à terme. Peut-être pas sur un clone de Pong, mais sûrement pour votre jeu spatial complexe. Comparez cela à un lecteur de fichier de configuration. L'implémentation d'un système permettant de canaliser XML dans votre constructeur principal, puis de reprendre le processus de jeu, prendra peut-être 10 ou 20 heures. Même si cela vous prend 50 ou 100, ce ne sera qu'une infime fraction du temps total du projet.

Ça fera gagner du temps

Ce n'est pas une dépense de temps; c'est un investissement de temps. Et ça va payer.

Le flux de travail est important, et avoir un chargeur de configuration améliorera votre flux de travail. En créant un système vous permettant d'éditer des configurations à la volée, vous économiserez d'innombrables reconstructions. Vous pouvez regarder le jeu en cours d'exécution, ajuster XML et vérifier à nouveau en quelques secondes. Ou vous pouvez regarder le code, trouver une ligne de code (parmi des milliers), éditer ses valeurs extrêmement soigneusement (vous êtes dans votre moteur principal, après tout), reconstruire, exécuter, ramener le jeu à l'état de test, essayer de rappelez-vous à quoi il ressemblait avant le changement et voyez si votre changement produisait l'effet escompté. En supposant que rien ne casse votre moteur, votre train de vie est certainement perturbé.

Dans une perspective comp-sci plus fondamentale, essayez de vous rappeler que la partie la plus fastidieuse du logiciel d’écriture n’a pas besoin de quelques touches supplémentaires ou espaces. C'est la chasse aux insectes. Et si vous passez un peu plus de temps pour clarifier les choses en écrivant du code plus détaillé, vous économiserez beaucoup plus de temps par la suite. Dans votre cas, l'écriture d'un importateur de contenu donne un code plus propre qui sera plus facile à lire. Au lieu de kilomètres de valeurs codées en dur, votre source comportera un simple chargement de fichier. De même, vous pouvez lire le fichier de configuration sans vous faufiler dans le code du moteur de jeu. Les deux parties deviennent plus faciles à gérer et à déboguer.

Les équipes composées d'un seul membre bénéficient le plus

Si vous avez embauché un artiste pour générer une partie de ce contenu, vous devrez créer des outils avec lesquels il pourra travailler. Ils doivent modifier les pixels et voir rapidement les effets. Vous n'oseriez pas les forcer à reconstruire le code pour voir chaque changement. Leur temps est cher et vous ne voulez pas le perdre.

Maintenant, imaginez que cet artiste soit très peu qualifié et lent (artiste programmeur) et qu'il doit s'occuper de beaucoup d'autres choses, car il est également le programmeur principal et le musicien. Vous ne voulez certainement pas perdre ce temps, sinon le projet ne sera jamais terminé. Et, cet artiste de merde détesterait la formation pour devenir un meilleur artiste, car ils passent tout leur temps à renommer des chaînes d'actifs en code.

Ne fais pas ça pour toi. Fabriquez les outils et vous aurez plus de temps pour créer un jeu.

C’est une bonne question et la meilleure réponse que je puisse vous donner est que seule l’expérience peut vraiment vous dire que c’est une bonne idée de prendre le chemin le plus difficile / long. Si quelqu'un vous dit que vous devriez TOUJOURS le faire «correctement», alors ils ont tout simplement tort.

Vous comprenez déjà que c'est un échange. D'une part, le codage en dur est si tentant, car il est rapide et facile de commencer, mais à long terme, l'ajout de fonctionnalités et le débogage deviendront cauchemardesques. D'autre part, écrire un bon système flexible et extensible nécessite un investissement initial important, mais rend la vie beaucoup plus facile à long terme.

Le but est d’obtenir quelque chose de fini, et si vous vous perdez à faire un bon système, le but recule encore et vous perdez votre motivation. Le codage en dur est acceptable dans certaines circonstances, mais vous devez comprendre les conséquences qui en découlent. Voici quelques raisons pour lesquelles le codage en dur est une mauvaise idée:

• Vous pensez peut-être que votre projet est petit, mais il est possible qu'il s'agrandisse lorsque vous décidez d'ajouter plus de fonctionnalités. Si vous commencez à coder en dur, le temps viendra où l’énergie nécessaire à sa maintenance (mise à jour avec de nouvelles données et réparation de la myriade de bogues inévitables) commencera à dépasser sérieusement les gains initiaux.

• Le codage en dur est par définition spécifique au projet en cours. Pour le prochain projet, vous devrez recommencer à zéro, éventuellement à nouveau coder en dur (parce que c'est ce que vous serez à l'aise). Si vous aviez mis le temps dans un système de chargement décent, vous pourriez ignorer ce travail et ces maux de tête pour tous vos projets futurs.

• Vous travaillez peut-être seul en ce moment, mais vous voudrez peut-être faire venir quelqu'un d'autre sur le projet. Allez-vous prendre le temps d'expliquer votre système paroissial dégoûtant et d'écrire de la documentation à ce sujet?

• Le codage en dur implique souvent de savoir ce que signifient certains nombres magiques ou des dépendances de classe compliquées. Vous pourrez peut-être garder tout cela à l'esprit maintenant, mais attendez que vous ayez quitté le code pendant un moment. Même avec de nombreux commentaires, une structure mal conçue est un enfer vers lequel remonter.

Je dirais que vous devriez vous sentir libre de coder en dur des choses sur les plus petits détails. Si vous avez la moindre idée de l'élément sur lequel vous travaillez, utilisé par quelqu'un d'autre, grossissant beaucoup ou utilisé dans un autre projet, prenez le temps de le faire correctement, maintenant.

D'autre part, je prototypise comme un fou et coder en dur certaines choses est rapide et facile et vous laisse libre de vous concentrer sur les expériences. Cela dépend en quelque sorte de votre style de travail.

Vous parlez de programmation basée sur les données .

Pour les petits projets, cela ne vaut peut-être pas l'investissement en temps, car il y a souvent des fonctionnalités beaucoup plus importantes que vous pouvez améliorer.

Cependant, la programmation basée sur les données peut être TRÈS facile à implémenter. Si vous êtes sérieux, vous devriez probablement utiliser XML, JSON ou YAML, mais vous pouvez aussi utiliser des fichiers texte.

Programmation pilotée par les données

Avantages

1. Permet aux concepteurs d'accéder aux données du jeu et de les modifier sans connaissances en programmation
2. Vous pouvez apporter des modifications au jeu sans avoir à recompiler . Cela ne doit pas être sous-estimé, car vous pouvez développer un jeu beaucoup plus rapidement de cette façon. Les bons jeux viennent après de nombreuses itérations.

Les inconvénients

1. Sa mise en œuvre prend du temps et des efforts.
2. Cela peut augmenter la complexité du programme.