spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

nox: das macht man nicht clientseitig mit dem wegrennen und so, können ja z.b. 40 user da stehen und dann würde es bei jedem etwas anders ablaufen...
und wie du sagst: 32 kerne bringen nix wenn die applikation die nicht wirklich einsetzten kann (d.h. multithreading godlike implementiert wurde (was nur chuck norris kann ))

Pardon ich habe mich missverständlich ausgedrückt. Den einen Teil, den er ansprach, ist größtenteils Grafik (Animationen usw.). Der andere Teil mit der KI ist meist doch eher "stupide" (Priority-Queue, "A^2 + B^2 > Aggrodistanzformel^2", Skripts) und daher nicht all zu sehr rechenintensiv und damit für den Server übermäßig belastend.

Zitat von »"DasBlub"«

einspruch! bei wow wird ALLES auf dem server berechnet (glaub mir, ich weiss es, ich schreib ja selber dran mit ). wir haben momentan 2 rootserver [...] knapp 700-800 spieler online in lastzeiten (wochenende, abends)[...]

Korregiere mich wenn ich falsch liege.. aber ich habe so in Erinnerung, dass z.B. bei 2 CS Servern mit je 32 Spielern bei den meisten Rechnern Schluss ist. Das sind immer noch andere Dimensionen als 800 Spieler mit 2 Hosts.
Wie auch immer, kann man letzendlich auch nicht vergleichen, da vollkommen andere Anforderungen für diese Spiele gelten.

Worauf es hier letzendlich ankommt: Es ist in der Entwicklungsphase finanzierbar. Ein Root Server für grob 60 Euro monatlich reicht da ja anfangs aus um gut ein paar hundert Leute zu bedienen. Und die Kapazität braucht man zu beginn ja noch nichtmal.

Den Root Server bekommt man sogar für 50 Euro Monatlich @xardias.

xardias: cs ist auch kein mmorpg dafür können nicht genug leute aufs mal miteinander spielen -> komplett anderer softwareaufbau

CS ist ein OMS.

Online
Multiplayer
Shooter

:lol:

genau, und dass ist der kleine aber sehr folgenintensive Unterschied zwischen Multiplayer und Massive Multiplayer.. multiplayer ist bis etwa in den Bereich von max. 64 Spieler ausgelegt, während bei Massive Multiplayer ein Spiel mit Zehntausend Benutzern klein ist...

Daher muss das Massive Multiplayer eben auch skalierbar sein, weil wenn man nicht darauf achtet kann etwas was mit 100 Spielern (und da muss man schon schauen das es geht) super gut funktioniert bei 150 überhaupt nicht mehr funktioniert, und mit stärkerer (=teurer) Hardware kann man auch nur begrenzt verbessern bzw. wenn das Programm zu schlecht umgesetzt wurde gar nix.

drittens, ein MMORPG muss ewig laufen können, die CS-Session ist nach relativ kurzer Zeit fertig. Das heisst die Speicherverwaltung auf dem Server muss perfekt sein (oder möglichst ).

so meine Lieben, ich hab mir nun mal die Zeit genommen und mal eine Beschreibung eines MMO gemacht... Anregungen/Kritiken oder Fragen (zum Inhalt oder weil meine blumige Sprache Probleme macht) sind erbeten!

Spiele müssen nicht genau so aufbaut sein, aber dies ist (denke ich) dass grobe Schema solcher Spiele.

