De l’importance du design document

Le jeu vidéo, c’est complexe a programmer. Des tas d’infos dans tous les sens, qu’il faut protéger des modifications importunes tout en les rendant accessibles à ceux qui en ont besoin, qu’il faut faire passer entre les threads, envoyer sur le réseau, sur l’écran, dans les différents systèmes.

J’ai toujours été un codeur instinctif. J’ai une idée abstraite de ce que je veux faire, et je la concrétise directement en code. Mais avec le jeu vidéo, principalement quand il s’agit de faire un moteur, la complexité est telle que soit je me noie dans les possibilités et je n’arrive a rien, soit j’oublie des trucs. J’avais donc besoin d’une méthode pour essayer de réduire le problème. La méthode que j’envisage est la suivante :

-D’abord, je précise le gameplay du jeu. Je le décrit en détail, sans m’occuper de la technique derrière. A quoi ressemblera le monde dans lequel le jeu se déroule ? Quelles actions les entités vont elles entreprendre, quelles sont les conséquences possibles des actions, comment le résultat est il décidé, qui ou quoi décide des actions entreprises, et selon quels critères ? Quelle interface est présentée au joueur ? Quel est le but du jeu ? Et tous les autres éléments de gameplay qui sont pertinents.

-Ensuite je traduis ces spécifications en flux de données. Qui a besoin de quelle info, qui effectue quelle action, et comment cette information transite ? Je note ca sur papier, ca servira de checklist.

-Ensuite UML. Je fais les structures de données, diagrammes de sequence sur la transmission des données, et tout ce qui est pertinent.

-Enfin seulement, je code.

J’amenderais surement cette méthode, probablement pour la simplifier une fois que je serais familier avec le processus et que j’aurais des technologies un peu éprouvées. Mais je pense que c’est une bonne base pour commencer.


Pathfinding

Un bon petit algo que j’ai trouvé sur le pathfinding. J’avais entendu parler des mesh de navigation, mais je ne voyais pas comment, une fois qu’on a la liste des triangles par lesquels, on en un chemin optimisé. Voici donc la solution : Le Simple Stupid Funnel Algorithm. Très intelligent, très rapide, a tester !


L’initialisation en deux étapes

Une contrainte sur laquelle je suis tombé il y a peu de temps. Afin de gérer la mémoire de manière fine, il faut utiliser des allocateurs. Des classes utilisant des allocateurs pour toute la gestion mémoire, a la place de new et delete, permettent de gérer la mémoire de manière fine, et de maitriser l’utilisation mémoire, d’éviter des problèmes de fragmentation mémoire, et d’optimiser les allocations.

Mais pour ce niveau de généricité, il est impossible de passer un argument au constructeur. Il faut séparer l’aspect allocation et l’aspect initialisation. Ça implique des petits changements dans le code, notamment le fait d’avoir une fonction init(…) qui initialise l’objet et le prépare à l’utilisation. Le constructeur quand a lui se limite du coup à une liste d’initialisation qui donne des valeurs par défaut aux membres.

Ça change pas mal de choses au final. Si on rajoute une methode cleanup qui remet la classe dans l’état où elle était après le constructeur, on peut alors réutiliser des classes. Pour les entitiés par exemple, on pourrait imaginer allouer à l’avance les unités, et les init/cleanup en conservant la mémoire. Je trouve ca très jeu console comme façon de voir, une façon d’allouer toutes les ressources disponibles à l’avance, de les répartir, et de s’y tenir après.


(c) Rewpparo 2010
Jarrah theme by Templates Next | Powered by WordPress