En tant que client cherchant à faire en sorte qu'un codeur / programmeur développe ses idées en un programme fonctionnel, que devrais-je fournir à mes développeurs?

Je suis le directeur d'un groupe de développement de jeux de start-up (je dis "groupe" car ce n'est pas encore une société officielle). J'ai récemment obtenu la volonté de quelques codeurs disposés à m'aider dans le projet, mais ils demandent de la documentation.

Je comprends le besoin de documentation, et plusieurs de nos idées sont exprimées dans plusieurs documents différents, mais j’imagine que j’aimerais vouloir l’organiser d’une manière que les développeurs puissent comprendre individuellement et collectivement.

Y a-t-il quelque chose que je devrais laisser de côté dans un tel document? si oui, quel genre de choses? Existe-t-il un modèle approprié pour ce type de document? Si oui, où puis-je le trouver? Y a-t-il autre chose que je devrais savoir à offrir aux codeurs avant qu'ils ne commencent leur travail?

Je sais que j'ai beaucoup de questions posées ici. J'espère que ce n'est pas un problème. Merci d'avance pour toute orientation!

Le développement de jeux fonctionne généralement un peu différemment du développement d'applications. La raison en est que les jeux ont généralement des exigences beaucoup moins strictes et beaucoup moins strictes. Vous n'avez pas de problème commercial bien défini que votre logiciel est censé résoudre. Les seules véritables exigences d'un jeu sont "fonctionne correctement sur la plate-forme cible", "s'adresse au groupe cible" et "est amusant à jouer" (et peut-être "vend beaucoup de micro-transactions" si vous êtes dans cette partie de l'industrie ). Tout le reste est sujet à changement au cours du développement.

Cependant, afin de vous assurer que tous les développeurs du jeu travaillent dans la même direction et ne finissent pas par se battre à outrance pour des différences de créativité, vous devriez avoir une "vision" codifiée de la manière dont vous voulez que le jeu final ressemble à un jeu. . Cette vision est généralement codifiée dans un document de conception de jeu . Un tel document décrit généralement:

• Le principe de base du jeu:
  • Le pas d'ascenseur : L'idée principale du jeu, décrite aussi brièvement que possible.
  • Quel est le genre du jeu?
  • Quel est votre groupe démographique cible?
  • Quelle (s) plateforme (s) ciblez-vous?
• La mécanique du jeu:
  • Quelles actions le joueur peut-il effectuer dans ce jeu et comment affectent-ils le jeu?
  • Quelles sont les entités non-joueurs présentes dans le jeu, comment se comportent-elles et comment interagissent-elles entre elles et avec le joueur?
• Le viseur:
  • Combien de contenu voulez-vous que le jeu ait?
  • Quel niveau de qualité souhaitez-vous que le contenu ait?
• La direction esthétique du jeu:
  • Quelle atmosphère générale voulez-vous que le jeu ait?
  • Comment voulez-vous que le jeu ressemble?
  • Comment voulez-vous que le jeu sonne?
• En matière d’histoire, cela dépend beaucoup du genre. Certains jeux n'ont besoin d'aucune histoire. Beaucoup de jeux n'ont besoin que de quelques phrases. Mais si vous créez un jeu basé sur l'intrigue, comme un RPG ou une aventure, cela peut en fait être la partie la plus longue du document de conception et peut inclure:
  • Une description du monde dans lequel le jeu se déroule et de ses lieux clés
  • Une description des personnages importants, de leur apparence, de leur personnalité et de leur passé
  • Un aperçu de base de l'intrigue qui est racontée pendant le jeu

Si vous parcourez le Web, vous trouverez un grand nombre de modèles de documents de conception de jeux. L’industrie du jeu exige beaucoup moins de formalités et de processus normalisés que le reste de l’industrie. Vous ne trouverez donc pas l’unique norme ISO pour les régir toutes. Essayez simplement de trouver un style qui correspond à votre projet, à votre équipe et à votre méthodologie de travail.

Cependant, soyez ouvert aux changements en cours de développement. Lorsque des documents de conception de jeux de jeux populaires sont divulgués au public, intentionnellement ou non, vous pouvez généralement remarquer quelque chose d'intéressant. Si vous comparez ces premières notes de conception au jeu final, il y aura généralement beaucoup de différences considérables. Ceci est généralement le résultat d'un processus de conception appelé par les développeurs de Fail Faster :

1. Venir avec un design approximatif
2. Créer un prototype simple
3. Testez-le avec un état d'esprit critique et déterminez ce qui ne fonctionne pas
4. Révisez votre design
5. Retourner à l'étape 2

Alors n’ayez pas peur de modifier ou de supprimer des fonctionnalités lorsque vous réalisez, lors du test, qu’elles ne sont pas aussi amusantes qu’elles ne l’étaient dans votre tête. Soyez également ouvert aux suggestions de l'équipe. La plupart des acteurs de l'industrie du développement de jeux ont décidé de s'y joindre car ils souhaitent mettre en pratique leurs propres idées de jeux. Donner une influence créative à votre équipe peut donc être un excellent facteur de motivation. Mais en tant que bon producteur, il est également de votre devoir de dire "Non!" si vous pensez qu'une idée ne fonctionnerait pas ou dépasserait le budget.

Je suis impatient de jouer à votre jeu.