Discussion :

[kain_tn]

Bonjour.

il y a une question que je me pose depuis peu après être tombé sur un wiki sur le format MPQ (format de fichiers de blizzard pour starcraft, diablo, diablo 2, warcraft III, etc): comment représenter une carte (2d, voire 3d) en termes de données?
Je pense que celà dépend fortement du type de carte, du type de jeu, etc mais je voudrais savoir si certains d'entre vous ont des idées, des pistes, des tutos ou même de l'expérience sur le sujet?

Merci à tous ^^

[Kurisu]

une solution serait de créer un tableau 2D avec les informations pour chaque case, du genre quel sol, etc... (oui, c'est assez bourrin, parce que grand).
Que ce tableau soit écrit dans un format binaire ou en XML, peu importe pour la logique derrière.

Sinon, en mieux peut-être, tu prends un fichier image (PNG par exemple) et tu reinterprètes les couleurs des pixels en tant que valeur du jeu. Ca te donne la possibilité d'avoir au moins 4 valeurs entre 0 et 255 par case et tu peux facilement éditer tes cartes. (Avec le format TGA, tu peux avoir encore plus de meta-informations par pixel je crois). Tu peux aussi utiliser plusieurs fichiers dans ce cas.

[kain_tn]

une solution serait de créer un tableau 2D avec les informations pour chaque case, du genre quel sol, etc... (oui, c'est assez bourrin, parce que grand).
Que ce tableau soit écrit dans un format binaire ou en XML, peu importe pour la logique derrière.

Dans ce cas, il ne vaudrait pas mieux écrire le tableau dans un fichier binaire optimisé pour une lecture et une recherche rapides, et charger des tableaux plus petits en fonction des besoins?

Sinon, en mieux peut-être, tu prends un fichier image (PNG par exemple) et tu reinterprètes les couleurs des pixels en tant que valeur du jeu. Ca te donne la possibilité d'avoir au moins 4 valeurs entre 0 et 255 par case et tu peux facilement éditer tes cartes.
(Avec le format TGA, tu peux avoir encore plus de meta-informations par pixel je crois). Tu peux aussi utiliser plusieurs fichiers dans ce cas.

Du genre un fichier avec des infos simples qui peuvent affecter le déplacement (eau, intérieur d'une maison, rocher, etc), un autre avec les textures et les objets du décor, et un avec les pnj par exemple?


à première vue, en utilisant un tableau 2d, chaque case du tableau représenterait la plus petite unité de position possible non? Dans le cas de la 3d, faut-il ajouter une dimension au tableau (un peu plus bourrin)?

Merci de ta réponse qui est déjà un bon début de réflexion!

Sinon, toutes vos réponses sont les bienvenues!
Merci d'avance

[Emmanuel Deloget]

Bonjour.

il y a une question que je me pose depuis peu après être tombé sur un wiki sur le format MPQ (format de fichiers de blizzard pour starcraft, diablo, diablo 2, warcraft III, etc): comment représenter une carte (2d, voire 3d) en termes de données?
Je pense que celà dépend fortement du type de carte, du type de jeu, etc mais je voudrais savoir si certains d'entre vous ont des idées, des pistes, des tutos ou même de l'expérience sur le sujet?

Merci à tous ^^

Plusieurs techniques sont à te disposition.
En 3D:

• une heightmap (une image bitmap en niveaux de gris; noir = élévation 0; blanc = élévation max) - cf Oblivion.
• un modèle 3D (créé avec un logiciel de modélisation) - cf Dungeon Siege.
• des patchs de bezier ou équivalent (créé avec un logiciel de modélisation) - Cf Rizom.
• etc...

Un problème se pose en 3D : celui du volume de données à traiter. Si tu veux représenter un terrain de 1km * 1km avec un vertex / m, cela te fait 1,000,000 de vertex à traiter. Chaque vertex est représenté par au moins 3 float, soit 12 octets: tu as donc besoin de 12 Mo par km2 au minimum - et ton terrain n'est pas texturé... Un problème se pose alors lorsque tu dois traiter et transférer ces données sur la carte vidéo. Pour palier à ces limitations (si elles existent vraiment : pour un FPS avec un terrain de taille réduite, on peut faire avec) il existe plusieurs algorithmes gérant le niveau de détail (le but: faire en sorte que l'arrière plan soit moins détaillé que l'avant plan): chunked lod, roam, roam 2, geomipmip, geoclipmap, etc...

Et pour la 2D:

• une bitmap à laquelle on associe un ou plusieurs masques contenant des méta-données (zones accessibles, triggers, etc)
• des tuiles (tiles), qui sont positionnées à l'aide d'un éditeur spécialisé pour former un niveau de jeu plus grand (shameless plug)
• etc...

HTH

[kain_tn]

Plusieurs techniques sont à te disposition.
En 3D: [*] une heightmap (une image bitmap en niveaux de gris; noir = élévation 0; blanc = élévation max) - cf Oblivion.[*] un modèle 3D (créé avec un logiciel de modélisation) - cf Dungeon Siege.[*] des patchs de bezier ou équivalent (créé avec un logiciel de modélisation) - Cf Rizom. [*] etc...

Je vais regarder plus en détail ces techniques;

Merci pour vos réponses

[kremvax]

A noter que la représentation des données peut être fondamentalement différente, entre de la 3D et de la 2D (ou de la 3D "tuilée" genre civilization).
Dans le premier, généralement tu importes directement un modèle 3D dans ton jeu, accompagné d'une heightmap. Pour des graphismes "tuilés" en revanche, tu récupères les données de ton terrain dans un fichier (ascii, binaire... comme tu préfères) et tu reconstitues le monde dans le jeu à partir de ces données

[kain_tn]

A noter que la représentation des données peut être fondamentalement différente, entre de la 3D et de la 2D (ou de la 3D "tuilée" genre civilization).

Oui c'est sûr... Je regarde en ce moment du côté des formats de compressions des fichiers et des structures de données (hash, arbres, etc) afin d'essayer de comprendre comment le jeu peut gérer ces données efficacement pour ses besoins (règles du jeu, collisions, etc)

Merci à tous en tous cas pour vos réponses qui m'ont permis d'orienter mes recherches