Die Grenze von MMO's?

[starcow]

Ich bin in einem DAoC Forum auf folgenden Thread gestossen:
http://daoc-guide.4players.de/forums/sh ... line/page4

Da wird diskutiert, dass es eine technische Grenze für MMO's gäbe was die gleichzeitige Spieleranzahl anbelangt. Und die soll relativ klein sein.
Es geht da vorallem um Kampfhandlungen. Wo da der Unterschied zum normalen rumspazieren liegen soll versteh ich ebenfalls nicht.
Es soll dadurch aber schnell zu einem desync kommen können.

Hier ein kleiner Auszug:

Aber wehe es kommen mal 100+ Leute auf einer Stelle auf die Idee sich gegenseitig anzugreifen. Dann geht die Ruckelorgie los und wenn du das darauf anlegst, bekommst du nen ganzen Server damit gecrasht. Das ist kaum auf die Grafikengine zu schieben. Das Problem ist wohl eher, dass dann der Server nicht mehr meinetwegen 200 einzelne Kampfhandlungen an 200 Spieler senden muss, sondern 200x200 wenn die alle auf einen Fleck stehen. Und dann beginnt die Kacke halt zu dampfen. Deshalb wäre ich auch sehr skeptisch, bei MMOs die so etwas nicht während der Beta testen um zu sehen was überhaupt möglich ist. Dann kommen dann so Aussagen wie: "Jeah wir haben 500 Bots spawnen lassen, lief awesome". Und? Musste da auch der Server an 500 Clients entsprechende Daten übertragen? Wohl kaum.

Was sagt den ihr als technische Experten zu diesem Thema? Ist es tatsächlich so, dass wir wohl nie MMO's erleben werden indenen sich in Echtzeit 1000 Leute angreifen? Kann mir vielleicht jemand vereinfacht erklären, an was das liegt?

Gruss starcow

[Florian Keßeler]

Das Problem ist, wie schon in deinem Auszug beschrieben, dass du im schlimmsten Fall n^2 viele Kampfhandlungen gleichzeitig laufen hast, was besonders dann schwierig wird, wenn es für die Spieler auch tatsächlich die Möglichkeit gibt, viele andere Spieler anzugreifen (zum Beispiel bei Flächenangriffen wie Feuer oder ähnlichem). Wenn andererseits so etwas nicht auftreten kann, wird es für Spieler schwer, mehr als eine maximal zweistellige Anzahl an anderen Spielern anzugreifen. In dem Fall dürfte die Aussage bereits jetzt nicht zutreffen. Und in dem anderen Fall ist es eigentlich nur die Geduldfrage, bis Netzwerk- und Serverhardware wieder mitkommen. Die dürften noch eine Weile exponentiell leistungsfähiger werden (Moore's Law), während die Anzahl der gleichzeitig stattfindenden Kämpfe quadratisch mit der Spielerzahl wächst.

Also sehe ich da kaum ein prinzipielles, sondern eher ein momentan noch technisch begründetes Problem.

[Jonathan]

Also, wenn man Videos streamen kann, ist es auch kein Problem, die Aktionen von tausend Kämpfenden Spielern an einen zu streamen. Und ob man jetzt alles an einen oder 1000 Leute schickt, macht auch keinen so großen Unterschied. Die Frage ist vermutlich nur, wie viele Serverkapazitäten man braucht, dass es aber prinzipiell derartig explodieren soll, dass es unmöglich wird, halte ich für sehr unwahrscheinlich.
Aber Server kosten Geld, also kalkulieren die Betreiber da entsprechend minimal.

ALso, die Kampfhandlungen und Schadensberechnungen mögen quadratisch steigen, aber die Anzahl der Spieleraktionen steigt nur linear mit der Anzahl der Spieler, und mehr sollte man ja ansich nicht übertragen müssen.

[Florian Keßeler]

Du willst ja dem Spieler auch Feedback geben, in dem du ihm anzeigst, wie viel Schaden er bei jedem anderen gemacht hat, wer ihn angreift u..

Wenn jeder Spieler -- sagen wir -- einen Blizzard castet und jeden anderen Spieler damit trifft, musst du jedem der Spieler eine Meldung über jeden getroffenen Spieler schicken. Bei tausend Spielern eben eine Million Ereignisse. Jedes dieser Ergeignisse muss irgendwie in deinem Stream kodiert werden, das geht leider nicht mit ein paar Byte wie bei Videos, die man dann auch noch verlustbehaftet komprimieren kann. Also ganz so easypopeasy ist das leider eben doch nicht ;-)

