I created a level with some walls, and the player can move around a sprite that shall be limited by those walls. So far so good. In the screenshot you can see how I modeled player (pacman) movement and collision detection. But it seems after one collision the player is blocked and cannot move any more.
To emphasize I added the javascript event, and yes I can see the screen flickering after first contact. That means the collision is going on, and that would imply the separation of the objects does not work.
I think the “stop object (remove all forces)” and “separate objects (only pacman will move)” actions are conflicting. You should probably pick one or the other. Also, the engine may be getting ‘confused’ by the stop and start of forces being used in the same events. You have to choose whether you want it to stop or add forces on the key presses, it can’t be both.
That sounds strange for me. I want the player to be stopped by a wall, so I have to choose that action.
But then after the collision with one wall there is an ongoing collision, so I assumed the player sprite has already stepped into the wall, so I’d have to move it back to the position prior of the collision.
Plus I thought that’s what the ‘separate objects’ was made for…
If I add the ‘Trigger once while true’ event Pacman can move through walls, as it keeps moving (it is never stopped, just moved to a new position) but the check runs once only. With continual testing my eyes hurt (the background is flashing a lot). Pakman is not stuck always, but still in a lot of situations it touches the wall and cannot escape. That is not yet satisfactory but I am clueless what to try.
How exactly does ‘separate objects’ work? I get the feeling it is crucial for the player to have some speed/force so it can be moved back?
It’s strange to combine opposite actions under the same condition. You are both trying to stop an object and make it go at the same time with the key press conditions. It’s similar to contradicting yourself in terms of how the engine is trying to follow your logic.
Again, I would remove the “stop” actions for key presses, leave only the addition of forces for those conditions. The collision condition should be able to handle the stop by itself with just the separate objects action.
Stopping removes all forces, which would prevent further movement.
It usually prevents one object from going through another.
So it would seem like the player has collided with something ‘solid’.
There’s probably other ways to explain it; I was trying to keep it simple.
Well, let’s leave the collision to the walls aside for a moment and just look at how pacman moves.
The player can decide to go any of four directions: up, down, left right.
When the player decides to go for one direction the sprite shall move all the way in that direction, unless some other direction is given. There is no option to stop midway. That is why I apply a permanent force.
Now suppose the user decides to change the direction. If he went right in first place, and we have to look at the four options again:
Going right + right keypress = still going right
If I add a force to go right Pacman would speed up. That is not what I want.
Going right + up keypress = going up
If I add a force to go up, GDevelop would keep the first force and move Pacman up, which would end up in a diagonal movement. Not what I want.
Going right + down keypress = going down
If I add a force to go down, GDevelop would keep the first force and move Pacman down, which would end up in a diagonal movement. Not what I want.
Going right + left keypress = going left
If I add a force to go up, GDevelop would keep the first force and move Pacman up, which would eventually end up in Pacman stopping (the two forces would neutralize each other). Again not what I want.
So how would you model the behaviour without removing existing forces? I do not see a contradiction but a necessity.
Please keep in mind I started using permanent forces just to keep Pacman going even if the user releases the key.
What you mention is the effect. But how is it calculated internally?
I get the feeling the internal logic assumes that objects collide because one, or both of them moved. It means in GDevelop speak there must have been a force driving this. To separate objects, the last step of movement is probably undone.
If that feeling is right it may be fatal to first stop Pacman (remove all forces) and then ask to go back a step - GDevelop would not know the direction of undoing the last move, the separate objects step fails and that is why my pacman is constantly colliding the wall.
Thus I tried to switch the sequence and first separate the objects, then removing all forces. But this seems to not work either.
Oh, then let me try again. Looking at my first screenshot:
Whenever Pacman collides with a wall, it would stop and be moved away from the colliding wall.
I understand you suggested to use the first occurrence only but calculate all walls.
In the meantime, to relax my eyes and better understand how separating objects works I removed the background color and added text fields to print Pacman’s position. This is what I ended up with now:
It works fairly well, but there are some occasions where after the action Pacman is still colliding. Yes, this is why I need the ‘trigger once’ filter. However, if in such a case I simply continue to walk towards the wall Pacman actually walks through…
I get the feeling I am thinking too complex. Pacman was one of the first arcade games, and the possibilities were so much more limited those days.
Sequence matters:
If you add a force and then stop the object it is stopped.
If you stop an object, then add a force it moves into that direction - regardless how it was moving before.
Yes, I know. I tried that over a year ago at this point.
What’s interesting is what Gruk said about how they run in order even inside a single block, with the same condition. That part just doesn’t make sense to me…
So I also tried to figure out how it works, and in the wiki we have the hint towards SAT, which refers to something like
or
Good, we can detect collisions. But how would then the separation of two collided objects work? And how does GDevelop decide whether to separate by position or by force? The Wiki says GDevelop can do both…
