Scripting on Pit Boss: Learning AI Behavior Trees the Hard Way

Now that we are most of the way through development, it seems like a good time to reflect on all the ways I did an awful job planning out the scripts for Pit Boss! While there are some major successes in the game, one of the most divisive for me in self critique is the NPC AI ecosystem. Conceptually, very cool and something I'm happy I took the time to attempt. Practically? Oh WOW was this a nightmare.

Out the gate, we wanted an npc system that would be able to handle a large number of AI agents to fill our virtual casino. Each of these NPCs would have individual names, textures/models, and be able to carry out some basic behaviors like movement. While these were largely able to be accomplished with some minor bugs and consolations, by far the biggest error in planning was not drawing out the behavior tree first, especially in regard to having NPCs interact at poker tables. In the current implementation, NPCs and Game Tables are 2 classes that hold a LOT of information, as well as individual functions regarding updating stats and changing goals. 

While hindsight is 20/20, it wasn't until late in development when I needed to code players leaving a poker table. While it was simple to make the character physically move from the table, the problem of removing the NPC data from the table while updating both the table, NPC, and worldstate data is atrociously complicated. First, we need to find which player needs to leave the table, then find that NPC in both the worldstate list and the game table "Current Players" list, which I did not consider weren't actually storing the same data but rather copies of the NPC data. This made accessing and updating all three at once impossible, and meant that changes to one would not affect any of the other stored methods. Next, the functions for both NPCs and Game Tables were defragmented in an awkward way, which meant that I often would have functions in the NPC scripts that would have to call functions in the Game Table scripts (and vice versa) back and forth in a game of scripting ping pong. This has prevented me from properly updating the game tables in order to keep the appearance of functionality present in the beta build, and hopefully will be able to be resolved before final.

Should I make another AI system again, centralizing and properly organizing hierarchy would be my first change. If I had make a proper diagram of where these systems would communicate, how to store relevant information and avoid double storage and copies, as well as oriented levels of accessibility for the information in each of these systems, this player leave problem would be MUCH easier to resolve. Having a map to reference these hierarchies as well would make it tremendously easier to follow the system and avoid the backtracking currently necessary for resolving these issues.

Overall, the rest of scripting is going well despite some bugs and this has been an excellent learning experience for a first time working with an AI system like this. Onward and upward!

-Dan