carte et interactions

[Ter Rowan]

bonjour bonjour

Je me pose des questions sur l'ihm d'un de mes projets, en particulier lors des déplacements du personnage sur la carte.

- Je propose une carte du monde à la google map (je fais glisser la carte à gauche, a droite, je peux zoomer, dézoomer, etc...)
- une icone représente le personnage du joueur.
- par défaut, la carte est centrée sur le personnage (mais vu au premier point, le joueur peut déplacer la carte, donc l'icone du joueur sera déplacée, avec la carte) 


maintenant arrive l'interaction : le joueur décide que le personnage se déplace de sa position d'origine à une autre position. (clique sur un lieu sur la carte et /ou option en dehors de la carte)

comment voyez vous la chose ?

je pense pour ma part :
1) je recentre la carte sur le personnage
2) le personnage se déplace sur la carte qui ne bouge pas
3) une fois arrivée à destination, la carte se déplace pour être centrée sur le personnage


mais je ne sais pas si cela est pertinent, ou si vous avez d'autres idées ou expérimenter des solutions plus user friendly ?

[niahoo]

Pour moi ce serait :

- Si le joueur est visible sur la carte, alors celle-ci suit son mouvement. Si le joueur fait bouger la carte, on stoppe le suivi
- Si le joueur n'est pas visible, la carte ne bougle pas.

Quand on suit le mouvement, on recentre le joueur dans une zone centrale de l'image, mais pas forcément le point central. Si ton joueur est dans le coin en haut à gauche, on va recentrer un peu pour qu'il ne soit pas trop au bord.

[Xenos]

Salut,

la plupart des RTS (supreme commander, world in conflict, voir AOE?) proposent deux modes de vues:
1 • Le mode normal, dans lequel les unités se déplacent dans la carte qui est fixe (la vue ne bouge pas, le décor ne bouge pas, on voit les unités se promener dessus). C'est l'option 2 pure et dure. Perso, je la trouve pratique car elle permet de lâcher un ordre à une unité, et de regarder ce qui se passe ailleurs (la carte est fixe) pendant que l'unité bouge et ce, sans avoir le mal de mer (la vue ne bouge pas).
2 • Le mode suivi, où la vue suit strictement l'unité: si celle-ci se déplace, la vue bouge avec. La carte /le décor bouge, mais l'unité est toujours au centre de l'écran. C'est pratique pour surveiller les alentours de l'unité, et lui donner rapidement un contre-ordre.

S'il n'y a qu'une unité à gérer, la 2e solution est sympa (on surveille l'unité), mais s'il y en a plusieurs, la 1ere est bien meilleure (on fait autre chose pendant que l'unité bouge).


La solution intermédiaire proposée (centrer la vue, laisser le personnage bouger, re-centrer une fois arrivé) peut être pratique, mais j'enlèverai la 3e étape: soit le joueur veut suivre l'unité, et il faut donc un mode "suivi" (cf 2 •), soit le joueur ne veut pas la suivre et il faut donc laisser sa vue là où elle est (cf 1•). Avec la 3e étape (je recentre la vue une fois arrivé), je crains que les joueurs se disent "Je dit à mon unité d'aller là-bas, elle commence à se déplacer, je vais voir ce qui se passe ailleurs, et là, bim, ma vue reviens au personnage: merde, je voulais pas bouger ma vue moi, faut que je retourne là où elle était".

Après, tu peux faire des options, par check box:
Centrer la vue sur le personnage quand:
• vous lui donnez un ordre
• il termine un déplacement
• il est attaqué (ça, cela peut être pratique avec 1 seul personnage )
...
Et un bouton de switch "vue normale / vue suivie" dans l'interface (sur les RTS, c'est un raccourcis clavier).

---

Je n'aime pas l'idée de suivre si le personnage est visible, sauf si on peut désactiver ce comportement, car si on fait un déplacement, la vue s'y "colle", on bouge la vue, elle se décolle, et comment la recolle-t-on? Si c'est "dès que le personnage est visible", alors on est forcé d'avoir une vue collée; si c'est "elle se recolle jamais", on perd une fonctionnalité.

Je pense que, comme toute interface, faut que l'utilisateur puisse choisir les options qui lui conviendront (et un A/B test ou de simples stats permettront de savoir quelles options mettre par défaut).

[Ter Rowan]

oki merci pour ce retour

là ou je suis un peu ennuyé c'est que je pensais faire l'animation de mouvement de l'icone du perso en suivant le path (svg) de la route sur laquelle il était, et pas m'ennuyer à calculer des coordonnées.

Là faudrait que je déplace là carte donc des calculs à faire; faut que je vois, avec des chemins à formule de beziers, si j'ai moyen d'inverser les formules

[Xenos]

T'as pas la possibilité de récupérer les coordonnées réelles d'un objet SVG?

[Ter Rowan]

si si, tu m avais donné la méthode y a quelques temps, mais il faut que je fasse moi même l'animation en javascript du coup et pas utiliser une anim standard css/svg

