[Moonheart]

Citation :

Publié par DooMeeR

Trop lourd a quel niveau ? Au niveau implémentation ? Ou pour que le MJ dessine ?

Les deux.

Niveau implémentation, c'est bien plus lourd de faire des calculs de trajectoire ou de pathfinding sur un système vectoriel que matriciel. Pense par exemple à la propagation du son: sur du matriciel il suffit de propager de case en case, et la plus forte valeur de deux chemins gagne, sur du vectoriel, c'est pas le même histoire.

Pour le MJ, presque n'importe qui sait faire une courbe sur Paint... pas super belle, mais assez fonctionnelle. Mais j'ai vu en revanche ramer pendant dix minutes à faire une simple courbe comme ils l'ont en tête sur du vectoriel, à galérer avec les points de pivot, les paralaxes, etc.

Et tout cela pour quoi au final? Qu'est-ce que cela apporte de plus sur la structure physique?

[DooMeeR]

Ok alors c'est bien ce que je pensais, tu as quelques idées fausses, et je vais essayer de te les démonter.

Citation :

Niveau implémentation, c'est bien plus lourd de faire des calculs de trajectoire ou de pathfinding sur un système vectoriel que matriciel. Pense par exemple à la propagation du son: sur du matriciel il suffit de propager de case en case, et la plus forte valeur de deux chemins gagne, sur du vectoriel, c'est pas le même histoire.

C'est faux. Est-ce que tu as une idée de comment on fait un ray tracer ? C'est le même principe, mais en beaucoup plus simple et en beaucoup moins lourd. Je vais essayer de te l'expliquer rapidement.

Comment marche un ray tracer ? On fixe d'abord une résolution de l'image. Ensuite on calcule la couleur de chaque pixel un par un. Pour cela, pour chaque pixel, on envoie un rayon dans la direction de la caméra. On calcule les intersections entre le rayon et chaque objet qu'il peut potentiellement traverser. Si le rayon touche un objet, on le sépare en deux rayons : le rayon réfléchi, et le rayon qui traverse l'objet. Là on calcule récursivement la couleur de ces deux rayons, on les multiplie par des constantes qui dépendent de l'objet (par exemple, un miroir aura un gros coef pour le rayon réfléchi et un tout petit pour le rayon qui traverse). Note que le rayon qui traverse peut être dévié selon l'incidence du rayon.

Il suffit donc d'être capable de calculer l'intersection d'un rayon (une ligne droite) avec une surface (un plan, une sphère, etc). Et ça c'est juste des calculs de géométrie très simples, niveau lycée.

Quel rapport avec ce qui nous intéresse ? Et bien c'est simple. On a le joueur qui sert de point de départ pour les rayons. On veut, pour chaque point de l'image, calculer sa valeur de perception du joueur. Et bah c'est pas compliqué : on envoie un rayon qui va du joueur jusqu'au point qu'on est en tain de calculer. Il suffit donc de calculer la liste des objets qu'il traverse, d'appliquer leurs coefficients d'absorption dans l'ordre, et voilà. C'est tout.

Donc c'est un mécanisme aussi simple que celui du ray tracer, sauf qu'en fait c'est encore plus simple pour les raisons suivantes.
1) On est en 2D et non en 3D.
2) On n'a pas besoin de réflexion, de réfraction etc. Ca diminue énormément la complexité (au sens de la durée nécessaire pour calculer).
3) On peut se permettre une résolution très, très faible. Par exemple 40*30, ce qui permet de calculer ça en temps réel et de garder une bonne dose de processeur sous le coude pour faire autre chose.
4) On peut se contenter de faire des calculs d'intersection avec des segments. On n'a pas besoin des objets usuels en ray tracing que sont les sphères etc.

Compare ça avec un système de cases, dans lequel il faut appliquer l'algorithme de Bresenham. Pas très difficile tu me diras. Oui mais ça veut aussi dire que ta résolution maximum est limitée à la taille des cases. Note que dans le cas où, pour un calcul à la ray tracer, on prend une résolution égale au nombre de cases que toi tu utiliserais, on obtiendrais un résultat quasiment identique, que ce soit en terme de vitesse de calcul ou de résultat à l'écran. Or, avec une méthode à la ray tracer, on peut changer la résolution à la volée et la rendre beaucoup plus fine juste en changeant une constante ! C'est donc strictement mieux sur tous les points !

