[C++] Projet Asteroid 3D pour portfolio --> Simple mais complet

Salut à tous,

Môa
Je suis étudiant en informatique, et je développe un jeu pour mon portfolio.
Ce n'est pas mon premier projet, mais je voudrais que celui là soit beaucoup plus rigoureux. Je ne cherche pas à faire quelque chose de très ambitieux. Simplement, il faut que ça fonctionne du début à la fin. Le code doit être impec, bref, ça doit donner envie d'engager le programmeur qui a codé ça ! :yaisse2:

J'ai choisi le jeu Asteroids comme base. Le gameplay est simple, c'est donc parfait pour ce concentrer sur l'architecture du programme.

Mesdames et monsieurs devant vos yeux ébahis j'ai le plaisir et l'immense honneur de vous présenter en avant première.... Asteroi3Ds (ouais je sais, c'est vachement bien trouvé comme nom :aie:).

Caractéristiques du jeu
Basé sur Asteroids, je ne cherche pas à refaire un design document de 120 pages, on utilise le gameplay vu et revu de Asteroid.

Mais :

- en 3D (en gardant la jouabilité 2D, simplement pour le niveau technique). Je connais Ogre3D, je pense que j'utiliserais ce moteur. Pas de moteur physique, PhysiX est vachement bien, mais là on reste simple. Cela dit, il faut que ça pète dans tous les sens donc effets de particules, shader, enfin tout ce qui fait que ça peut en jeter >_<.

- le jeu ne se joue plus sur un plan mais autour d'une planète. L'objectif est de dégommer la ceinture d'astéroide de la planète en question (on ne contrôle pas l'altitude du vaisseau par rapport à la planète, on tourne simplement autour).

- la caméra bouge avec le vaisseau (contrairement au premier Asteroid dans lequel elle était fixe).

- Il faut une gestion du HighScore sur internet.

A part ça, c'est un Asteroids classique avec des asteroids dans tous les sens, des méga bombes à ramasser, du sang et des larmes :king:

C'est là que vous entrez en scène, camarades capitalistes, j'ai fait un premier jet pour le moteur du jeu et je voudrais votre avis (pas de code pour l'instant). Encore une fois, je ne cherche pas à faire quelque chose de compliquer, mais je veux que ce soit aussi optimiser que possible (en restant raisonnable hein ?! j'vais pas non plus aller farfouiller en assembleur pour gagner 2 fps).

Je ne cherche pas particulièrement quelqu'un pour coder. Par contre, mes sources seront libres.

un peu d'UML pour la route. Je n'ai pas ajouté de commentaires, mais j'ai essayé de donner des nom de classes évocateurs. Si vous avez des questions n'hésitez pas.
http://lemondedecharlie.com/Image/class.jpg

Alors voilà, j'espère que tout ça vous a inspiré.
Et si vous avez tout lu, et bin bravo... et merci ;)
A vos commentaires ! Soyez sans pitié.

Bye
Charlie

Salut Charlie111 ne passe tout de même pas 6 mois sur le design avec UML...
un Asteroids c'est afficher des meshes de vaisseau spatial d'étoiles et une bitmap en fond.
Après il faut trouver le bon gameplay...
Regarde dans les exemples du SDK de Direct X il y a déjà les sources d'un jeu d'Asteroid

Je n'ai pas l'intention d'y passer des mois, mais il faut quand même un minimum non ?!

Le fait est que j'ai jamais eu la confirmation à propos de mon architecture.
Elle est peut être bidon.
C'est pour ça que je demande l'avis de ceux qui s'y connaissent ^^.

Citation:

---

Envoyé par Charlie111

Le fait est que j'ai jamais eu la confirmation à propos de mon architecture.
Elle est peut être bidon.

---

Attention je n'ai pas dit cela ; c'est très bien mais il ne faut pas y passer trop de temps non plus

Juste pour chipoter :
à chaque fois qu'un astéroïde sera détruit il te faudra augmenter le score du joueur, et donc changer l'affichage du HUD : pour se faire à chaque fois tu devras passer par son playerController ?!
Puis imaginons que tu veuilles ajouter la vie d'un boss ou autre sur le HUD : tu devras encore passer par le playerController...
Le mieux est d'avoir le HUD en singleton et pourquoi pas en tant qu'observateur.
Si par un HUD par joueur tu entendais la possibilité d'avoir plusieurs joueurs, garde la même structure mais avec un HUDManager qui se chargera de transmettre les informations au HUD concerné.

Sinon pour tester si ton archi tiens la route pense plutôt à de petits cas concrets comme celui décrit précédemment plutôt qu'au fonctionnement global : lors de ta réflexion sur l'archi tu as déjà pensé au fonctionnement global :)

