For a maze implemented with a tile map where the paths are the same size as the sprite there’s some unpredictable behaviour with trying to move the sprite down turnings. I’ve demonstrated this in this video (animated gif). A lot of the time I can make the turn by holding down the turn direction key and walking past it (effectively using a diagonal) but this doesn’t always work and sometimes many attempts fail. When I’m having trouble manoeuvring I press
A to indicate this with
Denied! message. This is the beta beta simulator (
Watching the D-pad closely reveals which keys I am pressing in the simulator.
Here’s the code:
I expanded the
move with buttons block to show the default speed. I tried that at
40,40 and it appeared to improve the ability to navigate around the maze which suggests the discrete nature of the movement may be causing this. I don’t know if this is a bug or a feature but it’s certainly a potential cause of frustrating gameplay and difficult to explain to novice programmers.
What’s the best workaround here? Reduce the size of the player sprite slightly?
@tballmsft is working on extending the controller blocks specifically for this scenario. Essentially the sprite always moves to the middle of the tile by itself.
BTW maybe it’s obvious but making the sprite slightly smaller will likely improve things.
There definitely are issues with pixel level collision detection and tile-based layout, which can probably be resolved by reducing sprite size. I am working on a simpler scheme for tile-based movement that should be ready in a week or so.
Thanks. I’m happy to do some testing when this is deployed.
On the subject of tiles, is there a way to list the tile(s) underneath a sprite in Blocks?
Not currently, but what’s the case you’d be using it for? To check collisions with non-wall tiles?
I was thinking about using the tile map to spread out (many) food elements, in that case, I’d want to use a non-wall tile collision to check for the player eating food.
If there a better way to do this ?
I’d create them as sprites on top of tiles - there’s a block for getting all tiles of a given tile, so use that in a for each loop to place one food sprite on each tile, then just check sprite collisions with that. I’m on my phone, but I’ll edit this with a quick example in a few. The jumpy platformer example game i wrote on the home screen uses this to spawn coins, enemies, and the player.
Edit: Made it on my phone real quick https://makecode.com/_10M5W7UKEatH
I’m also seeing what I think is the same issue with projectiles. I’d imagine most people’s projectiles are fairly small but I’ve got some absolute units at 16x16 and these disappear immediately / do not appear in a maze of the kind in the first post.
There are some definite issues/quirks with the mix of real numbers for physics and the discrete world of MakeCode Arcade’s tile maps and sprites. This example with maze navigation is frustrating and I suspect it’ll prove difficult to explain this behaviour to children.
I’ve put together some other tests which test things that are currently ok and highlight some problems with a 16x16 sprite passing a 16 wide gap slowly with acceleration toward that gap, see Physics engine tests?. Those might be useful to verify any changes made don’t alter desirable/current behaviour and to see what they do in terms of improving gap passing.
I’ll take a look at these. Many thanks!
Can you please share the program (via the Share button)?