Everade's Forum Posts

  • The type of multiplayer (PvP, Co-op or both) significantly influences how you should design your network architecture.

    Co-op Gameplay

    For co-op games, you can prioritize a smoother experience by allowing player-authoritative movement control instead of sending inputs to a server for validation. This approach reduces input delay and completely eliminates rubber banding for the controlling player's character. However, this comes with the trade-off of increased vulnerability to cheating since the server does not enforce strict authoritative decisions. But you can still mitigate cheating with periodic server-side sanity checks if needed.

    PvP Gameplay

    PvP games demand a stricter balance between responsiveness and fairness. Using input prediction can minimize the perceived delay for players but may introduce rubber banding if inaccuracies occur due to latency discrepancies. The challenges are more pronounced when:

    • Players interact with shared objects, like a ball(or disc in your case?!) in a "soccer" game. Here, discrepancies in latency mean each player effectively operates in slightly different past states of the game.
    • Without robust client-side prediction for actions like shooting or kicking, noticeable delays can occur. On the other hand, over-reliance on prediction can cause jarring corrections, such as mid-air direction changes for a ball when the server updates its position.

    To address these issues in PvP

    • Server-Side Buffers: Maintain a buffer of recent game states and allow clients to send their inputs with timestamps. The server processes these inputs by replaying the buffered state closest to the client’s perspective. (rewinding time to the scenario the player was facing at the time)
    • Client-Side Interpolation: Instead of rendering server positions directly, clients interpolate positions over time. This smooths out sudden corrections.
    • Input Prediction: Allow clients to predict their own actions (moving/shooting/kicking) while the server maintains ultimate authority. The server sends corrections that you will have to hide as good as possible without being disruptive.

    Ultimately, the optimal approach depends on your game's specific requirements.

    So it's up to you to find the right balance between responsivness, accuracy and fairness. In any scenario you will have to try to hide the time-offset as good as possible. And possibly even prevent players from joining if their ping is so high that it would influence other players gameplay.

    The solutions described above are already provided by the multiplayer plugin. And described in more detail here: https://www.construct.net/en/courses/online-multiplayer-construct-12 However, if you feel it doesn’t offer you enough control, you can develop your own implementations to better suit your needs. ( for example: still using the multiplayer plugin, but not relying on the automated interpolation from the "sync" feature )

    For co-op gameplay scenarios i offer a paid beginner and more advanced template in Construct's Asset Store (with a demo). They can give you a clear idea of how such setups might look in action.https://www.construct.net/en/users/92570/everade/asset-store

  • HTML5 games running in the browser are essentially websites, built using the same technologies like HTML, JavaScript, and CSS. So they follow the same security rules as any other website, including the use of iframe.

    If you're concerned about kids browsing online, there are plenty of great resources on internet safety you can find both online and at your local library.

  • Yes, a webGL 2D global illumination shader using radiance cascades was once shared by Xor in the construct community discord. One shader generated the cascades and another one was for GI, then multiple passes of blur. Although it didn't account for viewport scaling and wasn't very flexible. But you might still be able to find it there.

  • These events run on every tick. Meaning that as long as the event condition is true, the animation will start from the beginning and never get beyond the first frame.

  • Again same issue.

    In that specific scenario, on your Event Sheet "main", the event nr. 113 conditions stay true even after death. So it calls the "classicgamedeath" function on every tick. Means you reload the "deathscreen" layout indefinitely until you clicked that button for the first time, which is the last time the deathscreen is reloaded. Thus the second click will actually work as you escaped the endless loop.

    Note:

    All events with an arrow "On xyz" (including functions), are triggers. These only execute when that specific event is being triggered/called. Otherwise they are entirely ignored.

    Everything else, will run ON EVERY TICK. Even without specifically setting the event "On every tick". The "On every tick" event is actually redundant. That's just there for beginners, although i believe it causes more harm and confusion than anything else.

    So basically the game runs your entire event sheet, on every tick, all events from top to bottom, unless those triggers i mentioned before.

    "Trigger once", which you also seem to have been testing with, is also a beginners trap as it may behave differently than you would expect.

    One way to prevent something like this is utilizing Groups. You put these events into a "death" group, and deactivate the group when these conditions are no longer needed (after death) so on the next tick they are ignored. And reactivate the group when your player is back alive. Which is also performance friendly as all these event conditions are entirely ignored when deactivated.

    Or just refactor those nested events, so when your character dies it only calls the action once.

    Or you split the event sheets, so each layout has its own event sheet, only including event sheets that are required. For example the deathscreen should not need to run actual gameplay logic at all, it only needs to know certain variables which could be imported from a core/variables event sheet.

  • Set the 8Direction acceleration and deceleration by action.

    Then use the expression "Infinity" which returns a float set to positive infinity.

  • Because event nr.6 calls the classicgamedeath function on every tick.

    You can easily debug things like these yourself by adding an event at the very top of your event sheet. Then add a breakpoint to it and start a debug preview. It will hit the breakpoint right away, so you can continously click on the "step" button in the debugger, which will then visually show you where the code is currently at inside your event sheet.

    That way you can spot issues like these very easily.

    https://www.construct.net/en/make-games/manuals/construct-3/project-primitives/events/breakpoints

  • I made a workaround instead of using hierarchy i saved the UID in the "parent" object as an instance variable, then pick the "child" by evaluation. So not using hierarchy fixes the crash as well as further loading related issues, but also means you will need to handle hierarchy related conveniences manually.

    Or just leave it as it is and wait for a fix.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sounds like it might be related to this https://github.com/Scirra/Construct-bugs/issues/8118

  • All events with an arrow "On xyz" (including functions), are triggers. These only execute when that specific event is being triggered

    Everything else, will run ON EVERY TICK. Even without specifically setting the event "On every tick". The "On every tick" event is actually redundant.

    So basically the game runs your entire event sheet, on every tick, all events from top to bottom, unless those triggers mentioned above.

  • Since you create them at a specific location they should just stack on top of each other. Have you checked in the debugger if there's truly just one instance?

  • Looks like it was indeed getting it from a cache. Glad i was able to help.

    Just keep in mind when calling with a parameter like you said:

    https://worddad.com/download/output.json?v=" & current_date

    Will still cache it locally, and also still get it from cache for a max of 24 hours.

    For example if a player starts playing at 01:00 in the morning, and you update the JSON file at 01:30, the player will not get this update (loading the file from local cache) until the next day comes around.

    Which might not be what you want. So a more accurate timestamp including hours/minutes would make sense here.

    However keep in mind that the json files are still cached locally for the duration set by your web server (possibly for a year), even if not needed. Entirely depending on your website's cache settings. Not a big deal, but something to be aware off.

    If you want to truly prevent caching locally, you would have to change the expire header on your webserver.

    This here would disable local cache for all JSON mime types on your website:

    In your .htaccess add: 

    <IfModule mod_expires.c>
ExpiresActive On
ExpiresByType application/json A0
</IfModule>

    But there might be additional layers of caching, for example if you run your website through a CDN (for example Cloudflare) which may cache files on their cloud systems as well.

  • Sounds like a caching issue to me.

    It might be possible that C3 (or any export option) loads the file from local cache. In that case, check your web server's Cache-Control / Expire Header settings. Or any other layer of caching.

    Might be worth checking out.

  • In the export options, set Minify mode to either "Simple" or "None".

    More details about minification can be found in the Manual.

  • Just press play, so it will stop on the next tick, more specifically on your next breakpoint.

    Or add another breakpoint like citron suggested.