Night.png);">
Apprendre


Vous êtes
nouveau sur
Oniromancie?

Visite guidée
du site


Découvrir
RPG Maker

RM 95
RM 2000/2003
RM XP
RM VX/VX Ace
RM MV/MZ

Apprendre
RPG Maker

Tutoriels
Guides
Making-of

Dans le
Forum

Section Entraide

Sorties: Star Trek: Glorious Wolf - (...) / Sorties: Dread Mac Farlane - episode 3 / News: Plein d'images cools créées par (...) / Sorties: Star Trek: Glorious Wolf - (...) / Jeux: Final Fantasy 2.0 / Chat

Bienvenue
visiteur !




publicité RPG Maker!

Statistiques

Liste des
membres


Contact

Mentions légales

229 connectés actuellement

29186558 visiteurs
depuis l'ouverture

1609 visiteurs
aujourd'hui



Barre de séparation

Partenaires

Indiexpo

Akademiya RPG Maker

Blog Alioune Fall

Fairy Tail Constellations

Tashiroworld

Zarok

Lunae - le bazar d'Emz0

Leo-Games

Le Temple de Valor

Tous nos partenaires

Devenir
partenaire



forums

Index du forum > Généralités > Discussion Générale de making

Aller à la page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114

Reprise du message précédent:

Falco - posté le 13/03/2022 à 12:37:16 (19565 messages postés) -

❤ 0

Indie game Developer

Rots : En fait j'ai pas franchement réinventé la roue pour cet algorithme, je me base sur celui utilisé dans les Fire Emblem :

https://serenesforest.net/general/growth-rates/

A la différence que mon system de Potential Value permet d'assurer des unités fortes, et à contrario des unités mauvaises, à la manière d'un Pokémon.

Mais sinon oui tout est basé sur la chance et c'est ce que les joueurs aiment dans les Fire Emblem, tu peux recruter 3-4 unités d'une même classe, à toi de les entrainer et voir celle qui à des statistiques plus intéressants, même si il y a des unités naturellement plus disposées à devenir meilleures.

Ceci dit je ne suis pas contre réfléchir à un algorithme qui serait plus intéressant en terme de Game Design, si vous avez des idées !

Merci beaucoup pour le calcul que tu as proposé, ca a l'air tout bon, je vais mettre ça en place et voir ce que ça donne !
L'avantage de ton calcul, c'est qu'il permet d'avoir les mêmes statistiques à chaque fois.
Admettons que je voulais employer le système du "augmenter le niveau loop par loop" au démarrage du niveau, une même unité aurait pu avoir des statistiques totalement différentes à chaque reset.
Je viens de voir que c'était le cas dans les Fire Emblem à priori, mais j'ai jamais remarqué de vrais grosses différences, or après avoir fait des tests de mon coté une unité pouvoir avoir plus de 5 points de valeurs de différence, ce qui est énorme, donc pas sur que ça soit une bonne idée.

Edit : A contrario le désavantage c'est que deux mêmes unités avec la même Potential Value auront les mêmes statistiques... que je pourrais résoudre en augmentant la valeur max de la Potential Value, qui pourrait être comprise entre 1 et 50 par exemple, ce que éviterait d'avoir des doublons.

Edit 2 : Bon ton calcul fonctionne super ROTS, j'ai fait quelques test et ça donne un plutôt bon équilibrage je trouve :)
La démesure entre un Potential Value faible et un Potential Value élevé est pas si énorme, même si elle suffit à faire la différence, donc c'est parfait.
Merci encore !
Je vais probablement avoir une autre question, un peu plus technique et lié à l'algorithme de Dijkstra que j'utilise... mais je continue de chercher un peu par moi même avant !

Inexistence Rebirth - Inexistence - Portfolio


Suite du sujet:

Falco - posté le 13/03/2022 à 15:18:58 (19565 messages postés) -

❤ 0

Indie game Developer

Bon, je galère un peu à trouver la solution, je vais tout de même vous la décrire ici en général écrire me permet de résoudre le problème donc avec un peu de chance :p
Pour les déplacements de mon jeu, j'utilise un algorithme qui se rapproche de A*, je crois si je dis pas de bétises que c'est le principe de l'algorithme de Dikstra, qui est la base du A*.
Voici un screenshot pour vous illustrer tout ça :

image

En gros comment ça fonctionne, chaque tuile à une valeur.

0 si elle est libre
50 si un personnage est dessus
99 si c'est un obstacle que les personnages ne peuvent pas franchir


Lorsqu'on clic sur un personnage (à savoir le héros blondinet sur ce screen), j'ai un tableau de valeur qui est réinitialisé avec toutes les valeurs à 99, sauf celles ou se situe la héros, qui est à 0.

Ensuite, je lance une boucle qui va se répéter le nombre de déplacements maximums du héros (5 dans cet exemple, représenté par les cases bleues (les cases rouges sont la porté de son attaque, donc 2)) et qui va checker toutes les cases du tableau dans l'ordre.
Si la boucle tombe sur une cases qui est égale à 0+loopindex, elle va regarder de chaque coté la valeur de la case (donc pas occupé par un ennemi ou une collision), si c'est le cas, elle attribue la valeur minimum entre la case actuelle+1 ou la valeur de la case checké.
Ensuite je crée mes petites cases, bleues si la valeur de la case est inférieur ou égal au nombre de déplacement permis par le héros, et rouge si c'est plus (et si évidemment la valeur est inférieur à 99.)

