Networking in S&box

[peter-r-g]

What do you all think about networking in S&box? Below I have left some questions that you can answer to give a better insight into your experience and what could be changed.

• What works well?
• What does not work well?
• What changes could be made in the API to make it work better for you?
• What is your experience with the networking code generation around [Net] and [ClientRpc].
• Do you use BaseNetworkable? If not, why not?
• Do you use INetworkSerializer? If not, why not?
• Do you use entity components? If not, why not?
• Do you use custom networking through web sockets? If not, why not?
• Any ideas you have for networking instead of the client/server architecture currently used?

[peter-r-g]

I think the client/server with client prediction works well. It just needs some more love and features in my opinion. The INetworkSerializer interface is nice to have in some situations but at least for me, it goes mostly unused because I can't make one-time changes either way. If I make a change to any part of the class I have to re-serialize the entire instance. Maybe having additions to the INetworkSerializer where you can read/write single changes would be a good step forward.

Currently, RPCs are only supported by entities. While that does work most of the time it becomes a problem when you want to break your code up into base networkable or component classes and now you have to jump through hoops of entities to make your code more usable across entities. Additionally, there is no support for ServerRPC currently.

With ServerRPC, if/when it is implemented it would be nice to have control of how much it gets used to prevent a bad client from spamming RPCs to the server. Having something in the attribute like UsageLimit to control how many times it can be used by a client every X amount of time. When a client exceeds that make use of the Event system so a game can control what happens when a client hits the limit.

For the code generation around networking. I find that it breaks very easily if you stray too far from a very basic path. Once you start messing with networked classes or setting default values to your networked properties it will either prevent your game from compiling or produce strange behavior that stops you from using those C# features. A problem I have run into personally was the property default values and I have made an issue of it here. I obviously cannot make an educated guess on the inner workings of the networking in S&box/source but maybe steering away from such a reliance on code generation on networking could make some of the pain points easier to bare.

As for support on networkable types. While being able to "easily" network a list or a dictionary is nice. In the ILists case it can only be implemented as an IList which is then in the background created as an ObservableList which then comes with a set of weird behaviors documented here. Personally, I think it would just be better off to create wrapper classes of these types like NetworkedList<T> and NetworkedDictionary<TKey, TValue> which have implicit conversions to the List<T> and Dictionary<TKey, TValue> types. That way you avoid the strange behavior and know exactly what you're getting out of it. On top of that, it could be implemented in such a way that can be used by the end developer. So then people can run wild and create their own networkable classes and wrappers for things they may need.

As for the client authoritative method mentioned in Discord. Introducing base classes for web sockets that work both client and server. As far as connecting to a game goes, it stays the same. But once a client is in a game it is handed off to the game's web sockets to handle any kind of networking of state and entities. Of course, S&box would still need to handle things such as ping, timeouts, connects, disconnects, etc still. But a lot more control can be given over to the developer to customize their own networking system. With the client web socket, it can still be used as it currently is to connect to external servers for other game features.

[Fortune117]

I use networking a tonne alongside entity components - I really enjoy the current implementation. If there were two things I'd consider major improvements it would be:

• a proper ServerRPC
• RPCs on EntityComponents

For instance, I have this in my player class alongside a tonne of BindComponents

Components.Create<PsyHealthComponent>();
Components.Create<BleedComponent>();
Components.Create<HumanLimbsComponent>();
Components.Create<InventoryComponent>();
Components.Create<EquipmentComponent>();
Components.Create<TargetComponent>();
Components.Create<HeadGearComponent>();

Perhaps adding some way to have these automatically created on spawn using an attribute would be a nice change as well, like:

[BindComponent, CreateOnSpawn]
public HeadGearComponent HeadGearComponent { get; }

I've networked a tonne of things over the course of making my game, from a limb based health system, to an inventory system, as well as predicted phys bullets and I've generally been able to achieve anything I needed without too much difficulty.

[matekdev]

Would be nice if networking supported this as well
#2108

[LeQuackers]

I'm making a gamemode with various Pawn classes and all of them are slightly different. Using inheritance in this case makes the code very messy because of all the casting and special cases. For example, one Pawn might only be able to use IUse entities, another might have an active child, and the third might have both. Because of this I chose a composition model for Pawn classes, which definitely cleaned up the code; however, this trades one problem for another: networking.

I've tried pretty hard to get entity components to work with this, but they aren't pridicted/simulated right now (#2624 and #2591). The only one I was able to get working was an entity component equivalent to the Player.Use.cs stuff, but only because it doesn't network anything; it just needs to be simulated.

As a workaround I've been experimenting with using a "pawn proxy" entity that acts as a wrapper for a given gamemode's Player/Pawn, which allows you to wrap its Simulate method and add [Net]/[Predicted] properties to it indirectly. Like entity components though it has its issues: whenever the "pawn proxy" is casted it breaks stuff (switching weapons, spawning things, pressing the use key on things, etc.) and on top of that most of the properties on the actual Player/Pawn (at least in the default sandbox gamemode) aren't virtual, which requires a lot of workarounds. The test addon is called "Double Jump" and it's available for the default sandbox gamemode (here's the repo if anyone's curious).

And now for plan C: using the event system. The current plan is to try to get an Event.RunWhere<T>(string name, Predicate<T> predicate) method added that would allow you to control which methods are actually ran for a given event (#2631). The idea is to use Event.RunWhere to only call the pre-simuate and post-simulate events for the correct client being simulated and have predicted/simulated entities registered with said events. It would look something like this:

public abstract partial class Game : GameBase
{
	...

	public override void Simulate(Client cl)
	{
		if (!cl.Pawn.IsValid()) return;

		// Block Simulate from running clientside
		// if we're not predictable.
		if (!cl.Pawn.IsAuthority) return;

		Event.RunWhere<Entity>("entity.presimulate", x => x.Client == cl, cl)
		cl.Pawn.Simulate(cl);
		Event.RunWhere<Entity>("entity.postsimulate", x => x.Client == cl, cl)
	}
	
	...
}

public partial class DoubleJumpEntity : Entity
{
	[Net, Predicted]
	public bool AlreadyDoubleJumped { get; set; }

	protected bool OnGround { get; set; }

	[Event.Entity.PreSimulate]
	protected virtual void PreSimulate(Client cl)
	{
		var pawn = cl.Pawn;

		OnGround = pawn.GroundEntity?.IsValid() == true;
		if (OnGround) AlreadyDoubleJumped = false;
	}

	[Event.Entity.PostSimulate]
	protected virtual void PostSimulate(Client cl)
	{
		var pawn = cl.Pawn;

		if (!OnGround && !AlreadyDoubleJumped && Input.Pressed(InputButton.Jump))
		{
			AlreadyDoubleJumped = true;
			pawn.Velocity = pawn.Velocity.WithZ(300);
		}
	}
}

public void GiveDoubleJump(Entity pawn)
{
	new DoubleJumpEntity
	{
		Parent = pawn,
		Predictable = true
	};
}

Hopefully this one works. I would really prefer the Player/Pawn composition stuff to use entity components, but honestly entity components need a lot of love right now, so for the time being I think using actual entities for simulated/predicted stuff is the way to go.