DS button Shenanigans
I want to preface this article by saying it blows my mind the support that I have gotten in making this project, as well as everyone that has reached out to me to talk about dreams and dream weaving. Everyone that I have met has been absolutely wonderful and it makes me happy to be part of such a community.
Well this week not quite as much got done on the game, well not as much visually anyway. But I did get a bit done under the hood as well as come up and think quite a bit about a different technique for creating some really cool dreams. I will expand upon that after I talk about the GUI updater for The Depths.
So the GUI updater is actually really simple to do and uses concepts that I have used before to create a stable effect with the DS buttons. I used the same method as I had used in the vision code to cycle through all the active players. I had to store the names in different location this time though because I needed it to be updating even when players were not in the dungeon itself. So when it triggers each player it loads all the information from that players phoenix speak into holder variables. I wanted to use a single variable but it kept causing jumping and glitching of the buttons so I changed each one to an individual variable. I felt that this being important visually that the use of this many variables for a single task was worth it. After the data is loaded into variables all it does next is jump the button to the number stored in the variable. I am not sure if I went over this the last time but the way I make it work is just set the animation delay to 10000 ms, then every update jump it to a number. This seems to work so far without any issue.
The current source code can be found here
The next thing I want to go into is something that really got my gears going as to what is actually possible when dream weaving.
It is short so I am just going to post the code on this page.
*x600 y450 top left 00 bottom right 600 450
*when it is starting up place the button on screen and remember where it is
(0:9) When a furre arrives in the dream,
(5:15) move the triggering furre to (10,10), or to someplace nearby if it's occupied.
(5:180) show the triggering furre's DragonSpeak Button 20.
(5:182) move the triggering furre's DragonSpeak Button 20 to (0,0).
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be 0.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be 0.
*these chunks of code checks the bounds of the button to make sure it can move then moves the button in that direction increments 10
*works best if player is standing on unwalkable floor tile
(0:60) When someone moves northeast,
(1:602) and the PhoenixSpeak info {y} about the triggering furre is more than 0,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y.
(5:304) take variable %y and subtract 10 from it.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be %y.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
---------------------------------------------------------------------------------------------------------------------
(0:62) When someone moves southwest,
(1:603) and the PhoenixSpeak info {y} about the triggering furre is less than 450,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:302) take variable %y and add 10 to it.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be %y.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
---------------------------------------------------------------------------------------------------------------------
(0:61) When someone moves southeast,
(1:603) and the PhoenixSpeak info {x} about the triggering furre is less than 600,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:302) take variable %x and add 10 to it.
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be %x.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
----------------------------------------------------------------------------------------------------------------------
(0:63) When someone moves northwest,
(1:602) and the PhoenixSpeak info {x} about the triggering furre is more than 0,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:304) take variable %x and subtract 10 from it.
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be %x.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
So what I find so wonderful about this code is that with a bit of work you can make a bunch of games manipulating the position and animation of ds buttons. With this controller alone the idea opens up a bunch of classic arcade style dreams. There are even three layer standard layers to work with and higher number buttons can overlap lower number buttons, so that can be used to effect as well. Though honestly I have not thought much about that one. Another thing that I believe could be done are games like the original final fantasy and even Mario. How would you accomplish this? well that would get a bit more complicated but for starters you would need a method to store map information, most likely as numbers or letters and numbers. And you would have to keep track of where the player
was in that map. For the screen you would make a grid of buttons that will hold your graphics. I am not sure what size you would want to make them some experimentation would be needed for that. After that is all set up you would need to make code to scroll the buttons. for top down because you just move the character from box to box you would just need to scroll one grid each time. For a side scroller you would actually use a blind to block off the edge of the game screen and then literally scroll the boxes and only after they leave the screen cycle them to the other side to be loaded with the new relevant data.
I really want to work on this more and make some basic engines for people to use to make some great games within the editor. But I also have big dreams for The Depths and am focusing on that. Perhaps when the updates to the depths are less code heavy I will find some time to put some simple engines together for some basic classic game archetypes.
Well this week not quite as much got done on the game, well not as much visually anyway. But I did get a bit done under the hood as well as come up and think quite a bit about a different technique for creating some really cool dreams. I will expand upon that after I talk about the GUI updater for The Depths.
So the GUI updater is actually really simple to do and uses concepts that I have used before to create a stable effect with the DS buttons. I used the same method as I had used in the vision code to cycle through all the active players. I had to store the names in different location this time though because I needed it to be updating even when players were not in the dungeon itself. So when it triggers each player it loads all the information from that players phoenix speak into holder variables. I wanted to use a single variable but it kept causing jumping and glitching of the buttons so I changed each one to an individual variable. I felt that this being important visually that the use of this many variables for a single task was worth it. After the data is loaded into variables all it does next is jump the button to the number stored in the variable. I am not sure if I went over this the last time but the way I make it work is just set the animation delay to 10000 ms, then every update jump it to a number. This seems to work so far without any issue.
The current source code can be found here
The next thing I want to go into is something that really got my gears going as to what is actually possible when dream weaving.
It is short so I am just going to post the code on this page.
*x600 y450 top left 00 bottom right 600 450
*when it is starting up place the button on screen and remember where it is
(0:9) When a furre arrives in the dream,
(5:15) move the triggering furre to (10,10), or to someplace nearby if it's occupied.
(5:180) show the triggering furre's DragonSpeak Button 20.
(5:182) move the triggering furre's DragonSpeak Button 20 to (0,0).
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be 0.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be 0.
*these chunks of code checks the bounds of the button to make sure it can move then moves the button in that direction increments 10
*works best if player is standing on unwalkable floor tile
(0:60) When someone moves northeast,
(1:602) and the PhoenixSpeak info {y} about the triggering furre is more than 0,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y.
(5:304) take variable %y and subtract 10 from it.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be %y.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
---------------------------------------------------------------------------------------------------------------------
(0:62) When someone moves southwest,
(1:603) and the PhoenixSpeak info {y} about the triggering furre is less than 450,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:302) take variable %y and add 10 to it.
(5:600) memorize that the PhoenixSpeak info {y} about the triggering furre will now be %y.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
---------------------------------------------------------------------------------------------------------------------
(0:61) When someone moves southeast,
(1:603) and the PhoenixSpeak info {x} about the triggering furre is less than 600,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:302) take variable %x and add 10 to it.
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be %x.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
----------------------------------------------------------------------------------------------------------------------
(0:63) When someone moves northwest,
(1:602) and the PhoenixSpeak info {x} about the triggering furre is more than 0,
(5:610) remember the PhoenixSpeak info {x} about the triggering furre, and put it in variable %x.
(5:610) remember the PhoenixSpeak info {y} about the triggering furre, and put it in variable %y
(5:304) take variable %x and subtract 10 from it.
(5:600) memorize that the PhoenixSpeak info {x} about the triggering furre will now be %x.
(5:182) move the triggering furre's DragonSpeak Button 20 to (%x,%y).
So what I find so wonderful about this code is that with a bit of work you can make a bunch of games manipulating the position and animation of ds buttons. With this controller alone the idea opens up a bunch of classic arcade style dreams. There are even three layer standard layers to work with and higher number buttons can overlap lower number buttons, so that can be used to effect as well. Though honestly I have not thought much about that one. Another thing that I believe could be done are games like the original final fantasy and even Mario. How would you accomplish this? well that would get a bit more complicated but for starters you would need a method to store map information, most likely as numbers or letters and numbers. And you would have to keep track of where the player
was in that map. For the screen you would make a grid of buttons that will hold your graphics. I am not sure what size you would want to make them some experimentation would be needed for that. After that is all set up you would need to make code to scroll the buttons. for top down because you just move the character from box to box you would just need to scroll one grid each time. For a side scroller you would actually use a blind to block off the edge of the game screen and then literally scroll the boxes and only after they leave the screen cycle them to the other side to be loaded with the new relevant data.
I really want to work on this more and make some basic engines for people to use to make some great games within the editor. But I also have big dreams for The Depths and am focusing on that. Perhaps when the updates to the depths are less code heavy I will find some time to put some simple engines together for some basic classic game archetypes.
Comments
Post a Comment