Bonjour,

Voilà, étant encore (et pour encore un petit bout de temps je pense) débutant dans la programmation de jeux vidéos, je me suis décidé à monter un petit projet en SDL et C++. Je me suis donc mis comme objectif de créer un petit jeu de plateforme du type Mario.

J'y arrive d'ailleurs assez bien, avec l'aide de tutoriels dont je m'inspire (Lazy Foo, pour ceux qui connaissent), et j'en suis à un point où je peux parcourir un niveau avec une physique vraiment très proche d'un Mario (et dont je suis d'ailleurs assez fier), une gestion des animations, collisions, tilemapping et scrolling.

Mon problème principal est qu'à force de rajouter des éléments, mon code a pris une structure assez peu efficace, dont la structure pourrait être simplifiée grâce à la POO et qui, surtout, rendrait mon code bien plus réutilisable (ce qui fait parti de mon objectif via ce projet).

J'ai donc pris une feuille et un crayon et j'ai essayé de repenser mon système de classes. Le problème c'est que n'y connaissant pas grand chose, je ne sais absolument pas comment mettre en place une "bonne" architecture.
Je parcours pas mal le net pour essayer de trouver des solutions et idées mais je ne trouve rien d'applicable ou de suffisamment concret.

L'un d'entre vous aurait-il des astuces, codes sources (à titre d'exemple) ou même livres à me conseiller sur ce sujet ?

J'aimerais vraiment que mon code soit propre et pouvoir continuer sur de bonnes bases..

Si tu veux un très bon exemple d'OOP, jettes un oeil aux scripts de l'UDK (Development/Src/UTGame notamment).

Pour "simplifier" ton code, sépares un maximum les fonctions. Par exemple:

-Initialisation de la fenêtre
-Importation/Stockage des fichiers dans la RAM
-Physique etc etc

Fais un maximum de système réutilisable. Tu utilises des textures? Fais une fonction standard d'import de texture et place ce système dans son propre fichier (.cpp, .java etc). Il te suffira alors d'appeler cette classe/fonction/whatever un peu comme ça:

var Personnage1 = cGenerator.goodGuy(healthPoint, weight, speed);

Par exemple aussi, tu peux stocker ces "variables" (comme Personnage1 ici) dans un fichier différent. Il ne te restera plus qu'a lire les données de ce fichiers (vive le xml, entre autre)

Au final, tu te retrouves avec plusieurs classes, chacune ayant sa fonction (ou étendant une autre classe).

Niveau livre:
Object-Oriented Game Development - par Julian Gold
Object-Oriented Programming Using C++ - par Joyce Farell (cher)

Oui, je vois ce que tu veux dire. Mon problème reste que j'ai assez de mal encore à faire les bonnes distinctions pour me dire "là, faut que tu fasse une autre classe" ou bien encore "là, ta classe est mal foutue".

J'ai entendu parler de Design Patterns d'ailleurs, censés apporter des solutions d'architecture pour certaines utilisations (bien qu'isolées). Ca vaut le coup que je me renseigne aussi un peu là dessus ?

A part ça, le livre de Julian Gold est vraiment bien ? J'avais essayé de lire le début mais il ne m'avait pas assez convaincu pour que je l'achète (il me paraissait vraiment compliqué, l'anglais rendant la tâche légèrement plus ardue). Mais du coup s'il traite bien le sujet, il pourrait fortement m'intéresser..

http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

si t'as besoin d'aide, ya ce livre qui a recu de tres bonne critique (certe en anglais )(que tu pourrait peut être trouver en pdf) par contre, faudra adapter de la 3d à la 2d