[Ter Rowan]

hello je reprends mon sujet pour une question d'ergo.

Donc j'ai ma carte, avec des chemins (et des étapes sur les chemins)

sur ordre du joueur, le personnage se déplace sur le chemin allant d'une étape à une autre (1 clic suffit pour faire avancer le personnage de l'étape 1 à l'étape 8)


D'un point de vue jeu, une unité de temps correspond au temps nécessaire pour passer d'une étape à une autre.

Du coup l'unité de temps (jeu) sera proportionnelle au temps (réel) de l'animation pour passer de l'étape N à l'étape N+1

Se pose alors la question du délai IRL.

A votre avis, un joueur moyen est prêt à attendre combien de temps pour passer à l'action suivante (rappel du contexte nous sommes sur une sorte de jeu dont vous êtes le héros, pas sur un WoW)

on dira que sur l'échelle de base de la carte, on peut avoir 10-20 étapes sur une route pavée (bien plus dans une forêt sans chemin) pour traverser l'écran de jeu

[Xenos]

A mon avis, pour une commande de déplacement, faut que ce soit de l'ordre de la poignée de secondes. J'y croyais avant, au coup du "les joueurs passent donner leurs ordres et reviennent quelques heures après pour voir leur effet"... Ben en fait, ils ne reviennent pas forcément :p

Donc je dirai entre 1 et 10 secondes (je n'ai plus la source, mais au delà de 10 secondes, le fil de la pensée s'arrête et le joueur se distrait du jeu), suivant le rapport de taille entre le personnage et les étapes.

[Ter Rowan]

oui je suis plutôt comme toi, même si je joue à therian saga ou les mouvements (et les actions) sont de quelques minutes (à plusieurs heures) je ne trouve pas forcément cela pertinent


après d un point de vue technique je compte réaliser un appel ajax en // du mouvement affiché (ie vérifier coté serveur la capacité à se mouvoir et surtout identifier s il y a des rencontres en cours de route et dans ce cas, s'arrêter à l'étape ou se déroule la rencontre (la rencontre peut être un combat, mais aussi un pnj lanceur de quete par exemple)

du coup prenons le cas suivant :

le joueur lance un mouvement de l'étape 1 à l'étape 8
je lance mon appel ajax ==> le système calcule qu'à l'étape 2 il y a une rencontre (donc le personnage doit s'arrêter à l'étape 2 et le joueur reprendre la main)

mais voilà mon aller retour ajax va prendre plus de temps que les secondes nécessaires à l'animation sur l'écran du joueur

dans ce cas...

est ce qu'il vaut mieux

1) faire l'animation de l'étape 1 à l'étape 8 et au retour de l'appel ajax arrêter l'animation (quitte a déplacer le personnage en arrière)

2) faire l'animation de l'étape 1 à l'étape 2, mettre un beau sablier et attendre le retour de l'appel ajax puis lancer la suite du mouvement jusqu'à l'étape 8 (ou avant si une rencontre a lieu)

3) autre chose

a noter je ferais un appel ajax par ordre de déplacement ==> si l'ordre est de 1 à 8, l appel ajax calculera s'il y a une rencontre (donc une interruption) pour les étapes 2 puis 3 puis 4 puis... tant qu'il n'y a pas de rencontre ==> pas une requête par étape traversée mais une requête par ordre. Mon objectif là est de ne pas multiplier les appels client serveur sans intérêt

[Xenos]

Perso, je ferai ainsi:
• Lancer l'appel ajax pour dire au serveur "je veux aller à l'étape 2"
• Lancer l'animation de mouvement sans attendre le retour de l'appel ajax (normalement, les vérifications de base ont été faites coté client, aka si l'utilisateur n'a pas triché, il n'a pu demander le déplacement que s'il y était autorisé, donc l'utilisateur légitime n'aura pas de "faux départ" de son personnage)
• Si l'animation se termine avant le retour de l'ajax, afficher un indicateur comme quoi le réseau traîne les pieds (sablier ou autre, faut que le joueur pige que c'est le réseau qui est lent, pas le jeu)
• Lorsque l'appel ajax revient, attendre la fin de l'animation
• Lorsque l'appel ajax est revenu et l'animation terminée, poursuivre

Ainsi, je pense qu'on aura un résultat dynamique, sans pour autant avoir de risque de "retours arrières" ou de pauses inexpliquées dus à la latence réseau.

Après, si les déplacements venaient à être long (plusieurs minutes ou heures), j'aurai tendance à mettre en place un système de "callback" (Holowood Principle appliqué au gameplay :p ): on lance son ordre de déplacement, on va faire autre chose, et quand le personnage est arrivé, on reçoit un mal/tweet/SMS pour nous le dire (mais faut que ce genre d'option puisse être désactivée, et qu'elle ne s'applique que pour de longues tâches genre un ou plusieurs jours).