LionEngine (Moteur 2D en Java)

**DjThunder** · 03/09/2012, 00h12

Hello,

Après une longue absence, je passe pour donner quelques infos sur l'avancement pour la v6.0.0:

- Moteur [en cours]
- Module plateforme [terminé]
- Module RTS [terminé]
- Présentations (slides) [terminé]
- Tuto (wiki, site, code snippet, exemples progressifs) [terminé]
- Module Shoot'em Up [en cours]
- Module Multijoueur [en cours]

Concernant la partie multijoueur, je suis en train de faire une démo avec Mario, et pour le moment il est facile de gérer le multijoueur entre X joueurs sur une map, et ce, de manière efficace (en envoyant le moins de données possible sans sacrifier le gameplay).
Les connections des nouveaux joueurs sont notifiées pour chacun d'eux (il est donc aisé de créer les entités à la volée lors d'une connexion).

La partie suivante va consister à synchroniser le jeu plus en détail (interactions avec les monstres, objets...).

Pour le moment, l'architecture est à mi-chemin entre du bas et du haut niveau. Afin de laisser le plus de choix possible quant à l'implémentation du système de réseau, j'ai opté pour une solution encodage/décodage en byte combiné à un typage de message.
Cependant, une fois l'implémentation bas niveau (encodage/décodage) terminée, tout le reste est vraiment facile d'utilisation.

En gros, si vous définissez votre type de message: EntityMessage (qui va contenir les infos de déplacement, et les corrections de placement si besoin), vous devrez implémenter vous même le décodage et l'encodage du message (rien de bien compliqué cependant). De fait, vous pourrez contrôler totalement ce que vous enverrez sur le réseau (il est évident que gérer le multi pour 4 joueurs sur un petit jeu de plateforme n'est pas la même chose qu'une partie de RTS avec 8 joueurs et 100 unités chacun).

Je verrai lorsque j'aurai plus de recul sur mon travail si je simplifie encore les choses, au détriment du contrôle... où si je compense avec une bonne doc.

L'avantage pour le moment, c'est qu'il est possible d'ajouter une couche multijoueur directement sur un système solo.
Entre d'autre terme, il suffira de déclarer une entité comme étant "Networkable", d'utiliser le modèle de base en délégation et d'implémenter les méthodes d'application de message (pour mettre à jour les entités des autres joueurs). Ensuite, il faudra ajouter au "World" (lui aussi de type Networked) les entités qui sont sujettes à une mise à jour sur le réseau, et la partie cliente est gérée automatiquement.

En parallèle, j'ai préparé des tutos complets et expliqués, sur une utilisation pas à pas des différents composants.

Cette version a venir ne ressemble plus beaucoup à la version précédente, puisqu'elle est tout simplement plus facile à utiliser. Je ne sais pas du tout quand elle sera prête, sachant que mon stage de fin d'étude se termine, et que la suite s'enchainera rapidement.
Dans tout les cas je privilégierai la finition afin de ne pas avoir trop à y revenir par la suite.

A bientôt !

**DjThunder** · 24/09/2013, 20h55

Juste un passage rapide pour vous donner des infos a propos de l'avancement.
L'état actuel est disponible sur GitHub depuis peu, je laisse le lien pour ceux qui désirent avoir les sources actuelles (ce n'est pas encore la version complète !)

https://github.com/DjThunder/lionengine

Après une longue pause, le développement garde maintenant un rythme constant, en espérant aboutir prochainement à une release définitive !

Bonne lecture

**LittleWhite** · 24/09/2013, 21h09

Presque une année depuis le dernier message. Qu'est ce qui a changé dans le moteur ?

**DjThunder** · 24/09/2013, 22h12

La face visible de l'iceberg n'a pas trop changée, mais la face cachée a elle beaucoup évoluée.

Une des dernières grosses évolutions par exemple est la gestion des collisions qui est en fait parfaite et simple à mettre en oeuvre.
La gestion des map tiles a été largement revue pour être plus propre.
La gestion de la caméra est totalement intégrée à l'environnement (une map tile peut s'afficher très simplement en prenant comme paramètre une caméra, possédant un champs de vision défini, et calé sur les mouvements d'une entité)
Ou encore la gestion des projectiles, des effets (explosion...), ou bien la gestion des effets sonores.

