Jump to content


Photo

Problem with movement on a chess-like board


  • Please log in to reply
3 replies to this topic

#1 nodgene

nodgene

    GMC Member

  • GMC Member
  • 85 posts
  • Version:GM:Studio

Posted 01 March 2012 - 05:31 PM

Hello!

I have made a simple chess-like board. Each tile instance is from the same object.

On this board the player may each turn spawn units, and move them, and they may attack enemies, etc. It all works. Except for movement...

The movement works perfectly almost all of the time. However, for reasons unknown to me; a unit that attempts to move onto the top or far-left row of tiles, at the edge of the board, is instead moved a tile in the opposite direction. It does not however do anything strange if a piece is moved on to the bottom or far-right rows. And everything is fine with any tile that is not at any edge.

I have used the debugger in order to determine what is happening with the global variables I use. They log the selected piece, the tile that piece is on, the tile that piece is moving to, etc. The globals do not change unexpectedly, and appear to point the piece to the correct tile, and nothing changes unexpectedly when the piece is moved to the wrong tile either.

I am rather confused, has anyone else had any similar problems? :(

Right Released
if global.obj!=0 // check key variables if a source unit is selected
{
dist=point_distance(global.obj.x,global.obj.y,global.vtile.x,global.vtile.y) // get distance from source object to tile
rang=global.obj.range*100+90 // calculate the range variable    

//MOVE UNIT    
if global.obj_mode==1 // selected instance is the player's own
    and global.obj!=0 // source unit exists
    and collision_point(mouse_x,mouse_y,tile,1,1) // there is a tile there
    and not collision_point(mouse_x,mouse_y,object1,1,1) // there is not another unit there
    and global.obj.moves>0 // unit has moves
    and dist<160 // within range
    {
        with(global.obj) 
        {
        move_snap(global.vtile.x,global.vtile.y) // move the source unit to the target tile
        global.obj.moves=global.obj.moves-1; // reduce source unit's moves
        } 
    }
        else
        {
        move_snap(global.otile.x,global.otile.y) // move the source unit to their origin tile
        }

  • 0

#2 TheouAegis

TheouAegis

    GMC Member

  • GMC Member
  • 4725 posts
  • Version:GM8

Posted 02 March 2012 - 12:45 AM

Quick question: do the unit objects and tile objects (if i read that right and that's bad programming if i did) have the same relative origins? Or do the tiles have origins at (0,0) while objects have centered origins?
  • 0

#3 torigara

torigara

    GMC Member

  • GMC Member
  • 6483 posts

Posted 02 March 2012 - 04:52 AM

move_snap(global.vtile.x,global.vtile.y) // move the source unit to the target tile

You seem to be one of victims those are confused with move_snap. That is NOT the function to move the instance to the indicated position. For that purpose, you should simply say:
x = global.vtile.x;
y = global.vtile.y;

For the future reference, the proper usage of move_snap is something like the following:
move_snap(16, 16);
Where 16 is the size of your tile (not the target position!) It will make the instance align with the grid where each cell size is 16x16. What it actually does is to round the instance's x and y to a multiple of 16, so it snaps to the nearest cell.

When you put the target position instead, say vtile.x and vtile.y, it might look to work at the first time. For instance, when vtile.x is 256 and vtile.y is 128, move_snap(256, 128) makes the instance snap to the big grid where each cell is 256 pixels wide and 128 pixels tall. The nearest cell position to the current instance will be (256, 128) which happens to be the same as vtile.x and vtile.y. So you will think it is working correctly, until vtile.x or vtile.y gets less than the half of the instance's current position.

Edited by torigara, 02 March 2012 - 11:12 AM.

  • 0

#4 nodgene

nodgene

    GMC Member

  • GMC Member
  • 85 posts
  • Version:GM:Studio

Posted 02 March 2012 - 09:36 PM

Torigara was right :o

Little did I know, converting it to a jump move as you suggested fixed everything :D Thanks, both of you.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users