Bon courage !

Citation:

---

Juste pour chipoter :

---

au contraire, c'est ce que je veux :mouarf: 8-):aie:8-)

Pas bête le HUD en singleton, par contre qu'est-ce que tu veux dire par mettre le HUD en "observateur" ?
Cela dit, l'idée était bien de laisser la place à plusieurs joueurs. Donc pas forcément génial de mettre un singleton.

Je pense que je peux mettre un attribut Object* mTarget dans la classe Ship. Comme ça je pourrais atteindre les principales caractéristiques d'un boss ou de n'importe quel asteroid qui passe dans le coin (même d'un autre joueur).

Dans ce cas seul le HUDManager serait un Singleton et il s'occuperait de redistribuer les bonnes informations au bon HUD.

Je parlais du design pattern observateur ( http://come-david.developpez.com/tut...ge=Observateur) si un météore est détruit alors le HUD qui serait abonné à cet événement serait automatiquement notifié et mis à jour de lui-même.

Sinon tu as complètement passé sous silence les menus, à moins que ce ne soit les différents états de Game mais le mieux pour ça est de créer différentes Scene avec initialisation , update et destruction et l'une des scenes serait la GameScene soit le jeu lui-même.

Merci pour le lien ; très intéressant !

Citation:

---

Sinon tu as complètement passé sous silence les menus, à moins que ce ne soit les différents états de Game mais le mieux pour ça est de créer différentes Scene avec initialisation , update et destruction et l'une des scenes serait la GameScene soit le jeu lui-même.

---

Je pensais effectivement créer différents gameState. Et chaque gameState aurait la responsabilité d'une scene.

Sinon autre chose,
Ton archi ne comprends pas la partie graphique du projet, évidemment dans un jeu c'est une partie essentielle.
Si tu souhaites faire quelque chose de réellement exemplaire essais de faire une architecture gameplay qui ne soit pas dépendante de la partie graphique, voire coder une version 3D et une version 2D pour prouver que cela fonctionne ou carrément le même jeu avec 2 moteurs différents ;)
Bref si tu veux faire du Showcase y a de quoi faire !

Je suis complètement d'accord avec toi.
C'est pour cette raison que la partie graphique n'est pas présente.

Je vais d'abord implémenter le jeu avec Ogre3D.
Ensuite j'essayerais de coder moi même le moteur 3D en directX. (je connais déjà pas mal le langage mais je sais que ce sera du boulot ).

Par contre je ne suis pas sur de bien maitriser tous les éléments et j'ai peur d'oublier des trucs. Comment être sur que le gameplay est bien indépendant ?

Citation:

---

Envoyé par Charlie111

Par contre je ne suis pas sur de bien maitriser tous les éléments et j'ai peur d'oublier des trucs. Comment être sur que le gameplay est bien indépendant ?

---

Dans un premier temps bien entendu évite d'avoir des IDirect3DTexture9 dans ta classe Ship par exemple.
Ensuite il y a plusieurs moyens d'y arriver, fais une archi en conséquence et je te dirais si ça me semble tenir la route.

Bon courage :)

Enfait je pensais faire un pointeur vers un objet de la classe Entity (de Ogre3D) dans le classe Object, mais dans ce cas la modularité n'est plus vraiment respectée.

C'est la mon souçi, il faut que je fasse une classe exprês pour en quelque sorte parser le moteur graphique ?!

Dans ce cas j'ai plutôt intérêt à avoir X, Y et Z dans Object plutôt que de faire objectA->getEntity()->getPosition() (getPosition() étant une méthode de Ogre3D). Mais dans ce cas, à quel moment je passe la position de l'objet au moteur graphique ?
(Je sais pas si j'ai été clair ^^')

Tes questions sont légitimes et claires ne t'inquiètes pas ;)
Dans ta classe Object tu definiras plutôt une interface ( nommée IEntity par exemple ) qui te permettras de faire des get/set Position et autres...
Et dans ta dll qui gérera la partie graphique sous Ogre il te faudra créer une classe dérivant de Entity et de IEntity qui se chargera de faire le lien entre ton interface et Ogre.

Citation:

---

Envoyé par MoDDiB

Dans un premier temps bien entendu évite d'avoir des IDirect3DTexture9 dans ta classe Ship par exemple.

---

J'appuie à 100% cette remarque :D
Dans la mesure du possible essayer de faire des classes les plus génériques possibles si tu veux faire un portage sur d'autres plateformes ( Linux...)
Avec Direct X c'est un peu difficile je sais :( et pas évident de dégager les interfaces Direct X du code..

