Planification de jeu et conception de logiciels? Je pense que UML n'est pas pratique

Dans mon université, ils mettent toujours l'accent et font du battage médiatique sur la conception et les trucs UML, dans lesquels je pense que cela ne fonctionnera pas bien avec la conception de la structure du jeu. Maintenant, je veux juste un conseil professionnel sur la façon de commencer la conception de mon jeu. L'histoire est que j'ai des compétences en programmation et que j'ai fait de nombreux jeux mineurs tels que faire fonctionner un jeu de plateforme 2D dans une certaine mesure. Les problèmes que je trouve sur mon programme sont la mauvaise qualité de conception. Après avoir codé pendant un certain temps, les choses commencent à tomber en panne en raison d'une mauvaise planification (lorsque j'ajoute une nouvelle fonctionnalité, cela a tendance à me faire recoder l'ensemble du programme). Cependant, tout planifier sans un seul défaut de conception est un peu trop idéal. Par conséquent, des conseils sur la façon de planifier mon jeu? Comment dois-je le mettre en images visibles, afin que mes amis et moi puissions avoir un aperçu des dessins?

J'avais prévu de commencer à coder un jeu avec mon ami. Ce sera mon premier travail d'équipe, donc tout conseil professionnel serait un plaisir. Existe-t-il d'autres alternatives que UML?

Une autre question est de savoir à quoi ressemble normalement le "prototypage"?

Je veux juste un conseil professionnel sur la façon de commencer la conception de mon jeu.

La conception du jeu est la spécification du gameplay, des actifs, des systèmes de notation, etc. - ceux-ci ne sont pas spécifiques au logiciel. En tant que tel, UML n'est pas le bon outil pour cette tâche.

Quand il s'agit de concevoir le code pour implémenter ces systèmes, UML est un bon outil pour la tâche, en fournissant à votre équipe le savoir et en s'en tenant aux types de diagrammes les plus courants. Normalement, lorsque vous essayez de concevoir une fonctionnalité, vous saurez si vous devez utiliser une description ou un diagramme. Si vous avez besoin d'utiliser un diagramme, UML vous donne un moyen standard de le dessiner, ce qui est une bonne chose.

Après avoir codé pendant un certain temps, les choses commencent à tomber en panne en raison d'une mauvaise planification (lorsque j'ajoute une nouvelle fonctionnalité, cela a tendance à me faire recoder l'ensemble du programme).

C'est généralement un problème avec la façon dont vous programmez, plutôt que la façon dont vous planifiez. Un bon logiciel est généralement facile à étendre et à réutiliser. Si vous vous en tenez aux bonnes pratiques de programmation, ce problème diminuera. Mais une meilleure planification vous aidera également, et vous n'avez pas besoin de diagrammes complexes pour cela. Le simple fait d'avoir une liste de fonctionnalités signifie que lorsque vous codez une chose, vous avez les autres fonctionnalités à l'esprit et pouvez les considérer comme vous codez.

Par conséquent, des conseils sur la façon de planifier mon jeu? Comment dois-je le mettre en images visibles, afin que mes amis et moi puissions avoir un aperçu des dessins?

Il semble que vous mélangez 2 problèmes ici, la conception du jeu et la conception du code.

Je suggère d'abord d'écrire une conception de jeu de base, en spécifiant les fonctionnalités dont vous avez besoin, les graphiques et les sons dont vous avez besoin, comment le jeu est gagné et perdu, etc. Recherchez des «documents de conception» si vous avez besoin d'aide.

De là, vous aurez une idée des fonctionnalités dont vous avez besoin pour coder. Vous pouvez examiner chaque fonctionnalité à tour de rôle et essayer de réfléchir à la façon de les implémenter. Les diagrammes peuvent aider à montrer les relations entre les différentes classes et les objets dans votre jeu, mais l'habileté de savoir quels objets doivent exister est quelque chose que vous devez apprendre par la pratique et / ou la lecture.

Essayez également de travailler sur des projets plus petits et moins ambitieux. Cela vous habituera à écrire un bon code de travail, sans avoir besoin d'une planification approfondie ou de réécritures.

