Discussion :

[Guntha]

Bonjour Bonsoir Bonne nuit!

Après quelques heures à chercher l'inspiration puis à enfin commencer à travailler, je vous présente notre projet pour cette année.

Pour trouver l'inspiration pour coller aux thèmes, je suis notamment allé sur l'article Wikipedia sur le nombre 10, duquel je me suis ensuite vite retrouvé sur celui des 10 plaies d'Égypte.
J'avoue qu'en combinaison avec le thème "Vous ne devez pas arrêter de bouger pour ne pas mourir", j'ai d'abord pensé à faire un clone de Serious Sam

Je me suis retrouvé à réfléchir à plusieurs idées de jeux poursuites, basés sur le fait de fuir quelque chose (à voiture, en bus...) pour finalement m'arrêter sur un jeu où, à bord d'un bateau sur le Nil, vous devrez échapper à la 1ère des 10 plaies d'Égypte: le fleuve de sang. Et ce faisant (si les délais me le permettent), vous devrez aussi sauver les gens à pied sur la rive qui veulent aussi y échapper.



Je vous annonce qu'il y aura pas mal de recyclage dans ce projet vous pouvez déjà voir le même rendu de l'eau que pour mon prototype de jeu d'aventure sous-marine, dont un topic est présent quelque part sur ce forum.

Biiscuit me fournit une précieuse aide cette année encore, elle a déjà réalisé, entre autres, le bateau ci-dessus.

Bonne nuit encore et à bientôt,

Guntha

[Jamatronic]

Bonne jam ! Et que les dieux (égyptiens) soient avec vous !

[Guntha]

Bonjour,

Le fleuve de sang peut maintenant vous poursuivre et vous rattraper pour vous faire perdre la partie.

J'ai aussi ajouté de l'inertie dans le déplacement du bateau.

J'ai perdu un peu de temps à corriger des bugs de rendu, mon eau n'était pas vraiment prête à l'emploi, surtout que j'ai fait quelques changements pour ce jeu (il n'y a pas de réfraction vu qu'on ne voit pas sous l'eau, et je l'ai adaptée pour l'effet de rivière d'une couleur différente qui nous poursuit).
Pour cet effet, je rends simplement la réflexion 2 fois, une fois avec un ciel rouge et une fois avec un ciel bleu, et je sample l'une ou l'autre selon la position du pixel d'eau dans le monde.
J'aimerais bien avoir un effet similaire pour tout ce qui est affiché au-dessus de l'eau.

[SylvainPV]

Cet effet d'eau est effectivement très sympathique !

Je ne sais pas s'il est possible de rendre moins rectiligne le fleuve de sang qui se rapproche. Peut-être avec des cercles plutôt qu'un rectangle, si c'est possible ?

[Gregouar]

Ou alors avec un shader qui prendrait en compte la position world x et le bruit utilisé pour l'eau (comme ça en plus ça correspond). Après, il faut que ça reste relativement une ligne pour que ça soit assez clair la distance qu'il y a entre toi et le sang.

[Guntha]

Tout ce que dit Gregouar (l'idéal ça serait un effet qui s'intègre bien dans le bruit de l'eau, mais que la limite reste lisible pour le joueur, d'ailleurs c'était aussi mes conclusions sur le chat ^^)

Mais faire un nouvel effet visuel pendant le week-end ça serait chaud, surtout que j'ai déjà perdu pas mal de temps sur des bugs visuels (qui aurait cru que c'était si galère de mettre proprement des sprites 2D dans un monde 3D, surtout quand on veut des réflexions sur l'eau? J'ai d'ailleurs quelques soucis de blending parce que je ne trie pas mes sprites, mais je vais laisser ça de côté...)

Pour continuer sur le visuel, aujourd'hui j'ai passé pas mal de temps sur l'effet quand on perd, vous risquez d'avoir plus envie de perdre que de battre votre score pour le voir plus souvent :p


Les palmiers, les mains et encore plusieurs autres sprites qui ne sont pas encore intégrés sont de Biiscuit, qui est très motivée cette année!

J'ai aussi ajouté des bouts de décor qui s'enchaînent aléatoirement les uns dans les autres:



Je les ai faits avec Trenchbroom; comme je l'ai déjà utilisé pour mon jeu d'aventure sous-marine (qui n'a pas été mis à jour depuis un moment :/ ), le gros du boulot était déjà fait, même le gros des collisions, sur lesquelles je suis en ce moment.


Les cubes bleus sont censés représenter l'emplacement des palmiers :p et les rectangles verts les crocodiles, qui ne sont pas encore intégrés.

Une fois que j'aurai fini les collisions, je pourrai mieux équilibrer le jeu en réglant bien la vitesse de la vague rouge. J'espère pouvoir ajouter toutes les features que je veux avant dimanche soir, notamment les bonshommes à sauver sur les bords ou les crocodiles qui bloquent le passage. J'ai un peu abandonné l'idée d'un effet visuel de monde "corrompu" autour des parties du fleuve déjà ensanglantées.

Bonne nuit!

[Guntha]

Bonjour,

Petite update car je devrais bientôt pouvoir faire une version:
=>Je n'ai pas pu faire le système de collision que je voulais dans les temps (on ne glisse pas sur les bords, on rebondit dessus, pas forcément vers la bonne direction, ce qui suffit pour jouer)
=>J'ai ajouté des visages familiers:

Passer près du rivage pour les sauver et multiplier votre score.

Il y a maintenant aussi des crocodiles, qui vous font rebondir en arrière quand vous les percutez.

Je n'ai pas encore bien équilibré l'avance de la rivière de sang.

À plus tard!

[Guntha]

Première petite version:

https://lhuillia.iiens.net/wejv10/WEJV10.zip

J'ai déjà eu le temps de corriger quelques petits détails depuis que j'ai fait ce zip ^^'
Il n'est pas complet, il manque le Readme, et j'aimerais ajouter un dernier effet visuel en plus.

Pour info, je mets les exécutables DX12 et OpenGL3.0 en plus de celui qui choisit la bonne API (voir le post sur le sujet :p ) parce que sur une machine Windows 10 que j'ai testé, ce dernier n'arrive pas à initialiser D3D12 mais ne retombe pas sur OpenGL, et je n'ai pas eu le temps de débugger ça.

[SylvainPV]

Des crocodiles béliers bien sûr !

Je vois qu'il est possible d'appliquer des rotations sur le modèle du bateau, puis-je suggérer de le tourner légèrement lors des virages ?

[forthx]

Sympa, ma me rappel les bonshommes de "ya le feu"

[Guntha]

Ce SONT les mêmes bonhommes (c'est même le même fichier du modèle, contenant les mêmes animations, qui sont jouées ici Enfin à l'époque de la jam, ils n'étaient pas vraiment animés, j'ai fait ça par la suite...)

Comme je l'ai dit plus tôt, cette année c'est la jam du recyclage, j'ai essayé de récupérer tout ce qui pouvait me servir, et ça m'a aussi permis de voir ce qui manquait à mon moteur.

@SylvainPV: c'est ce que je voulais faire à un moment, mais devoir faire la rotation équivalente pour le reflet dans l'eau complique ça surtout que je ne suis pas doué en maths, j'en ai déjà sué pour que les sprites aient une rotation à peu près bonne par rapport à la fois à la caméra et au reflet, ce sera du fignolage pour plus tard
Ce n'est peut-être pas vraiment compliqué, mais j'ai eu du mal à intégrer tout ce que je voulais, j'ai même coupé certains détails, et puis je veux en finir et ne pas risquer de casser quelque chose, je commence à être lessivé ^^'

Nouvelle version, probablement définitive pour ce soir:
https://lhuillia.iiens.net/wejv10/WEJV10.zip

Cette URL sera peut-être mise à jour avec des versions améliorées par la suite si je suis motivé. Celle de ce week-end restera disponible à cette adresse:
https://lhuillia.iiens.net/wejv10/WE...am_version.zip

Au menu des changements:
=>L'écran avant le début de la partie vous montre votre meilleur score (qui n'est toutefois pas sauvegardé sur le disque)
=>Le menu pause avec le bouton "Recommencer" s'affiche automatiquement au bout d'un moment après avoir perdu (sans masquer l'animation des mains :p )
=>Les crocodiles sont en plus haute définition
=>Quelques tweaks pour que l'ordre d'affichage des sprites et l'utilisation du Z-buffer ne soit pas trop pété, mais c'est du bricolage
=>Une tentative d'équilibrage de la vitesse de la marée rouge (si vous voguez à fond, elle ne tolère quasiment aucune erreur).
=>Une petite animation quand on récupère des gens sur les rives, chaque personne est un multiplicateur de score


Bonne soirée, et à plus tard pour le stream de SylvainPV!

[Guntha]

En re-testant, je me suis aperçu que la vague de sang était vraiment trop intransigeante, je l'ai modifiée pour que le je ait un tout petit peu le droit à l'erreur.
https://lhuillia.iiens.net/wejv10/WE...am_version.zip

C'est difficile de trouver un bon réglage pour que les parties soient courtes sans que le jeu soit trop frustrant, tout en faisant en sorte de ne pas pouvoir avoir des stratégies qui permettent de jouer infiniment avec peu d'efforts...

[Guntha]

Désolé, encore une mise à jour (d'un côté j'espérais en avoir fini pour de bon plus tôt, d'un autre je suis content de pouvoir apporter des améliorations qui rendent le jeu plus fun au lieu de travailler jusqu'à la fin sur des bugs décourageants)

https://lhuillia.iiens.net/wejv10/WE...am_version.zip

Cette fois-ci j'ai agi sur l'accélération du bateau au lieu de la vitesse de la vague de sang: en-dessous d'une certaine vitesse, le bateau accélère plus vite.
Avec ça, maintenant quand on se prend un rebond, on a le temps de se rattraper de justesse alors qu'on voit le sang qui commence à passer sous le bateau, ce qui rend le jeu plus grisant.

[Guntha]

Bonjour,

J'ai fait une petite mise à jour qui répare principalement les critiques qui ont été adressées pendant la jam:
=>La vague de sang qui est coupée sur une ligne droite: maintenant elle suit l'effet de l'eau (en fait, pendant que je dessine le reflet, j'ajoute un gros quad rouge que je dessine pas dans la "vraie" scène, ça donne un résultat satisfaisant :p)

=>Le bateau tourne quand le joueur appuie sur les flèches haut et bas.
C'est là qu'on se rend compte que c'est compliqué de mixer de la 3D avec de la 2D, en voulant se permettre des excentricités comme pouvoir tourner des sprites ou les refléter dans l'eau. En fait je ne tourne pas vraiment le sprite, je tourne les vertices du sprites AVANT de faire les transformations de la projection; et encore même là ce n'est pas vraiment une rotation car je n'ai eu un bon résultat qu'en utilisant un quaternion qui n'était pas normalisé. Je dois aussi tricher sur la profondeur en écrivant, pour tout le sprite, la même profondeur que celle qui est à son point de pivot. Et pour le rendu de la réflexion j'ai galéré aussi pour que le bateau ait bien l'air de couler quand on perd.

=>J'ai aussi amélioré le système de collision en mettant celui que je voulais mettre depuis le début: maintenant le bateau rebondit en fonction de l'orientation du plan sur lequel il se cogne et pas seulement vers l'arrière.
Du coup j'ai du rééquilibrer la vitesse de la vague de sang (et elle n'est pas encore bien équilibrée, y a moyen d'exploiter en roulant assez lentement pour voir arriver les virages sans que la vague ne nous rattrape), parce que certaines collisions nous projetaient vers l'avant, même si ça diminuait la vitesse du bateau ça permettait de jouer en appuyant seulement sur la flèche droite :p
=>Quelques autres améliorations visuelles, il y a notamment moins de stuttering (j'avais choisi d'updater le jeu à un framerate fixe, mais je ne smoothais pas la position du bateau/de la caméra au moment du rendu, du coup visuellement on voyait des frames skippées...), et je dessine les arbres du plus éloigné au plus proche, donc il y a moins de soucis de blending sur leurs contours.

Voilà, amusez-vous bien =)
https://lhuillia.iiens.net/wejv10/WEJV10.zip

[SylvainPV]

Super ces ajouts, bien joué

[Guntha]

Bonjour,

L'un des derniers défauts de la version jam, c'est qu'on avait du mal à évaluer dans quelle zone il fallait aller pour récupérer les bonshommes. Maintenant on peut dessiner les triggers dans TrenchBroom (alors qu'avant on plaçait un point qui représentait le centre de la zone, c'était difficile d'évaluer la zone même dans l'éditeur... J'avais déjà fait de quoi dessiner des triggers pour mon jeu d'aventure sous-marine, mais j'avais oublié comment l'utiliser ^^' et l'API pour le faire n'était pas très pratique)

J'ai essayé de faire un petit effet sympathique à l'affichage:


Et puis tant qu'à faire, comme je peux donner la forme que je veux à mes triggers, j'en profite pour les rendre plus arrondis et plus jolis ^^



Du côté des améliorations moins visibles, je suis actuellement sur le chantier de réduire le nombre de fichiers qui réduisent les chunks. Pendant la jam il y avait un fichier pour tout: un pour le mesh, un pour les collisions, un pour l'emplacement des palmiers, un pour l'emplacement des crocodiles, un pour l'emplacement des bonshommes. Actuellement je suis à 2 fichiers par chunk (un qui contient toutes les données et un autre qui contient les meshes), le but c'est d'en avoir 1 seul pour tous les chunks, que je pourrai flat-loader sans aucun traitement (à part les meshes et les textures, qu'il faut toujours envoyer au GPU ensuite). Le but c'est non seulement d'avoir un chargement le plus rapide possible, mais aussi, comme je fournirai plus tard tout ce qu'il faut pour créer un "niveau", de pouvoir se partager plus facilement les fichiers contenant des niveaux.
Je sortirai une version quand ce chantier sera fini.

Ensuite il en restera encore un gros (faire un outil qui associe les chunks "compatibles" entre eux, actuellement c'est hardcodé), et ensuite ce ne sera que du polish et de l'ajout de contenu.

À bientôt!

[Guntha]

Bonjour!

Je viens de sortir un nouvelle version avec les 2 améliorations décrites ci-dessus:
https://lhuillia.iiens.net/wejv10/WEJV10.zip


(En fait la tâche "tout rassembler dans un fichier flat-loadable" n'est pas complètement terminée, il reste juste les textures du mesh du chunk qui sont séparées).
Le problème avec FirstPlague.exe qui ne fonctionne pas sur toutes les machines a normalement été réglé (en tout cas, ça fonctionne sur la machine sur laquelle j'avais le problème), j'ai quand même laissé les 2 autres par précaution.

Niveau gameplay, il reste les collisions avec les crocodiles qui sont désagréables, et puis j'attaquerai sérieusement l'outil de combinaison de chunks. Et puis un outil plus propre pour "compiler" un ensemble de chunks en un niveau.
Il faudrait aussi que je trie mes sprites et les meshes avec de la transparence pour régler certains soucis de rendu. Et les réflexions côté sang ne sont pas terribles.

Après tout ça, je ferai sûrement des modifs qui feront que le jeu n'a plus grand chose à voir avec la version jam, donc je mettrai les prochaines versions sur une autre URL. Je trouve notamment que le défilement du décor à toute vitesse pète les yeux, je trouverai donc un moyen de changer la caméra pour rendre ça plus agréable (je suis même tenté de mettre une caméra 3ème personne à l'arrière :p ), et/ou réduire la vitesse du bateau (et donc rendre les niveaux plus accidentés pour rééquilibrer). Peut-être donner l'impression que le bateau navigue sur des vagues et ne glisse pas sur du plat.

Voilà, amusez-vous bien, et à la prochaine mise à jour!

[Guntha]

Bonjour/Bonsoir!

Les 3 tâches dont je parle ci-dessus ont été faites:
=>Améliorer les collisions avec les crocos: maintenant elles sont mieux intégrées et marchent comme les collisions contre le décor
=>Les sprites et les triggers translucides sont maintenant triés pour que le blending se fasse dans le bon ordre:


=>L'éditeur, dont j'ai un peu documenté la progression à coups de vidéos:

Le début du développement de l'éditeur: j'ai juste ajouté la possibilité de déplacer une caméra librement:
https://streamable.com/z9c1x0

Première version primitive de l'éditeur, qui permet juste d'assembler 2 chunks côte à côte pour décider s'ils sont compatibles ou non:
https://streamable.com/9wxmko

Une UI proche de la version actuelle de l'éditeur, qui permet déjà d'ouvrir/sauvegarder/compiler un niveau:
https://streamable.com/7ezgx0

Ici, à peu près toutes les features dont j'ai besoin étaient présentes, avec des features de qualité de vie supplémentaires, comme pouvoir compiler un niveau et y jouer immédiatement après:
https://streamable.com/n2aa7e

Ici 2 changements ont été ajoutés: la surface de l'eau fait maintenant partie des chunks (ce qui permettra plus tard d'avoir potentiellement plus de liberté, avec 2 chunks avec la surface de l'eau à différentes hauteurs séparés par une chute d'eau, ou un étang dans le décor avec des vagues moins vives...), et les chunks n'ont plus forcément tous la même longueur
https://streamable.com/zmsf52

Finalement j'ai toujours une mésaventure avec FirstPlague.exe: chez la machine de quelqu'un, D3D12 s'initialise bien, mais le jeu crashe à la 1ère frame, et je ne fallback vers OpenGL3 que si c'est l'initialisation qui foire, pas s'il y a un crash en plein milieu :/

-------------------------------

Je songe à complètement changer la façon dont le décor fonctionne: actuellement il y a au premier plan une ligne de chunks "normaux", sur lesquels le joueur se déplace, et à l'arrière plan une ligne de chunks "de décor". Ça marche suffisamment bien tant que le jeu se déroule sur une ligne droite, mais j'ai des plans un peu plus ambitieux, où le parcours pourrait partir plus en biais, et avec le système actuel ça serait compliqué d'avoir un rendu correct.
Je songe donc à me débarrasser du concept de "chunk de décor", et, à la place, sur les chunks normaux ou sur des chunks supplémentaires vides (si la caméra peut voir loin du parcours), pouvoir désigner des "zones de décor", sur lesquelles le jeu décidera de placer des éléments de décor (bâtiments en 3D, ensemble de sprites, foule de bonshommes...) aléatoirement.
Ça promet d'être un gros chantier, j'aimerais bien pouvoir sortir une version après l'avoir fini.

Avec ça, je veux aussi rendre le jeu moddable, et faire quelques changements de gameplay comme j'en parle dans le post précédent.

À bientôt!

[Guntha]

Bonjour,

J'ai stagné pas mal de temps avant de décider quoi faire avec mon système de décor, j'en ai profité pour ajouter quelques petites choses à mon moteur. Je progresse toujours assez lentement en ce moment.

D'abord, la capacité de recharger à la volée des assets quand leur fichier change. Ça marche avec les textures, les shaders et les meshes, et c'est relativement facile d'y ajouter le support de formats spécifiques à un jeu. Pour First Plague, ça marche donc avec les fichiers .map, avec un comportement différent selon que c'est un chunk de "parcours" ou de décor.

J'ai aussi légèrement changé mon système de localisation pour pouvoir flat-loader un fichier de localisation sans aucun autre traitement, alors qu'il y avait un petit peu de traitement avant (détecter tous les caractères uniques pour préparer les fonts, assigner plein de char*). C'était loin d'être un goulot d'étranglement, mais j'ai du être traumatisé par d'anciens projets pros où les textes localisés étaient stockés dans des fichiers XML :p

================================

Pour le système de décor, la première décision que j'ai faite est de finalement caser le jeu sur des tiles. L'ancien système était suffisant pour avoir un tracé qui ne soit pas une ligne droite, mais ça compliquait l'ajout de décor autour. Grâce au fait de forcer les chunks à avoir une taille en tiles, je suis sûr de pouvoir remplir tous les trous dans la map autour du chemin.
Je fais en sorte de n'ajouter du décor que si l'angle de caméra le nécessite. À chaque frame, je remplis une grille pour savoir quelles tiles sont encore inoccupées, et lesquelles peuvent être vues par la caméra.

Les cases blanches montrent les tiles inoccupées, les noires les tiles occupées, et celles qui ont aussi du rose les tiles vues par la caméra. Les tiles aux bords d'un chunk peuvent colorées si les tiles contiguës sont encore vides, c'est pour signifier quels chunks voisins seraientt "compatibles" et pourraient y être placés, c'est une capacité que je n'utilise pas encore dans mes assets.

Ensuite, il m'a fallu définir où les décors en eux-même (ensembles d'arbres, de maisons...) pourraient apparaître (pour qu'ils ne puissent pas chevaucher l'eau ou apparaître sur une pente raide par exemple).
Je dessine des zones de décor dans TrenchBroom, dont je prends l'une des faces dans le jeu pour définir le polygone où le décor peut apparaître. Pour que l'algo qui va remplir ces zones (que je n'ai pas encore écrit :p ) reste relativement simple, chaque zone doit être composé d'un seul brush, pour que ce soit forcément un polygone convexe.

Voilà où j'en suis. Actuellement, je suis en train de m'occuper des décors en eux-même (qui seront traités presque comme un 3ème type de chunk), et ensuite je m'occuperais de remplir à la volée les zones de décor avec ces décors.

À la prochaine, dans moins longtemps j'espère!

[Guntha]

Bonjour,

Je viens donner quelques nouvelles sans vraiment avoir rien de nouveau à montrer.

J'ai mes "chunks de décor" et je peux les ajouter dans les zones au bord de l'eau. J'aurais pu le montrer, mais l'algo qui place le décor est assez naïf et le résultat n'est pas forcément super joli.

J'étais pris quelques temps par d'autres projets persos qui n'ont pas leur place ici, et aujourd'hui je bloque sur un problème lié à la sérialisation de mon niveau.

Je n'en ai pas parlé ici, mais j'ai fait en sorte que le format de fichier de mon niveau n'ait quasiment pas besoin d'être parsé, notamment à l'aide de pointeurs relatifs.

En gros, j'ai des structures définies comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct Level
{
	//Simplifié pour l'exemple. Il y a aussi plein de sous-structures.
	u32 chunkCount;
	u32 decorGroundChunkCount;
	u32 biomeCount;
	u32 textureCount;
	Diskable<Chunk> chunkMeshes;
	Diskable<DecorGroundChunk> decorGroundChunkMeshes;
	Diskable<Biome> biomes;
	Diskable<Texture> textures;
}Level;

Que je peux utiliser dans le code comme si elle était définie comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
typedef struct Level
{
	u32 chunkCount;
	u32 decorGroundChunkCount;
	u32 biomeCount;
	u32 textureCount;
	Chunk* chunkMeshes;
	DecorGroundChunk* decorGroundChunkMeshes;
	Biome* biomes;
	Texture* textures;
}Level;

Ou même:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct Level
{
	//Ici les "Count" sont redondants mais bon :p
	u32 chunkCount;
	u32 decorGroundChunkCount;
	u32 biomeCount;
	u32 textureCount;
	std::vector<Chunk> chunkMeshes;
	std::vector<DecorGroundChunk> decorGroundChunkMeshes;
	std::vector<Biome> biomes;
	std::vector<Texture> textures;
}Level;

L'intérêt de la 1ère version, c'est que je peux lire toute les données du niveau en 1 seul fread() (en vrai un poil + pour quelques méta-données). C'est tout aussi facile de l'écrire, une fois que la structure est formée.
L'intérêt des 2 suivantes, c'est que je peux modifier mon niveau à la volée dans mon éditeur, sans me soucier du layout des données en mémoire (tant pis s'il y a trop de fragmentation pendant l'édition :p)

J'ai essayé de faire un code "générique" qui permettrait de convertir la 2ème version de la structure dans la 1ère (et vice-versa), mais comme tout code générique (en tout cas en C/C++), ça finirait par devenir difficilement débuggable, et ce code lui-même était difficile à utiliser et même pas "assez" générique - j'avais un certain nombre de modifs à faire à chaque fois que je voulais ajouter une feature au niveau, en faisant attention de ne rien casser -, et le fossé dans lequel j'ai fini par tomber, c'est que c'est devenu de plus en plus difficile et démotivant d'ajouter de nouveaux types de données au niveau.

J'ai donc mis en chantier un outil qui permettrait, à partir d'une des versions des structures, de générer le code permettant de convertir les structures d'une version à l'autre.
Comme ça si je veux ajouter une nouvelle feature au niveau, j'ai juste à l'ajouter à l'une des structures, faire tourner ce générateur, et hop, je peux la programmer, l'utiliser et avoir un format de niveau déjà rapide à charger :p

Jusqu'ici c'était relativement facile, quand il s'agissait de convertir dans le cas le plus compliqué des tableaux de tableaux.
Ma difficulté maintenant, c'est de gérer des champs qui pointent ailleurs dans la structure, voire dans la structure "parent". Typiquement dans le cas ci-dessus, mes Chunks ont besoin de pointer sur des textures contenues dans le Level.

J'ai fait un petit état de l'art avant de me lancer là-dedans pour voir si un outil du genre existait déjà, j'ai trouvé FlatBuffers ou Data Desk qui ne me semblent pas faire exactement ce dont j'ai besoin, et puis j'aime bien mon format sérialisé actuel, et j'aime bien le fait de ne pas devoir faire appel à un langage intermédiaire pour définir mes structure, et au contraire d'avoir les structures C que je peux déjà utiliser dans mon code. Même si en vrai, je parse une version très limitée du C qui contient juste ce dont j'ai besoin (pas envie d'avoir besoin de LLVM juste pour cet outil, au moins pour l'instant :p ), donc je dois être prudent quand même.

Cette techno pourrait me servir pour des futurs prototypes ou wek-ends de développement (je pourrais sortir des petits jeux avec des fichiers "propres" sans effort :p ) Et je pourrais aussi les porter dans mes précédents projets (que je compte continuer, même si je n'y passe plus beaucoup de temps en ce moment ^^')

À la prochaine, avec des images j'espère :p