Comment garder mon personnage centré sur l'écran?

Je crée un jeu similaire à Legend of Zelda: Link to the Past (action-aventure 2D descendante). Je veux que le personnage reste centré sur l'écran quand il bouge.

Actuellement, chaque fois que le joueur veut se déplacer, je déplace toute la carte dans la direction opposée. Cela fonctionne, mais comme j'ajoute plus d'objets au monde, les déplacer devient de plus en plus compliqué.

Y a-t-il une meilleure façon d'aborder cela?

2d camera movement

— asbumste
source

Créez une caméra et déplacez-la. Essentiellement, tout sera dessiné avec un décalage basé sur la position de la caméra. Déplacer l'univers pour déplacer votre personnage est un peu excessif, le professeur Farnsworth.

— MichaelHouse

+1 pour référencer son référencement de sa référence futurama: P

— Poignée de porte

@ Byte56 Merci, c'est proche de ce que je fais, donc je pourrais simplement le garder tel quel. Mais cela a beaucoup de sens. Vous voulez mettre cela dans une réponse pour que je puisse l'accepter?

— asbumste

Quel sous-système de rendu utilisez-vous?

— bobobobo

Réponses:

La manière typique de gérer cela est de créer un objet caméra. La forme la plus simple d'une caméra n'est qu'une position. Cette simple caméra définit le "centre" de la vue actuelle. Ainsi, vous ne modifiez pas toutes les positions de vos tuiles / entités, vous soustrayez simplement les coordonnées de la caméra des positions lors du dessin. Dans cette situation, la caméra ne "bouge" pas.

Bien que la caméra et votre personnage partagent une position la plupart du temps, vous pouvez toujours les avoir en tant que valeurs distinctes, vous pouvez donc, par exemple, empêcher la caméra de bouger lorsqu'elle atteint la fin du monde, mais autorisez la joueur de continuer à se déplacer.

Un appareil photo légèrement plus avancé bouge. Toutes les entités et les tuiles sont dessinées sans décalage et la position à partir de laquelle vous effectuez le rendu change. Ceci est très similaire à l'appareil photo le plus basique, et vous pouvez toujours effectuer plusieurs des mêmes optimisations pour le rendu sélectif (en ne faisant appel drawqu'à ce que l'appareil photo peut voir), sur les deux. C'est essentiellement juste une façon différente de voir les choses.

— MichaelHouse
source

Salut Byte, j'ai mis en œuvre ce que vous avez dit avec succès ... Je pense. Mais maintenant je rencontre des problèmes ... pouvez-vous aider à jeter un coup d'œil? Un gars a dit que je n'en avais vraiment pas besoin cam variables... et a proposé une méthode alternative ... stackoverflow.com/questions/18199373/…

— Growler

Je vais y jeter un coup d'œil plus tard, pour l'instant je vous suggère de vous renseigner à ce sujet dans le chat .

— MichaelHouse

Non, ce n'est pas la bonne façon de procéder.

Comment allez-vous faire la détection des pièges? Et quand le joueur atteint les bords des murs? Votre système de visualisation fonctionnera-t-il pour les donjons ou devrez-vous réécrire une partie importante du code?

Le monde est la géométrie. Le joueur est la géométrie. Le monde ne bouge pas. Le joueur le fait. Réglez la position de la caméra pour centrer sur le lecteur. Toujours . Et c'est tout ce qu'il y a à faire.

N'essayez pas de devenir fantaisiste avec "oh si je fais glisser le monde, cela donnera l' apparence que le joueur bouge". Vous allez simplement compliquer les calculs avec des systèmes de coordonnées étranges à la fin de la journée.

Il est vrai que le rendu d'OpenGL fonctionne réellement en «fixant la caméra pour qu'elle pointe vers le bas - z, et en transformant et en faisant pivoter toute la géométrie du monde pour qu'elle tienne dans le volume de la vue canonique», mais vous n'êtes pas censé penser de cette façon lors de la programmation . gluLookAta des paramètres nommés eye, looket uppour une raison - vous pouvez donc penser en termes de système de coordonnées sensible.

— bobobobo
source

L'une des plus grosses erreurs que j'ai faites avec un système d'interface utilisateur GL que je développais a été d'essayer de travailler en coordonnées canoniques ([-1,1]) "pour le rendre plus simple". Tous les objets d'écran avaient des coordonnées dans [-1,1]. C'était une énorme erreur, j'essayais constamment de penser dans cette gamme [-1,1], en convertissant entre pixels et NDC, en reconvertissant. Quand j'ai abandonné cette idée de travailler en NDC et que j'ai juste travaillé en pixels et converti en NDC juste avant le rendu comme vous êtes censé le faire , il y avait un monde de différence dans la façon dont il était facile de penser au positionnement des éléments sur l'écran, traiter les événements d'entrée, etc.

— bobobobo