I'm designing it to be a networked game from the beginning on. The problem I currently have is the question: Where does the User input information belong?

Let's assume we have a server and two clients. Both clients have player entities which exist on the server and all clients.

When client 1 presses a key, it sends it to the server. Should the server send it to the other client?

Also, my question is also a little about code design.I want to have the same code running on the server and both clients. But when I have my PlayerEntity, it expects Mouse input. But on client 1 I have both PlayerEntities from both clients, and it only has mouse input for one of them - the Player they are actually ment to play.

A possible solution I thought of was this: Every client already has a unique connection ID. Whenever a client creates an entity, the entity will be dedicated to a connection ID, if it needs to have specific client input, or not, when it's an enemy for example (spawned by the server).The client sends it's input to the server and the server sends Input Deltas in the form of: Connection ID -> Mouse Input. All clients know of the inputs of all other clients and therefore they can even predict the movement of a player.

My actual question is: How would you solve it? How did you solve it? How do AAA games solve this problem?

I'm designing it to be a networked game from the beginning on. The problem I currently have is the question: Where does the User input information belong?

You don't need to design your game\engine with networking in mind. When I was developing JevaEngine, there was no consideration for networking. The networking isn't apart of the engine or rpg game at all. It really shouldn't be either because it obscures the purpose and function of the class with a bunch of networking and syncing code.

What you should do is design your entities so that they allow for Observers, using the Observer Pattern.

If you implement the observer pattern for your entities, you can observe them through another module (i.e, the server) and notify users of your observations. The users will then mutate their local entities to sync up with the server.

Quote

When client 1 presses a key, it sends it to the server. Should the server send it to the other client?

That is almost the right idea, the problem with doing it at such a level you describe (syncing input) is it is incredibly difficult to maintain synchronization through that method and it works on a much too abstract level for the server to optimally distribute accross clients.

Intead, while observing your entities you catch observations you want to be synchronized (i.e, pressing somewhere to move to some point B) The entity will begin moving to B and the server can broadcast taht observation to clients.

Here is how moving works in JevaEngine:

The client character class attempts to travel to point B. The client will dispatch a message telling the server that it would like to move to point B. The server responds by moving it's corresponding player entity to point B (notice at this point the client's player entity hasn't actually moved yet.) The server will then notify the client of the mutations performed on the server-side entities and where it is moving. I.e, the client should never mutate an entity's state unless it is told to by the server.

Send commands not raw input. Raw input is improper because it does not provide an appropriate level of abstraction. Individual objects should not care if I pressed the up, W, I, or 8 key or if I used the mouse or if I used a touch screen gesture. If you can, then aggregate multiple commands and remove canceled commands before sending them to reduce bandwidth. Your commands should be enough to reproduce a game on any client for the purposes of synchronization, debugging, or replay "videos" no matter what input method the user has. (Or even if their is no user, such as on a server or for an AI.)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org