Was ist (technisch gesehen) ein (MMO-) Spiel?
- Ein Programm, dass im Unterschied zu den meisten normalen Anwendungen (z.B. ein Internet-Browser, oder Word, oder..) meist nicht nur darauf wartet dass ein Benutzer etwas macht, sondern selber ständig sich verändert auch ohne Benutzer-Interaktion (die Rakete fliegt weiter, die NPCs bewegen sich auch wenn niemand zuschaut oder mit ihnen interagiert, usw.)
- Multimedial: Bilder, Geräusche, Musik, Filme, Animationen (und Benutzereingaben)
- viel Zeug: In vielen Spielen, insbesondere MMORPGS, müssen hunderte wenn nicht tausende von Objekten verwaltet und gespeichert werden, das muss so gebaut sein dass man da schnell suchen, sortieren und filtern kann... und schnell laden und speichern..
- online: das heisst jede aktion eines benutzers muss überprüft werden - wir können ja nicht 100% sicher sein dass der unseren Client benutzt und nicht einfach uns so diese Nachrichten schickt...
- Ausfallsicher: Dieses Spiel soll doch 24 h / 7 Tage die Woche, das ganze Jahr durch laufen - das erfordert viel Vorraussicht und Können
- Spass: Das Spiel muss Spass machen, aber was ist Spass? Die Summe aller der Dinge die zusammenkommen und eine Atmosphäre erzeugen... ein kleiner Missklang kann die ganze Komposition unbrauchbar machen
- Geschichten: wahrscheinlich viele viele Geschichten Gute Geschichten brauchen viel Zeit und Talent
- Schönheit : Schönheit, und das wichtigste dabei ist dass alles zusammenpasst und einen einheitlichen Stil besitzt. Das ist, neben dem Geschmack der Entwickler, der Hauptgrund warum fast alle MMOS keinen realistischen Grafik-Stil besitzen - die Dinger sollen ja über Jahre benutzt werden, bei realistischer Grafik wäre diese aber noch bevor das Spiel fertig ist hoffnungslos veraltet.
- Abwechslung: es muss Abwechslung geben, entweder durch eine solide Spielmechanik oder immer neue Sachen die es zu entdecken gibt
- Wartbar: Bei sowas das so lange nach der ersten Erstellung noch geändert oder ergänzt wird muss diese Arbeit möglichst leicht zu machen sein - erfordert ebenfalls sehr viel Voraussicht und Können

Also was brauchst man alles..
Zuerst: Hängt stark davon ab was das Ding alles machen/können soll (=Spielkonzept)

Der Client - Beim Spieler auf dem Rechner:
------------------------------------------------------
Üblicherweise ist die Spiellogik nur zum Teil auf dem Client vorhanden und wird immer auf dem Server durchgeführt um Betrug zu verhindern, daher ist der Client eigentlich nur ein Programm dass die Benutzereingaben entgegen nimmt und die Ausgabe (Grafik,Ton) anzeigt. So ziemlich immer ist es auch so dass der Client alle Daten hat, also alles Ausgeben kann (alle Gebiete, alle Monster, alles) und vom Server jeweils nur den Befehl bekommt dies oder jenes zu tun, weil jedesmal zu übertragen kostet zuviel Zeit (Second Life macht dies teilweise, ist auch sehr langsam beim Grafikaufbau...)
Der Client muss mit dem Server "reden", dazu müssen sie beide die gleiche Sprache können - und zwar eine Sprache die es ermöglichst mit möglichst kurzen Worten alles zu sagen, weil je weniger Worte wir über die Internetleitungen hin- und herschicken müssen desto schneller läuft das Ding bzw. umgekehrt.
Bei Computern nennt man so eine Sprache ja Protokoll, z.B. HTTP um Websiten zu übertragen. Es gibt einige von denen, normalerweise macht man aber ein eigens Protokoll (Sprache) damit das möglichst effizient ist für das eigene Spielprinzip. Die Kommunikation hängt ja nicht nur von der Sprache ab sondern auch wie die Gesprächspartner denken, also wie sie das interpretieren und wie sie darauf reagieren, es hängt so mit Datenverwaltung, Logik und Events (programm-events, nicht feiertage) ab.
Manchmal dauert es ein Weilchen bis der Server dem Client eine Antwort gibt, und da darf das Spiel ja nicht einfach anhalten und gewartet werden bis vom Gesprächspartner eine Antwort kommt, daher muss ein System vorhanden sein mit dem man die wahrscheinlichste Antwort prophezeien kann, falls sie dann anders ist muss halt korrigiert werden (das sind die sogenannten "Lags" im Spiel).
So, unser Client kann nun mit dem BigBoss reden und die Eingaben die der Benutzer macht (und zwar auf jeder Tastatur, egal in welchem Land der wohnt...) an den Server weitererzählen. Natürlich muss das geordnet ablaufen und schnell und flexibel gehen damit es sich da nirgends staut oder gar etwas verloren geht.
Nun muss der Client das aber auch noch umsetzen - dass heisst für jedes einzelne Pixel auf dem Bildschirm entscheiden welche Farbe das nun haben soll und die richtigen Signale in der richtigen Menge und Reihenfolge an die Lautsprecher senden. Das natürlich mehrere dutzend Male pro Sekunde oder gar mehr, während er gleichzeitig noch eine Hand frei hat um Benutzereingaben entgegenzunehmen und lauscht ob der Server etwas sagt.
Der Client besteht also aus verschiedenen Komponenten, einmal ein Ding das die Benutzereingaben entgegen nimmt, ein Teil der mit dem Server spricht, eine abgespeckte Variante der Spiel-Logik-Engine um bei Verzögerung im Gespräch mit dem Herrn Server trotzdem dem Kunde etwas liefern kann, einer (natürlich möglichst guten = komplizierten) Grafik-Engine, einer Komponente die die Geräusche verwaltet (also zum Beispiel das Geräusch von Hufen abspielt wenn ein Pferd vorbeiläuft) und ein Ding das ab und zu mal ein wenig Hintergrundmusik abspielt weil Geräusche alleine vielleicht langweilig sind.
Diese einzelne "Arbeiter" müssen so organisiert sein dass sie sich nicht gegenseitig in die Quere kommen (was wie bei richtigen Arbeitnehmern oft sehr komplex ist).
Das tollste an der ganzen Geschichte ist aber dass all diese Komponenten nicht nur auf einer bestimmten Hardware (und Betriebssystem) funktionieren sollen sondern auch mit ganz anderen komischen Dingern zurecht kommen sollten (ohne sich gegenseitig zu behindern) oder verschiedenen Kombinationen. Der Client sollte sich auch noch möglichst gut an die jeweiligen Umstände anpassen damit er so gut es geht nicht nur auf den neusten Computern oder denen auf welchen die Entwickler arbeiten funktionieren und auch kein zu grosser Unterschied für den Spieler bemerkbar ist wenn er auf verschiedenen Computern (die vielleicht das gleiche können, aber anders zusammengestellt sind) spielt.

