Szenenmanagement MMORPG

[TsPaddy]

Hi Leutz.

Mal ne etwas kniffelige Frage:

SpielMapAufbau:
Stadt & Land.
Land kann man mit ner Terrainengine machen.
Stadt als Occtree.

Da die Spieler aber auch in der Lage sein sollen selber Häuser zu bauen muß die Karte Aktualisiert werden. Die Stadtkarte ist in Sektoren unterteilt, die eine feste Größe haben (sagen wir mal 500x500m).
Die StadtWelt wird als großer Occtree dargestellt, und die Stadtsektoren sind dann ihrerseits in Occs unterteilt, die dann einfach in den StadtGlobalen Occtree eingeladen werden können.

Wenn ich nun einen Spieler ein Haus bauen lassen hab ich erstmal ein Problem:
Ich muß den anderen Spielern mitteilen,dass an XYZ jetzt ein neues Haus vom Typ XY steht (vordefinierte Häusertypen je nach Stadtteil).

Wie mach ich das nun am Trafficschonensten (nicht nur das der auch was kostet...die Spieler sollen ja nicht ewig auf Daten warten müssen).

Methode 1:
Ich sende den Spielern bei Spielstart ein Update auf den Sektor, der sich geändert hat.
Nachteil:
-Sende viel Zeugs, dass die Spieler schon haben.
-Was wenn sich was ändert während die Spieler online sind?

Methode 2:
Ich sende die Änderungen während des Spiels über eine 2. Netzwerkverbindung/Socket.
Vorteil: Hab alles immer frisch bei den Spielern.
Nachteil:
-Es muß zur Laufzeit in den Mapdaten gearbeitet werden. Was wenn das Spiel dabei abschmiert?...Dann Version 1, da der Spieler dann laden kann, bevor er Online geht?
2a: Nur die Stellen die geändert werden sollen (Wildes Rumeditiere)
2b: Den Sektor der sich ändert(viel Traffic)
...

Hat einer von euch eine handliche Idee?

Ich will halt keine reinen Gebiete in denen der Spieler baut und Gebiete in denen der Spieler nur mieten oder questen kann...

Cu Paddy

[Gast]

TsPaddy schrieb:

Wenn ich nun einen Spieler ein Haus bauen lassen hab ich erstmal ein Problem:
Ich muß den anderen Spielern mitteilen,dass an XYZ jetzt ein neues Haus vom Typ XY steht (vordefinierte Häusertypen je nach Stadtteil).

Ich hätte zwei vorschläge...

1.) Schick einfach die Liste mit allen gebauten Häusern und Häusertypen beim Spielstart an den Client und schick ne Nachricht "Spieler foo hat haus vom Typ bar gebaut", sobald ein neues Haus im Spiel entsteht.

2.) (Traffic schonen) Mach Alles genauso, wie in 1.) aber speicher einen Hashwert, für jeden "Sektor" im Client und schick nur neue Hausdaten, falls der Sektor sich geändert hat.

Btw. du brauchst dafür keine 2 Netzwerkverbindungen. Eine reicht vollkommen aus...

[TsPaddy]

Die zwei Server meinte ich für Ingamesachen.

Beispiel:
Spiele x baut n Haus.

Der Gameserver sendet eine kurze Meldung darüber an den Login/Updateserver.

Der Updateserver gibt nun jedem Spieler der sich einlogged die neuen Sachen.
Aber was viel wichtiger ist:
Während der Gameserver mit den Spielern weiter lustig das Spiel laufen lässt, kann der Updateserver an Spieler Y,Z,etc die sich alle im Spiel befinden (die Spieler,die am nächsten zu dem Updatepunkt sind zuerst) die neuen Kartendaten über ne Updateverbindung verteilen, ohne damit die Performance des Gameservers zu beeinträchtigen.

Dafür dachte ich mir halt den 2. Server.

[Gast]

TsPaddy schrieb:

[...] Während der Gameserver mit den Spielern weiter lustig das Spiel laufen lässt, kann der Updateserver an Spieler Y,Z,etc die sich alle im Spiel befinden (die Spieler,die am nächsten zu dem Updatepunkt sind zuerst) die neuen Kartendaten über ne Updateverbindung verteilen [...]