Alors après si t'as beaucoup de segments il faut optimiser un peu le calcul pour ne pas tester tous les segments à chaque fois. Et là c'est magique, l'optimisation est toute trouvée, il s'agit de quad trees. Très utilisés, très classiques, rien de très sorcier là-dedans. Je rappelle le principe : il s'agit d'arbre à 4 fils. La racine de l'arbre est le rectangle qui contient tout le plan. On coupe ce plan en 4 (nord-ouest, nord-est, sud-ouest, sud-est), ça donne les 4 fils du noeud. Et on fait pareil pour les fils récursivement. Ensuite on place les segments dans les noeuds qui les contiennent le mieux. Comme ça si je veux savoir ce qu'il y a dans un rectangle donné du plan, je peux accéder en temps logarithmique à une liste restreinte des segments pertinents. Si les segments sont à peu près répartis équitablement et qu'ils ont des longueurs assez similaires, j'y gagne énormément.

Citation :

Pour le MJ, presque n'importe qui sait faire une courbe sur Paint... pas super belle, mais assez fonctionnelle. Mais j'ai vu en revanche ramer pendant dix minutes à faire une simple courbe comme ils l'ont en tête sur du vectoriel, à galérer avec les points de pivot, les paralaxes, etc.

Encore une fois, c'est faux. Tu peux tout à fait fournir une interface à la Paint, où le MJ a l'impression de faire un dessin non vectoriel. Les éditeurs qui font ça existent depuis au moins la naissance de flash. Note que comme en plus c'est vectoriel, on peut appliquer facilement des heuristiques pour lisser un peu les courbes et les rendre beaucoup plus jolies que ce que tu obtiens avec Paint. Pour te donner une idée, ça donne presque l'impression que ta souris a la précision d'une tablette graphique !

Donc pas besoin de gérer des points de pivot ou de paralaxe ou quoi que ce soit. Je sais pas d'où tu sors ça d'ailleurs, quand tu fais des courbes en vectoriel tout ce dont tu as besoin ce sont de 4 points (2 extrémités + 2 points de contrôle) pour chaque segment de la courbe.

Comment on implémente un tel éditeur facilement ?
1) Quand le MJ clique, on note là où il a cliqué. C'est le point de départ.
2) Tant que le MJ n'a pas lâché le bouton de la souris, à chaque fois qu'il bouge la souris, on note la nouvelle position du curseur. C'est un point intermédiaire.
3) Quand le MJ lâche la souris on note la position du curseur. C'est le point d'arrivée.
On obtient donc une liste de points. On pourrait s'arrêter là et on aurait une suite de segments qui serait déjà plus convaincante qu'un système de cases ! Mais on peut encore aller plus loin et calculer des points de contrôle automatiquement pour lisser la courbe. C'est pas très compliqué. C'est juste qu'après, une courbe de Bézier, pour calculer l'intersection du rayon et de la courbe, on va de toute façon avoir besoin d'approximer la courbe en une suite de segments.

Donc voilà. Tout ça se code en fait assez facilement. Comme d'habitude c'est le peaufinage qui est long, et ça c'est vrai que ce soit avec des cases ou avec des segments.

[Moonheart]

Je reste sceptique.

Déjà ton exemple de ray tracer ne marche qu'avec la vue. La partie la plus difficile à gérer, cependant, c'est pas la vue, c'est le son... une propagation sonore dans un espace vectoriel c'est beaucoup plus ardu que dans un espace matriciel parce qu'au lieu de 4 ou 8 axes de propagation, tu en a une infinité.
Cela revient donc à l'application d'algorithmes complexe sur un outil que je veux portable et léger.

(nb: le point de pivot, c'est le point de jonction entre deux segments d'une courbe, et je pense que dans ton langage, la paralaxe c'est la droite qui passe par tes deux points de contrôle... j'utilise le langage que j'ai tiré d'explications d'une personne qui m'a montré son logiciel de CAO, c'est pas forcément le même que le langage utilisé par les informaticiens)

Citation :

1) Quand le MJ clique, on note là où il a cliqué. C'est le point de départ.
2) Tant que le MJ n'a pas lâché le bouton de la souris, à chaque fois qu'il bouge la souris, on note la nouvelle position du curseur. C'est un point intermédiaire.
3) Quand le MJ lâche la souris on note la position du curseur. C'est le point d'arrivée.

Je peux faire cela sur un système de cases aussi. Pas besoin de vectoriel.



Moi, ce que j'aimerais savoir, c'est qu'est-ce que le vectoriel va apporter?
Je n'ai aucun doute qu'il soit plus complexe. Peut-être pas énormément plus complexe, mais forcément un peu plus.... maintenant c'est quoi la fonctionnalité supplémentaire que cela va apporter à la structure physique?