Klar kann man das geschickt verpacken und ähnlich wie bei First Person Shootern die Clients alles mögliche vorberechnen lassen, aber schlussendlich musst du doch jedem Spieler den Zustand jedes anderen Spielers mitteilen...

Nachtrag: Dieses letzte Problem ist mir grade vorher noch entgangen. Du musst natürlich auch ohne Kampf jedem anderen Spieler mitteilen, was die anderen Spieler in seiner Nähe tun. Je mehr Spieler in der Nähe sind, desto schlimmer.

Ich weiß noch damals bei LotRO gab's Proteste gegen die Nichtsnützigkeit der GMs. Es haben sich ein paar Hundert Spieler (friedlich, weil kein PvP möglich) in einer Gegend getroffen und das ganze ging echt übel zu. Daraufhin haben die GMs angedroht, wer die Versammlung nicht verlässt, würde für eine Woche gesperrt werden. Wird wohl bei anderen MMOs ähnliche Aktionen geben, die kenne ich aber nicht ;-)

[Artificial Mind]

Naja man kann auch sehr gut verlustlos komprimieren, besonders bei vielen gleichförmigen Ereignissen.

Und außerdem koennen sich die Spieler doch auch teilweise peer-to-peer updaten, um die Server zu entlasten.

[Florian Keßeler]

Selbstverständlich geht das. Trotzdem bleibt am Ende noch die ganze Rechenlast auf dem Server. Bei der Kompression wollte ich auch nur darauf hinweisen, dass man das nicht mit Videos vergleichen kann, die ersten sehr stark komprimiert sind (mit beachtlichem Offline-Kompressionsaufwand) und dann auch noch im Prinzip weniger Information enthalten als Spieleraktionen.

Ich sag ja auch, es gibt keinen prinzipiellen Grund, warum es eine Grenze für die maximale Anzahl an Spielern in einer Gegend geben sollte, sie momentan aber nunmal existiert.

Benutzen aktuelle MMOs P2P-Protokolle? Da bin ich tatächlich nicht besonders gut informiert...

[starcow]

Ok, ich verstehe soweit. Nur seh ich irgendwie das Problem nicht ganz.
Wir haben folgendes Szenario:

- Eine kleine Weltkarte mit statischer unveränderlicher Level-Geometrie
- 500 Eingeloggte Clients
- 500 KI gesteuertes Getier, wie Ameisen, Wildscheine und Bären
- Alle dynamischen Objekte wie Tiere und Spieler können sich in dieser Version des Spiel nur ihre Position ändern

Der Server muss nun nicht mehr tun also den Status von 1000 Dynamischen Objekte an je 500 Clients senden.
Er versendet nun also 500 Pakete. Soweit sogut.

Was ich nicht verstehe:
Wo macht es den einen Unterschied ob die Clients noch weitere Aktionen als laufen ausführen können?
Der Server wird auch weiterhin 500Pakte versenden müssen. Diese Zahl steigt ja nur linear an und entspricht der Anzahl an Clients.
Ok, das Paket wird nun dadurch grösser, da nun mehrere Stats übermittelt werden. Aber an den paar Bytes wirds ja wohl nicht liegen. Zumal man ja wohl meistens nur irgendwelche Flags mübermittelt (z.B Player0023 ist im Begriff getroffen zu werden [x]).
Zur reinen Position der dynamischen Elemente, kämen noch ne Handvoll an Informationen dazu. Die muss ich aber auch übermitteln wenn niemand kämpf.

