spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Bei einem Spiel wie WoW müssen aber viel weniger Daten übertragen werden als bei einem Spiel in Richtung Battlefield, schon alleine weil dort die Daten viel zeitkritischer sind.

In dem Zusammenhang könnte Designing Virtual Worlds durchaus interessant sein. Zu beachten dabei ist, dass mit "Virtual World" in dem Zusammenhang nicht jede beliebige Welt/Umgebung eines jeden beliebigen Spiels gemeint ist, sondern dass diese diverse Anforderungen erfüllen: Ich kann gerade nicht nachlesen, allerdings dürften diese Bedingungen mehrere "Benutzer", Einfluss der Benutzer auf die Welt und ein gewisser Grad an Persistenz sein.
Im 2. Kapitel wird bereits darauf eingegangen, wie im Groben die Struktur der Server (häufig) aussieht. Dabei werden die verschiedenen Möglichkeiten genannt, um die Spielerlast möglichst gut auf die verschiedenen Server zu verteilen (Load Balancing).
Da ich gerade erst am Lesen bin (Seite ~ 150 von ~ 700), kann ich noch nicht sagen, welche weiteren Punkte alles bezüglich des Themas von Interesse sind.

Aber bevor du dich jetzt überstürzt in diese Thematik wirfst: Je nach Art und Umfang deines Spiels wird es entweder ziemlich komplex oder viel zu komplex, als dass es alleine umgesetzt werden könnte.
Damit du dich nicht übernimmst, solltest du die Interaktionsmöglichkeiten der Spieler untereinander und der spieler mit ihrer Umgebung möglichst gering halten. Selbst wenn du das ausreichend gut hinbekommst, wird ein großer Brocken Netzwerkprogrammierung auf dich zukommen, der nicht zu vermeiden ist. (Vielleicht zu vereinfachen, ich kenne mich mit entsprechenden Bibliotheken nicht aus, aber in jedem Fall aufwendig.) Und sollte das erstmal implementiert sein, fehlen immernoch Dinge, wie eine gewisse Skalierbarkeit beispielsweise.
Bevor ein solches Projekt begonnen wird, sollte vorher ein einafcheres Mehrspielerspiel umgesetzt werden. Und bevor dieses umgesetzt wird, sollten ein paar einfachere Spiele mit Singleplayer oder lokalem Multiplayer umgesetzt werden.

Es wird dich wohl niemand daran hindern, dass du ein solches Projekt mal in Zukunft umsetzen wirst, aber du solltest nicht enttäuscht sein, wenn es wirklich erst in etwas entfernterer Zukunft etwas wird. (Ich kann nicht einschätzen, wie gut oder schlecht du bist, aber grundsätzlich würde ich dir dazu raten, vorher die bereits erwähnten Spiele umzusetzen.)


@Cookiezzz:
Damit hast du etwas angesprochen, was ebenfalls in Designing Virtual Worlds beschrieben wird.
Aber es stimmt schon, was du geschrieben hast. Wesentlich einfacher wird das ganze auch dann, wenn es sich um ein Rundenbasiertes Spiel handelt, da der genaue Zeitpunkt eines Ereignisses dann weniger von Bedeutung ist.

Ich denke, wer die Frage danach stellt, wie viele Spieler in einem Game möglich sind, ist leider nicht qualifiziert so ein Projekt überhaupt durchzuführen. Wenn man Erfahrungen hätte, könnte man anhand des Genres und des eigenen Budges in etwa schätzen, wie viele man supporten kann.
Das soll nicht böse gemeint sein, es ist einfach mal so. Du darfst uns mit Deinem Team natürlich gern das Gegenteil beweisen und niemand wird Dir Dein Vorhaben verbieten wollen.

Meine Diplomarbeit (Ende 2011 abgegeben) ging in die Richtung dieser Fragestellung. Schwierig sind vor allem physikalische Simulationen über die Grenzen eines physikalischen Servers hinweg. Das kriegen die bei dem System von Pikkotekk auch nicht gut hin, Pikkotekk wurde ja von poorsider erwähnt (siehe David Almroth - PikkoServer, how to scale game servers and enable player density. 26:00:-27:28).

Sofern keine Probleme mit eher quadratischer Komplexität provoziert werden (Kollisionserkennung mit hoher Objektdichte), wird eher die Bandbreite ein Problem, das ergaben jedenfalls meine Studien.

Big World Tech haben 2011 was von 100.000 simulierten Spielern auf ihren Servern erzählt (AFAIK ohne Kollisionserkennung): http://www.youtube.com/watch?v=bzrSaTIWEVc

Im GD Mag gab es mal einen Artikel für ein FPS Spiel mit 256 Spielern (inkl. Kollisionserkennung) leider ja offline, ging vor allem um die geschickte Verteilung der Spieler und Replikation.
Luo, L. (2010). Big Wars - Server Architecture for 256+ Simultaneous Players Real-Time Multiplayer Games. Game Developer Magazine, September, 7–13.

EVE Online bekommt bei größeren Spielerhäufungen auch Probleme, die haben deswegen einfach die "Zeit" verlangsamt. Eine ziemlich pragmatische aber effektive Hernagehensweise:
http://wiki.eveonline.com/en/wiki/Time_Dilation

Beim Begriff Server muss man übrigens aufpassen, i.d.R. wird der Begriff in Computerspielen eher für Shards/gemeinsame Interaktionsräume verwendet und nicht für die physikalischen Server. Das sind meistens mehr, ich denke das gilt mit Sicherheit auch für PlanetSide 2.

Für meine DA habe ich einen einfachen auf Kombinatorik basierenden Algorithmus gebaut, der ein "N zu N" Problem auf mehrere Server verteilt. Irgendwann schreib ich auf ZFX oder so mal was dazu. Das ganze hat bei entsprechend hoher Objektdichte auch wirklich Verbesserungen gebracht. Meine Benchmarks sind allerdings nicht besonders stichfest, da sie zwar mehrmals durchgeführt wurden, aber immer auf Servern in der Cloud... naja aber immerhin gab es überhaupt eine Konstellation in der der Algorithmus die verteilt laufende JBullet Physik Simulation verbessert hat, das hat mir schon gereicht . Meine letzte Zusammenfassung der Ergebnisse waren Ticks pro Sekunde bei 1000 Objekten in einer Physiksimualtion mit hoher Objektdichte: 1 Server ~17; 3 Server ~21; 6 Server ~26; Hier steht auch ein bisschen was dazu: http://zfx.info/viewtopic.php?f=10&t=112&start=495#p27266