[DooMeeR]

Edit : Ah désolé j'ai pas vu le crosspost. Bon j'ai vraiment pas le temps de lire ta réponse là, je verrai ça plus tard.

Bon, je me permets ce double post pour essayer de réexpliquer encore plus simplement.

Voici l'algorithme dont tu auras besoin pour les cases :

Code:

On suppose que le joueur est à la position P.
Pour chaque case C :
  Calculer le chemin (algorithme de Bresenham**) qui va de P à C. On obtient une liste de cases.
  Coef = 1
  Pour chaque case C' sur le chemin :
    Coef = Coef * Coef_de_la_case(C')
  Coef vaut maintenant le degré de luminosité de la case C.

Voici l'algorithme dont tu auras besoin avec des segments :

Code:

On suppose que le joueur est à la position P.
Pour chaque point C de l'image finale* :
  Calculer la liste des segments touchés par un rayon de P à C**. On obtient une liste de segments.
  Coef = 1
  Pour chaque segment S dans cette liste :
    Coef = Coef * Coef_du_segment(S)
  Coef vaut maintenant le degré de luminosité du point C.

* Contrairement à l'algorithme pour les cases où la résolution est fixée au nombre de cases visibles, dans mon algorithme la résolution de l'image finale n'est pas fixée, je peux la choisir comme je veux.

** Comme tu peux le voir, la différence est dans le calcul de la liste des cases ou des segments. Dans un cas on applique l'algorithme de Bresenham. Je vous laisse lire Wikipedia pour la description de cet algorithme. Dans l'autre cas, pour chaque segment S, on teste si le segment de P à C intersecte le segment S. Si oui, on rajoute S à la liste.

Je pense que cette simple comparaison te montre que l'algorithme à base de segments (donc vectoriel) est quasiment aussi simple que celui pour les cases.

Ensuite je t'ai déjà expliqué comment coder un éditeur de segments très simple (aussi à bien pour le codeur que pour le MJ), qui permet de dessiner son univers comme si on était dans Paint. L'avantage par rapport aux cases c'est qu'en plus, vu que c'est vectoriel, on peut imaginer des transformations (rotation, zoom) qu'on ne peut pas faire aussi bien dans un univers discret comme celui des cases.

Et au final, la différence c'est que les segments permettent des choses beaucoup plus naturelles et intuitives que les cases. Je pense pas que j'ai besoin d'argumenter là-dessus, si ? Il suffit de voir les trolls entre "grille carrée ou hexagonale" pour comprendre tous les défauts d'un système à grille. C'est le B-A-BA du game design

[DooMeeR]

Citation :

Publié par Moonheart

Déjà ton exemple de ray tracer ne marche qu'avec la vue. La partie la plus difficile à gérer, cependant, c'est pas la vue, c'est le son... une propagation sonore dans un espace vectoriel c'est beaucoup plus ardu que dans un espace matriciel parce qu'au lieu de 4 ou 8 axes de propagation, tu en a une infinité.
Cela revient donc à l'application d'algorithmes complexe sur un outil que je veux portable et léger.

Alors d'abord la portabilité n'a rien à faire dans l'histoire à moins que tu utilises une librairie. Mais si tu codes l'algo de propagation toi-même, ça sera autant portable avec des cases qu'avec des segments.

Ensuite effectivement la propagation du son c'est un peu différent. Cependant, j'ai l'impression que tu sous-estimes la difficulté. Je vois pas comment on peut s'en sortir en calculant "4 ou 8 axes de propagation". Tu peux détailler ton algorithme ?

Parce que moi j'ai l'impression que si tu veux vraiment une simulation réaliste de la propagation du son, il y a beaucoup plus d'axes, même avec des cases. Je suis même pas sûr qu'on puisse parler d'axe dans le cas de la propagation d'une onde, m'enfin. Bref, c'est assez compliqué, et j'aimerais voir ton algo, parce que j'ai l'impression que tu fais une approximation telle qu'on pourrait l'appliquer direct sur la méthode avec segments.

Mais surtout, je ne crois pas qu'il soit nécessaire de simuler la propagation du son de façon réaliste. Je pense que les joueurs ne feront pas la différence entre une propagation réaliste et un calcul comme celui de la vue (en rajoutant une baisse d'intensité dûe à la distance bien sûr). Le seul cas intéressant d'une propagation réaliste serait si quelqu'un veut espionner en écoutant à côté d'un conduit d'aération qui est connecté à une salle dans laquelle parlent les joueurs ou des PNJ. Mais là le MJ peut intervenir et raconter à l'espion ce qui se passe. Comme c'est un cas très rare ça ne pose pas de problème.

