Forum Arkhan

Je corrige au passage : ma sœur ne sort plus avec Tintin depuis belle lurette

Et pour le chan, c'est là (l'adresse est dans le menu du forum "chan IRC")

Isidore, le débat est plus complexe que ca, tu aborde là toute la difficultés des jeux web par rapport aux jeu "en dur", on joue pas dans la même cour ni avec les même ballons...

Tu ne peux pas attendre de l'un de se comporter comme l'autre, et c'est valable dans les deux sens à mon avis.

[Admin] Uld a écrit:

Isidore, le débat est plus complexe que ca, tu aborde là toute la difficultés des jeux web par rapport aux jeu "en dur", on joue pas dans la même cour ni avec les même ballons...

Tu ne peux pas attendre de l'un de se comporter comme l'autre, et c'est valable dans les deux sens à mon avis.

C'est clair qu'on ne peut pas attendre la même chose dans le monde du "client lourd" et dans le "client léger", comme on dit, et s'il y a clairement des limitations, par exemple dans les traitements graphiques qu'on peut espérer, du fait que ton appli web ne bénéficie pas des technos qui vont bien pour exploiter la carte graphique d'un PC, je n'ai pas le sentiment que cette suggestion soit empêchée par une limitation technique réelle. Dans la pratique, il s'agirait de créer un jeu de fonctions javascript capable d'identifier les cases "atteignables" par un perso en fonction du terrain et de ses PA. Après, tout se gérerait avec des événements classiques (onclick, onmouseover...)

Multiplicité de chemin
Limitation des vues en fonction des terrains
Cout de déplacement différents pour les terrains.

Ne serait-ce que pour ces trois choses, il est impossible d'avoir quelque chose de fonctionnellement exploitable pour le joueur.

La combinaison de 1 et 3 fait que la seule implémentation "réaliste" est soit un calcul du chemin le moins cher soit celui du plus court. Dans les deux cas, 50% des joueurs ne seront pas content de la fonctionnalité. En terme de charge, c'est coûteux
La combinaison de 1 et 2 fait que l'arrêt est quasi impossible, car à partir d'une certaine vue, on a toujours quelque chose, dans la vue. donc de base c'ets coûteux, et si tu regarde que ce qui est nouveau, c'est alors juste ultra coûteux.

Je ne vois pas sur quoi tu te bases pour dire que c'est coûteux ? Tu veux dire en terme de puissance de calcul ? Je suis à peu près certain que tout serait gérable côté client, en javascript, et même de façon assez simple. Je ne dis pas qu'il n'y a aucune réflexion à avoir en terme d'algorithmie, m'enfin franchement c'est pas de la magie noire...

En ce qui concerne la multiplicité de chemin et le coût de déplacement, je ne sais plus qui (désolé !) parlait de l'algo A*, il est en plein dans le mil ! Il y a même du code javascript tout fait qui implémente cet algo (Algo A* en Javascript). Et il y a forcément une multiplicité de chemins... mais si on a un algo qui en donne un bon...

Concernant la limitation des vues en fonction des terrains, ce n'est pas vraiment non plus un problème : soit on peut dire qu'un terrain invisible est non ciblable, soit on peut dire qu'il est ciblable et que le PJ s'arrêtera s'il n'a plus de PA ou si quelqu'un / quelque-chose rentre dans son champ de vision...

Et concernant la charge du fait de s'arrêter si on a quelque-chose de nouveau dans la vue, ça ne me paraît pas bien complexe non plus : on connaît la liste des objets présents dans la vue avant déplacement, il suffit de tester les objets présents dans la vue après chaque itération de déplacement de 1 case pour voir s'il y en a un nouveau, non ? Côté serveur, on peut faire les déplacements case par case comme actuellement, et le déplacement en série ainsi que le test de "nouveauté dans la vue" pourrait être fait côté client...

Non, franchement, je ne vois pas ce qui peut militer contre ce type d'améliorations... Je ne dis pas que ce sera utilisable par tout le monde tout le temps (encore que, moyennant une bonne étude sur les règles d'arrêt sur "nouveauté dans la vue"...), mais on a tous autre chose à faire que de cliquer 10 fois pour se déplacer de 10 cases... Non ?

A + !
Yann, aka "Tan Noz", joueur d'Isidore Lemalin

Isidore Lemalin a écrit:

