Microsoft MakeCode

How to test when player is over a certain type of tile?

ok for my marble game, there’s holes in the map, when the ball overlaps the hole…game over!
but im struggling with how to get the logic for either “make these tiles enemy type” OR “place enemy on top of the array of these tiles” OR “test player overlap tile type”

this would be handy for creating adventure maps that have treasure/warpzones/etc? im sure its possible somehow but its been 20 minutes of prodding and i cant figure it out :smiley:

code in question

1 Like

So we have a pretty good way to handle ‘place enemies on these tiles’ that I added a while back and used in the Jumpy Platformer example a lot. Here’s a shorter example: https://makecode.com/_icoiC94WEV8d

Basically, you want to:

  1. Use array of all {color} tiles from the scene category to get all the orange (in your case, hole) tiles
  2. Iterate over those tiles with the for loop
  3. Create a new sprite for the thing to place (e.g. coins, or the holes for you)
  4. Place them ontop of the tile in each iteration of the loop with on top of {myTile} place {mySprite}

This can be pared down to just the loop without the extra temp variables depending on what you need to store / change: https://makecode.com/_6zT36tHWaMyJ

I think I’ll add another tutorial to the Game Design Concepts to show this approach off a bit more clearly, as it’s fairly useful but not something that would be obvious to do - maybe making a forest and use the tiles to create a path of breadcrumb sprites :slight_smile:

1 Like

thanks - i can do that.
i do sorta feel like this blockset should do the same, perhaps if the type of the first item is a list it can do the iteration for ya?
image

In the current form of Static TypeScript that is used in PXT, functions can’t be overloaded. So, the same function cannot accept two different types for its parameters.

That’s not quite true, as we can use some of the more advanced features of typescript to allow arbitrary type combinations; for example, function placeThings(tile: tiles.Tile | tiles.Tile[]) { } would accept either a tile or a tile array, and then you can use a instanceOf b to disambiguate whether tile is a tile or an array:

That said, I’m a tiny bit hesitant on the idea here for a few reasons; one, it would make a weird semantic difference between the two (the implication would be that if you place on a single tile it would place that sprite where you want, but if you place on a tile array it would have to clone the sprite and place it on each tile - then what happens to the original sprite? We don’t have any other cases where a sprite is duplicated without the user duplicating it manually).

I think I would personally lean towards specifying tile and sprite on the block itself (on top of tile {hole} place sprite {holeSprite}) to make it a bit more clear, and consider a different approach as a different block as this one just goes to a method on the tile class

2 Likes

im up for whatever, just that manually iterating with a loop seems un-makecode-y :slight_smile: being able to place enemies/treasure with the tilemap would be good!

Oh that’s interesting, @jwunderl. I don’t remember when I wanted to do a function overload (it was in one of the internal functions for one of my extensions), but I’ll have to remember that syntax in the future. I’m with you, though: For the Blocks environment, these two implementations should be two different blocks.

1 Like

I’d like to ask for something else, if I may: it’s not always practical to create a sprite for every type of a tile; for instance, in a game that has a lot of water and a lot of land, detecting whether you’re flying over land would be very silly to create a sprite for every land tile.

So I’d like to return to the original question, and ask ‘how can I detect what type of tile is at position X,Y [or underneath an existing sprite’s position, or whatever)?’

It would be perfectly acceptable, for my purposes, to be able to enquire of the tile map what tile is at a given position - we have a block to acquire the tile at the co-ordinates, we just can’t tell anything about it at all. Even if we had access to the colour index and could compare it to something else, that would be absolutely fine.

…and I’ve just found I can hack this by reading myTile.tileSet, which is an integer, and using that as a colour index. In case anyone else needs it.

1 Like

Yup, the .tileSet is property of the tile object you want (I wouldn’t really call it a hack necessarily as it was written exactly for that purpose, it’s just a part of the typescript API that doesn’t currently have a block associated with it).

Ah! I used the word ‘hack’ because I couldn’t find any reference to it anywhere, so didn’t know if it was an internal variable I’d lucked onto or not :slight_smile:

I’m deeply pleased you included it though - thank you!

1 Like