J'ai expérimenté différentes idées sur la manière de stocker un monde de jeu 2D. Je suis intéressé par des techniques d'audition de stocker de grandes quantités d'objets tout en gérant l'ensemble visible (disons 100 000 carreaux de carreaux). De toute évidence, les techniques peuvent varier en fonction de la manière dont le jeu rend cet espace.
Supposons que nous décrivions un monde de jeu 2D défilant plutôt que de l'écran basé sur l'écran, car vous pouviez facilement effectuer un rendu d'écran à partir d'une telle configuration pendant que l'inverse est un peu plus désordonnée.
À la recherche de solutions agnostiques linguistiques ici, donc c'est plus utile pour les autres.
éditer: Je pense qu'une bonne réponse ici serait une revue générale des idées à prendre en compte lors de la réflexion, car certains des intervenants ont tenté, mais aussi Commencez à expliquer comment différentes solutions s'appliqueraient à ces scénarios. C'est une question quelque peu complexe. Je m'attendrais donc à une bonne réponse pour refléter cela.
5 Réponses :
Vous pourriez obtenir des idées sur la manière de la mettre en œuvre à partir de certaines structures de données spatiales telles que la plage ou les arbres KD.
Cependant, la réponse à cette question varierait considérablement en fonction de la fonctionnalité de votre jeu.
Parlons-nous un plateforme 2D avec 10 ennemis à l'écran, 20 autres offscreen mais "actif" et un nombre inconnu plus "inactif"? Si tel est le cas, vous pouvez probablement stocker votre niveau entier comme une éventail de "écrans" où vous manipulez ceux qui sont les plus proches de vous.
ou voulez-vous dire un vrai jeu 2D avec beaucoup de mouvements haut / bas aussi? Vous devrez peut-être être un peu plus prudent ici.
La plate-forme est également d'une certaine importance. Si vous implémentez un simple stratifileur pour les ordinateurs de bureau, vous n'auriez probablement pas à vous soucier de la performance autant que vous le feriez sur un appareil intégré. Ce n'est pas une excuse pour être naïf à ce sujet, mais vous n'avez peut-être pas à être terriblement intelligent non plus.
C'est une question quelque peu intéressante que je pense. Vraisemblablement, quelqu'un de plus intelligent que moi qui a de l'expérience avec la mise en œuvre des plateformes a déjà pensé ces choses.
Quadtrees Sont une solution assez efficace pour stocker des données sur un grand monde en 2 dimensions et le objets en elle.
De ce que j'ai lu sur les quadrits, ils semblent chers à mettre à jour. Donc, s'il y a des objets en mouvement activement, cela pourrait être problématique, non?
Cela dépend principalement de la pâte à la portée du monde - si le ratio d'objets à l'espace dans le monde est assez petit, les gains d'utilisation de quadtrès l'emporteront un processus de mise à jour légèrement plus compliqué. Si le ratio est grand (et donc le monde est plutôt dense avec des objets), les quadries ne seront pas aussi idéales une solution, et une autre représentation serait plus idéale.
Brisez le monde dans des zones plus petites et de les traiter. Toute solution à ce problème va bouillir à ce concept (comme Quadtrees, mentionnée dans une autre réponse). Les différences seront dans la façon dont ils subdivisent le monde.
Combien de données sont stockées par carreaux? À quelle vitesse les joueurs peuvent-ils se déplacer à travers le monde? Quel est le comportement des PNJ, etc., qui sont décrénaux? Est-ce qu'ils se réinitialisent lorsque le joueur revient (comme de vieux jeux Zelda)? Est-ce qu'ils reprennent simplement là où ils étaient? Font-ils une sorte de script de rattrapage?
Combien de données de rendu différentes vont être nécessaires pour différentes zones?
Quelle quantité de monde peut être vue à la fois?
Toutes ces questions vont immaculer votre solution, ainsi que les capacités de votre plate-forme. A propos d'une réponse générale pour ceux-ci sans avoir une idée raisonnable de ces paramètres va être un peu difficile.
Je peux fournir des détails pour mes activités particulières, mais cela ne semble pas aussi utile aux autres ici. Je vais essayer de préciser davantage les paramètres pour une bonne réponse ici ...
En supposant que votre jeu ne mettra à jour que ce qui est visible et une zone autour de ce qui est visible, ce qui vient de casser le monde dans "écrans" (un "écran" est une zone rectangulaire sur le Tilemap qui peut remplir tout l'écran). Gardez en mémoire les «écrans» autour de la zone visible (etc. et d'autres personnes si vous souhaitez mettre à jour des entités proches du caractère - mais il y a peu de raisons de mettre à jour une entité éloignée) et faites le reste sur le disque avec un cache Pour éviter de charger / déchargement des zones couramment visitées lorsque vous vous déplacez. Une certaine configuration comme: où la partie "V" est "l'écran" où le centre (héros ou autre) est, les parties "n" sont celles qui sont à proximité et sont actives (mise à jour ) Les entités, sont vérifiées pour les collisions, etc. et les pièces "F" sont des parties éloignées qui pourraient être mises à jour rarement et sont sujettes à être "échangées" (stockées sur disque). Bien sûr, vous voudrez peut-être utiliser plus de "n" écrans «n» que deux: -). Note BTW que puisque les jeux 2D ne contiennent généralement pas beaucoup de données au lieu de sauver les parties éloignées sur le disque que vous voudrez peut-être Il suffit de les garder en mémoire comprimé.
Merci de partager cela. Je fais déjà quelque chose comme ça, et je l'ai trouvé assez efficace pour mes besoins.
Vous voulez probablement utiliser un seul réseau int ou octet qui relie les types de blocs. Si vous avez besoin de plus d'optimisation à partir de là, vous voudrez alors créer un lien vers des structures de données plus compliquées, telles que les arbres OCT de votre tableau. Il y a une bonne discussion sur un forum de jeu Java ici: http: // www. javagaming.org/index.php/topic,20505.30.html texte
Quelque chose avec des liens devient très coûteux car le pointeur prend quelque chose comme 8 octets chacun, selon la langue, selon la manière dont votre monde est rempli de manière coûteuse (8 points de 8 octets de 84 octets par article et un tableau d'octets est de 1 octet par article). Donc, à moins que 1/64 de votre monde est vide, un tableau d'octets sera une option bien meilleure. Vous aurez également besoin de passer beaucoup de temps dans l'arborescence chaque fois que vous devez rechercher une collision ou tout autre - un tableau d'octets sera une recherche instantanée.
J'espère que c'est assez détaillé pour vous. : -)
J'apprécie les pensées! Il n'est pas assez général d'être la réponse acceptée, mais merci de partager l'idée.