Il y a aussi pas mal d'évolutions mineurs, comme l'externalisation de choses plus ou moins standards, sous forme d'interface, afin de limiter la complexité des classes, mais surtout pour permettre une ré-utilisabilité maximale.

L'initialisation même du moteur a été revue (voir exemple en page d’accueil du repository).
La documentation a également été complétée en profondeur, surtout sur les classes bas niveau.

J'avoue que pour le moment je ne peux pas dresser un tableau comparatif des différences avec la version précédente, car ce n'est pas ma priorité.
L'objectif du moment est de mettre au point la démo de Lionheart avec cette nouvelle version (et pas un prototype comme on peut trouver en Applet sur mon site), soit un niveau totalement jouable au plus proche de l'original.

Warcraft est également de la partie (bien que j'ai arrêté pour rester sur Lionheart d'abord). J'ai un ralentissement sur le pathfinding groupé (pour gérer parfaitement le déplacement d'un groupe d'unité, chose qu'il manque dans la v5). L'idée est qu'il soit facile de le mettre en place pour tous.
Tyrian subira également un lifting, afin de le mettre à jour.
Puis je reprendrais la section Multijoueur, en complétant la version multijoueur de Mario.

Voilà, pas mal de choses faites, et encore beaucoup à faire

J'ai pensé au GitHub afin que chacun puisse suivre petit à petit l'avancement, pour rentrer dans le bain plus facilement lors de la release.
De plus, cela peut me permettre d'avoir des retours sur des souhaits ou fix à faire.

**LittleWhite** · 28/09/2013, 11h49

En tout cas, cela semble très prometteur

**eclesia** · 29/09/2013, 20h25

Histoire de faire un peu plus sérieux :
- passe ton projet sur maven
- suit les conventions de formattage java
- met les headers de license sur tous les fichiers
- ajoute le tag @author

bonne continuation.

**DjThunder** · 30/09/2013, 00h42

Salut,

Je suis souvent ouvert aux critiques / remarques, mais moins lorsqu'elles manque d'argumentation.
Cela me donne plus l'impression d'avoir des remarques d'un professeur sur une copie corrigée.

Aussi ce sont des questions que j'ai longuement étudié, et c'est également l'objet de débats sans fin, mais voilà mes raisons:

Pas de maven pour le moment, j'estime que c'est complexifier pour l'utilisation visée (contrainte également pour l'utilisateur). On peut être sérieux aussi sans maven.
J'ai choisi mon formatage après de longues réflexion, et je trouve plus lisible ce choix (qui n'est pas un cas isolé). Ce projet reste à titre perso, seul les *.JAR sont voués à êtres utilisés par des personnes tierces. Se faire plaisir est aussi important.
La question de la licence, à quoi bon la mettre partout quand il en existe une à la racine ? Débat également récurant, et cette solution évite une forte redondance.
Le tag author me semble peut approprié dans un projet comme le mien, où je suis le seul à travailler. Il est évident que je suis l'auteur des classes que j'ai écrite, qui par ailleurs sont tracées dans git. Un peu comme la licence, j'évite la redondance.

Si je fais erreur sur un/des points, sache que je suis toujours ouvert à des explications

**divxdede** · 30/09/2013, 14h45

Bonjour,

Le cas de la licence est particulière.
Aujourd'hui, la licence s'applique même à un seul fichier de ton projet.
L'important est donc que si quelqu'un réutilise un bout de ton projet (en reprenant qu'une classe par exemple), il ne puisse pas dire "Je n'avais pas vu que c'était Open-Source".

C'est pourquoi on réplique un Header de licence sur tous les fichiers afin que personne ne puisse "ignorer" la licence en réutilisant tout ou partie d'un projet.
L'header d'ailleurs ne se substitue pas à la licence elle-même qui doit être effectivement présente le plus souvent à la racine du projet.

Pour l'auteur, c'est un peu la même chose, en cas de reprise d'une partie d'un projet, on doit connaitre l'auteur. En cas de réutilisation, ce n'est pas ton dépot (git,svn,etc...) qui va informer le développeur de l'auteur réel.
D'ailleurs, sur ton git tu peux avoir commiter un fichier dont tu n'es pas l'auteur car toi même tu peux reprendre un code venant d'un autre projet.

Pour moi ces deux informations sont fondamentales pour un projet "publié".
Pour un projet perso qui n'a pas vocation de sortir de chez soi, on s'en moque carremment.

Pour le reste des remarques (indentation & maven), je n'ai pas d'avis tranché, à chacun ces préférences.

**DjThunder** · 30/09/2013, 20h19

Bonsoir,

Merci pour la réponse détaillée.
Je vois, c'est donc plus par prévention.
J'ajouterai ça sous peu. Par contre je verrai plus tard pour le @author, je n'ai pas trouvé d'outil permettant de compléter une javadoc de classe (d'autre priorité que de faire un script).

