Comment fait-on pour qu'un enemi ai le comportement suivant :
lorsqu'un allié est proche(il y a plein d'obj allié différents (plusieurs obj1, plusieurs obj2)l'enemi aille sur le plus proche et l'attaque ?

[Topic renommé]

Citation :

instance_nearest(x,y,obj) Returns the id of the instance of type obj nearest to (x,y). obj can be an object or the keyword all.

Citation :

Parents

Every object can have a parent object. When an object has a parent, it inherits the behavior of the parent. Stated differently, the object is a sort of special case of the parent object. For example, if you have 4 different balls, named ball1, ball2, ball3 and ball4, which all behave the same but have a different sprite, you can make ball1 the parent of the other three. Now you only need to specify events for ball1. The others will inherit the events and behave exactly the same way. Also, when you apply actions to instances of the parent object they will also be applied to the children. So, for example, if you destroy all ball1 instances the ball2, ball3, and ball4 instances will also be destroyed. This saves a lot of work.
Often, objects should behave almost identically but there will be some small differences. For example, one monster might move up and down and the other left and right. For the rest they have exactly the same behavior. In this case almost all events should have the same actions but one or two might be different. Again we can make one object the parent of the other. But in this case we also define certain events for the child object. These events "override" the parent events. So whenever an event for the child object contains actions, these are executed instead of the event of the parent. If you also want to execute the parent event you can call the so-called "inherited" event using the appropriate action.

It is actually good practice in such cases to create one base object. This base object contains all the default behavior but is never used in the game. All actual objects have this base object as parent. Parent objects can again have parents, and so on. (Obviously you are not allowed to create cycles.) In this way you can create an object hierarchy. This is extremely useful to keep your game structured and you are strongly advised to learn to use this mechanism.

There is also a second use of the parent object. It also inherits the collision behavior for other objects. Let us explain this with an example. Assume you have four different floor objects. When a ball hits the floor it must change direction. This has to be specified in the collision event of the ball with the floor. Because there are four different floors we need to put the code on four different collision events of the ball. But when you make one base floor object and make this one the parent of the four actual floor objects, you only need to specify the collision event with this base floor. The other collisions will perform the same event. Again, this saves a lot of copying.

As indicated, wherever you use an object, this also implies the descendants. This happens when, in an action, you indicate that the action must be applied to instances of a certain object. It also happens when you use the with() statement in code (see below). And it works when you call functions like instance_position, instance_number, etc. Finally, it works when you refer to variables in other objects. In the example above when you set ball1.speed to 10 this also applies to ball2, ball3 and ball4.

donc

tu fait un object appelé allie_basic et tes objects alliés on cet object comme object parent ensuite tu trouve l'id du plus pres avec
dans ton object ennemi :
id_de_l_instance_la_plus_proche=instance_nearest(x,y,allie_basic)

pour le reste c'est à toi de faire il n'y a pas de fonction préfaite pour attaquer c'est trop vague

CA c du resumé..

Ah ! Gab...
J'ais trouvé il y a seulement une heure :boulet: (quand j'étais à mon entrainement de foot. Aucun rapport mais du moment que j'ais trouvé ).
Mais je viens de voir que tu m'avais répondu et...
Merci :p_merci:
C'est quand même gentil...