Metroidvania Month 7 Day 21
I don't think I'm going to make it. I'll drop out of Metroidvania Month if I can't get anything playable by then, but I will continue to work on this game.
So, I started to get back into things by just modifying the SaveFile class. I figured that I might not want to reload the Player's Health and Ammo every time they reload the game. It would have made it very easy to cheat the game: get to a Save Room by a boss, save, refresh the page to restart the game, load the old Save Slot, and you're now at full Health and Ammo. Now the SaveFile has the hp, filledTanks, and heldMissles to keep track of the Player's Health and Ammo to help avoid that cheat.
While I was editing the SaveFile class, I also figured I should refactor the way I keep track of explored areas. My original idea was to have a new field in the SaveFile and that field would be a 2D Array for each Area. That means to set if the Player has visited a spot on the "map" for the Test Area, I would have done "saveFile.testArea[gridRow][gridColumn].visited = true". It would have done the job, but I felt it was very inefficient: I would need a switch-case statement or something to find out what Area the Player was in and which field of the SaveFile we should use to mark as visited, each time we have to mark a cell as visited. I figured it would be better if we gave each Area it's own unique ID and make a field in SaveFile called explored which is a 3D Array. So to mark a cell as visited, we use "saveFile.explored[0][gridRow][gridColumn].visited = true" where 0 is my ID for Test Area. That should take my O(N) time of searching a switch-case of N Areas for the field, and move it to an O(1) time of instantly marking a cell on our map as explored. Plus, now I can easily generate more Areas for the game by simply adding the result of a generateGrid(gridRow, gridCol) to the explored Array. Which is why I like to think of my 3D Array for explored as an Array of 2D Arrays.
Now that I'm making all these changes to SaveFile, I'm also thinking about the Player of my game needing to change their SaveFile to match the new one. What happens if they already have a SaveFile in LocalStorage and I make another structure change? How can I have the Player use a different SaveFile?
Sadly, my thought was to have them delete their current SaveFile and replace it for a new one for a "New Game". I might try to find a way to copy the old SaveFile to a new format, but I want to make sure that a Player can delete their save and start over if they choose. Now, not every Player is able to pop open the developer's console on their browser and know to type in "LocalStorage.removeItem('daemon_slot1')" to delete their SaveFile on "Slot 1". So I added some buttons to the right of each "Save Slot" to delete the SaveFile stored on that slot. It even brings up a confirmation alert when clicked, so a Player can decide to cancel deleting their SaveFile in that slot if they accidentally clicked that button.
I've been trying to figure out how I could lay stuff down in a Room. The Rooms can get pretty massive, so it would be pretty hard to lay stuff out using pixels. Plus, I want the Rooms to have a bit of uniformity to look nice. What I came up with was an idea to use two scales:
The red lines are what I call Grid Scale. Grid Scale is based on how much of a Room should equal a Cell on the mini map. I think having something like that would be useful for setting up my cellBlockers (they're what I called camBlockers in my Metroidvania Month 7 Day 4 post). Now when I start placing down walls, enemies, power-ups, doors, or whatever; then I'm going to need a smaller scale for extra precision. This is where my Tile Scale, which are the blue lines in the above diagram, comes into play. The Tile Scale should make a square for each tile; which, should make it easier for me to place objects in the room without worrying about overlap. I'll just make everything in the Room snap to one of those lines on the Tile Scale. Plus, it just makes the Room easier to design on paper if I wanted to design Rooms when I'm away from the computer. I've also noticed when I play Metroid, a lot of the blocks in a Room are laid out in a similar fashion. Samus herself also seems to fit a Title Scale as well: while standing she's about 2.5 Tiles tall, in some games she can crouch to 2 Tiles tall, and her morph ball form is 1 Tile tall. I tried to actually look up how many Tiles go to a Room in Metroid, and I found this page that explained the data for the original Metroid. It's a bit spooky how similar my Area layout idea is to the map in Metroid that was decoded by that site. I swear I just found that site today!
Anyway, that's about enough work for today. I'll continue tomorrow, if I can find the time again. Hopefully, when I return, I'll have an answer to how many Pixels should go to a Tile and how many Tiles should go to a Grid.
As always: here's the repo for Daemon, and here's the github.io page for Damon.
So, I started to get back into things by just modifying the SaveFile class. I figured that I might not want to reload the Player's Health and Ammo every time they reload the game. It would have made it very easy to cheat the game: get to a Save Room by a boss, save, refresh the page to restart the game, load the old Save Slot, and you're now at full Health and Ammo. Now the SaveFile has the hp, filledTanks, and heldMissles to keep track of the Player's Health and Ammo to help avoid that cheat.
While I was editing the SaveFile class, I also figured I should refactor the way I keep track of explored areas. My original idea was to have a new field in the SaveFile and that field would be a 2D Array for each Area. That means to set if the Player has visited a spot on the "map" for the Test Area, I would have done "saveFile.testArea[gridRow][gridColumn].visited = true". It would have done the job, but I felt it was very inefficient: I would need a switch-case statement or something to find out what Area the Player was in and which field of the SaveFile we should use to mark as visited, each time we have to mark a cell as visited. I figured it would be better if we gave each Area it's own unique ID and make a field in SaveFile called explored which is a 3D Array. So to mark a cell as visited, we use "saveFile.explored[0][gridRow][gridColumn].visited = true" where 0 is my ID for Test Area. That should take my O(N) time of searching a switch-case of N Areas for the field, and move it to an O(1) time of instantly marking a cell on our map as explored. Plus, now I can easily generate more Areas for the game by simply adding the result of a generateGrid(gridRow, gridCol) to the explored Array. Which is why I like to think of my 3D Array for explored as an Array of 2D Arrays.
Now that I'm making all these changes to SaveFile, I'm also thinking about the Player of my game needing to change their SaveFile to match the new one. What happens if they already have a SaveFile in LocalStorage and I make another structure change? How can I have the Player use a different SaveFile?
Sadly, my thought was to have them delete their current SaveFile and replace it for a new one for a "New Game". I might try to find a way to copy the old SaveFile to a new format, but I want to make sure that a Player can delete their save and start over if they choose. Now, not every Player is able to pop open the developer's console on their browser and know to type in "LocalStorage.removeItem('daemon_slot1')" to delete their SaveFile on "Slot 1". So I added some buttons to the right of each "Save Slot" to delete the SaveFile stored on that slot. It even brings up a confirmation alert when clicked, so a Player can decide to cancel deleting their SaveFile in that slot if they accidentally clicked that button.
I've been trying to figure out how I could lay stuff down in a Room. The Rooms can get pretty massive, so it would be pretty hard to lay stuff out using pixels. Plus, I want the Rooms to have a bit of uniformity to look nice. What I came up with was an idea to use two scales:
Anyway, that's about enough work for today. I'll continue tomorrow, if I can find the time again. Hopefully, when I return, I'll have an answer to how many Pixels should go to a Tile and how many Tiles should go to a Grid.
As always: here's the repo for Daemon, and here's the github.io page for Damon.
Comments
Post a Comment