Was die Rechenpower anbelangt kann ich mir ebenfalls nicht wirklich einen Reim drauf machen. Ich meine diese Berechnungen die da im Hintergrund für einen Kampf ablaufen ist ja nicht mehr als einfachste Arithmetik.

Welche meiner Annahme(n) sind falsch und wieso?

Gruss starcow

[RazorX]

Was die Rechenpower anbelangt kann ich mir ebenfalls nicht wirklich einen Reim drauf machen. Ich meine diese Berechnungen die da im Hintergrund für einen Kampf ablaufen ist ja nicht mehr als einfachste Arithmetik.

Ich hab jetzt nichts mehr aus dem WoW Forum gefunden (hab da damals mal sehr interessante Gleichungen gesehen), aber hier scheint auch ganz gut erklärt zu sein wie komplex die simple Arithmetik doch eigentlich ist. http://www.tankspot.com/showthread.php? ... ath-in-WoW Es geht ja nicht nur um einfachen Schaden, sondern um Gruppenschaden, Gruppeneffekte, etc. Das heißt der Server muss zeitgleich auch ein Check durchführen welche Charakter in der Reichweite für Auren sind, dann müssen die miteinbezogen werden und die Pakete die letztlich gesendet werden belaufen sich nicht nur auf Schadensmeldungen sondern eben auch über solche Effektinteraktionen. Und wenn man dann halt nochmal drüber nachdenkt, dass wenn 500 Charaktere auf einem Platz stehen, dann muss auch für jeden dieser 500 Charakter ein Abgleich mit den anderen 499 durchgeführt werden. Ich kann mir also gut vorstellen, dass ein Weltserver da schon Probleme bekommt. Bei WoW ist es soweit ich weiß so, dass für jede Region ein eigener Server pro Realm läuft. Falls du es mal in WoW erlebt hast wie eine Hauptstadt überfallen wurde, dann weißt du das du da kaum noch spielen kannst weil die Latenz so im Keller ist.

[Chromanoid]

Es kommt wirklich sehr auf die Art des Spiels an. Je nach Spiel hat man unterschiedliche Bottlenecks.
BigWorld Tech schafft laut eigenen Angaben 100.000 Spieler in einem eher kleinen Gebiet. Siehe z.B. http://www.youtube.com/watch?v=bzrSaTIWEVc

Bei Eve Online wird ja jetzt "Time Dilation" Verlangsamung der Spielschleife eingesetzt um Situationen mit zu viel Interaktionen in den Griff zu bekommen. Wenn sich da 500 Raumschiffe gegenüberstehen und alle Raketen auf einander schießen, dann stößt die Verarbeitungskapazität des Servers schon an ihre Grenzen.

Anstatt die Zeit zu verlangsamen könnte man auch versuchen die Verarbeitung des Spielerhaufens auf mehrere Server zu verteilen. Das ist aber nicht so einfach... Stellen wir uns folgende Situation vor:
Spieler A und Spieler B wollen beide den selben Gegenstand aufsammeln. Die Spieler werden nicht vom gleichen Server verarbeitet. Wie stellt man sicher, dass der Gegenstand nicht mehrfach vergeben wird, die Spieler fair behandelt werden und die Echtzeitanforderungen nicht verletzt werden. Das mag bei 2 Spielern und 1 Gegenstand noch relativ gut machbar sein, aber je mehr Spieler dazukommen, steigt die Kommunikation zwischen den Servern...

[simbad]

Die Anforderungen an die Kommunikationstechnik im Server sind dann einfach recht hoch.
Ich will damit nicht das Problem kleinreden, aber bei einer Infiniband- Verbindung schaufel ich da schon ein paar 10.000 Events von einer Maschine auf die andere. Der reine Datendurchsatz von 40GBit und mehr ist leider nicht geeignet um einfach mal so eine Aussage zu treffen, wieviele Events man transferiert bekommt. Da sind ja noch diverse Bussyteme dran beteiligt etc. Es gibt also schon einiges an Technik, die, wie ich vermute, leider nicht eingesetzt wird, aus welchen Gründen auch immer.
Ich bin ja schon am Suchen nach entsprechenden Interface-Karten um das mal zu testen. Nur leider benötigt man bei Infiniband in jedem Fall einen entsprechenden Switch. Und die Dinger sind leider recht teuer. Aber es steht auf meiner Liste der Aktivitäten, die in diesem Jahr noch gemacht werden sollen.

