rewind a écrit 3425 commentaires

Le problème, c'est que l'exemple du quinconce pulvérise tous les algos proposés :-(

On interdit aux artistes de faire ce genre de choses et hop, plus de problème !

J'aurais fait pareil.

D'un autre côté, dans le journal, il manque un élément essentiel : qu'est-ce qui est attendu sur les exemples donnés ?

Il faut bien entendu générer cette matrice" mais c'est un autre problème.

Pour ça, je te conseille un petit article qui contient quelques idées d'algos pour générer tes montagnes.

Pour le reste, j'aimerais savoir si l'idée est de générer une carte une bonne fois pour toute ou alors si tu génères des cartes en ligne. Parce que dans le premier cas, en fait, ce n'est pas si grave que ce soit lent (et quand je dis lent, je parle de truc de l'ordre de la seconde voire, dans le pire des cas, de la minute). Dans le second cas, oui c'est intéressant de regarder. Et si tu es dans le premier cas, tu pourrais sans doute essayer sqlite, parce que ta carte va rester constante a priori au cours du jeu, donc tu n'auras pas de problème d'écritures concurrentes.

Dans mon cas, les entrées et sorties, ce sont des cartes complètes ! ;)

C'est pas mal mais est-ce que ça peut se spécialiser ? Je veux dire, est-ce que je peux définir mes propres opérateurs dans les boîtes ?

Petite remarque en passant, puisque tu utilises Boost, je pense que ça serait une bonne idée d'utiliser boost::any dans pas mal d'endroit dans ton code (notamment à la place de ton type Model::Data) ;)

L'agenda des feminazis et de leur zélotes est de faire du genre féminin le genre dominant. Pour cela plusieurs options: La plus "discrète" est de mettre le mot au féminin, mais avec un tiret. Dans ce cas, employé-e, étape 1. Etape 2, on enlève le tiret. La plus "décomplexée" est d'utiliser de fait le féminin par défaut.

Ho mon dieu ! Quelle atteinte à ta virilité !

Sans lire le papier "terrain generation" sur lequel tu mets un lien en début d'article, c'était complètement obscur et incompréhensible pour moi.

En fait, j'aurais pu mieux l'expliquer en montrant plusieurs octaves consécutives. Il existe des exemples en 1D pour bien comprendre, genre là (et d'ailleurs, j'ai oublié de mettre ce lien qui explique bien les choses, de manière très visuelle).

le point P n'étant pas défini, j'ai cru au début à une faute de frappe de ta part, j'ai compris ensuite que je n'avais pas compris ;)

Heu, il est défini le point P, sur une des images insérées dans le texte, dans la section du bruit à base de valeur. Le point P et le point A se refère à cette image là, pas à la présentation de Perlin. Je n'ai pas les mêmes notations que la présentation de Perlin d'ailleurs, j'ai simplifié.

Tu as sans doute raison, c'est sans doute possible. Maintenant, je ne suis pas trop partisan d'essayer de faire rentrer un carré dans un rond. Je veux dire par là que ce genre d'interface a l'air finalement assez courante dans plein de domaines différents mais que ça ne justifie pas de réutiliser le même morceau de code pour tout faire. Dans ce cas là, je pense que ça serait plus une contrainte trop importante à gérer qu'une facilité.

Je télécharge la version Windows, je dézippe, je lance et :

Impossible de démarrer le programme car il manque libgcc_s_dw2-1.dll sur votre ordinateur. Essayez de réinstaller le programme pour corriger ce problème.

Pour quiconque connaît le mouvement, il est flagrant que c'est la théorie du genre qui est à l’œuvre.

Es-tu sûr que ce ne sont pas les chinois de la NSA ? Ou le grand complot judéo-maçonnique ?

C'est vrai ! Voilà la version longue :

En tout cas ça fournit une GUI et un certain nombre de briques de bases pour ce que tu veux faire.

Ce que je veux faire, c'est vite dit. J'ai un jeu à faire ! Donc, j'ai mis ça comme idée si quelqu'un se sent l'envie de le faire. Ou alors, je donnerai ça à des étudiants, juste pour voir ce que ça peut donner.

Pas satisfait non plus. GEM est très orienté OpenGL, mon outil est pour l'instant orienté pixels. Après, Pure Data peut être spécialisé pour des heightmap, de la même manière que GEM a spécialisé Pure Data pour le graphique. Mais est-ce que ça vaut bien le coup par rapport à un développement from scratch ?

Est-ce que ça vaut le coup de devoir lancer Blender pour générer des heightmaps ? Il me semble que détourner un outil tel que Blender pour faire totalement autre chose, c'est contre-productif.

Merci pour ce conseil ! En fait, je pensais que la copy-ellision était difficile à détecter et donc qu'elle ne se produisait que dans de rares cas. En fait, c'est le contraire ! Du coup, je vais aller supprimer mes move.

Oui, ça correspond à ça sauf que là, c'est hyper spécialisé et en regardant vite fait, je ne crois pas que ce soit adaptable à mon cas. C'est dommage parce que ça correspond assez bien à ce que j'aimerais avoir.

Merci pour ces bonnes références ! Effectivement, j'imaginais plutôt ce genre de choses. Ça sera une bonne source d'inspiration le moment venu, le rendu est plus que convenable.

Du coup ça me fais pensé qu'il pourrait être intéressant d'avoir un système de marées ou certaines zones ne sont accessible qu'a marée base genre le mont st Michel sans cette horrible digue.

