A student's Eureka Moment with game state analysis

I was in the studio the other day with a student working on redesigning part of the gameplay implementation on this semester's immersive learning project. Incidentally, it's been an amazing semester for this team, but I've had other writing tasks eat up the time I would otherwise have been blogging about it. In any case, he told me that he had a solution in mind that would require using two booleans. I stopped him and pointed out that once we have more than one boolean, we need clearly enumerated states. This is good practice generally and it is also a rule in the Gamemakin UE4 Style Guide that we're following.

I took the student over to the whiteboard and we began analyzing the interactions involved, resulting in this diagram:

We talked through a few scenarios. When I was convinced that he understood the analysis, we went back to the workstation and I showed him how to create an enumerated type with three values. Then, we went into Blueprint and looked at the events. I demonstrated how we could switch on the new enumeration that we had defined and use that to encode the logic from the diagram on the whiteboard. At first he was kind of quiet and seemed to be thinking about the problem at the source code level. Then, around the time we added the logic of the second trigger, he spun around and proclaimed something like, "Oh! That diagram becomes the code!" It was a wonderful example of that eureka moment when the pieces click and, as a result, he became a more powerful developer. Now he has a new tool in his toolbelt, and I can work with him to understand how to recognize when the problem affords using such a tool.