Règle numéro 1 : Ecris du code seulement pour ton jeu, et pas pour ton prochain jeu.
Règle numéro 2 : Garde ton code simple, pas la peine de créer une classe pour englober une seule fonction.
Règle numéro 3 : Evite l'héritage et surtout les fonctions virtuelles pour tes entités, ça a un gros impact sur les performances d'itérer sur une liste d'entité et appeler des fonctions virtuelles. Préfère plutôt des structures simples.
Règle numéro 4 : Itère toujours des objets semblables. Par exemple, il vaut mieux itérer sur toutes les positions que sur toutes entités pour ensuite récupérer leur position.
Règle numéro 5 : Se passer de l'orienté objet n'est pas mal, dans la plupart des cas, ton jeu aura juste besoin de fonction et de struct contenant quelques variables. L'orienté objet aura un sens quand il s'agit par exemple d'englober les fonctions graphiques, ou bien pour rendre l'utilisation d'une machine à état plus simple.
Règle numéro 6 : Il n'y à pas de règle. Méfie toi des design patterns et des truc tout fait, il faut avant tout réfléchir à ton propre système, les design pattern ne répondent pas aux problèmes, ce sont plus des patrons qui vont t'aider à construire ta solution.

Pour le reste, les autres t'ont proposé des livres qui m'ont l'air intéressants.

3 Liens interessants :

http://gamesfromwithin.com/ ( notamment cette catégorie : http://gamesfromwithin.com/category/data-oriented-design )
http://www.altdevblogaday.com/
http://www.flipcode.com/ (mine d'or, ce site vient de ré-ouvrir, il y à beaucoup de vieillles archives, d'il y à plus de 7 ans, et des nouveautés depuis une semaine)

Merci pour vos réponses, je vais jeter un oeil aux sites/livres dont vous me parlez.

Il y a quand même quelque chose qui me chiffonne dans ce que tu dis Paulop. Tu dis de ne pas écrire du code pour un prochain jeu mais bel et bien pour celui en cours. Or, j'ai trouvé au fil de mes recherches énormément de développeurs mettant au premier plan l'aspect "réutilisable" du code.

Je suis d'accord qu'il ne faut pas utiliser une classe différente pour une unique fonction, mais n'est-il pas préférable de bien dissocier chaque fonction du code ? Même au détriment du jeu actuel (à une certaine échelle bien sur) ?

Le peu que j'avais lu du livre de Julian Gold ne traitait quasiment que de ça, c'est ce qui me semble un peu étrange.

Sinon, pour parler des héritages et fonctions virtuelles, c'est si violent que ça sur les performances ? Je ne connais pas d'autres méthodes remplaçant ce système mais il me paraissait avoir une réelle clarté pour tout ce qui était gestion d'états, ou de plusieurs entités justement (et à vrai dire je songeais à l'implémenter dans mon code).

J'avais fait un jeu de plateforme ("Dna"), je peux te partager le code.
J'ai même des docs qui expliquent l'architecture.
L'idée globale est de tout decouper en "manager" uniques. Chacun a des fonctions elementaires comme init / update et display. Une fois que tu as fait ça, tout devient plus clair en general.
Pour un jeu de plateforme, tu peux faire un système avec des elements que tu appelles des entités (en gros des trucs qui bougent). Libre à toi ensuite de mettre du code en comment et de faire de l’héritage si tu veut que ce soit très propre. C'est aussi expliqué dans mes docs.
Laisse moi un mail si tu veux que je t'envoie cela.

Chacun a son style de programmation. Moi je suis plutot "oldskool", c'est à dire que je programme très très simple. j'utilise le C++ et l'objet que lorsque c'est necessaire. Cela rejoins ce que dit Paulop.

"Règle numéro 1 : Ecris du code seulement pour ton jeu, et pas pour ton prochain jeu."

Oui tout à fait. Si ca se trouve tu n'aura jamais de "prochain jeu". Et puis dans ton prochain jeu tu reutilisera du code, meme si celui ci n'a pas été pensé pour cela.

"Règle numéro 2 : Garde ton code simple, pas la peine de créer une classe pour englober une seule fonction."

Oui aussi. J'ai beaucoup de fonctions "bas niveau" en C. Ce sont des fonctions uniques qui font une seule chose.

"Règle numéro 3 : Evite l'héritage et surtout les fonctions virtuelles pour tes entités, ça a un gros impact sur les performances d'itérer sur une liste d'entité et appeler des fonctions virtuelles. Préfère plutôt des structures simples."

