Mech Retriever Dev Blog
I talked in my previous post about how I found an answer to a problem that I had with the code. The issue was that I had to replicate logic from the Driver code into the View code… which was bad, because the View code shouldn’t have to know.
I tried to look into Finite State Machines, which model all the states and transitions in a system so that you have robust code and avoid bugs. The problem is that, while the number of states a MechRetriever game can be in are finite, they are so astronomically many that there’s no way I could enumerate them. This was by design–in fact, the whole point of Emergent Game Design is this “Explosion of Probability Space*,” which enables the player freedom of creative expression.
But, what I realized was finite was the number of actions you could take at any given moment. As a turn based game, only one thing could happen at a time. This turned the Finite State Machine idea on its ear, inverting the paradigm into what I’ve taken to calling a Finite Command Machine. As a result, I was able eliminate the need for any of the View code to know what was valid–all it had to do was pick from a menu of options the driver supplied it with. This also meant I could drastically simplify the code necessary to make sure the AI behaved logically.
So, figuring out what was limited in my system enabled great structural improvement, and restructuring my code based on the demands of the system offers great power. Sometimes it’s more effective to spend time learning and considering options than continuing to slog away, coding.
May you build the ultimate giant robot.
*Detailed in the book Game Mechanics: Advance Game Design by Ernest Adams and Joris Dormans