Ne pas comprendre quelque chose le rend facile à ignorer. L'UML est un outil d'ingénierie utilisé pour communiquer les idées que vous avez de manière structurée. Un jeu est un système qui peut être conçu comme n'importe quel autre. Si quoi que ce soit, la complexité et le dynamisme d'un jeu rendent une représentation visuelle de ses parties et de leurs interactions inestimables.

Les diagrammes UML sont différentes vues d'un modèle du système en discussion. Je commence par des cas d'utilisation pour une personne assise devant mon programme et le démarrant. Dans le cas d'un jeu, il existe deux types d'utilisateurs: les concepteurs et les joueurs. J'écris un cas d'utilisation pour chacune des choses que je peux les voir faire. Ensuite, je fais des cartes CRC pour déterminer quels services je dois fournir. Ensuite, je fais un diagramme de classes pour les interfaces qui fourniront ces services et leurs relations. Ceci est basé sur les cartes CRC. Viennent ensuite les diagrammes dynamiques pour des événements comme l'initialisation qui nécessitent une planification et une orchestration. Puis des diagrammes statiques plus détaillés montrant les classes implémentant les interfaces.

Pendant ce temps, j'écris du code et du prototypage et je le fais évoluer dans le sens de fournir les services nécessaires pour répondre aux exigences de mon jeu. Rien n'est construit qui ne prend pas en charge l'utilisateur à travers les cas d'utilisation. J'écris des éléments de diagramme inutiles, mais entre le codage d'interface et le diagramme j'écris très peu de code inutile. La création de diagrammes me donne l'assurance que je comprends la façon dont la classe que j'écris s'intègre dans l'ensemble du système.

Le point que j'essaye de faire est qu'un programme trivial peut être écrit sans plans, mais un jeu est tout sauf trivial. Il y a quelque temps, lorsque la POO était nouvelle, il y avait beaucoup d'expérimentation et certaines des meilleures pratiques étaient apparues. La communauté du développement de logiciels a convenu que nous avions besoin d'un langage pour écrire et analyser les conceptions de logiciels. L'UML est le langage que nous avons développé. Nous le savons et le comprenons tous, donc si vous voulez utiliser les solutions d'autres personnes à vos problèmes (livres, discussions en ligne, articles, catalogues de modèles, etc.) et ne pas réinventer la roue, vous devez apprendre à lire la notation standard. En prime, lorsque vous vous forcez à penser à votre système dans une autre langue, vous apprenez des choses inattendues.

Il existe de nombreuses méthodologies différentes, mais elles identifient toutes le problème et décrivent une solution de manière systématique. C'est de l'ingénierie. L'UML est énorme et complexe, mais aucun modèle n'utilise chaque construction. C'est comme un couteau suisse. Vous devez le connaître et comprendre comment l'utiliser pour soutenir votre processus d'ingénierie. L'important n'est pas de savoir quel processus ou quelle méthodologie mais que vous en avez un. Sinon, vous vous noierez dans la complexité.

Je travaille également sur des projets de jeux indépendants avec un ami (équipe de 2 personnes). En tant que personne dans une situation similaire à la vôtre, je peux vous offrir quelques morceaux que j'ai trouvés utiles.

1. Si vos idées sont approximatives, essayez de les mettre en œuvre une par une dans des projets de prototypage super minuscules. Par exemple, je fais un jeu de plate-forme 2D maintenant et il est extrêmement important pour moi de bien sauter. J'ai donc fait un nouveau projet où les 2 seules choses qui se produisent sont a) dessiner le joueur sur l'écran, et b) détecter les entrées et redessiner le saut [le personnage ne peut même pas se déplacer vers la gauche ou la droite]
2. Certaines personnes pourraient désapprouver ce conseil, mais pensez d'abord à écrire le manuel du jeu (pour expliquer les concepts, les contrôles, les objectifs). Cela peut faire 2 choses pour vous - générer un document bien nécessaire, mais également décrire les sous-systèmes de votre jeu et tous les détails nécessaires pour le joueur. Si vous savez à l'avance ce que le joueur doit savoir, vous savez à l'avance ce que vous devez faire.
3. Écrivez le code en morceaux suffisamment petits (également modulables ) pour que les morceaux factorisés puissent être déplacés ou mieux organisés sans avoir l'impression que vous essayez de retirer tous les morceaux de spaghetti de taille moyenne d'une assiette de pâtes.

J'espère que vous y avez trouvé au moins une information utile, et bonne chance!

