Projet de RPG en réseau et de framework se basant sur la SFML.

[Lolilolight]

Salut,

Je développe actuellement un projet, basé sur un frawework que je gère grâce à la SFML, Qt, openssl, gmp, boost et d'autres librairies. (Le framework possèdera un petit éditeur de jeux RPG en 2D dimétrique.
Le moteur graphique du jeux est en 2D dimétrique pour être correct. (3D isométrique par abu de langage.)

Mon framework possède les avantages suivants :

-Un moteur de lumière et d'ombre.
-Une grille pour stocker et récupérer toutes les entités qui sont dans la partie du monde qui est visible à l'écran de manière rapide.
-Un design de code bien conçu : (Des conteneurs pour accéder aux systèmes et aux composants, des systèmes pour mettre à jour les composants et charger ou libérer des ressources, des composants et des entités qui peuvent hériter de une ou plusieurs interfaces si elles sont dessinable, transformable, etc...)
-Le framewok utilise les avantages du c++11. (multi-threadé utilisant les primitives de syncrhronisation du c++11 avec un thread pour la mise à jour des entités animées ainsi que pour la récupération de tout ce qui est visible à l'écran, un thread pour l'affichage et la gestion d'évènement (le main à cause des limitations de l'os), un thread pour l'IA et la physique et un dernier pour la communciation réseau.)
-La synchronisation verticale pour éviter de bouffer trop de CPU et d'avoir un effet de tiring.
-Un éditeur de map qui possèdera en plus (quand j'aurai le temps de le faire.) un éditeur d'animation, un éditeur de quêtes, un éditeur de sors, etc...
-Et pleins d'autres avantages que vous découvrirai par vous même.

J'ai encore quelques petites choses à améliorer au niveau du code pour que ce soit vraiment parfait.

Le projet en est plus au moins à la moitié il reste à améliorer un peu le design du code pour vraiment profiter de toutes les nouveautés de la SFML2, car, j'ai commencé le projet avec la SFML1.6 donc...
Et encore quelques petites choses à rajouté au niveau du gameplay (les quêtes, les objets/l'équipement, les compétences, le tchat et la minimap.) ainsi que le son que je n'ai pas encore testé avec la SFML mais que je ne vais pas tarder à tester.

Je déciderai en fonction de ma situation financière si je peux le rendre opensource ou si je rend commercial pour essayer de percer dans le monde professionnel. (Vente, pub, etc...)

J'ajouterai quelques images et vidéos par la suite avec le FPS en haut de l'écran pour prouver mes dires. (Mais il faut que je trouve un bon logiciel pour filmer qui ne saccade pas trop on verra si ça va mieux maintenant que j'ai passé ça en multi-thread.  )

Mais au niveau des graphismes je sèche pas mal vu que ce n'est pas vraiment mon domaine, mon point fort c'est plutôt le côté tehncique donc, ne vont attender pas à des personnages, monstres et animations formidables. :/

[Lolilolight]

Voilà 2 screens-shot de ce que l'on peut déjà faire actuellement avec le framework et l'éditeur de map.





Je mettrai une vidéo un peu plus tard dans la journée pour vous montrer déjà un petit aperçu de l'avancement du framework "in game".

[Lolilolight]

Voici le lien vers la 1ère vidéo, elle inclus en plus le moteur réseau et un début du système de combat. (Les graphismes et animations des personnages et monstres ainsi que les GUI seront à refaire.)

http://www.youtube.com/watch?v=5eN-RixyL-g&feature=youtu.be

Mais les graphismes ne sont pas la priorité pour l'instant, la prochaine mise à jour concernera surtout l'intégration d'un éditeur de quêtes.

PS : désolé pour la mauvaise qualité de la vidéo, j'essayerai de trouver un meilleur logiciel pour la prochaine. (Pas facile en logiciel gratuit. :/)

[Lolilolight]

Salut, je compte finir l'éditeur et après je mettrai surement les sources de l'éditeur et du framework à disposition, avant de finir mon jeux. ^^

Car j'aimerais bien avoir quelques retour là dessus.

[Lolilolight]

Re, je suis entrain d'améliorer le code soure du framework pour que chaque entité (monstre, personnage, tile, animation, ombre, lumière, etc...) aie leur propre transformation.

Après, je mettrai peut être les sources ligne.

[Lolilolight]

Re, l'amélioration du code source avance bien, je n'ai plus qu'à mettre toutes les entités qui ne sont pas semi-transparente dans une tileMap et le tour est joué.

[Lolilolight]

J'ai dit que ça avançait bien mais je n'ai pas énoncé les nouveautés à venir donc, je vai le faire :

-Le level designer pourra assigner à chaque tileset un nom, se sera aussi le type de l'entité, le framework fera une vérification si la texture contient de la semi-transparence ou pas, ceci permettra au framework de savoir si il peut utiliser le depthtest avec ma version personnalisée de la SFML pour accélérer le temps de rendu ou si il doit faire un tri.

Chaque entité pourra être dynamique ou statique, elle auront une position (le coin supérieur gauche de la box de l'entité.) et un centre. (l'origine de la transformation.)
Différente interfaces pemettront de définir les propriétés pour les entités personnelles.
C'est important pour améliorer le stockage de ses entités dans la grille du framework.

PS : les ombres et lumières utiliseront une render texture, en fait, tout le code sera adapté pour passer de la SFML 1.6 à la SFML 2.0.

[Lolilolight]

Suite à une trop grande différence de code design entre les versions 1 et 2 de la SFML, j'ai décidé de laissé tombé la mise à jour du code source et donc de ne pas faire mes propres entité transormable et dessinable mais plutôt continuer à utiliser les entités de haut niveau de la SFML. (Tant pis. :/)

Et puis ça devenait vraiment trop complexe au niveau du code :

-Changer la position z des entités autres que le sol dérivant de transformale et drawable dans les tilemaps pour les afficher dans l'ordre de celle qui est la plus éloignée à celle qui est la plus proche. (Plus facile de faire un tri et d'afficher bêtement les sprites un par un.)

-De plus ceci ne marche que pour les textures qui ne contiennent pas de semi-transparence donc il faut encore faire un test à chaque ajout de texture pour savoir si on peut utiliser une "tilemap" ou pas.

Bref tout ceci demande trop de modification au niveau du code source, sans être sûr que ça marche et rend le code source trop complexe, de plus, en devant faire plusieurs interfaces dont plusieurs dérivent d'une seule et même classe Entité, je me retrouve avec des problèmes d'ambiguité et tout les problèmes que l'héritage multiple en c++ pose car j'ai une sous sous classe qui dérive de 2 sous classes qui chacune héritent de entité. (TexturedEntity et DynamicDrawableEntity par exemple qui dérivent de DrawableEntity et TransformableEntity.)

-Et pour couronner le tout, mais ça c'es plutôt à cause de Qt je pense, lorsque je fais une classe IHM qui contient une QMainFrame et des méthodes statiques pour la créer et l'afficher, je me retrouve avec des crash donc j'ai décidé de laissé tombé ces idées de classes statiques et de conteneurs, désormais je fais tout dans le main, moins propre, mais moins d'emmerdes.

Non je pense que je ne vais pas chercher les emmerdes et continuer à avancer dans le projet en faisant l'éditeur de quêtes.

[Lolilolight]

Bon finalement j'ai réussi à trouver un design de code source pas trop compliqué pour implémenter les entités à la "SFML-LIKE" ce qui simplifie le code source du framework. (Car plus besoin de récupérer les entités enfants dans la grille pour leur appliqué la même transformation que à leur entité parent et de récupérer toutes les entités enfants lorsque je dessine le parent.)

Mais ce n'est pas encore terminé pour le moment il n'y a que le sol qui s'affiche, j'ai encore quelque soucis avec les tilemaps pour dessiner les murs et les décors mais ça devrai vite être réglé.

Une fois ça de fait j'adapte le code au serveur et au client puis j'entame l'éditeur de quêtes et la fin du projet.

Pour l'instant le framework ne gère que les lumières statiques mais se sera amélioré dans une version future.

[Lolilolight]

Bon ça progresse, je suis enfin parvenu à afficher les tiles et les ombres à la bonne position mais je n'ai pas encore tout à fait fini pour le code source de l'éditeur de map et vu que j'ai amélioré la structure du monde pour qu'elle ressemble plus à quelque chose comme la SFML2 j'ai du modifier aussi la structure des enregistrements des entités dans le fichier de sauvegarde. (Mais le plus lourd est fait.)

Le framework utilise maintenant un graph de scene avec un noeud (la classe DynamicDrawbleEntity) qui ne contient que la transformation de l'entité (position, centre, origine de tansformation, échelle, taille et rotation de l'entité, bref, c'est comme la classe sf::Transformable mais je l'ai refaîtes en plus complète.)
Elle contient bien sûr aussi un sf::transform qui est la matrice de transformation de l'entité et quelques autres informations comme l'id, le type et le "zOrder" car cette classe hérite de la classe DrawableEntity du framework (DrawableEntity hérite de sf::Drawable et contient en plus une composante Z, DrawableEntity hérite aussi bien sûr de Entity.)

Toute entité dessinable et transformable du framework devront dériver de ce noeud. (DynamicDrawableEntity) 
Certaines entités utilisent des classes haut niveau de la SFML comme noeud enfant les transformations sont donc combinées avec celles du noeud parent. (Bref exactement comme expliqué dans le tutoriel.)
Mais je suis content mon code source est beaucoup plus léger, ici, il suffit de combiner les transformations et de les passer à draw hors qu'avant je devais chercher les entités enfants dans la grille et les transformer.
Bref finallement je m'y retrouve mieux.
Pour le moment, une seule matrice de transformation par entité est possible mais, je pense que je vais laissé la possibilité d'en avoir plusieurs pour une seule et même entité plus tard au cas ou je devrais faire des transformations avec des origines différentes mais je préfère si moyen ne travailler qu'avec une seule matrice de transformation par entité. (Plus simple.)

[Lolilolight]

Bon finalement en combinant les transformations pour faire des transformations d'entités autour de plusieurs origines ça ne marche pas avec 2 matrices, donc, le framework utilisera un vertex_shader. (Plutôt que de faire les transformations vertex par vertex côté CPU.)

Je pense que tout les PC d'aujourd'hui vont supporter les shaders de toute façon.

[Lolilolight]

Bon finalement j'ai réussi à me passer des shaders, il suffisait juste que je combine le tout dans une seule matrice.

Mais les shaders seront quand même utilisés dans le framework pour d'autres choses, j'ai presque terminé là  ré-écriture du code source du framework.

Il ne me restera plus qu'à ré-adapter ça dans le code source du serveur et du client.
 

[Lolilolight]

Voila j'ai fini de ré-adapter mon code source mais je dois encore faire quelques codes minimes pour résourdre certains crash. (en plus ça ne crash pas tout le temps mais parfois donc c'est assez aléatoire bref...)

Cela arrive quand j'utilise les threads du c++11 et le réseau. (au chargement de la map)
Et parfois aussi lors de la connection, bref...

Une fois cela de fini je commence le gameplay et donc le jeux qui utilisera ce moteur.

Et si le moteur marche bien je l'améliorerai pour que l'on puisse aussi faire de la 3D avec.

[luciole]

Le projet peut être intéressant en effet