Citation :

Publié par Moonheart

Je peux faire cela sur un système de cases aussi. Pas besoin de vectoriel.

Tu affirmais qu'avec des cases, on pouvait faire un truc facile à la Paint où on a juste à cliquer, bouger la souris, puis relâcher le bouton pour dessiner une courbe. Tu affirmais qu'avec des segments, on ne pouvait pas faire ça. Moi, je t'affirme que je peux faire ce que tu fais avec des cases, mais avec des segments et ce, aussi facilement. D'où oui forcément, tu peux le faire avec un système de cases aussi, puisque c'était le comportement que j'essayais de recopier...

Faut suivre la discussion un peu

Citation :

Publié par Moonheart

Moi, ce que j'aimerais savoir, c'est qu'est-ce que le vectoriel va apporter?
Je n'ai aucun doute qu'il soit plus complexe. Peut-être pas énormément plus complexe, mais forcément un peu plus.... maintenant c'est quoi la fonctionnalité supplémentaire que cela va apporter à la structure physique?

"forcément un peu plus" : ça c'est toi qui le dit. Les cases aussi apportent des difficultés en pratique que n'ont pas les segments. Je crois que tu trouves les cases plus simples uniquement parce que tu en as plus l'habitude.

Mais je vais quand même répondre à ta question sur l'intérêt, même si je crois l'avoir déjà fait plusieurs fois.

1) Ca permet de dessiner des trucs plus naturels, puisque moins carrés. Toi tu dis qu'on peut faire ça avec des cases, en séparant le visuel de la physique. Mais ça implique que le MJ doive faire deux dessins différents au lieu d'un seul, ce qui lui demande plus de boulot. En plus il devra faire attention que les cases bloquantes soient bien placées sur les murs, et ça sera forcément approximatif puisqu'il n'aura à sa disposition que des cases. Du coup les collisions et les lignes de vue ne correspondront pas exactement au dessin et ça se ressentira pour les joueurs.

Quoiqu'on en dise, les cases restent une simplification, une abstraction qui s'éloigne de la réalité plus que les segments, donc le MJ devra forcément faire des compromis.

2) Ça permet de zoomer et de dézoomer autant qu'on veut, ce qui est important pour le MJ qui veut avoir une vue d'ensemble pour vérifier la cohérence. C'est aussi possible avec des cases, mais c'est plus compliqué que dans un monde vectoriel où il suffit de tout multiplier par le zoom pour obtenir le zoom quasiment gratuitement.

3) Tu peux beaucoup plus facilement augmenter la taille du monde avec du vectoriel. Avec des cases, quand tu multiplies par deux la largeur et la hauteur, tu multiplies par 4 le nombre de cases à stocker en mémoire. Avec du vectoriel, tu ne stockes que ce qui est important, donc multiplier par deux la taille du monde ne change rien. Tu peux même te permettre d'avoir une seule feuille de papier gigantesque pour le monde entier, du moins s'il est sur un seul étage et si tu as le courage de le dessiner entièrement.

4) Le vectoriel apporte plus de flexibilité, puisque tu peux changer la résolution à la volée. Avec des cases, si tu décides tout à coup que finalement tu veux des cases plus petites, le MJ doit retoucher tout son monde. Avec du vectoriel, tu n'as strictement rien à changer. Du coup, ça permet, si ton logiciel est toujours utilisé dans 20 ans, de profiter de l'évolution technologique du matériel pour augmenter la résolution juste en changeant une constante, ce que tu ne peux pas faire avec les cases.

5) Le vectoriel est porteur de sens, plus que les cases. Par exemple, imaginons que tu veuilles faire un mur. Avec des cases, bon, tu places disons 23 cases "mur" côte à côte. Avec les segments, tu peux imaginer placer le point de départ et d'arrivée. Bon. Ensuite imagine que tu veuilles déplacer le mur, le rendre un peu plus petit et le tourner de 45° en même temps. Avec les cases t'es quasiment obligé de redessiner le mur et donc ses 23 cases, alors qu'avec le segment, t'as juste à déplacer le point de départ et le point d'arrivée.

[Shahanyr]

Vous avez peut-être la chance d'avoir une bonne connexion mais beaucoup n'en profite pas forcément. À la base de cette idée repose quand même le fait que le logiciel de communication fonctionne aussi bien qu'un téléphone et on en est pas là.

