This week may have been my most productive of the year. I simply put in more time than I normally do – 12 hours last weekend and another 6 the rest of the week. I really want to get this demo done!
- Potions fully working. A number of issues were fixed – inconsistent and incorrect behavior, missing configuration data, missing corresponding liquid palettes and puddle objects. I finalized how potions are used. Throwing a potion at an enemy has the same effect as if the enemy drank the potion. Throwing a potion at the ground will create a puddle containing the liquid from the potion. Combining an empty vial with a puddle will create a potion of the puddle’s liquid type. Potions that don’t act in this manner, such as the Fire Potion (starts a fire when thrown) and Poisonous Gas Potion (creates a poisonous gas cloud when thrown) were removed. The effects of these potions will now be produced in other ways. Sadly, I had to remove the Invisibility Potion; it was going to take a lot of effort to properly implement it for enemies. I’ll add it back after the demo is done.
- Saving/loading/level transition bugs fixed. The biggest problem was that inventory and Quick Switch Slots were changing when moving to a different level. In hindsight, this should have been easy to figure out, but I was chasing red herrings. Each map JSON file stores the player’s data along with every other actor’s data. When revisiting a level, the player’s inventory was reset to the state it was in when the level was last exited. To fix this, I saved the player’s data to a separate file and, after loading a map file, replaced the player data from the map with the player data from the player data file. Another bug was that I never serialized player cell visibility. This caused the automap to reset when loading a game.
- Removed the pixel-based lighting system. I decided to remove the lighting asset I installed a couple of years ago because it will take me more time to fix the existing issues with it than it will take to add a grid-based system.
- Priority kill combat applied to Charge ability. Last week’s change to prevent enemies from attacking if they are killed by the player in the same turn didn’t affect the Charge ability. Actions are composed of ActionSteps. The priority kill change was implemented by modifying the MeleeAttackActionStep to determine the impact of an attack when the action starts. The Charge ability contains the MeleeAttackActionStep, but this step is preceded by a MoveActionStep that causes the player to charge at an enemy and delays the attack determination. I extracted the attack determination into a new ActionStep to fix this issue.
- Fixed AI issues. Enemies, especially lately, would sometimes inexplicably not pursue the player when the player appeared or stop pursuing the player when the player was just a few cells away. There were two reasons for this: 1) a bug in the grid traversal line of sight algorithm that prevented the enemy from seeing the player when the player clearly should have been in the enemy’s field of vision and 2) in game events involving the player and another entity, the AI logic that determined which event to react to only considered the other entity (the target entity). An example of the second reason is the player (the causing entity) destroying a stalagmite (the target entity). In this example, only the stalagmite was considered. Since the stalagmite was of no interest to the enemy, the enemy would react to a different game event. By considering both the causing and target entities in a game event, the enemy can properly prioritize events.
- Fixed duplicate log messages. Recently, some messages began appearing twice in the on-screen message log. The source was easy to find – now that sound observations are being generated in addition to sight observations, a message is written for each observation. Determining the solution was also simple. Log messages needed to be associated with the game event that generated the observations, and, when there were multiple observations for an event, a single observation needed to be chosen. The change was unexpectedly difficult because it involved reworking a winding path of methods and events.
- The player now starts with one ability point. Sometimes the player finds an ability book before advancing to level 2. When this occurs, the joy of finding the first book is quickly replaced with the disappointment of not being able to use it. My solution to this was to give the player one starting ability point to spend.
- Miscellaneous bug fixes.
Demo progress:
Thrown potion bugs.Save/load and level transition bugs.5 miscellaneous minor bugs.- Lighting bugs/refinement and deciding whether to use grid-based lighting.
- One more optimization pass.
- Beat the demo.
Next week, I plan on completing the remaining three bullets for the demo.