Analyse et conception orientée objet

Pour tout ce qui est fan arts, homebrew, shooters codés à la main, rip de sprites, doujins et toute autre productions artistiques ou logicielles faites maison.
Répondre
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

Salut les gens !

J'ai besoin d'aide par les personnes développant en orienté objet ( peu importe le langage )...

La syntaxe du C++ dans mon cas ne me pose pas vraiment de problème... J'ai été habitué à utiliser des langages de scripts proches du C ou du C++.

Ce qui me gène, c'est comment concevoir l'architecture d'un jeu ( voire logiciel au sens large ).

Je me renseigne sur le paradigme objet mais ont me montre juste comment coder tel ou tel fonctionnement sans réellement m'expliquer le processus de réflexion derrière.

J'ai tenté une approche "top-down", mais à chaque fois, jme retrouve à rajouter des trucs dans les niveau supérieur à mesure que je descend... ( en partant du contexte logiciel vers le joueur par exemple ).
En faisant l'inverse, "down-top", la cascade de modification se fait moins ressentir mais je continue de bloquer ( ou alors je cherche des problème là où je ne devrais pas en chercher )

J'en suis arriver à un truc du genre du schéma suivant ( je sais, ma modélisation n'est pas UML mais m'en fout ) :

Image

C'est le gros de l'architecture sur quoi je réfléchi depuis déjà longtemps xD

Je sais qu'il n'y a pas une seule manière de faire pour un "moteur de jeu"... J'ai lu que d'un coté, on avait pour par exemple un shoot, un moteur de jeu synchro sur le moteur graphique ( on affiche une fois que TOUT est calculé ) et dans le cas d'un FPS, un moteur de jeu à "fréquence fixe" en ayant un moteur graphique à "fréquence variable" ( on affiche même si le calcul n'est pas complet ce qui provoque des distorsions ).

J'ai du mal à me représenter la communication entre ces objets et qui fait quoi entre le contexte logiciel et le moteur de jeu ( qui pour moi est le chef d'orchestre ) dans mon architecture...

La création de la fenêtre et de tout le contexte logiciel ne me semble faire parti des fonctionnalités d'aucun des objets ( il est vrai que j'aurai pu choisir le mot classe à la place d'objet maintenant que j'y pense... ) dans mon schéma...

Donc est-ce que je me plante quelque part ? Est-ce que je cherche des problèmes là où finalement, il n'y en a pas ? :D

Pour la partie coding, c'est pas les ressources qui manquent sur le "comment coder ça ?"... Et j'en suis pas encore à faire l’algorithmie... J'en suis encore qu'à l'étape analyse et conception :)

Un autre truc qui me pose problème... C'est, "Où je fout mes classes/objets joueur, ennemi décors ? et comment ?"
Jme doute que ca sera une relation d'héritage "a-un" mais heu... Comment je fais pour les mettre dans mon logiciel ? xD

La réponse que je me suis trouvé, c'est une classe "ressources" ( à défaut d'un meilleur nom ) "gérée" par le moteur de jeu ( encore une relation "a-un" ).

Voilà :) merci de votre lecture et des futures réponses :))
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
MikeNeko
Jeune Pad-awan
Messages : 52
Inscription : 29 avr. 2012, 14:23

Hmm...
Il faut et c'est bien que tu le fasses, toujours décomposer un problème complexe (comment je fais un shoot ?) en sous-problèmes de complexité moindre.

c'est ton programme qui va orchestrer le tout bien sur, pas le moteur ! :)
ton programme devra disposer:
d'un objet temps (tic tac tic tac pour maintenir la synchro son/framerate/saisie, la frame en cours tout ça...)

d'un objet saisieutilisateur (avec référence temps)
d'un objet graph (avec référence temps et device direct3D ou viewport opengl)
d'un objet son (avec référence temps)
d'un objet moteur (avec référence temps)
ces objets sont en scope global appli

tu crées d'abord le temps, le graph et le son puis tu crées le moteur en lui donnant en référence ses ptits copains.

ton moteur lui a
une liste d'objets de classe vaisseau joueur (1 ou 2 instances normalement)
une liste d'objets tirs amis
une liste d'objets ennemis (qui ont des sous classes par type)
une liste d'objets générateur de boulettes (c'est mieux d'avoir les générateurs de boulettes séparé de l'ennemi en lui même, ça permet de faire des patterns intéressants et réutilisables chez une lolipachi TTLB ou d'en instancier un différent en fonction du rank)
une liste d'objets boulettes
une liste d'objets bonus
un générateur d'explosions
une liste d'explosions
un générateur de particules
une liste de particules
et donc une référence vers le temps,les entrees, le graph et le son.
enfin bon tu y mets ce que tu veux hein ! a toi de voir en fonction de ton jeu

