Sub-tick updates sound to me like they're still using a tick rate system, but specific CBasePlayer mechanisms will now undergo interpolation using UserCmd timestamps alongside their rewind buffer to understand specifically where you were during gameplay as opposed to looking backwards in the rewind buffer and not making interpolated calculations based on timestep.
There is still an upperbound where additional granular game states don't occur and that upperbound is based on framerate, afaiu.
We use a similar system in Planimeter Game Engine 2D.[1]
Planimeter engineers are former Source Engine developers.
Couldn't you separate input from framerate and interpolate based on the input timing? I do this in a reaction-based arcade game I'm working on in Unity with their newer input system. e.g. If they input happens 8ms before the current frame, a projectile is "fast-forwarded" by the equivalent of 8ms, and then is in sync with the tickrate. The bigger issue I've run into is since mobile is my primary target, I've found that phones don't report touch inputs more frequently than their screen refresh rate. Works perfectly fine in the desktop build though with 60fps and a mouse with a 8k polling rate though.
We write a general purpose game engine, but some of the predefined classes do have integrations exactly like this. What you're describing is similar to what we do for predicted projectiles, yes.
We reused the concept from Team Fortress 2, which is when Valve first implemented the concept, I believe. But the idea is as old as when QuakeWorld first came on the scene. I think I remember Carmack specifically talking about how projectiles wouldn't be predicted in his .plan files, but the overall feel would be much better.
This is correct. QuakeWorld pushed the limits of real-time networking projectile detection by keeping a small history buffer of interpolated data for the server to perform lookups and hit checks. It was never perfect but it was good enough for fast paced QW games.
We were doing some experimentation with a future Planimeter Game Engine 3D product, but will be moving back to Game Engine 2D development this upcoming quarter, with a new website planned, a getting started tutorial path, and sample game code included from internal projects. The current version includes example code in the game folder.
I am hoping that a getting started path will encourage new users to help one understand core workflows we've designed for developers, starting with creating entities in a test map, and then updating those levels, and finally, building your own fully-custom features which tie into premade systems.
I'm really looking forward to this. The fact is that there's no game engine (that I could find after hours of searching) that offers out-of-the-box multiplayer for skilled programmers who just want to make a game, and if Planimeter can deliver that _and_ have good documentation and a clear ramp-up path, it would appeal to a huge audience.
Thanks, that's been our #1 complaint about large mainstream engines like Unreal, Unity, and Godot. None of them have working out-of-the-box multiplayer (Unreal is the closest, but by default it rubberbands worse than Goldsrc!), and we find it super weird.
Otherwise, we wouldn't have written our own engine.
Are you guys going to separate the networking code from the engine? I would love a sane networking framework to use with Unity/Unreal. I've been writing my own source-esque networking to work with Unity but it's far from perfect. I would love a solid open source implementation here.
I've been wanting to do this for years. It's still sitting in my IDEAS.md[1] file. But it does require some abstractions that sit above reliable UDP or other alternative transports.
You need an idea of entities or at least some abstraction for a rewind buffer so that you can make calls to some sort of reconcile or predict function.
I don't have an idea of what that looks like in my head. I'd have to think about it. I know it can be done.
your granularity upper bound being the framerate is a result of LÖVE not passing SDL timestamps as well as it doing SDL_pumpevents once per frame, so even if you try to timestamp the individual events they are still bunched up into the start-of-frame rather than accurately being able to do sub-frame rollbacks.
To be fair, I think the way SDL hand wave the processing into one lumped Pumpevent is where the blame lies —- it is just a compromise made for the sake of being a cross-platform abstraction so they had to make it a black-box invocation
There is still an upperbound where additional granular game states don't occur and that upperbound is based on framerate, afaiu.
We use a similar system in Planimeter Game Engine 2D.[1]
Planimeter engineers are former Source Engine developers.
[1]: https://github.com/Planimeter/game-engine-2d/wiki/Tick_rate_...