Dofus Battle Arena

Jeu de plateau 3D (inspire de Dofus)

a marqué ce sujet comme résolu.

Et bien ca avance mine de rien, continu comme ca !

Petite remarque, avant de commencer la partie combat, tu pourrais peut être étoffer encore un petit peu le déplacement. En mettant en surbrillance toutes les cases disponibles par exemple. On aurait une meilleur vision de ce qu'il est possible ou non de faire. Tu pourras même réutiliser cette technique pour afficher les cases d'attaque à distance.

Après fait comme tu le sens ce n'est qu'une proposition. ;)

+0 -0

Effectivement ca m'a l'air d'etre une bonne idee d'amelioration. Je pense que je vais l'implementer et a la limite je le mettrai dans les options en laissant le chois au joueur de l'activer ou non.
D'ailleurs je compte aussi faire un systeme de mise en transparence. Je m'explique : actuellement, lorsqu'un joueur est derriere un batiment, il est impossible de la voir et presque impossible de cliquer sur la case. Ce que je veux mettre en place c'est mettre les batiments et elements du decors en transparence lorsq'un perso passe derriere celui ci.

Tu peux déjà régler le problème du click à travers un bâtiment ou un obstacle esthétique (décor), en terme d'interaction seul les cases importes.

Du coup, pour que ton click ne soit pas "intercepter" par un décor tu peux le mettre dans le Layer "IngoreRaycast". Et hop un problème de régler mais bon comme tu l'as dis, il faudra aussi mettre en semi transparence le décor pour voir ce que l'on fait derrière. ^^

Personnellement j'ai déjà ma petite idée pour détecter quand et comment mettre le décor en semi-transparence mais je te laisse le plaisir de chercher. ;)

+0 -0

Yep j'ai aussi déjà quelques idées.
Pour le truc de la transparence, je pense que je changerai le material de l'objet qui bloque la vue en transparent diffuse, j'ai testé de le faire à la main ça fait l'effet que je recherche.
Pour la détection du moment ou le perso passe derrière un décors, je comptais faire un raycast avec la position du perso et le maincamera mais si je mets les trucs dans le IgnoreRaycast layer ça marchera pas … hum faudra que je me creuse la tête là c'est juste les trucs qui me sont venus instantanément

Personnellement j'aurai fais le raycast à partir de la case highlight ET du/des persos.

Mais sinon c'est pas mal l'idée est bien la. Pour le régler le problème essaye de creuse la piste d'un layer de personnaliser "Transparancy" par exemple. Avec les même propriétés que le IgnoreRaycast. Ensuite tu peux simplement pas préciser un Mask de layer à ta fonction raycast pour qu'elle ne prenne que le layer "Transparancy" en compte.

C'est une idée il y a peu être mieux comme il y a moins bien. Mais c'est certain que ca fonctionnera sans trop d'inconvénients.

Ps: On devrait renommé le sujet "Les Raycast dans Unity" tellement qu'on en parle. ^^

+0 -0

Ouai je vais tester ces solutions et voir ce qui correspond le mieux a ma situation. Par contre j'ai pas compris le principe du raycast a partir de la case highlight et du perso. C'est sense detecter s'il y a un obstacle sur le chemin si c'est bien ce a quoi je pense. Du coup ca marcherai pas car suffit que le perso passe derriere un decors mais sans intercepter celui-ci (j'entends par la qu'il fait son chemin en ligne droite).

Par contre c'est vrai qu'on parle beaucoup des utilites du raycast ici. En meme temps je me rends compte en les utilisant plus que c'est vraiment un outil super puissant et que ca offre enormement de possibilite pour le developpement. J'etais un peu réticent au debut car j'y comprenais que dalle mais honnetement c'est un element tres important d'Unity (je sais pas s'il y a le meme genre de chose sur les autres moteurs genre UE4).

Par contre j'ai pas compris le principe du raycast a partir de la case highlight et du perso. C'est sense detecter s'il y a un obstacle sur le chemin si c'est bien ce a quoi je pense.

MeliMelo

Arf, j'ai pas du m'exprimer clairement.

En gros l'idée n'est pas de faire un raycast de la case vers le perso ou inversement. Mais un raycast du perso vers la camera pour voir si tu n'as pas d'obstacle t'empêchant de voir ton personnage. Et idem pour les cases. Faire un raycast depuis chacune des cases highlight toujours vers la camera pour voir si il n'y pas d'obstacle entre le chemin et la camera. C'est quand même mieux de voir ou tu cliques et quel chemin ca génère.

Tu comprend mieux ce que je voulais dire ?

+0 -0

