Cartes de vue 2D de haut en bas

Je me demandais comment cela fonctionne.

Chargez-vous la carte complète au démarrage du jeu ou chargez-vous des parties de la carte au moment de l'exécution?

Et comment voulez-vous enregistrer les cartes? Serait-ce au format XML ou dans un format binaire?

Merci!

Je suis d'accord avec eBusiness. Cela dépend de la taille et de la façon dont vous souhaitez le modifier.

Estimer la taille en octets de votre carte dans une représentation raisonnablement compacte. Décidez également quelles parties de la carte peuvent changer au cours du jeu. Les parties qui ne changent pas peuvent être chargées et ne doivent pas être enregistrées. Si la taille estimée est petite, il suffit de tout stocker en mémoire. Cela ne vaut pas la complexité supplémentaire de charger des parties de la carte et de suivre ce que vous avez chargé ou non, à moins que les données soient si grandes qu'elles soient nécessaires.

Par exemple, si vous écriviez Civilization II , la taille de votre carte pourrait être de 100 x 100 tuiles.

1. Chaque tuile est l'un des 12 types, vous pouvez donc la stocker sur 4 bits. Cela signifie que la carte principale est de 100 x 100 x 0,5 octets = 5 000 octets pour stocker les types de tuiles. La carte principale ne change jamais.
2. Vous pouvez également améliorer les tuiles de carte avec les routes, l'irrigation, etc., et il y a jusqu'à 7 améliorations. Cela signifie 2 ^ 7 valeurs différentes, prenant 7 bits, mais nous utiliserions probablement juste 1 octet pour cela. Cela nous donne 100 x 100 x 1 octet = 10 000 octets pour stocker les améliorations.
3. Le brouillard de guerre nous indique les tuiles de carte que vous avez vues, vous avez donc besoin d'un bit par joueur. Si vous limitez à 8 joueurs, c'est un autre octet par tuile de carte, ou 10 000 octets pour le brouillard de guerre.
4. Enfin, il y a toutes les villes et unités. Vous pouvez estimer que chaque joueur a jusqu'à 20 villes et 100 unités, et chacune d'elles peut nécessiter 100 octets de données (estimation approximative), ce qui fait 12 000 octets (beaucoup plus si vous utilisez XML).

C'est moins de 30k pour une représentation binaire compacte des objets + carte Civ II, de sorte que vous pouvez tout stocker en mémoire, même si vous utilisez un format détaillé beaucoup plus grand. J'ai reçu les chiffres ci-dessus de la part d'une personne qui a procédé à l'ingénierie inverse de la structure de la carte Civ II .

Daggerfall , considéré par certains comme ayant une carte ridiculement grande, semble être 5000x2500 et environ 25 mégaoctets, mais il a également un grand nombre de PNJ (750 000 est ce que j'ai lu mais cela semble très élevé). Sur les ordinateurs de bureau / portables d'aujourd'hui, cela peut également tenir en mémoire, mais sur les appareils mobiles ou les navigateurs qui peuvent être un peu trop volumineux. Il y a un wiki décrivant le format de carte Daggerfall .

Vous pouvez réduire la taille en identifiant et en éliminant la redondance . Par exemple, au lieu de stocker 100 000 arbres ou épées identiques chacun au format XML, stockez un arbre et une épée et 100 000 références. Dans les formats binaires, cette référence peut n'être que de 1 ou 2 octets, et dans un format plus détaillé, la référence peut toujours être raisonnablement petite.

Faites la chose la plus simple qui fonctionne pour votre jeu. Si la carte est petite, peu importe si vous utilisez un format compact ou détaillé. Si le format compact tient dans la mémoire mais pas le format détaillé, vous devez décider si le travail supplémentaire du format binaire est plus ou moins important que le travail supplémentaire de chargement de parties de la carte. Cela dépendra du jeu. Dans un jeu de type Civ où vous avez besoin de toutes les données pour simuler des virages, le format binaire est probablement un meilleur choix. Dans un jeu de type Daggerfall où vous n'avez pas besoin de charger des zones sauf à proximité du joueur, le chargement de parties de la carte est probablement un meilleur choix. Si la carte est ainsi grand que même le format compact ne tiendra pas en mémoire, alors demandez-vous d'abord si cela vaut vraiment tout le travail supplémentaire pour y faire face, et si oui, concevez un format binaire dont vous pouvez charger des portions.

Pour mon projet actuel (passe-temps), les cartes et tous les objets qu'ils contiennent tiennent dans 50 Mo, donc tout garder en mémoire serait bien. Cependant, je veux qu'il s'exécute dans le navigateur, et 50 Mo est plus que ce que je veux transférer sur le réseau, donc je les garde tous en mémoire sur le serveur, puis je ne charge que des parties du monde dans le client. Mes tuiles de carte sont 1 octet par tuile, tuiles 2048x2048 (4 Mo). Les objets (arbres, chaises, orques, etc.) sont codés JSON pour plus de simplicité. Dans le client, je charge uniquement les zones de carte (y compris leurs objets) qui sont proches du joueur.

La quantité à charger dépend au moins de la taille de la carte, si les données peuvent raisonnablement tenir en mémoire, il n'y a vraiment aucune raison de s'embêter avec un chargement progressif.

La chose la plus notable que XML fait est de prendre beaucoup de stockage / mémoire / espace réseau / trafic supplémentaire. Si vous pensez que l'utilisation de XML est amusante, assurez-vous de le faire uniquement pour des quantités de données relativement petites.

Lorsque vous concevez un format de données, vous devez avoir à l'esprit la façon dont vous souhaitez modifier ces données. Vous pouvez utiliser un simple éditeur de texte pour écrire vos données sous forme de fichier texte brut, vous pouvez utiliser ces fichiers directement ou les convertir au format binaire pour économiser de l'espace. Vous pouvez utiliser un éditeur d'images pour créer vos niveaux sous forme de bitmaps, encore une fois, vous voudrez peut-être convertir en un fichier plus petit.

Ou vous pouvez créer votre propre éditeur, auquel cas il n'y a pas de raison de ne pas utiliser un format binaire compact.

Il n'y a pas de réponse unique à ces questions. Tout dépend de vous par nature.

Vous pouvez enregistrer les cartes comme vous le souhaitez et les afficher / les rendre à tout moment.