Yop tous le monde , j'ouvre ce topic , car j'ai une idée que j'aimerai bien réaliser sur mon jeu vidéo actuel qui en cours de développement ...
Donc je développe mon jeu avec la librairie slick2d en java sur l'ide Eclipse .
L'idée ce serai donc de faire un champ de vision du personnage , mais j'ai aucune idée de comment le faire ,j'y ai réfléchi toute la journée ...

En clair , c'est d'avoir la map , comme grisée pour montrer les différentes pièces de la map et une partie comme un triangle qui partirai du joueur pour faire le champ de vision et a l’intérieur de celui-ci , y voir les joueur lorsqu'il sont placé dessus , les événement quoi , les actions en cours ...

J’espère que j'ai été compréhensif , si vous avez une idée qui pour m'aider , vous êtes le bienvenu.

Si c'est une map en 2D type damier et qu'il faut gérer finement case par case, ça peut se faire simplement. Il faut juste vérifier, dans une certaine distance autour du joueur, que le champs de vue est libre ou non, c'est à dire si pour chacune des cases de cette zone proche, on peut la rejoindre sans rencontrer un obstacle. Après, il est possible d'ajouter la gestion du sens du personnage sans trop de problème. L'idée générale serait d'utiliser l'algorithme de Bresenham, non pas pour tracer une ligne mais pour tester l'absence d'obstacle, pour toutes les cases à tester, et si le test échoue, considérer la case comme non visible. On peut faire des effets de lumière de cette manière aussi:

Donc si j'ai bien compris , il faudrait créer une mal 2d type damier et utiliser l'algorithme de bresenham ?

Je vais déjà créer un modèle de map sous damier et je reviendrai sur jvc

Est-ce que le logiciel tiled convient?

Attends, pas besoin de changer de méthode pour s'adapter à mon système de ligne de vue. On peut gérer des champs de vision de beaucoup de manières et je t'ai donné celle correspondant à un jeu de type "tilé", car je ne sais pas comment tu le fais derrière, c'est une réponse par défaut. Si t'utilise pas de système de case-par-case, tu peux utiliser des formules de collision entre un segment (allant vers chaque élément à vérifier) et une sphère/carré (les zones de collision).

Mais après une approche par tile est potentiellement plus simple, même si plus lourde. Je ne connais pas assez Tiled pour répondre mais je sais qu'il est fait pour du mapping de ce genre.

eh bien je me vois mal faire toutes les collisons a la main... donc je pense utiliser Tiled pour créer une map sous forme de tuiles et gerer directement les collisions dessus ...

3D : Bonne idée le truc de la lampe.
2D : Gabarit triangle attaché à la position du perso.
+ faire des tirs rafales ultra rapide (pour faire comme des rayons lasers) de projectiles opacité transparent,
qui une fois en collisions avec les objets qui cachent la vue (piliers par exemple), devient noir, de tel sorte que l'on a l'impression de voir une ombre derrière l'objet. (bien sur le projectile continu sur sa trajectoire après la collision...)
Voilà, c'est un peu trucage comme solution, et je ne sais pas si cela peut vraiment fonctionner (en fait, je pose la question ?), mais c'est peut-être plus simple qu'une solution de damier...
Note : Oui Tiled c'est pour faire des map à partir de tuile, type map RPG Maker...

C'est exactement l'idée que je veux intégrer , reste a savoir comment , s'il faut utiliser l'algorithme cité ci dessus

Tester le chemin pour chaque case est un peu plus compliqué à implémenter qu'un tir de projectile aléatoire, mais guère plus, et surtout il garantit une fiabilité totale à un coût en performance facilement prédictible. En faisant un test comme évoqué, tu risque de devoir lancer une très très grande quantité de projectiles pour être sûr qu'il n'y ait pas de "trou" dans la zone de tests.

Si ton jeu marche sous forme de tableau en 2D, utilise le test par case avec l'algorithme de Bresenham, sinon si tu dispose de boites/cercles de collision pour les obstacles, utilise un test de collision segment à cercle ou segment à rectangle.

Le 08 mars 2017 à 17:56:33 blachscholes56 a écrit :
Tester le chemin pour chaque case est un peu plus compliqué à implémenter qu'un tir de projectile aléatoire, mais guère plus, et surtout il garantit une fiabilité totale à un coût en performance facilement prédictible. En faisant un test comme évoqué, tu risque de devoir lancer une très très grande quantité de projectiles pour être sûr qu'il n'y ait pas de "trou" dans la zone de tests.

Il est peut-être possible d'effectuer des tests de collisions (un peu de la même façon qu'avec le test de Bresenham), en testant les collisions entre la bordure du gabarit triangle et les obstacles, et de n'envoyer des missiles que sur les obstacles à la vue ?

Edit (désolé du double post, la fonction edit ne fonctionne plus...) Il faudrait un second gabarit triangle (à l'intérieur du premier), mais transparent, pour tester les collisions....
A partir de là, pas très difficile de décortiquer l'algo...
- Si collision il y a entre le gabarit triangle transparent et les obstacles à la vue, alors un missile invisible est créé à la position (x,y absolue) du perso. Le missile est orienté vers l'obstacle, puis se déplace a très grande vitesse vers l'obstacle.
Si collision il y a entre l'obstacle et le missile invisible, alors le missile noir devient visible.
...