Help moving characters together and overriding depth

[artitj]

I wanted to say grid-engine, and the tutorial that was written that led up to grid-engine, was great for understanding how to move on a grid in phaser. I have two questions, which hopefully I can clearly describe :).

First question: I am working on a game where you move two characters with one set of controls -- if you've ever played "Baba is you", it's a similar idea to when the level has 2 "babas" on the screen. The problem is that, if the characters ever are next to each other, one of them won't move until there's a space between them. I suppose this is because of the collision check -- on a keyboard input, I use the "move" function to move both of them. Since the neighboring tile is occupied prior to the move, it won't let one of the characters move. I tried delaying the move of one of the characters (using scene.time.delayedCall), but I need to delay by a significant amount for it to work. Any ideas on making this work?

Second question: In my game, I have the concept of a hole that a character can fall in, and then the other character can walk on over. I remove the character from grid-engine using the removeCharcter function, and this works for disabling the collision check, so I can walk over the character, but the depth isn't correct -- the character that's in the hole, which I've removed from grid-engine, still appears on top (depending on the direction that I approach). I am manually setting the depth of the sprite using setDepth, but it looks like it gets overridden by grid-engine anyway. Is there another way to override the sprite depth?

Thanks for any suggestions!

[splashsky]

For the first question, is there any way you'd be able to provide a gif of this issue happening? From all the examples we have of multiple characters moving, it's not usually an issue for characters to move in directions not towards other characters.

For the second question, you could perhaps try setting the depth of the character than can walk over the holes? I'm not sure how to address that one.

[artitj]

Here's a gif of the first question. I'm trying to get the ball to be on the tile immediately to the left of the character when walking to the right. EDIT: to clarify, it's the initial switch in direction that is problematic, I'm trying to prevent the one tile space from appearing in the first place.

Here's a gif illustrating the 2nd problem:

I'm trying to get the character to walk over the ball (which is stuck in the hole). I think grid-engine manipulates the depth of the characters so that things appear properly layered, so manually overriding it doesn't seem to have an effect :(.

[splashsky]

The first issue looks similar to the issue I currently have, as well. What's the code you're using for following?

That does look like depth sorting. You could look into the alwaysOnTop property for characters, and maybe that would fix it?

[lendsp]

about the first problem i think i would try to move using moveto and i would try to control with ismoving and maybe some more semaphore variable or maybe folow 0

about the second problem I believe that the grid increases the depth as the sprites are inserted, so you can try to insert the ones that need to be on top later.

[artitj]

Thanks again everybody for helping!

My code is a little bit convoluted from handling other things in the environment, but essentially it distills down to...

function update() {
  const cursors = this.input.keyboard.createCursorKeys();
  if (this.input.keyboard.checkDown(cursors.left, 100)) {
    this.gridEngine.move("player", "left");
    this.gridEngine.move("ball", "left");
  } else if (this.input.keyboard.checkDown(cursors.right, 100)) {
    this.gridEngine.move("player", "right");
    this.gridEngine.move("ball", "right");
  } else if (this.input.keyboard.checkDown(cursors.up, 100)) {
    this.gridEngine.move("player", "up");
    this.gridEngine.move("ball", "up");
  } else if (this.input.keyboard.checkDown(cursors.down, 100)) {
    this.gridEngine.move("player", "down");
    this.gridEngine.move("ball", "down");
  }
}

So it's not really following the player, it's that the same inputs control both the player and the ball.

@splashsky In regards to the idea of using the alwaysOnTop property, that would work except I had to make things complicated and there are actually things in the scene that I want the player sprites to appear under (such as the door way in the 2nd gif above).

@lendsp I tried to reorder how I created the sprites and added them to the scene and to grid-engine, but that didn't seem to have any effect. As for using moveTo... I may resort to that and all the associated complexity of controlling it (turning it on/off), but I'd prefer not to if possible. It looks like it might introduce some delay in the movement as well :(.

I guess I'm really trying to figure out a way to allow a character to enter a tile if the character occupying the tile will be leaving the tile, and make it look like it's happening simultaneously, but since things are happening asynchronously I'm not certain how to make that happen.

[Annoraaq]

Hi @artitj

first of all, thank you for giving us insight into your use case. It is important for us to know which problems occur in projects so we know which features make sense.

Maybe I can shed some light on the inner mechanics of grid-engine.
You seem to be mentioning two issues:

1. blocking chars
2. manual depth (zIndex)

Blocking Chars:
Grid-Engine works as follows. If a character is NOT moving, it will block the tile it is currently standing on. If it IS moving it will block both tiles: the one it is leaving and the one it is entering.

Manual Depth:
For non-isometric maps the logic is:
Every sprite that has been added to grid-engine will get a depth (zIndex) of 1000 + y-coordinate on the map. The 1000 makes sure that there are enough layers below for tilemap layers. The y-coordinate as an offset ensures that characters that are more "south" on the map will be rendered in front of characters that are more "north" on the map.

Now let's think about how we could solve your issues.
The first one could be solved by making characters block only the tile they are moving to. Give me some time to try that out and check if it comes with any downsides.

For the second one:
If you removed the character from grid-engine you can set a manual depth < 1000 for the sprite. For the future maybe a property like "belowAllChars" in combination with a "collides: false" property on the character could solve the problem more elegantly. But both features are currently not implemented.

[artitj]

Blocking Chars:
Grid-Engine works as follows. If a character is NOT moving, it will block the tile it is currently standing on. If it IS moving it will block both tiles: the one it is leaving and the one it is entering.

Manual Depth:
For non-isometric maps the logic is:
Every sprite that has been added to grid-engine will get a depth (zIndex) of 1000 + y-coordinate on the map. The 1000 makes sure that there are enough layers below for tilemap layers. The y-coordinate as an offset ensures that characters that are more "south" on the map will be rendered in front of characters that are more "north" on the map.

Now let's think about how we could solve your issues.
The first one could be solved by making characters block only the tile they are moving to. Give me some time to try that out and check if it comes with any downsides.

For the second one:
If you removed the character from grid-engine you can set a manual depth < 1000 for the sprite. For the future maybe a property like "belowAllChars" in combination with a "collides: false" property on the character could solve the problem more elegantly. But both features are currently not implemented.

Thank you @Annoraaq for the clear explanations and for thinking about accommodating my use case.

For the 2nd issue, I was able to set a manual depth and have it work correctly in a small demo (https://codepen.io/artitj/pen/mdmyXQV for anybody interested, hit the spacebar to remove the character from grid-engine), but it's not working in my main project... I'll have to dig into my code a bit deeper to figure out what's different.

[splashsky]

The first one could be solved by making characters block only the tile they are moving to. Give me some time to try that out and check if it comes with any downsides.

I would chuck this into a config bool and allow people to choose which behavior makes sense for their project.

[Annoraaq]

I created an issue for problem 1 (blocking chars):
#164

The reason why blocking is currently implemented in a way that the char blocks two tiles while moving is that there are ugly overlapping issues otherwise. Therefore there might be the need to have the "2-tile-blocking" mechanism in place for everything but for certain characters. The most flexible solution I came up with is to make the type of blocking configurable for each pair of characters. That would enable you to have the current blocking mechanism for all the chars but change it only for specific characters. Moreover it could be a non-symmetric relation. Meaning that char1 could free up its former tile immediately when moving for char2. But char2 does not do the same thing for char1 if not explicitly stated.

Then you could define the collision very fine grained for each ordered pair of characters.