public interface IPredictedInput<TSelf> where TSelf : struct, IPredictedInput<TSelf>What a client is doing on one tick, as the game defines it.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
A game defines one of these and the engine never looks inside it. Movement axes, a look direction, which buttons are down — it is a struct with a codec, exactly as IBroadcast is, and for the same reason: static abstract members give both ends the same encoding at compile time, so nothing here reflects over anything at run time and the whole path survives NativeAOT.
Small is the whole point. An input goes out every tick, several times over — see Redundancy — so it is the one payload that is sent more often than a snapshot. Quantize the axes, pack the buttons into bits, and do not put anything in here the server can work out.
One input type per session. A game whose players and vehicles want different inputs puts a discriminator in the struct rather than having two — because the tick a payload belongs to is what makes it useful, and two streams of ticks that have to be interleaved is a second ordering problem for no benefit.
Methods (2)
Used by (7)
- ClientPredictionVixen.Net
- FuzzInputVixen.Net.Fuzz
- InputBufferVixen.Net
- InputLogVixen.Net
- MoveVixen.Net.Tests
- MoveVixen.Net.Tests
- PlayerMoveInputVixen.Net.Engine