Discussion :

[smartties]

Salut,

Je me présente, je m’appel Martin j'ai 20 ans et je suis étudiant à l'université. Je viens vous présenter un des projets sur lequel je travaille en ce moment : Exploration Craft




En savoir plus sur le projet
Genèse

L'origine du projet, est un projet scolaire portant sur la création et la manipulation de fonction pseudo-aléatoire ( bruit de perlin...). A partir de cette base, je pouvais générer des paysages "aléatoire" en 3D, et c'est à partir de ce moment que j'ai décidé d'en faire un jeu sur mobiles.

Généralités et avancement
Exploration Craft est un clone de Minecraft. C'est un jeu sandbox en 3D qui prend place dans un environnement cubique. Le jeu est actuellement jouable uniquement en mode "survival", bien que la partie multijoueur fonctionne, mais requièrent de nombreuses optimisations avant d'être disponible.

Objectifs
Dans un premier temps je souhaiterais améliorer les performances et la consommation de la mémoire.
Puis gérer la création de Biomes, améliorer le multijoueur ( n'est pas accessible pour tout le monde actuellement )
Et enfin je compte également porter le jeu sur IOS durant le mois de septembre si j'ai le temps.

Le projet et son originalité

Le projet n'a rien d’original. Le but du projet n'étant pas d’innové mais d'apprendre et acquérir de l’expérience en faisant un projet qui m’intéresse.

Les technologies utilisées

Le jeu est codé en C++ et j'utilise l'API graphique OpenGL sur windows et OpenGL ES 2.0 sur mobile et Fmod pour le Son. Bien qu'une version windows est disponible, je ne la distribue pas puisqu'elle n'est adaptée à la plateforme.

Téléchargement :

https://play.google.com/store/apps/d...plorationcraft

Voila, si vous avez des critiques/retours à faire sur ce projet, je vous écoute

[smartties]

Petite Mise à jour du jeu avec au programme :

- Amélioration de la génération de la carte. Avant j'effectuais le calcul dans un thread qui utilisait de la mémoire qui était également modifiée dans le thread principale, donc je devais faire des lock/unlock pour éviter toutes interférences.
Le problème c'est que le thread de calcul faisait souvent patienter le thread principal, rendant alors l'utilisation du thread inutile. (Le thread fait des calcul assez lourd et dure 40ms sur un téléphone : lire_fichier->générer->créer la géométrie->création vbo et cela pour chaque chunk de 16*16*16 blocs)
Bref, c'était mal implémenté. J'ai remédié à cela en séparant la mémoire nécessaire pour le calcul de manière à n'avoir plus d’interférences et d'attente entre les deux threads. Me permettant ainsi d'avoir un jeu très fluide.

- Correction de bug graphique

- plus de matériaux disponible

C'est la derniere mise à jour avant le portage sur IOS

[smartties]

Plop,


J'ai reçu mon iphone 5C la semaine dernière afin de porter mes jeux sur la plateforme d'apple.
Vendredi j'ai commencé le portage et bonne nouvelle j'ai fini le portage dimanche !




Si le portage à été aussi rapide, c'est grâce au peu de dépendances du projet : Opengl, pthread, fmod(pour le sond).
Il ne me restait plus qu'à réaliser les wrappers en obj-c++, optimiser les shaders, revoir la gestion de l'importation/écritures des fichiers/assets et enfin adapter les events multitouch.

Je pense ajouter encore un peu de contenu avant de soumettre l'application sur l'appStore (le week-end prochain).

[smartties]

Salut,
le jeu bénéficie d'une nouvelle mise à jour :


-Mode créatif et survival disponible
-Le joueur peut maintenant choisir parmi 6 personnages
-Refonte de l'interface graphique de l'inventaire et du menu des crafts
-taille du jeu réduit, pour un total de 4.2 mo
-Possibilité de voler en créatif
-Optimisation de l'affichage (avec un gain de 10% ) et de la génération des chunks
-Explosion des blocks de TNT (j'ai préféré le retirer du jeu pour l'instant, car ce n'est pas encore très bien optimisé).
-Ajout d'option pour modifier : la distance d'affichage, activer lumières/brouillard/ombres, ajuster la sensibilité de la camera
-Résolution d'un problème de shader sur certains téléphone, causant des chutes de fps considérable.
La cause était l'appel de la fonction smoothstep qui n'était pas implémentée sur certains GPU (mali-400, adreno 420...)
Au passage j'ai réussi à fixer ce bug grâce aux services d'amazon : https://aws.amazon.com/fr/device-farm/ qui vous permet de tester votre applications à distance sur un large panel de téléphones.
-Le portage sur IOS est enfin terminé et va être soumis sur l'appstore demain.


Dites moi ce que vous en pensez !

[smartties]

Le dév du mode multijoueur avance, j'ai encore pas mal de travail à faire, mais j'ai un prototype fonctionnel qui supporte 100 personnes de manière fluide dans les conditions les plus gourmandes pour le serveur.
En attendant que ce mode soit disponible, je publie une mise à jour avec du nouveau contenu, comme de la TNT, porte, escalier, lit, échelle...

[smartties]

Une version spéciale noël est disponible

• Des nouvelles textures
• plus de blocks, crafts et skin
• de la neige !
• correction d'un bug avec l'AI des monstres

https://play.google.com/store/apps/d...mine.snowcraft

[smartties]

Mise à jour en approche :
-animaux sauvages cochon/vache/
-biomes avec des villages pré-construit et des villageois
-intégration d'un système d'achievements et d'un leaderboard mondial
-un meilleur rendu graphique :

Avant


Maintenant



Pour le rendu, j'ai implémenté l'ambient occlusion. http://0fps.net/2013/07/03/ambient-o...t-like-worlds/

[smartties]

Après une petite semaine de tests avec le mode multijoueur disponible pour les joueurs, j'ai décidé de fermer les serveurs car leurs locations est plus coûteuses que la marge ramenée par ce nouveau mode.

Voila, je pense avoir atteins tous les objectifs que je m'étais fixé au départ de ce projet, donc je vais sortir la dernière mise à jour d'ici une semaine :

-les derniers bugs (éclairage des torches et de certains objets)
-ajouter une dizaine de nouveaux blocks (redstone, intérrupteur, ...)
-l'eau dynamique (qui est actuellement statique)

Après quoi, je passerais à un nouveau projet.
A bientôt !

[MoDDiB]

Essais ça : https://gamesnet.yahoo.net/
10% de revenue share au dessus de 5000 DAU.
Ca fonctionne plutôt bien et ils sont sur tous les continents !

[smartties]

Salut,


Bien que le développement du jeu soit terminé et travaillant déjà sur un autre projet, je continue de le maintenir avec des mises à jours mineures puisque de nombreuses personnes y jouent encore.


Cette mise à jour contient :


- Ajout de nouveaux npc : mouton, vache, cochon, panda et cheval.
- Possibilité de faire spawn des npc en créatif.
- Monter à cheval.
- Un nouveau mode de caméra : permettant de faire tourner la caméra autour du personnage.
- Correction du bug des dommages infligés par la TNT.
- Gros gain de performance : refonte du code sur le système de stockage des chunks maintenant référencés sur des std::unordered_map


Voila un gif pour illustrer certaines nouveautés :

[Kannagi]

tu fait pleuvoir des animaux
Je félicite le projet tout de même , je trouve le projet suffisamment bien fait et assez technique (et j'aime bien la technique) pour pouvoir te féliciter
Le jeu est fait en OpenGL et en C++ chose assez rare sur le forum (un jeu fait en 'bas niveau hourra)
Par contre je suis pas fan de Minecraft (je dirais meme que j'y joue pas) , mais tu as très bien fait d'en avoir fait un sur mobile c'est un très bonne chose pour que cela marche

Quel est ton futur projet ?

[LittleWhite]

Y a t-il une limite sur le nombre d'animaux ?
J'ai lu un article, récemment, indiquant que les std::unordered_map n'était pas toujours la solution la plus rapide (souvent "lamentable" sur les lookup). Si cette structure (table de hashage donc) est votre goulet d'étranglement, peut être il faut changer et prendre une table de hashage optimisé pour votre cas précis.

[smartties]

Salut et merci à vous deux !

Par contre je suis pas fan de Minecraft (je dirais meme que j'y joue pas)

Pour être franc, j'ai dû jouer à Minecraft un peu moins de trois heures dans mon existence . Bien que j'aime bien le gameplay, je suis plus intéressé par les différentes méthodes/algorithmes qu'implémente ce jeu.
C'est le genre de projet qui est simple à commencer (afficher des cubes), et au fur et à mesure demande de nombreuses optimisations pour avoir des performances acceptables. Il permet également d'aborder de nombreuse notions intéressantes.

Y a t-il une limite sur le nombre d'animaux ?

Non, il n'y en a pas. Après je pense que ce nombre restera bien en dessous de 1000 entités simultanées. Car lorsque un monstre est situé en dehors du rayon d'affichage depuis la position du personnage (réglable dans les options d'un rayon de 6 à 20 Chunks de distance), l’entité est détruite après que sa position soit sauvegardée dans un fichier. De manière à ne pas encombrer la mémoire. Il suit le même processus qu'un chunk. (les chunks sont des volumes de 16x16x16 blocks)

Quel est ton futur projet ?

Ayant une importante base de joueurs, il m'est maintenant plus facile de lancer un jeu et d'assurer son "succès", donc je continue à faire des petits jeux mobiles.

J'ai lu un article, récemment, indiquant que les std::unordered_map n'était pas toujours la solution la plus rapide (souvent "lamentable" sur les lookup). Si cette structure (table de hashage donc) est votre goulet d'étranglement, peut être il faut changer et prendre une table de hashage optimisé pour votre cas précis.

J'ai testé pas mal de conteneurs, ( http://yjliu.net/blog/2015/03/10/ben...-few-keys.html ceux cités sur cette page), et le std::unordered_map fût le plus rapide dans mon cas.
Un des désavantages de ce conteneur est qu'il peut se "réhasher" à chaque insertion/suppression. Mais l'insertion/suppression est négligeable comparé au nombre d'accès à un élément, qui est en revanche crucial dans mon jeu.

Si le jeu posséderais un bottleneck, il serait situé au niveau des drawcalls des chunks. Je pourrais le réduire en augmentant la taille des chunks (de 16x16x16 vers du du 64x64x64 par exemple), mais à ce moment là ça augmenterais le temps de reconstruction d'un chunk de manière générale.
Car à chaque ajout/suppression d'un block par le personnage, le chunk auquel il appartient ainsi que ses 6 voisins (pour des questions d'éclairages et d’optimisation de géométrie) doivent être reconstruits (géométriquement pour Opengl).
Les calculs sont fait sur un autre threads, mais l'upload de la géométrie vers Opengl se fait dans le thread principale, car Opengl l'impose.
Avec des chunks de taille 64x64x64 j'obtiendrais des petits lag à chaque modification du terrain, ce qui rendrait le jeu frustrant voir injouable. Tandis qu'avec une taille de 16x16x16 le délais de reconstruction du chunk est infime.
Donc pour le moment, n'ayant pas trouvé d'autres solutions, je préfère sacrifier un peu de FPS (dû au nombre de drawcall) au profit d'une stabilité des FPS et donc d'une meilleure jouabilité.

[LittleWhite]

Je n'ai pas lu cet article, mais je n'ai pas le lien.
Par rapport aux chunks de plus grosses taille, est-ce qu'il y a une gestion de depth of field ? Genre, les chunk au loin sont plus gros ? ça donnerait quelque chose, ou l'idée est débile ?

[smartties]

Par rapport aux chunks de plus grosses taille, est-ce qu'il y a une gestion de depth of field ? Genre, les chunk au loin sont plus gros ? ça donnerait quelque chose, ou l'idée est débile ?

Non ce système n'est pas présent dans le jeu, et je ne pense pas qu'il apporterait un gain de performance si grand que ça. Il faudrait que je test.
Puis le frustum réduit déjà énormément les drawcalls.

[smartties]

Nouvelle mise à jour du jeu :
-De nouveaux biomes/paysages
-ajout de coffre et système de stockage.
-Amélioration des performances : réduction du nombre de drawcall ( agrandissement de la taille des chunks )
-Possibilité de créer ses propre Skins :





Du coté technique de l'éditeur de personnage, l'enjeu était de récupérer les coordonnées UV suggéré par la position du curseur. J'ai donc essayé deux méthodes :

Pour la premiere méthode j'ai créé une deuxième texture de même résolution que la texture du personnage, sur laquelle j'assigne à chaque composantes Rouge et Vert de cette texture les coordonnées U et V de la texture en faisant à chaque points une interpolation entre les trois sommets du triangle. Ensuite en faisant un simple glReadPixels(souris.x, souris.y, ...), j'obtient directement les coordonnées UV sur lequel pointe la souris.

Pour la deuxième méthode, je fais un lancé de rayon en parcourant l'ensemble des triangles à la recherche d'une éventuelle intersection. Je récupère le point d’intersection le plus proche de la caméra puis je calcule les coordonnées barycentrique de ce point d'intersection avec le triangle auquel il appartient. Et dernièrement je multiplie les coordonnées barycentrique avec les coordonnées UV des 3 sommets du triangle et j'obtient mon UV final.

Une fois les coordonnées UV obtenue, il ne me reste plus qu'à peindre la texture, la mettre à jour...

J'ai finalement choisi de garder la deuxième méthode, car elle est plus portable et plus harmonieuse à mon gout

[LittleWhite]

J'ose croire que le plus souvent, c'est la technique du lancer de rayon qui est utilisée.
Sinon, sympa les évolutions

[Mat.M]

graphismes un chouia basiques mais c'est du bon boulot
bravo !

[smartties]

Merci !

J'ose croire que le plus souvent, c'est la technique du lancer de rayon qui est utilisée.

Oui, je pense que c'est également le cas, mais je me demande si cette méthode est plus lente que la premiere (qui se fait pratiquement sur que sur le GPU).
Et avec le nombre très réduit de polygones de mes modèles je n'ai pas pu tester quelle méthode était la plus performante de manière générale.

graphismes un chouia basiques

C'est le theme du jeu qui le veut . Plus sérieusement, je suis du même avis, malheureusement le graphisme/design ne sont pas mes domaines, je vais essayer de contracter des gens compétent pour améliorer ces aspects.

[CIRO31]

Bonjour, felicitation pour avoir réussie ton projet, j'aimerais bien connaitre les etapes de création que t'as suivie pour la creation de ton jeux ou tes passer direct à la prog ?
Cordialement,