En ce qui concerne la multiplicité de chemin et le coût de déplacement, je ne sais plus qui (désolé !) parlait de l'algo A*, il est en plein dans le mil ! Il y a même du code javascript tout fait qui implémente cet algo (Algo A* en Javascript). Et il y a forcément une multiplicité de chemins... mais si on a un algo qui en donne un bon...

Concernant la limitation des vues en fonction des terrains, ce n'est pas vraiment non plus un problème : soit on peut dire qu'un terrain invisible est non ciblable, soit on peut dire qu'il est ciblable et que le PJ s'arrêtera s'il n'a plus de PA ou si quelqu'un / quelque-chose rentre dans son champ de vision...

Non, franchement, je ne vois pas ce qui peut militer contre ce type d'améliorations... Je ne dis pas que ce sera utilisable par tout le monde tout le temps (encore que, moyennant une bonne étude sur les règles d'arrêt sur "nouveauté dans la vue"...), mais on a tous autre chose à faire que de cliquer 10 fois pour se déplacer de 10 cases... Non ?

Ouais, Il en donne un, mais rien n'indique qu'il est bon, car bon voudrait dire que l'algorithme connait la volonté derrière l'action, alors que c'ets une volonté bien précise qui est implémentée dans le code. A partir de là c'ets du pur fonctionnel, et si tu commences à faire un code rapide pour le chemin le plus rapide, tu vas en avoir un qui va vouloir un code pour éviter les terrains à réduction de vision etc...

Donc fonctionnellement pour Uld, commencer à faire un code comme celui là, c'est ouvrir la possibilité à un tas d'emmerdes et de la gestion de "bug", parce que le joueur ne comprends la fonctionnalité couverte par l'implémentation.

Sur la partie limite, cibler un terrain invisible ca veut dire une refonte de la page de vue et sauf erreur de ma part, tu vas prendre badelel sur le coin de la tronche si tu touches à sa page
Et si on ne cible que le visible tu vas rien gagner sauf en ville.

Pour la partie, on a tous mieux à faire que de cliquer 10 fois en 10 cases. Je me permettrais de corriger que le problème n'est pas exactement ça, la sensation de perte de temps est lié au refresh de la page, pas au déplacement, et rien ne t'empeches d'envoyer plusieurs requetes avant un refresh, aussi appelées maladie du double-click.

Donc perso, je ne vois aucun avantage pour Uld à investir du temps sur cette fonctionnalité.

Sur ce je m'arrête, je sais que c'est la période des listes au père Noël, mais j'ai déjà mes clients pour ça.

[Admin] Uld a écrit:

Non, franchement, je ne vois pas ce qui peut militer contre ce type d'améliorations...

Le fait que je sois le seul developpeur du jeu

8-o T'as fait ça tout seul ?? Vache... Je l'avais dit dans l'autre topic où j'avais fait ma suggestion initiale, mais là je réitère : bravo ! Super (et gros !) boulot !

[Admin] Uld a écrit:

que je bosse dessus en moyenne 30 heures par semaines, et que bien qu'on ait été en bêta pendant un an et demi on a quand même lancé une version finale en mai 2009 qui n'était pas complète et qui ne l'est toujours pas. Bref, que j'ai "mieux à faire".

Quand je disais que je ne voyais pas ce qui pouvait militer contre ce genre d'améliorations, je parlais "évidemment" (mais peut-être pas tant que ça, on dirait ! ) de raisons d'usage/fonctionnelle... Je suis bien conscient du temps nécessaire pour développer et -encore pire- maintenir ce genre d'application en prod sans que ça pète de partout à la moindre modif...

[Admin] Uld a écrit:

C'est gentil le "y a qu'à", "faut qu'on" mais j'ai des priorité plus urgentes. Je ne dis pas que ce que tu propose n'est pas pertinent ni inutile, je pense simplement que j'ai bien mieux à faire et à finir et que cette proposition ne vise qu'à améliorer le confort de jeu d'une partie des joueurs (je suis persuadé que certains -moi inclus- préfèrent le case par case).

Ouh là, désolé si ma remarque a été prise pour un "yakafokon", c'était vraiment pas l'intention... Je sais que pour développer/maintenir un jeu comme ça, ça demande beaucoup de temps, et que l'équipe de dev (çàd toi, si j'ai bien compris ? ) a sans doute une liste longue comme le bras de modifs à faire, et que des fois tu aimerais peut-être même faire autre chose que de t'occuper du jeu... Donc... désolé ! Je reste convaincu que ça apporterait un vrai plus à l'ergonomie du jeu (dans la mesure où ça ne se substituerait en aucun cas à la manipulation en case par case), mais promis, je ne vais pas hurler si cette modif se retrouve loin dans votre "to do list"...

