0 Favourites

Pixel-precise custom movement on a grid.

  • Hi,

    I'm planning to make a grid system for a turn based game and searched through the forums to check what was done before, reading all the links in the how-to thread but the most detailed example I were able to find was from the Construct Classic era which is fine as CC turned out to be a familiar experience after using C2:

    related topic

    The example I linked above was probably before the time tiled backgrounds were implemented and I have no desire to place tons of empty sprites, bogging down cpu resources to create a grid so I'm thinking about moving objects in relative distances from where they were previosly or maybe keep possible x,y values in arrays and move sprites to them using the rex_moveto behaviour. However I prefer the stock behaviours as they might be less prone to bugs as more people use them and fixes are guaranteed to arrive (not that rex_moveto behaviour isn't cool as it is, just forcing myself to do things the intended way).

    I'm going for the relative distance approach but having a problem: I'm never able to produce consistent results using custommovement to stop a sprite after moving a set number of pixels (in this case, 84). The result is unpredictable in the runtime and different in every case. I tried to set the x location of the sprite to floor() and int() of itself on every tick but this only removes the trailing digits and doesn't guarantee I'm going to get multiples of 84 every time. I'm assuming this is due to the delta timing features within the custommovement behaviour but I may be wrong on this.

    Attached is a .capx that has an event disabled to show what I'm getting normally. Enable that events to see what I'm intending to end up with. I believe my current *fix* of the matter is a dirty hack and is doomed to cause collision related troubles in the long run or maybe I'm just being paranoid and this is how it's supposed to be like. I'd love to hear what experts can say on this matter.

    Thanks :)

  • Ok, after looking at you code, I would recoment, that you use the "every tick" event to move the sprite by "x" and check if the desired delta value is reached...

  • Nice example Yann.

  • Thank you for the replies. :)

    Ok, after looking at you code, I would recoment, that you use the "every tick" event to move the sprite by "x" and check if the desired delta value is reached...

    I'm not really sure what you meant but I'm interested to hear more :/

    http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

    Thanks, that's a very good example and I'll surely make use of instance variables like you did but rotating the sprites unintentionally rotates the pixel data within them and I'll have to find a workaround that doesn't use the angle parameter at all. This is what I mean.

    Also if I understood correctly, even if you "Substract speed*dt from move" it may return a negative value and we may need to use the fix you already provided. IMO If there was a way to limit the maximum frame rate without using dt, I'd just drop the dt and all the hassle that comes with it. Inconsistent sprite movement speeds vs. sprite movements that don't stop accurately = I'd take the first one any day. I'm still feeling illiterate about it even after reading the available resources here but I just don't see how dt might come in handy in the case of turn based, non action oriented scenarios. I'm an interface designer, not a programmer, previous flash user and certainly not a flash fan. C2 with its brilliant event system helps me do what flash with all its weird elitist script driven ugly face didn't. Oddly enough timing was never an issue in flash and everything was fps driven. Or at least, it was never the user's responsibility to be bothered with whatever sorcery laid underneath. I know that C2 is new and yet incomplete and I'm not going to be alienated by this; probably learn more in time and keep supporting it but some way of simplifying these kind of issues is kinda required to keep non coders interested especially if they're attracted by "no coding required" slogan. I bet a couple behaviours will appear in some months and C2 will suddenly start catering people like me that aren't coders and are interested in making a 2d game that isn't action related or in real time.

    Unrelated bug report for the devs:

    I think I've come across an interesting Construct 2 bug on this example. Try creating an action from "textch" on every tick like I did with the other variables and text objects and set its text to the player's instance variable "checked" It'll work, the preview will work but it won't save! Next time you load the file the action will be gone. Looks like boolean instance variables have a problem with saving when called into text objects.

  • Wronghands: For bug reports prefer to make them in the bugs forum following the instructions on how to report bugs. This is the better way to be sure that Ashley treats/fixes it.

    Be sure to post though, I reproduced the bug according to your steps.

  • Just keep the dt, it's not only a framerate thingy, it makes the movement smooth and consistant. And the substraction is what makes the movement pixel precise. It's not a fix it's just manual rounding. So I strongly suggest you keep it that way. One tiny action is not what we can call "a hassle" in my opinion.

    Also, for the angle, I already thought about that. I could have simply used an instance variable. But it's just a sprite. It's just an object with angle and position. Nobody said you had to use the same object for graphically eye-candy stuff.

    Just set the 'Player' sprite to invisible, and just make your character follow the position (and not the angle) of this 'Player' sprite.

    And for the bug you talked about, I would guess that it's a type issue. booleans aren't string nor number. What is displayed in text should be strings or number converted into strings. C2 might not handle what is called type casting from boolean to string.

  • Also, for the angle, I already thought about that. I could have simply used an instance variable. But it's just a sprite. It's just an object with angle and position. Nobody said you had to use the same object for graphically eye-candy stuff.

    Just set the 'Player' sprite to invisible, and just make your character follow the position (and not the angle) of this 'Player' sprite.

    That's simple and effective. Didn't think of it due to lack of experience. :)

    I'd like to use mouse controls however and were going to attempt merging what I learned here with Kyatric's pathfinder behaviour, moving tile by tile with the data generated by pathfinder but with the time based animation logic you provided but then again I thought I could just use the default 8 direction behaviour with pathfinder now that you gave me the idea above! This is still well above my head so I'll be heading back to forums quite often. Will try to use this thread to keep things tidy. :) Thanks again.

    @Kyatric

    Done!

  • Wronghands: Your issue with the iFrame is maybe not a bug.

    Sorry for the misguidance.

  • That must be someone else's bug, I never even used iframe in C2 :)

  • Oh wow, I really should go to bed. Indeed, wrong bug. <img src="smileys/smiley17.gif" border="0" align="middle" />

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • Wronghands

    If you use the mouse, you pretty much have no choice but to use a pathfinder.

    A pathfinder will return all the cell you have to go through to reach the cell you clicked on (if it is reachable).

    Then, the grid movement I coded won't be used at all. You won't need to check for collision and you will just have to interpolate between each coordinate returned by the pathfinder.

  • Yann Thanks for writing and sharing your example! Hopefully someday there will be some grid-movement behavior or action that is part of the Construct 2 core. In the meantime, I've written something similar using the bullet behavior to automate the calculation of the new X and Y coordinates during the movement of the sprite. If you're interested, check it out at http://www.scirra.com/tutorials/308/cloning-the-classics-pacman

  • stemkoski

    nifty indeed (:

  • http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

    With this (otherwise perfect for me) script you are able to move through walls occasionally.

    If the speed is lower than 256, the player can move through walls easily, but even at 256 the player can still move through walls. Is it possible to make the collision detector always position itself before the player moves to it?

    I hate to bump the topic, but I have a sticking point in my game because I do not want there to be a bug where player can run through walls, and I need grid based smooth movement.

    If you turn on the visibility of the green sprite, collision detector, you can plainly see how the character moves faster than the detector sprite allowing you to at times enter the collision object (wall). Is there any work around for this?

    It's easier to reproduce if you lower the speed variable, but even at 256 you can still at times move through walls.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)
Similar Topics Posts Views Last Post
Unread hot topic
564 105,210
rexrainbow's avatar
rexrainbow
Unread hot topic
233 22,249
TiAm's avatar
TiAm
Unread hot topic
0 Favourites
Path Movement Behavior
98 52,470
R0J0hound's avatar
R0J0hound