Carte top-down 2D: normalisation ou pas?

Je suis un débutant absolu en programmation de jeux, si cette question est mal formulée, sachez que ce n'était pas de la négligence à mes côtés, mais un manque d'expérience en programmation de jeux.

Le jeu que je prévois de coder utilisera une carte 2D descendante comme "monde". Le monde peut être plus grand que la fenêtre (la fenêtre peut zoomer ou dézoomer) et les véhicules peuvent être situés à n'importe quel point du monde (= ce n'est pas une carte carrelée, l'espace est "continu").

Pour clarifier avec un exemple: si le monde est un terrain de 1000x1000 mètres, un véhicule pourrait être à l'emplacement (327,31, 720,4) mètres.

Ma question est: quelle est la manière la plus pratique de représenter le monde en interne? Je pourrais penser à ces possibilités:

ne rien faire et utiliser des compteurs comme si je travaillais avec l'objet physique,
normaliser en pixels définissant la taille du monde comme le nombre de pixels pour représenter 1000 mètres au zoom maximum,
normaliser à 1 définissant le mot comme un carré de taille 1

... mais je suis sûr qu'il pourrait y en avoir d'autres / certains des miens pourraient ne pas avoir de sens. C'est juste qu'étant mon premier match, je n'ai pas une image claire des problèmes qui m'attendent, et je voudrais des conseils pour faire un choix initial raisonnablement correct.

Merci pour votre temps.

2d maps

— Mac
source

J'ai eu ce problème. Je ne posterai pas comme réponse - il y a déjà beaucoup de choses là-bas. Mais si vous travaillez dans une unité arbitraire, vous pouvez prendre en charge n'importe quelle résolution simplement en modifiant une seule valeur. Il est également beaucoup plus facile à gérer en termes de gameplay. Enfin, avec de grands nombres tels que des mesures de pixels, les simulations physiques peuvent exploser.

— The Communist Duck

Réponses:

Je suis d'accord avec l'utilisation d'une valeur réelle (mètres, pieds, etc.) comme base de la distance. Le problème avec vos deux autres suggestions est qu'elles sont toutes les deux des variables. Si vous travaillez avec une taille mondiale, 1toute votre arithmétique sera en virgule flottante entre -1 et 1, ce qui peut entraîner davantage d'erreurs en virgule flottante. De plus, si jamais vous décidez de créer des tailles de monde variables ("grands" mondes pour des jeux plus longs, etc.), vous introduirez de nombreux problèmes dans votre code. De même, si vous utilisez des pixels, même à un niveau de zoom maximum / minimum, vous rencontrerez de la confusion ainsi que des problèmes si vous décidez d'augmenter ou de diminuer les niveaux de zoom.

— dlras2
source

Cette réponse est excellente (+1). J'aime particulièrement la façon dont vous avez expliqué les problèmes potentiels liés à l'utilisation de "1" pour la taille du monde.

— Randolf Richardson

Si vous faites n'importe quel type de simulation physique, même si elle est totalement inventée, l'utilisation d'entiers à virgule fixe finira par entraîner des résultats invalides. Tout ce que vous avez à faire est de modéliser un seul véhicule se déplaçant à la vitesse unitaire sur la diagonale et vous constaterez que vous n'avez aucun moyen de représenter correctement sa position.

— edA-qa mort-ora-y

RE: utilisation de compteurs. Cela vous aidera également à visualiser et à comprendre mentalement les choses. "Ce véhicule mesure 5 mètres de long", ou "Ces deux objets sont distants de 500 mètres" et ne pas avoir à faire des calculs mentaux tout le temps pour avoir une idée de ce que vous faites.

— Tim Holt

-1 cette affirmation selon laquelle l'arithmétique entière est plus rapide que la virgule flottante n'est pas vraie en général, en fait, ils sont beaucoup plus rapides sur la plupart des plates

— Maik Semder

L'utilisation de valeurs à virgule fixe pour les positions absolues peut être une bonne idée. Cela conduit à une précision constante et à une physique identique partout dans le monde.

— CodesInChaos

Des trois options que vous avez suggérées, l'utilisation des compteurs sera probablement la meilleure. Lorsque vous créez d'autres données, le traitement de la longueur en mètres vous facilitera la vie. Entre autres raisons, vous pouvez décider de changer la taille de votre monde, ou différents niveaux peuvent nécessiter des cartes de tailles différentes.

Vous pouvez également décider d'utiliser des pieds (ou éventuellement des pouces). Une partie de cette décision peut dépendre des packages de middleware que vous utilisez - certains moteurs physiques préfèrent un type d'unité ou un autre (bien qu'il soit presque toujours configurable). Pour la plupart, vous pouvez simplement choisir une unité et aller avec.

— Retourner
source

Normaliser à '1' n'est vraiment pas la voie à suivre (et si vous avez un monde non carré? Ou plusieurs mondes de taille différente ...).

Utiliser les pixels comme ... NE JAMAIS mélanger le gameplay et les mesures graphiques !! Ne vous enfermez pas pour ne pas pouvoir changer les graphiques sans avoir à changer le code.

Les mètres (pieds ou toute mesure que vous aimez le plus) sont donc la voie à suivre. Vous vous sentirez beaucoup mieux pour coder votre lanceur de missiles pour se déplacer à 50 km / h que 0,00076 unités / seconde ...

— Valmond
source