ton programme va à chaque rafraichissement:
demander à l'objet de saisie de capturer les entrées de l'utilisateur
demander au moteur de gérer son bazar
demander à l'objet son de mixer
demander à l'objet affichage de balancer la sauce

le bazar de l'objet moteur est de faire bouger le ptit monde, ajouter des éléments à ses listes, vérifier les collisions tout ça puis alimenter l'objet graph en appelant une méthode "ajoute moi un élément-à-afficher" autant de fois que nécessaire (cette méthode accumulera tous les appels dans une "displaylist" des éléments à afficher), avec leur priorité leur emplacement, les effets, et c'est tout (ça doit rester très con un objet spécialisé dans l'affichage, et surtout ce n'est pas son job de transformer un joueur vivant en un tas de cendre)... et l'objet son avec une méthode "joue moi ca" ou "coupe ! coupe !".

Si tu bosses en directx et que tu ne veux pas te prendre la tête, toute ta magie applicative tu pourras la balancer dans ton OnFrameRender ... c'est tout con mais c'est thread-safe comme endroit, et tu es certain qu'avant d'y arriver les périphs direct input auront été proprement disponibles et donc tu pourras appeler un joystick->Poll() sans risquer de perdre une précieuse frame de capture d'action... et ça permet de rester synchro et de gérer les ralentissements, car quand on débute le onframerender on peut alimenter en quads/tris texturés qui seront préprocessés et quand on sort de onframerender la page est balancée à l'écran tout comme X-OR se transforme, en une fraction de pétardième de seconde. Si tu détectes qu'il reste du temps avant d'être à ton 1.66666666 dixième de secondes de rendu , tu poirotes là jusqu'à arriver au bon tick d'horloge et PAN tu termines le onframerender.

personnellement je ne supporte pas l'objet pour faire des jeux (sauf en java, pas le choix mais je n'aime pas le JAVA xD) c'est trop de lourdeur pour rien une fois compilé même si ça rend le code plus lisible d'une certaine façon. Enfin je dis ça... je suis un vieux crouton hein faut pas m'écouter :)
Bon heu... bon courage hein ! c'est déjà bien de vouloir faire un truc comme ça et pas se contenter d'un gamemaker ou je ne sais quoi. L'apprentissage de la life.
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

Tu pars un peu trop dans le détail sur certain points, tu anticipes des besoins que je n'ai pas encore exprimé.

Mais en même temps tu me donnes des indices d'architectures plus loin dans les différents moteurs...
Va falloir que je lise et relise plusieurs fois pour bien voir et comprendre tout ca :)

Merci encore ^^
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
MikeNeko
Jeune Pad-awan
Messages : 52
Inscription : 29 avr. 2012, 14:23

Ahaha , la faute aux jambes de ton avatar ça si je me suis emballé ;)

Sérieusement, j'ai juste décrit du classique (tel que j'ai pu le faire par le passé), mais libre à toi de réinventer la roue !
Cela fait partie d'ailleurs du bonheur de ne pas avoir recours à un kit de développement tout prêt, la seul limite c'est ta tête :)

Documente toi bien, et roulez jeunesse !
Avatar de l’utilisateur
Radigo
Counter Stop
Messages : 7567
Inscription : 22 mai 2003, 17:31
Localisation : Paris
Contact :

Mike Neko t'a décrit un jeu synchro, et dans le cas d'un jeu "classique", "arcade", "shmup", c'est ce qu'il faut faire. Son idée de tictac qui fait l'horloge pour tout décrit bien ce principe et du coup toute la série d'opérations qu'il décrit. Je te conseille évidemment de partir dans cette direction sinon ça voudra dire se taper de l'évênementiel dans tous les sens ou autres joyeusetés).

Concernant tes questions sur "comment tout ça communique", avec un système synchro rien ne t'empêche de faire dans le bourrin. MikeNeko dit "ces objets sont en scope global appli", ça veut dire que toutes tes classes y ont accès. C'est plutôt gourmand/lent en général mais c'est bien pratique. Selon le langage que tu va utiliser essaye de trouver comment rendre des variables globales ("static" aussi) et rempli ces variables avec des tableaux d'instances de classes : ennemis, boulettes, switchs, etc... Ensuite, à chaque tic du tic tac tu parcoure tes listes et tout le monde s'agite en même temps.
"HYPER GAGE : 500%"
Image
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

En cherchant de la doc, je suis tombé là-dessus...

http://khayyam.developpez.com/articles/ ... hitecture/

J'ai tout lu... C'est... Ca va trop loin pour ce que je veux faire en premier lieu xD
Est-ce que c'est une bonne base pour moi ? ( jveux me restreindre à de la 2D dans un premier temps et faire un premier truc simple... )
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

Bon...

J'ai compris où ca allait pas xD

En fait, mauvaise habitude prise avec gamemaker...
Je sautais une phase d'analyse permise par gamemaker.

En gros, j'exprime un besoin, et je tente de le modéliser directement. Ca marche avec gamemaker, mais pas avec un langage compilé et avec un vrai paradigme objet derrière.

Toute la phase analyse était court-circuitée ^^

Je vais donc reprendre des projets beaucoup moins ambitieux qu'un jeu dans un premier temps.

J'avais commencé à écrire des fonctions pour un logiciel. Les fonctions fonctionnent en mode console, jvais intégrer ca dans une GUI en utilisant la bibliothèque CeGUI.

Pour la suite, on verra quand j'aurais terminé le bordel ^^

D'ailleurs, me suis posé une question qui n'a pas grand chose à voir...
Une des fonctions que j'avais développé, utilisait d'une part des nombres entiers et un nombre à virgule flottante.

J'avais fait un truc du genre :

Code : Tout sélectionner

float maFonction ( int a , float b , int c )
{
return (a*b)/c;
}
Et le compilateur refusait de compilé en me parlant du typage qui n'allait pas. J'ai résolu le problème en passant tout le monde en float, mais ca me gène car mes entiers sont des entiers stricts et lire dans mon code que les variables sont floats pour des entier, ca me plait pas xD

Et je comprend pas pourquoi... C'est peut-être expliqué dans mon bouquin et j'ai oublié ce qui fait que ca m'a surpris car je n'ai pas souvenir de ce genre d'avertissement...
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
Avatar de l’utilisateur
niluge
Radiant Silverpost
Messages : 1247
Inscription : 29 juin 2006, 15:29
Localisation : Above and beyond

Tu ne peux pas faire ce que tu veux de la manière dont tu l'écrit, car les entiers et les float n’étant pas codé en binaire de la même manière, les circuits pour réaliser les opérations ne sont pas les mêmes (renseigne toi rapidement sur les Floating Point Unit et le codage des float pour comprendre).

je te propose de garde le même prototype de fonction qu'ici, par contre il faut réaliser un "cast" (conversion) de tes entiers au moments de l'opération.

Ce qui donnerait quelque chose comme ça :

Code : Tout sélectionner

float maFonction ( int a , float b , int c )
{
return ((float)a*b)/(float)c;
}
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

Merci niluge pour cette précision ^^

Je me souviens de cette histoire de cast, j'irai relire ce qu'il en est dit dans mon bouquin.
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
Kushullein
Brute du bouton A
Messages : 225
Inscription : 05 juil. 2011, 00:46
Page Facebook : https://www.facebook.com/TheOneManArmyGameStudio
Localisation : Nîmes
Contact :

Hello,

Petit nouveau que je suis (lecteur occasionnel du forum et des news depuis pas mal de temps, je ne participais pourtant jamais),
je me permets de m'incruster aujourd'hui sur ton post !

Quel environnement as tu choisi finalement, (pc windows , le langage, le compilo etc) ?

Je peux peut être essayer de t'aider ou de t'orienter un peu, enfin je crois.
Si tu as toujours envie de te lancer.

je m'incruste dans les topics mais je suis sympa, enfin je crois ... :D
Gunny
Empereur Bydo
Messages : 3404
Inscription : 15 mai 2006, 15:26
Localisation : Rayon chaussettes du Kiabi du coin
Contact :

Tu auras remarqué que je me suis gardé de parlé de langages ou quelque technologies que se soit ;)

Pourquoi ?

Parce que bien avant le choix du langage qui peut mettre des contraintes sur la conception/intégration, j'ai des problèmes en amont du choix du langage...

Les explications sont valable pour tout langage orienté objet. A partir de ces explications, je peux autant partir sur java que c++ que C# ou encore delphi...

J'ai eu une question sur un point particulier qui n'avait rien à voir avec l'analyse et conception, mais plutot sur les rouages mathématiques des types. Et donc carrément sur les routines gravées dans les procos. Ce qui apriori ne concerne aucun langage non plus ^^

Je continue de me pencher sur mon petit projet, et plus je réfléchi et fait de schémas, plus je trouve de "solutions"...

Faudra juste les tester voir si elles fonctionnent toutes :D
Si t'as un truc électronique cassé, ça se passe par là https://www.atelier-electrodd.fr/

-Je comprend rien à ce que tu dis...
-Pas grave... C'est pas en vivant plus longtemps qu'on deviens moins con.
Répondre