Avant de parler de performance il faut savoir a quoi va servir l'objet et combien de fois il sera appellé. L'heritage permets souvent d'ecrire du code commun à beaucoup de choses qui ont un comportement identique. Pour un jeu de plateforme, tu aura beaucoup de chose qui vont bouger, certaines avec les meme caracteristiques physiques, d'autres qui seront controllable par le joueur ou par l'IA, etc, etc ... beaucoup de choses en commun. L'heritage peut aider ici. Mais rien d'obligatoire. Pour des fonction appellées une seule fois par "update", aucun problème de performance.

"Règle numéro 4 : Itère toujours des objets semblables. Par exemple, il vaut mieux itérer sur toutes les positions que sur toutes entités pour ensuite récupérer leur position."

Même remarque que plus haut. Si cette opération n'est faite qu'une seule fois par "trame" alors peu importe. Autant faire au plus simple (parcourir des objets et recuperer leur position).

"Règle numéro 5 : Se passer de l'orienté objet n'est pas mal, dans la plupart des cas, ton jeu aura juste besoin de fonction et de struct contenant quelques variables."

"L'orienté objet aura un sens quand il s'agit par exemple d'englober les fonctions graphiques, ou bien pour rendre l'utilisation d'une machine à état plus simple."

Fondementalement la POO n'est utile nul part. Tu peux écrire un jeu en C. C'est juste une commodité d'ecriture. C'est souvent pratique d'avoir une structure de données et des fonctions associées, une classe donc.

"Règle numéro 6 : Il n'y à pas de règle. Méfie toi des design patterns et des truc tout fait"

Jamais utilisé le "design patterns". Mais c'est toujours bien de penser son architecture avant.

gros +1 pour le init update render, une fois qu'on est habitué à en mettre plusieurs tout deviens beaucoup plus simple (genre dans une classe Ennemi par exemple, je met ces trois fonctions render dessine l'ennemi à sa position, init charge son image, et update gère ses déplacements)

Merci à tous pour vos suggestions ! J'ai encore du mal à imaginer comment mettre en place mon architecture mais ça viendra au fil du temps (et du code).

Par hasard, vous connaîtriez de bons exemples/tutos pour des State Manager ? J'ai encore du mal à cerner le concept (en POO en tout cas) et j'ai du mal à en trouver relatifs aux entités (j'en trouve énormément en ce qui concerne les états du jeu, par contre, mais j'ai du mal à faire le rapprochement).

Merci de préciser Lapintade que oui l'héritage peut servir, je voulais préciser mais j'ai oublié. Donc effectivement, des fonctions appelées une fois par frame, ça devrait aller, mais pour un système de particule assez avancé attention.

Il y a quand même quelque chose qui me chiffonne dans ce que tu dis Paulop. Tu dis de ne pas écrire du code pour un prochain jeu mais bel et bien pour celui en cours. Or, j'ai trouvé au fil de mes recherches énormément de développeurs mettant au premier plan l'aspect "réutilisable" du code.

Du code réutilisable dans un même jeu, ça s'appelle factoriser le code, c'est une bonne pratique. Par contre, n'essaie pas de coder ton jeu comme si c'était le suivant. Quand tu feras ton prochain jeu, tu vas soit ne rien réutiliser, soit tu prendra des petit bout et tu devras les adapter.

Une des principale raison pour laquelle les gens ne finissent pas leur jeu, c'est qu'ils veulent faire trop bien et au final ne font rien. En retouchant 30 fois une même classe, en essayant de coder un truc générique qui ne va jamais leur servir plus tard.
Quand tu auras fini un jeu, tu sauras que le plus important, c'est de finir un jeu, et pas de faire le meilleur code. Pour améliorer son code, il faut coder, ça prend des années, et donc, ça prend de finir des jeux (par exemple).

Voila, code envoyé.

Merci pour le code !

Je pense que tu n'as pas tort, Paulop, et c'est dès que je me rends compte que le code que j'ai n'est pas bien structuré que ma motivation s'en va (en même temps, difficile de se rendre compte qu'il va falloir remanier ce qu'on considérait comme acquis).

Je crois que je vais suivre ton conseil, essayer de finir mon Mario-like et ensuite je verrais bien qu'elles étaient les leçons à en tirer.

Lapintade, accepterais-tu de partager le code en question ? J'aimerais beaucoup voir un code fait par un vétéran

Envoie moi et mail et je te partage cela également.