Wenn sich aber deine Umgebung wärend des Spiels ändert, ist es vielleicht nicht so klug, zwei getrennte Server anzulegen, da diese sonst untereinander auch noch komunizieren müssten, welche Kartenänderungen gerade stattgefunden haben.

Außderdem macht das nur Sinn, wenn du 2 getrennte Server (also hardwaremäßig getrennt) zur verfügung hast, an sonsten hast du keinen Vorteil, da die Resourcen ja die selben bleiben. Aber wenn du soweit bist, dass dir ein Computer nicht mehr ausreicht, sind warscheinlich größere Anstrengungen nötig, um die gebrauchte Skalierbarkeit zu erhalten.

[TsPaddy]

Ja, geht um ein Servergrid.
Die Skalierbarkeit ist bedacht.
Login und Gameserver sind eh einzeln angelegt.

Und was den Traffic zwischen den 2 Servern angeht:
Der Gameserver teilt dem Updateserver nur mit:
Gameserver: Hallo Updateserver, auf xyz steht jetzt das Haus NummerSchießMichTot.
Updateserver: Haus NummerSchießMichTot auf Punkt XYZ, richtig
Gameserver: Richtig

Das wäre dann die gesammte kommunikation unter den beiden.
Die Rückfrage nur um zu Checken, das wirklich alles 1000% richtig angekommen ist.
Wenn nun 100 Spieler online sind spart das dem Gameserver 99% Traffik ein, denn die Kommunikation mit dem Updateserver/Mapserver/Loginserver/whatever ist genauso zeitaufwendig als würde der GameServer einen Client bescheidsagen.
Der ganze Updateprozess geht so aber zu lasten des Updateserver und der Gameserver kann ungestört weiterknechten.

BEI 1000 SPIELERN DIE ONLINE SPIELEN SIND DAS SOGAR 99.9% ENTLASTUNG!!!

[Gast]

TsPaddy schrieb:

BEI 1000 SPIELERN DIE ONLINE SPIELEN SIND DAS SOGAR 99.9% ENTLASTUNG!!!

Naja... Jetzt muss dein Updateserver aber wissen, welchen Player er das Update schicken soll. Also muss er wissen, welche Player gerade in der nähe, des geänderten Geländes sich befinden. Jetzt müssen dein Gameserver und dein Updateserver richtig arbeiten, denn dein Gameserver muss jetzt eine relativ lange Liste von zuupdatenden Clients erstellen, die muss serialisiert werden und am Updateserver wieder deserialisiert werden... Das verbrennt dir schon einiges an Performance...

Es ist klaar, dass bei zwei Servern, sich diese gegenseitig entlasten sollten, aber vielleicht wäre eine andere Trennung sinnvoller...

[TsPaddy]

Wieso?
Die User, die Online sind erfahre ich auch vom Loginserver, und die Position kann man auch vom Client anfragen...
und schon ist der Gameserver wieder aus der Nummer raus

[hustbaer]

Hm. Ich würde erstmal gucken wo sich der Flaschenhals des Systems ergibt, wenn alles was das eigentliche Spiel betrifft (also auch die Häuser) auf dem Game-Server läuft. Oder weisst du das schon? Wenn ja dann teile es uns ruhig mit

Je nachdem wo das ist kann es Sinn machen (oder eben auch nicht) Teile der Client <-> Server Kommunikation auf weitere Server auszulagern.

Weiters wäre natürlich interessant wie oft es vorkommt das solche Updates über Häuser an Spieler-PCs verschickt werden müssen. Wenn es selten genug passiert sehe ich keinen Grund sich darüber überhaupt gross Gedanken zu machen.

[TsPaddy]

Flaschenhälse gibts da einige:
-1. Server, die Innenstadtbereiche, Dörfer oder ähnliches betreffen...bestes Beispiel das mir da grade einfällt ist Everquest 2 und die Städte. Da können Spieler nix bauen, da der Server teilweise schon lahm genug wird wenn sich alle da rumdrücken). Diesen Servern jetzt noch Updateaufgaben zuzumuten ist dann etwas viel.

-2. Große Welten: Je größer eine Welt wird, desto höher in der Regel auch die Einwohnerdichte. Flaschenhals 2 wäre da das Risiko Menschenansammlungen nicht unbedingt vorraus zu sehen. Es entsteht also Problem 1 nur an einer nicht vorher 100% vorraussehbaren Stelle. Ein Servergrid muß also in der Lage sein die Karte in verschiedene Teile auszuteilen und diese dynamisch an Server mit freier Kapazität zuzuweisen. Dadurch entsteht auch Auslastung auf Servern, also warum noch die Gameserver extra quälen.