Da das Spiel vermutlich in mehreren Menschen-Sprachen (deutsch, englisch, ..., usw) sein soll muss der Client die Zeichen die da verwendet werden alle zeichnen können (= nicht selbstverständlich).

Der Server (die Software, nicht die physikalische Maschine)
----------------------------------------------------------------
Anders als der Client muss der Server nicht auf jeder Hardware unbedingt funktionieren da diese durch die Betreiber ja bestimmt werden kann.
Ebenfalls wie der Client muss der Server aber immer bereit sein für ein Gespräch und die Sprache des Clients perfekt beherrschen, und anders als der Client muss er mit sehr sehr sehr sehr sehr sehr sehr sehr vielen vielen Clients gleichzeitig reden können (ohne zu stottern). Wenn dem Server irgendeine Mitteilung geschickt wird muss er überprüfen ob diese Mitteilung überhaupt sein kann, ob die Sprache eingehalten worden ist (und falls nicht muss er Meldung machen damit dass jemand überprüft) und danach mal ansehen was den in dem Brief steht (auch sollte er möglichst immun gegen Briefbomben sein da im Internet zu rechnen ist dass er ab und zu sicher irgendwas bekommt was ihn kaputt zu machen versucht). Wenn er den Brief vom Client gelesen hat muss er überprüfen ob das stimmen kann was der sagt und wenn der Client etwas machen möchte (zum Beispiel der Spieler sich bewegen) muss er anhand der Gamelogik überprüfen ob er das darf, z.B. irgendwo hingehen (Wand? Gebietsgrenze? Ein anderer Spieler steht schon dort?). Er muss ALLES WISSEN - von jeder Spielfigur was sie alles kann und darf, wo sie ist, wer sie ist, aber auch wo alles andere ist, jeder Grashalm, jedes Monster muss er kennen und auf jede Frage und alles immer eine Antwort bereit haben - und dabei darf er nur sehr sehr sehr kurz überlegen weil der Client ungeduldig ist. Und er hat ja noch 999 andere Clients die ihn auch anschreien und was wollen...
Dabei sollte er noch über alles was ein Spieler macht Buch führen (d.h. wenn ein Spieler sich einen Schritt zur position x,y macht, den gegner BliBlaBlub mit Attacke DonnerPeng angreift..) und in ein Log schreiben damit im Falle eines Streites die Entwickler dort genau bis ins Detail nachsehen können was passiert ist.
Gleichzeitig ändert sich diese Daten auf welche seine Antworten an die Clients basieren auch noch ständig, durch die Clients aber auch durch die Spiellogik an sich, z.B. Tag/Nachtwechsel, Erreignisse in der Welt und Sachen die sich Ändern weil ein Spieler irgend etwas macht (ein Monster töten -> nun muss es auch tot und weg sein..) - dabei muss der Server unbedingt darauf achten dass er nicht gerade mit einer Hand eine Veränderung an einem Spielobjekt macht wenn er dieses gleichzeitig gerade mit einer anderen Hand an den Client weiterreicht -> der Client würde ein halbgeändertes komisches Ding bekommen womit er nichts anfangen kann oder dass ihn möglicherweise sogar so verwirrt dass der Client Selbstmord begeht. Trotzdem muss der Server ja irgendwann die Änderung machen, dafür muss er eine Arbeitsmethodik haben. Er redet also gleichzeitig (mit keinen oder nur kurzen Unterbrechungen) mit sehr sehr sehr vielen Clients gleichzeitig, überprüft Sachen, schreibt ein Tagebuch und verwaltet ein sehr grosses Lagerhaus voller verschiedener Objekte die sich dabei noch ständig ändern (bzw. er die ganze Zeit ändern muss). Ebenfalls berechnet er was sonst so in der Welt unabhängig vom Spieler (oder nur vom Spieler gestartet) passiert, und steuert dabei aber auch noch eine ganze (Spiel-) Weltbevölkerung von NPC's und Monstern die sich ja scheinselbständig in der Welt bewegen und agieren und reagieren.

