The tutorial developed a single enemy type, working up from a simple asteroid you could shoot once to kill, to one that took multiple hits, to one that spawned smaller bits on defeat. I imagined creating multiple types of asteroids and perhaps even other kinds of enemies, but didn’t want to duplicate my code each time.
GameMaker did allow for class inheritance at this point, though the tutorial didn’t discuss it. I wanted to see if I could figure out how to achieve it on my own, and had gratifying results. I could now make my enemies’ stats and sprites data-driven (or at least, start them out that way)! This would eventually lead to a deeper line of inheritance as I tried to unify more and more, eventually reaching
2021-10-05 1:22 PM Let’s see if we can implement a
2021-10-06 12:13 AM I totally did it. I now have an
obj_base_enemy that has all of the core asteroid behaviours, a script containing a constructor for the variables that could set those asteroid types apart, and then a series of global variables set which use the constructor to create a data “struct” (hash) with all those type-specific variables.
At the beginning of any asteroid create event (which inherits from
obj_base_enemy), I set
enemy to the type of asteroid, and then inherit the parent, which is expecting
enemy in order to function.
And it worked on the first try! I’ve replaced my large and small asteroids with new ones that follow this pattern, and it works beautifully! I can now EASILY add new enemy types!
… But, I’m thinking just literally creating the enemy hash, rather than using the constructor might be easier for future readability, even though it means I won’t be able to type my parameters. It’s a hassle to figure out what the sequence of inputs refers to.
2021-10-06 12:41 AM … So I did. All still works nicely. Bedtime.