Cela vaut-il la peine de planifier avant de sauter dans le code?

J'ai toujours pensé que la planification était importante pour un match. Mais je ne sais pas à quel moment. Certains me disent de coder au lieu de planifier, mais je pense que c'est toujours important parce que lorsque vous serez dans le code, vous saurez quoi faire plus facilement. Je travaille actuellement sur un jeu qui aura beaucoup de contenu, j'ai donc décidé de commencer un document de conception présentant ce contenu et, à côté, je fais des preuves de concept pour vérifier si cela peut être fait. Des parties de chaque preuve de concept pourraient ensuite être utilisées plus tard dans le jeu réel.

EDIT: Je travaille seul sur ce projet.

Donc ma question est: ça vaut la peine de planifier avant de sauter dans le code? Im toujours intéressé de savoir ce que les autres ont à dire à ce sujet. Parce que je reçois encore des gens qui disent que je devrais coder au lieu de penser .. alors quelle est votre opinion à ce sujet?

Vous avez dit deux choses intelligentes dans votre question:

1. "code au lieu de penser" - il y a toute une philosophie qui décrit cela: http://gettingreal.37signals.com/toc.php
2. "preuves de concept pour vérifier si cela peut être fait" - j'ai vu et eu beaucoup d'idées qui se sont avérées impossibles ou extrêmement difficiles à faire quand elles étaient presque terminées. Parfois, vous ne pouvez tout simplement pas le prédire, car c'est votre environnement de programmation (langage, bibliothèques, performances matérielles) qui vous limite.

Voilà pourquoi je dis:

• concevoir, mais ne faites pas un énorme doc de design si vous ne cherchez pas de collaborateurs ou d'investisseurs, à moins que ce ne soit amusant pour vous et que vous le preniez comme une pause dans la programmation;
• ayez toujours à l'esprit ce que vous voulez réaliser; chaque module doit avoir une entrée et une sortie conçues; de cette façon, vous pouvez facilement tester le module et ne ressentez aucune sensation d'errance dans le brouillard;
• rappelez-vous que vous concevez la plupart du temps de toute façon, car la saisie de code ne prend que 5% environ de votre temps (au moins en tapant le code final);
• la programmation n'est pas une science théorique, au lieu de vérifier si quelque chose fonctionnera sur un morceau de papier, vous pouvez simplement le coder et essayer; le produit final consiste principalement à rendre les entrées utilisateur à toute épreuve, à l'interface graphique agréable et à traiter des cas spéciaux - un sale test d'une idée peut être fait immédiatement;
• créer une liste de tâches si vous avez peur d'oublier vos idées
• parler avec vos amis de vos idées, car ils seront moins enthousiastes et auront peut-être plus d'expérience dans un domaine; une fois, j'ai eu l'idée de garder secrets les paramètres de l'unité (dans un jeu stratégique), mais mon ami m'a dit que c'était une mauvaise idée, car il jouait à un jeu comme celui-ci et c'était une expérience utilisateur terrible.

Oui, mais seulement un peu .

Pour la programmation de jeux, en particulier la programmation de gameplay, il est essentiel d'avoir une bonne cas d'utilisation avant d'écrire un code. Par exemple, qu'est-ce que le joueur est censé faire, où est-il censé aller et comment, comment interagit-il avec le monde, etc. Cela peut être un storyboard esquissé sur papier, ou ressortir d'une discussion avec un pair ... fait partie de la conception du jeu , et il sera stupide de commencer à coder sans même avoir une idée approximative de la façon dont le jeu est censé être joué.

Mais les jeux doivent être créés manière itérative . Vous ne pouvez pas créer une énorme spécification pour votre jeu et espérer que ce sera amusant à jouer. Vous avez besoin de tests de jeu réguliers pour découvrir ce qui fonctionne et ce qui ne fonctionne pas, et continuer à répéter. Plus l'exécutable s'exécute rapidement, plus la conception du jeu peut être testée rapidement, meilleur est le jeu à la fin. Il est donc toujours préférable de commencer à coder dès que possible, à partir d'une conception de jeu très non formelle, de voir ce qui sort et de continuer.

Une chose est sûre, comme vous codez seul, vous n'avez pas besoin de document ou de méthodologie de conception de logiciel sophistiqué, le code source est la conception.

