Utilisez-vous des diagrammes pour modéliser des jeux? [fermé]

Je veux dire principalement UML mais toute méthode qui fonctionne est viable. Donc - modélisez-vous réellement vos jeux avec des diagrammes UML / autres ou différentes méthodes? J'avais un sujet dans mon université sur la modélisation avec UML et cela semblait plus d'efforts que d'avantages réels, mais je me rends compte que c'est peut-être uniquement parce que je n'ai jamais créé un énorme système informatique complexe. Cela vaut-il la peine et quels types de diagrammes / méthodes sont généralement * les meilleurs?

* Bien sûr, il faut souvent choisir des outils concrets pour résoudre des problèmes concrets, mais il y a peut-être des modèles.

Edit: j'ai oublié une chose importante - créez-vous des diagrammes avant ou après avoir implémenté des trucs? Ce que je veux dire, c'est que lorsque l'on conçoit et met en œuvre quelque chose, on change d'idée ou que quelque chose d'inattendu survient et que l'on doit apporter des modifications, parfois majeures, et les faire dans des diagrammes déjà complexes semble tout aussi désespéré que dans le code lui-même.

J'aime à penser que tout ce qui nous entoure peut être représenté, d'une manière ou d'une autre, à travers un diagramme. Même s'il ne s'agit que d'un diagramme linéaire représentant la transition entre les états d'un objet particulier au cours du temps (comme un être vivant, passant par un certain nombre d'états de la naissance à la mort). J'utilise des diagrammes pour exposer mes pensées et idées pour la mise en œuvre réelle. J'improvise pas mal.

Par conséquent, mes diagrammes sont la plupart du temps à un niveau très élevé et ressemblent à des cartes mentales .

Pour jeter quelques exemples, c'est en fait une carte d'héritage de classe (une qui a été coupée) dans mon jeu où Interactive Object est le type de base.

Il s'agit d'un diagramme FSM ( machine à états finis ) pour un piège à pointes (ces pièges impressionnants sur lesquels vous marchez et les pointes woosh apparaissent du sol).

Il s'agit d'un diagramme de manuel (nommé de cette façon car il est destiné à être un diagramme de retour souvent ) que j'ai dessiné récemment. Il décrit les composants d'un jeu et aide également à rassembler les actifs requis, car vous pouvez voir immédiatement ce qui est nécessaire et ce qui ne l'est pas. Je les recommande sur les petits projets, car ils deviennent assez énormes sur les grands. Cependant, ils peuvent être élargis, ce qui peut régler les choses.

Quand je passe à un niveau inférieur, c'est généralement parce que je dois planifier les aspects les plus complexes de mon architecture, et je traite généralement avec UML là-bas. Je ne me concentre jamais sur la sortie d'un UML absolument propre et correct. J'ai adopté ce que j'aimais le plus à propos de la convention UML, et je l'ai transformé en un joli UML mindmap-ish. C'est simple et fait le travail pour moi, mais je n'irais pas avec dans un environnement où l'UML est attendu, pour des raisons évidentes.

Une autre situation où je dois aller à un niveau inférieur est quand je dois décrire des algorithmes réels. J'utilise ce que j'appelle des organigrammes . C'est un format inspiré des diagrammes utilisés dans les tests en boîte blanche .

Un échantillon pour le piège à pointes que j'ai dessiné en ce moment ressemblerait à ceci:

Il s'agit normalement de la dernière couche entre les diagrammes et les implémentations réelles d'algorithmes. Si le besoin s'en fait sentir, je détaille davantage les organigrammes (avec des instructions supplémentaires exécutées), et je déduis ou estime la complexité, et je construis des cas de test précis. Je préfère également les diagrammes au pseudocode.

Ce n'est pas lié au développement de jeux, j'ai également un bon format pour décrire les écrans dans une application multi-écrans, les fonctionnalités que l'utilisateur peut déclencher sur chaque écran et la relation entre les écrans. Je les construis normalement avant de commencer le développement réel, et ils agissent comme une carte tout au long du processus de développement. Si c'est pour un client, le diagramme d'écran est encore plus utile! Cela m'aide à parcourir tout le projet, du début au début, et à prendre en considération toutes les fonctionnalités dont il aura besoin. Par conséquent, il est inestimable de fournir une estimation précise des coûts et du temps.

Alors oui, je représente définitivement tout et n'importe quoi. Si j'ai une idée, je peux et je vais certainement en dessiner un diagramme. Si je commence un projet sans au moins un schéma très large pour me soutenir, je me sens paralysé.

Je fais certainement - à la fois structurel et comportemental - ma règle de base est que je fais des diagrammes lorsque le coût de fabrication du diagramme est inférieur à celui d'essayer de me rappeler ce que je pensais un mois plus tard - ou quand j'ai besoin de m'expliquer clairement un autre développeur

Diagrammes de classes lorsque la hiérarchie d'héritage devient suffisamment complexe

