It is a bit early for a postmortem – the game is not really complete and we haven’t released it to the public yet. But the majority of the code is done and I didn’t want to wait to capture both the things that worked well and poorly.
I’ve also been catching up on blogging about my programming projects. I’ve retroactively posted some entries to the date when I did the work. Since that makes it really hard to spot new content, here are links if you are interested:
What worked
The Move/Ability/Action Point system worked very well. All player actions are a Move, and each Move uses some number of Action Points that build up over time. How many Action Points a Move takes, and whether a player can perform a given Move is determined by the Ability system. Each player has a set of Abilities. We ended up making the Abilities fairly fine grained. So there is not just a “walk” ability. It is actually broken down to walk, walk with victim, walk with item, walk into fire, etc. Each player can start with a different set of abilities to make different characters, and players can gain or lose abilities during the game. This can handle equipment or player upgrades.
The real time Timeline also worked well. Scheduling Moves for a future time was a convenient way to have things happen in the game. It allowed for scripting of events and for Moves to schedule other Moves. This allowed the Moves to be more atomic which prevented code duplication. It also allowed a fairly easy way to animate some of the Moves.
Using websockets and a dumb client for the web page controls: The websocket connection is fast and reliable. We aren’t seeing much lag on our local network, even with 6 players connected at once. Having a dumb web client (all player state and move options are sent to the client) makes it easy to handle phone/connection issues. We have rare instances of someone being disconnected from the game, but all they have to do is re-load the page.
What didn’t work
The biggest problem was our method for connecting the C++ source code to the script. We have traditionally kept any GUI code in the script and game logic in the C++. This worked fairly well, but we decided that the interface between script and code would be function calls back and forth. This was more work than if we had made the C++ model classes derive from ScriptObject. This would have allowed the script to use some of the C++ model directly.
Another problem was keeping the human players separate from the fire fighters they are controlling in the code. This made the disconnect/reconnect code more complicated than necessary.
Finally, we are having a problem with the multiple inputs to the calculation of the action point cost of certain actions. We wanted the model to be fairly flexible, so to determine the cost to walk between two spaces requires input from both the fireman (what abilities do they have, are they carrying stuff) and the board (is there fire on the space, are you going up stairs). Making the abilities more fine-grained helped with this problem, but there is still quite a bit of ugly code that needs revisited before the next game using this system.
One thought on “Fire Platoon postmortem”