La première étape du développement de mon jeu a été le développement du moteur RTS. J'ai l'intention d'écrire une série d'articles sur les problèmes qui sont survenus et leurs solutions sur ce blog. Dans cet article, je vais vous expliquer comment j'ai organisé le comportement des unités.
En réfléchissant à où commencer ce moteur RTS en général, je suis arrivé à la conclusion qu'il valait la peine de commencer par les détails et de passer de celui-ci à l'abstraction. La première application qui me vint à l'esprit fut la collecte de ressources, ou plutôt l'extraction du bois.
Habituellement, ce processus dans la plupart des stratégies consiste dans le fait que l'employé, à la réception du décret de couper l'arbre, va à l'arbre, pendant un certain temps agite une pioche près de lui avec une hache, puis va à l'entrepôt et recommence.
Autrement dit, le processus ressemble à ceci:
Pour que cette image puisse véritablement revendiquer le nom de l'automate, il lui manque les conditions de transition entre les états et l'état initial et final.
Ici, tout est simple: la machine est initialisée avec l'état "je vais couper", et la fin du travail se produit lors du changement. Nous pouvons exprimer les transitions entre les États en utilisant les conditions suivantes: «atteint l'arbre», «coupé un tas de bois de chauffage», «atteint l'entrepôt», «cédé des ressources». Si la réponse est oui, la machine passe à l'état suivant, si elle est négative, elle reste à l'état actuel.
Dans chacun des états de l'automate, l'action correspondante est invoquée lors de l'itération. Un ensemble d'actions peut également être effectué lors de la transition entre les états.
Par exemple, lors de l'itération dans l'état "Remise", les ressources du sac à dos de l'unité seront transférées vers le magasin de ressources du joueur, et lors du passage de l'état "Going to chop" à l'état "Rouble", l'animation correspondante démarrera.
Je note également que la marche elle-même n'est pas une opération «atomique», elle se retrouve dans de nombreux comportements et est elle-même un comportement, et donc le comportement d'extraction d'arbre utilise en fait le comportement de marcher à l'intérieur de lui-même. Autrement dit, un nouvel automate peut être obtenu en utilisant la composition de plusieurs autres automates finis.
En écrivant les comportements de cette manière, nous obtenons une frontière architecturale entre les détails de la mise en œuvre des comportements et la politique de haut niveau de gestion de ces comportements. Les implémentations de comportements deviennent essentiellement des plug-ins pour le reste du jeu, c'est-à-dire que leurs modifications n'affecteront pas l'exactitude du travail de la logique de haut niveau.
Ces comportements fonctionnent en appelant la méthode d'itération à partir de l'événement Update d'objets de type Unit (cet événement déclenche chaque trame). Pour communiquer avec le reste du monde, les méthodes IStateMachineListener sont appelées.
Ceci est un exemple de construction de machine d'état dans mon jeu. À la réception d'une équipe de construction, l'unité se rend au point spécifié, puis entre dans l'état de construction directe, transférant les unités de construction dans le bâtiment. Lorsque le bâtiment a accumulé suffisamment d'unités de construction, la machine de construction se termine et l'unité reçoit un nouveau comportement, le comportement par défaut.
C’est tout. Si vous aimez ou n'aimez pas ce format, écrivez-le dans les commentaires!