|
I found some significant new information about how the game logic/events work so documenting it here.
first some context.
In alundra there are entities (npcs, monsters, jars, chests, dummies, anything pretty much) and these entities are the main data structure in the game, lots of state data.
entities can have attached event programs, which are created with the alundra scripting language. much of my work has been implementing function handlers for the various event commands. an entity has 6 event program slots, (load,map,tick,touch,unload,interact). so an entity can possibly have an event program in each of these slots, and it's run everytime the condition for that slot is met.
what i discovered now is there is a second set of 6 slots(load,map,tick,touch,unload,interact), but the event programs in these slots are not made up from the alundra scripting language, its like a separate event system that run code handler functions directly, not scripts.
what handler functions will run in these slots are determined by an entity's "blueprint" which is a small record that mostly just defines what kind of entity it is going to be, the sprite for that entity, and some other basic information about its dimensions and physics properties. but also there was some unknown data on there that i now know determines what is run in its second set of event slots.
so basically there is a large second event system that i didnt know about previously, and that has perhaps 100+ additional functions to implement.
fun. |
he did impressive job with this Alundra port/clone 
