Je viens de faire un test en mettant le sol plus vu de dessus. Je ne sais pas trop si ça passe mieux... comme je disais, j'ai toujours du mal avec la perspective au pif
(et un petit après/avant)
Faut dire qu'en adoptant une perspective moins rasante, la même différence de hauteur dans l'image correspond à une moins grande distance dans l'espace, du coup ta version modifiée rend également compte d'une porte moins immense que dans l'image de départ, ce qui parait plus naturel.
J'aurai quand même tendance remonter un poil Mizuka, et puis donc à étaler la lumière émanant de la porte sur le sol, l'arrêt abrupte de l'éclairage à cet endroit participant à mon sens à la confusion.
Nival, j'ai testé dans le jeu ta 1ère proposition (celle juste avant l'image des escaliers), qui entre toutes semble la plus juste et lisible.
Mais le personnage se retrouve à marcher de profil.
Idem pour ta dernière proposition.
Comme expliqué dans notre article, c'est une question de trajectoire de marche qui s'approche trop de l'horizontale. C'est la raison pour laquelle on était partis sur l'idée d'une porte plus haute dans l'image.
C'est bizarre, mais un dessin parfaitement juste ne sera pas forcément adapté au jeu.
On apprend surtout à tricher en travaillant sur Coral Cave, héhé.
Pour les escaliers, c'est une idée qui implique une animation spéciale donc plus de travail...
Thorn : pour le sol vu de dessus, je vais voir si je peux déformer l'image sans trop l'abîmer.
Au final, je pense que je vais essayer de mixer un peu vos propositions.
Ceci dit, la scène est voulue un peu étrange et sans repère. C'est pourquoi le sol est "coupé" devant la porte, pour donner cette impression que les éléments flottent dans le noir. Et, même si le joueur est désorienté premier coup d’œil, il ne faut pas oublier que le personnage va se déplacer là-dedans... et donc recomposer l'espace.
Pour les escaliers, je rajouterais que ça implique aussi un script spécial : le perso doit "monter", et non s'éloigner... et donc garder la même taille, ce qui n'est pas géré par la perspective de Wintermute.
C'est le genre de truc qu'il faut prévoir dès les premiers croquis pour pas se retrouver avec une surcharge de travail. Du coup, on a plutôt tendance à éviter les escaliers... pour l'instant !
Dans le même genre, on a un problème intéressant qui se profile dans une scène : Mizuka, vue de dos, est censée descendre une pente.
Sauf que comme c'est un jeu 2D, quand on descend dans l'image, le perso est automatiquement de face (logique !).
Il va falloir trouver une astuce, mais c'est ça le plus marrant quand on fait un jeu.
C'est comme résoudre des puzzles !
Mmmh... Ça me semble compliqué de considérer qu'il faille s’accommoder de ce genre de limitation, et donc de se brider lourdement dans les possibilités de mise en image/mise en scène au lieu de chercher à les surmonter.
Il y a surement moyen de faire en sorte qu'en fonction des zones, les différentes orientations du sprite correspondent à des orientations de déplacement différents, déterminés spécifiquement (ainsi que la taille du sprite selon la hauteur sur l'écran).
Spoiler :
Schématisé ici, les deux zones (verte et orange) pourraient avoir des règles différentes pour l'affichage du personnage (les grosses flèches représentant l'orientation du sprite selon les directions de déplacement).
Avec du coup, pour le cas de la descente, le sprite défini comme orienté vers le haut pour des déplacements vers le bas.
Cela permet au final d'intégrer toute sorte de dispositions dans l'espace avec escalier, passerelle, ou tout ce qu'on veut d'autre.
Idéalement il faudrait aussi que les directions verticales et horizontales possèdent un coefficient de vitesse, car une dizaine de pixels dans le sens de la hauteur ne correspondra pas, dans l'espace, à la même distance parcourue que dix pixels horizontalement ; cela changeant là encore en fonction de l'inclinaison du plan par rapport au point de vu (la vitesse finale de déplacement est ensuite simple à calculer en fonction de ses composantes horizontale et verticale). En même temps j'imagine que Wintermute gère déjà cela, mais le truc c'est qu'il faudrait que chaque zone ait des caractéristiques propres sur ce point également.
Je pense qu'effectivement, il est possible de déterminer une zone dans laquelle on oblige le personnage à marcher de dos. Bon, après, je peux pas vous donner le code, mais à mon avis, c'est jouable
Idéalement il faudrait aussi que les directions verticales et horizontales possèdent un coefficient de vitesse, car une dizaine de pixels dans le sens de la hauteur ne correspondra pas, dans l'espace, à la même distance parcourue que dix pixels horizontalement ; cela changeant là encore en fonction de l'inclinaison du plan par rapport au point de vu ; la vitesse finale de déplacement est ensuite simple à calculer en fonction de ses composantes horizontale et verticale. En même temps j'imagine que Wintermute gère déjà cela, mais le truc c'est qu'il faudrait que chaque zone ait des caractéristiques propres sur ce point également.
A part le changement de point de vue, Wintermute fait tout ça d'emblée, en effet : on peut placer des limites horizontales pour définir la taille du personnage (et la vitesse est calculée en fonction de cette taille).
Donc on peut très bien placer deux lignes entre lesquelles la taille ne changera pas, comme ça :
Par contre, s'il y a un escalier, impossible d'y couper : il faut dessiner une animation spécifique.
Donc on préfère éviter si c'est pas absolument nécessaire.
Pour le changement de point de vue, comme le dit Thorn, il y a sûrement moyen d'écrire un script pour ça.
Mais c'est un poil trop compliqué pour nous et, comme on en a besoin que dans une scène, on va plutôt trouver une solution de substitution.
Par exemple, positionner manuellement les différentes frames de l'anim de marche d'une manière spécifique à cette scène.
C'est pas forcément très orthodoxe mais, si ça fonctionne, ce sera une solution simple et rapide.
On essaie d'éviter les prises de tête sur le code quand c'est possible pour nous concentrer sur des solutions visuelles.
Mais je peux comprendre que, quand on se passionne pour le code, on puisse s'amuser comme un fou à résoudre des problèmes par ce biais. Ça semble hyper stimulant !
C'est assez astucieux, définir la taille des objets aux différentes hauteurs dans l'image est trés intuitif pour le développeur et permet ensuite au moteur de calculer tout le reste .
En revanche il devrait justement également pouvoir en déduire les angles de déplacements où p.ex. le perso doit être plutôt de dos que de profil.
Et d'ailleurs ça fait quoi si vous définissez une taille plus faible quand le perso va vers le bas ? (pour considérer le cas de la descente)
Je viens de faire un test en mettant le sol plus vu de dessus. Je ne sais pas trop si ça passe mieux... comme je disais, j'ai toujours du mal avec la perspective au pif
(et un petit après/avant)
Oui c'est mieux aussi comme ça
.
Faut dire qu'en adoptant une perspective moins rasante, la même différence de hauteur dans l'image correspond à une moins grande distance dans l'espace, du coup ta version modifiée rend également compte d'une porte moins immense que dans l'image de départ, ce qui parait plus naturel.
J'aurai quand même tendance remonter un poil Mizuka, et puis donc à étaler la lumière émanant de la porte sur le sol, l'arrêt abrupte de l'éclairage à cet endroit participant à mon sens à la confusion.
Merci pour vos interventions !
Nival, j'ai testé dans le jeu ta 1ère proposition (celle juste avant l'image des escaliers), qui entre toutes semble la plus juste et lisible.
Mais le personnage se retrouve à marcher de profil.
Idem pour ta dernière proposition.
Comme expliqué dans notre article, c'est une question de trajectoire de marche qui s'approche trop de l'horizontale. C'est la raison pour laquelle on était partis sur l'idée d'une porte plus haute dans l'image.
C'est bizarre, mais un dessin parfaitement juste ne sera pas forcément adapté au jeu.
On apprend surtout à tricher en travaillant sur Coral Cave, héhé.
Pour les escaliers, c'est une idée qui implique une animation spéciale donc plus de travail...
Thorn : pour le sol vu de dessus, je vais voir si je peux déformer l'image sans trop l'abîmer.
Au final, je pense que je vais essayer de mixer un peu vos propositions.
Ceci dit, la scène est voulue un peu étrange et sans repère. C'est pourquoi le sol est "coupé" devant la porte, pour donner cette impression que les éléments flottent dans le noir. Et, même si le joueur est désorienté premier coup d’œil, il ne faut pas oublier que le personnage va se déplacer là-dedans... et donc recomposer l'espace.
Pour les escaliers, je rajouterais que ça implique aussi un script spécial : le perso doit "monter", et non s'éloigner... et donc garder la même taille, ce qui n'est pas géré par la perspective de Wintermute.
C'est le genre de truc qu'il faut prévoir dès les premiers croquis pour pas se retrouver avec une surcharge de travail. Du coup, on a plutôt tendance à éviter les escaliers... pour l'instant !
Dans le même genre, on a un problème intéressant qui se profile dans une scène : Mizuka, vue de dos, est censée descendre une pente.
Sauf que comme c'est un jeu 2D, quand on descend dans l'image, le perso est automatiquement de face (logique !).
Il va falloir trouver une astuce, mais c'est ça le plus marrant quand on fait un jeu.
C'est comme résoudre des puzzles !
Mmmh... Ça me semble compliqué de considérer qu'il faille s’accommoder de ce genre de limitation, et donc de se brider lourdement dans les possibilités de mise en image/mise en scène au lieu de chercher à les surmonter.
Il y a surement moyen de faire en sorte qu'en fonction des zones, les différentes orientations du sprite correspondent à des orientations de déplacement différents, déterminés spécifiquement (ainsi que la taille du sprite selon la hauteur sur l'écran).
Schématisé ici, les deux zones (verte et orange) pourraient avoir des règles différentes pour l'affichage du personnage (les grosses flèches représentant l'orientation du sprite selon les directions de déplacement).
Avec du coup, pour le cas de la descente, le sprite défini comme orienté vers le haut pour des déplacements vers le bas.
Cela permet au final d'intégrer toute sorte de dispositions dans l'espace avec escalier, passerelle, ou tout ce qu'on veut d'autre.
Idéalement il faudrait aussi que les directions verticales et horizontales possèdent un coefficient de vitesse, car une dizaine de pixels dans le sens de la hauteur ne correspondra pas, dans l'espace, à la même distance parcourue que dix pixels horizontalement ; cela changeant là encore en fonction de l'inclinaison du plan par rapport au point de vu (la vitesse finale de déplacement est ensuite simple à calculer en fonction de ses composantes horizontale et verticale). En même temps j'imagine que Wintermute gère déjà cela, mais le truc c'est qu'il faudrait que chaque zone ait des caractéristiques propres sur ce point également.
Je pense qu'effectivement, il est possible de déterminer une zone dans laquelle on oblige le personnage à marcher de dos. Bon, après, je peux pas vous donner le code, mais à mon avis, c'est jouable
A part le changement de point de vue, Wintermute fait tout ça d'emblée, en effet : on peut placer des limites horizontales pour définir la taille du personnage (et la vitesse est calculée en fonction de cette taille).
Donc on peut très bien placer deux lignes entre lesquelles la taille ne changera pas, comme ça :
Par contre, s'il y a un escalier, impossible d'y couper : il faut dessiner une animation spécifique.
Donc on préfère éviter si c'est pas absolument nécessaire.
Pour le changement de point de vue, comme le dit Thorn, il y a sûrement moyen d'écrire un script pour ça.
Mais c'est un poil trop compliqué pour nous et, comme on en a besoin que dans une scène, on va plutôt trouver une solution de substitution.
Par exemple, positionner manuellement les différentes frames de l'anim de marche d'une manière spécifique à cette scène.
C'est pas forcément très orthodoxe mais, si ça fonctionne, ce sera une solution simple et rapide.
On essaie d'éviter les prises de tête sur le code quand c'est possible pour nous concentrer sur des solutions visuelles.
Mais je peux comprendre que, quand on se passionne pour le code, on puisse s'amuser comme un fou à résoudre des problèmes par ce biais. Ça semble hyper stimulant !
C'est assez astucieux, définir la taille des objets aux différentes hauteurs dans l'image est trés intuitif pour le développeur et permet ensuite au moteur de calculer tout le reste
.
En revanche il devrait justement également pouvoir en déduire les angles de déplacements où p.ex. le perso doit être plutôt de dos que de profil.
Et d'ailleurs ça fait quoi si vous définissez une taille plus faible quand le perso va vers le bas ? (pour considérer le cas de la descente)
Je viens d'essayer : rien d'inattendu. Le personnage s'approche de nous tout en rapetissant.
Pages