[Admin] Uld a écrit:

L'avantage au moins c'est que t'as l'air de savoir de quoi tu parles, ce qui change des gens qui ralent sans comprendre les implications (y en a), et ca ca fait plaisir.

Oui, je travaille dans le domaine du web alors je situe pas trop mal ce genre de problématiques...

'Florane a écrit:

Ouais, Il en donne un, mais rien n'indique qu'il est bon, car bon voudrait dire que l'algorithme connait la volonté derrière l'action, alors que c'ets une volonté bien précise qui est implémentée dans le code. A partir de là c'ets du pur fonctionnel, et si tu commences à faire un code rapide pour le chemin le plus rapide, tu vas en avoir un qui va vouloir un code pour éviter les terrains à réduction de vision etc...

Je ne te suis pas : c'est purement une question de conceptin et d'ergonomie : que ce soit l'utilisation "case par case" ou "multi-cases", l'algo ne connaît pas l'intention du joueur. Si mon intention est de me déplacer de 10 cases sur la route vers l'Est de Bélérim, et que le joueur veut le faire case par case, rien ne l'empêcherait de continuer comme il préfère, en fonction du contexte. Peut-être que le joueur disposant d'un peu de temps et jouant un voleur en quête d'une proie le fera en case par case, tandis qu'un joueur jouant vite parce qu'il n'a pas trop de temps IRL, et jouant un marchand cherchant à aller au plus vite serait content de trouver un fonctionnement multi-cases...
Quant à l'algo sur le choix du chemin, j'ai envie de dire :
- si on utilisait un algo de choix de chemin, personne n'oblige à l'utiliser : tant que le chemin qui serait emprunté est matérialisé dans la vue, ça resterait un choix du joueur de l'utiliser ou pas...
- on n'est même pas obligés de prévoir un algo de choix de chemin : on pourrait imaginer que ce soit le joueur qui sélectionne le chemin emprunté, en parcourant au pointeur souris les cases par lesquelles il veut que son personnage passe.

'Florane a écrit:

Sur la partie limite, cibler un terrain invisible ca veut dire une refonte de la page de vue et sauf erreur de ma part, tu vas prendre badelel sur le coin de la tronche si tu touches à sa page big_smile

C'est gros comment un Badelel ?

'Florane a écrit:

Et si on ne cible que le visible tu vas rien gagner sauf en ville.

Ben quand même : même avec une vue à 2 cases, ça me fait potentiellement diviser par deux le nombre de clics pour les phases de déplacement qui ne sont pas forcément les plus passionnantes en soi dans le jeu. Et donc autant de temps dispo pour faire du RP...

'Florane a écrit:

Pour la partie, on a tous mieux à faire que de cliquer 10 fois en 10 cases. Je me permettrais de corriger que le problème n'est pas exactement ça, la sensation de perte de temps est lié au refresh de la page, pas au déplacement, et rien ne t'empeches d'envoyer plusieurs requetes avant un refresh, aussi appelées maladie du double-click.

Oui tout-à-fait, c'est le temps de rafraîchissement de la page qui joue... Mais tu veux dire que si je clique 3 fois sur Est dans la rose des vents, mon perso va enchaîner 3 déplacements ? J'ai un gros doute, là...

'Florane a écrit:

Donc perso, je ne vois aucun avantage pour Uld à investir du temps sur cette fonctionnalité.

Sur ce je m'arrête, je sais que c'est la période des listes au père Noël, mais j'ai déjà mes clients pour ça.

Wow, super classe, t'as un impresario, Uld ! Bon, je rigole, hein : je ne sais pas pourquoi la discussion a pris une tournure un peu tendue, en tous cas c'est comme ça que je le perçois, et je le regrette. J'apprécie énormément le travail déjà fait, et comme je l'ai dit dans l'autre topic, Arkhan intègre plein de choses que je recherchais en vain dans d'autres jeux. Voyant un thread "Suggestions" dans le forum, je ne vois pas pour autant de raison de ne pas y faire des suggestions d'améliorations, et les défendre un tant soit peu... ^^ Y'a rien de mal à ça, si ? Ou alors j'ai pas compris à quoi servait le thread "Suggestions" ?

