Finite State Machines [Deel 1] – Unity-ontwikkelingshulpmiddelen van TKoU
Finite State Machines is misschien iets dat alle ontwikkelaars minstens één keer hebben gehoord in de paar jaar dat ze met game-ontwikkeling in Unity zijn begonnen.
Wat is een Finite State Machine eigenlijk? Wel, er is veel te behandelen, daarom gaan we minstens 3 delen doen. In principe is een eindige toestandsmachine (of FSM) een ontwerppatroon waarbij automatisering een rol speelt. Vaak gebruikt in AI implementaties voor bepaalde gedragingen. Zoals: lopen, aanvallen, stationair draaien, etc. FSM kan ook worden geïmplementeerd in NPC’s en komt het meest voor in Open World RPG’s.
Laten we FSM behandelen als een opziener:
Nu, de opziener controleert de toestand van een AI. Afhankelijk van de toestand, zal de AI hierop reageren. Ook, afhankelijk van het type van een AI (of het een vliegend type is, of grond type, of zwemmend type) is de actie die de AI zal maken. In dit scenario vertelt de FSM de AI dat hij zich in de “Patrouilletoestand” bevindt, en zal de AI zeggen “van A naar B te lopen”. Tenzij de toestand verandert, zal de AI alleen van A naar B lopen.
Om van toestand te veranderen, moeten we eerst een toestand hebben. In de afbeelding links, ziet de AI de speler, en vertelt dit aan de opzichter. Nu zal de opzichter de toestand van de AI veranderen, en beginnen aan te vallen.
Ook nu begint de AI weer te patrouilleren omdat de speler niet in zijn gezichtsveld is.
Zoals te zien is in deze slecht gemaakte tekeningen, heeft elke toestand zijn voorwaarden alvorens over te gaan naar andere toestanden.
Laten we eens kijken naar het diagram hieronder.
Hier is een diagram van toestanden van een normale AI. Rode lijnen staan voor onwaar op de voorwaarde die nodig is om van toestand te veranderen. Het diagram is vrij rechtlijnig. De AI zal in de ruststand staan als hij zijn bestemming bereikt, en vice versa. Als hij een vijand ziet, zal hij beginnen aan te vallen. De FSM handelt alle overgangen tussen toestanden af en helpt de AI de actie uit te voeren die voor die toestand beschikbaar is.
Nu gaan we ons FSM-systeem afbreken.
- Hoofd FSM-systeem – Dit is degene die de toestanden van de AI controleert en controleert of de omstandigheden tussen de toestanden overeenkomen. De Main FSM zal alle toestanden bevatten, en zal de event calls van de FSM Actions afhandelen.
- FSM State – Dit bepaalt de huidige toestand van de AI en bevat alle acties die op de AI zijn geplaatst.
- FSM Action – Dit zal de actie zijn die de AI zal doen wanneer de AI in een specifieke toestand is.
Nu, hoe gaan we het doen? Laten we alles in kaart brengen.
Dit wordt de lus van onze FSM. Eerst initialiseren we de FSM, maken we toestanden, maken we acties en brengen we ze allemaal in kaart. Nadat we ze in kaart hebben gebracht, starten we nu de FSM en geven de toestand aan waarin de AI zal beginnen. Nu zal de AI in een bepaalde toestand komen, en de FSM zal de actie initialiseren, deze bijwerken tot de actie is voltooid en een event zenden dat aangeeft dat de actie is voltooid. Tenslotte gaat de FSM terug en verandert de toestand.
Een ander ding dat een verandering van toestand veroorzaakt, is wanneer een gebeurtenis wordt opgeroepen buiten de logica van de AI om. Zoals wanneer we een commandant maken en tegen alle soldaten zeggen dat ze moeten stoppen met bewegen.
Dit is het einde van het eerste deel van onze FSM tutorial. Ik hoop dat ik je FSM goed heb uitgelegd. Als je het nog steeds niet snapt, zul je waarschijnlijk eerst alles in actie moeten zien, en alles zelf moeten scannen. Zo heb ik het geleerd.
In het volgende deel zullen we eerst weer een paar eenvoudige real life FSM implementaties bespreken, en we zullen beginnen onze hele FSM Engine vanaf nul te scripten!