Home Creators Posts Import Register Favorites Logout

Content

Following up on the latest feature in the previous blog post; the improved stairs system.

My prototype system for stairs was a relatively simple one - with only 2 main objects (the top & bottom entry points). Instead of treating stairs like a physical object, players would instead enter the "on stairs" state, only allowing them to move diagonally. That is how the original CV games did it, but can't work if we want players to land ON stairs after a jump. So we created a new object [o_stairs_mid] and placed one at each tile of the entire staircase.

The problem with this solution is that it requires I hand place every single step for every single staircase in every single room. It is extremely prone to user error, and if I wanted to move any of the staircases, I'd have to move EVERY single step. That's annoying.

So I've decided to automate the process, though this was a bit tricky.

My initial plan was to have [o_stairs_mid] duplicate on creation until it meets [o_stairs_top], but GameMaker wouldn't allow this because it could result in an infinite loop...

So I came up with another solution; involving measuring the desired length of each staircase to automatically create the amount of steps needed between both entry points.

---

But this was still tricky... [o_stairs_bottom] needs to find the EXACT [o_stairs_top] I wanted. Using a collision_line to detect the top entry could still choose incorrect instances, such as:

Instances at the same X coordinate as my desired instance (like right next to it).

Instances above my desired Instance, but still along the collision line.

So here's what I'm ultimately doing: send out a collision line, save a list of every single entry the line touches, then filter out any instances that have a different direction (image_xscale), then loop through that list of entries, and select the closest instance.

Once I've found the closest instance, I measure the distance between the two entries in tiles, then [o_stairs_bottom] will create [o_stairs_mid] along the line until they meet [o_stairs_top]. Now, I only need to hand-place the entries and the engine will handle the rest on its own.

---

Oh, and I've added a slide ability.

This is a feature I've planned to include since the early prototype, but its inclusion was never essential, so I never spent time to include it. When the player starts sliding, they get a sudden burst of speed, and they decelerate over time.

I thought about making it identical to Mega Man's slide, but worried it would be too fast that too many people would prefer it over walking. That slide also would make it easier to die too...

I still need to create original art for it.

---

I hope everything works as intended. I have a nearly complete basic movement system, assuming I don't do extra stuff like wall jumps or back flips.

I'm noticing an issue with sprite warping (presumably due to sub pixel movement) and my old smooth camera system doesn't fix it (but it still works perfectly in my prototype even after it has been converted into the latest version of Gamemaker). So I might need to create a new camera system or find out why it's happening.

---

Don't forget to eat & sleep.

Files

Comments

Ethan Moreno

You explaining how you measured the distance between each staircase makes me think of how you would find the area in a graph using limits. Also, I didn't think you would have a need for a camera system in your game, but that makes sense if the model starts to blur out a bit.

D

Always enjoy these updates, neat to read through the process of making new features

John Harris

This is a case where implementation was arguably easier in the original games. Gamemaker lets you place objects on arbitrary pixel locations, but games at the time of Castlevania all used tilemaps. It's a lot easier to check for the precise location of an object if it has to be contained in a space on a grid than if it could be on any pixel location in a room.