Tag Archives: movement

Workflow: Using 2 Boards

In my RND I have come upon a method to use two Boards, one for use with movement logic, and the other for tile/sprite placement. The movement logic Board has more cells (x2 or x4) than the placement Board.

The movement Board is referred to as the MBoard, and the graphics Board is referred to as GBoard. Each Board has its own SquareTx object, MSquareTx and BSquareTx, respectively.

The SquareTx defines the physical dimensions of the Board, so each must be configured for its purpose. (MBoard/GBoard will be referred to inclusive of their SquareTx associations).


The GBoard’s purpose to place tiles. The GBoard’s cell sizes are bigger in order to fit more unique looking graphics and cover more ground using tiles (instead of Tiled Image Objects).

The GBoard is essentially what is depicted in the Tiled editor.


The MBoard is derivation of the GBoard. It’s constructed alongside the GBoard when it is read from the TMX.

The MBoard essentially subdivides the GBoard’s bigger tiles so that it would have 4x-8x more tiles, depending on the desired subdivision.


  • Create GBoard and MBoard
  • Create GSquareTx and MSquareTx. Associate with respective Boards.
  • Create SLG. Associate SLG with MBoard.
  • Create placement tile for MBoard. This can be any tile, but it must cover one cell size of MBoard in order to register a click predictably.
  • SquareTx offsets tne cell widths are set, and Board width/height are set accordingly:

    Offset X is the same for both MBoard and GBoard. Offset Y is a little different to account for the half size of the MBoard cell. ‘-16’ is used in the image due to the 32×32 size of the MBoard cell.

Orthogonal functions

Some orthogonal-related functions must reflect the different coordinates.

In OXY2LXY (OrthoXY to LogicXY), the logical return value will obviously be different because of the different cell size.

All functions that use the SquareTx as a point of reference must have their own function for each board.


It is best to use two different Text objects to debug the cells of the two Boards.



Workflow: Filtering SLG Movement results

Researching on another tack, I came upon to need to filter the results of ‘Get movable area’ call in SLG movement.

In SLG movement, you can direct it to get a path, or get a movable area. I needed a movable area. Getting a movable area also has a ‘cost’ function. The issue I initially faced was that when you assign slg.BLOCKING as cost value, you are blocking that line of search.


The image above shows a case situation (though this is depicting the problem solved). The yellow circle is trying to find a movable area beyond the LOS of the blue circle. The green circles denote valid movable areas, which, again, are the result of having the issue solved. The tiles with LOS is depicted as the squares with the white outlines. Originally, I had put a blocking cost to tiles that are LOS’d, and the result was that I wasn’t getting any green circles.

When the ‘Get movable area’ cost function is run, it seems to spread out to tiles that are movable. However, if a blocking cost was assigned, then it can never branch out past that, unless it finds another route. In the image, the yellow circle is completely surrounded by LOS’d tiles, and therefore, even though tile # 427 and tile # 475 might be out of LOS, the ‘Get movable area’ function can’t get past those tiles that have been blocked.

To make this work, it had to be a 2-step process. First, make a simple ‘Get movable area’ cost function in which impass=1 is blocked, but everything else is nominal.

Next, filter the result of the cost function further.

The call to the filter function from the ‘Get movable area’ action.
The filter function ‘remove LOS tiles’ goes through the tiles that were gathered by SLG.

So now, in the filter function (‘remove LOS tiles’), the resulting tiles gathered by SLG needs to be appended back to a list (before it’s actually passed into the InstanceGroup).

All tiles that are not appended to this filter result will not be put in the InstanceGroup. So this is a matter of the explicit inclusion of tiles to this result.

In the above image, those tiles that are not LOS’d, are put into the InstanceGroup.