netfox v2

[elementbound]

Background

This is an issue for tracking planned changes for netfox v2. Work is currently not being done on netfox v2.

Until we get there, this issue will serve as a living document to add, discuss, and update changes planned.

Goals

The second iteration of netfox should focus on improving the API through breaking changes that we can't do in v1, and to improve performance both in terms of CPU- and network usage.

Compatibility

netfox v2 should raise the bar of minimum supported Godot version to newest at release.

Changes

• Remove autoloads
  • Autoloads, especially when referred to directly, have multiple quirks, and introduce import errors, even though they don't break anything
  • Instead of multiple autoloads, netfox would have a single autoload, without a global variable
  • All netfox globals would be accessed through static fields or static classes
  • See #141
• Organize components into namespaces
  • To avoid name clashes
  • Also to signify which classes are public and which classes are private in netfox
  • Note: At the time of writing, Godot doesn't support namespaces, but there is both a workaround and proposal
• Disable runtime changes to state, input and interpolation configurations
  • Currently, netfox allows for changes to the configurations of RollbackSynchronizer, StateSynchronizer, and TickInterpolator at any time
  • In part, this was needed for #347, so configuration can be changed from code
  • However, having the possiblity of runtime changes makes code difficult to reason about and optimize
  • Ideally, configuration should be set and processed in the editor, before the game starts
  • At game start, each node should have configurations that are ready to use ( e.g. no need to parse property path strings in _ready() ), and are immutable
• Establish definitive coding conventions
  • Keep it reasonably close to Godot recommendations
  • Preferably automate it with tooling and CI
• Dark mode support for the docs site
  • Keeping this in v2, because this would probably mean using a different theme
• Redesign Noray as non-singleton
  • Currently there's an autoload that manages connection and exposes the API
  • Would give much more control to the user if it were something that could be instantiated as needed
  • Possibly something similar to nohub.gd ( version 0.9, https://github.com/foxssake/nohub/commit/8056bb2255e25dd54425f11ee20caed7c2606620 )
• Consider making NetworkEvents non-toggleable
  • There's not much reason to disable it
  • Making it non-toggleable would mean library code could depend on it
• ❔ Remove @tool requirement for procedural configuration
  • Introduced in #347
  • Having to make regular game classes @tool scripts works, but would be better to avoid, if possible
• ❔ Remove shared state ownership support
  • Technically netfox enables setups where RollbackSynchronizer receives state from multiple different peers
  • Since different peers may own different nodes under a single RollbackSynchronizer
  • Not sure how solid this functionality is
  • AFAIK not very widely used
  • In return, complicates the mental model by a lot
  • Could simplify by saying that whoever owns the RBS node owns all the state managed by it
• ❔Remove shared input ownership support
  • See previous point but with inputs
• ❔ Remove Sync to physics setting
  • Original idea was to enable manipulating physics objects from both tick loops
  • Godot by itself doesn't support physics and rollback, so it's not useful there
  • Is there any need to run regular ticks in a physics context?

Use new Godot features

• Introduce typed dictionaries ( Godot 4.4 )
• Use varargs in logger methods ( Godot 4.5 )
• Use abstract classes where appropriate ( Godot 4.5 )
  • BaseNetInput?

[DustieDog]

Organize components into namespaces To avoid name clashes Also to signify which classes are public and which classes are private in netfox

This would also greatly ease building source code generators to automatically keep NetfoxSharp up to date with latest instead of manually updating for each release.

Would there be merit to removing the conditional sim optimization in 2.0? The issue of #383 would still persist as-is, and I've had a great deal of difficulty in finding a solution that works with the current model. It's caused issues in multiple projects (discussed through Discord) which were solved by modifying source code to bypass this optimization, so there's a clear and present benefit to doing so, and can be added back once we have a plan for a more robust model.

All in all, seems like a solid plan for 2.0.

[elementbound]

I'm not against removing conditional sim in v2, though it has to be noted that it didn't start out as an optimization, but as a way to make rollback work at all 😄 My opinion is that people run into issues with it because we don't provide the right primitives to manage it.

However, removing it would free us from a lot of complexity, so I'm happy to investigate the option once we get there, and have some more experience under our belt.