Architecture of networking in game engine

Question

I am currently building a 2d game engine, with the future intention of adding some sort of networking functionality. I have past experience making networking games in Unity and whatnot, however I am sort of conflicted as to how to structure the networking part. So far I have thought of two scenarios:

1. I give a low-level/high-level API to the user to do networking on their own (like UNet I guess?). Basically just building the networking on top of the game engine, which means the other functionalities (like rendering, physics, etc.) don't need to know about networking right?

2. I assume every game is multiplayer (multiplayer with 1 player if single player) and kind of build networking into the engine natively.

In past experiences adding networking to a single-player game is quite hard, and I assume this principle will apply to a game engine as well (ie. add networking later down the line). But this would only be the case if I choose to go with scenario 2 right? Meanwhile if I go with scenario 1, I could just add networking whenever because the game engine isn't dependant on it. Or am I misunderstanding something?

Answer 1

If you go with option two, there's a good chance you'll make things harder for game developers that want to build a single-player game. So, your choice depends on what goal you have in mind for the engine that you're building.

Making multiplayer functionalities the core of the engine can be super interesting for game devs who want to focus on that, but you'll need to take into account things like lag compensation, client-side prediction and other features for a multiplayer deterministic engine.

If your goal is just to make a fun 2D game engine that can appeal to a broader audience, I would go with option 1 and just give the building blocks of multiplayer networking so that developers can use them for their specific needs.