Square Movement Problem

0 favourites
  • 4 posts
From the Asset Store
Gravity Square is a game where I aim to reach the square at the polka dot door :)
  • Hello,

    I'm working on a game where I need pedestrians to move around each block. So basically make them move in a square.

    What I have is displayed in this sample:


    I tried searching the forums but I only saw complicated samples that are way above my head. I just need the pedestrians to move and face in the direction they're walking, infinitely.

    Now what happens in the .capx I posted is that when two or more pedestrians hit the block on the corner at the same time, weird things happen and one or more of them ignore their path.

    Since I intend to have around 12 housing blocks on my map, I thought the easiest way was to copy-paste the blocks on the corners (that make the pedestrians rotate 90 degrees direction) but that causes problems when pedestrians are simultaneously hitting he corner blocks.

    Any way to fix this? See capx, thanks!

    I'm sure there should be a simple solution I'm just missing it I guess.

    • R
  • Thanks 99Instances2Go.

    I was wondering though, why that change was needed. I mean like the difference between what I initially had and you implemented?

    One can always learn more. Thanks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You obvious need the concept of a trigger, that is what you did find out yourself too.

    Else, at the speed they 'run', they overlap 2 ticks, resulting in rotating twice 90 degrees (or 180 degrees).

    You noticed that, and that is why you used 'trigger once while true'.

    I backed initial off from an explanation because i have a little problem that i can not explain. You used a 'trigger once' as a lonely condition. You can never do that. Because it works this way ... >

    When the event is true, it runs the actions. Then it waits till the event is untrue, in the mean while it will not run the action. While the event is untrue, it will obvious run no actions. The next time the event is true, it will run the actions, and then it waits again.

    Or: It runs the actions only once when that event is changing from untrue to true. Hence 'Trigger ONCE while true'.

    Now, a lonely 'trigger once' runs once, and after that 'once' this event can not ever be set untrue again. Hence you need to start such a event with a condition that can be changed from true to untrue to true ... and so on, to make the (second condition) 'once while true' work.

    I can not explain why it runs its action in that sub event, that you made, at this moment. That has me puzzled. So, you might not learn from the best in this.

    What i can i explain is why a 'trigger once' does not work as you expect when paired up with a picking condition. A Picking condition ( like 'Is (A) overlapping (B)' ) is ONLY untrue when the picklist is empty.


    The game starts with everything empty.

    The first tick that they overlap, the resulting picklist from that overlap is not empty. That makes the condition true. Since the condition flips from untrue to true, the 'trigger once' allows the actions to run. The blue dot in the left/down corner is changing angle. The next tick, the resulting picklist from that overlap is not empty due the overlaps on the right side. The condition is true (no empty picklist), so there is no flip from untrue to true, and the 'trigger once' is not allowing the actions to run. This means that non of those blue dots get a rotation. Since they are just moving the same path, the overlap is still true in the next tick. And will still be true as long as they overlap. There is no flip from untrue to true happening, as a result the 'trigger once' will not allow the actions.

    Once those blue dots on the right are out of the overlapping situation, the resulting picklist finaly gets empty. The condition is now untrue. At that the moment a blue dot on the left overlaps, the picklist is not empty, the condition is true and there is a flip from untrue to true happening. Hence the 'trigger once' can do its job. And so on ....

    And from this point, everything works as you expect.

    So now, it is clear that this 'trigger once' can not do the job. Yet, we desperately need a trigger.

    Well, on collision is a trigger. All conditions that start with 'on' are triggers.

    WHEN the collision happens, IT PICKS the colliding objects, the actions work purely on the picked objects. And, when you have 5 object colliding at the same time, it triggers ONCE for each object.

    The rest is just making sure that the angles can not shift due little floating point errors. Your setup is really tight.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)