I'm fit & healthy for my age, but I've been hit by a car while biking before and anyone can get a cancer diagnosis without warning. Insane to imagine that kind of crisis snowballing into also destroying my home and retirement, but That's America Baby.

Hey man, you know what would make Nightshift Galaxy way easier to realize? Medicare For All. Literally the biggest impasse right now is figuring out Health Insurance for next year.

On GG Xrd they just rewrote that from scratch -- IIRC they're on a hard-fork of UE3

Add one ugly one, just to naturally balance things out.

Yeah it's not designed for that so you're basically at square one.

My Unreal-workaround for this on Nightshift is to update all my characters' intents, and then actually SetActorTransform() in a batch, later.

If you're a real programming sicko, you can define a "tick" as, like, 1/8th of a frame and do all timing calculations using uint64s rather than floats or doubles to allow exact timing comparisons, rather than always resorting to "epsilon bounds" -- it was good enough for PSX!

It's kinda like how it's more useful to configure rotation text-boxes as euler-angles/degrees than quaternions. Picking units that are relevant to the problem-space, rather than the solution-space.

Ask why every fighting game using Unreal has to fundamentally rewrite the game-thread-timing and input-stack. Their built-in input use a multi-threaded pub-sub that can add latency frames, and Epic closes every PR against it as WONTFIX :P

My "If muscle-memory/skill-ceiling" proviso doing a lot of heavy-lifting. Obviously not relevant to cozy games or puzzles, lol.

(Which isn't even going into my programming gripes about having to worry about elastic CPU costs competing with GPU for perf-bounds 🤮)

It really makes no sense in unreal, a first-class online replicated engine, where the server has to bend over backwards to accommodate both 30FPS and 120FPS clients simultaneously.

I _really_ blame Unity and Unreal for pushing variable-timestep gameplay as an unexamined hard-coded assumption (and worse, Unity defaulting their secondary "fixed update" to PAL-oriented 50fps rather than standard 60). Variable draw-times is rendering problem, _not_ a gameplay scripting problem.

That last one's a subtle point -- it's not about the "integration error" per say, but about reliably showing the same output for the same input (even if that output is somewhat numerically unstable). There can be glitches and quirks, but high-level players can _learn_ those glitches and quirks.

Lastly, action games are highly-concurrent, formally an intractable series of interlocking differential equations without closed-form solutions. So we use numeric approximations, which in variable timesteps introduce intrinsic RNG . So high-level players cannot reliably "reach the ceiling."