December was a busy month for KeyRunner, and today I have a new release to make.
The two topics of r3 were Conveyor Belts and Push-Hold player movement. Both features were quite challenging to implement.
One challenge was developing the logic for determining the destination tile. After trying several strategies, I ended up with something I liked. Assume that the player is currently standing on a conveyor belt tile:
Often new features in software require some 'hidden work'. In the case of Conveyor Belts, Animation support was the hidden work. KR's animation functionality uses several points of data:
With these points of data, KeyRunner is able to animate each tile of a conveyor belt. If you play KeyRunner, you'll notice that each belt's tiles are 'synchronized'. Each tile is started in staggered order which creates the illusion of a single seamless animation, even though each tile is animating independently!
Push-hold movement was tweaky. I found that it was difficult to get it 'just right'. If I made it too responsive, Moschata would fly past keys and locks and everything else before the player or game would have time to react. If I made it too sluggish, the time clock would run down before levels could be beaten. What's more is that I wanted rapid key pressing to continue working correctly as in prior releases. Some levels are best solved by rapidly mashing the arrow keys.
I ended up providing support for both Push-Hold and Rapid-Fire movement. Push-Hold had a few caveats:
Both features were difficult work, but they seem fairly robust.
Key Runner is coming along very well, but has a problem which must be overcome: difficulty. The first time you play, it's much too difficult. But once you've played each level 100 times like I have, it's incredibly simple. The next release will add different difficulty levels. It will also add score and a system to help new players frantically muddle through levels they've never encountered while the clock ticks down.
Download KeyRunner r3 at http://killergame.net/keyrunner.
The two topics of r3 were Conveyor Belts and Push-Hold player movement. Both features were quite challenging to implement.
One challenge was developing the logic for determining the destination tile. After trying several strategies, I ended up with something I liked. Assume that the player is currently standing on a conveyor belt tile:
- Check the tile in the direction of the current conveyor tile.
- If that tile is a conveyor tile (and not the tile which led to the player's tile), use that as the destination.
- If that tile is not a wall, but is a non-conveyor tile, consider it a second place option.
- Move to the next adjacent tile clockwise from the current tile being checked. Repeat for all adjacent tiles.
- If there were a suitable conveyor tile, it would have been decided upon by now.
- Is there a second place option? If so, select it as the destination.
- Otherwise, the destination tile must be the player's current tile.
Often new features in software require some 'hidden work'. In the case of Conveyor Belts, Animation support was the hidden work. KR's animation functionality uses several points of data:
- Sprite Sheet - a bitmap containing each animation still.
- Still Dimension - a height and width pair indicating the size of the still
- Still Sequence - an ordered list of x and y pairs indicating the placement of each animaiton's stills in the spritesheet and the display order of these stills.
- Stills Per Second - a number indicating the rate at which to change the current displayed still
With these points of data, KeyRunner is able to animate each tile of a conveyor belt. If you play KeyRunner, you'll notice that each belt's tiles are 'synchronized'. Each tile is started in staggered order which creates the illusion of a single seamless animation, even though each tile is animating independently!
Push-hold movement was tweaky. I found that it was difficult to get it 'just right'. If I made it too responsive, Moschata would fly past keys and locks and everything else before the player or game would have time to react. If I made it too sluggish, the time clock would run down before levels could be beaten. What's more is that I wanted rapid key pressing to continue working correctly as in prior releases. Some levels are best solved by rapidly mashing the arrow keys.
I ended up providing support for both Push-Hold and Rapid-Fire movement. Push-Hold had a few caveats:
- Push-Hold moves at a rate of 10 tiles per second. That's a little faster than you can Rapid-Fire on your keyboard.
- Push-Hold is initialized by holding down an arrow key for ~200ms
- Once in Push-Hold movement mode, you can change directions at any time by pressing another arrow key and releasing the current key.
- Push-Hold movement is interrupted when Moschata runs into a wall or a teleporter pad.
- Push-Hold movement is accelerated further when on a conveyor belt.
Both features were difficult work, but they seem fairly robust.
Key Runner is coming along very well, but has a problem which must be overcome: difficulty. The first time you play, it's much too difficult. But once you've played each level 100 times like I have, it's incredibly simple. The next release will add different difficulty levels. It will also add score and a system to help new players frantically muddle through levels they've never encountered while the clock ticks down.
Download KeyRunner r3 at http://killergame.net/keyrunner.
