this post was submitted on 30 Aug 2024
183 points (98.4% liked)
Games
32521 readers
805 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's in Unity, isn't it? So rather than multiplying the speeds by
Time.deltaTimewhen you're doing frame updates, you just don't do that. Easy peasy. They've got that real "Japanese game devs from twenty years ago" vibe going.Or even a decade ago. Dark Souls 2 had some enemies' attack animations tied to frame rate, like the Alonne Knights. So they attacked incredibly fast on PC compared to console.
Weapon degradation was also tied to framerate :(
Huh, now i know why that particular enemy are janky as heck in every aspect.
Minecraft has this wonderful mechanism where everything is dependent on game-tick/server-tick, which is independent of player FPS. Why do modern developers keep using FPS for game physics?
basically every game uses ticks lol this was not intentional
Minecraft is different because it uses a client and server pattern, separating the physics and display loops completely
At least Gearbox isn't spending a year+ denying that the problem exists.
You mean "Bethesda to this day?"
They fixed that with 76, Both 76 and Starfield have physics untied from framerate.
Thats great to hear. Not surprised about Starfield tbh, but I am surprised they fixed it for F76, considering it relies largely on the same tech as F4, which does have that limitation.