après carré et hexagone, la position réelle ?

[Ter Rowan]

coucou suite au post d'à côté et les réponses intéressantes, j'aimerais réaliser un système de déplacement basé sur les positions réelles plutôt que sur des "cases" (carrés ou hexagonales)

et je me retrouve un peu sec ...

d'un point de vue gameplay,

- quel GP pour que le joueur se déplace ? utiliser des flèches de direction (4,8,...) ?

- avec une notion de distance (je me déplace de n pixel que j'ai saisi dans un input) ou pas (1 clic/touche = 1 pixel) ?

- J'imagine qu on pourrait penser à je clic sur la carte là où je veux arriver mais je ne trouve pas ce comportement très "sympa" (raccourci utile, mais laisse trop la place au calcul informatique, optimisation d'algorithme, au lieu de l'immersion du joueur)

- Quid des routes ? Avec des cases on pouvait imaginer : case de départ = route, case d'arrivée = route, donc déplacement sur route.
Mais là comment traiter le sujet je suis sur une route et j'y reste ou j'en sors ? de la même manière, différemment ?

'un point de vue technique
- qu'est ce qu on stocke pour la position ? des coordonnées longitude lattitude ? keke parlait de float, mais pas bien compris pourquoi ?

- et la carte, on la stocke comment ? qui dit position réelle plutôt que case doit revoir complètement le modèle à mon sens. En effet on va exploser le nombre de positions, une table [x,y,type de terrain] deviendrait énorme ? j'ai pensé à un moment à du stockage "image" la couleur du pixel représentant son type (avec éventuellement des régions en base permettant des cas particulier) mais est ce pertinent ? est ce qu'on ne ralentit pas fortement les traitements par rapport à des cases ?


bref, plus largement, Comment on fait ? ^^

[LoganG]

Il y a effectivement plein d'intérêts stratégiques... Mais de mon point de vue de nombreuse contraintes ^^

Déjà pour le mouvement, on devra sûrement utiliser du pathfinding. Sans cases, ça risque d'être un poil plus compliqué, et si on veut que ça ait l'air réel...

Ensuite pour ce qui est des calculs : l'orientation de notre objet qui pourrait alors voir à 360° risque d'être difficile à calculer (saus méthode qui me serait inconnue ^^)
On peut aisément le contourner en définissant des directions connues : les 4 (8) points cardinaux, etc...

Pour le déplacement, ça dépendra du jeu : si ce sont des armées (par exemple) qui ont un mouvement maximum, on pourra montrer le rayon d'action de l'objet et un simple clic dans l'aire autorisée enclenchera le déplacement.
Si c'est comme un RPG où le déplacement n'est pas limité (ou très peu), des flèches de direction peuvent être utilisées, mais dans ce cas il faudra préconiser le JS (par exemple), parce que je me vois mal recharger la page à chaque pixel de déplacement ^^

Pour le stockage de la carte, je verrai un fond dessiné qui ne comporterait aucun obstacle, puis on stocke en BDD les coordonées absolues des obstacles et leur taille : par exemple j'ai une maison située à 150px du haut et 80 de la droite, et sachant qu'elle fait 20px de large je peux calculer simplement.
Après, ça ne fonctionne qu'avec des objets... On va pas enregistrer la position exacte de chaque image d'une rivière, c'est sûr.
De ce côté là je n'ai pas d'idées...

Mais là comment traiter le sujet je suis sur une route et j'y reste ou j'en sors ? de la même manière, différemment ?

Si on arrive à connaître les coordonnées de la route, et qu'on connait la taille de chaque tronçon, on peut calculer si la position de notre perso est proche de celle de la route (avec pour marge la largeur de la route et celle du perso)
Mais on revient au problème du dessus : encore faut-il savoir où est notre route...

Bref c'est très attrayant, mais assez compliqué ^^
Si quelqu'un a déjà vu un système semblable quelquepart...

[keke]

Coucou,

Ca ne me semble pas aussi insurmontable.
Les floats est le nom pour désigner des décimales (des variables à virgule).
Ils sont grosso modo de la forme "int,int".
Bref, pour les coordonnées en décimale (mathématiquement on parle de Réel) on peut définir (X, Y, Z) avec X, Y, Z en décimale.

- quel GP pour que le joueur se déplace ? utiliser des flèches de direction (4,8,...) ?

Pour le Game Play, un simple clic sur la position d'arrivée. Cela redonne l'orientation finale.

- avec une notion de distance (je me déplace de n pixel que j'ai saisi dans un input) ou pas (1 clic/touche = 1 pixel) ?

Pourquoi pas ... il n'y a pas qu'une méthode à imaginer. Perso, j'opterais pour une fatigue par rapport à la distance parcouru, mais pourquoi ne pas faire 1 clic = 1 cout de déplacement.

- J'imagine qu on pourrait penser à je clic sur la carte là où je veux arriver mais je ne trouve pas ce comportement très "sympa" (raccourci utile, mais laisse trop la place au calcul informatique, optimisation d'algorithme, au lieu de l'immersion du joueur)

Peut-être que c'est une histoire de goût. Ca donne une plus grande liberté et donc, plus de calcul en définitive. Mais d'un point de vue GP, ça peut rendre qqc de bien ^^

- Quid des routes ? Avec des cases on pouvait imaginer : case de départ = route, case d'arrivée = route, donc déplacement sur route.
Mais là comment traiter le sujet je suis sur une route et j'y reste ou j'en sors ? de la même manière, différemment ?

Alors là, plusieurs solutions.
- Soit tu gères ta carte comme avant en Hexa ou en carré. Quand ton joueur rentre dans la case contenant la route, il profite du bonus. S'il en sort, il perd le bonus de déplacement.
- Soit tu gères ta carte en coordonnée libre. Tu représentes ta carte par des polygones (rectangulaire si ton imagination est déjà flétrie ^^). Lorsque le joueur rentre dans le polygone, il profite du bonus.

- et la carte, on la stocke comment ? qui dit position réelle plutôt que case doit revoir complètement le modèle à mon sens. En effet on va exploser le nombre de positions, une table [x,y,type de terrain] deviendrait énorme ? j'ai pensé à un moment à du stockage "image" la couleur du pixel représentant son type (avec éventuellement des régions en base permettant des cas particulier) mais est ce pertinent ? est ce qu'on ne ralentit pas fortement les traitements par rapport à des cases ?

La solution de stockage par image me semble la plus lourde ...
Sauvegarder tous les objets de la carte sous forme de polygones me semble être le plus sympa. une table artefact, une table polygone, une table sommet (contenant les coordonnées du polygone) ...
Sinon, une alternative mixte entre polygone et carte (hex ou carrée) peut être un bon compromis.
D'autres solutions sont tout à fait envisageable ... d'ailleurs tu noteras que dans mon esprit, j'ai intuitivement rajouté la variable Z pour indiquer l'altitude. Mes polygones, je les vois dans un espace 3D ^^

Bref, bon sujet de discussion ^^.

kéké

[Morningkill]

Pour moi, le plus complexe/fastidieux, c'est la communication avec le joueur.

Dans un jeu à cases, le joueur peut facilement compter "j'ai six cases par tout, la foret coute 2, je peux donc aller la".

S'il n'y a plus de cases, il faut que le joueur ait des outils pour faire ce même genre de calcul.

[wild-D]

mdr, je regardais justement de ce coté.

j'étais parti avec une carte hexa. Et en fait je remets bcp sur le metier mon jeu ces temps (ce qui aide pas à avancer -_-). Dont là, la possibilité de passer en coordonnée "réelle"
(enfin un jeu avec un background spatial, disons que l'on a du vide, donc ça me parait assez naturel, en tout cas bcp plus que d'autre environnement, ou on a une topologie bcp plus contraignante et une interaction terrain-environnement/déplacements bcp plus élevée )

[DragonMaster]

Pour le gameplay je verrais bien un système comme dans "Heroes of Might and MAgic" pour ceux qui connaisse. Je ne crois pas que sa serait si compliqué que sa à réaliser, mais je n'y vois pas d'intérêt.

[NicoMSEvent]

pour moi (mon interprétation), les coordonnées réelles sont en terme de pixel. Hors les pixels sont de tout petits carrés :p

Donc, ce ne sont que des divisions de plus en plus petites, mais toujours en carrés. Seul problème (ou contrainte), c'est que ton perso va prendre plusieurs pixels (plusieurs casses) en même temps.

(idée a développer?)

[keke]

Hum, fractionner pour mieux reigner hein ? me rappelle un thème houleux sur le blog de prélude.

Nico > je ne penses pas comme toi.

Hors les pixels sont de tout petits carrés :p
Donc, ce ne sont que des divisions de plus en plus petites, mais toujours en carrés. Seul problème (ou contrainte), c'est que ton perso va prendre plusieurs pixels (plusieurs casses) en même temps.

tu peux raisonner à une échelle plus petite que le pixel. l'affichage fera une approximation, mais le calcul lui sera au pouième près. 1/1000 de pixels peut-être, voir plus ?

La différence sera que ton "pion" pourra par exemple être incliné de 33,75° . Cela rajoutera par exemple, un angle de vision ou de tir qui pourrait être très intéressant d'un point de vue Stratégie.
En tous les cas, on sort de la contrainte "ton perso va prendre plusieurs pixels" ^^.

Vois-tu tout ce que cela peut induire ? Alors maintenant, rapporte ça à de la 3D, et à l'usage des angles solides (i.e. angles à 3 dimensions)

Kéké

[NicoMSEvent]

rajoutons à ça la détection des collisions (pour éviter que 2 objets s'interpénètrent), et on en arrive a un vrai moteur 3D avec des règles de physique, etc... je crois qu'on s'éloigne tout doucement du concept qu'on avait au départ des jeux web

[Zamentur]

Bon personnellement çà fait longtemps que mon choix est fait pour Algol de ce coté là. Même si du coup on perd une certaines stratégie lié au damier...

Moi je calcul la distance parcourus par le corps et lui augmente son taux de fatigue. Au bout d'un moment il n'est donc plus possible d'avancer.

J'ai décidé d'utiliser le clic pour demander au corps d'aller là ou on veux, via un système de pathfinding ne prenant en compte que les connaissances de celui qui contrôle le corps (vision, gps...).

Ensuite pour le placement des choses je distingue 2 voir 3 choses:
- les objets qui ont une forme, une orientation et une coordonnée dans l'espace, on peux notamment compter dedans les corps, les bâtiments, les rocher etc...
- les chemins qui sont en fait une suite de positions associé chacune à une largeur et une hauteur, ces chemins me permettent de représenter notamment les routes et autre sentier(chemin parcourus par un corps), des champs de force droit et des rivières
- et enfin la 3ème chose concerne les caractéristique d'une zone, par exemple la composition du sol terre, sable, roche, minerai, gaz(ex:nuage)... Ou même éventuellement des zones servant d'optimisation zone de forêt ou les arbres seraient placé aléatoirement. J'ai encore plusieurs solutions pour ce troisième type, notamment la solution polygonal mais aussi une solution plus original à base de barycentre...

A noter que mes planètes ne sont pas fixe, et que leur terrain peut être modifié par des évènements etc...

A noter qu'un espace définis par ce qui est plus haut pourra être intégré comme objet dans un autre. Cas des vaisseaux, des bâtiments ou encore des planètes dans le système algoléens.

Je réserve un identifiant d'univers au cas ou j'ai envie de créer un univers parallèle voir pour des opérations de maintenance.

Le tout sera modélisé coté client à l'aide de polygone et de la bibliothèque sandy 3.0 en action script.

Ceci dit la plus part des choses ne seront pas de la vrai 3d pour des raison de performance.