[C/C++] Gestion de la complexité

Le côté programmation du développement d'un jeu vidéo.

Gestion de la complexité

Messagepar Rewpparo » 30 Jan 2012, 16:00

Tout d'abord, je m'excuse du titre un peu cryptique pour un sujet qui me pose quelques problèmes. Il n'est pas strictement C++, mais je préfère avoir des avis d'habitués au mode de pensée C++.

Depuis des années maintenant, je m'intéresse à la création de jeux 3D. J'ai l'avantage de le faire en amateur, ce qui me permet de viser haut, j'ai le temps. Cependant, j'aimerais un jour sortir un titre et pourquoi pas passer pro (dans mes doux rêves).
J'ai beaucoup appris avec les moteurs que j'ai essayé (notamment Ogre, Irrlicht). J'ai également appris que pour faire le genre de jeu que j'ai en tête, il me faut des technos nouvelles. J'ai donc pris l'option de faire mon propre moteur. J'ai déjà fait des systèmes, comme une backend graphique, un moteur physique, je maitrise je pense suffisamment bien ces aspects pour l'usage que je veux en faire.
J'en suis au stade où il faut tout mettre en relation, et en faire un vrai moteur pour notre premier projet (j'ai un artiste 3D avec moi).
J'ai toujours eu un mode de programmation instinctif. J'ai les concepts dans la tête, sous une forme complétement abstraite, et je les concrétise directement en code. Mais cette forme de travail arrive a ses limites, et je me retrouve obligé d'apprendre a organiser et prévoir mon travail. Mes idées doivent donc prendre une forme intermédiaire. J'ai appris l'UML, je suis familier avec la syntaxe, et je pense donc utiliser ceci.

Le problème que je rencontre est double. Je n'arrive pas a faire un inventaire précis de ce que je dois modéliser. Dans un jeu vidéo, surtout niveau gameplay, il y a tellement d'interactions dans tous les sens et a tellement de niveaux que je m'y perd, j'en oublie, je ne prend pas tout en compte. Penser aux deadlocks, à la bonne transmission des données, a rendre les données accessibles à ceux qui en ont besoin et les protéger de ceux qui n'ont rien a faire avec, tout ca fait beaucoup, surtout en multithread.

Ma question concerne donc le travail que vous abattez avant de commencer le code sur un projet complexe. Que modélisez vous exactement ? A quoi faites vous attention ? Comment vous y prenez vous pour être exhaustifs ? Avez vous une méthode particulière à ce stade d'un projet ?
Avatar de l’utilisateur
Rewpparo
Hello World, I'm new !
 
Messages: 41
Inscription: 30 Nov 2007, 14:04
Localisation: La rochelle

Messagepar Aranoth » 31 Jan 2012, 13:38

Je modélise uniquement les données et leur flux. A partir de là, le code qui les transformera en découle naturellement et n'a même plus besoin d'être documenté.
Avatar de l’utilisateur
Aranoth
Hello World, I'm new !
 
Messages: 1327
Inscription: 10 Avr 2005, 00:10
Localisation: Montréal

Messagepar deathangel » 31 Jan 2012, 14:29

Pour ma part, je le fais toujours en deux fois. Un premier codage à la mode XP (Xtreme Programming) je code comme ca me vient à l'esprit avec les fonctions nécessaires pour voir si ca fonctionne dans l'idée générale. Puis une deuxième passe ou je reprends juste les fonctions utiles en remettant le tout en ordre et ca me donne mon appli.
95% des problèmes informatiques se situent entre la chaise et le clavier
--> Créez votre robot chien : http://doggyproject.free.fr/
--> Gagnez des PACK+ gratuitement : http://www.packbarre.com/
--> S.U.S Tennis de table http://www.sus.asso.fr
Avatar de l’utilisateur
deathangel
Hello World, I'm new !
 
Messages: 963
Inscription: 10 Avr 2005, 08:50
Localisation: Strasbourg

Messagepar Ono » 31 Jan 2012, 15:57

