Im groben läuft es ähnlich ab wie du beschrieben hast. Wenn auf einem Client etwas passiert, schickt der dieses Update an den Server, und der wandert seine Client-Liste durch, und schickt jedem ein "Hallo, hier neue Daten für ...". Dazu sollte man sich ein kleines Protokoll ausdenken, wie man welche Infos kenntlich machen will, und in welcher Form sie verschickt werden. Das Senden zum Server macht man dann am besten Event-gesteuert, ggf. mit einer Limitierung auf n Mal pro Sekunde. Daher macht es auch meist eher Sinn absolute, nicht Deltawerte zu schicken, da man sonst schnell Probleme mit asynchronen Clients bekommen kann.
Eine Stufe weiter wäre dann ein Server, der etwas intelligenter ist, in dem er z.B. nicht blind alle Updates an alle Clients schickt, sondern die Spiellogik kennt, und entscheiden kann für welche Clients diese Info überhaupt relevant ist.
Ob und wie genau man funktionalen Code auf wen verteilt ist dann nur im konkreten Fall wirklich zu eintscheiden, jedoch dürfte das für dein einfaches Beispiel noch lange nicht relevant werden.
Ich persönlich würde zu UDP tendieren, dann allerdings mit einer kleinen eigenen Implementierung eines Acknowledgement-Systems, da ja doch schon mal hier und da ein Päckchen unter geht. Das aber auch nur aus Erfahrungen im LAN, ich weiss nicht, ob im WAN die Latenzen durch das Netz die Geschwindigkeitsvorteile von UDP aufwiegen. (Ich weiss garnicht, ob Router untereinander auch ACKs austauschen.) Der wesentliche Vorteil von
TCP ist halt die implizite "Ankommsicherheit" (so denn das Netz selber nicht weg bröselt).
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)