Encore un peu trop tôt peut-être pour qu'un tel projet soit d'usage courant une fois présenté au public. Alors devriez vous peut être envisagé qu'il se développe dans 10 ou 15 ans et de voir avec beaucoup de longueur d'avance.

[Menestrel]

Je n'ai que survolé le thread, et je vais rester loin des considérations de ray-tracing, mais avez vous déjà jeté un œil au jeu Sleep Is Death de Jason Rohrer ?

C'est à peu près le principe du jeu de rôle classique avec les possibilités immersive du jeu vidéo. Le problème, c'est que ce n'est prévu que pour être joué à deux.

http://sleepisdeath.net/

En espérant que ça vous inspire, j'aimerais bien avoir vos réaction à son propos.

[JdlF]

En fait ... Il faut tout de même des cases parce que .... La majorité des jdr papiers fonctionnent par cases.

[Ygard]

Citation :

"La majorité des jdr papiers fonctionnent par cases"

mais ce n'est pas un bon argument non plus les jdr règlent leur combat et leur distances par cases, parce que c'est une abstraction facilement compréhensible par l'Homme.

Avec l'aide de l'ordinateur pour régler ces point de règles, on peut s'abstraire (quasiment totalement) de toutes les nécessitées de connaitre les règles pour juste garder le l'histoire et le RP.

Citation :

Vous avez peut-être la chance d'avoir une bonne connexion mais beaucoup n'en profite pas forcément. À la base de cette idée repose quand même le fait que le logiciel de communication fonctionne aussi bien qu'un téléphone et on en est pas là.

Faux.
Un logiciel comme ça, c'est même pas 50Mo, et envoyer une poignée de ligne de texte a chaque tour, ça prend rien comme connections. aucun besoin en latence, et la VoIP, ça prend pas temps de place que ça.

[Shahanyr]

Ygard, j'écrivais que s'il n'y avait pas de bonnes communications vocales, les logiciels jdrs n'ont pas d'intérêt. Ou alors on sort de l'expérience de partie de jeu de rôle de table via vocale.

[GtB]

Le système par case implique un pathfinding style A* ce qui peut être assez laborieux à mettre en place.
Avec du vectoriel on peut remplacer le pathfinding par un système de collision ultra basique, beaucoup plus léger et flexible.

La partie compliquée me parait les communications vocales. Commencer par un mode texte serait peut-être plus simple, après tout dépend des compétences techniques des développeurs.

[Dez]

Citation :

Publié par Moonheart

Je notes ces remarques sur le tracé. Tu as peut-être raison sur le fait qu'il ne faut pas que je fasses un quadrillage si gros, mais alors je dois réfléchir à comment gérer le fait que les personnages tiennent sur plusieurs "pixels".

La solution simple serait de ne considérer que le "centre" du personnage pour tous les calculs, mais cela fait qu'il y aura des cas un peu approximatifs, comme par exemple le cas où le moteur n'affichera pas un personnage alors qu'il est évident que son bras dépasse d'un recoin de mur...

C'est une fausse problématique, car tu rencontres rigoureusement la même chose sur un quadrillage.



Car là, tu détermines comment ce que peut voir le personnage qui se situe dans la case verte par rapport à ce qui se situerait dans la case orange ? Voir partiellement = voir totalement ou voir pas du tout ?

Je rejoins les arguments de DooMer concernant l'avantage d'un plan basé sur du vectoriel. Il n'y a que des avantages. Et si le besoin se fait ressentir d'utiliser un système de quadrillage pour la faciliter la gestion des phases de combat, il suffit de rajouter une grille en sur-impression par rapport au plan.

Comme ça, la gestion des personnages / plans pourrait toujours se faire ainsi, mais sans devoir s'attarder sur les limitations inhérentes à un quadrillage pour ce qui est de la "physique" (vue, etc.)

[Moonheart]

Alors, laissez-moi un peu synthétiser ma pensée.

Dans un premier point, si j'ai décidé de séparer structure physique et apparence graphique sur les cartes, ce n'est pas à cause du matriciel: c'est parce que je veux permettre aux MJs d'utiliser des dessins importés, soit trouvés sur le net dans des scénarios tous faits, soit dessinés avec leur outil graphique préféré plutôt que d'imposer le mien.

On ne fera pas mieux qu'un photoshop ou un paint simplement sur la base d'un développement d'une ou deux personne en bénévolat. Il en découle qu'importer une image pour le fond de la carte est plus ouvert, souple et performant que d'essayer de faire un outil qui la dessine.

