Dans quelle mesure vos documents de conception de jeu sont-ils détaillés et / ou complets avant de commencer un projet?

Ce que je me demande, c'est à quel point vos documents de conception sont généralement complets avant de commencer la mise en œuvre d'un projet? Je parle de projets moyens à très petits avec une très petite équipe ici où même entièrement étoffé le document entier peut ne faire que quelques dizaines de pages.

Commencez-vous avec un cadre approximatif et commencez à étoffer les détails en même temps que la mise en œuvre démarre?

Avez-vous complètement étoffé chaque section avant même de commencer une implémentation? Si oui, quel pourcentage de changement avez-vous constaté après le début de la mise en œuvre?

Si vous avez de l'expérience avec l'un des deux scénarios que j'ai décrits, j'aimerais connaître votre opinion sur les problèmes que cet itinéraire particulier a causés et sur les obstacles qui, selon vous, vous ont aidé à éviter.

Si l'idée du jeu est fortement basée sur un concept de gameplay inhabituel , je prototype tout de suite , en utilisant un projet précédent comme modèle. 95% du temps, cela conduit à réaliser que ce n'est pas aussi amusant que je l'imaginais, et pour le rendre amusant, il faudrait plus de ressources qu'il n'en vaut la peine.

Si je travaille sur un autre projet en attendant, je prends mon temps, fais un doodle pour avoir une idée de ce à quoi devrait ressembler le prototype (essayez de ne pas vous laisser distraire par les croquis). Ensuite, je le partage avec des amis, en partie pour voir s'ils ont une contribution, mais surtout pour me faire penser à des choses qui ne sont pas évidentes tout de suite (il y a toujours des tonnes de choses, même pour les plus intelligents qui réfléchissent aux idées les plus simples). Après quelques heures comme ça, je vais noter quelques concepts clés qui doivent être dans l'architecture, littéralement ~ 20 mots. Ensuite, je peux construire un prototype quand j'ai le temps.

Actuellement, mes conceptions de jeu ont été suffisamment détaillées avant de commencer.

Je vais étoffer la plupart des classes importantes, dessiner des maquettes (les dessins sont généralement horribles), faire une description du jeu.

Bien que cela soit principalement dû au long trajet pour se rendre au travail et à rien d'autre à faire. Je préfère passer moins de temps à faire cela, et plus de temps à programmer, car étoffer les classes qui vont très probablement changer semble être excessif.

Travaillant sur de petites équipes sur de petits jeux (équipes individuelles sur de petits jeux occasionnels), je suis passé du «design lourd» au «design rapide». Je trouve que le développement itératif (deux semaines axées sur un seul objectif, par exemple un gameplay de base) aide à étoffer le design et vous donne quelque chose à jouer, ce qui signifie que vous ne changerez pas d'avis et invaliderez 90% de ce que vous avez conçu qui avait l'air bien "sur le papier" mais pas dans le jeu.

Cela dit, je passe la majeure partie de mon temps de conception sur le gameplay et les mécanismes de base (comment le jeu principal fonctionnera), et cela change rarement beaucoup - il obtient des ajustements et parfois je prends de nouvelles idées ou abandonne de vieilles idées; mais rien ne va sans un prototype fonctionnel.

Sur le plan technique, tout devrait être réfléchi au moins quelques minutes avant de rendre le code réel. Mais, vous pouvez toujours refactoriser plus tard.

La documentation de conception a un coût d'entretien; à mesure que les choses changent, vous devez revenir en arrière et relire et mettre à jour tous les documents existants. En tant que tel, ce devrait être un objectif de production de minimiser la quantité de documentation maintenable, car cela maximisera le temps passé à construire le jeu.

De là, il s'ensuit que vous ne voulez pas tout concevoir dans les moindres détails à l'avance, car vous savez très bien que la moitié va changer, et vous aurez alors à perdre beaucoup de temps. Faites la conception minimale nécessaire pour commencer à créer le jeu de base. Une fois cela fait, répétez au besoin, puis répétez le processus pour chaque nouvelle fonctionnalité.