Wie oft es passiert liegt immer an den Möglichkeiten, die man dem Spieler gibt in die Architektur einzugreifen. Wenn ein Spieler sein Haus/Anwesen/etc verändert, dann muß das weitergegeben werden. Die Häufigkeit liegt an der Größe der Welt/ der Menge der Spieler. Bei einem Spieler mag sowas in der Regel vielleicht 1-2 Mal im Monat vorkommen (nicht nur Bau, sondern auch Modernisierungen) aber auf ein gut laufendes MMORPG mit 100000+ Spielern sind das im Worstcase 10 Updates pro Sekunde, die man zwar sammeln und alle 5min, 15 oder 30 min übertragen kann, jedoch kanns dann eng werden. Der Traffic ist auch für so viele Updates gering, aber die Rechenleistung dafür darf man dem Gameserver nicht klauen.

[rüdiger]

Soll der Benutzer die Map denn immer cachen? Sonst unterteile die Map doch in entsprechend kleine Teile und schicke immer die Daten für die Map-Bereiche die der Benutzer sieht oder voraussichtlich in der nächsten Zeit sehen wird.

Mit der Last würde ich mir nicht so viele Sorgen machen. Grids haben doch dynamische Last-Verteilung. Wenn in einer Stadt auf einmal 5000 Nutzer versammelt sind, dann wird das Gebiet eben von mehreren Servern abgedeckt.

Das Updaten dürfte ja auch nicht viel Last beanspruchen, vor allem wenn du die "kreativität" der Nutzer einschränkst. Sprich wenn der Nutzer die Gegend nur über vorgefertigte Bauteile beeinflussen kann, musst du ja nur Informationen ala "Bauteil B an Stelle X, Y" speichern/transportieren. Das ist ja keine große Belastung.

[RHBaum]

Ich wuerde das soweiso Layern ...

Statische Elemente, allso alles was der spieler ned beeinflussen kann ... also landschaft etc (ich hoffe da kann keiner mitm bagger kommen und Huegel wegraeumen) .... als Grundlegenden layer und die texturen und die Maps dazu in nem Verzeichnis beim client.
Nen weiteren layer fuer jeden dynamischen Objecttyp ... haeusser zum beispiel ...
dann bekommst ne einfache glatte liste wo nur noch drinnsteht, welcher position (evtl koordinaten), welcher haussertyp, welche aussrichtung, von welcher Player und irgendwie nen verweis auf verwaltungstechnische daten (wer darf rein etc) bekommst.
Keine texturen kein gar nix. Die zu verwendenden texturen sind im Typ codiert ...

die map wird aufm server gehalten ...

kommt nen spieler in die zone:
- holt er sich die Dynamischen objectmaps (kann man cachen)
- Das grundlayer wird gerendert
- die dynamisc hen objecte werden stueck fuer stueck geladen und in nen 2. layer geladen, der layer wird auch gecahct klar ...
- die layer werden alle uebereinander gelegt, voiala, fertig ist das komplette bild ....

aendert ein spieler die dynamischen objecte:
- mittels funktion wird die aenderung an den server uebertragen
- wird an jedem in der Zone nen event geschickt, mit der info welches dyn. layer geaendert wurde.
- jeder Spieler holt sih die Liste mit den dynamischen Daten des entsprechenden Layers neu
- der client rendert den geaenderten layer neu
- die anderen ungeaenderten Layers liegen noch irgendwo gecacht auf der pladde ...
- der client setzt nur die layer wieder neu zusammen ...

die dynamischen listen kann man cachen in dem man mit checksummen arbeitet ... er bekommt bei der 1. Anfrage ned die daten sondern die checksumme, vergelicht ob die checksumme mit der aktuellen gehaltenen liste stimmt, und nur wenn die sich aendert werden die daten neu geholt und der zugehoerige Layer neu gerendert.
So kann man mit den events bisserl groesszugiger arbeiten .. bisser oefters abfragen ohne das die netzlast explodiert, macht die sache auch etwas fehlertoleranter ....

So ca. wuerd ich sowas bauen ...
Nur als Anregung

Ciao ...