Jusqu'à la tout fonctionne plutôt bien, je ne sais pas si c'est la méthode optimale, probablement pas étant donné que je suis une bille en programmation, mais c'est une méthode qui fonctionne et qui semble correspondre aux articles que j'ai lu sur cet algorithme, le chemin est bon et ca calcule toujours le plus court.

Ensuite viens mon problème.
Dans les tactical, les personnages peuvent utiliser des attaques avec une porté éloignée, par exemple un arc, ou un tome de magie qui attaque très loin, et qui ignorent les valeurs de collisions.
Dans mon exemple là, le héros est équipé d'un arc à, et a donc une porté de deux cases.
Il y a donc un problème sur le screen que je vous ai montré, le vrai rendu devrait être le suivant :

image

Et je n'ai malheureusement aucune idée de comment gérer ça de façon simple et optimale.
Ca serait facile de créer la porté d'une attaque si le héros était immobile, suffirait de faire le même calcul précédent mais en ignorant toutes les collisions et les ennemis, mais le coupler à un système de déplacement me rend la chose compliqué.
Si vous avez une idée simple qui pourrait marcher ça m'enlèverait une énorme épine du pied, c'est le seul système que je n'ai pas encore réussis à créer pour que mon moteur soit totalement fonctionnel !
Je sais que Tass avait l'air d'être un export dans le domaine donc je me dis qu'avec un peu de chance il aura une idée efficace :p

Merci d'avance :)

Inexistence Rebirth - Inexistence - Portfolio


Mack - posté le 13/03/2022 à 15:50:43 (2286 messages postés)

❤ 0

Bah, là le "problème" c'est que tu essaie de cibler des cases inciblables non ?
Genre, tu dis que les trucs à 99, c'est cases inatteignable, donc tes montagnes tu peux pas les cibler non ?
Donc à la limite c'est pas très grave.

