Lag in actor following another actor - isometric view game

Wonder MaruWonder Maru Member, PRO Posts: 98
edited August 2016 in Working with GS (Mac)

Hello!
I'm trying this experiment with an isometric view game and I'm quite happy with the result achieved in simulating the 3D overlapping between characters. BUT I have a little issue, not a huge deal, but still something I'd like to solve to perfect the game's look.
This is what I do to simulate actors moving in a 3 dimensional space: every character has a copy of itself, same size and same animations, one called "front" and one called "back", the layers are ordered as follow:
character_front
enemy1_front
enemy2_front
etc...
character_back
enemy1_back
enemy2_back
etc...
so that whenever a character overlap another one I check the Y positions of both and I hide the front copy of the one higher on screen (Y higher means it's further away in perspective, therefore behind whatever is in front, that has a lower Y position on screen).

This works pretty well, need maybe some tweaks but the result is quite good (will post a video later if someone's interested).
All of the "back" copies just follow the X and Y of their "front" copies around the screen. The problem is there's sometimes a little lag between the position of the front copy with its back copy, resulting in a little offset where I can see part of the back copy. I tried to move the constrain X and Y behaviors on top of each actor, so that they're the first instruction in the flow, but nothing changes.

Then I tried using some booleans attributes: whenever the front is shown, the back copy is hidden and viceversa. Works, but still lagging, causing a flickering between the "hide front-show back" resulting in the character disappearing for a fraction of a second. I tried to add a timer to mitigate this, but still flickering for some reason.

Also, sometimes (rare occasions) it hides the front and not show the back, like it's skipping the instruction, making the character completely invisible until the IF cycle kicks in again and reset the thing.

I think there's no solution to this, looks like a limit of the engine, but maybe someone has an idea :)

Thanks in advance!

Wonder Maru: casual games for casual people. www.wondermaru.com

Comments

  • NNterprisesNNterprises Member, PRO Posts: 387

    Yea idk, may be a limit to the engine, BUT I do know that Gamesalad processes the layers from BOTTOM FIRST to TOP... so remember that. Since your BACK is a lower layer than the top, maybe have the rules in the back layer so it will get processed first.

    Not fully sure what is going on and a video would help, but that's all I got lol good luck

  • Wonder MaruWonder Maru Member, PRO Posts: 98

    @NNterprises said:
    Yea idk, may be a limit to the engine, BUT I do know that Gamesalad processes the layers from BOTTOM FIRST to TOP... so remember that. Since your BACK is a lower layer than the top, maybe have the rules in the back layer so it will get processed first.

    Not fully sure what is going on and a video would help, but that's all I got lol good luck

    ah wait, I didn't know that. So the layers from the bottom are the first to be processed? But within the actor the instructions are top to bottom, right?

    Wonder Maru: casual games for casual people. www.wondermaru.com

  • NNterprisesNNterprises Member, PRO Posts: 387

    Yes yes the BOTTOM layer goes first in the scene.

    The TOP rule goes first in the actor.

    It's semi inconvenient, cuz usually the actors in the back are less important in my games. But now you know and you can fix it to take that into account

  • Wonder MaruWonder Maru Member, PRO Posts: 98

    @NNterprises said:
    Yes yes the BOTTOM layer goes first in the scene.

    The TOP rule goes first in the actor.

    It's semi inconvenient, cuz usually the actors in the back are less important in my games. But now you know and you can fix it to take that into account

    true, on an average I guess actors on top are the most important, while the ones in the back are probably background elements and stuff like that. But good to know! I'll try switching things from front to back!

    Thank you!

    Wonder Maru: casual games for casual people. www.wondermaru.com

  • SocksSocks London, UK.Member Posts: 12,822

    @Wonder Maru said:
    the layers are ordered as follow:

    >

    character_front
    enemy1_front
    enemy2_front
    etc...
    character_back
    enemy1_back
    enemy2_back

    >

    All of the "back" copies just follow the X and Y of their "front" copies around the screen.

    This should be the other way around, the upper actors should 'follow' lower actors to avoid lag.

    @Wonder Maru said:
    The problem is there's sometimes a little lag between the position of the front copy with its back copy, resulting in a little offset where I can see part of the back copy. I tried to move the constrain X and Y behaviors on top of each actor, so that they're the first instruction in the flow, but nothing changes.

    You shouldn't have any active rules in your non-visible actors at all ! The non visible actors should only be constrained to their positions when visible. When they are not visible they should have no constrains or rules firing.

  • Wonder MaruWonder Maru Member, PRO Posts: 98

    @Socks said:

    @Wonder Maru said:
    the layers are ordered as follow:

    >

    character_front
    enemy1_front
    enemy2_front
    etc...
    character_back
    enemy1_back
    enemy2_back

    >

    All of the "back" copies just follow the X and Y of their "front" copies around the screen.

    This should be the other way around, the upper actors should 'follow' lower actors to avoid lag.

    @Wonder Maru said:
    The problem is there's sometimes a little lag between the position of the front copy with its back copy, resulting in a little offset where I can see part of the back copy. I tried to move the constrain X and Y behaviors on top of each actor, so that they're the first instruction in the flow, but nothing changes.

    You shouldn't have any active rules in your non-visible actors at all ! The non visible actors should only be constrained to their positions when visible. When they are not visible they should have no constrains or rules firing.

    yes! I'm definitely gonna try changing things using the front ones as copies and using the bottom ones as main actors and put the rules in there.

    I'll let you know how it goes :)

    Thanks!

    Wonder Maru: casual games for casual people. www.wondermaru.com

  • frdfrd Member Posts: 191

    When you change it to have the upper actor follow the lower one it should work fine, I do it the same way -

  • Wonder MaruWonder Maru Member, PRO Posts: 98

    Worked GREAT!
    Thanks guys! This is awesome!

    It's also a very important lesson for future projects.

    Thanks a lot!

    Wonder Maru: casual games for casual people. www.wondermaru.com

  • SocksSocks London, UK.Member Posts: 12,822

    @frd said:
    When you change it to have the upper actor follow the lower one it should work fine, I do it the same way -

    Game looking amazing !

Sign In or Register to comment.