Discussion :

[Aladore]

Bonsoir tout le monde ! (:

J'ai commencé le projet de créer un Sokoban 3D. Je sais que ce n'est pas génial, mais bien que je connaisse le C++ et le Java, je n'ai jamais rien programmé sauf de mini projet sans interêt. Mon projet avec ce sokoban: faire un jeu d'une qualité professionnel.

Je veux dire par là, un jeu auquel on prendra plaisir à jouer, et qui soit agréable à regarder.

Bon le soucis, c'est que j'ai tellement le soucis du détails que j'aimerai bien savoir si l'architecture que j'ai commencé est bonne. Je joins le code source au topic, est-ce possible que quelqu'un regarde et me donne son avis ?

C'est du Java. (:
Merci d'avance! ^^

[Djakisback]

Salut,
une analyse est évidemment faite à l'appréciation de chacun ^^.
Personnellement je trouve ton code très propre.

Au niveau de la conception, il y a des choses qui me choquent (Mais j'ai encore plus le souci du détail que toi ) mais qui fonctionnent quand même très bien. Pour moi un moteur physique n'a pas à savoir qu'il manipule des maps ou des players et doit être réutilisable pour n'importe quel jeu, idem pour le moteur graphique, que d'ailleurs tu n'as pas encore implémenté mais j'imagine qu'il va gérer des Element.
Si tu penses réutilisabilité, alors je dirais que la conception n'est pas très bonne, sinon dans le cadre limité du jeu je trouve ça très bien.

Toujours dans la vision de découpage/réutilisablité du code, l'utilisation d'interfaces pour grouper des objets est dommage car tu stockes des entités à un plus bas niveau qu'ils ne devraient l'être dans la hiérarchie des classes. Pour ça il y a plusieurs solutions, étendre un élément physique ou étendre un élément graphique; personnellement pour faire la liaison entre un objet graphique et un objet physique je passe par la notion de container. Un élément du jeu contient donc un élément graphique et un élément physique.

[Aladore]

Au niveau de la conception, il y a des choses qui me choquent (Mais j'ai encore plus le souci du détail que toi ) mais qui fonctionnent quand même très bien. Pour moi un moteur physique n'a pas à savoir qu'il manipule des maps ou des players et doit être réutilisable pour n'importe quel jeu, idem pour le moteur graphique, que d'ailleurs tu n'as pas encore implémenté mais j'imagine qu'il va gérer des Element.
Si tu penses réutilisabilité, alors je dirais que la conception n'est pas très bonne, sinon dans le cadre limité du jeu je trouve ça très bien.

En fait, j'ai remarqué que je pouvais changer tout les Element[][] et Element en PhysicItem. Le soucis, c'est qu'au final ça ne change pas grand chose puis que ça ne sera pas ré-utilisable pour n'importe quel jeu. Le fait de manipuler une Map c'est juste pour récupérer le layer statique et physique de la map en fait, je ne suis même pas obligé de la stocker.

Pour le moteur graphique, il manipulera des GraphicItem. L'interface permettera de récupérer le modèle associé à l'élément, puis le GraphicEngine va se charger d'encapsuler les appels à OpenGL.


Merci pour la deuxième partie de ton message ! A vrai dire, j'étais tellement habitué à C++ que je me suis posé la question toute une après midi sur comment j'allais gérer le fait de me dire "Un Element est un objet graphique et un objet physique". Je n'avais rien trouvé de mieux qu'à passer par une interface, et à stocker des données (qui auraient du se retrouver plus haut dans la hiérarchie) dans la classe Element. =/
Je crois que je vais retravailler mon code pour utiliser ton approche, qui me semble nettement meilleur que ce que j'ai fais là. (:


Merci pour ta réponse! ^^