[refusé] cout en pa inferieure sur les routes

[kitsu_taka]

J'ai cherché et je n'ai rien trouvé concernant cette idée... et nos chers concepteurs ont déjà du y réfléchir... mais je poste quand même.

Il y a des routes sur Sistearth... pourquoi les utiliser ne décroit pas  le coût du déplacement (de 1 par exemple)...

En fait, pourquoi ne pas mettre un modificateur positif ou négatif selon le type de terrain ?

Par exemple :
Désert : +1 PA | Routes : -1 PA | Plaine : 0 PA

Si le PJ dispose d'une Licorne, les modificateurs de déplacement pourrait être de cette manière :
Désert : -1 PA | Routes : 0 PA | Plaine : -1 PA

j'explique le 0PA de modif sur la route pour la licorne de la mnière suivante :
Une licorne (un animal mystique) est à l'aise dans les prairies, pas sur un chemin rectiligne qui n'a plus rien de naturel.

Le vice pourrait être poussé jusqu'à donner un avantage de déplacement à un peuple sur un certain type de terrain :
Mizu : aucun
Seizon : route (c'est un peuple marchand) ou les marais
Reikon : plaines "enneigés"
Tsuchi : aucun

Ce n'est qu'une idée

Et en voici une autre :
Une case peut elle avoir une fonction stratégique (au sens, modification de caract) :
Marais : - x phy à l'attaquant ou +x dex en défense
Plaine : neutre
Forêt : -x dex à l'attaquant et -x phy au défenseur


PS: comment ça j'ai trop joué à Colonisation et Civilisation I

[Kub]

Ca a déja été proposé pour v1 et la réponse était que c'était trop difficile à mettre en place, il me semble.
Mais je peux raconter n'importe quoi ^^

[TicTac]

Si je me rappelle bien, les exemples de jeux que l'on avait cités n'autorisaient qu'un déplacement d'une case (donc 8 possibles) ce qui était plus facile à programmer qu'un déplacement potentiel sur 6 cases de distance...Reste que l'idée est bonne!

[uops]

oui je crois que cette idée avait déjà été longuement débattue pour la V1, mais les admins trouvaient que c'était trop dur à mettre en place

[nainfa]

Oui je confirme. Cette idée a été évoquée lors de la v1 mais abandonnée faute d'algo.

Mais si t'en a un, les admins sont preneurs je crois  :wink:

[kitsu_taka]

Le tout est de savoir si le développeur a un accès direct à la matrice.

A) Soit le trajet est du case par case.
 Mon perso est en X

1|2|3 Si 3 est une route alors application modif (9-1 par ex)
-------
4|X|5 Si 5 est le désert alors application modif (9+1 par ex)
-------
6|7|8 ça c'est pas très compliqué

B) Soit il faut faire une recherche du meilleur parcours, et là s'est un peu plus difficile mais on peut considérer des algos de type "arbre" ou récursif (plus pratique dans ce cas).

l'accès a la matrice "visuelle" est là importante, mais la recherche est limitée par le fait que :
1) la matrice fait 11*13 et que le parcours est vers le centre
2) en général, le meilleur parcours ne fait pas le tour de la carte

Déjà une première approche serait de "copier" la matrice, de l'analyser et de remplacer les terrains par la valeur du déplacement. Ensuite, il s'agit "simplement" :roll:  de récupérer la somme de chaque chemin potentiel et de valider le déplacement le moins élevé pour la case choisie.

Quant à l'algo, je peux donner un coup de main si nécessaire bien que je sois rouillé... mais bon... déjà je donne des idées et une solution.

c) on peut donc voir deux solutions, et donc 2 traitements :
cas 1 : un clic sur les 8 cases adjacentes au persos
cas 2 : un clic sur les 16 autres et + cases

Voili.
KT.
"Un informaticien rouillé et fatigué de poster à une heure si tardive."

[TicTac]

Je n'ai rien compris tu m'as donc l'air compétent... :shock:

[Daweird]

le probleme exact est qu'on ne peut pas trouver un compromis efficacité / performance, parce que ce genre d'algos demanderait quand meme des ressources à chaque déplacement.

l'arbre prend pas mal de processeur et le recursif prend processeur et mémoire, meme si c'est plus rapide. disons je sais pas ce que vaudrait le php pour faire ce genre de calculs. Meme si c'est faisable techniquement, je ne considère pas cela comme une priorité, ni comme une amélioration pour l'instant.

[nainfa]

Pour le cas A, cela implique du déplacement au case par case, non? ca surcharge pas le serveur?

