- Project page
- Tutorial[1]
- Repo[2]
Part 6 adds bumping into enemies.
The Python tutorial uses class hierarchies with BaseAI and BaseComponent base classes. I’m instead using columns with optional values, and I added a way to query for optional fields in the Table class. They put the logic into the classes; I have the logic in top level functions.
This week I started wondering if my Table structure would even work for this project.
I wanted to have the Fighter component with (hp, max_hp, power, defense) just like the tutorial. But (max_hp, power, defense) are static properties. They can go in the prototype, and an entity inherits from the prototype. But (hp) is a dynamic property. It should be per entity. I don’t have a way to do inheritance per column, so I ended up splitting this into two columns. One is (hp) alone and one is (max_hp, power, defense) that will be shared. Until I split these, I had a bug in the code where combat on one enemy would affect the hp of all the other enemies. I made the static properties read-only to avoid future bugs like this.
The AI component is even worse, because (looking ahead) I’m going to need a stack of values, not just one. And that means I have an array of objects, which my Table class doesn’t fully support. I’m getting away with it because I neither index nor query this column, but I may need to do another round of Table class improvements to support the AI column.
I decided the enemies can just walk towards the player instead of running A* pathfinding. Since they only act when they’re in line of sight, I think this is almost as good.
My index.js is getting a little messy but I will organize it later. I find that I am not smart enough to organize code early on. My premature organization is often the wrong organization. I make better decisions once I have more things to organize, and that means sometimes I will temporarily have a mess.
The Python tutorial assumes that all blocking entities are actors, but I’ll try to distinguish these cases.
The Python tutorial handles death by changing the event handler. There will be multiple event handlers in the future for things like UI elements (menus, dialog boxes, etc.). I plan to make the UI elements HTML instead of <canvas>. I decided not to make a new event handler yet. I’ll wait until I have more before deciding on the structure. Sometimes I need to have three instances of something (in this case, event handlers) before I can figure out the best abstraction.
See https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)[3]
(Spoiler: I figured out a structure I like during Part 8)
Here’s the game at the end of Part 6: