A few days ago I got the elevators moving by simply counting an offset if the elevator sprite becomes visible. While rewriting and rethinking a few core concepts of my game engine and how things work I almost fell for the same trap as before!!! Putting code into the wrong places!! 
Right now the visibility of the elevator sprite is done inside the players "collision detection system" (if you can even call it that!) This was fine to actually see the elevator move and hack in some more bits to make it go up and down. An awesome moment by the way! But I knew it was a temporary solution and it had to be implemented in a more robust and universal way. Not focused on this single elevator at the spot in the level that I was looking at...but for all of them!
After fighting with the compiler over some of the names in the struct...hard to explain and no idea what is causing it (but I found a workaround)....I got some of the event configuration loaded for the individual elevators. Meaning mostly their speed at the moment as I have not gotten around to the other parameters just yet. Without going into enormous detail of how I implemented the events in my game engine...lets just say that each of them as their x,y location in tiles(multiply by 32 pixels), the config struct (32bits), 4 misc integers and 4 misc floats. This was my primitive attempt to make things appear to work!
What I am now considering is actually using the eventmap from the game files only as a "guide" to how and where objects and events are placed. And not keeping the internal structure of the gamefiles as a limitation after they have been loaded! This might mean that instead of one big array containing ALL events and their config...I will have multiple array's. One for each type of event that only has variables it really needs. For example the one-way-laser-passtrhough-platforms have an event block that is just 32x32 pixels in size and placed in a 2x4 (I think) grid to make the one-way platform work the way it does. That you can stand on top and jump through from below. But for this it needs no status information like an elevator does. So it's actually wasting a little bit of memory. Not a lot...but it's there. But besides the "wasted memory" the problem is more that those "misc" variables are starting to become a limiting factor! Sometimes I need more...sometimes I need none! But while developing the game for powerful systems....meaning not something like the DSi or GBA....I don't think increasing the number of "misc" variables is going to hurt so much. It's all about making it work first...right?
The other issue I am running into is how to detect the end of the elevators track. Visually it seems simple right? There is just an end stop and it can't go further! Right? Well....yes and no! It's true that in the original this is how it works, and any game with similar moving platforms on a track will make it look this is the case. But in the background it's the game engine that needs to make this happen! There is no limitation on the sprite to run of the track...and it actually does right now since I only gave it fixed offsets to go up and down. The one's that are "correct" for the first elevator in the puzzle you encounter.
The end-stops actually do have a separate event in the eventmap placed on the elevator track. I made them visible with the magenta block in my last post's video. But other than drawing that block this "event" does nothing at the moment. It does have a configuration value "trigger_id" which should be the same as the elevator's "trigger_id" but I didn't check that yet. I'll just assume that it is for now because that makes the most sense!
What I think happens in the original is that a "trigger_id" is activated with a battery holder. This battery holder has a specified time period after which it deactivates the "trigger_id". At least that is what I think it does. Then all the elevator needs to know for movement is "is my trigger active? Yes? Then we move!" and then when it hits an end-stop it checks again and decreases it's moves counter. When the either the trigger_id of deactivated or the moves goes to zero...it stops. Not sure if this is really the logic behind the original game....but this is basically what I have planned for it now.
But as I said the "end-stops" don't do anything yet, but they should do collision detection not related to the player itself. And when hit the behavior of the elevator should change. If I implement it in a way that the end-stop detects from which side the elevator enters, and it remembers until it's clear, then I can use that to slow the elevator down and change direction. my observation is the original does a nearly instant change in direction but I don't like that. So here I take a bit of my own and add it in. It will visibly slow down...and then increase it's speed slightly faster. That's the easy part....whats more difficult is how to actually implement this!
My original idea was to search for an endstop both below and above the elevator in the eventmap...and keep those offsets in those "misc" variables I talked about. While that could work...it also resulted in an issue with not having enough of those variables. or not enough of the correct type. I was thinking of adding 16bit integer misc's as well....further increasing the wasted memory on events that do not even need any variables! What I might end up doing instead is add a new array for the trigger_id's and put the misc variables in there instead. Or use a combination of them...I really don't know yet.
Sorry it got this long, and that it probably is a bunch of random thoughts. Just needed to get them out of my head again.
Right now the visibility of the elevator sprite is done inside the players "collision detection system" (if you can even call it that!) This was fine to actually see the elevator move and hack in some more bits to make it go up and down. An awesome moment by the way!
But I knew it was a temporary solution and it had to be implemented in a more robust and universal way. Not focused on this single elevator at the spot in the level that I was looking at...but for all of them!After fighting with the compiler over some of the names in the struct...hard to explain and no idea what is causing it (but I found a workaround)....I got some of the event configuration loaded for the individual elevators. Meaning mostly their speed at the moment as I have not gotten around to the other parameters just yet. Without going into enormous detail of how I implemented the events in my game engine...lets just say that each of them as their x,y location in tiles(multiply by 32 pixels), the config struct (32bits), 4 misc integers and 4 misc floats. This was my primitive attempt to make things appear to work!
What I am now considering is actually using the eventmap from the game files only as a "guide" to how and where objects and events are placed. And not keeping the internal structure of the gamefiles as a limitation after they have been loaded! This might mean that instead of one big array containing ALL events and their config...I will have multiple array's. One for each type of event that only has variables it really needs. For example the one-way-laser-passtrhough-platforms have an event block that is just 32x32 pixels in size and placed in a 2x4 (I think) grid to make the one-way platform work the way it does. That you can stand on top and jump through from below. But for this it needs no status information like an elevator does. So it's actually wasting a little bit of memory. Not a lot...but it's there. But besides the "wasted memory" the problem is more that those "misc" variables are starting to become a limiting factor! Sometimes I need more...sometimes I need none! But while developing the game for powerful systems....meaning not something like the DSi or GBA....I don't think increasing the number of "misc" variables is going to hurt so much. It's all about making it work first...right?
The other issue I am running into is how to detect the end of the elevators track. Visually it seems simple right? There is just an end stop and it can't go further! Right? Well....yes and no! It's true that in the original this is how it works, and any game with similar moving platforms on a track will make it look this is the case. But in the background it's the game engine that needs to make this happen! There is no limitation on the sprite to run of the track...and it actually does right now since I only gave it fixed offsets to go up and down. The one's that are "correct" for the first elevator in the puzzle you encounter.
The end-stops actually do have a separate event in the eventmap placed on the elevator track. I made them visible with the magenta block in my last post's video. But other than drawing that block this "event" does nothing at the moment. It does have a configuration value "trigger_id" which should be the same as the elevator's "trigger_id" but I didn't check that yet. I'll just assume that it is for now because that makes the most sense!
What I think happens in the original is that a "trigger_id" is activated with a battery holder. This battery holder has a specified time period after which it deactivates the "trigger_id". At least that is what I think it does. Then all the elevator needs to know for movement is "is my trigger active? Yes? Then we move!" and then when it hits an end-stop it checks again and decreases it's moves counter. When the either the trigger_id of deactivated or the moves goes to zero...it stops. Not sure if this is really the logic behind the original game....but this is basically what I have planned for it now.
But as I said the "end-stops" don't do anything yet, but they should do collision detection not related to the player itself. And when hit the behavior of the elevator should change. If I implement it in a way that the end-stop detects from which side the elevator enters, and it remembers until it's clear, then I can use that to slow the elevator down and change direction. my observation is the original does a nearly instant change in direction but I don't like that. So here I take a bit of my own and add it in. It will visibly slow down...and then increase it's speed slightly faster. That's the easy part....whats more difficult is how to actually implement this!
My original idea was to search for an endstop both below and above the elevator in the eventmap...and keep those offsets in those "misc" variables I talked about. While that could work...it also resulted in an issue with not having enough of those variables. or not enough of the correct type. I was thinking of adding 16bit integer misc's as well....further increasing the wasted memory on events that do not even need any variables! What I might end up doing instead is add a new array for the trigger_id's and put the misc variables in there instead. Or use a combination of them...I really don't know yet.
Sorry it got this long, and that it probably is a bunch of random thoughts. Just needed to get them out of my head again.
