Bonjour à tous !

Pour mon grand retour sur le forum création de jeu (je ne sais pas si vous vous souvenez de moi... ) j´ai une question de la plus haute importance.

Je suis actuellement en stage de deuxième année d´IUT Informatique et je dois concevoir une structure réutilisable pour créer plusieurs types de jeu sur téléphones mobiles/PDA. Je travaille donc avec le langage J2ME sous Linux.

Mon architecture est déjà bien avancée et je commence à implémenter des mécanismes de jeu redondants notamment pour des jeux de type Shoot them up et plate-forme (que j´ai choisi de prendre en considération.)

L´un de ces mécanismes sur lequel je me penche actuellement est le scrolling. J´ai étudié l´exemple de jeu conçu avec la SDL (avec le petit DBZ qui se heurte aux murs) de fvirtman - ancien JYY que je salue ^^ - et je me base dessus pour le scrolling. Avant d´aller plus loin, j´aimerais savoir comment vous feriez pour implémenter un tel mécanisme dans une structure pensée objet afin qu´il soit le plus indépendant possible et réutilisable (à la limite votre point de vue sur une approche diagramme de classe UML m´intéresserait.)

Voilà, en vous remerciant d´avance amis développeurs,

Alex6891

Je vais avoir du mal a t´aider car je connais pas le java, je fais pas d´objets pour des trucs unique (scrolling=unique),je fais jamais de code reutilisable car ca sert a rien et je fais pas d´UML Voila, desolé.

ma réponse sera simple...
tu fais ton scroll comme avec la sdl...

Ce que j´aimerais savoir, d´un point de vue objet, sachant que j´ai une classe PlateForme qui va créer un jeu de type Plate-forme, c´est comment lui rattacher ce mécanisme du scrolling pour qu´une autre type de jeu (classe Aventure par exemple qui créé un jeu d´aventure) puisse si besoin est utiliser aussi le scrolling (sans avoir besoin de réécrire dans chaque classe le même code pour l´affichage) ?

Fondementalement, il n´y a aucune difference entre afficher un truc, et afficher un truc pour que ca scroll. Le definlement c´est simplement afficher un truc plus large que l´écran, mais ca reste de l´affichage. Maintenant il existe des dizaines de methodes pour faire des scrollings et je pense pas que tu puisses creer une classe magique qui puisse te faire toutes ces sortes.

Tu utilise des tiles ? une map ?

Vouloir créer une classe qui puisse etre utiliser pour n´importe type de jeu est une utopie a mon sens, car tous les jeux sont differents. Ca va bien plus vite de modifier le code pour les besoins.

Cependant si tu fait une classe trés bas niveau (genre, lire une map, des tiles et afficher le plan avec le decalage souhaite) alors ca peut etre reutilisable. Cependant ensuite, il faut que ce decor ai les meme proprieté pour tout tes jeux : Par exemple,un shoot em up, il faut gerer les collision alors que dans un jeu ou ton scroll c´est juste pour le decor, tu n´en auras pas besoin. Donc au final ta classe, elle risque de continue 1000 trucs qui serviront a rien suivant les jeux.

"Par exemple,un shoot em up, il faut gerer les collision"
C´est pas le scrolling qui fait ca...

La classe tres bas niveau est réutilisable, le seul truc qu´elle doit faire c´est décaler une zone d´affichage sur un décor. Les collisions, le calcul de l´affichage ou n´importe quoi d´autre c´est géré par autre chose.

Je crois que cet article de kamron traite du sujet :
http://www.kamron.net/french/prog/coupling.php

"C´est pas le scrolling qui fait ca..."

A partir du moment ou tu veux faire de l´objet, tout ce qui touche à ton decor doit etre regrouppé. Si tu dissocie ton scrolling et tes collision et bien a mon sens tu ne fais plus de l´objet.

Maintenant si ta classe, c´est juste afficher des trucs alors c´est pas vraiment un objet, c´est juste des routine bas niveau qui font l´affichage. Dans ce cas, pas la peine de se poser des questions, pour moi un scrolling n´est pas fait dans les fonctions d´affichage, c´est fait dans un objet plus haut niveau qui va gerer le scrolling.

Merci pour l´article de Kamron, je l´avais jamais lu celui la. Ca rejoint ce que j´ai dit, c´est qu´il faut dissocier les fonctionnalité, mais a un certain niveau seulement.

Il le dit lui meme : "une fonction d´affichage fait l´affichage, le moteur de jeu dit quoi et comment". C´est le cas pour le scrolling, c´est le moteur de jeu qui dit comment afficher pour creer l´effet de scrolling. (car en effet souvent on reaffiche tout, le moteur de jeu calcul les decalage et les objets a afficher, et voila un scrolling).

Donc si le scrolling n´est pas fait dans le trés bas niveau, il est fait au niveau d´au dessus, donc dans un objet qui serait "decor" et qui donc doit gerer aussi les collision. En tout cas, c´est comme ca que je fait dans le decoupage de mes jeux.

