derekfountain / zxwonkyonekey

A game for the ZX Spectrum, written in C
4 stars 1 forks source link

Door on third level #12

Closed derekfountain closed 6 years ago

derekfountain commented 6 years ago

Levels 0 and 1 are done, nearly time for level 2. What to introduce?

I'm thinking about an animated door, which opens to give access to the exit point. This door should close a few seconds after triggering its opening, so it'll require a timer and a magic trigger point, or something.

Level 2 can have a sequence of, say, 5 of these?

There's no killing, and no way to reset the level, so it all has to reset somehow to stop the player getting permanently stuck.

derekfountain commented 6 years ago

Some thoughts:

The idea here is that there's a door, which is a single cell solid block, which animates vertically, raising to open, falling to close. A switch point somewhere in the level triggers it opening and it falls on a timer. If the runner is underneath the door when the timer expires he's considered to be through it. Once he's passed through a door the switch disappears and the door remains permanently open. This solves the issue of resetting/getting stuck.

A door requires a switch point which I can copy from teleporters or slowdown pills. This is looking like a generic-isation of that code. The door end itself needs a range: y,8-x-pixels. If any part of the runner is inside that range then he's under the door and the door can't close. When the door is closed (or part closed) the attribute for the cell needs to be set to non-background, in which case the collision detection will stop the runner going through it.

The switch needs an animated graphic like the slowdown pill. A key would be a bit cliché but is the simplest graphical cue. I like the idea of having a key the same colour as the door, but I don't think that would work - if the key isn't the same colour as the runner the collision code will see him bounce off it. It might be possible to flicker the door and key when he's not near them, but maybe that thought comes later.

So, gameloop checks the runner's position against the array of door switches in the level. If he's on one, animate the door opening. Once the animation finishes change the door's cell attribute to background so he can pass through it, then start a timer. Each loop, check his position against the range of x pixels covered by the door. It'll be

spritey == doory && spritex+spritewidth>=doorx && spritex<=doory

which means he's under the door. Once he's under the door flag it as open. Stop the timer, don't restore the switch.

If he's not under the door reduce the timer. If it gets to zero change the door's cell attribute to block it and start the animation to close the door.

The cell above the door will need to be solid platform so it can be set to permanently valid. The door graphic is then a simple sprite placed at decreasing y coordinates for the animation. The effect will be that the door appears to open into the block above it.

I'd expect the door to open/close in about half a second, so 8 pixels in 500ms is about 1 pixel every 60 milliseconds. The key animation can be 3 frames handled by the same code as the slowdown pill animator.

derekfountain commented 6 years ago

Doors work fine.