Diagrammes d'objets lorsque des choses comme l'instanciation d'objets deviennent quelque chose de proche de la création d'un monstre de Frankenstein à partir de pièces disparates - particulièrement utile pour les utilisateurs de vertex d'évier de cuisine et de pixel shader, pour s'assurer que tous les bits requis sont poussés à travers le tuyau

Diagrammes de séquence lorsque les interactions détaillées entre un ensemble d'objets deviennent complexes - ceci est extrêmement utile pour modéliser des flux de rendu complexes où des informations précédemment calculées sont nécessaires à des emplacements en aval à peine liés

Les diagrammes sont un excellent moyen de communiquer, de documenter et d'aider votre conception , et la conception est la partie la plus importante du développement logiciel. UML a beaucoup de fonctionnalités mais vous n'êtes pas censé les utiliser toutes en même temps, seulement celles qui sont utiles.

Lorsque vous naviguez dans une nouvelle ville, vous arrêtez-vous réellement et regardez-vous une carte, plutôt que de simplement continuer et suivre les panneaux? C'est à cela que sert le design vs le codage. Lorsque les choses ne sont pas familières, lorsque le problème est complexe, lorsque vous vous sentez perdu, c'est à ce moment-là que penser au design est le plus utile, et il vaut mieux le faire plus tôt que plus tard. Il est beaucoup plus facile de modifier votre conception avant d'avoir mis en œuvre quoi que ce soit .

Les diagrammes sont un excellent moyen de visualiser le problème et d'aider votre conception, en particulier pour les penseurs visuels (qui sont la plupart d'entre nous sur gamedev, j'imagine). Beaucoup de problèmes deviennent triviaux, les défauts deviennent évidents, quand ils sont clairement cartographiés sur un diagramme. Quelques problèmes que vous pouvez trouver dans un diagramme:

• Trop de connexions à un seul composant? Vous pouvez avoir un objet divin difficile à entretenir
• Trop d'interconnexions? Peut-être que la modularité peut être améliorée, pour rendre l'architecture moins fragile
• Trop de voies entre deux composants? Vous avez peut-être un couplage serré
• Pour les applications hautes performances telles que les jeux, y a-t-il trop de composants impliqués dans le hot path ou la boucle interne? Cela peut avoir un impact sur vos performances
• Cependant, la plupart du temps, le diagramme montre des incohérences entre la conception que vous envisagez et la mise en œuvre réelle

De plus, les diagrammes sont parfaits pour communiquer et documenter votre conception, à des personnes non techniques ou à des personnes qui sont nouvelles dans votre projet - et n'oubliez pas qu'en 6 mois, vous êtes pratiquement nouveau dans le projet aussi!

La façon dont vous utilisez UML doit être basée sur ces considérations. Créer des diagrammes pour vous-même? Utilisez la notation qui vous convient le mieux. Collaborer avec d'autres développeurs? Essayez d'inclure les détails des appels API, les types de messages, les directions des dépendances. Vous discutez d'architecture? Des boîtes noires et des connexions simples suffiront. De toute façon , personne n'utilise l'ensemble complet des fonctionnalités UML , et il est très utile en tant qu'ensemble de notation standardisé que beaucoup de gens comprennent - alors que mes griffonnages de serviette peuvent être incompréhensibles pour vous et vice versa.

Quant à moi, j'utilise des diagrammes tout le temps - de simples dessins de bloc-notes pour des projets personnels, de simples diagrammes UML au travail. Ce diagramme UML est ce que je considérerais comme trop complexe, et que je ne ferais jamais car le coût de production et de maintenance l'emporte sur son avantage, mais bien sûr YMMV.

Je dirais qu'il existe deux types de diagrammes. Diagrammes formels et gribouillis.

Concernant les diagrammes formels, je les fais quand je travaille avec d'autres programmeurs, mais je le fais rarement quand je programme seul.