A bientôt pour de nouvelles évolutions

**eclesia** · 30/09/2013, 20h33

Envoyé par DjThunder

Je suis souvent ouvert aux critiques / remarques, mais moins lorsqu'elles manque d'argumentation.
Cela me donne plus l'impression d'avoir des remarques d'un professeur sur une copie corrigée.

Mes remarques n'ont pas pour but de te rabaisser. je te mets juste sur la voie en ce qui concerne les plus grosses différences avec ce qu'on trouverait dans une projet qui a vocation a être utilisé par d'autres.

C'est ce qui est écrit sur ton site :

The engine is as a library, in Jar format (including its javadoc), which can be included in any project; for utility class uses, or to directly implement and inherit a game skeleton ( including management of frame rate, extrapolation, input output...).

Si c'est une librairie, on s'attend a avoir le format d'echange classique, donc maven. Rien que monter le projet dans l'IDE c'est deja plusieurs minutes. un petit pom.xml, ant ou ivy, peut importe mais se serait deja mieux que rien.

Pour le formattage, c'est afin d'aider les autres a contribuer. on trouve deja peu de bienfaiteur sur les projets amateur, alors n'amenuise pas tes chances avec un formattage inhabituel.

A propos des headers et @author, divxdede a expliqué le probleme ^^.

Mais si tu veux des encouragements, je peux aussi. tu documente plutot bien. tu as divisé ton code en bloc spécifique. (quasiment l'equivalent de module maven)
tu penses a la portée de tes classes/variables.
Bref c'est deja un projet amateur au dessus de la moyenne.

**DjThunder** · 30/09/2013, 21h30

Hey re,

Non non, je ne passe pas sur un forum uniquement pour chercher des louanges; c'est juste que j'avais trouvé ton commentaire disons, un peu 'RAW'

J'ai donc du en faire une mauvaise interprétation.

Mais comme tu le vois, je me suis appuyé dessus pour creuser le sujet.

En fait je pense que mon utilisation du dépo maven n'est pas comprise.
Il me sert d'une, à déposer mes sources (

) (j'avais mis en place un serveur perso avant, mais j'ai trouvé ça inutile à la longue et source problème pour pas grand chose), et ensuite c'est juste pour laisser en libre accès continu (et pas à la fin d'une release) les sources pour les plus curieux.
Mais en fait je n'attend aucune contribution; il faut plutôt voir ça comme une vitrine.
Après la release, je met les JAR sur mon site, et c'est tout (un simple download, lier la/les lib à un projet et voilà).
Le flot de version n'est pas suffisant pour recourir à maven me semble t-il.
Peut être que j'y passerai, mais ce n'est pas à l'ordre du jour pour le moment.

Niveau formatage, ce que tu décris par inhabituel doit être les accolades en retour de ligne ? Car pour le reste, hormis les 120 lignes (80 appartiennent au passé pour ma part depuis les écrans 16/10 et la fin du papier pour le code), c'est du classique.

Bon allez, sur ce il me reste encore des choses à faire.

PS: Et merci pour les encouragement

**franck06** · 02/10/2013, 21h52

salut !

j'étais déjà passé sur ton topic, t'as pas laché l'affaire c'est top !
moi ce que je trouve manquant, ce sont des tutoriaux simples, pour apprendre rapidemment à sortir un truc avec ton moteur
c'est bien de refaire le jeu lion, mais peut etre qu'une démo de tilemap, une démo de scrolling, une démo de sprite qui bouge a l'ecran, une démo de collision, une démo de physique, une démo de déplacement de caméra ... ça serait plus attrayant pour des utilisateurs éventuels ...

d'ailleurs certains t'ont fait des retours et ont utilisé ton moteur ?

**DjThunder** · 02/10/2013, 23h24

Salut !