Sinon, pour le cas B, ca pourrait peut etre se faire avec du récursif wep mais je suis pas callé j'ai que de petites bases donc trop dur pour moi ^^

[Lilith]

En fait, ca surtout une grosse prise de tète pour un truc pas vraiement significatif...

[glaps]

Je suis en train de bricoler un p'tit jeu avec plusieurs pote : on s'est butée exactement au meme problème.
Comme on voulait absolument pouvoir gerer les type de terrain et les degat selon le type de terrain, c'etais indispensable de trouver un moyen. On a essayer les deux : ça donne ça -->

Arbre :
En local la solution arbre s'est revelé assez sympa, quoi que lourde a mettre en place. C'est le mieux pour l'ergonomie, l'utilisateur peut cliquer directement a l'autre bout de la carte. Mais une fois sur le serveur .... hum. bobo. ( notre algo etais surement pourri puisque prototype, mais ça donne une idée )

Déplacement unique :
Du coups on a retenu la solution B. Qui simplifie les choses pour le programmeur. Mais j'aime pas ce que ça donne pour l'utilisateur. ( un déplacement = un click )

[kitsu_taka]

C'est justement la que le bas blesse...
L'un des cas est du "tape-case" et donc l'utilisateur doit se taper chacun de ses déplacements, ce qui est "lourd" pour lui mais "leger" pour la programmation => une simple fonction de type :

Code: [Sélectionner]

Modif_Pa=recup(Xm,Ym)
 {ou Xm,Ym sont les coordonnés de la carte.}
 
 case Terrain_Carte[Xm][Ym]
                 "type désert" :  Modif_Pa=(+1)
                 "type route"  :  Modif_Pa=(-1)
                  ...
                  reste : Modif_Pa=(0)
 end case
 Return(Modif_Pa);

Et à mon avis, un algo d'arbre doit être optimisable car la taille de la  matrice à gérer est plutôt du 8x8 que du 13*11

Au pire, plutôt que de faire le serveur, pourquoi ne pas utiliser du javascript, et laisser le Pc utilisateur faire le calcul... (mais ce n'est pas très sécurisé.)

Kitsu Taka
"Qui va se repencher sur son bouquin de php2 qu'il n'a pas ouvert depuis fort longtemp) :wink:

[kitsu_taka]

Les méthodes de calculs des déplacements que j'ai expliqué plus haut partaient d'un "mauvais" principe. En effet, j'appliquais le modificateur de terrain vers lequel je me dirigeais.

ex : je suis sur une case désert, je vais vers une route(Xr,Yr) et je suis un chevalier en (X,Y) sans Licorne :

- (Xr=X+1,Yr=Y+1) déplacement en diagonal vers le bas
- Le chevalier se déplacais donc de 8+recup(Xr,Yr) soit 8+(-1)=7

Hors, il faut appliquer le modificateur du terrain en cours, vers la case auquel il faut accèder.

Avec le même exemple :
- (Xr=X+1,Yr=Y+1) déplacement en diagonal vers le bas
- Le chevalier se déplacais donc de recup(X,Y)+8 soit (+1)+(8 )=9

 :roll: *Juste pour précision.

ce qui donnerais une récurence du type
cout_deplacement= recup(X(a à x)),Y(a..x))+8

Mais bon... je ne réponds pas au problème de la recherche du meilleur parcours.

[Kira]

ben en fait ça dépend comment on prend les choses. dans pas mal de jeu c'est le modificateur sur la case ou l'on vas qui s'applique, on peut faire les deux.

et sinan pour dire quelquechose d'utile, je pense que se déplacé case par case ça n'a rien de contraignant:en effet moi je me déplace quasiment toujours case par case au cas ou une mauvaise surprise (un tsuchi ou autre) se trouvait a la limite de mon champ de vision.Je ne pense pas etre le seule a prendre cette précaution élémentaire, donc je pense que si l'idée intéresse vraimen, on peut se permettre de n'autoriser que le case par case, ça ne me semble pas génant.

kira

PS: sinan l'idée de se déplacer pour un cout différent sur les route me semble bonne, tandis que celle de mettre des bonus/malusde défense pour les différents type de terrain me semble peu judicieuse, vu que dans sistearth il peut y avoir un nombre infini de joueur sur une meme case, et que donc tout le monde se retrouverait sur les case fortifiés lors de huerres.

[TicTac]

on peut se permettre de n'autoriser que le case par case, ça ne me semble pas génant.

.

C'est là qu'on avoir des difficultés à traverser les rivières ou l'oasis...