[Lynxeye]

Infiniband ermöglicht dir aber auch nur ein NUMA System über mehrere physische Systeme aufzubauen. Der Vorteil an Infiniband ist ja gerade, dass du keine Events per se mehr über einen Netzwerkstack schicken musst, sondern geteilte Speicherbereiche zwischen den Maschinen direkt per Remote DMA und Cachekoherenzprotokoll abgeglichen werden.

Das Infiniband bisher weniger Verbreitung außerhalb des HPC Bereichs erfahren hat, liegt einfach daran, dass es sehr wenige Leute gibt, die Applikationen derart skalierbar schreiben können. Bei NUMA Systemen dieser Größe können schon kleinste Fehler zu dramatischen Auswirkungen führen: wenn deine Datenstrukturen beispielsweise falsch angeordnet sind kann es passieren das ein hochfrequenter Mutexlock und eine relativ dazu niederfrequente Variable auf der selben Cacheline liegen, was dir bei jedem Zugriff auf die Variable einen kompletten Koherenzabgleich beschert, mit dem du eigtl nicht rechnen würdest.

Ganz ohne Infiniband kannst du das einfach mal an einem 4P Server mit MagnyCourse Prozessoren von AMD testen. Dort hast du dann 4 Nodes mit insgesamt 48 Prozessoren, was 4 Speichernodes, 8 L3 Nodes und jeweils 48 L2 und L1 Nodes ergibt. Die Koherenzlinks dort sind im Vergleich zu Infiniband richtig schnell (ungeswitcht, heißt jeder Speichernode kann mit jedem anderen direkt kommunizieren; pro Node 51,2 GByte/s [Faktor 10 zu Infiniband]), trotzdem wirst du es sehr schwer haben auch nur annähernd an eine lineare Skalierung heran zu kommen.

Selbst das VM Subsystem des Linuxkernels, welches von Leuten geschrieben wurde, welche Parallelität im Sinn hatten und diese auch verstehen, geht derzeit ab etwa 24 aktiven Prozessoren auf 4 NUMA Nodes in ein logarithmisches Performancewachstum über. Um noch höher zu kommen muss man dann bereits sehr komplexe Tricks anwenden um Koherenzupdates zwischen den Prozessoren Batchmäßig vernehmen zu können.

Ich glaube nicht, dass der durchschnittliche Spieleentwickler das entsprechende Know-how und die benötigte Zeit bzw. Geld hat um so etwas umzusetzen. Die meisten Spieleentwickler verstehen ja noch nicht einmal normale Allokatoren und sehen solche Mikrooptimieren, wie sie zB Krishty bisweilen betreibt, als übermäßig komplex an. Was passiert wohl wenn diese sich mit per-CPU Allokatoren (Allokationen nur auf der aktuellen CPU gültig und nur per explizitem Sync verschiebbar) auseinandersetzen müssen, welche für größere NUMA Systeme absolut fundamental für annehmbare Performance sind?

[Chromanoid]

Ich denke man sollte jede MMO Technologie so aufbauen, dass man die Ressourcen nicht selbst bereitstellen muss, sondern einfach mieten kann. Computerspiele sind risikoreiche Produkte, da sollte man so wenig wie möglich an Vorinvestitionen leisten müssen. Ich weiß nicht wie teuer diese Technologien sind, aber zusammen mit dem entsprechenden Knowhow und der benötigten Infrastruktur ist es sicher aufwendiger so ein Serversystem mal eben in mehreren geographischen Zonen bereitzustellen als normale Systeme einzusetzen. Ich stelle mir den Einsatz solcher Technologien aber sicher sehr sinnvoll bei Streaming-Anbietern vor. Die werden sowas in der Richtung auch sicher nutzen...