Petit up pour dire que je suis en train de bosser sur le systeme de mise en evidence des cases accessibles au joueur en fonction du nombre de point de mouvement qu'il lui reste. J'ai pas encore trouve comment faire tout le tour du joueur, j'ai juste reussi a mettre en place un algo qui pour 1/4 de cercle, il me reste donc a le generaliser pour faire tout le tour du player.
J'en ai aussi profite pour alleger mon code. Maintenant, plus de fonction higlight et resetHighlight, je n'ai plus qu'une seule fonction a laquelle j'envoie un bool qui en fonction de celui ci determine si elle doit highlight le chemin ou le reset.
Du coup le highlight des cases accessibles fonctionne sur le meme principe.
J'ai aussi voulu utiliser l'astuce du layerMask pour eviter le Collider du player lorsque je raycast la souris sur le terrain mais pour l'instant Unity plante a la 2e iteration donc va falloir que je planche sur le probleme.

Qui a t'il par rapport a mon message macadoum ? J'ai pas compris ce qu'il y avait de marrant …
Sinon j'ai toujours pas trouver comment faire le tour de mon perso mais j'ai deja des pistes pour ensuite n'afficher que les cases accessibles (celles bloquees par le décor ne doivent pas etre affichees). J'ai vu vite faire qu'un algo avec des groupes connexes permettrait de determiner cela. En gros, je fais des groupes des cases qui se touchent. Et ensuite je ne retiens que celui dont la case du perso fait partie car les autres sont du coup bloquees par quelque chose.

Qui a t'il par rapport a mon message macadoum ? J'ai pas compris ce qu'il y avait de marrant …

MeliMelo

Idem, c'est vrai que c'est un peu rude comme phrase mais on a vu pire.

Sinon j'ai toujours pas trouver comment faire le tour de mon perso mais j'ai deja des pistes pour ensuite n'afficher que les cases accessibles (celles bloquees par le décor ne doivent pas etre affichees). J'ai vu vite faire qu'un algo avec des groupes connexes permettrait de determiner cela. En gros, je fais des groupes des cases qui se touchent. Et ensuite je ne retiens que celui dont la case du perso fait partie car les autres sont du coup bloquees par quelque chose.

MeliMelo

Si tu veux mon avis tu cherches trop complexe. L'AStar nécessitait un peu de réflexion car c'est assez gourmand. Mais pour ca vas'y au felling, sort un crayon et dessine un coup. Tu verras ca viendra tout seul.

Voici une petite image :

Shéma

L'idée est toute bête, tu prend la position de départ (le joueur), puis tu regardes quelles sont les cases directement accessibles. Ici il y en a 3 (en haut, à gauche et à droite). Tu stocke ces cases dans un tableau ou une liste en stockant aussi inscrivant aussi leur poids (nombre de déplacements restants).

Ici on va supposer qu'on a un déplacement de 4 cases maxi. Donc nos 3 premières cases pèseront 4. Ensuite on recommence la même technique avec les cases que l'on vient de trouver précédemment en descendant au fur et à mesure le poids jusqu'à arriver à un poids de 1. Evidement on vérifiera à chaque fois que les cases trouvées n'ont pas un poids supérieur au notre pour ne pas les recalculer pour rien (sans compter la boucle infini ;) ).

+1 -0

Salut!

Je n'ai aucune connaissance sous unity et je vais peut être dire des bêtises, mais ton projet m'a fait réfléchir avec mes modestes connaissances à comment aborder le problème d'un jeu 2D en 3D! Je te fais pars de ma réflexion et du système que j'envisagerai en espérant ne pas dire trop de bêtises:

Mon idée est de découper l'affiche (3D) du principe du jeu en lui même (2D). Pour cela on découpe l'environnement en 3 couches: -Le plateau de jeu qui est le support des éléments (joueurs, décors etc). -un plaque de détection sous le plateau qui est une réplique du plateau (vide bien sur) translaté vers le bas. -une plaque de détection du même genre au dessus du plateau. Chaque plaque de détection est bien entendu invisible pour le joueur.

1)Chaque élément du plateau possède une sorte de "tige" qui transperce le plateau, et qui envoie un raycast dans le prolongement de la tige soit à la verticale, en direction de la plaque de détection du bas (plaque1). Lorsque le raycast entre en collision avec cette plaque on récupère les coordonnés et en les convertis en système de cases: (2.23,5.96,4) donnerait comme info que la case (2,5) est occupée par l'élément x qui à envoyé le rayon! Ainsi tu peux avoir une vision en 2D des cases occupées ou non, ce qui permet de faire facilement les calculs nécessaires sans avoir à t'occuper des colider des différents objets etc.. Si un élément comme une maison prend 2 cases, il comprendra 2 tiges, une pour chaque case occupée.