Je suis d'accord que cela rend la structure physique un peu plus dure à aligner... mais avec une simple "baguette magique" comme dans photoshop, qui permette en un seul clic de sélectionner toutes les cases couvrant un tracé commun dans l'image de fond, on doit arriver à permettre au MJ de faire cela relativement simplement.

On a donc pas de souci particulier sur le côté "carré" du matriciel ni sur le réalisme dès que la finesse des cases sont suffisantes. Les autres fonctionnalités, comme le zoom ou le fait de ne pas stocker toutes les cases d'une structure physique évitant la multiplication linéraire de sa taille quand on augmente la taille globale du monde, se font très bien en matriciel aussi.
Je n'ai donc toujours pas conscience d'une fonctionnalité qu'apporte le vectoriel et le matriciel non dans ce paradigme.

En attendant, je reste persuadé sur le vectoriel est bien plus complexe à implémenter, peut-être pas sur les calculs de perception ou de mouvement (et encore le cas du son continue à me rendre perplexe) mais sur l'ergonomie nécessaire pour concevoir le dessin vectoriel en lui-même.

Pour comparer, voit un peu que Paint ne fait que 340ko pour un nombre de fonctionnalités non-négligeables sur du dessin purement matriciel (lasso magique, rotations, zooms, stockage sous différents formats, etc)... pouvez-vous seulement me trouver un outil de taille comparable en dessin vectoriel?

Citation :

Ensuite effectivement la propagation du son c'est un peu différent. Cependant, j'ai l'impression que tu sous-estimes la difficulté. Je vois pas comment on peut s'en sortir en calculant "4 ou 8 axes de propagation". Tu peux détailler ton algorithme ?

Je l'ai expliqué déjà plus haut: tu fais en récursif. Tu commences par fixer une clarté par défaut au point de départ du son, puis tu "propages" récursivement dans les cases adjacentes en amoindrissant la clarté à chaque fois par le facteur d'isolation de la case.
Si tu arrives par propagation dans une case où tu as déjà calculé une clareté, tu stoppes cette propagation à moins que la clareté soit supérieure (c'est à dire dans ce cas que le son à pris ici un chemin de moindre difficulté, genre en contournant un mur au lieu de passer à travers)

Du coup, ta propagation se faire uniquement dans 4 ou 8 directions (en fonction de si tu décides de taper dans les diagonales ou pas quand tu évalues les cases adjacentes) et le rendu est très réaliste.
Mais en vectoriel, cela n'est pas possible. Il va te falloir un algorithme de pathfinding pondéré très complexe pour calculer la même chose

Citation :

Publié par Shahanyr

Ygard, j'écrivais que s'il n'y avait pas de bonnes communications vocales, les logiciels jdrs n'ont pas d'intérêt. Ou alors on sort de l'expérience de partie de jeu de rôle de table via vocale.

Ce n'est pas mon problème ça.
Pour la communication vocale, y'a Skype, je ne prévois pas d'essayer de redévelopper ce que des outils existants et pouvant être lancés en même temps font très bien.

De toutes façons, il est impossible de reproduire à 100% l'expérience sur table à travers le net... d'où l'utilité d'apporter des compensations et c'est sur cela que ce projet se concentre, pas le reste.

[GtB]

Ta technique de flood ok, ç'est simple à mettre en oeuvre, sauf que ce qui fait qu'un son est perceptible dépend principalement du niveau de son ambiant et l'atténuation par le milieu (une cascade à proximité, une caverne silencieuse, murs et sol recouverts de moquette) et là il faut que tu appliques des gradients sur toute ta map et avec Paint oublies.
C'est pourquoi je disais qu'un système par case est plus complexe, on vas se retrouver avec 30 infos par case assez rapidement, tout ça avec des gradients ce qui donnera 30 maps au lieu d'une.

[Ebe]

Désolée, j'ai pas lu toutes vos réponses : je passe juste en coup de vent pour exprimer ma joie de voir ressortir l'idée du JDR web écrit/vocal. Ayant fait partie des joueurs expérimentaux, je confirme que c'était vraiment super intéressant et sympathique, très différent de ce que j'ai pu tester autrement et plein de possibilités. Bon courage !

[Moonheart]

N'exagérons pas, GtB. Concrètement parlant, s'il y a trois sources significatives de bruits dans un même lieu, c'est le bout du monde dans un scénario.

Si tu veux symboliser le fait que dans un lieu il y a du boucan et qu'on entend rien d'autre, on peut aussi faire que les cases libres aient une isolation de 100%, c'est du bricolage, mais c'est un cas si rare que cela peut suffire


@Ebe: Merci. Je regrette seulement qu'on ait pas pu mener mon scénario au bout à cause de l'indisponibilité de certains.

[Flak]

génial ! se projet est tout simplement génial !

courage pour la mise en œuvre .

ps : si tu as besoin d'un programmeur delphi/python je peux aider

[Moonheart]

Non, je ne pense pas le coder dans ces langages, et ce pour deux raisons:

1- Je souhaite que cela soit portable et utilisable via le web. Ce qui laisse en gros Java et Flex comme langages sérieux pour le faire.
2- Je ne connais ni Delphi ni Python parce que ce sont deux langages absolument exclus d'utilisation dans mon milieu professionnel

[Gardien]

pour le son, a mon avis, tu devrait faire ton systeme de "flood" a partir de la sourcedu son et non du joueur en la stockant dans une matrice stockant tous les sons "actifs".

ca permet de gerer tous les types d'environnement ambiant pour pas cher tout en etant simple.

et pour le coups, à chaque "update" des positions des joueurs and co, tu n'a rien a calculer au niveau du son, juste à lire dans ton tableau. les seuls cas ou tu aura à faire des calcules cela sera quand un son sera modifier / jouer / stopper ce qui est plus rare je pense que les mouvements et autres actions des joueurs

en gros, au lieu de faire pour chaque joueur : flood joueur => son
faire plutot pour chaque modification de son (arrêt, départ etc) : flood son => monde, stocker dans une matrice.

dans tous les cas, ce projet m’intéresse

edit : en faite, c'est pas tres clair si ca se trouve, c'est deja ce que tu disais si c'est le cas, j'ai rien dit

[Moonheart]

C'est bien comme cela que je pensais le faire. Après il faut gérer intelligemment les conversations, qui sont un son qui change très souvent, plus que les positions des joueurs.

[Gardien]

Citation :

Publié par Moonheart

C'est bien comme cela que je pensais le faire. Après il faut gérer intelligemment les conversations, qui sont un son qui change très souvent, plus que les positions des joueurs.

avec un systeme d'ID de son, pour les son ambient ou pour les joueurs. ca prend la derniere phrase dite par le joueur.

et quand le joueur se deplace, il deplace son ID de son.

truc du genre... enfin ca marche aussi si on veut garder tous l'historique (ou qu'une partie), en gerant plusieurs ID par joueurs aussi... ca complique juste un peu plus les choses