Yann

Isidore: désolé de ma réaction, non je suis bien conscient que tu ne présente pas ca comme un yakafaukon, désolé pour la réponse un peu sèche d'hier.

C'est gros comment un Badelel ?

Je dirais 67 kilos et deux gros boum boum (pas taper, pas taper, aaaaaaaaaah, tapé )

Ou alors j'ai pas compris à quoi servait le thread "Suggestions"

Y a suggestion et suggestion... ca fait bizarre de voir un "nouveau" proposer des refontes aussi énorme. Je suis pas contre mais promis ca fait bizarre...

Ça m'a quand même l'air plutôt pacifique comme discussion, si ça peut te rassurer, on a vu bien bien pire ^^

Sinon, juste un truc hein, Uld il a pas fait ça "tout seul". Certes 90% du code est de lui (j'en donnerais 9,5% à Stifleur qui a malheureusement quitté la team, et 0,5% à Lyraa, quand même ), mais bon, il a pas tout inventé non plus sur le jeu.
Dans les admins y'a ceux qui sont en charge du graphisme, d'autres qui sont en charge du roleplay, du système de jeu, du bestiaire, de la cartographie... y'en a même qui ont un rôle plus "relationnel" et qui se chargent de la communication interne entre les codeurs. Et sans eux, Uld serait un peu démuni.

Bref, je défend un peu mon beefsteak comme on dit, mais bon (sinon je suis d'accord, Uld a fait un boulot énorme sur Arkhan ).


Au passage sinon, tu peux aussi intégrer l'équipe, why not, et nous faire le système de déplacements made-by-you

[Admin] Uld a écrit:

C'est gros comment un Badelel ?

Je dirais 67 kilos et deux gros boum boum (pas taper, pas taper, aaaaaaaaaah, tapé )

Pour les kilos j'en sais rien je ne veux pas savoir, et pour les euh... UUUUUUUUUUUUUUUUUUUUULD !!!!!!



Isidore, ce qui me chiffonne le plus dans ta proposition, c'est que tu remets en cause la base même du système du jeu.

Ouaaaaaaaaaais vas-y Isidor te laisse pas faire

Ecoute pas Erk, il est aigri, tout ça parce que l'autre jour, deux ours mal léchés l'ont un peu rushé sur une suggestion, maintenant il boude ( au fait le post est un peu mort les marchands là )

Moi ton système m'intéresse, en tant que Rôdeur, je gagnerais un paquet de click Je sais pas si ça allégerait la charge serveur, mais si ça fluidifie un peu tout ça c'est pas plus mal

Une rumeur est née sur Badelel on dirais

Mouhahaha j'adore

Dernière modification par Algol (11-12-2009 13:33:56)

C'est ça Trop tard j'ai envoyé la rumeur mouahaha j'adooore

Pour te répondre Isidore, ta vue est une vue autour de la fonctionnalité (feature) et donc son implémentation, la mienne est une vue modification des processus d'encadrement De la même façon que toi, c'est une déformation professionnelle

Pour la multi-requête, je te confirme que ça marche je le fais régulièrement, pas forcément avec tous les navigateurs par contre

Et t'inquiètes pas, on dissèque pas mal, mais on mord pas J'ai commencé un peu avec le même genre de post que toi mais plutôt dans bug
Mais comme le dit Erk, ça peut surprendre.

PS : Badelel est de sexe féminin Si ça peut t'aider

Dernière modification par Florane (11-12-2009 13:47:51)

Isidore Lemalin a écrit:

Florane a écrit:

Pour la multi-requête, je te confirme que ça marche je le fais régulièrement, pas forcément avec tous les navigateurs par contre

Mais dis-moi... C'est pas une sorte d'aveu sur le fait que c'est utile de pouvoir se déplacer plus vite, ça ? Hmmm ??

En fait je le fais sur la preview (1PA par 10s), pas sur le jeu, mais à part sur des déplacements sur les 6 axes principaux, c'est assez inutilisable.
Le seul endroit où je vois vraiment l'intérêt c'est en ville, parce qu'on a une grande vue et les coûts de déplacement sont faibles donc génèrent beaucoup de déplacement, mais quand tu es en dehors la vue étant "réduite" et les coûts de déplacement plus important, ca peut se révéler un peu superflu sauf peut-être par les rôdeurs.