Da dies sehr viele Aufgaben gleichzeitig sind werden die verschiedenen Aufgaben am Besten soweit möglich in mehrere eigenständige Programme (Server) unterteilt welche dann auch verschiedene Hardware-Maschinen sein können. Allerdings beeinflussen all diese Sachen sich ja gegenseitig und daher muss er wieder eine Sprache haben um mit den anderen Server(-Typen) reden zu können, und mit ihnen muss er sich noch schneller und besser absprechen als mit dem Client.

So, das ist nun mal eine Beschreibung des Programmierungs-Teiles alleine.. der nicht sichtbar ist (wird meist nur bemerkt wenn was NICHT funktioniert), ohne die Tonnen an Inhalt, Bildern, Geräusche und Musik. Auch lohnt es sich in der Regel erst mit diesen Dingen zu beginnen wenn die Programmteile die z.B. die 3D-Modelle anzeigen bereits einigermassen fertig sind weil sonst hat man möglicherweise einen grossen Haufen an Material dass man nicht verwenden kann weil es im Game drin zusammengesetzt halt doch ganz anders aussieht als beim herstellen.
Dann ist ja da noch die möglicherweise recht komplexe Spiellogik insbesondere die KI für die NPCs und Monster.



fkrauthan: Wäre das vielleicht etwas für das Magazin? Nicht weil ihr da viele MMORPG-Progger-Besucher habt, sondern weil viele Anfänger nicht wissen wie das eigentlich technisch in etwa aussieht. Wenn Du willst stell ich es entsprechend angepasst bei dir rein..

EDIT: einige Rechtschreibfehler korrigiert und zwei Sätze ergänzt

wow, wirklich toller artikel beneroth
wäre auch dafür, dass der ins magazin kommt

noch was als nachtrag wegen daten schicken: bei wow ist es so, dass der client bei sich alle daten gespeichert was die models und items und spells angeht. auf dem server ist auch alles gespeichert und vorallem noch mehr. die ganzen texte sind auf dem server gespeichert und werden bei bedarf an den client geschickt (da kann man dann auch das 'protal' von blizzard wieder 'portal' nennen ). auch kann man z.b. auf wow-private-servern eigene waffen & rüstungen machen, da die auch alle beim server gespeichert sind. der schickt dann nur die anzeige-id (also die id des models) und die daten (stärke, zusatzpunkte und blablabla) an den client.