Quote

 

(This already looks slightly flawed to me since it will be very network heavy I guess) 

 

What do you mean by "network heavy"? What kinds of properties change about your game entities; how many entities are there; and what other mechanism would use much less data?

Quote

 

This also means that I need to be able to send a lot of different kinds of data over network, and that at the beginning of the game I need to send data about the whole world.

 

Yes, all networked games know how to send property updates for their entities, and how to send the initial game conditions when a player joins. For games that don't support late drop-ins, everyone is just told "here's where the players are, and here's the level file you load from disk," for any game that supports late joining, the state of any entity that changed (or spawned, or died) compared to the initial level file will have to be sent on join. No way around that!

In general, game networking engines keep track of which player has seen what changes from what objects, and in every network tick (which is typically between once a second and 100 times a second, depending on game) the game will look at all the un-acknowledged changes for a particular player, select those that are "most urgent," and pack those into a packet that it queues to the player. An update that has been sent, but not yet acknowledged, may be given less urgency for a little bit, but if it remains un-acknowledged, it may pop up in priority again.

Typically, priority for a particular update for a particular player will be based on what that player is close to, who/what that player is interacting with, how big/scary/dangerous the entity is, and so forth, in addition to how long ago the player last got an update for the entity.

If you detect that the player suffers packet loss, you can assume that you are sending too much data, and reduce how often you generate-and-send packets, and also increase the tolerated time between entity updates. You can also introduce a "view distance," where entities too far away aren't shown to the player, and reduce this distance to reduce amount of bandwidth consumed. Similarly, if you detect that there's no packet loss, there may be more network bandwidth available, and if you're not already sending everything you want at the frequency you want, you could turn up the frequency/size a little bit.

There are other models. Most importantly, the "lockstep" model, where players only send inputs, and the input from all players for step X is received on the server before the simulation is allowed to advance to that step. Similarly, each client must run the same simulation with exactly the same (deterministic) math, and will wait until they have the inputs for all players sent to them before they advance simulation. Command latency will be high, and is usually hidden through some kind of "yes, sir!" acknowledgement animation (hence, why this model is most common for real time strategy games, but also works for RPGs, turn-based games, and so forth.)

Late joining (and dropping) in a deterministic game is often quite disruptive, and these games tend to have more lag in cases of those type of events, not to mention all the command latency involved, so this is not necessarily any better or less bad than the other models.

if I were to run a bigger part of the simulations on the machines of the different players, I could avoid quite a bit of the "network flow"

You need to send a flow of state updates anyway, because you need to put the clients back in sync when they de-sync, even if they simulate. Only in the lock-step deterministic model do you get away with sending less. The only question is how much / how often you send the state updates for each entity, and how big the entity state is.

Regarding talking about "game objects," that's fine as far as it goes, but you will also need to talk about "properties" of those objects, and "serialization" for those properties, and "change notifications" (or "diffs") of those properties of those objects. Once you have that, you can build a reasonably efficient representation of what actually updates.

It also matters whether you use TCP or UDP. If you use TCP, you can assume that the player has seen everything you send, although sometimes with a longer delay. If you use UDP, you can assume that players will see updates reasonably quickly, but may miss some of those updates, so you need some kind of acknowledge (and perhaps not-acknowledge) to tell the sender what the receiver actually got and didn't get.