Je pense qu'il y a de précieux points à retenir d'UML que vous ne pouvez pas nier. d'autre part, gardez à l'esprit que UML a été conçu pour les processus métier , vous savez, pour modéliser des systèmes qui ont beaucoup de gens qui interagissent avec, tous avec des désirs, des besoins et des désirs différents. UML essaie de vous assurer de ne rien laisser de côté ou de vous laisser submerger par les détails.

UML est "une façon standard de visualiser l'architecture d'un système"

UML décrit

• Activités
• acteurs
• processus d'affaires
• schémas de base de données
• composants (logiques)
• déclarations de langage de programmation
• composants logiciels réutilisables

Mais si vous créez un jeu simple, avez-vous vraiment besoin de modéliser tout cela?

• Acteurs: Le joueur.

Combien cela aide-t-il?

Modéliser certaines des autres choses est cependant très utile. Par exemple, si vous créez un petit MMO, vous voulez certainement des schémas de base de données bien conçus.

Ainsi, même si les enseignements à tirer d'UML sont excellents (sachez ce que vous faites, notez les exigences et esquissez des diagrammes de diagrammes là où cela est nécessaire), et les éléments de celui-ci sont très utiles, j'ai tendance à penser que le processus UML complet est un petit trou rond à cheville carrée pour les jeux.

UML n'est pas une chose, c'est un ensemble de choses dont certaines ont de la valeur pour d'autres moins. les anciens cas d'utilisation de style (au moins ce que nous appelons des cas d'utilisation) qui indiquent

• prénom
• exigences
• conditions préalables
• déclencheurs
• Actions
• actions alternatives
• des exceptions

peut être très utile. si ce que vous trouvez pour les "cas d'utilisation" si vous effectuez une recherche sur le Web (les images) sont plus pour des logiciels généraux.

Je voudrais également mettre un peu de crédit sur le diagramme de classe. cela montre que vous êtes capable de montrer la relation entre tous vos objets et que vous connaissez la disposition de votre architecture.

ce qui revient à dire que votre ensemble de fonctionnalités doit être entièrement planifié et verrouillé en entier (au moins loué dans une configuration de besoin / besoin) avant la modélisation, et le diagramme est même commencé. ceux-ci devraient être tous dans votre dossier / traitement / script (parfois appelé pitch, document de fonctionnalités et histoire). puis à partir de là, vous feriez votre truc doc technique qui a vos modèles et diagrammes.

il y a des entreprises qui utilisent UML, mais ce sont généralement des entreprises qui ont des équipes de conception et de mise en œuvre distinctes. les sociétés qui créeront toute leur documentation, puis la remettront à une équipe de singes-code pour créer un prototype / alpha. il est dit que si vous pouvez modéliser votre jeu avec précision, vous devriez pouvoir le donner à une équipe complètement différente et les faire programmer, bien que ce soit plus un rêve de pipe qu'une précision.

Ils vous enseigneront l'UML dans votre université pour vous aider à communiquer vos idées au reste de votre équipe et montreront aux enseignants que vous avez une bonne connaissance pratique des principes de base du génie logiciel.

Comme toute discussion sur le langage, les outils ou la conception - cela se résume généralement à la façon dont VOUS l'utilisez. Choisissez le meilleur outil / langage / design pour le travail et sauvegardez votre choix avec une justification solide. J'admets que UML n'est pas si flexible pour la production de jeux, bien que je puisse dire que nous l'avons utilisé efficacement pour modéliser des fonctionnalités de moteur telles que les communications réseau et la synchronisation, la gestion des tâches parallèles et les cas d'utilisation. Il n'y a rien de pire que d'expliquer la même chose à 5 membres différents de l'équipe 10 fois parce qu'ils ne comprennent pas tout à fait. Voici la documentation, lisez-la.

En fonction de la solidité de vos conceptions et de la discipline de votre équipe, il peut être très productif de pouvoir modéliser vos propres constructions autour de celles qui n'ont même pas encore été démarrées et de savoir exactement comment elles fonctionneront en raison de la Documentation.

Malgré cela, vous entendrez probablement (et réaliserez durement) qu'il s'agit de DOCUMENTS VIVANTS, et à moins qu'ils ne soient révisés et mis à jour régulièrement, ils deviendront obsolètes rapidement et efficacement inutiles.