Oui je sais, et c'est ce que je fais actuellement dans cette version.
Si tu jettes un oeil au dépôt, tu y trouveras 4 tuto orientés jeux de plateforme (une sorte de mario pas à pas) et le prototype de Lionheart. Autant côté Rts avec un warcraft pas à pas. Et pour finir même chose sur un Shoot'em up.
Tout cela se trouve dans le module lionengine-examples. Il y a même un pong des plus basique.

Je les ai intégré directement dans les sources du moteurs afin qu'ils me soit plus facile de les mettre à jour lorsque je modifie le moteur.

Là je passe également encore un peu de temps sur les docs des classes afin de donner le plus d'information sur leur fonctionnement.

Au niveau des retours oui, j'ai eu des personnes qui m'ont contacté depuis le mail de mon site, afin d'avoir des infos, de l'aide, ou des remarques.

Voilà voilà !

**franck06** · 03/10/2013, 09h33

et un truc auquel je pensais, c'est qu'avec Android, il est beaucoup plus interessant de sortir un jeu sur téléphone qu'en standalone sur PC

j'avais fait à l'époque 2-3 jeux en java 2D, intérêt très limité en standalone et un peu plus en applet à l'époque

avec Android, si t'as la possibilité de migrer ton moteur dessus, n'hésite pas ça pourrait interesser beaucoup plus de monde qu'un moteur standalone java

**jehal** · 03/10/2013, 12h55

Je suis tombé sur ton moteur ce matin et j'ai vraiment apprécié. Une petite question cependant, ou en est la partie réseau ?

Je pense l'incorporer à mon projet. Je te contacterai sous peu par mp de toute façon

HONOR for you !

Et bravo bravo bravo

**DjThunder** · 03/10/2013, 18h44

@franck06: Suite à ta remarque (et d'autres que j'avais eu par le passé), je suis en train d'élaguer les dépendances vers les truc genre AWT de java, afin que toute la partie haute du moteur soit totalement libre.
De fait, je ne devrais avoir qu'un travail mineur pour supporter un autre moteur de rendu (Android).

J'ai pas dis que j'étais en train de le faire, mais je prépare le terrain pour ce genre de chose

@jehal:

Elle n'a pas bougé depuis l'exemple Mario en réseau, mais elle reste au programme.

**jehal** · 04/10/2013, 14h26

Merci pour les infos, je ne l'ai pas trouvé mais il doit etre quelque part. En revanche j'ai remarqué pas mal de post de remarque sur le fait que ta doc n'est pas a jour. Tu leur réponds que la v6.0.0 sortira avec une doc à jour, tu as une date de sortie de la v6 à me communiquer ? C'est pour bientôt ?

Désolé du harcelement, mais j'accroche un max a ton moteur

**DjThunder** · 04/10/2013, 17h30

En étant ambitieux j'espère la fin d'année (si je reste sur ce rythme).
Sinon en étant plus réaliste ce sera plus probable pour début 2014.

Décroche pas d'ici là

@franck06: Petite info d'avancement: voilà, j'ai totalement retiré les utilisations directes d'AWT pour le moteur. La seule partie concernée est le nouveau module lionengine-java, qui implémente le moteur à base d'AWT.

A priori, si c'est bien fait (en prenant en compte le fait que je n'ai jamais utilisé Android), il devrait être facile de rendre compatible le moteur avec Android.
Il suffirait de créer un module lionengine-android, implémenter les interfaces du module lionengine de la même façon que c'est fait dans lionengine-java.

Dans le genre "new feature", voici un exemple de contrôle de la taille dynamique et du temps (bullet time):

http://www.b3dgs.com/v6/projects/lio...e_temporal.mp4

Bon, les deux sont en même temps, c'est pas super agréable à voir comme ça, c'est juste un exemple brut.

**Vetea** · 05/10/2013, 21h23

Excellent travail ce moteur !!!

Super travail et de ce que j'ai pu voir sur ta démo, c'est vraiment du boulot de pro !!
Avec les ressources et bien sur du code, on a toute les cles pout realiser un bon petit jeu 2d !

Je n'ai jamais eu l'occasion d'utiliser un moteur cle en main comme le tien mais je reste fidele a mon bon vieux QB64 procedural ... Mais j'apprecie qu'une personne puisse aider par son travail des createurs indé !

Bravo !