[Flak]

Citation :

Publié par Moonheart

1- Je souhaite que cela soit portable et utilisable via le web. Ce qui laisse en gros Java et Flex comme langages sérieux pour le faire.

queoi !! et C# et Vb net ^^?
silverlight c'est bien, quand je vois se que l'autre team de dev fais avec ses outils !

[Moonheart]

Flex fait mieux.

[DooMeeR]

Je réponds à Moonheart encore une fois. J'ai relevé 3 questions principales :
1) Comment propager le son de façon réaliste en vectoriel ?
2) Comment implémenter facilement un outil de dessin vectoriel ?
3) Quelles sont les fonctionnalités apportées ?
Alors c'est parti.

1) Comment propager le son de façon réaliste en vectoriel ?

Tu peux appliquer directement ton algorithme à base de case. Moralement, tu superposes une grille au-dessus du monde vectoriel, et tu calcules le coefficient de propagation d'une case à l'autre de la même façon qu'on a fait pour la vue : en envoyant un rayon du centre de la case d'origine, vers le centre de la case d'arrivée, et en calculant les intersections avec les segments rencontrés.

Alors évidemment, tu me diras que ça sert à rien de faire du vectoriel si c'est pour finalement calculer avec des cases. C'est presque entièrement vrai pour le son. Mais là on est dans un contexte où il n'y a pas que le son (cf ma future réponse à la question 3).

Je dis "presque" entièrement vrai parce que la représentation vectorielle permet deux astuces :
- on ne crée la grille qu'autour de la source du bruit ;
- on peut régler la finesse de la grille à la volée, en fonction de la puissance CPU disponible, comme pour le calcul de la vue.

Pour finir, je pense que ton algorithme de flood est très naïf et que tu peux avoir un résultat équivalent en utilisant un calcul de flot dans un graphe de capacité. Je te laisse te renseigner. Ca n'a rien à voir avec le débat vectoriel / cases, puisque ça s'applique aussi (et même plus facilement) pour les cases.

Bon mais je persiste à penser que de toute façon ça ne sert strictement à rien de calculer la propagation du son de façon réaliste, et qu'on s'en sortirait très bien avec le même calcul que pour la vue (mais avec des murs qui laissent passer une partie du son, hein). J'en ai déjà parlé dans mon post précédent.