Es besteht ja außerdem immer die Frage wie wichtig diese 500 Spieler Schlachten überhaupt für eine Vermarktung sind. Macht es überhaupt Sinn in eine solche Technologie zu investieren, wenn es auch so ganz gut läuft? Ich bin mir auch immer noch nicht sicher wieviel Spaß so Riesenschlachten überhaupt machen.

Hier mal ein paar interessante eher praxiserprobte Publikationen/Präsentationen:
Message Queuing on a Large Scale: IMVU's Stateful Event Architecture http://www.gdcvault.com/play/1014546/Me ... on-a-Large
MMO 101: Building Disney's Server System http://www.gdcvault.com/play/1013848/MM ... g-Disney-s
Big Wars - Server Architecture for 256+ Simultaneous Players Real-Time Multiplayer Games http://gdmag.com/issue/index.php?id=26
PikkoServer, how to scale game servers and enable player density. http://www.erlang-factory.com/conferenc ... vidAlmroth (hier bin ich mir um die Praxiserprobtheit nicht so sicher)
Scalability for Social Games: YOVILLE, MAFIA WARS and FARMVILLE http://www.gdcvault.com/play/1013842/Sc ... es-YOVILLE
Inside Tibia - The Technical Infrastructure of an MMORPG http://www.gdcvault.com/play/1014908/In ... astructure
BigWorld Technology Server Whitepaper http://www.bigworldtech.com/docs/2009_b ... epaper.pdf

Hier eher akademische Sachen deren Einsatz in der Praxis ich nicht abschätzen kann:
Real-Time Framework (Sachen aus dem edutain@grid Projekt)
- High-level development of multiserver online games http://downloads.hindawi.com/journals/i ... 327387.pdf
- Replication-based Scalable Parallelization of Virtual Environments http://pvs.uni-muenster.de/jmueller/jmi_thesis.pdf
- From a single- to multi-server online game: a Quake 3 case study using RTF http://pvs.uni-muenster.de/pvs/forschun ... epared.pdf
An Optimistic Obsolescence-Based Approach To Event Synchronization For Massively Multiplayer Online Games http://www.cs.unibo.it/~cpalazzi/papers/Palazzi-OOS.pdf
A platform for dynamic microcell redeployment in massively multiplayer online games http://web.cs.wpi.edu/~claypool/nossdav ... ossche.pdf
Running Quake II on a grid http://www.cs.berkeley.edu/~bethenco/ibmsj06quake.pdf

Im Anhang eine Liste mit so ziemlich allen Quellen die ich für meine Diplomarbeit angeschaut habe, da sind natürlich auch ein paar irrelevante Sachen bei... Das ganze ist eigentlich eine HTML Datei, die wurde aber als Angriff identifiziert...

[NytroX]

Hi, danke für die Links, Chromanoid. Den Beitrag von PikkoServer fand ich interessant.

Ich denke es hängt auch einen Großteil damit zusammen, dass jedes Gamestudio von vorne anfängt.

Wenn man z.B. das Steam-Netzwerk nimmt, kann sich evtl. der ein oder andere daran erinnern, was die für Probleme am Anfang hatten.
Immerhin gibt es neben "einfachen" Sachen wie Streaming auch Echtzeit-Kommunikation innerhalb der Spiele mit Hilfe des Steam Frameworks.
Komischerweise hatte z.B. LeagueOfLegends Jahre später das gleiche Problem: Friends-Listen über ihre Serverfarm zu skalieren, brachte viele Auszeiten für die Spieler.
Das hätte man problemlos vermeiden können, wenn man das Ganze "richtig programmiert" und aus den Fehlern von Steam gelernt hätte.