Ci joint l´architecture de DNA par exemple :
http://www.gosg.org/viewtopic.php?topic=530&forum=31

Lapintade quand tu parles d´un objet "decor" qui gére aussi les collisions, je ne comprends pas trop... En fait je n´arrive pas à voir comment la classe Decor fonctionnerait...

Admettons qu´elle soit de plus haut niveau comme tu dis, dans ce cas elle ne s´occupe pas de l´affichage (ce que tu mettrais dans du bas niveau) ? Que fait-elle alors ?

Merci pour vos réponses en tout cas c´est sympa

Je fait mes architecture en forme de pyramides. (comme tu peux le voir sur le graph dont je t´ai donné le lien). Le premier objet c´est un "Game Manager", celui qui appel tout le reste. La couche d´en dessous, on va trouver tous les gros modules du jeu, genre les trucs qui bougent, le decor, les interfaces. Donc quand je parle d´un objet decor c´est une classe trés haut niveau qui s´occupera de tout ce qui touche au decor (dont l´affichage, les collisions, les differents plans si il y a besoin, les effets graphique). Cependant c´est du haut niveau comme tu dis. Je considere qu´un scrolling se gere en haut niveau (calculer l´emplacement de toutes les tiles suivant la valeur du scrolling. Ensuite il commange au module d´affichage bas niveau d´afficher les tiles a tel ou tel endroit. Le bas niveau n´a pas de notion de scrolling).

Dans l´ancien temps (mon temps ), on faisait les scrolling en bas niveau. C´est a dire qu´on decalait tout l´ecran avec ce qui existait deja dedans et on recopait les quelques nouveaux pixels sur les cotés. C´etait plus optimisé. De nos jours je pense que ca sert plus a rien de faire comme ca. Autant tout reafficher. Ca simplifie tout.

Vu que tu fais de l´objet et du java, je suppose que tu as une certaine puissance disponible sur les machine ou tu travaille (sinon tu ferai de l´asm). Donc il serait plus interressant pour toi de faire ton scrolling dans tes classes haut niveau et de laisser l´affichage pure dans le bas niveau.

Justement pour ce qui est de la puissance et des contraintes de complexité je suis plutôt limité car je développe cette structure pour téléphones portables...

Pour que vous compreniez mieux l´avancement de mon travail actuel, je vais résumer ma conception :

J´ai une classe abstraite "Jeu" qui contient les méthodes creerJeu() - pour créer un type de jeu -, setKeys() - pour effectuer une action lorsque le joueur appuie sur telle ou telle touche -, updateGameScreen() - pour mettre à jour l´affichage de la scène de jeu - toutes les trois implémentées dans les trois classes filles "Reflexion" (pour les jeux de reflexion type puzzle), "STU" (pour les jeux de type shoot them up) et "PlateForme" (pour les jeux de type plate-forme.) Une autre méthode buildGameScreen() propre cette fois-ci à la classe "Jeu" s´occupe de contruire l´écran initial de jeu (indépendamment du type de jeu.)

En gros pour l´instant selon que j´instancie un type de jeu, j´ai un écran différent en fonction du jeu (pour ça je me suis aidé du design pattern Builder pour ceux qui connaissent...)

De plus, j´ai commencé à implémenter la notion de scrolling pour le jeu de type PlateForme en créant une classe "Carte" qui se charge de charger une map en fonction d´une image chipset et du tracé de la carte (je traite les couleurs de ce tracé pour placer des murs, un sol, etc. sur la map finale.) et qui affiche une partie de la map. Mon scrolling n´est donc pas encore définit puisque je dois changer cette affichage lorsque le joueur se déplace (il me reste donc implémenter le sprite du joueur qui se déplace sur l´image ce qui n´est pas encore fait car je n´ai pas voulu "m´enfoncer" dans une conception trop mauvaise pour devoir tout refaire proprement après...)

Comme un jeu comporte plusieurs niveaux et donc plusieurs cartes, je pensais créer dans ma classe abstraite "Jeu" un tableau de Cartes vide et le remplir depuis sa sous-classe "PlateForme" par un "new Carte(chipset,tracé,x,y...)" mais je doute de cette méthode...

En effet, j´essaie surtout d´avoir une approche particulière qui consiste à séparer au possible l´affichage / la mise à jour de l´écran après chaque action de jeu et le coeur de l´appli (tout ce qui n´est pas graphique comme la gestion des collisions ou le scrolling peut-être...)

Je me dis aussi que deux types de jeu différents peuvent avoir des éléments en commun et qu´il serait sans doute souhaitable de ne pas les recoder en dur à chaque fois (et donc d´introduire une forme de redondance du code.) Par exemple les jeux de shoot them up et de plate-forme on en commun des sprites / des tiles, le mécanisme de scrolling (que les jeux de type réflexion (puzzle) n´ont pas)... Mon travail est d´essayer de distinguer ce qui dépend vraiment du type de jeu (ce qui doit obligatoirement et systématiquement être implémenté à chaque fois) et ce qui peut être rendu abstrait (ce qui peut être commun à plusieurs jeux.)

