netcode | A protocol for secure client/server connections over UDP | Networking library

As a general rule when dealing with sockets: you should usually be working with oversized arrays (ArrayPool.Shared can be useful here), and then use the Send overloads that accepts either the byte[], int, int (offset+count), or ArraySegment - so you aren't constantly re-copying things, and can re-use buffers. However, frankly: you may also way to look into "pipelines"; this is the new IO API that Kestrel uses that deals with all the buffer management for you, so you don't have to. In the core framework, pipelines is currently mostly server-focused, but this is being improved hopefully in .NET 5 as part of "Bedrock" - however, client-side pipelines wrappers are available in Pipelines.Sockets.Unofficial (on NuGet).

To be explicit: no, constantly calling ToArray() on a List is not a good way of making buffers more convenient; that will probably work, but could contribute to GC stalls, plus it is unnecessary overhead in your socket code.

I applied two changes that made it work:

The player that had deleted the hurt() function would be invincible.

Not if a "master copy" of the game state is computed by the server. In that case, the player who modifies code will only have their client show an invalid game state, which doesn't help them play.

In general, everything except player input must be done by the server, the client only says what the player chooses to do and every resulting action/change is performed by the server. That way, the player cannot change anything except what they want to do, which is already under their jurisdiction.

Note that players can still cheat with the aid of tools, such as auto-clickers or aimbots. These forms of cheating are much harder to deal with, since it's hard to tell if someone is receiving inhuman assistance or if they're just a good player.

I see that you are using Swift 4's NSAttributedStringKey so I added that tag to your question.

You must make the telephone URL manually and set isSelectable = true otherwise no interaction can happen from within the text view:

There is nothing to stop you doing this. In fact, this is probably what I use protocols for more than for delegates etc...

However, I'd think about what you call the objects and the protocol.

A delegate is some object that your main object "delegates" work to. A table view (for instance) knows it has to have a number of rows, sections, etc... but instead of calculating those itself it says "my delegate is going to do this work for me". It then allows the same tableview to interact with any delegate.

Your objects are obviously not like that as there are many of them. They may all have some common usage though. What is that usage? Is delegate the right word to use?

If they are all "Listeners" then it would make more sense to call the protocol Listener with a function someListenedToActionWasTriggered and to call the array listeners.

Well, there is certainly room for optimization. Since you are quoting big game engines as a reference, I will give you some examples based on the older Unreal Engine versions and some of the optimizations they are using:

• Network packages use the UDP protocol. It still needs to take care of dropped, duplicated or out-of-order packages on its own, but it swallows that bitter pill instead of using an actual TCP connection because the latter would introduce even more overhead.
• The server keeps track of which information updates it did send to clients. For every object on the client side that is replicated by the server, the server keeps track of all variables. At the end of each game loop update, the server will check which variables actually have different values from the last time the server sent an update to the client. And only if there is actually a difference, the new value is sent to the client. That may seem like an incredible overhead, but network bandwidth is a much scarcer resource than system memory and CPU time.
• Vector information is actually truncated before being sent over the network. The engine uses float as datatype for its vector components, but it still rounds X, Y and Z to the nearest integer and transmits those instead of the full floating point data. That way they only take up a couple of bits to a few bytes, rather than 12 bytes of the uncompressed original floats.
• Position updates are simulated on the client-side and merged with the incoming data from the server. To avoid jittering from position updates, clients predict the new position of an object from its velocity value. When the client receives a position update from the server later on, it will gracefully move the object slightly to the new position (basically a compromise between the client and server coordinates) and only do a hard update if the server's position differs too much from the client's version. This is done with a lot of things. If a player shoots a projectile, that shot is performed on the server, which will create the projectile and send it to the player to update its position. But the player will also receive the function call about the shot and create the projectile locally and update its trajectory. Even if that projectile can't actually kill a player on the client side, its trajectory and effects can still be simulated locally to give the impression of smooth gameplay. If it hits something, the appropriate effects can be played at the location without requiring the server to tell the client to create those effects.
• The server keeps track of what is relevant to each player. If a player is on the other side of the map behind several walls, it doesn't need to send you any updates about that players actions. And if a projectile of that player happens to come into your view later on, the server can still tell you about those projectiles at the appropriate time.

The whole matter is a lot more complex than what little I can cram into this post, but the gist of it is probably: network bandwidth is the most limited resource in multiplayer games, so the engine goes out of its way to send as little and few information packages as it can get away with.

Notice something? Less than a single component of your position vector would already be considered way too large for the entire vector in this engine. I guess JSON really introduces some overhead here, simply due to its verbosity. You are sending numbers as strings when you could also be just sending their actual bits and infer their meaning from the actual package.