Microsoft MakeCode

Grid Extension - Dev Input Requested

#1

Update: I have released this extension via GitHub. Refer to the announcement here: Grid extension

For the course that I’m writing, I’m thinking about a game similar to the Memory card game. I’m going to need to build a grid similar to that used in the Memory game found in Blocks Games or that John Park uses in his Re-MakeCode Racing Game. Since it might be a useful construct for others, I figured I’d create an extension.

The extension is basically done, but I’m looking for some input. You can find my current work here:

Use the arrow keys to move the taco around the grid. Pressing A will add columns to the grid; B will add rows.

Some thoughts that I’m pondering:

  • When switching to JavaScript, and then switching back to Blocks, the grid.drawGrid() call renders as a JavaScript block. Any ideas as to why? (Does the same in beta.) Fixed. Thanks, @riknoll!!! :smiley:
  • I’ve created moveDown(), moveLeft(), moveRight(), and moveUp() functions that you can bind to the appropriate keys. Is that a reasonable way to implement this, or should I go the route of controller.moveSprite()? If the latter, what’s the best way of going about that?
  • The indexing for the rows and columns begins at 1. Is that reasonable, or should it start with zero? I’ve switched the indexing to begin at zero per the conversation below. If you feel strongly otherwise, feel free to comment.
  • I’ve added the ability to animate the transition from one coordinate to the next as @peli suggested.
    • In the demo, when you move right or down, the taco “slides” to the next location. When you move left or up, the taco “teleports.” In addition, in the demo, the grid “wraps around,” so moving the taco off of an edge will send it to the other side of the grid.
    • The default action is to teleport. If you feel like it should be the other way around, feel free to comment.
    • How do you feel about the “slide” from, say, the right side to the left?
    • Do you think that it should jump to the opposite side instead, even if teleporting is turned off?
    • Do you think this should be a global setting (all sprites either teleport or slide), a per-sprite setting (each sprite can either teleport or slide as it moves), or a per-direction setting as currently implemented?

I’m always happy to entertain other thoughts and ideas, so feel free to share them!

Happy Monday!

1 Like
#2
  • could move the sprites smoothly between points? instead of just “teleport”, interpolate their position quickly to smooth the moves.
1 Like
#3

indexing
Starting at 0 is more consistent with arrays, pixels on screen. I would go for that.

1 Like
#4

You need to add img.fieldOptions.decompileIndirectFixedInstances="true" to the comment annotations on the declaration of grid.drawGrid() to fix the grey block.

Sorry, that one is definitely not obvious! That annotation is only required for arguments of “fixed instance” types (Image is the only one in arcade that I can remember off the top of my head).

1 Like
#5

Thanks so much, @riknoll, for that one! I’m pretty sure that shows up in some of my other extensions. I’ll have to add it to those, too.

#6

I tend to agree, @peli. The Memory game uses a base index of zero; John’s game, IIRC, uses a base index of one. Zero is more consistent with JavaScript, so the updated version (which I’ll post shortly) will switch to that. Game authors can use an index of -1 to move the sprite to the top or left edge of the screen.

#7

@AlexK this is really cool! This will be very useful, thanks so much for making it and sharing.

2 Likes
#8

Thanks so much, John! Welcome to the community!

I love your videos. Thanks so much for the incredible work and for sharing it with the world!

#9

Hi, Alex, very nice to be here, and thanks so much for the kind words!

1 Like
#10

Melody also uses fixed instances. Maybe we can simplify block syntax, now that there is more and more folks writing block extensions?

#11

To simplify it, we need to cut features that are used in other editors