Certains disent que vous devriez coder au lieu de penser? Eh bien pour coder, vous devez savoir ce que vous voulez créer, pour savoir ce que vous voulez créer, vous devez d'abord penser à ce que vous voulez avoir, ergo, vous devez penser avant de coder;).

Et sérieusement, vous n'avez probablement pas besoin d'un plan détaillé au début, mais avoir un aperçu et / ou des jalons est toujours bénéfique - aussi pour votre atitude, lorsque vous biffez les choses comme faites, vous serez plus encouragé à en faire plus travail.

Le codage et la planification sont nécessaires. Planifiez d'abord, puis codez, mais ne planifiez pas tout à la fois. Planifiez un noyau, codez-le, mettez à jour votre plan au besoin, puis planifiez des fonctionnalités qui s'ajoutent à la jouabilité, aux graphiques, aux sons, aux sprites, etc., cela rendra le jeu que vous créez plus beau et globalement plus agréable. Vous pouvez évidemment exécuter un tel cycle plus d'une fois, et je vous conseille de prendre des décisions qui soutiendront la mise à l'échelle en cas de besoin.

Vous devez savoir où vous allez avant d'écrire du code et l'écriture / dessin peut être un bon moyen de matérialiser ce que vous voulez réaliser. Je dis dessin parce que dessiner des diagrammes, des croquis, etc. peut également vous aider beaucoup. Vous n'avez pas besoin de faire un merveilleux document avec Word ou quoi que ce soit, prenez simplement un crayon et un morceau de papier (beaucoup de morceaux de papier?) Et dessinez, écrivez tout ce à quoi vous pensez.

Pour moi, c'est une bonne pratique d'utiliser un crayon et des papiers, cela aide à matérialiser vos idées et aussi à définir où vous voulez aller pour éviter d'aller n'importe où, fixer votre objectif. Cela fonctionne pour tout ce qui a besoin de réflexion. Et il est évident dans de nombreux domaines d'écrire des choses avant de faire le travail réel.

Faites ce qui vous convient. Personnellement, je planifie les choses dans une petite mesure, mais je n'ai pas de documents de conception qui sont des plans extrêmement détaillés avant de commencer à coder quoi que ce soit. Faites ce qui est le plus productif pour vous, d'autant plus que vous travaillez seul.

(Je suppose que la question est posée du point de vue de la conception du code / de l'architecture, et non de la conception du jeu, bien que la réponse s'applique au moins dans une certaine mesure aux deux.)

Comme nous l'avons déjà dit, vous avez besoin des deux et vous devez l'équilibre. La sur-conception et la sous-conception de votre flux / structure de code peuvent entraîner des problèmes. Il est difficile de dire quel est le bon équilibre, mais en général, je trouve que j'ai besoin d'avoir au moins une vague idée de la façon dont le reste du code rejoindra ce que je programme en ce moment, et de réfléchir aux problèmes possibles, sinon j'ai tendance à "me coder dans une impasse" - entrer dans une situation où je me rends compte "ok, maintenant grâce à la façon dont j'ai résolu ce problème, j'ai créé un nouveau problème qui a rendu toute ma solution précédente (ou même plus, dans les pires cas) ) futile ".

En général, à mon avis, vous pouvez à peu près juger si vous avez le bon équilibre en pensant à des scénarios "et si" comme dans "et si plus tard (quand tout est entièrement mis en œuvre dans le paradigme similaire que j'utilise maintenant) savoir que la partie A doit fonctionner légèrement différemment, ce qui signifie que je devrai retravailler complètement la partie B qui s'y connecte pour s'adapter aux changements? ". Si la modification architecturale d'une partie ne vous oblige pas à modifier plus d'une ou deux autres parties et que les modifications ne se répercutent pas (ce qui signifie que vous devez également modifier les parties suivantes se connectant à la partie B, puis les parties se connectant à , etc.), le code est relativement bien compartimenté.

Mais vraiment, c'est quelque chose que vous aurez une idée après avoir acquis de l'expérience. C'est en partie pourquoi tout le monde donne au début des conseils à gamedevs pour coder d'abord quelque chose de connu et de facile (Breakout / Tetris / Snake) et le faire complètement, avec tous les menus, sons, effets, tout pour que le jeu soit complètement fini - c'est mieux visser un projet plus petit et le faire (que ce soit dans le bon ou le mauvais sens) vous aidera exactement à avoir une idée de l'étendue des effets des différentes décisions architecturales.