spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn ein Client diese Animation berechnen und daraus logische Kommandos berechnen kann, dann geht das genauso gut auch andersrum.

Der Server sollte den aktuellen Zustand aller Spieler an die Clienten schicken, entsprechend kann dann jeder Client die Animationen für die anderen Spieler abspielen (zB Laufen oder Fahren).

Eingaben über Maus- und Tastatur sind ja letztendlich nichts anderes. Daraus werden Requests an den Server generiert (eventuell unabhängig davon zur Lag-Reduzierung die Aktionen im Client trotzdem erst mal direkt ausgeführt), der schickt sie an alle Clients und jeder setzt diese dann um. Ist also eigentlich im Grundgedanken keine große Magie dabei. Spannend wird es erst bei erwähnter Lag-Reduzierung, wo Clients die Aktionen auch schon ohne Server-Response als "korrekt" annehmen oder aus vorherigen Aktionen (Bewegungen) eine Extrapolation vornehmen.

Ich glaube bei Quake werden übrigens die Animationen mitgeschickt.

Da glaubst du richtig. Bin mir relativ sicher dass hier irgendwo im Forum noch ein Link rumgeistern müsste, wo das alles beschrieben wird. Wobei man mittlerweile Spiele oder allgemein Software abstrakter aufbaut. Von daher macht eine Trennung von Ausgabe und Logik Sinn und solange der Server nichts anzeigt sollte er sich über sowas keine Gedanken machen. Dazu hat BlueCobold ja schon geschrieben, dass aus den Eingaben am Client ein Befehl generiert wird, und aufgrund des Befehls kann dann jeder Client selbst seine Ausgabe bestimmen. Ich ich jetzt aufgrund einer Tastatureingabe eine Animation abspiele, oder aufgrund von Befehlen vom Server reagiere macht an sich keinen Unterschied. Man kann einfach mal versuchen sich ein schönes Schichtenmodell zu erstellen und Logik, Entitäten und Ansicht "komplett" voneinander zu trennen. Dann fällt der Groschen vielleicht schneller als wenn man es sich nur vorstellt.

Um ein Problem bei der Trennung von Darstellung und Logik mal vorweg zu nehmen: Wenn man Waffen/Mündungen etc. an einem Skelett/Turm etc. hat, muss man das (reduzierte) Modell auch auf Serverseite laden und animieren, wenn man dem Client nicht vertrauen will.

Ich entwickel gerade ein multiplayer Aufbauspiel, in dem ich sogar eine ganze Instanz des Spiels auf dem Server laufen lasse. Um das zu ermöglichen muss man natürlich Logik und Darstellung sehr stark voneinander trennen. Bis jetzt läuft es aber ganz gut.

Zitat von »NachoMan«

Ich entwickel gerade ein multiplayer Aufbauspiel, in dem ich sogar eine ganze Instanz des Spiels auf dem Server laufen lasse. Um das zu ermöglichen muss man natürlich Logik und Darstellung sehr stark voneinander trennen. Bis jetzt läuft es aber ganz gut.

Muss man nicht unbedingt, solange man den Rendering-Teil einfach deaktivieren kann. Meine Modelle sind z.B. nicht nur Modelle, sondern gleichzeitig übernehmen sie auch ihre eigene Darstellung (was nicht unbedingt MVC-konform ist, aber ich finde es praktisch so). Dennoch kann ich das Rendering komplett deaktivieren und könnte es als reinen Server laufen lassen. Man muss also nicht generell stark trennen zwischen Logik und Darstellung, sondern es reicht, wenn man diese Teile unabhängig voneinander aufrufen kann. Klar, man darf nicht sowas machen wie eine Methode "updateMyPlayer", wo sowohl sämtliche Logik ausgeführt, Kollisionen berechnet und auch noch das Rendering gemacht wird. Das wäre aber insgesamt ein sehr gutes Beispiel für schlechtes Design oder schlechte Kapselung.

Das Problem ist, dass für die Darstellung Bibliotheken benötigt werden die für einen Server unnötig sind und die, wenn man z.B. DX verwendet, auf der Serverplatform vielleicht garnicht verfügbar ist.
Ausserdem benötigt man viel Speicher für Dinge, die man eigentlich garnicht benutzt.

Deswegen sagte ich ja, dass den Server das nicht interessieren braucht. Bei mir wäre das egal, die Bibliotheken würden nicht benötigt werden. Auch wichtig wäre die Frage was ein Server ist - ein zentrales Programm auf einer echten Hardware genannt "Server" oder einfach nur einer der Clients, welcher ein Multiplayer-Spiel hostet.
Wenn man wie ich auf C# mit Schnittstellen zu DLLs setzt, dann ist Portabilität aber z.B. auch vornherein gar nicht notwendig und nie geplant gewesen. Ist halt relevant, was man eigentlich will. :) Trennung zwischen Logik und Grafik auf irgendeine Art, ist generell aber sicher wichtig, schon weil alles andere einfach sehr schlechtes Design wäre. Entweder ich mache ein Update der Logik oder stelle was dar, das sollte man in keiner Methode irgendwie zusammenpanschen.