Mfcttrf

So after working on my game engine for 2 years, I´ve decided to step into the networking environment. I just don´t know if its good idea to rewrite the engine, or how much work it will take (but still want to try it). I´m little bit confused by some approaches, so thats why I´m here.

In short I have an architecture like this:
There is a main object, that controls the whole engine world(physics steps, rendering, audio, input, entities). Then there is a Game instance that is running inside the loop and "creating the content of the game".

I already started with ENet, created a small console chatting app - but packets were just strings. But I´m not sure if I understand the concept of game networking, so here is my idea:

There is a server and clients. Server is controlling everything. Client sends messages.

So basically:
When client connects to the server, server creates new entity. Now, for example, when client presses 'A', packet is sent to a server containing this information. Server will proccess it, moves the entity.

Am I right?

So basically, clients does not have anything, except input controller and keyboard. So when they press keys, action is done. And rendering for the scene render, but all they receive is just a "image" of the scene from the server? Or is there something I miss?

Thanks in advance.

Edit1
And also wondering, everything, like physics manager, or whole scene with entities, are present only on the server machine?

TLDR - start simple and build up. Getting to AAA quality networking in an action game is complicated but may not even be necessary for your game.

So basically: When client connects to the server, server creates new entity. Now, for example, when client presses 'A', packet is sent to a server containing this information. Server will proccess it, moves the entity.

Am I right?

Basically, yeah. There are multiple networking architectures, but the common server-authoritative model used in most real-time action games follows that model.

As Bram noted in comments, though, the client typically does have more work to do to overcome network latency even for non-twitch games. The simplest version is to make sure the client acknowledges input before waiting for the server response. Even your Web browser does this (clicking a link animates right away even though it might take some time for the new page to load).

Likewise, the server might have to do a lot of work to overcome the latency as well, depending on the type of game. The server has to keep in mind that by the time it receives any input from the client(s), the player had actually entered that input many milliseconds ago. A common approach is to use object history buffers so the server can simulate "back in time" based on its estimate of when the input was actually pressed on the client.

Going back to the client, some deeper prediction can be required for inputs. For example, a client might immediately respond to input and move, but then adjust that movement based on the eventual response from the server. Various techniques can be applied to smooth over the times when the server response contradicts the client prediction.

Further, the client can't just apply movements from the server for other objects, because that would cause objects to only move when packets come in. A client might have its own small history buffer of positions from the client and smoothly interpolate between them; or the client might extrapolate and predicate movement (though this will result in frequent rubber-banding in many games).

When local player A observes remote player B, local player A can see their own inputs immediately. However, remote player B's movements will be delayed by the time it takes for B's input to get to the server and then back down to player A's client. Every player sees a very stale version of every other player, which can be problematic for games where players are meant to interact at close range frequently. This often just relies on the actual game design avoiding creating situations where this can matter much, as well as on history buffers and the like.

There's a whole 'nother topic about timing and syncing of certain kinds of action, where you might want all players see an ability activate simultaneously despite network latency. Actions might have a warmup animation that is compressed on remote clients so that everyone sees the action happen at near the same instant despite the network latency.

I recommend that you look at the classic Halo GDC talk https://www.youtube.com/watch?v=h47zZrqjgLc.

Edit1 And also wondering, everything, like physics manager, or whole scene with entities, are present only on the server machine?

That depends a bit on what you mean by "physics."

Typically, the server is only going to do physics on objects that affect gameplay. This is both to cut down on server processing costs (physics is CPU intensive) and to cut down on bandwidth costs (synchronizing every little piece of rubble would use a lot of bandwidth).

Depending on the game, the server might do almost no real physics (just very basic capsule movement and ray casts); or the server might do full physics on a small class of objects (set pieces that can move and players can stand on or hide behind); or the server might do full physics on a variety of objects (for games where the environment is highly interactive and can be used against other players).

All the rest of the physics will be done purely on the client. Small debris, background objects, VFX physics, etc. The result will be physics objects that will interact naturally with each other but will be non-collidable or weightlessly pushed around by any server-authoritative objects (like players).

The short version of that being that both server and client need to do "physics" of some variety, but typically on different sets of objects. The client will still apply positions/velocities from server objects into its local sim but can't apply any counter-force (these are typically called "kinematic" objects in most physics libraries/toolkit).

If the client has a 100ms ping to the server, then there would be a delay of at least 6 extra frames between the user pressing a button, and seeing the result, probably more.

Even adding 1 frame from double-buffered rendering causes perceivable delay.

This means that client/server gaming is a lot more complicated than this, and prediction is involved.