Collision bug using Chrome

From the Asset Store
Match same tiles with each other as fast as you can and earn more score during a limited time!
  • Hello Scirra team!

    I have a game published on Steam, and I received a report from a user with a bug where the character could cross the colliders (solid tilemaps, and sometimes just triggers) in some situations.

    After testing on several computers, with suspected performance or updates, I was unable to reproduce the problem. So, I exported it in HTML5 form and asked the user to test it in different ways.

    It was seen that through the Google Chrome browser, the bug persisted. While the same did not happen with Microsoft Edge.

    The user has more updated Chrome, compared to my own version.

    In a curious event, the player noticed that the bug did not happen in Chrome after opening the Valorant game in the background.

    What can I do to find the problem? Why can this be happening?

    We already checked if the browser ran webgl2.

    The only thing I didn't do was ask the user to clear the browser's cache.

    It is a very strange problem to require such action in a game that will be released shortly ... Any solution?

    ---

    You can play and test the Demo version of the game by yourself:

    store.steampowered.com/app/1389120/Dojoran

  • It's virtually impossible to help unless you can follow the bug report guidelines (i.e. reproduce the problem in a minimal project and provide steps to reproduce).

    Given the fact we are running pretty much identical code in all browsers, it seems very unlikely it's actually anything to do with the browser version, and that is just a red herring that you've falsely correlated with this. If that's the case, then we have nothing to go on at all - hence the need to follow our guidelines for issues.

  • Hello Ashley

    I had two more feedbacks from people with the same bug. The way they play is clear, they force the character on the wall during a walljump.

    Even so, I couldn't represent on any of my 3 computers with different performances (a good one, a medium one and a terrible one).

    After MANY tests with one of the people who had the problem, this started to happen only through FireFox. As you said that the browser would theoretically have no difference, I made some more adjustments to the advanced engine settings.

    Apparently, the only setting that "fixed" the problem, was to change the "Use worker" option to "No", and "Framerate mode" to "Unlimited".

    I tried the separate settings and were unsuccessful.

    What can that mean? That the computer is skipping collision frames?

    The character clearly teleports from one side of the wall to the other. It appears that the program tests the player's collision only when it is already inside the solid object.

    I am not accusing a bug in Construct, but trying to understand what may be happening, or where.

  • I'm not sure this is the issue you're experiencing but -

    Sometimes lower frame-rates can cause collision issues depending on how you handle collisions. If you're using the built-in platform movement stuff, then I'm not sure if this applies -

    If your player's movement is based on "Set position to Self.X + Self.Speed * dt", and then your collision is the basic "Is player overlapping Solid" then as your framerate gets lower, then "dt" will get higher, meaning the "Set position" code will pretty much teleport your player further along, meaning sometimes the player will completely overlap a solid, or sometimes teleport the player beyond the wall which would ruin the game completely in some cases.

    However, if your player's movement is based on raycasting using the LoS behaviour or something, and you cast a ray in front of your player until the ray finds a Solid, and then update the X position of the player, then this would be a lot more reliable, even at lower framerates, as it will always perfectly detect the incoming walls/floors/ceilings and position accordingly.

    Hope this is useful in your case.

  • Jase00 You are completely correct.

    I was making some changes to the code today, and everything indicates that it has to do with dropping frames along with platform behavior and overlapping events.

    Since Framerate Mode Fullframes requires the computer to process all frames, this ended up solving the problem. But I don't know how much it can affect performance.

    It is also difficult to test, as I depend on something working very poorly, such as low FPS monitor, video card or even processing. This explains why there were changes according to the browser.

    Btw, Framerate Mode explains, but I did not understand the function of the Use worker.

    I never thought I could have done that kind of movement with LOS. Is the raycast made in proportion to the character to detect walls?

  • Oh I wonder how the platform movement is designed - I've always been cautious about the unknown nature of behaviours - I assume they are made with effeciency and performance in mind, but I do know the complexity of some behaviours is quite high (especially the Platform behaviour), which makes me very unsure about using them, as if I encounter any unwanted issues or wanted to request a change to the behaviour that is vital to my project, then it may not get updated as any update to the behaviour might break it for someone else's project.

    I know that the "Custom Movement" behaviour has a "Stepping" feature, so I presume the platform behaviour uses this too - This is great but I believe this is still not as reliable as raycasting. (If not sure on definition - "Stepping" means that it will "move the object, test collisions, move object again, test collisions again" multiple times in 1 tick.) EDIT - I use a combination of both stepping + raycasting in my C2 projects, so that it handles high-speeds and collisions well, even running at the speed of 3000*dt into a 1px wall would work reliably!

    To be honest I've only started experimenting with the LOS behaviour to make a raycast-based platform movement - Back in C2, I used to use the "Light" and "Trace" plugins and it worked very reliably. In C3, I have high hopes that LOS would be reliable, but I haven't nailed it down just yet, only because of having the time to check it out!

    For your project right now, one possible solution you could explore would be the System event "Set Minimum Framerate", where you could choose a Framerate that you expect your game to run at (e.g. 30fps) and if someone's computer cannot reach this and say reaches 20fps, then "dt" will not increase further, meaning the player would experience a slow-motion effect if their fps falls below 30fps (which is much better than teleporting through the map! But may be bad for any games that require rhythm or precision jumping ).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • So what solution do you use for Platform Behavior? All programing by "X+10*dt"? I almost sure the platform behavior works the same way...

    What I did on my project, and soon I find out if it worked, is not to let the character simulate the movement to the side of the wall for a short time after the wall jump.

    Theoretically, I didn't need to, because there is a wall on his side anyway, and he shouldn't go through.

    But at the same time, if it happened on average computers, I sometimes imagine with the computer practically locked.

    I have seen a lot of talk about different fall speed on 144hz monitors, and now I see that this is due to the Framerate Mode V-Sync. Perhaps this mode is no longer the best option today.

    At the same time, more complex games may not be well accepted by Fullframe.

    I had already set a limit of 60FPS by the command line "--limit-fps=60"

    How do I limit the minimum?

  • To limit the minimum fps in C3, I think it's only a "System" event right now, not a project property (unless I'm missing this). You can read about it here too: construct.net/en/make-games/manuals/construct-3/system-reference/system-actions

    Personally I don't use any behaviours at all and do everything in events - I do this because I want ALL the control lol. You can specify your collisions exactly the way you want by doing it this way, although this can get extremely fiddly and complicated and likely has a performance overhead, but to me it's worth the hassle to get the game feeling perfect. I aim to use LOS as I know there's a major performance gain compared to the event-only way of raycasting where you "Make a sprite, increase it's width by 1 until it hits a wall". It gets tricky though as a ray is only 1px wide.

    Perhaps LOS could be used in conjunction with the platform behaviour, but the more I think about this, I'm not sure this would work too well for your case, as it's a ray; a 1px wide line, so it's not going to account for the whole width or height of the player. Perhaps you could make a system where if the fps is lower than 30fps, then a make-shift sprite-based ray that is the same width/height as the player, that increases it's width/height by 1px in a loop (this is taxing for performance so this may be terrible advice) or maybe utilising the "On overlap at offset" for the player... OR MAYBE the system "Set minimum FPS" would suffice in this case to avoid over-complicating things!

    Yeah the whole 144hz monitor stuff (they have 240hz monitors now, would you believe? Must be butter smooth), I try to wrap my mind around this as I like the idea of making precision platformers, but I'm aware that when your fps is changing a lot, it can make your jump heights change just a little, but enough to ruin a precision jump and either miss it or overshoot it.

  • Thank you Jase00 !

    I limited the FPS to 25.

    But on second thought, I think it would hardly matter if I put a minimum FPS limit of 50 for example.

    If the game was fixed and ran normally when placing Fullframes, it means that computers could run much more FPS than they showed. Something specific about each browser limited the game's performance.

    This may have to do with WEBGL or any feature that browsers use to run, or improve the performance of the browser. Probably placing a minimum FPS limit on all games should make the browser obligatorily transmit the use of performance to the game, rather than slowing it down (except on extremely bad computers).

    After all, what made me confused, is that the game is simple enough to run on almost any computer at 60 FPS.

  • Wall climbing?

    If so that's not a regular part to the Platformer behavior.

    Best bet would be to make an example with the code you're using and post it.

    Otherwise the rule of thumb is that if the player speed(pps) is greater than the size of the obstacle, then skipping is going to happen eventually.

  • Platform behavior have an event to check "Is by wall", so you can just set the fall speed to 0.

    But I'm pretty sure this works same as overllaping.

    Anyway, I've solved with other simple solutions mentioned

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