Interessant fand ich daher auch das Video von PikkoServer.
Dort werden nämlich Dinge als "Lösung" vorgeschlagen, die in anderen Bereichen (nicht Spieleentwicklung) längst Standard sind.
Z.B. erzählen sie anfangs, dass oft die Überlastung der Backend-Datenbank ein Problem ist. Wenn man statt einer normalen DB ein In-Memory DataGrid nehmen würde, wäre das nicht so.

Viele Spiele-Programmierer wissen meiner Meinung nach einfach garnicht, was es so alles an HighPerformance-Lösungen gibt und erfinden das Rad immer wieder neu.
Auch sehe ich oft, dass die Server wegen Wartungsarbeiten heruntergefahren werden, dabei wäre das meist garnicht notwendig.

Ich denke daher, dass in der Spiele-Branche (und nicht nur da) in dieser Hinsicht noch viel Nachholbedarf ist und die Grenze der gleichzeitig agierenden Spieler eigentlich höher liegen müsste, als es zurzeit der Fall ist.

[Chromanoid]

Jo, diesbezüglich finde ich die Ansätze bei Social Games ziemlich interessant. Die haben zwar meist nicht mit besonders interaktiven Mehrbenutzer-Situationen zu kämpfen, kommen aber oft aus der Webanwendungsentwicklung und bringen dieses Wissen immer mehr in die Spielebranche ein.

Zu League of Legends findet man hier auch interessante Informationen zur Backend-Architektur http://www.infoq.com/presentations/League-of-Legends

Ich denke das Populärwerden von Open Betas oder gar Open Alphas etc. wird viele Firmen mutiger werden lassen. Skalierbarkeit ist immer sehr anwendungsspezifisch. Man kann zwar funktionierende Lösungen übernehmen, aber die so einzusetzen wie es für den jew. Anwendungsfall richtig ist, hat immer viel mit Erprobung zu tun.

[Thoran]

Bin mal gespannt auf GuildWars2. Dort wird ein sog. Welt gegen Welt PvP angeboten auf ziemlich großen Karten, die in 4 Bereiche geteilt sind. Jeder dieser Bereiche erlaubt dann wohl bis zu 500 Spieler. Das macht über die gesamte Map ~2000 Spieler.

Ich finde grad die Quellen nicht mehr, liefere sie aber nach sobald ich sie gefunden hab.

Thoran

[NytroX]

Hi, cooler Link Chromanoid, wie findest du sowas immer? :D

Hätte mir allerdings im Bezug auf Architektur mehr erwartet.
SIe sprechen viel über "Coherence", das ist z.B. das In-Memory DataGrid Produkt von Oracle: http://www.oracle.com/de/products/middl ... index.html
Hab ich wohl recht gehabt mit meinem letzten Beitrag :P

GuildWars2 werde ich mir definitiv mal anschauen/kaufen, das scheint ganz spaßig zu sein.
Bin mal gespannt, wie da die Performance bei den Schlachten so ist.

[Chromanoid]

Naja ich habe ca. ein Jahr an meiner Diplomarbeit "Konzeption und Entwicklung skalierbaren Serverarchitektur für interaktive Online‐Echtzeitanwendungen" gesessen :D Da sollte mir der ein oder andere Link zum Thema bekannt sein ^^
Ich hab übrigens was ähnliches in der Richtung von JBoss für meinen Prototypen eingsetzt (JBoss Infinispan). Allerdings hab ich das Ding eher für Kommunikation und automatische Verteilung von Daten missbraucht... Ich muss mal schauen ob ich da noch irgendwie ein Paper daraus mache, ansonsten poste ich meine Ideen zum Thema demnächst hier mal.

[Jofarin]

Also wenn mans rein drauf anlegt ein MMO herzustellen wo 1000 Spieler sich auf einer Karte schlachten, wäre das denke ich selbst mit "hausüblichen" Mitteln machbar solange die Leitung mitspielt. Im Aachener Studentenwohnheim hatten wir ne 1GBit/s Anbindung, ne entsprechende Netzwerkkarte ist heutzutage in jedem aktuellen PC verbaut.

