Everade's Recent Forum Activity

  • This function is not called every tick, it is called while the player is inputting a movement direction (which I suppose is every tick that it is needed) and deceleration is handled by the 8-Direction behavior. Would I still need use "TimeElapsedSinceLastExecution" in that case?

    If the function is called once per tick (while movement is active), then you should be good to go.

  • It's not really an issue with the 8 Direction behavior, but with how the lerp is implemented. Your code is not framerate independent.

    Framerate independent lerp example:

    lerp(CurrentValue, TargetValue, 1 - (0.05 ^ dt))

    In this example, 0.05 means that after 1 second, only 5% of the difference remains. Lower values = faster / Higher values = slower.

    If the function does not run every tick, then you would need to replace dt with the elapsed time since this function last executed.

    In that case, use the elapsed time since the previous function execution instead:

    lerp(CurrentValue, TargetValue, 1 - (0.05 ^ TimeElapsedSinceLastExecution))

    You should apply this to every lerp.

    Sidenote: Since this code is inside a function and i don't see how it's being executed... the function should run once every tick for the lerping to behave as expected.

  • Hi,

    I recently got Blasphemous. I played it on the deck for an hour, and then when I booted it up on my pc, the save file didn't exist, because the linux version and the windows version of the game apparently can't share save files. So my playthrough is stuck on the deck.

    If this is the case, and with the existence of the proton interpreter, Why would I bother with making a Linux version for a game targeting the steam deck?

    It's up to the developer to set up steam cloud saving properly. It's definitely possible to share save files between different operating systems, i've done it myself. This has nothing to do with the export option, with Auto-Cloud, the developer must configure the save path mapping correctly across OSes, using a single root plus overrides for cross-platform sync.

    A proper export would surely run smoother than letting Steam run it through Proton, so there are surely some benefits. Possibly a little quicker to get through the SteamDeck verification process as well. The game would also be listed as "Native" on databases like protondb and so on. So marketing wise it might do you some favors too.

    However again, this has nothing to do with cloud save syncing issues.

    If you as the game developer use Steam's Auto-Cloud feature, and want to support cross-platform saves, then you must configure a "Root Override" for each OS manually within Steamworks. So it's possible that they missed that on Blasphemous if what you're saying is true.

    For more details, checkout the "Cross-Platform Saves" section here:

    partner.steamgames.com/doc/features/cloud

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Shadow lights can only handle shadow casters which have convex collision polygon shapes. So the effect will break on shadow casters having concave polygon shapes. Make sure that's not the case and that there aren't multiple polygons on the exact same spot.

  • I also have encountered the issue where image points I set to specific positions don't save the new position and revert to the old position as soon as I close the frame I edited (so even when I keep the image editor open and just go to the next frame)

    I encounter this issue all the time.

  • 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

Everade's avatar

Everade

Online Now

Member since 24 Jun, 2014
Last online 3 Jun, 2026

Twitter
Everade has 12 followers

Connect with Everade

weakspots.com

Trophy Case

  • 11-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • x4
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • RTFM Read the fabulous manual
  • x85
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x151
    Lightning Draw First person to up-vote a new Construct 3 release
  • x4
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Magnificent Comment One of your comments gets 25 upvotes
  • Email Verified

Progress

26/44
How to earn trophies