Et je suppose que pour calculer tes cases ciblables tu utilises le A* de la même façon que pour vérif les déplacements ? ( Mais avec +2 dans la partie déplacement max de ce que j'ai compris dans ton texte )
Si c'est le cas, tu fais juste une vérif différentes si tu veux les cases d'attaques ou les cases de déplacements, genre, si tu check les cases d'attaques tes montagnes sont pas à 99.

Mais ça me semble pas la meilleur solution.
Perso, j'aurais appliquer le pattern d'attaque à toute les cases où le joueur peut aller.
( Soit par récursivité, soit en stockant toute les cases possibles dans un tableau )

( Je prend note de tout les commentaires, même si je n'y répond pas )


Falco - posté le 13/03/2022 à 16:04:55 (19565 messages postés) -

❤ 0

Indie game Developer

Citation:

Bah, là le "problème" c'est que tu essaie de cibler des cases inciblables non ?
Genre, tu dis que les trucs à 99, c'est cases inatteignable, donc tes montagnes tu peux pas les cibler non ?
Donc à la limite c'est pas très grave.



Dans les faits oui, mais par exemple c'est des cases que certaines unités peuvent franchir, genre celles qui volent, ou plus concrétement, dans ce genre de cas ou deux unités sont séparés par un mur, mais avec la possibilité d'attaquer si t'es archer :

image

En soit, le problème n'en est pas un dans le cas du tour du joueur, puisque je peux faire en sorte de calculer le fait de rendre l'attaque possible sur un personnage si ils ont une distance proche.
C'est plus problématique quand c'est le tour de l'ennemi puisque son IA est censé pouvoir savoir quelles sont les personnages qu'il peut attaquer, et donc ceux qui sont dans son ranges.

Citation:

Et je suppose que pour calculer tes cases ciblables tu utilises le A* de la même façon que pour vérif les déplacements ? ( Mais avec +2 dans la partie déplacement max de ce que j'ai compris dans ton texte )
Si c'est le cas, tu fais juste une vérif différentes si tu veux les cases d'attaques ou les cases de déplacements, genre, si tu check les cases d'attaques tes montagnes sont pas à 99.



Oui en fait j'utilise le même algo pour les deux ! C'est juste la valeur de la case qui va influer sur quelle case créée.

Citation:

Mais ça me semble pas la meilleur solution.
Perso, j'aurais appliquer le pattern d'attaque à toute les cases où le joueur peut aller.
( Soit par récursivité, soit en stockant toute les cases possibles dans un tableau )



Je suis pas sur de comprendre, si tu appliques le patern d'attaque, tu ignores toutes les collisions, donc ça marcherait visuellement, mais ça veut dire que le joueur pourrait se déplacer sur une case auquel il n'a pas le droit d'aller, il traverserait les murs, les montagnes, etc...
Ou alors j'ai pas compris :p

Edit : Ah je pense avoir compris.
Tu veux dire faire une loop pour chaque cases de déplacement et lui appliquer le patern d'attaque ?
J'y ai pensé, mais j'ai peur que ça soit trop gourmand.

Inexistence Rebirth - Inexistence - Portfolio


Mack - posté le 13/03/2022 à 16:19:33 (2286 messages postés)

❤ 0

Falco a dit:

Citation:

Bah, là le "problème" c'est que tu essaie de cibler des cases inciblables non ?
Genre, tu dis que les trucs à 99, c'est cases inatteignable, donc tes montagnes tu peux pas les cibler non ?
Donc à la limite c'est pas très grave.



Dans les faits oui, mais par exemple c'est des cases que certaines unités peuvent franchir, genre celles qui volent.
Ou plus concrètement, il y à ce genre de cas :

image

Ou les personnages peuvent tirer une flèche à travers les murs.

Citation:

Et je suppose que pour calculer tes cases ciblables tu utilises le A* de la même façon que pour vérif les déplacements ? ( Mais avec +2 dans la partie déplacement max de ce que j'ai compris dans ton texte )
Si c'est le cas, tu fais juste une vérif différentes si tu veux les cases d'attaques ou les cases de déplacements, genre, si tu check les cases d'attaques tes montagnes sont pas à 99.



Oui en fait j'utilise le même algo pour les deux ! C'est juste la valeur de la case qui va influer sur quelle case créée.

Citation:

Mais ça me semble pas la meilleur solution.
Perso, j'aurais appliquer le pattern d'attaque à toute les cases où le joueur peut aller.
( Soit par récursivité, soit en stockant toute les cases possibles dans un tableau )



Je suis pas sur de comprendre, si tu appliques le patern d'attaque, tu ignores toutes les collisions, donc ça marcherait visuellement, mais ça veut dire que le joueur pourrait se déplacer sur une case auquel il n'a pas le droit d'aller, il traverserait les murs, les montagnes, etc...
Ou alors j'ai pas compris :p



Je trouve que c'est une très mauvaise idée de juste "étendre" ton algo depuis la position initiale du joueur :/
Ça marchera tant que tu utilises des portée d'attaque simple, mais dés que tu vas vouloir faire des trucs un peu plus complexes ( attaque dispo seulement en diagonale par exemple ), ça va te foutre un de ces bordels xD


Justement, comme tu utilises exactement le même algo, quand il rencontre une case impraticable, jamais il pourra te la mettre en case rouge, vu que de toute façon l'algo cherchera pas plus loin.
Donc faudrait que tu créer une petite particularité quand ta distance passe en rouge ( donc dans le cas du screen, D>5 ), pour pas qu'il te considère tout truc bloquant le déplacement comme un truc bloquant l'attaque.



Quand je parle de pattern d'attaque, c'est la forme de ce qui est justement ciblable.
Pour une attaque au CaC, ça donne ça :
image
Pour de l'arc :
image


Et tu calcules le pattern sur chaque cases disponibles.


Oui, clairement ça sera un peu plus gourmand, mais je pense pas que ça soit vraiment gênant, surtout si tu comptes faire des paternes un peu plus chiants.

( Je prend note de tout les commentaires, même si je n'y répond pas )


Falco - posté le 13/03/2022 à 16:29:48 (19565 messages postés) -

❤ 0

Indie game Developer

Ok c'est une bonne idée de calculer pour chaque cases, ça peut marcher effectivement... merci beaucoup !
Je verrais un truc du genre, calculer un nouveau chemin pour chaque cases bleues, de la porté de la distance, en ignorant les collisions, et afficher une case rouge si la case est pas déjà occupée par une case bleue.
La comme ça ça pourrait marcher, j'ai juste peur que étant donné que l'algo va calculer un chemin pour chaque cases, ça risque de lagger un max pour les personnages qui peuvent se déplacer de 10 case par exemple... mais on verra.

Inexistence Rebirth - Inexistence - Portfolio


Falco - posté le 13/03/2022 à 17:48:33 (19565 messages postés) -

❤ 0

Indie game Developer

Bon, ca fonctionne !
Le seul soucis c'est qu'il y a un micro lag de quelques secondes, voir une seconde quand le personnage a beaucoup de mouvements.
C'est pas très grave honnêtement, ce n'est pas ultra fréquent, mais disons que si vous avez une meilleure idée je prends, sinon ça fera le taff.
Merci encore !

Inexistence Rebirth - Inexistence - Portfolio


Tassle - posté le 16/03/2022 à 09:48:34 (5233 messages postés)

❤ 0

Disciple de Pythagolf

Citation:

Pour les déplacements de mon jeu, j'utilise un algorithme qui se rapproche de A*, je crois si je dis pas de bétises que c'est le principe de l'algorithme de Dikstra, qui est la base du A*.


Perso j’appellerais pas ce que tu fais l'algo de Dijkstra, parce que tu ne suis pas l'ordre de "relaxation" des arrêtes du graphe typique de l'algo de Dijkstra ("relaxation" est la terminologie anglaise et peut-être que ça s'appelle "détente" en français, je suis plus sûr). C'est encore moins du A* parce qu'il n'y a pas d'heuristique de distance utilisée (et que de toute façon A* ne s'applique qu'au cas où on veut la distance entre deux points donnés, pas quand on veut la distance d'un point à tous les autres).
Edit: C'est Bellman–Ford en fait l'algo que t'utilises.

Citation:

Jusqu'à la tout fonctionne plutôt bien, je ne sais pas si c'est la méthode optimale, probablement pas étant donné que je suis une bille en programmation, mais c'est une méthode qui fonctionne et qui semble correspondre aux articles que j'ai lu sur cet algorithme, le chemin est bon et ca calcule toujours le plus court.


Dans le cas d'un jeu sur une grille et sans déplacement diagonaux on peut effectivement faire mieux sans trop de difficulté (en gros ici tu regarde chaque case de la map 5 fois, même celles qui sont loin et qui ne seront donc pas accessibles, alors qu'avec la bonne stratégie tu peux te contenter de regarder chaque case une seule fois). Je peux élaborer si tu veux, mais si c'est assez rapide en l'état tu peux laisser comme ça.

Citation:

Bon, ca fonctionne !
Le seul soucis c'est qu'il y a un micro lag de quelques secondes, voir une seconde quand le personnage a beaucoup de mouvements.
C'est pas très grave honnêtement, ce n'est pas ultra fréquent, mais disons que si vous avez une meilleure idée je prends, sinon ça fera le taff.


Si tu veux garder la base que t'as, tu peux essayer l'amélioration suivante qui évitera de refaire toute la procédure pour chaque case bleue:
Une fois que t'as déterminé toutes les cases bleues, réinitialises ton tableau (ou un nouveau tableau si tu veux pas perdre celui-ci) pour qu'il ait toutes les valeurs à 99, sauf les cases bleues que tu mets toutes à 0. Ensuite, tu lances ta procédure habituelle pour calculer les cases à distance 2 (en ignorant les collisions) en partant de ce tableau. En gros, ça te permet de dire à ton algo que le bonhomme peut se déplacer vers n'importe quelle case bleue avant d'attaquer, ce qui te permet donc de calculer toutes les cases qui sont à une distance d'au plus 2 d'une case bleue.

Ça marche pour les patterns d'attaques qui sont du type "toutes les cases à distance au plus k". Si t'as des patterns plus compliqués tu risque de devoir réfléchir à d'autres stratégies.

Autre stratégie plus générale : Ici pour chaque case bleue de coordonnées (x,y) tu sais que les cases suivantes peuvent être attaquées :
(x-2,y)

(x-1,y-1)
(x-1,y)
(x-1,y+1)

(x,y-2)
(x,y-1)
(x,y+1)
(x,y+2)

(x+1,y-1)
(x+1,y)
(x+1,y+1)

(x+2,y)

Il suffit donc pour chaque case bleue (ou mieux: chaque case bleue du bord) de regarder ces 12 cases et de les marquer en rouge si elles ne sont pas déjà marquées en bleu. Cette stratégie s'adapte facilement à d'autres patterns d'attaque et est rapide à exécuter tant que le pattern d'attaque ne contient pas trop de cases.

Une autre amélioration possible serait de calculer dès le début du combat les distances entre toutes les paires de cases (et pas seulement la distance d'une case particulière à toutes les autres). Ça prendra un peu de temps au début (mais pas beaucoup plus que le lag que tu as avec ta stratégie actuelle) mais ensuite t'as plus jamais à recalculer des distances après chaque déplacement vu que t'as tout précalculé au départ.

Tu peux même faire ça pendant la phase de développement pour chaque map et ensuite le stocker "en dur" dans les données de la map. Comme ça les distances n'auront jamais à être calculées en jeu, tout a été calculé avant même de compiler. Ça devrait pas représenter grand chose en terme de poids sur le DD par rapport au reste du jeu.

~~


Mack - posté le 16/03/2022 à 10:03:18 (2286 messages postés)

❤ 0

Tassle a dit:



Autre stratégie plus générale : Ici pour chaque case bleue de coordonnées (x,y) tu sais que les cases suivantes peuvent être attaquées :
(x-2,y)

(x-1,y-1)
(x-1,y)
(x-1,y+1)

(x,y-2)
(x,y-1)
(x,y+1)
(x,y+2)

(x+1,y-1)
(x+1,y)
(x+1,y+1)

(x+2,y)

Il suffit donc pour chaque case bleue (ou mieux: chaque case bleue du bord) de regarder ces 12 cases et de les marquer en rouge si elles ne sont pas déjà marquées en bleu. Cette stratégie s'adapte facilement à d'autres patterns d'attaque et est rapide à exécuter tant que le pattern d'attaque ne contient pas trop de cases.


C'est aussi ce que j'aurais proposé, mais là ça pose un problème de ligne de vue.
Genre, si en X-1 t'as une case impraticable, le joueur devrait pas pouvoir attaquer en X-2. Or, avec cette méthode, c'est plus compliqué à gérer.

Après, question un peu con Falco, mais avec ton algo, tu peux pas stocker juste les dernières cases de chaque branches ?
A vue d'oeil un peu grossier, ça serait un truc du genre :
Toutes les cases à 5 + toutes à 4 qui n'ont qu'un seul 3 à côté + toutes les cases à 3 qui n'ont qu'un seul 2 à côté, ...
Comme ça tu récupères que les bordures des déplacements possibles, et fais ton algo d'attaque que dessus ces cases là, tu gagneras déjà pas mal de temps.

( Je prend note de tout les commentaires, même si je n'y répond pas )


Falco - posté le 16/03/2022 à 10:04:16 (19565 messages postés) -

❤ 0

Indie game Developer

Citation:

Dans le cas d'un jeu sur une grille et sans déplacement diagonaux on peut effectivement faire mieux sans trop de difficulté (en gros ici tu regarde chaque case de la map 5 fois, même celles qui sont loin et qui ne seront donc pas accessibles, alors qu'avec la bonne stratégie tu peux te contenter de regarder chaque case une seule fois). Je peux élaborer si tu veux, mais si c'est assez rapide en l'état tu peux laisser comme ça.



Ah je suis curieux oui, pourquoi pas !
Après faudra que tu employes des mots simples pour un simplet comme moi :F
Mais je vois peut-être l'idée, déjà partir du héros plutôt que d'une boucle qui test chaque case permettrait de ne pas avoir à calculer des cases inutilisables.

Merci beaucoup pour les solutions que tu proposes.
Pour l'instant je pense que je vais garder ce que j'ai, ça a l'air de marcher sans bugs, mais je suis quasiment sur que je trouverais une faille dans ce que j'ai fais prochainement, et à ce moment là j'aimerais repartir de zéro pour avoir quelque chose de vraiment fonctionnel, et surtout moins complexe parce que là j'ai l'impression d'avoir un bourbier immense pour quelque chose que j'aurais pu faire en quelques lignes XD

Citation:

Après, question un peu con Falco, mais avec ton algo, tu peux pas stocker juste les dernières cases de chaque branches ?
A vue d'oeil un peu grossier, ça serait un truc du genre :
Toutes les cases à 5 + toutes à 4 qui n'ont qu'un seul 3 à côté + toutes les cases à 3 qui n'ont qu'un seul 2 à côté, ...
Comme ça tu récupères que les bordures des déplacements possibles, et fais ton algo d'attaque que dessus ces cases là, tu gagneras déjà pas mal de temps.



J'y ai pensé, ça serait une bonne solution mais ça rajouterais beaucoup de calcul pour calculer chaque case qui est en bordure.
Mais en vrai ça pourrait marcher...

En soit je disais que ça laggais mais c'est quand j'avais essayé avec un perso a 10 mouvements et une porté d'attaque de 5, ce qui arriverait quasiment jamais.
Un perso a 6-7 mouvements et à deux de porté ne fais pas lagger.

Merci pour votre aide en tout cas !

Inexistence Rebirth - Inexistence - Portfolio


Mack - posté le 16/03/2022 à 10:19:10 (2286 messages postés)

❤ 0

Mack a dit:


Après, question un peu con Falco, mais avec ton algo, tu peux pas stocker juste les dernières cases de chaque branches ?
A vue d'oeil un peu grossier, ça serait un truc du genre :
Toutes les cases à 5 + toutes à 4 qui n'ont qu'un seul 3 à côté + toutes les cases à 3 qui n'ont qu'un seul 2 à côté, ...
Comme ça tu récupères que les bordures des déplacements possibles, et fais ton algo d'attaque que dessus ces cases là, tu gagneras déjà pas mal de temps.



En vrai, je pense que cet algo est claqué x).

Par contre, quand tu parcours tes chemins pour savoir si ton héros peut bouger ou pas, il te suffit juste de rajouter la case courante dans un tableau à condition qu'au moins une des 4 cases autours ne soit pas praticable, et là t'obtiens sans soucis tout les bouts de chemins.

Après, effectivement, si pour l'instant ça te va, et que tu comptes refaire l'algo plus proprement plus tard, c'est pas forcement une priorité, mais ça vaut le coup de garder tout ce qu'on dit sous la main xD

( Je prend note de tout les commentaires, même si je n'y répond pas )


Falco - posté le 16/03/2022 à 10:40:04 (19565 messages postés) -

❤ 0

Indie game Developer

Citation:

Par contre, quand tu parcours tes chemins pour savoir si ton héros peut bouger ou pas, il te suffit juste de rajouter la case courante dans un tableau à condition qu'au moins une des 4 cases autours ne soit pas praticable, et là t'obtiens sans soucis tout les bouts de chemins.



J'aime bien cette idée :)
Je la garde quand je referais tout mon système.

Merci !

Inexistence Rebirth - Inexistence - Portfolio


Tassle - posté le 16/03/2022 à 10:40:26 (5233 messages postés)

❤ 0

Disciple de Pythagolf

Citation:

C'est aussi ce que j'aurais proposé, mais là ça pose un problème de ligne de vue.
Genre, si en X-1 t'as une case impraticable, le joueur devrait pas pouvoir attaquer en X-2. Or, avec cette méthode, c'est plus compliqué à gérer.


Ah je pensais que les attaques à distance ignoraient le terrain, mais j'ai ptêt' mal compris.

Citation:

Ah je suis curieux oui, pourquoi pas !



Tu peux faire comme ça:

- T'as ton tableau 2D "Dist" qui représente les distances de chaque case depuis le personnage. Au début il est initialisé partout à 99, sauf la case du perso qui est à 0.
- T'as un deuxième tableau (à une seule dimension) "Q" qui représente une file d'attente des cases à explorer (ou "queue" en anglais). La longueur de ce tableau est égale à deux fois le nombre de cases sur la map (et au départ osef de ce qu'il y a dedans).

Ensuite tu procède comme ça:

Portion de code : Tout sélectionner

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
On pose la variable startQ := 0 et endQ := 2.
On met Q[0] := xp et Q[1] := yp, où xp, yp sont les coordonnées de ton perso.
Tant que startQ < endQ:
    x := Q[startQ]
    startQ := startQ+1
    y := Q[startQ]
    startQ := startQ+1
    Pour chaque case (xv, yv) voisine de (x,y):
        Si (xv, yv) est passable et Dist[xv, yv] == 99:
            Dist[xv, yv] := Dist[x, y] + 1
            Q[endQ] := xv
            endQ := endQ + 1
            Q[endQ] := yv
            endQ := endQ + 1
        Fin du Si...
    Fin du Pour chaque...
Fin du Tant que...
 



À la fin de la procédure, tu auras la distance de toutes les cases de ta map depuis le perso stockées dans "Dist".

Si tu veux laisser à 99 les distances supérieures à 7 par exemple, tu peux exécuter la boucle "Pour chaque case (xv, yv) voisine de (x,y)" seulement si Dist[x,y] < 7 (et dans le cas Dist[x,y] >= 7 tu skip cette boucle).

Dans ce cas tu peux aussi économiser un peu de place en utilisant un tableau Q de longueur 4*7*(7+1)+2 (si ce nombre est plus petit que deux fois le nombre total de cases sur la map, sinon ça sert à rien). Mais bon le gain ne sera jamais très significatif par rapport aux autres trucs stockés pour la map, donc tu peux ignorer cette petite optimisation si tu veux.

Edit:

Citation:

Je sais que Tass avait l'air d'être un export dans le domaine donc je me dis qu'avec un peu de chance il aura une idée efficace


C'est pas exactement mon domaine d'expertise (mon truc c'est la géométrie algorithmique) mais ça reste de l'algorithmie donc je peux me faire passer comme expert auprès des non-experts :p (À vrai dire même dans "mon" domaine je reste un débutant par rapport à ceux qui ont vraiment de la bouteille !)

~~


Mack - posté le 16/03/2022 à 10:44:43 (2286 messages postés)

❤ 0

Tassle a dit:

Citation:

C'est aussi ce que j'aurais proposé, mais là ça pose un problème de ligne de vue.
Genre, si en X-1 t'as une case impraticable, le joueur devrait pas pouvoir attaquer en X-2. Or, avec cette méthode, c'est plus compliqué à gérer.


Ah je pensais que les attaques à distance ignoraient le terrain, mais j'ai ptêt' mal compris.


C'est pas préciser, c'est pour ça que j'en parle.
Mais clairement, si on s'en fou c'est de très loin la solution que je préfère.

( Je prend note de tout les commentaires, même si je n'y répond pas )


Falco - posté le 16/03/2022 à 11:09:58 (19565 messages postés) -

❤ 0

Indie game Developer

Citation:

C'est pas préciser, c'est pour ça que j'en parle.
Mais clairement, si on s'en fou c'est de très loin la solution que je préfère.



Si j'ai bien compris le problème de cet algo c'est que si un perso peut attaquer a 5 cases, voir plus, ça peut être chiant à mettre en place.

Et effectivement les cases rouges ignorent toujours le terrain !

Tass : J'ai relu deux trois fois, je suis un peu perdu mais je vais quand même le garder de coté peut-être que ça sera plus clair quand je travaillerais dessus en même temps, j'ai toujours été nul pour comprendre à la lecture, en général je comprends plus facilement quand j'ai les mains dedans.
Merci !

Inexistence Rebirth - Inexistence - Portfolio


Tassle - posté le 16/03/2022 à 16:45:42 (5233 messages postés)

❤ 0

Disciple de Pythagolf

Je crois qu'une bonne solution pour l'IA des ennemis qui s'adapte bien à d'autres patterns d'attaque qu'une zone à distance <= k est de résoudre le truc à l'envers.

Sur l'image suivante, le méchant est en rouge et les héros sont en rose. L'ennemi tire à une distance d'au plus deux. J'ai marqué en hachuré les cases depuis lesquels le méchant pourrait attaquer un héros sans bouger. Certaines (en bleu) ne sont pas passables.
image

On commence par initialiser ces cases à 0 si elles sont passables. Tout ce que je n'ai pas noté est à 99.
image

Ensuite tu fais ta boucle d'update à partir de là (qui n'est en fait pas Dijkstra ni A* mais Bellman-Ford), ce qui te donne le tableau suivant:
image

Comme le méchant est sur une case marquée 3 (je l'ai pas écrit sur l'image mais c'est le cas), il peut attaquer un des héros en faisant trois pas comme suit:
image

Ça devrait laguer beaucoup moins parce qu'au lieu d'appliquer le pattern d'attaque sur chaque case accessible en un certain nombre de pas (celles que tu avais marqué en bleu), tu as seulement besoin de l'appliquer sur chaque héros que tu veux attaquer. C'est aussi facile à appliquer à d'autres patterns d'attaque (par exemple loin en ligne droite, ou seulement les cases à distance exactement 3, ou seulement vers la droite, etc.) ou en prenant en compte certains obstacles (on peut tirer au dessus de l'eau mais pas à travers un mur, ce genre de choses).

Le problème c'est que ça ne permet pas de trouver toutes les cases attaquables mais seulement celles ou un adversaire se trouve. Donc si tu veux ta visualisation rouge/bleu comme sur ton image c'est pas bon (mais ça peut toujours servir pour l'IA des ennemis, qui j'imagine ne vont pas vouloir attaquer une case où il n'y a pas de héros).

~~


Falco - posté le 16/03/2022 à 17:26:09 (19565 messages postés) -

❤ 0

Indie game Developer

Ah oui effectivement c'est pas bête du tout et ça serait facile à mettre en place avec l'architecture que j'ai déjà.
Je vais essayé de l'appliquer, merci beaucoup !

Cet histoire d'algorithme c'est quand même assez complexe pour un néophyte comme moi, enfin ca allait pour calculer des distances et faire déplacer un personnage vers le chemin le plus court, mais quand il faut commencer à créer une IA qui doit réfléchir stratégiquement avec ça, c'est moins simple...

Inexistence Rebirth - Inexistence - Portfolio


Falco - posté le 30/03/2022 à 11:40:45 (19565 messages postés) -

❤ 0

Indie game Developer

Il y a eu des news sur RPG Maker Unite, ils vont faire des dev log une à deux fois par mois.
Voilà ce qu'on a appris sur le premier :

- Il faudra posséder Unity pour utiliser RPG Maker Unite, mais à priori on aura pas besoin de taper une seule ligne de code, donc je suis pas sur de comment ça fonctionnera pour être honnête...

- Refonte totale de la UI des RPG Maker pour quelque chose de plus accessible, et plus "Unity", mais toutefois ils disent que les habitués de la série ne seront pas perdus
image
image

- La résolution HD sera gérée automatiquement

- Ils disent que la rétrocompatibilité ne sera pas en place, aussi bien pour les projets que pour réutiliser des ressources, je pense qu'ils veulent dire qu'on pourra pas juste importer tels quels les ressources, mais il sera bien évidemment possible de retravailler les tilesets/charsets/etc... pour les rendre compatibles.

- On pourra utiliser RPG Maker Unite sans payer Unity

- Le logiciel possèdera ses propres RTP

- Ils ont teasé un système de Blue print, sans en dire plus, à voir ce que ça donnera mais c'est une très bonne idée, ça voudrait dire uq'ils ont poussé la programmation en event bien plus loin et qu'il sera techniquement possible de faire de grandes choses.

La page en question, avec pas mal de screenshots :

https://steamcommunity.com/app/1650950

Inexistence Rebirth - Inexistence - Portfolio


Sylvanor - posté le 30/03/2022 à 14:06:12 (24561 messages postés) - webmaster -

❤ 0

Le gars chiant qui rigole jamais (il paraît)

Citation:

On pourra utiliser RPG Maker Unite sans payer Unity



Rappelons tout de même qu'Unity est gratuit pour les particuliers.

Les croissants croâssent en croix, s'ancrent ou à cent croîssent sans crocs à sang. Crois! Sens! ౡ


harusame17 - posté le 30/03/2022 à 17:07:32 (744 messages postés)

❤ 0

Oui, une licence pro est nécessaire uniquement si on a un revenu de plus de 100 000$ par an. On a le temps de voir venir et même après les prix ne sont pas exorbitants.

Très prometteur cette version, si on a l'accessibilité de RPG maker et les performances d'unity (ainsi que l'export multi plateforme dont les consoles), c'est un pont incroyable !

« Close the World, Open the nExt »


Usui_Kenta_VL - posté le 30/03/2022 à 21:14:25 (51 messages postés)

❤ 0

Game Creator & Freelance Translator

Vu de loin ca ressemble pas mal a un asset/plugin pour Unity avec un ensemble de scripts editeur (l'interface de RM qui va se superposer par dessus celle de Unity).
A voir surtout comment les scenes(maps) et la database vont etre gerees et si il sera possible de switcher entre les fonctions de RM et Unity sans trop de casse, il y aurait moyen d'avoir le meilleur des deux mondes.

Atelier Melon-Kissa, suivez moi sur Twitter!


Nemau - posté le 30/03/2022 à 21:35:47 (52129 messages postés) - honor -

❤ 0

The Inconstant Gardener

Citation:

- Le logiciel possèdera ses propres RTP

Vus les screens, ils ont l'air toujours aussi bidon. :c

Citation:

Ils ont teasé un système de Blue print

De quoi s'agit-il ?

Citation:

Oui, une licence pro est nécessaire uniquement si on a un revenu de plus de 100 000$ par an.

Arf, j'ai peur d'être un poil au-dessus cette année. =>[]

Quel RPG Maker choisir ?Ocarina of Time PCPolaris 03 • Le matérialisme c'est quand tu as du matériel.


Roi of the Suisse - posté le 21/04/2022 à 20:44:37 (29765 messages postés) - honor -

❤ 1

Alerte neige !

Martin Donald, une super chaîne Youtube pour la création de jeux en 3D :



L'essentialisme c'est quand ta voiture a un moteur essence. | Es-tu une star ? | Kujira no Hara | Polaris 03 | Planète Glutko


Layri2432 - posté le 21/04/2022 à 21:51:04 (20 messages postés)

❤ 0

Vive l'engin diabolique n°9

Citation:

Martin Donald, une super chaîne Youtube pour la création de jeux en 3D


Je ne connaissais pas du tout la chaîne, mais après y avoir jeté un coup d'oeil ça a effectivement l'air vraiment pas mal, merci !


cortez - posté le 22/04/2022 à 22:42:18 (523 messages postés)

❤ 0

Le topic de discusion générale de making me semble pas vraiment adapté, il
n'existe pas une section pour partager les réflexions et théories permettant de
concevoir un jeu/ guider la création d'un jeu ?

Je prend comme exemple "Le système des 7 jours".
Il s'agit de compter au moins 7 jours entre l'apparition d'une nouvelle idée et son
ajout au projet/jeu que l'on souhaite créer. Cela permet de peser le pour et le
contre de cette idée, et prendre le temps de la réflexion sur la pertinence d'un
ajout. Avec cette rêgle on se s'éparpille pas dans tous les sens avec 40 systèmes
différents et on se concentre sur l'essentiel (surtout si il s'agit de notre 1er ou 2e
projet making)

Exemple concret, en début de semaine j'ai eu l'idée d'ajouter un système de
crochetage des coffres dans le jeu. Durant la semaine entière j'ai continué a
bosser sur le projet pour réaliser que cela reste gadget. (mais si mon jeu était
orienté infiltration ou avec un perso principal hors la loi ça aurait eu plus de sens)

En bref on évite le "woahou effect" lorsque l'on trouve une nouvelle idée. C'est pas
parce que c'est nouveau que c'est forcément pertinent sur le projet en cours.

Si vous avez une idée pour regrouper ce genre de conseil je prend. :clindoeil2


Falco - posté le 28/04/2022 à 11:08:59 (19565 messages postés) -

❤ 0

Indie game Developer

Nouvelles infos sur RPG Maker Unite :

https://store.steampowered.com/app/1650950/RPG_Maker_Unite/

Ils parlent de ce fameux "Outline Editor" qu'ils avaient teasé la semaine dernière, c'est une nouvelle façon de gérer son projet, exit les listes de maps relous, là on a un système d'héritage qui permet de gérer facilement les données du jeu.
Pas plus d'autres infos.

Inexistence Rebirth - Inexistence - Portfolio

Aller à la page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114

Index du forum > Généralités > Discussion Générale de making

repondre up

Suite à de nombreux abus, le post en invités a été désactivé. Veuillez vous inscrire si vous souhaitez participer à la conversation.

Haut de page

Merci de ne pas reproduire le contenu de ce site sans autorisation.
Contacter l'équipe - Mentions légales

Plan du site

Communauté: Accueil | Forum | Chat | Commentaires | News | Flash-news | Screen de la semaine | Sorties | Tests | Gaming-Live | Interviews | Galerie | OST | Blogs | Recherche
Apprendre: Visite guidée | RPG Maker 95 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker MV | Tutoriels | Guides | Making-of
Télécharger: Programmes | Scripts/Plugins | Ressources graphiques / sonores | Packs de ressources | Midis | Eléments séparés | Sprites
Jeux: Au hasard | Notre sélection | Sélection des membres | Tous les jeux | Jeux complets | Le cimetière | RPG Maker 95 | RPG Maker 2000 | RPG Maker 2003 | RPG Maker XP | RPG Maker VX | RPG Maker VX Ace | RPG Maker MV | Autres | Proposer
Ressources RPG Maker 2000/2003: Chipsets | Charsets | Panoramas | Backdrops | Facesets | Battle anims | Battle charsets | Monstres | Systems | Templates
Ressources RPG Maker XP: Tilesets | Autotiles | Characters | Battlers | Window skins | Icônes | Transitions | Fogs | Templates
Ressources RPG Maker VX: Tilesets | Charsets | Facesets | Systèmes
Ressources RPG Maker MV: Tilesets | Characters | Faces | Systèmes | Title | Battlebacks | Animations | SV/Ennemis
Archives: Palmarès | L'Annuaire | Livre d'or | Le Wiki | Divers