Wenn man die Steuerung jetzt Diablo ähnlich macht (irgendwohin klicken um hinzulaufen und irgendwohin klicken nachdem man eine Taste gedrückt hat um eine Attacke/Cast dorthin zu machen) und die Berechnung des Ergebnisses komplett auf die Clients abwälzt ginge es beim Server ja ausschließlich um die Verteilung der Daten. Dementsprechend gehen wir mal von 20 Frames/s aus die das Spiel aktualisiert wird (bzw. dem Server die aktuelle Aktion des Spielers übermittelt) bei 1000 Spielern sind das 20 Mio Aktionen pro Sekunde die der Server versenden kann. Das sind bei 1GBit/s dann noch 50 Bit für die Aktion. Das wären z.B. zwei Shorts mit je 65.535 unterschiedlichen Stellen für die Position und 18 Bits für Aktionen...was ggf. etwas sehr großzügig sein dürfte ^^

Die Clients kriegen dann pro Sekunde 1000*20*(32-50) Bit an Daten, was mit ner 1 MBit Leitung schaffbar sein müßte (Outbound wärens gradmal 50*(32-50) Bit/s also bis zu 2,5kBit/s). Die Berechnung ist dann leider doch etwas sehr abhängig vom Spiel um zu sagen ob sowas schnell genug (20 Mal pro Sekunde) berechnet werden kann. Ich würd mal optimistisch schätzen, dass ein Spiel wo die Figur dem Mauscursor hinterherläuft und man jemandem Schaden zufügt, wenn man gegen ihn läuft von nem GHz Prozessor zu schaffen ist.

...und das sind jetzt hausübliche Mittel.

[pUnkOuter]

Du kannst diese Berechnungen nicht mal einfach so auf die Clients abwälzen. Ausserdem redet hier niemand von mangelnder Bandbreite auf Seiten der Clients.

[Jofarin]

Du kannst diese Berechnungen nicht mal einfach so auf die Clients abwälzen. Ausserdem redet hier niemand von mangelnder Bandbreite auf Seiten der Clients.

Doch, kann man. Ist halt nur bei einfachen Spielen definitiv möglich (deswegen begann ich mit "wenn mans drauf anlegt...".), bei komplexeren kommts dann schnell auf die Clienthardware an.
Wobei das auch wieder nur für den Fall gilt, dass jeder alles brechnet. Wenn man "vertrauensvoll" nur die eigenen Daten berechnet, kann das auch die letzte Brotdose. Ein "gesunder Mittelweg" dürfte dann sein, dass durch den Server noch zusätzlich ein paar weitere Spieler zugeteilt werden, die der Client dann auch berechnen muß, so dass wichtige Statusänderungen (wie Tod, Stunned o.ä.) zusätzlich publiziert werden. Das belastet dann natürlich aber wieder den Server mehr (8 bit für ID und 2-3 Bit für den Status mal 5 zu berechnende Spieler mal 1000 Spieler mal 20 Hz-> 100kBit/s). Aber dafür ist man abgesicherter gegen cheaten.

Und ich red hier hauptsächlich auch nicht von der mangelnden Bandbreite der Clients, mein Hauptpunkt war die Bandbreite und Rechenkapazität am Server.

[Chromanoid]

Bei Tibia Online verwaltet ein Server ca. 1000 Spieler bzw. einen Shard. 2D MMOs mit Point&Click Steuerung sind sowieso ziemlich gut zu optimieren, schließlich muss man nur die Start/Endpunkte der Figurenbewegung ggf. mit leichter verlustbehafteter Kompression übermitteln. Solange die Spieler nicht miteinander kollidieren, kann man da sehr viel Kommunikation sparen. Bei Kollision zwischen den Spielern kann man dann vielleicht noch sehr von Grid basierter Bewegung und Positionierung profitieren.

Das Paper ist für 2D MMOs auch ganz interessant: http://pvs.uni-muenster.de/pvs/mitarbei ... kkatan.pdf Direkt aus der Praxis berichtet diese (schon oben verlinkte) Präsentation über Tibia http://www.gdcvault.com/play/1014908/In ... astructure

[Firoball]

Also zu meiner DAoC Zeit da gab es durchaus mal 100 vs. 100 Kämpfe - da hatte ich noch ISDN. Mit dem Datentraffic gab es nie Probleme, damals warn lediglich die Rechner leistungstechnisch (3D Darstellung) relativ schnell am Ende, und es hat bis zur Unspielbarkeit geruckelt.
Wie sie das genau gemacht haben, weiß ich nicht, aber es scheint recht gut funktioniert zu haben.

Ich kann mir vorstellen, dass die nicht vorhandene Kollision zwischen Spielern einiges erleichtert hat.

[LONy]

Hi,
ich will ja ein RTS im Browser schreiben, bei dem auch am Ende viele 100 Spieler gleichzeitg auf einem Server spielen können. Meine Hoffnung ist, dass dies mit Websockets möglich wird. Um die Möglichkeit von node.js mit socket.io usw. auszuloten, schreibe ich momentan einen kleinen Space-shooter. Jeder hat ein kleiens Raumschiff (dreieck^^) mit dem er rumfliegen kann und andere Spieler abschließen kann.
Auch bei einem so simpelsten Spiel habe ich schon meine Probleme den Server nicht gleich mit Rechenaufgabern zu überlasten. Umgedreht muss der Server aber alle Eingaben der Clients überprüfen, da man JS leicht im Browser manipulieren könnte.

Ich bin hier wohl auch grad dabei, das Rad neu zu erfinden :lol: Momentan mach ichs so, dass ich nur eine Nachricht an den Server schick, wenn eine Taste gedrückt oder losgelassen wird. Dieser Befehl von einem Spieler wird dann vom Server an alle Clients verteilt und dann an den Clients die Spielerposition berechnet... da es durch die Latenz zu unsynchronen Koordinatne kommen würde, berechnet der Server zusätzlich die Positionen der ganzen Spieler und syncronisiert die Momentan alle 50ms. Screenshots und nen kleinen Testserver gibts, sobald ich ein wenig weiter bin ;)

@Chromanoid ich muss mir deine Quellen mal anschaun, ist ja cool wenn wir hier im Forum so einen Experten haben :)

Ganz Trivial scheint das Problem aber nicht zu sein (ich hab es am Anfang selbst sehr unterschätzt). Z.B. bei End of Nations waren am Anfang 50 Spieler pro Map geplant, die gleichzeitig an einer Schlacht teilnehmen; Inzwischen wurde die Spielerzahl denke ich auf ca. 25 eingeschränkt.

Ich hab mir nie wirklich gedanken gemacht, warum bei MMORPGs der Schwerpunkt auf PvE liegt und oft (mein Kentnisststand von vor 4-5 Jahren^^) PvP nur in speziellen Arenen möglich ist, aber in Anbetracht auf die Serverlast und was bei PvP zusätzlich zu tun ist leuchtet das schon ein...

[odenter]

Ich hab mir nie wirklich gedanken gemacht, warum bei MMORPGs der Schwerpunkt auf PvE liegt und oft (mein Kentnisststand von vor 4-5 Jahren^^) PvP nur in speziellen Arenen möglich ist, aber in Anbetracht auf die Serverlast und was bei PvP zusätzlich zu tun ist leuchtet das schon ein...

Es macht ja auch nen Unterschied ob ich da ein 2D Spiel habe oder ein 3D Spiel das sich wie ein Shooter spielt. In Ultima-Online gabs auch PvP.
Weil die Konzepte eben auf PvE ausgelegt sind und nicht auf PvP. Es gibt doch PvP Spiele, wo PvE wirklich unr Mittel zum Zweck ist der Endgamecontent aber schwerpunktmässig aus PvP besteht.
Der Endgamecontent in den meisten Spielen beschränkt sich auf das sammeln von grünen, blauen und lila Items um danach nach einem Addon wieder mit nem grünen Item anzufangen. Und die Leute sind auch noch so doof und zahlen dafür Geld, scheint sich ja zu lohnen. :)