Ce sujet a été résolu
J'ai un peu de mal à savoir comment ton truc fonctionne, je saurai pas déchiffrer l'erreur sur ce coup-là
Qu'est-ce qui contient quoi? Qu'est-ce qui charge quoi, quand, et comment?
L'inventaire de ton personnage ou d'un coffre contient quel genre d'objet pour représenter une arme? Tu enregistres des PackedScenes dans un dictionnaire?
Qu'est-ce qui contient quoi? Qu'est-ce qui charge quoi, quand, et comment?
L'inventaire de ton personnage ou d'un coffre contient quel genre d'objet pour représenter une arme? Tu enregistres des PackedScenes dans un dictionnaire?
Je viens de penser à un truc, mes armes référencent leur sort d'arme, et ça doit être ce sort qui n'est pas instancié correctement (même s'il est child dans la scene donc étrange tout de même)
J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis

J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis
il y a un an
Je viens de penser à un truc, mes armes référencent leur sort d'arme, et ça doit être ce sort qui n'est pas instancié correctement (même s'il est child dans la scene donc étrange tout de même)
J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis

J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis
ça m'a l'air assez farfelu
Bon c'est juste qu'on fait les choses différemment, je vais pas juger mais c'est pas évident de voir la solution
On est d'accord que:
- Tu instancies des armes comme enfants d'un coffre ou du sac du joueur.
- Ces armes ont un enfant Spell qui peut posséder des effets spéciaux.
- Ces effets spéciaux sont définis via un NodePath qui pointe vers un Node que tu ajoutes en enfant à la création de ton instance "Spell"
-----
A mon avis, tu ne peux pas utiliser un NodePath, car un Node c'est un truc >Unique< qui possède son propre ID. C'est une instance en gros. ça doit être pour ça que c'est tout géré pareil
A la limite, il faudrait plutôt que tu pointes sur un PackedScene, si on suit la logique de ta structure. Quelque chose qui puisse se charger et s'instancier proprement
Cependant tu devrais étudier la question de travailler avec des Resources. C'est vraiment extrêmement pratique, vu que ça peut se passer dans des variables, y'a pas besoin de les instancier pour les utiliser, ça contient tout un tas de variables et de fonctions pratiques que tu définis.
Une fois que tu as une classe de Resource bien construite pour une arme / un spell / un effet, tu as juste à créer une scène qui sache s'en servir et qui agisse sur le jeu en fonction des valeurs associées.
Bon c'est juste qu'on fait les choses différemment, je vais pas juger mais c'est pas évident de voir la solution
On est d'accord que:
- Tu instancies des armes comme enfants d'un coffre ou du sac du joueur.
- Ces armes ont un enfant Spell qui peut posséder des effets spéciaux.
- Ces effets spéciaux sont définis via un NodePath qui pointe vers un Node que tu ajoutes en enfant à la création de ton instance "Spell"
-----
A mon avis, tu ne peux pas utiliser un NodePath, car un Node c'est un truc >Unique< qui possède son propre ID. C'est une instance en gros. ça doit être pour ça que c'est tout géré pareil
A la limite, il faudrait plutôt que tu pointes sur un PackedScene, si on suit la logique de ta structure. Quelque chose qui puisse se charger et s'instancier proprement
Cependant tu devrais étudier la question de travailler avec des Resources. C'est vraiment extrêmement pratique, vu que ça peut se passer dans des variables, y'a pas besoin de les instancier pour les utiliser, ça contient tout un tas de variables et de fonctions pratiques que tu définis.
Une fois que tu as une classe de Resource bien construite pour une arme / un spell / un effet, tu as juste à créer une scène qui sache s'en servir et qui agisse sur le jeu en fonction des valeurs associées.
il y a un an
ça m'a l'air assez farfelu
Bon c'est juste qu'on fait les choses différemment, je vais pas juger mais c'est pas évident de voir la solution
On est d'accord que:
- Tu instancies des armes comme enfants d'un coffre ou du sac du joueur.
- Ces armes ont un enfant Spell qui peut posséder des effets spéciaux.
- Ces effets spéciaux sont définis via un NodePath qui pointe vers un Node que tu ajoutes en enfant à la création de ton instance "Spell"
-----
A mon avis, tu ne peux pas utiliser un NodePath, car un Node c'est un truc >Unique< qui possède son propre ID. C'est une instance en gros. ça doit être pour ça que c'est tout géré pareil
A la limite, il faudrait plutôt que tu pointes sur un PackedScene, si on suit la logique de ta structure. Quelque chose qui puisse se charger et s'instancier proprement
Cependant tu devrais étudier la question de travailler avec des Resources. C'est vraiment extrêmement pratique, vu que ça peut se passer dans des variables, y'a pas besoin de les instancier pour les utiliser, ça contient tout un tas de variables et de fonctions pratiques que tu définis.
Une fois que tu as une classe de Resource bien construite pour une arme / un spell / un effet, tu as juste à créer une scène qui sache s'en servir et qui agisse sur le jeu en fonction des valeurs associées.
Bon c'est juste qu'on fait les choses différemment, je vais pas juger mais c'est pas évident de voir la solution
On est d'accord que:
- Tu instancies des armes comme enfants d'un coffre ou du sac du joueur.
- Ces armes ont un enfant Spell qui peut posséder des effets spéciaux.
- Ces effets spéciaux sont définis via un NodePath qui pointe vers un Node que tu ajoutes en enfant à la création de ton instance "Spell"
-----
A mon avis, tu ne peux pas utiliser un NodePath, car un Node c'est un truc >Unique< qui possède son propre ID. C'est une instance en gros. ça doit être pour ça que c'est tout géré pareil
A la limite, il faudrait plutôt que tu pointes sur un PackedScene, si on suit la logique de ta structure. Quelque chose qui puisse se charger et s'instancier proprement
Cependant tu devrais étudier la question de travailler avec des Resources. C'est vraiment extrêmement pratique, vu que ça peut se passer dans des variables, y'a pas besoin de les instancier pour les utiliser, ça contient tout un tas de variables et de fonctions pratiques que tu définis.
Une fois que tu as une classe de Resource bien construite pour une arme / un spell / un effet, tu as juste à créer une scène qui sache s'en servir et qui agisse sur le jeu en fonction des valeurs associées.
Le nodepath c'est uniquement car il n'y a pas moyen de référencer un node directement depuis un @export Array (ou du moins j'ai pas trouvé), mais le node réel est bien un enfant
Et excepté ce bug/mécanisme que je ne comprend pas qui n'instancy pas la scene de base, je n'ai pas de soucis particulier avec ma façon de faire donc ça me va
Pour l'instant j'ai trifouillé pour que ça fonctionne, j'espère juste que ça ne me posera pas de soucis à l'avenir
Par contre je suis quand même intrigué, tu entends quoi par système de Resources ? T'aurais un exemple ?
Et excepté ce bug/mécanisme que je ne comprend pas qui n'instancy pas la scene de base, je n'ai pas de soucis particulier avec ma façon de faire donc ça me va
Pour l'instant j'ai trifouillé pour que ça fonctionne, j'espère juste que ça ne me posera pas de soucis à l'avenir
Par contre je suis quand même intrigué, tu entends quoi par système de Resources ? T'aurais un exemple ?
il y a un an
Le nodepath c'est uniquement car il n'y a pas moyen de référencer un node directement depuis un @export Array (ou du moins j'ai pas trouvé), mais le node réel est bien un enfant
Et excepté ce bug/mécanisme que je ne comprend pas qui n'instancy pas la scene de base, je n'ai pas de soucis particulier avec ma façon de faire donc ça me va
Pour l'instant j'ai trifouillé pour que ça fonctionne, j'espère juste que ça ne me posera pas de soucis à l'avenir
Par contre je suis quand même intrigué, tu entends quoi par système de Resources ? T'aurais un exemple ?
Et excepté ce bug/mécanisme que je ne comprend pas qui n'instancy pas la scene de base, je n'ai pas de soucis particulier avec ma façon de faire donc ça me va
Pour l'instant j'ai trifouillé pour que ça fonctionne, j'espère juste que ça ne me posera pas de soucis à l'avenir
Par contre je suis quand même intrigué, tu entends quoi par système de Resources ? T'aurais un exemple ?
Bon bah tant mieux si ça marche parce que j'ai du mal à saisir complètement
J'utilise les Resources pour à peu près tout:
- Les stats et informations de base des Personnages sont contenues dans des Resources de type "CharacterBase". Vraiment c'est juste un gros pack de variables ici:
Quand je veux créer un nouveau personnage, j'ai juste à aller dans mon arborescence, clic droit, créer -> Nouvelle Ressource, et je peux sélectionner un nouveau type CharacterBase. Puis j'ai plus qu'à remplir le formulaire avec chaque paramètre et enregistrer.
Vraiment c'est exactement comme si tu gérais un matériau de particule, une shape2D, une Curve, etc.
Ensuite je charge ça dans un Autoload "PlayerData", qui va importer ces données de base dans ses propres variables, pour pouvoir les modifier à l'infini selon les items qu'on collectera.
Lorsque je crée l'instance "Player", celui-ci utilise PlayerData pour définir son fonctionnement: vitesse de déplacement, projectile, etc.
Et par la même occasion, l'UI à gauche peut récupérer les portraits de personnages grâce à PlayerData
Avec un petit jeu de set/get, je peux aisément changer de personnage à l'infini comme on le voyait sur ma vidéo de démo:
PlayerData._character_base = load(...../NebariBaseChara.tres)
(évidemment faudra aussi changer le projectile mais tu vois l'idée)
Mais ça c'est pour construire juste un personnage auquel on apportera énormément de modifications et qui aura énormément de mécaniques. Ensuite on peut s'en servir pour faire un millier de trucs avec la même scène
- Quand tu tires un projectile, c'est toujours la même scène qui est appelée, mais elle utilise une Resource que j'ai appelé "ProjectileProperty" dans laquelle elle piochera absolument toutes les informations sur son comportement.
Ce ProjectileProperty on le définit exactement comme le CharacterBase. On crée la ressource avec tous les paramètres listés:
On enregistre, et on peut le charger quand on veut avec PlayerData!
Quand on instancie Player_projectile, on a juste à utiliser sa fonction setup() pour définir sa position, sa direction, son owner, son ProjectileProperty, et il se démerde pour la suite.
Mais attention! Toute modification qu'on souhaite faire sur cette ressource s'appliquera au fichier de base, il faut donc que je la copie avant de jouer avec. Je fais donc un _projectile = ProjectileProperty.new() avec PlayerData, auquel je fais passer les valeurs de la base souhaitée. Je pourrai ensuite modifier les stats du projectile quand je veux
Truc drôle, mais j'utilise aussi ProjectileProperty pour les projectiles des ennemis. C'est vraiment la même chose.
Autre truc, mon ProjectileProperty peut contenir d'autres ProjectileProperty pour définir les différents stades de Tir Chargé.
C'est vraiment un gros pack de variables et de fonctions qu'on peut façonner facilement, et qui s'utilise dans des variables sans jamais rien instancier.
- Tu peux facilement voir comment je compte utiliser la même structure avec les Biomes. Chaque biome du jeu sera une Resource, qui contiendra tout ce qu'il faut savoir sur l'étage dans lequel tu es. Que ce soit le background, ou les patterns d'ennemis à utiliser, ou les boss possibles, ou des événements spéciaux à mettre sur la map, ce sera disponible sur la même ressource interchangeable. Les éléments du jeu qui créeront la map, les vagues d'ennemis, etc, seront toujours les mêmes scènes avec des paramètres différents
J'utilise les Resources pour à peu près tout:
- Les stats et informations de base des Personnages sont contenues dans des Resources de type "CharacterBase". Vraiment c'est juste un gros pack de variables ici:
Quand je veux créer un nouveau personnage, j'ai juste à aller dans mon arborescence, clic droit, créer -> Nouvelle Ressource, et je peux sélectionner un nouveau type CharacterBase. Puis j'ai plus qu'à remplir le formulaire avec chaque paramètre et enregistrer.
Vraiment c'est exactement comme si tu gérais un matériau de particule, une shape2D, une Curve, etc.
Ensuite je charge ça dans un Autoload "PlayerData", qui va importer ces données de base dans ses propres variables, pour pouvoir les modifier à l'infini selon les items qu'on collectera.
Lorsque je crée l'instance "Player", celui-ci utilise PlayerData pour définir son fonctionnement: vitesse de déplacement, projectile, etc.
Et par la même occasion, l'UI à gauche peut récupérer les portraits de personnages grâce à PlayerData
Avec un petit jeu de set/get, je peux aisément changer de personnage à l'infini comme on le voyait sur ma vidéo de démo:
PlayerData._character_base = load(...../NebariBaseChara.tres)
(évidemment faudra aussi changer le projectile mais tu vois l'idée)
Mais ça c'est pour construire juste un personnage auquel on apportera énormément de modifications et qui aura énormément de mécaniques. Ensuite on peut s'en servir pour faire un millier de trucs avec la même scène
- Quand tu tires un projectile, c'est toujours la même scène qui est appelée, mais elle utilise une Resource que j'ai appelé "ProjectileProperty" dans laquelle elle piochera absolument toutes les informations sur son comportement.
Ce ProjectileProperty on le définit exactement comme le CharacterBase. On crée la ressource avec tous les paramètres listés:
On enregistre, et on peut le charger quand on veut avec PlayerData!
Quand on instancie Player_projectile, on a juste à utiliser sa fonction setup() pour définir sa position, sa direction, son owner, son ProjectileProperty, et il se démerde pour la suite.
Mais attention! Toute modification qu'on souhaite faire sur cette ressource s'appliquera au fichier de base, il faut donc que je la copie avant de jouer avec. Je fais donc un _projectile = ProjectileProperty.new() avec PlayerData, auquel je fais passer les valeurs de la base souhaitée. Je pourrai ensuite modifier les stats du projectile quand je veux
Truc drôle, mais j'utilise aussi ProjectileProperty pour les projectiles des ennemis. C'est vraiment la même chose.
Autre truc, mon ProjectileProperty peut contenir d'autres ProjectileProperty pour définir les différents stades de Tir Chargé.
C'est vraiment un gros pack de variables et de fonctions qu'on peut façonner facilement, et qui s'utilise dans des variables sans jamais rien instancier.
- Tu peux facilement voir comment je compte utiliser la même structure avec les Biomes. Chaque biome du jeu sera une Resource, qui contiendra tout ce qu'il faut savoir sur l'étage dans lequel tu es. Que ce soit le background, ou les patterns d'ennemis à utiliser, ou les boss possibles, ou des événements spéciaux à mettre sur la map, ce sera disponible sur la même ressource interchangeable. Les éléments du jeu qui créeront la map, les vagues d'ennemis, etc, seront toujours les mêmes scènes avec des paramètres différents
il y a un an
VisualStudio
1 an
Salut les kheys,
Je compte faire une vidéo pour savoir comment programmer un suika game, le code est prêt, j'ai juste à enregistrer ma voix et j'hésite à faire une facecam
Mais de façon général, ça intéresserait des kheys de regarder des lives de programmation ici ?
Si pas c'est pas grave
Je compte faire une vidéo pour savoir comment programmer un suika game, le code est prêt, j'ai juste à enregistrer ma voix et j'hésite à faire une facecam
Mais de façon général, ça intéresserait des kheys de regarder des lives de programmation ici ?
Si pas c'est pas grave
Tu peux faire un live sur la manière de casser des DRM pour le droit à la copie privé ?!
Mon propos est imaginaire et fictif, il n'implique donc aucun fait ou élément réel et toute ressemblance serait fortuite
il y a un an
Unreal c'est bien aussi si ça te correspond, même si c'est surtout bien pour la 3D
Je veux surtout un truc avec beaucoup de possibilités pour m'amuser un max, après je suis débutant donc c'est pas évident mais j'ai réussi à faire un petit jeu de tir en arène je suis content
même si ça va paraître à chier pour n'importe qui un peu expérimenté
Perdez pas espoir
il y a un an
Bon bah tant mieux si ça marche parce que j'ai du mal à saisir complètement
J'utilise les Resources pour à peu près tout:
- Les stats et informations de base des Personnages sont contenues dans des Resources de type "CharacterBase". Vraiment c'est juste un gros pack de variables ici:
Quand je veux créer un nouveau personnage, j'ai juste à aller dans mon arborescence, clic droit, créer -> Nouvelle Ressource, et je peux sélectionner un nouveau type CharacterBase. Puis j'ai plus qu'à remplir le formulaire avec chaque paramètre et enregistrer.
Vraiment c'est exactement comme si tu gérais un matériau de particule, une shape2D, une Curve, etc.
Ensuite je charge ça dans un Autoload "PlayerData", qui va importer ces données de base dans ses propres variables, pour pouvoir les modifier à l'infini selon les items qu'on collectera.
Lorsque je crée l'instance "Player", celui-ci utilise PlayerData pour définir son fonctionnement: vitesse de déplacement, projectile, etc.
Et par la même occasion, l'UI à gauche peut récupérer les portraits de personnages grâce à PlayerData
Avec un petit jeu de set/get, je peux aisément changer de personnage à l'infini comme on le voyait sur ma vidéo de démo:
PlayerData._character_base = load(...../NebariBaseChara.tres)
(évidemment faudra aussi changer le projectile mais tu vois l'idée)
Mais ça c'est pour construire juste un personnage auquel on apportera énormément de modifications et qui aura énormément de mécaniques. Ensuite on peut s'en servir pour faire un millier de trucs avec la même scène
- Quand tu tires un projectile, c'est toujours la même scène qui est appelée, mais elle utilise une Resource que j'ai appelé "ProjectileProperty" dans laquelle elle piochera absolument toutes les informations sur son comportement.
Ce ProjectileProperty on le définit exactement comme le CharacterBase. On crée la ressource avec tous les paramètres listés:
On enregistre, et on peut le charger quand on veut avec PlayerData!
Quand on instancie Player_projectile, on a juste à utiliser sa fonction setup() pour définir sa position, sa direction, son owner, son ProjectileProperty, et il se démerde pour la suite.
Mais attention! Toute modification qu'on souhaite faire sur cette ressource s'appliquera au fichier de base, il faut donc que je la copie avant de jouer avec. Je fais donc un _projectile = ProjectileProperty.new() avec PlayerData, auquel je fais passer les valeurs de la base souhaitée. Je pourrai ensuite modifier les stats du projectile quand je veux
Truc drôle, mais j'utilise aussi ProjectileProperty pour les projectiles des ennemis. C'est vraiment la même chose.
Autre truc, mon ProjectileProperty peut contenir d'autres ProjectileProperty pour définir les différents stades de Tir Chargé.
C'est vraiment un gros pack de variables et de fonctions qu'on peut façonner facilement, et qui s'utilise dans des variables sans jamais rien instancier.
- Tu peux facilement voir comment je compte utiliser la même structure avec les Biomes. Chaque biome du jeu sera une Resource, qui contiendra tout ce qu'il faut savoir sur l'étage dans lequel tu es. Que ce soit le background, ou les patterns d'ennemis à utiliser, ou les boss possibles, ou des événements spéciaux à mettre sur la map, ce sera disponible sur la même ressource interchangeable. Les éléments du jeu qui créeront la map, les vagues d'ennemis, etc, seront toujours les mêmes scènes avec des paramètres différents
J'utilise les Resources pour à peu près tout:
- Les stats et informations de base des Personnages sont contenues dans des Resources de type "CharacterBase". Vraiment c'est juste un gros pack de variables ici:
Quand je veux créer un nouveau personnage, j'ai juste à aller dans mon arborescence, clic droit, créer -> Nouvelle Ressource, et je peux sélectionner un nouveau type CharacterBase. Puis j'ai plus qu'à remplir le formulaire avec chaque paramètre et enregistrer.
Vraiment c'est exactement comme si tu gérais un matériau de particule, une shape2D, une Curve, etc.
Ensuite je charge ça dans un Autoload "PlayerData", qui va importer ces données de base dans ses propres variables, pour pouvoir les modifier à l'infini selon les items qu'on collectera.
Lorsque je crée l'instance "Player", celui-ci utilise PlayerData pour définir son fonctionnement: vitesse de déplacement, projectile, etc.
Et par la même occasion, l'UI à gauche peut récupérer les portraits de personnages grâce à PlayerData
Avec un petit jeu de set/get, je peux aisément changer de personnage à l'infini comme on le voyait sur ma vidéo de démo:
PlayerData._character_base = load(...../NebariBaseChara.tres)
(évidemment faudra aussi changer le projectile mais tu vois l'idée)
Mais ça c'est pour construire juste un personnage auquel on apportera énormément de modifications et qui aura énormément de mécaniques. Ensuite on peut s'en servir pour faire un millier de trucs avec la même scène
- Quand tu tires un projectile, c'est toujours la même scène qui est appelée, mais elle utilise une Resource que j'ai appelé "ProjectileProperty" dans laquelle elle piochera absolument toutes les informations sur son comportement.
Ce ProjectileProperty on le définit exactement comme le CharacterBase. On crée la ressource avec tous les paramètres listés:
On enregistre, et on peut le charger quand on veut avec PlayerData!
Quand on instancie Player_projectile, on a juste à utiliser sa fonction setup() pour définir sa position, sa direction, son owner, son ProjectileProperty, et il se démerde pour la suite.
Mais attention! Toute modification qu'on souhaite faire sur cette ressource s'appliquera au fichier de base, il faut donc que je la copie avant de jouer avec. Je fais donc un _projectile = ProjectileProperty.new() avec PlayerData, auquel je fais passer les valeurs de la base souhaitée. Je pourrai ensuite modifier les stats du projectile quand je veux
Truc drôle, mais j'utilise aussi ProjectileProperty pour les projectiles des ennemis. C'est vraiment la même chose.
Autre truc, mon ProjectileProperty peut contenir d'autres ProjectileProperty pour définir les différents stades de Tir Chargé.
C'est vraiment un gros pack de variables et de fonctions qu'on peut façonner facilement, et qui s'utilise dans des variables sans jamais rien instancier.
- Tu peux facilement voir comment je compte utiliser la même structure avec les Biomes. Chaque biome du jeu sera une Resource, qui contiendra tout ce qu'il faut savoir sur l'étage dans lequel tu es. Que ce soit le background, ou les patterns d'ennemis à utiliser, ou les boss possibles, ou des événements spéciaux à mettre sur la map, ce sera disponible sur la même ressource interchangeable. Les éléments du jeu qui créeront la map, les vagues d'ennemis, etc, seront toujours les mêmes scènes avec des paramètres différents
Je vois, merci pour les explications approfondies
Malgré que je ne suis pas sûr de comprendre l'intérêt majeur, à part un accès plus simple aux valeurs par défaut
Et accessoirement pouvoir le crée avec les valeurs par défaut, mais de mon côté ça me paraît très étrange que ça soit pas le cas avec instantiate
Par-ce qu'au final je fais plus ou moins la même chose, exemple avec les Spell :
(+ je me garde une grosse marche de manœuvre dans le code pour faire à peu près tout ce que je veux)
De plus ta méthode t'empêche d'utiliser l'éditeur pour modifier certains nodes, on le voit que t'es obligé de définir à la main la taille de la hitbox alors que moi je le fais sur la nouvelle hitbox de l'héritage
__________________
Bon je sais aussi que mon code est loin d'être clean, mais si je m'écoutais j'aurais déjà recommencé à 0
J'essaye de coder au fil de l'anguille, et d'outrepasser les défauts qui arrivent ça-et-là, mon but n'est pas de faire le code parfait mais le jeu de mes rêves
Des fois je me dit "C'est vraiment pas propre quand même", puis je repense au code de Terraria et je me dis que c'est pas si grave en faite
La dure vie d'un perfectionniste dans la programmation
J'évite aussi les grosses TODO list, c'est une autre source de démotivation pour moi
Malgré que je ne suis pas sûr de comprendre l'intérêt majeur, à part un accès plus simple aux valeurs par défaut
Et accessoirement pouvoir le crée avec les valeurs par défaut, mais de mon côté ça me paraît très étrange que ça soit pas le cas avec instantiate
Par-ce qu'au final je fais plus ou moins la même chose, exemple avec les Spell :
(+ je me garde une grosse marche de manœuvre dans le code pour faire à peu près tout ce que je veux)
De plus ta méthode t'empêche d'utiliser l'éditeur pour modifier certains nodes, on le voit que t'es obligé de définir à la main la taille de la hitbox alors que moi je le fais sur la nouvelle hitbox de l'héritage
__________________
Bon je sais aussi que mon code est loin d'être clean, mais si je m'écoutais j'aurais déjà recommencé à 0
J'essaye de coder au fil de l'anguille, et d'outrepasser les défauts qui arrivent ça-et-là, mon but n'est pas de faire le code parfait mais le jeu de mes rêves
Des fois je me dit "C'est vraiment pas propre quand même", puis je repense au code de Terraria et je me dis que c'est pas si grave en faite
La dure vie d'un perfectionniste dans la programmation
J'évite aussi les grosses TODO list, c'est une autre source de démotivation pour moi
il y a un an
Je viens de lire vos messages, c'est intéressant de voir comment vous faites et je trouve ça bien, prenez soins de vous et bon weekend les kheys
Pour la modification des variables dans l'éditeur, c'est pas mal, ça ressemble beaucoup à ce qu'on peut faire des unity c'est pas mal, j'en ai pas encore eu l'utilité, mais ça peut être pratique si tu veux drag & drop des scènes et les modifiers sans devoir modifier le code
Pour la modification des variables dans l'éditeur, c'est pas mal, ça ressemble beaucoup à ce qu'on peut faire des unity c'est pas mal, j'en ai pas encore eu l'utilité, mais ça peut être pratique si tu veux drag & drop des scènes et les modifiers sans devoir modifier le code
Je vous aime les kheys, prenez soins de vous
il y a un an
ViveLaConsole
1 an
Oui, j'adore les lives sur la programmation
C'est un vieux topic que je resors quand j'ai besoin d'aide/conseil, mais depuis VisualStudio a sortie ça :
https://onche.org/topic/5[...]remier-tutoriel-sur-godot
il y a un an
Je vois, merci pour les explications approfondies
Malgré que je ne suis pas sûr de comprendre l'intérêt majeur, à part un accès plus simple aux valeurs par défaut
Et accessoirement pouvoir le crée avec les valeurs par défaut, mais de mon côté ça me paraît très étrange que ça soit pas le cas avec instantiate
Par-ce qu'au final je fais plus ou moins la même chose, exemple avec les Spell :
(+ je me garde une grosse marche de manœuvre dans le code pour faire à peu près tout ce que je veux)
De plus ta méthode t'empêche d'utiliser l'éditeur pour modifier certains nodes, on le voit que t'es obligé de définir à la main la taille de la hitbox alors que moi je le fais sur la nouvelle hitbox de l'héritage
__________________
Bon je sais aussi que mon code est loin d'être clean, mais si je m'écoutais j'aurais déjà recommencé à 0
J'essaye de coder au fil de l'anguille, et d'outrepasser les défauts qui arrivent ça-et-là, mon but n'est pas de faire le code parfait mais le jeu de mes rêves
Des fois je me dit "C'est vraiment pas propre quand même", puis je repense au code de Terraria et je me dis que c'est pas si grave en faite
La dure vie d'un perfectionniste dans la programmation
J'évite aussi les grosses TODO list, c'est une autre source de démotivation pour moi
Malgré que je ne suis pas sûr de comprendre l'intérêt majeur, à part un accès plus simple aux valeurs par défaut
Et accessoirement pouvoir le crée avec les valeurs par défaut, mais de mon côté ça me paraît très étrange que ça soit pas le cas avec instantiate
Par-ce qu'au final je fais plus ou moins la même chose, exemple avec les Spell :
(+ je me garde une grosse marche de manœuvre dans le code pour faire à peu près tout ce que je veux)
De plus ta méthode t'empêche d'utiliser l'éditeur pour modifier certains nodes, on le voit que t'es obligé de définir à la main la taille de la hitbox alors que moi je le fais sur la nouvelle hitbox de l'héritage
__________________
Bon je sais aussi que mon code est loin d'être clean, mais si je m'écoutais j'aurais déjà recommencé à 0
J'essaye de coder au fil de l'anguille, et d'outrepasser les défauts qui arrivent ça-et-là, mon but n'est pas de faire le code parfait mais le jeu de mes rêves
Des fois je me dit "C'est vraiment pas propre quand même", puis je repense au code de Terraria et je me dis que c'est pas si grave en faite
La dure vie d'un perfectionniste dans la programmation
J'évite aussi les grosses TODO list, c'est une autre source de démotivation pour moi
L'avantage majeur c'est que tu as pas besoin d'instancier des scènes pour chaque truc, et que tes ressources elles restent bien rangées et accessibles via variables. Tu peux les modifier à volonté donc c'est pas nécessairement pour des paramètres de base impossibles à changer, faut juste faire un duplicata pour éviter de faire des bêtises
Tu as effectivement pas le même éditeur graphique que pour une scène, donc c'est pas la solution à tout (mes patterns d'ennemis sont des Nodes avec des enfants dont je définis les trajectoires visuellement par exemple)
Tu peux définir des méthodes dans tes Resources, c'est pas plus compliqué qu'une scène de toute façon, faut un script.
Je me disais que pour un jeu RPG avec énormément de stats et autres trucs chiffrés, ça pourrait être pratique. Pour gérer un inventaire je pense que c'est pas mal non plus, quitte à associer ensuite une scène à l'item "acteur" sorti du sac.
Mais t'as raison, je vais pas te faire refaire ton code pour ça si ton système marche. Faut juste faire en sorte de:
- S'y retrouver facilement quand on relit
- Pouvoir créer du contenu facilement derrière
- S'assurer que ça bloquera pas avec de nouveaux ajouts de mécaniques plus tard
Pour avoir fait plein de projets à la con comme ça, sans jamais finir, j'ai souvent rencontré ces difficultés parfois même en les connaissant à l'avance. Pour ça qu'aujourd'hui je prends bien mon temps pour trouver des structures solides et pratiques
Appelons ça des techniques de fainéant pour avoir le moins de code à faire
____
Sinon la TODO list ça me fait peur aussi. Je suis juste obligé de prévoir les choses un peu à l'avance, même vaguement, pour construire les bonnes bases. Mon plus gros bloquage c'est de créer de nouvelles grosses structures, vu l'impact que ça a sur le reste
Aujourd'hui j'en suis à la gestion de "salles" comme sur Isaac. Le système qui ouvre/ferme les portes, donne les récompenses, etc. Et ça demande beaucoup de choses interconnectées entre biomes, map... Maps qui doivent aussi gérer la RNG avec des seeds... Sacré bordel
Tu as effectivement pas le même éditeur graphique que pour une scène, donc c'est pas la solution à tout (mes patterns d'ennemis sont des Nodes avec des enfants dont je définis les trajectoires visuellement par exemple)
Tu peux définir des méthodes dans tes Resources, c'est pas plus compliqué qu'une scène de toute façon, faut un script.
Je me disais que pour un jeu RPG avec énormément de stats et autres trucs chiffrés, ça pourrait être pratique. Pour gérer un inventaire je pense que c'est pas mal non plus, quitte à associer ensuite une scène à l'item "acteur" sorti du sac.
Mais t'as raison, je vais pas te faire refaire ton code pour ça si ton système marche. Faut juste faire en sorte de:
- S'y retrouver facilement quand on relit
- Pouvoir créer du contenu facilement derrière
- S'assurer que ça bloquera pas avec de nouveaux ajouts de mécaniques plus tard
Pour avoir fait plein de projets à la con comme ça, sans jamais finir, j'ai souvent rencontré ces difficultés parfois même en les connaissant à l'avance. Pour ça qu'aujourd'hui je prends bien mon temps pour trouver des structures solides et pratiques
Appelons ça des techniques de fainéant pour avoir le moins de code à faire
____
Sinon la TODO list ça me fait peur aussi. Je suis juste obligé de prévoir les choses un peu à l'avance, même vaguement, pour construire les bonnes bases. Mon plus gros bloquage c'est de créer de nouvelles grosses structures, vu l'impact que ça a sur le reste
Aujourd'hui j'en suis à la gestion de "salles" comme sur Isaac. Le système qui ouvre/ferme les portes, donne les récompenses, etc. Et ça demande beaucoup de choses interconnectées entre biomes, map... Maps qui doivent aussi gérer la RNG avec des seeds... Sacré bordel
il y a un an
VisualStudio
1 an
Je viens de lire vos messages, c'est intéressant de voir comment vous faites et je trouve ça bien, prenez soins de vous et bon weekend les kheys
Pour la modification des variables dans l'éditeur, c'est pas mal, ça ressemble beaucoup à ce qu'on peut faire des unity c'est pas mal, j'en ai pas encore eu l'utilité, mais ça peut être pratique si tu veux drag & drop des scènes et les modifiers sans devoir modifier le code
Pour la modification des variables dans l'éditeur, c'est pas mal, ça ressemble beaucoup à ce qu'on peut faire des unity c'est pas mal, j'en ai pas encore eu l'utilité, mais ça peut être pratique si tu veux drag & drop des scènes et les modifiers sans devoir modifier le code
C'est giga pratique
Tu peux paramétrer ce que tu veux en un clic, et voir la différence en live sur le mode debug
Tu peux paramétrer ce que tu veux en un clic, et voir la différence en live sur le mode debug
il y a un an
L'avantage majeur c'est que tu as pas besoin d'instancier des scènes pour chaque truc, et que tes ressources elles restent bien rangées et accessibles via variables. Tu peux les modifier à volonté donc c'est pas nécessairement pour des paramètres de base impossibles à changer, faut juste faire un duplicata pour éviter de faire des bêtises
Tu as effectivement pas le même éditeur graphique que pour une scène, donc c'est pas la solution à tout (mes patterns d'ennemis sont des Nodes avec des enfants dont je définis les trajectoires visuellement par exemple)
Tu peux définir des méthodes dans tes Resources, c'est pas plus compliqué qu'une scène de toute façon, faut un script.
Je me disais que pour un jeu RPG avec énormément de stats et autres trucs chiffrés, ça pourrait être pratique. Pour gérer un inventaire je pense que c'est pas mal non plus, quitte à associer ensuite une scène à l'item "acteur" sorti du sac.
Mais t'as raison, je vais pas te faire refaire ton code pour ça si ton système marche. Faut juste faire en sorte de:
- S'y retrouver facilement quand on relit
- Pouvoir créer du contenu facilement derrière
- S'assurer que ça bloquera pas avec de nouveaux ajouts de mécaniques plus tard
Pour avoir fait plein de projets à la con comme ça, sans jamais finir, j'ai souvent rencontré ces difficultés parfois même en les connaissant à l'avance. Pour ça qu'aujourd'hui je prends bien mon temps pour trouver des structures solides et pratiques
Appelons ça des techniques de fainéant pour avoir le moins de code à faire
____
Sinon la TODO list ça me fait peur aussi. Je suis juste obligé de prévoir les choses un peu à l'avance, même vaguement, pour construire les bonnes bases. Mon plus gros bloquage c'est de créer de nouvelles grosses structures, vu l'impact que ça a sur le reste
Aujourd'hui j'en suis à la gestion de "salles" comme sur Isaac. Le système qui ouvre/ferme les portes, donne les récompenses, etc. Et ça demande beaucoup de choses interconnectées entre biomes, map... Maps qui doivent aussi gérer la RNG avec des seeds... Sacré bordel
Tu as effectivement pas le même éditeur graphique que pour une scène, donc c'est pas la solution à tout (mes patterns d'ennemis sont des Nodes avec des enfants dont je définis les trajectoires visuellement par exemple)
Tu peux définir des méthodes dans tes Resources, c'est pas plus compliqué qu'une scène de toute façon, faut un script.
Je me disais que pour un jeu RPG avec énormément de stats et autres trucs chiffrés, ça pourrait être pratique. Pour gérer un inventaire je pense que c'est pas mal non plus, quitte à associer ensuite une scène à l'item "acteur" sorti du sac.
Mais t'as raison, je vais pas te faire refaire ton code pour ça si ton système marche. Faut juste faire en sorte de:
- S'y retrouver facilement quand on relit
- Pouvoir créer du contenu facilement derrière
- S'assurer que ça bloquera pas avec de nouveaux ajouts de mécaniques plus tard
Pour avoir fait plein de projets à la con comme ça, sans jamais finir, j'ai souvent rencontré ces difficultés parfois même en les connaissant à l'avance. Pour ça qu'aujourd'hui je prends bien mon temps pour trouver des structures solides et pratiques
Appelons ça des techniques de fainéant pour avoir le moins de code à faire
____
Sinon la TODO list ça me fait peur aussi. Je suis juste obligé de prévoir les choses un peu à l'avance, même vaguement, pour construire les bonnes bases. Mon plus gros bloquage c'est de créer de nouvelles grosses structures, vu l'impact que ça a sur le reste
Aujourd'hui j'en suis à la gestion de "salles" comme sur Isaac. Le système qui ouvre/ferme les portes, donne les récompenses, etc. Et ça demande beaucoup de choses interconnectées entre biomes, map... Maps qui doivent aussi gérer la RNG avec des seeds... Sacré bordel
Je vois, c'est intéressant de savoir comment tu gères ça de ton côté
J'ai toujours eu du mal à suivre les normes de structure du code des autres, je m'estime pas super bon 'programmeur', et malgré 5 ans d'étude en programmation c'est juste un outil pour faire des jeux pour moi
Je serais complètement perdus pour faire du web moderne par exemple
Et je parle même pas de l'ennui de coder h24 un truc sans beau résultat derrière
___
Sinon de mon côté je viens de terminer les checkpoints (qui permettent de changer la classe d'un perso, de changer le groupe, et de respawn; et plus tard qui servira de tp probablement)
Et là il me reste Sauvegarde / Traduction / Classe Tamer à réaliser sur cette étape
Pour le système d'invocations je pense que je vais les faire hériter de tous les passifs de l'invocateur (sauf passif inné), ça pourra donner lieu à de sacrés synergies !
J'en dirais pluss au prochain devblog
J'ai toujours eu du mal à suivre les normes de structure du code des autres, je m'estime pas super bon 'programmeur', et malgré 5 ans d'étude en programmation c'est juste un outil pour faire des jeux pour moi
Je serais complètement perdus pour faire du web moderne par exemple
Et je parle même pas de l'ennui de coder h24 un truc sans beau résultat derrière
___
Sinon de mon côté je viens de terminer les checkpoints (qui permettent de changer la classe d'un perso, de changer le groupe, et de respawn; et plus tard qui servira de tp probablement)
Et là il me reste Sauvegarde / Traduction / Classe Tamer à réaliser sur cette étape
Pour le système d'invocations je pense que je vais les faire hériter de tous les passifs de l'invocateur (sauf passif inné), ça pourra donner lieu à de sacrés synergies !
J'en dirais pluss au prochain devblog
il y a un an
Je vois, c'est intéressant de savoir comment tu gères ça de ton côté
J'ai toujours eu du mal à suivre les normes de structure du code des autres, je m'estime pas super bon 'programmeur', et malgré 5 ans d'étude en programmation c'est juste un outil pour faire des jeux pour moi
Je serais complètement perdus pour faire du web moderne par exemple
Et je parle même pas de l'ennui de coder h24 un truc sans beau résultat derrière
___
Sinon de mon côté je viens de terminer les checkpoints (qui permettent de changer la classe d'un perso, de changer le groupe, et de respawn; et plus tard qui servira de tp probablement)
Et là il me reste Sauvegarde / Traduction / Classe Tamer à réaliser sur cette étape
Pour le système d'invocations je pense que je vais les faire hériter de tous les passifs de l'invocateur (sauf passif inné), ça pourra donner lieu à de sacrés synergies !
J'en dirais pluss au prochain devblog
J'ai toujours eu du mal à suivre les normes de structure du code des autres, je m'estime pas super bon 'programmeur', et malgré 5 ans d'étude en programmation c'est juste un outil pour faire des jeux pour moi
Je serais complètement perdus pour faire du web moderne par exemple
Et je parle même pas de l'ennui de coder h24 un truc sans beau résultat derrière
___
Sinon de mon côté je viens de terminer les checkpoints (qui permettent de changer la classe d'un perso, de changer le groupe, et de respawn; et plus tard qui servira de tp probablement)
Et là il me reste Sauvegarde / Traduction / Classe Tamer à réaliser sur cette étape
Pour le système d'invocations je pense que je vais les faire hériter de tous les passifs de l'invocateur (sauf passif inné), ça pourra donner lieu à de sacrés synergies !
J'en dirais pluss au prochain devblog
T'avances bien comme d'hab
Je devrais pas tarder à donner des nouvelles aussi, si j'arrive à marquer une fin d'étape claire avant de devoir me mettre à la map procédurale
Je devrais pas tarder à donner des nouvelles aussi, si j'arrive à marquer une fin d'étape claire avant de devoir me mettre à la map procédurale
il y a un an
Re-coucou, j'ai un peu pause dernièrement mais j'avais bien envie de continuer aujourd'hui
@VisualStudio @Millefi-Hime
Je suis en train de test un peu la trajectoire des projectiles d'animation, avec le Path2D, comme je sais que t'as dût en faire Millefi je me suis dit que tu pouvais savoir comment résoudre ma problématique
J'aimerais pouvoir altérer la trajectoire pour aller du premier point (le lanceur), à un 2ème (la cible)
J'imagine qu'il doit y avoir moyen de faire ça avec quelques calculs sur les points, mais je me demande si y a pas plus simple
Aussi faudrait que ça puisse mirror pour viser autant de droite vers la gauche, de gauche vers la droite, de haut en bas
Des idées ?
@VisualStudio @Millefi-Hime
Je suis en train de test un peu la trajectoire des projectiles d'animation, avec le Path2D, comme je sais que t'as dût en faire Millefi je me suis dit que tu pouvais savoir comment résoudre ma problématique
J'aimerais pouvoir altérer la trajectoire pour aller du premier point (le lanceur), à un 2ème (la cible)
J'imagine qu'il doit y avoir moyen de faire ça avec quelques calculs sur les points, mais je me demande si y a pas plus simple
Aussi faudrait que ça puisse mirror pour viser autant de droite vers la gauche, de gauche vers la droite, de haut en bas
Des idées ?
il y a un an
Je viens de penser à un truc, mes armes référencent leur sort d'arme, et ça doit être ce sort qui n'est pas instancié correctement (même s'il est child dans la scene donc étrange tout de même)
J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis

J'essaye de résumer étape par étape ma situation :
1. L'arme
-> C'est un Item, avec une référence d'un spell (qui est une autre scene)
-> Dans quelques cas, ce sort possède une référence à un effet (qui est aussi une autre scene mais placé en tant qu'enfant du spell également), qui est initialement un Nodepath (oblige car c'est dans un @export Array pour simplifier ailleurs), qui est set au vrai Node dans le _ready du spell
2. Les instances directs
-> J'ai quelques coffres sur une map, dont j'ai placé directement les armes à l'intérieur
=> Dès les 2nds coffre j'ai un problème et la référence à l'effet est la même qui a été modifié au premier coffre/arme
3. Les instances en jeu
-> Cette fois-ci j'instance depuis le code, avec des armes de départ qui sont directement ajoutés à l'inventaire
=> Même soucis
C'est quoi le thème de l'éditeur ?
il y a un an
C'est quoi le thème de l'éditeur ?
il y a un an
Je bute sur la création de mesh, pour faire une carte avec heightmap.
Bon des plugins le font mais c'est pour le principe.
J'ai déjà vu du code qui marche, je comprends vaguement l'idée mais mon cerveau sait pas le refaire
Par contre j'avais un shader pour un mesh déjà existant, la génération c'est obligatoire dans mon cas ça permet de texturer les slopes sans avoir de mesh d'avance
Bon des plugins le font mais c'est pour le principe.
J'ai déjà vu du code qui marche, je comprends vaguement l'idée mais mon cerveau sait pas le refaire
Par contre j'avais un shader pour un mesh déjà existant, la génération c'est obligatoire dans mon cas ça permet de texturer les slopes sans avoir de mesh d'avance
il y a un an
0-0
1 an
Re-coucou, j'ai un peu pause dernièrement mais j'avais bien envie de continuer aujourd'hui
@VisualStudio @Millefi-Hime
Je suis en train de test un peu la trajectoire des projectiles d'animation, avec le Path2D, comme je sais que t'as dût en faire Millefi je me suis dit que tu pouvais savoir comment résoudre ma problématique
J'aimerais pouvoir altérer la trajectoire pour aller du premier point (le lanceur), à un 2ème (la cible)
J'imagine qu'il doit y avoir moyen de faire ça avec quelques calculs sur les points, mais je me demande si y a pas plus simple
Aussi faudrait que ça puisse mirror pour viser autant de droite vers la gauche, de gauche vers la droite, de haut en bas
Des idées ?
@VisualStudio @Millefi-Hime
Je suis en train de test un peu la trajectoire des projectiles d'animation, avec le Path2D, comme je sais que t'as dût en faire Millefi je me suis dit que tu pouvais savoir comment résoudre ma problématique
J'aimerais pouvoir altérer la trajectoire pour aller du premier point (le lanceur), à un 2ème (la cible)
J'imagine qu'il doit y avoir moyen de faire ça avec quelques calculs sur les points, mais je me demande si y a pas plus simple
Aussi faudrait que ça puisse mirror pour viser autant de droite vers la gauche, de gauche vers la droite, de haut en bas
Des idées ?
Ce qu'il va te falloir, c'est du code pour créer un Curve2D:
https://docs.godotengine.[...]lass_curve2d.html#methods
> var courbe := Curve2D.new()
> <setup de la courbe>
> Path2D.curve = courbe
A partir de là, pour la trajectoire définie sur ton exemple, tu n'as besoin que de deux points:
• Un point qui part de l'ennemi (0,0) et dont la tangente part vers le haut (0,-F)
• Un point situé sur le joueur (chara.x, chara.y) et dont la tangente est parallèle à la droite qui passe par (0,0) et (chara.x, chara.y)
Il te suffit donc de paramétrer cette courbe directement via le code, avec add_point( pos, in, out )
Avec in la tangente d'arrivée au point, et out la tangente de sortie du point. (tu peux jouer avec l'éditeur pour te faire une idée d'à quoi ça correspond).
N'oublie pas que les tangentes sont normées: Si tu donnes un gros facteur F, ça aplatira largement plus la courbe dans un sens.
> var courbe := Curve2D.new()
> <setup de la courbe>
> Path2D.curve = courbe
A partir de là, pour la trajectoire définie sur ton exemple, tu n'as besoin que de deux points:
• Un point qui part de l'ennemi (0,0) et dont la tangente part vers le haut (0,-F)
• Un point situé sur le joueur (chara.x, chara.y) et dont la tangente est parallèle à la droite qui passe par (0,0) et (chara.x, chara.y)
Il te suffit donc de paramétrer cette courbe directement via le code, avec add_point( pos, in, out )
Avec in la tangente d'arrivée au point, et out la tangente de sortie du point. (tu peux jouer avec l'éditeur pour te faire une idée d'à quoi ça correspond).
N'oublie pas que les tangentes sont normées: Si tu donnes un gros facteur F, ça aplatira largement plus la courbe dans un sens.
il y a un an