Pour ma part, pour mon dernier projet, j'ai fait un peu l'inverse. Je décrivais absolument tout mon processus de réflexion sur papier. J'écrivais tout, tout, absolument tout jusque dans les moindres détails, de manière simple et verbale (sans utiliser de méthode particulière, sans style particulier, juste écrire les pensées comme elles viennent), comme si j'étais en train d'expliquer à quelqu'un d'autre comment est sencé fonctionner mon projet. Poser toutes les questions non résolues par écrit, y répondre, et quand on ne sait pas y répondre, écrire de quoi ça dépend, etc... De sorte qu'au bout du compte je puisse faire des choix raisonnés en ayant tous les éléments en main, éliminer totalement le hasard.
Au bout du compte (ça a pris six mois) j'ai abouti à quelques centaines de pages de texte sans avoir touché à la programmation (enfin quelquefois je faisais des petits essais pour vérifier si tel ou tel point technique était faisable ou non, histoire de ne pas s'engager dans une voie sans issue). Bref au bout du compte j'ai abouti à un genre de pavé dans lequel tout a fini par devenir clair comme du cristal. Derrière, la réalisation c'était les doigts dans le nez, et exempte de bugs conceptuels car tout était déjà bien pensé en amont, alors qu'au départ ce projet m'était clairement inaccessible en terme de complexité, je n'aurais jamais su comment m'y prendre. Ensuite pour chaque upgrade de mon projet, j'ai appliqué la même méthode. Tout décrire sous forme de texte et seulement une fois que ça tient debout jusque dans les moindres détails sur le papier, passer à la réalisation.