J´espère maintenant que vous comprenez mieux ou je veux en venir et pourquoi j´ai ce genre de problèmes

Merci pour vos conseils. J´ai créé ce topic pour que vous m´aidiez à découper les éléments d´un jeu en plusieurs couches et que vous n´hésitiez pas à critiquer mon travail c´est à dire mon approche du problème (c´est ça qui me fera progresser!) Dites-moi ce qui va, ne va pas, peut être amélioré, comment vous feriez votre découpage et abstraction du problème si vous étiez à ma place ?

Au sujet de la separation gestion/affichage, tu as tout a fait raison, c´est comme ca que c´est fait dans tous les jeux (enfin les bons). En ce qui me concerne, dans chaque classe j´ai toujours une fonction "update" (qui fait la gestion) et une fonction "display" (qui fait l´affichage). Il ne faut jamais melanger les problemes.

Comme j´ai un peu réflechit cet aprem, j´aimerais vous faire part de mon approche pour que vous me disiez si ça colle ou pas :

- ma classe PlateForme (PF) créé une map et l´ajoute au tableau de Cartes de sa classe mère.

- PF créé des Personnages non joueurs et les ajoute au tableau de PersonnagesNJ de sa classe mère.

- PF appelle la méthode Display() de la classe Carte, qui affiche la zone de la map qu´il faut pour la carte en cours.

- PF appelle la méthode Display() de la classe PersonnageNJ, qui affiche les personnages non joueurs sur la zone de la map affichée précédemment pour tous les personnages non joueurs (ennemis, valable aussi pour les items, pièces, etc.) de la map en cours.

- PF appelle la méthode Display() de la classe Joueur qui affiche le héros (donc le joueur) sur cette même zone.

On aurait donc une classe Jeu (la classe mère de PlateForme qui ne contient en gros que deux tableaux (celui des cartes du jeu et celui des éléments du jeu sur la carte)), sa sous-classe PlateForme qui créé un objet de type Carte, pleins d´objets de type Personnages (ou Element dans l´esprit) puis qui appelle les méthodes Display() pour l´affichage de la Carte, et de ses éléments selon qu´ils y figurent ou pas.

Néanmoins je suis moyennement sûr de cette approche et deux questions se posent alors : Comment et où gérer les collisions ? Quand savoir réafficher quoi ?

Merci

Je n´ai pas le lu le topic, donc j´esoère que je suis pas à côté de la plaque. Mais voici un topic intéressant sur les algo. de collision :

https://www.jeuxvideo.com/forums/1-31-8465061-1-0-1-0-0.htm

Merci Qosimo, c´est vrai que j´écrit beaucoup, mais c´est pour tenter d´être clair !

Je suis la même chose, je t´en veux pas!

Le sujet que tu m´as donné est intéressant, certes, mais il ne correspond pas à mon souci actuel (j´aurais sans doute à me poser cette question des collisions à un moment ou à un autre quand même ^^)

Là je suis complétement perdu ! Alors que j´ai beaucoup de difficultés à schématiser en UML mon architecture, voilà que je tombe sur deux Framework déjà faits : Jade (
http://jade.pautrot.com) et Genuts (
http://www.genuts.com)...
Les deux sont très bien pensés et Genuts a même été développé pour PDA et téléphones mobiles avec la j2Me...
Je viens de me rendre compte que le projet Genuts, c´est dans l´idéal ce que j´aurais dû faire pendant mon stage et voir tout ça maintenant après un mois de stage sur deux ça me démoralise
Que faire ?

Est-ce que le découpage objet suivant vous paraaît correct ?

- Une classe Carte (pour les maps)
- Une classe Perso (pour les sprites)
- On créé des objets de type Carte et Perso depuis le type de jeu sélectionné.

Merci de me donner votre avis

Tout depends si tu veux que ton code corresponde a du code dis "professionel". Si c´est le cas, reduis au *maximum* ton nombre de classes, utilise des array statics par exemple, etc: jar plus petit (ce qui est important si tu veux faire qqchose qui est multiplatformes), fragmentation de la memoire grandement diminuee (et garbage collector plus rapide du coup), etc
Ensuite il n´y a pas d algo parfais pour un scrolling, certains algo vont etre rapides sur certains tels/pda, alors qu ils seront tres lents sur d autres (car par exemple il est plus lent d afficher 20 tiles que une map tiles en contenant 20). (et ne pas oublier que les tailles d ecran varient)
Comme je le precisais au debut, c est uniquement si tu desires faire du code dis "pro" et qu effectivement tu vas essayer ton prog sur differentes machines.

/kUfa