Construct 2 (et Construct 3, Construct classic aussi sûrement) nous permettent de faire des jeux de manière accessible, et compréhensible.
L’une des premières règles que l’on apprend est la suivante:
Les évènements sont lus de haut en bas, les conditions sont lues de haut en bas, et si l’une est fausse, les autres ne seront pas évaluées, si toutes les conditions sont vraies, les actions sont exécutées de haut en bas.
Cela est vrai pour les conditions et évènements classiques, mais si il y a un trigger, ce n’est pas pareil, explications:
Notion de condition
Lorsque l’on met une chaîne de conditions classique, elle est évaluée une fois à chaque tick (c’est à dire à chaque fois que la feuille d’évènement est lue), si elle est vraie, les actions se produisent (il y a des notions plus complexes qui jouent là aussi, comme le fait de sélectionner des instances, ou « picking », mais ce n’est pas le but ici)
Notion de fonction
Pour bien se rendre compte des trigger, il est bon de savoir se servir de l’objet fonction, au moins comprendre la chose suivante:
Ici, lorsque on appelle la fonction « Manger », le nombre_de_repas augmente de 1,et il est possible d’appeler cette fonction avec une simple action. De même, si on appelle plusieurs fois la fonction, elle va s’exécuter autant de fois que nécessaire, et ce peu importe l’endroit où elle est placée dans la feuille d’évènement.
Notion de callback
Un callback est une fonction que le programme appelle tout seul, de lui même, comme une fonction, il peut donc se produire plusieurs fois, s’exécuter sans tenir compte directement de l’ordre des évènements autour, un trigger, c’est ça, c’est un callback, une fonction qui est appelée par le programme.
Ainsi, un « On start of layout » s’exécutera lorsque le programme dira que on à changé de layout, même si il se trouve en bas de la feuille d’évènement, pareil pour un « On timer » qui lui s’exécutera au moment ou un timer défini atteint 0, ou encore un « On collision » qui testera les collisions dès que c’est nécessaire.
Cela n’implique pas que l’évènement ne prend aucune ressource, le « On collision » est un bon exemple de trigger qui devient assez vite gourmand, cependant, cela implique que ils peuvent se produire plusieurs fois, et ne tiennent pas compte de l’ordre dans lequel ils sont placés, aussi, on ne peux pas vérifier deux triggers dans la même chaîne de conditions (car ils ne sont pas évalués au même moment).
Aussi, il vaut mieux éviter d’avoir le même trigger plusieurs fois présent.
Conclusion
Je n’ai pas l’habitude de faire des tutoriels sur les bases de Construct, donc n’hésitez pas à me dire si il y a des choses floues, voire fausse, dans ce petit article. Et je vous encourage vivement à lire le manuel pour plus d’informations sur la manière dont les évènements sont lus.