This project’s goal was to create an AI that could take over for a real human player using a structured state machine. This was a partner project with Drew Matthews, and we created a simple twin-stick shooter to show-off our AI. We used Flashpunk for the underlying engine, which allows us for easy collision detection. Along with the player AI, we also have an enemy state machine, and easy switching between AI and human controls.
The State Machines
Both player-types share the same state machine architecture:
Each player-type then has different states such as patrol, shoot, seek health, investigate, etc. We then form a state web, making segues between the different states, and what the conditions of the segue are (such as low health, enemy close by, etc.) Each state can offload data to the next state, thus its possible to alter behavior in multiple states and stay consistent (if power-ups were involved, for instance).
Retrospection and Postmortem
This project showed me the possible advantages of using finite state machines over decision or behavior trees. Here, each state, or behavior, is encapsulated and within its own class, allowing it to be independent of any other states and the ability to be hot-plugged based on other factors in the game (or for fast prototyping). On the other hand, behavior/decision trees tend to have their logic and behavior separated, which leads to the system reaching further in the codebase. This could be remedied slightly by having grouping behaviors into categories, but this still isn’t ideal: it doesn’t allow for individual behaviors to be independent of the system without a good bit of over-engineering. Still, there are advantages of behavior trees too, but that’s for another post. Overall, this project went well; I am proud of the result, and I feel it demonstrates a good understanding of how state machines work, and the code itself is clean and concise too.