2) Comment implémenter facilement un outil de dessin vectoriel ?

Bah je t'ai donné l'algo pour tracer des courbes à main levée il y a déjà quelques posts. Tu as besoin de quoi d'autre que des courbes à main levée ? Oui bon il faut pouvoir effacer des segments, ok. Je pense pas que ça soit ça qui pose problème, si ?

On n'a pas besoin de refaire un éditeur à la Inkscape hein, on a juste besoin d'un outil pour que le MJ puisse dessiner rapidement le plan des lieux...

3) Quelles sont les fonctionnalités apportées ?

A chaque fois que tu me poses la question je te donne plein de réponses différentes, et à chaque fois ou presque tu me reposes la question telle quelle, sans me dire ce qui ne te convient pas dans ma réponse Du coup forcément, au bout d'un moment je n'aurai plus d'arguments c'est sûr... Enfin bref.

La fonctionnalité principale apportée, je le répète donc, c'est des environnements beaucoup plus naturels. Pour avoir quelque chose d'équivalent avec des cases il te faut des cases d'un pixel de côté ! Et encore, parce qu'en vectoriel tu peux zoomer à l'infini, et donc la notion de pixel est assez floue...

Supposons que tu n'affiches à l'écran qu'une image dessinée hors de ton outil. Comme je l'ai déjà signalé, ça implique de doubler le travail du MJ, parce que t'as pas toujours à ta disposition des images pour ton scénario, surtout si tu l'as inventé toi-même. Mais même, admettons que tu aies une image. Si tu utilises des cases, même si elles ne font que 10 pixels de large, tu vas avoir un effet d'escalier dans tes collisions, dans tes lignes de vue, bref dans tout ce qui est sensible par le joueur. Et comme il ne verra que la partie lisse, qui est fausse, il ne comprendra pas pourquoi des fois ça collisionne à 8 pixels du mur et des fois à 1 pixel. Il y aura une incohérence entre les différents sens : la vue ne sera pas cohérente avec le toucher, par exemple. Et le joueur mettra ça sur le compte d'un bug. Ou d'une limitation artificielle débile, qu'elle soit technique ou non (comme avec les murs invisibles dans pas mal de jeu).

Si tu as des cases c'est que tu imposes des contraintes très forte au MJ sur la façon de représenter le monde. C'est peut-être une croyance philosophique de ma part mais pour moi, l'intérêt du JdR papier, c'est d'être le plus libre possible. Les cases c'est moins libre que le vectoriel.

Autre fonctionnalité, le zoom. Je le mentionne ici parce que tu y as répondu. Tu dis qu'on peut le faire avec des cases. Oui, mais ça demande beaucoup plus de boulot qu'avec du vectoriel. Je te l'ai signalé mais tu sembles ne pas l'avoir lu. Avec du vectoriel il suffit de tout multiplier par le facteur de zoom au moment des calculs. De plus tu n'auras pas tous les effets d'escalier à la con qu'on obtient avec du zoom d'image non vectorielle, ça sera plus efficace, etc.

Peut-être que tu manques de pratique avec le vectoriel aussi ? Il y a des jeux qui n'ont été possibles de créer que grâce au vectoriel. Voici quelques exemples.
- Tous les FPS. Bon, sauf Wolfenstein 3D. A part lui, tous les décors sont en vectoriel : on peut placer les vertex de chaque polygone n'importe où dans l'espace. Imagine un FPS à base de cubes ? Non, au lieu d'imaginer, tape "minecraft" dans google image...
- Gish. Impossible de représenter précisément à l'écran l'état physique du héros (une boule de goudron) s'il n'était pas vectoriel.
- Loco Roco, pour la même raison que Gish.
- World of Goo, aussi pour que la physique colle parfaitement à la représentation à l'écran.

A tout ça faut rajouter tout les autres exemples des 3 pages précédentes.

[Ygard]

pour parler un peu hors du "vectoriel vs cases" :

Ca n'est pas parce que c'est plus subtil, ou plus détaillé, que c'est "mieux", personnellement, j'ai toujours considéré les graphisme crasseux de NWN1 comme une force d'abstraction.
De même, je préfère du pur texte que la personne a pris quelques secondes a penser avant d'écrire à de la voix mal jouée, et je préfère du beau pixel art dans mes textures carrée que des trait souples avec des textures moches, ou que du simple trait.

Comme quoi, des gout et des couleurs...