Cependant, cela ne signifie pas que je m'assois et que je code tout ce qui me vient à l'esprit. À mon avis, la chose la plus importante lors de la programmation (ou en fait n'importe quoi dans la vie) est de penser d'abord et de faire plus tard .

Le codage est une tâche très mécanique. Vous tapez et les mots apparaissent à l'écran. L'idée est qu'au moment où vous commencez à coder, vous devriez déjà avoir résolu le problème à portée de main. Faire des gribouillis est un excellent moyen de trier vos pensées, et même de vous forcer à penser que vous devez faire la partie codage correctement. Les gribouillages ne sont pas destinés à être enregistrés pour référence future, juste pour que vous puissiez comprendre facilement vos processus de pensée.

Ne vous inquiétez pas si vous prenez trop de temps à réfléchir. Je pense qu'un bon équilibre se produit lorsque vous consacrez 90% de votre temps à réfléchir et 10% à coder. J'ai rencontré plusieurs programmeurs "seniors" qui vivent "nous n'avons pas le temps de penser, juste de faire". Mais même s'ils appellent leur code "terminé" plus tôt que ceux qui prennent le temps de réfléchir à ce qu'ils font, ils (ou les âmes malchanceuses sont parties ensuite) passent ensuite d'innombrables heures à réparer et à corriger quelque chose qui aurait dû être construit correctement. Depuis le début.

La meilleure chose est que la réflexion est gratuite! vous n'avez pas besoin d'être assis sur votre ordinateur pour réfléchir. Vous pouvez penser au code pendant que vous mangez, faites la navette, faites de l'exercice ... En fait, les meilleures idées viennent quand vous vous y attendez le moins, alors gardez l'esprit ouvert à tout moment et ne commencez à coder que lorsque vous savez vraiment ce que vous allons coder.

Voici un article connexe avec lequel je suis d'accord.

Edit : En ce qui concerne le format et le type de diagrammes, je vous recommande de choisir le style libre et en fait manuscrit au lieu d'utiliser des outils préemballés. N'oubliez pas que le but est de vous aider dans votre réflexion, alors n'hésitez pas à dessiner ce que vous voulez. La sémantique est ce que vous voulez qu'ils soient, et ils peuvent être différents entre les diagrammes, et même entre différentes parties du diagramme.

Les diagrammes freestyle / manuscrits présentent trois avantages principaux par rapport aux outils préemballés:

1. Vous n'êtes pas obligé de respecter le type de diagramme pris en charge par l'outil que vous choisissez. Parfois, mapminds fonctionnera, parfois quelque chose de plus comme UML ira bien, tandis que d'autres fois un diagramme logique fera l'affaire. D'autres fois, un diagramme entièrement personnalisé fonctionne, et aucun outil ne peut vous donner toute la flexibilité des diagrammes de style libre (essayez de percer un trou dans le papier et de continuer au verso du papier, dans votre emballage préféré, et voyez ce qui se passe)

2. Vous passerez plus de temps à créer des diagrammes au lieu d'utiliser l'outil. Quel que soit l'outil, le stylo et le papier sont toujours plus rapides à créer des diagrammes qu'à saisir et à parcourir les menus pour trouver les éléments spécifiques que vous recherchez.

3. Vous n'avez pas besoin d'un ordinateur pour écrire à la main. La plupart du temps, je fais des dessins complexes, je les fais dans une bibliothèque, un café ou même à l'intérieur d'un avion. De plus, les bonnes idées surgissent toujours au moment le moins approprié, alors assurez-vous de toujours avoir quelque chose pour écrire et quelque chose pour écrire.

Il vaut peut-être la peine de souligner quelques présentations du schéma de conception de la Game Developers Conference 2013. Ce sont des exemples très pratiques et testés sur la route - et il semble qu'ils aient été présentés lors de nombreuses conférences au fil des ans.

(Les autres réponses ont fait un travail admirable pour démontrer pourquoi et comment les diagrammes axés sur la conception peuvent être extrêmement utiles dans la planification, la construction, la croissance et la maintenance d'une base de code, donc je vais laisser cet aspect seul, et je fais confiance à ces ressources pourraient être utiles à toute personne visitant la question.)

Joris Dormans et Ernest Adams ont discuté du système de schémas de conception / équilibre du jeu Machinations . (Voici une vidéo GDC Vault paywallée de GDC EU 2012; exemples de GDC 2013 sur le wiki de Dormans.) Plutôt que d'essayer de paraphraser, voici comment le wiki décrit le système:

Machinations est un cadre théorique et une représentation graphique interactive et dynamique qui décrit les jeux comme des systèmes dynamiques et se concentre sur des boucles de rétroaction fermées en leur sein. L'intention est de trouver un moyen d'exprimer et d'étudier les structures de jeu (récurrentes) méthodologiquement. Machinations propose un nouvel objectif sur la pratique intuitive et délicate de la conception de jeux et de l'équilibrage.

Noah Falstein a donné une conférence intitulée "L'art des arcanes des diagrammes de dépendance des puzzles" (paywalled GDC Vault ). Je ne trouve aucun lien non paywallé ici, mais plusieurs personnes ont discuté ou publié leurs notes en ligne.

Les deux entretiens ont discuté de la date de création et de la manière dont ils ont maintenu ces diagrammes, dans une certaine mesure.

Vous devriez probablement consulter cet article sur l'utilisation d'une simple grammaire abstraite pour décrire votre boucle de jeu, comment elle peut vous aider à identifier les problèmes de conception et à quel point il est facile d'itérer à ce niveau.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Je peux également vous orienter vers mon propre travail sur le sujet, plus basé sur l'économie de la boucle de gameplay, en utilisant des ressources abstraites pour suivre des choses comme les opportunités, la chance ou la préparation:

http://www.stephanebura.com/diagrams/

Si vous trouvez cette approche utile, vous devriez jeter un œil à Machinations de Joris Dormans, un outil pour créer de tels diagrammes et exécuter leurs simulations:

http://www.jorisdormans.nl/machinations/

Tout son processus est expliqué dans son livre:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/