Mais donc si je comprends bien, pour chaque fonction que je veux utiliser utiliser le graphique je dois créer une autre fonction qui interprete le moteur graphique.
Ce qui donne :
Direct X/Open GL --> moteur graphique (Ogre3D) --> Parseur du moteur graphique --> moteur de jeu

Donc en réalité on fait un moteur graphique édulcoré basé sur un autre moteur graphique.
Et on doit perdre des performances...
J'ai raté quelque chose ?

Edit :
Je me rends compte qu'il y a un petit souçi :
Game inclus StateMachine qui inclus State
et State inclus Game (pour recuperer le SceneManager et tous ces trucs)
Du coup ça risque de méchamment pas marcher...
Je peux toujours passer le SceneManager en parametre ainsi que le clavier et tout le bordel... mais je voudrais savoir si il n'y a pas une solution plus simple et plus intelligente.
Merci ^^

La perte de performance ici sera du à quelques appels de méthodes supplémentaires soit largement négligeable.
Ce que tu vas coder en plus n'est pas un moteur graphique mais juste des appels vers les bonnes méthodes.
Et si un jour tu veux porter ton jeu sur un autre moteur il n'y aura que cette couche de code à réécrire.
C'est une vision à long terme mais c'est très couteux en temps sur le design original c'est pour cela qu'il faut bien y réfléchir avant ;)

Okd'accord, merci pour ta réponse, je vois bien ce que tu veux dire mais j'avoue que j'ai du mal à voir comment ça peut fonctionner concrètement.

Si je comprends bien :
On imagine que je dois utiliser le code suivant (code pour Ogre3D)

SceneManager *mSceneManager = new SceneManager(...);

Il faut que je créé une classe (avec un namespace propre) qui encapsule le code du dessus.

du genre
CreerSceneManager()
{
SceneManager *mSceneManager = new SceneManager(...);
}

Et donc pour chaque méthode que j'utilise qui vient d'Ogre3D je créé une autre méthode (dans le parseur) qui le fasse à la place.
C'est bien ça ?

Enfait, je n'arrive pas à bien visualiser quel type de méthodes je dois créer.
Ou comment remplacer les classes existantes; Par exemple, si je vais bien être obligé de garder en mémoire le SceneManager quelque part... hors si je faits SceneManager blabla; je fais appel à Ogre. Et je sais pas comment éviter ça... (peut être redéfinir le type ? mais même en faisant cela, ça ne change pas grand chose)
En bref, je suis un peu perdu là ^^'

Citation:

---

Envoyé par Charlie111

du genre
CreerSceneManager()
{
SceneManager *mSceneManager = new SceneManager(...);
}

---

Surtout pas !!
le scene manager est propre à Ogre ; il faudrait plutôt une méthode Initialize qui se charge de la creation du sceneManager pour ogre et la creation du device pour DirectX par exemple.

Tous les appels à Ogre se feront dans la surcharge spécifique à Ogre (dans une dll à part ) donc rien de grave.

Si tu n'arrives pas à bien visualiser le concept tente de le réaliser sur un tout petit projet ( du genre un bonhomme dont la position X , Y bouge et rien de plus ; tu visualiseras mieux le besoin....
Maintenant n'oublies pas qu'il s'agit de là de l'archi révée : tu n'est pas obligé de t'imposer ça :)

Okokokokok, j'ai fais quelques test et je commence à y voir plus clair.

Du coup je suis entrain de bosser un peu sur les design pattern, je pense que c'est la clef pour ce faciliter la vie (ou pas).

Citation:

---

Tous les appels à Ogre se feront dans la surcharge spécifique à Ogre (dans une dll à part ) donc rien de grave.

---

Tu veux dire que je dois écrire une dll qui utilise Ogre et qui contient des méthodes de type InitilizeGraphic, CreateObject,... ?! Enfait, à chaque fois que je veux utiliser Ogre dans mon exe, jme met 2 claques et je crée une méthode dans la dll qui fait appel à Ogre (bien sur je réfléchi à l'avance pour que ce soit fait de manière plus ou moins intelligente :aie:) (et merci pour ta patience :king:)

Citation:

---

Envoyé par Charlie111

Tu veux dire que je dois écrire une dll qui utilise Ogre et qui contient des méthodes de type InitilizeGraphic, CreateObject,... ?! Enfait, à chaque fois que je veux utiliser Ogre dans mon exe, jme met 2 claques et je crée une méthode dans la dll qui fait appel à Ogre (bien sur je réfléchi à l'avance pour que ce soit fait de manière plus ou moins intelligente :aie:) (et merci pour ta patience :king:)

---

Yep c'est bien ça :
je te souhaite bon courage ;)