Why all the networking solutions (Mirror/Photon/MLAPI) are prefab oriented solutions?

I am a developer from at least 10 years, and start gamedev 2 years ago and i was very unconfindent on how to implement basic networking.

My first doubt was "Why all these frameworks are 'Player' oriented?" Let me explain.

Quicks Steps:
1) Open any network framework build in into Unity.
2) Check on NetworkManager for a "Player Prefab" or "Client Prefabs".

I find it really no sense and ultra constraint to a scenario where a player spawn when we connect. Why these solutions are so popular?

Why put that hard constraints on spawn "Something" on connection? And if i won't? What happen?
These thing warm my mind like hell.

I don't want to built up a philosophical discourse, but i really need to understand why all these frameworks are "player prefab spawn on connection to server" oriented and not general events oriented by default.

I don't want to be ignorant anymore, i need answers.
Maybe it's only my problem, but i need to know if its only mine or not.

 

I have same feeling.
Also annoying when network lib try to manage scenes. What if I dont have scene or have many scenes per map...

So we build our own system that dont need any prefabs or scenes. And then migrate all that system to DOTS.
Now even in editor we have 3 ECS worlds. One general, one for battle host and one for battle client.

 

They do this because they are high level tools. They handle the life-cycle of objects throughout. They "guarantee" (if the setup is right) that they sync the object through the network, including the moment when the player spawns.

You can choose not to use any high level tool and just take any transport library and write your own synchronization and handle the life-cycle of your objects yourself.

 

The traditional Unity way of developing games is around Prefabs and other GameObjects representing the player character and other characters in the game. So, many high level network implementations revolve around those same concepts. If your game functions differently, implement your own high level networking systems which fit the structure of your game, on top of a basic network transport.

 

It is quite common practice for network solutions to provide an abstraction layer on top of events. Having a high level layer which handles network entities and state/events for them just saves a lot of boiler plate. To make such a system work there needs to be some level of contract between the client and the server. (All entities will need to have the same state variables to synchronize properly)

In Unity entities are represented by GameObjects and a specific definition of such an entity type is done via Prefabs. It's just the most intuitive way for a networking solution in Unity to use those built in ways.

A lot of the Unity solutions out there are much more flexible when you dig in deeper.
- Almost all of them allow you to not spawn a player object on connection but instead have full control over object spawning.
- MLAPI allows you to define custom spawn handlers and skip the prefab workflow completely.
- Forge does not even tie network objects to Unity objects. (at least I think that's the case my knowledge about it is quite limited)

So to answer your question I guess, you are right a lot of Unity solutions do the things you mentioned. They do it for convenience and ease of use but often provide other ways to incorporate your own workflows.

 

Also, if I can add something, the "Player prefab" can also be seen as an easy replicated "PlayerController".
You don't have to bind your real player character here, but a high level controller that will spawn your character when you want (ie: not in the lobby for ex).

 

I'll have to admit that all the responses are nice answers! Thanks to all of you! Now my mind is more clear than before. I think i would take a custom event oriented solution, because i have more control on events.

From your responses, i simply just realize that i'm scared from under the hood solutions, even if it works well.
Anyway still not very clear why the need of this high level of abstraction layer.