Promis, j’ai parcouru la section “Demande de nouvelles fonctionnalités” avant de poster ce message. D’ailleurs, c’était une bonne idée car j’ai vu que la fonction modulo existait
Ce message suit la discussion “collision entre instances d’un même objet” dans la partie “Aide à la création”
Je suis conscient qu’une partie de la facilité d’utilisation de GD vient du fait que le logiciel gère lui même la sélection d’une instance d’objet grâce aux conditions définies dans un évènement (collision entre la classe “Héro” et la classe “Garde” sélectionnera uniquement l’instance de “Héro” et de “Garde” qui sont effectivement entrés en collision). Donc pas question bien sur de revenir sur ce concept.
Ce que j’aimerais proposer est de faire cohabiter ce mode de sélection d’objets avec un autre mode qui permettrait, lui, d’accéder directement à des instances d’objet.
A chaque fois qu’un objet est créé, GD lui associe un identifiant unique accessible au programme (ex: Hero.ID(), Garde.ID()… un peu de la même manière que l’on a accès à Hero.X(), Hero.Y(), etc.)
Grâce à cet identifiant unique on peut (en parallèle du mode de sélection automatique d’instance de GD décrit plus haut) accéder à une instance donnée d’objet => identificateur ID permet d’accéder à un tableau d’instances:
Garde[0] accède à la première instance de garde créée
Garde[1] accède à la seconde, etc.
Bien entendu, il est possible par programme (grace à une variable) d’accéder à l’ensemble des instances d’un objet:
Garde[Variable(index)]… Il suffit d’incrémenter la variable index…
Toutes les ressources d’un objet sont bien sur accessibles (ex: Garde[1].X() retourne la position X de la seconde instance de Garde)
On peut effectuer des conditions et des actions sur des instances d’objet:
“L’objet Garde[1] est en collision avec l’objet Hero”) testera uniquement la collision éventuelle entre la seconde instance de Garde avec n’importe quelle instance de Hero… et comme d’habitude sélectionnera l’instance de Hero impliquée dans cette collision)
“L’objet Garde[0] est en collision avec l’objet Garde[1]” ou ne testera une éventuelle collision qu’entre ces 2 instances d’objets et uniquement celles ci.
“La distance entre les objets Garde[0] et Garde[1] est < 2”… pas besoin d’expliquer, tout le monde a compris…
Il y a déjà dans GD le concept de nombre d’instances d’un objet (ex: Count(Garde)), parfait. Il faudrait peut être pouvoir avoir une condition qui teste si une instance d’objet existe (ex: “Tester si une instance d’objet Garde[1] existe”) comme il existe déjà “Tester si une variable est définie” par exemple. En effet, si pendant un jeu, une instance est détruite (“Supprimer un objet Garde[1]”), tester l’existence d’une instance peut être intéressant.
Bon, enfin bref… ce message est déjà très long et tout le monde a compris l’idée Je suis tout à fait conscient que je suis dans le monde du “Ya-Qua”, “Faut-Quon” et que cela doit représenter beaucoup de travail (notamment, il faut permettre une nouvelle syntaxe “Objet[identificateur d’objet]” un peu partout dans GD…)
Disons que GD est déjà génial et, qu’avec cette possibilité, il deviendrait hyper-génial
En attendant, tu peux mettre des ID toi-même dans une variable que tu appelles ID. Pour retrouver l’objet, tu met un événement Répéter Pour chaque “Garde” (par exemple), avec une condition qui teste la variable ID de celui-ci.
Mais c’est vrai que si ça serait implémenter dans GD, ce serait plus facile et rapide.
tu peux mettre des ID toi-même dans une variable que tu appelles ID
Oui, c’est déjà ce que je fais (d’ailleurs sous tes conseils ).
Cet ID me sert à lier les objets “capteurs” aux objets “Hero” et “Gardes” ainsi qu’à avoir un chronomètre différent par instance d’objet (chronomètre “Garde0”, chronomètre “Garde1”, etc.). Tout cela marche déjà très bien.
Mais l’objet de cette demande de nouvelle fonctionnalité est plus de pouvoir adresser directement par programmation des instances d’objet Garde[0], Garde[1], etc…et bien sur, pour cela, il faut que chaque instance d’objet ait un ID unique… => il serait plus simple que cet ID unique soit généré par GD.
Ou alors, que l’on puisse prendre l’ID d’un objet et le garder temporairement en mémoire d’évènement (une fois l’évènement terminé ça disparaît…)
Prendre l’objet “Objet” et mettre ton ID dans le Slot1
Prendre l’objet “Objet” où son ID != ID(Slot1) et mettre son ID dans Slot2
On peux alors dire, créer un objet Bidule en position Objet.X() Objet.Y() où ID de Objet est du Slot1 ou 2, pour bien différencier, l’on peux alors faire des successions d’actions ou l’on est précis dans la selection des objets.
Fin de l’évènement, on vide les Slots. (Un peu comme une carte mémoire, sur une Game Cube, on la met dans un Slot.)
C’est peut être faisable
et imagine que tu est un pateaux de cases
comment u dit a game develop de calculer la distance entre
l’objet case et l’objet case ?, il on tous les deux le même nom et
le plateau en est remplie lol
avec les identifiant, oui surement mais bon
voir mon sujet “déplacement a la rpg maker” dans création
vous comprendrez mieux je pence !
J’approuve comme idée, ça serait vraiment super de pouvoir accéder à des ID directement sans avoir a le créer.
De plus, actuellement, soit on met un random X (qui peut tomber sur le même nombre déjà existant, soit il faut chercher un objet déjà existant, prendre son id, l’incrémenter.
La chose n’est elle pas réalisable avec une incrémentation directe dans GD ? (tant qu’à faire) Puis en plus ça permettrait de savoir que le premier objet crée serait ID[0] et de pouvoir faire une prog en fonction d’une plage d’ID (exemple, ID 0 à 9 facile etc…)
En tout cas si c’est intégrable dans GD, je pense que ça apportera vraiment des choses faisable beaucoup plus simplement
Je ne pense pas, il n’y a aucun raison pour que la valeur 0 ne marche pas, c’est une valeur de variable comme une autre.
A moins que tu ait un exemple de jeu à m’envoyer qui montre clairement que Game Develop bugge avec les variables qui ont 0 comme valeur.
Non j’ai pas d’exemples, et je ne vois pas non plus.
Enfin après, un ID de 0 quoi de plus débile…(ID vide quoi…, “NULL”)
Autant commencer à partir de 1
C’est pas débile, dans tous les langages de programmation, tout ce qui est listes, tableaux, etc… commencent toujours pas 0 (dans les tableaux, les matrices).
Oui mais 0 étant la valeur par défaut de GD, un objet n’ayant pas d’ID serait a 0, donc celui qui en a un n’est pas différentiable
Enfin, c’est du détail, si GD gère ça tout seul, ce sera du chipotage de savoir si c’est 0 ou 1 de début
)