Intéressant mais difficile comme tu le supposes par la suite. Parce qu'il faut pouvoir modifier la carte de base sur de grandes zones, ce qui peut être compliqué suivant le format de la carte (en mémoire). Dans mon cas, je n'avais pas prévu ce genre de choses donc ça ne va pas être possible. Mais l'idée est intéressante.

Les vieux RPG 2D l'utilisent beaucoup, comme les montagnes au nord de Link's Awakening.

Oui mais là, c'est de la fausse vue de dessus. Dans mon jeu, j'ai pris le parti de faire de la vue de dessus vraiment dessus, à la verticale. Du coup, on ne peut pas utiliser ce genre d'astuce pour simuler le relief.

Finalement, je me suis simplement penché sur un bête A* en utilisant la topologie de la carte comme heuristique, le résultat s'est montré satisfaisant dans le cadre du projet sur lequel je travaille, bien qu'il montrerait très vite ses limites si on cherche à représenter un monde trop réaliste.

C'est intéressant comme algorithme, j'en ai un qui ressemble un peu. Et sur le côté réaliste, je dirais qu'on est dans un jeu vidéo, donc on peut prendre quelques libertés. Je ne suis pas géographe !

Puisque, si j'ai bien compris, tu travaille sur un jeu 2d, comment penses tu représenter visuellement une topologie aussi précise que celle que ton algorithme est capable de générer ?
Au final, sous quelle forme vas tu représenter le monde au joueur ? Vas tu granulariser ta carte pour l'afficher sous forme de tuiles, comme la plupart des jeux 2d ?

L'idée, pour la suite, c'est de dire qu'un pixel sur la carte d'altitude, c'est une tuile sur la carte finale. J'ai déjà une carte sous forme de tuile (voir l'épisode 7), mais pour l'instant, elle est un peu basique. Le tileset est moisi, les couleurs sont horribles. Je vais donc définir un tileset, puis définir pour chaque case quelle tuile convient le mieux, en fonction de l'altitude, mais pas que.

Une difficulté, comme tu le dis, c'est de représenter le relief et la pente en vue de dessus. Je pense que c'est hyper difficile, et que ça n'apporte pas grand chose étant donné le niveau de zoom sur le personnage. Mais on peut donner des indices visuels qui permettent, pour certaines situations (comme les zones infranchissables) de suggérer qu'il y a un relief. Et on peut toujours permettre au joueur de voir une grande carte générée par mon programme en l'état actuel pour qu'il voit les reliefs ;)

Comptes-tu utiliser des graines différentes pour chaque partie afin de générer des niveaux aléatoires, ou n'est-ce qu'un moyen pour toi d'accélérer et de simplifier le level-design d'un monde unique ?

Je suis clairement dans la deuxième solution. Je veux un monde assez grand et je ne veux pas m'occuper de tous les détails, surtout ceux qui peuvent être délégués à un algorithme. Donc, j'ai écris ces algos pour pouvoir générer des mondes et en choisir un qui me servira pour mon jeu. Dans la partie 2, je montrerai tout ce que je génère en plus pour éviter de me fatiguer ;) Mais clairement, si je devais tout générer, y compris les quêtes et tout ça, ça serait un travail énorme et d'une difficulté largement supérieure à ce que j'ai fait là.

Ho, il aime pas le using dans la définition de l'exception. Bon, ça va, c'est possible de traiter ce problème aussi. Du coup, j'ai ajouté deux bugs sur github pour m'en souvenir, merci !

oui, ça compile, et ensuite il y a d'autres erreurs

Tu peux me les indiquer. Pour d'autres lib, j'ai prévu un mode sans C++11 de toute façon, je peux faire pareil ici dans la mesure du possible.

J'ai oublié d'en parler, mais ces techniques sont encore utilisées de nos jours. Notamment dans Minecraft où les terrains sont générés à base de bruit de Perlin. Et beaucoup d'éditeurs de niveaux pour des jeux modernes ont un module qui permet de générer des terrains à partir des techniques présentées ici. Donc, ces techniques ne sont pas mortes, au contraire. Mais elles ne sont plus intégrées dans les jeux, elles servent justes de base pour éviter de passer trop de temps sur des tâches sans intérêt. Ensuite, une fois la base générée, on peut décorer la carte comme on veut.

Pour le bug, c'est juste que GCC 4.7.2 ne gère pas C++11 entièrement (la gestion est complète à partir de GCC 4.8.1). Et donc, la fonction emplace qui permet de construire l'élément directement dans la map n'existe pas dans les vieilles versions. Tu peux remplacer la ligne incriminée par (pas testé mais ça doit passer) :

  m_map.insert(std::make_pair(offset, c));

Pour ta deuxième question, oui on peut. Il suffit d'implémenter un générateur qui lit un fichier contenant une heightmap. Et ensuite, on applique des opérateurs d'érosion (qui sont définit de manière indépendante dans MapMaker). Si la carte est en couleur, ça peut être assez compliqué à lire, généralement les heightmaps sont en dégradé de gris. La carte que tu montres, c'est le résultat que tu veux avoir ou c'est le point de départ ?

La génération de rivière, ça sera pour la partie 2. Et oui, j'y ai déjà réfléchi (ou plutôt, deux de mes étudiants y ont réfléchi) et il existe plusieurs algorithmes possibles. Les plus naïfs ne marchent pas bien en fait, soit parce qu'ils sont beaucoup trop long, soit parce qu'ils ne donnent pas de bons résultats. Du coup, il faudra un peu patienter ;)