Pourquoi j'ai appliqué cette méthode ? Dans mon cas, mon projet n'était pas un jeu à proprement parler mais plutôt un concept à développer, donc je n'avais pas une idée claire et précise dès le départ du truc terminé, seulement des pistes, beaucoup de pistes. Je n'ai qu'une seule vie donc je ne pouvais pas toutes les tester en vrai. Du coup, tout décrire sur le papier permet de se poser les bonnes questions, résoudre les gros dilemmes, simuler intégralement le truc dans sa tête, je ne dirais pas gagner du temps mais plutôt éviter d'en perdre de manière incontrôlée: éviter de se retrouver dans la configuration: "Ah merde j'avais pas pensé à ça, faut tout reprendre différemment" en cours de réalisation. Savoir dans quoi on s'engage à l'avance, savoir ce que telle direction choisie va impliquer comme sacrifices en termes de fonctionnalités et en avoir fait le deuil à l'avance.
Cette méthode me permet aussi de me souvenir de nombreux mois plus tard du processus de réflexion qui m'avait conduit à faire tel ou tel choix, et de le reprendre lorsqu'un élément nouveau vient le remettre en question, ça me dispense aussi de commenter mon code (j'étais tout seul sur ce projet, je lance pas un troll), mon code n'étant qu'une instance, une traduction du projet papier, si le projet papier tourne, le projet réel tournera.
Bref, cette méthode fonctionne bien pour moi, c'est un peu laborieux, mais ça me garantit de ne jamais finir "noyé", ce qui m'est arrivé bien trop souvent par le passé, c'est pour ça que j'en fais part. Je vois la ligne de texte comme l'élément atomique de travail sur un projet.

Avec le temps j'ai d'ailleurs étendu cette méthode à d'autres aspects de ma vie réelle. Lorsque j'ai des problèmes complexes à résoudre, des choix difficiles à faire, j'écris tout ça au kilomètre sur le papier ce qui me permet de me faire une bonne vue d'ensemble des choses et de prendre la meilleure décision possible.

Voilà, c'était peut-être hors-sujet car selon moi ça vient en amont d'une modélisation type UML, m'enfin si ça peut servir...
Avatar de l’utilisateur
Ono
Hello World, I'm new !
 
Messages: 300
Inscription: 14 Déc 2007, 21:20
Localisation: Rennes

Messagepar Rewpparo » 31 Jan 2012, 18:51

Merci a tous pour vos réponses ! Je pense que je fais faire quelque chose dans le genre d'Ono, on va se repencher sur le game design avec le collègue, et redescendre vers le code graduellement. Je pense que ca va bien m'aider.

D'autres commentaires sont bienvenus, cette partie la du design d'un jeu est nouvelle pour moi, et je pense que c'est l'étape finale pour accomplir mon premier projet.
Avatar de l’utilisateur
Rewpparo
Hello World, I'm new !
 
Messages: 41
Inscription: 30 Nov 2007, 14:04
Localisation: La rochelle

Messagepar Eva » 31 Jan 2012, 20:52

Le truc d'Ono, c'est grosso modo du waterfall ou du cycle en V. C'est bien quand on sait où on va.
C'est assez pourri quand les enjeux changent en cours de route. Mais bon, quand on est seul, qu'on a pas de client c'est potable.

Sinon, un bon truc, c'est d'avoir une conception incrémentale, si possible.
Avatar de l’utilisateur
Eva
Hello World, I'm new !
 
Messages: 651
Inscription: 31 Mai 2005, 15:43

Messagepar Rewpparo » 01 Fév 2012, 01:51

Je suis d'accord, et pour moi c'est important, ces capacités d'évolution. Ca l'a toujours été. Quand on fait un jeu, on se rend compte que le gameplay ne marche pas aussi bien qu'on le voulait, et il faut pouvoir changer pas mal de trucs, parfois en profondeur. Mais je me suis rendu compte que si je pars en me disant qu'il faut que je prévoie telle ou telle évolution au cas où, je me noie dans les possibilités.

Idéalement on a un design très modulaire qui permet de faire tout ce qu'on veut. C'est ca que je vise, mais sans une vision claire du strict minimum, tous mes designs faits a la volée ont échoué.

C'est pourquoi j'ai besoin de passer une marche, faire un design complet ou je sais où je vais, en en m'y collant. Une fois que j'aurais un jeu complet, je pourrais me concentrer sur un nouveau design qui prend en compte ce que j'aurais appris pour faire une structure qui permette un développement incrémental, de façon propre.
Avatar de l’utilisateur
Rewpparo
Hello World, I'm new !
 
Messages: 41
Inscription: 30 Nov 2007, 14:04
Localisation: La rochelle

Messagepar Eva » 03 Fév 2012, 11:31

C'est marrant, parce qu'on a eu une discussion vaguement en rapport avec ça hier, sur irc. Bref.

Il s'agit que de mon expérience qui s'applique davantage à la recherche qu'au jeu vidéo.

Se noyer dans les possibilités. Déjà, t'as pas de délais à tenir, donc c'est une très bonne chose pour toi : tu peux explorer autant que tu veux, prototyper des trucs relativement vite/mal écrits, garder ce qui te semble bon, réexplorer autour de ça... Ca peut être très incrémental, tout ça. Et c'est très bien.

Typiquement, ce qui se fait ici, c'est qu'une fois qu'on a un petit truc qui marche, on le garde de côté, on le réécrit proprement de façon à ce que "cet outil" en particulier puisse être utilisé sans aucun à priori particulier sur son utilisation.

En clair, ce que je te dis là, c'est qu'une fois que tu as un élément de gameplay qui marche, tu devrais essayer de passer le rasoir d'ockham dessus, jusqu'à ce que tu ne puisses plus rien enlever sans que ça cesse de fonctionner. Une fois que tu as cette version minimale de l'élément de gameplay, tu peux l'intégrer plus facilement dans autre chose. Bref, tu t'en sers comme d'une brique dans ta construction.

Bon, je rappelle que c'est une vision qui me vient pas du développement dans le jeu vidéo, hein.
Avatar de l’utilisateur
Eva
Hello World, I'm new !
 
Messages: 651
Inscription: 31 Mai 2005, 15:43


Retourner vers Programmation

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 13 invités

cron