2) La vue est gérée par la caméra qui envoie des raycasts vers les personnages et éléments à afficher. Le raycast va entrer ou non en collision avec les colliders des éléments de décors si le personne est caché ou non. Lors de la collision tu récupère la position 2D de l'impact et la compare avec les informations de la plaque 1: si l'impact correspond aux coordonnées du joueurs celui ci est visible. Si non, la plaque 1 t'indique quel objet occupe le plateau à cet endroit et tu peux lui appliquer une texture transparente pour voir le personnage à travers!

3) La souris envoie elle un raycast orienté vers le haut, à la vertical du plateau. Ce raycast entre en collision avec la plaque 2 et te permet de récupérer les coordonnées de la case actuellement survolée. Tu peux comparer ces données à celles issues de la plaque1 pour savoir si tu dois afficher la case en grisés (non disponible) ou en clair (disponibles pour une action)! Tu peux enfin transmettre ces informations à la caméra qui va envoyer un ray cast vers la case indiqué pour voir si il existe des obstacles à la vue et leurs apporter un traitement spécifique (rendre transparent un bâtiment) afin de voir la case ciblée!

Découper le jeu ainsi te permet de te concentrer sur la 2D pour ce qui est des calculs et de ne prendre en compte la dimension 3D uniquement que pour l'affichage! En tout cas si je devais faire un projet comme le tient c'est ainsi que je l'aborderais :)

Qu'en penses-tu?

+0 -0

Hello,
Deja merci beaucoup de t'interesser a mon projet. Je vois bien ce que tu veux dire avec tes plaques dessus et dessous mais dans mon projet j'ai modeliser mon terrain de telle sorte qu'il est constitue de cube de 111 donc au final je n'ai qu'a faire un raycast qui me renvoie le cube du terrain intercepte et ensuite d'attribuer a mon player les coordonnees de ce cube.

Pour ce qui est de le vue (determiner si le personnage est cache ou pas par un element du decor), avec le meme principe que tu as imagine, je vais envoyer des raycast de la camera vers le joueur (ou l'inverse peu importe) et controller si ce raycast est intercepte par un element du decor (tous les elements du decor ont un tag special et sont sur un autre layout). Ensuite, je vais juste changer le material de cet element du decor en transparent.

Pareil pour la souris, il y a un fonction toute faite sous unity qui cree un ray depuis la souris vers la camera ( ou le contraire je sais plus) et ca te permet de recuperer les coordonnees de ce que tu pointes tres facilement sans avoir a implementer un systeme.

Pour les elements de plus de 1 case, il suffit simplement d'ajuster la taille du collider pour qu'il intercepte les raycast passant par l'objet.

Ton idee est vraiment pas mal mais au final tout est grandement simplifie par Unity et du coup pas besoin de s'embeter a creer des plaques de detection au dessus et en dessous. Au passage je ne gere tout qu'en 2D car pour le moment tout est a la meme altitude mais je compte faire des cases plus hautes que d'autres afin de donner un peu de relief au jeu (ca viendra bien apres par contre)

Bon pour le moment je suis en train de revoir mon systeme de highlight de cases car au final tout etait dans le fichier du tour manager et ca devient vite le bordel. Du coup une class a ete creee a part et je suis en train de retravailler l'algo parce que pour le moment c'est bien moche. Merci Loptr au passage pour tes pistes.
La periode de fete approchant j'ai un peu moins de temps a consacrer a mon projet mais ne vous inquietez pas je n'abandonne surtout pas et je compte m'y remettre serieusement apres cette courte periode.
Sur ce, bonne fetes a tous ceux qui liront ce message ;)

EDIT : au fait est ce que le C# gere les boucles sur un tableau dynamique ?
enfin c'est pas vraiment un tableau mais en gros ce que j'aurai besoin de faire c'est parcourir chaque element d'une list (donc boucle for) mais au fur et a mesure je rajoute des elements a cette meme liste. Est il possible de faire une boucle for en mettant comme condition d'arret la fin de la liste alors qu'on rajoute des elements a chaque iteration ?

EDIT : au fait est ce que le C# gere les boucles sur un tableau dynamique ?
enfin c'est pas vraiment un tableau mais en gros ce que j'aurai besoin de faire c'est parcourir chaque element d'une list (donc boucle for) mais au fur et a mesure je rajoute des elements a cette meme liste. Est il possible de faire une boucle for en mettant comme condition d'arret la fin de la liste alors qu'on rajoute des elements a chaque iteration ?

MeliMelo

Du moment que tu utilise bien la méthode Count() de ta liste pour boucler dessus oui ca ne devrais pas poser de soucis. Par contre avec un foreach je ne saurais te dire, je suis plutôt le programmeur C++ qui code en C# à la manierre du C++. Tu vois le truc, donc foreach je connais pas trop… ^^

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte