Bravo à toi, je trouve ce projet très aboutis et très bien réalisé !
Merci !
Ce que ton projet propose c'est exactement ça et je suis curieux de savoir comment tu l'as implémenté !
L'implémentation abstrait (plutôt concrètement) le cas typique du terminal : un tableau de cases où chaque case est caractérisée par un caractère utf-8, deux couleurs (devant et le fond) et si oui ou non elle est sur la carte (ce qui permet de gérer différemment les cases suivant si elles sont ou non sur la carte), c'est le type UICell dans ui.go.
Ensuite, chaque backend (terminal, Tk ou WebAssembly) associe à cette combination lettre-couleurs-carte quelque chose d'adapté à la situation. Dans le cas de Tk et WebAssembly, j'associe simplement une image monocolore à chaque type de case à dessiner (via un simple map) et je la colorie ensuite à la volée (puis garde en cache l'image coloriée), ça permet d'avoir des images/symboles à la place de caractères utf-8, ce qui donne parfois plus de liberté pour obtenir des trucs plus intuitifs que le caractère utf-8 d'origine (par exemple, pour Tk, les fichiers tk.go et tiles.go gèrent l'essentiel, c'est un bon endroit où commencer pour comprendre l'implémentation dans Harmonist). Note, par contre, que pour la partie purement terminal non tuiles, je me limite à des caractères utf-8 courants présents dans la plupart des polices, donc la version terminal de Harmonist est plus abstraite dans sa symbolique que la version graphique web.
Dans le cas des backends graphiques, pour le dessin des tuiles dans la grille, le seul point vraiment subtil ensuite est l'optimisation des instructions de dessin comme le font ncurses et d'autres bibliothèques pour le terminal : s'assurer qu'on n'envoie pas au final des instructions de dessin redondantes à des cases qui n'ont pas changé : en pratique il faut utiliser deux buffers, un correspondant à l'état des cases après le dernier "flush" d'instructions de dessin, un autre où on modifie au fur et à mesure, puis ensuite la fonction "flush" doit faire la différence entre les deux pour calculer les instructions de dessins qui sont vraiment à exécuter.
Après, suivant le langage que tu utilises, il se peut qu'il y ait déjà une bibliothèque toute prête pour ce genre de cas (par exemple, libtcod, disponible pour divers langages, est couramment utilisé et, me semble-t-il, a des fonctionalités prévues pour abstraire tout cela). Si ton jeu ressemble à un roguelike, même vaguement, tu peux essayer de regarder la faq de roguelikedev pour voir s'il y a des choses qui peuvent t'aider, il y a plein de ressources pour les développeurs de jeux roguelike (et par extension, de jeux utilisant une grille avec des tuiles ou de l'ASCII) et l'ambiance est plutôt accueillante.
[^] # Re: Super projet !
Posté par anaseto . En réponse à la dépêche Harmonist: Dayoriah Clan Infiltration, un jeu rogue‐like d’infiltration. Évalué à 6.
Merci !
L'implémentation abstrait (plutôt concrètement) le cas typique du terminal : un tableau de cases où chaque case est caractérisée par un caractère utf-8, deux couleurs (devant et le fond) et si oui ou non elle est sur la carte (ce qui permet de gérer différemment les cases suivant si elles sont ou non sur la carte), c'est le type UICell dans ui.go.
Ensuite, chaque backend (terminal, Tk ou WebAssembly) associe à cette combination lettre-couleurs-carte quelque chose d'adapté à la situation. Dans le cas de Tk et WebAssembly, j'associe simplement une image monocolore à chaque type de case à dessiner (via un simple map) et je la colorie ensuite à la volée (puis garde en cache l'image coloriée), ça permet d'avoir des images/symboles à la place de caractères utf-8, ce qui donne parfois plus de liberté pour obtenir des trucs plus intuitifs que le caractère utf-8 d'origine (par exemple, pour Tk, les fichiers
tk.goettiles.gogèrent l'essentiel, c'est un bon endroit où commencer pour comprendre l'implémentation dans Harmonist). Note, par contre, que pour la partie purement terminal non tuiles, je me limite à des caractères utf-8 courants présents dans la plupart des polices, donc la version terminal de Harmonist est plus abstraite dans sa symbolique que la version graphique web.Dans le cas des backends graphiques, pour le dessin des tuiles dans la grille, le seul point vraiment subtil ensuite est l'optimisation des instructions de dessin comme le font ncurses et d'autres bibliothèques pour le terminal : s'assurer qu'on n'envoie pas au final des instructions de dessin redondantes à des cases qui n'ont pas changé : en pratique il faut utiliser deux buffers, un correspondant à l'état des cases après le dernier "flush" d'instructions de dessin, un autre où on modifie au fur et à mesure, puis ensuite la fonction "flush" doit faire la différence entre les deux pour calculer les instructions de dessins qui sont vraiment à exécuter.
Après, suivant le langage que tu utilises, il se peut qu'il y ait déjà une bibliothèque toute prête pour ce genre de cas (par exemple, libtcod, disponible pour divers langages, est couramment utilisé et, me semble-t-il, a des fonctionalités prévues pour abstraire tout cela). Si ton jeu ressemble à un roguelike, même vaguement, tu peux essayer de regarder la faq de roguelikedev pour voir s'il y a des choses qui peuvent t'aider, il y a plein de ressources pour les développeurs de jeux roguelike (et par extension, de jeux utilisant une grille avec des tuiles ou de l'ASCII) et l'ambiance est plutôt accueillante.