MMORPGsVeröffentlicht von: Gryphus am 05. 2005 um 00:35 UhrQuelle: http://vsoh.molgam.net |
|
rundlegende Informationen über MMORs verquest 2 und auch andere Spiele, wie Star Wars alaxies, Ultima Online, Final Fantasy XI gehören zum enre der MMOR. Das heisst verkürzt Massively Multiplayer Online Role lay ame und bedeutet alleine vom Namen her 3 Dinge: Das Spiel ist ein Rollenspiel, das ausschliesslich online gespielt wird und zwar mit vielen Leuten. Im egensatz zu Offline Rollenspielen, wie Morrowind, othic 2, Neverwinter Night oder Baldurs ate 2 oder Online Multplayer Spielen wie Unreal Tournament 2003, Counter Strike, Warcraft 3, entwickelt sich die Welt weiter, auch wenn der Spieler nicht im Spiel eingeklinkt ist („persistente Welt“). Das bedeutet auch, dass sich die eschichte, die eschehnisse, die Inhalte, usw. weiterentwickeln, z.b. neue Quests oder neue Mobs oder einmalige vents implementiert werden. Dies wird durch ein sogenanntes Live Team ermöglicht. Das Spiel ist auch weit riesiger, es gibt nicht nur Städte, Wälder, weite ebirge, sondern auch Kontinente, manchmal kann man auch auf anderen laneten oder Dimensionen oder auf einem Mond spielen. usserdem ist es möglich, dass Tausende von Spielern gleichzeitig auf dem Realm (also auf den Servern, die die Spielwelt simulieren) sind und zusammen spielen können Der Service ist auch bemerkenswert, es ist im Spiel möglich eine nfrage zu starten, z.b. wegen eines möglichen Bugs und es wird wirklich schnell geantwortet (bei Q1 meist innerhalb von 15 Minuten). Da also die rogrammierfirma wegen der Bereitstellung der Server, der Implementierung neuer Inhalte, der hohen Komplexität eines MMORs laufend Bugs beseitigt, des hohen Service auch hohe Kosten hat, muss man pro Monat einen gewissen Beitrag zahlen um das Spiel weiter zu spielen. Dieser beträgt meist zwischen 10-15 uro im Monat. Nachdem man sich aber das Spiel gekauft hat (zu normalen reisen, also 40-45 uro), ist ein Monat gratis enthalten. Detaillierte Informationen über MMORs 1.rinzip: Heartbeat/ Tick Der Kern eines MMORs ist der Heartbeat, Spieler nennen es meist "Ticks", das ist tatsächlich sowas wie ein "Herzschlag". Bei Q schlägt der Heartbeat alle 3 Sekunden (wenn ich mich richtig erinnere). in "Tick" ist also 3 Sekunden. Dieser Herzschlag löst alle vents im Spiel aus. Z.B. wird man bei jedem Tick ein wenig regenerieren. Ist man vergiftet wird man mit jedem Tick Schaden nehmen. in leichtes ift könnte definiert sein 20 Ticks lang zu wirken. benso tauschen Server und Client mit jedem Tick ositionsmeldungen aus. Der Client meldet dem Server wo der Spieler gerade steht, in welche Richtung er schaut und mit welcher eschwindigkeit er in welche Richtung wie schnell läuft. Ändert sich daran etwas weil der Spieler z.B. plötzlich stehen bleibt geht wieder eine neue Nachricht an den Server. Der Server erhält diese Meldungen von allen Spielern und berechnet selber solche Daten von allen Objekten im Spiel die er kontrolliert (z.B. NCs, mobs oder Vehikel). Dann erhält jeder Client alle Informationen die er braucht um die Umgebung für den Spieler darstellen zu können. Dieses System hat sowohl Vor- als auch Nachteile. Der größte Vorteil ist das der Client komplett frei in seinen Bewegungen ist und somit unabhänging vom ing jeder Spieler die gleiche Bewegungsfreiheit hat. Der Nachteil wird in der Darstellung deutlich. Kommt etwa ein Spieler auf mich zugerannt und bleibt dann plötzlich stehen, so sehe ich erst das er stehen bleibt wenn diese Information meinen Client erreicht. In der Zwischenzeit sehe ich ihn weiter laufen weil das die letzte Information ist, die mein Client zur Berechnung meiner Umgebung hat. Das führt bei einem Lag dazu das mich der Spieler erst über den haufen rennt um dann abrupt wieder vor mir auf zu tauchen. Nämlich dann wenn das Lag vorbei ist und seine tatsächliche osition meinem Client gemeldet wird. 2.rinzip: Objekt in zweites grundlegendes rinzip sind die Objekte. Wirklich alles was in irgendeiner Form interagieren kann ist ein Objekt. in anzer lanet ist ein Objekt und ein Sandkorn das ich in mein Inventar nehmen kann ist ebenfalls ein Objekt. in Spieler ist ein Objekt, ein NC ist ein Objekt, auch ein Raum ist voller Objekte. Die igenschaften eines Objektes definieren sich über viele Tabellen mit Informationen wie die röße des Objektes, das ewicht, ist es ssbar?, ist es vergiftet?, mit welchem ift? was soll passieren wenn es gegessen wird? usw. Wenn es ein vergiftetes Objekt ist und ich esse es, so ist das ift selber auch wieder ein Objekt. Das Objekt das ich gegessen habe ist nun vermutlich aus meinem Inventar verschwunden oder ein "Teller emüsesuppe" durch das Objekt "schmutziger Teller" ersetzt worden. leichzeitig habe ich in einem unsichtbaren Inventar das Objekt "ift" erhalten das mich nun mit jedem Tick vergiftet bis es sich selbst löscht oder dadurch das ich das Objekt egengift trinke von diesem gelöscht wird. Mit diesem Wissen lassen sich sehr viele "Fehler" in einem MMOR erklären. twa warum man einen Muffin nicht essen kann (der rogrammierer hat versehentlich die igenschaft "ssbar" vergessen). uch das Crafting System lässt sich einfacher verstehen. Wenn man 5 Objekte in ein sechstes Objekt legt und dann "Kombinieren" klickt, entscheidet das sechste Objekt ob diese 5 Objekte kombiniert werden können, in welcher Form und was mit diesen 5 Objekten dann geschieht und welches neue Objekt dann erscheint. Leichte Nachlässigkeiten in der rogrammierung führen dann dazu, dass man sich aus "a egg" und anderen Zutaten ein Omlette kochen kann. "n egg" (Schreibweise beachten!) dazu aber nicht verwendet werden kann. in rogrammierer hat halt eine bestimmte, wichtige igenschaft bei "an egg" vergessen. Das Crafting System soll ja dynamisch sein. Das wird vermutlich bedeuten jedes Objekt hat noch eine Tabelle mit Haufenweise "Crafting igenschaften". Blei könnte etwa die Information beinhalten sich mit Zink als nergiequelle zu eignen. Jeweils mit einer Information darüber wie Hochwertig eine solche Kombination mit diesem Objekt werden kann. Das Objekt "nergiequelle" könnte sich dann mit Objekten, die etwa die usprägungen "Waffengehäuse" und "Lasergenerator" besitzen, zu einer Laserpistole kombinieren lassen, vorausgesetzt die Qualität und die röße stimmen. Wie diese Laserpistole aussieht, welche Farbe die Teile haben, wie gut man damit Zielen kann und wie schwer die Treffer sind definiert sich in dem neuen Objekt durch die igenschaften der Objekte aus dem es entstanden ist. rinzipien der rogrammierung und der bläufe Die 4 lemente eines MMOR sind 1.) Der Server-Core. rogrammiert in C/C++ bringt er, wie schon beschrieben, einen Interpreter für eine objektorientierte rogrammiersprache mit und sorgt für den HeartBeat. 2.) Die Library. Das ist das Juwel eines jeden MMOR, die Bibliothek von Objekten und Funktionen auf denen das Spiel basiert. Sie ist die größte Investition bei der rschaffung eines neuen MMORs und wird in der Script-Sprache erstellt. 3.) Die Objekte. Das eigentliche Spiel, ebenfalls in der Script-Sprache. 4.) Der Client. Sorgt für die visuelle Darstellung des Spiels. In etwa programmiert wie ein Shooter auch. Ist der einzige Teil der beim Spieler liegt. Der unkt der das eigentliche Spiel ausmacht sind die Objekte. Die grundlegende Struktur eines Objektes wird in der Library definiert. in rogrammierer "holt" sich aus der Library ein usgangsobjekt und modelliert es nach seinen Wünschen um das zu erhalten was er möchte. Beispiel Wasser ls Beispiel könnten wir mal einen einfachen egenstand produzieren, sagen wir eine Flasche mit Wasser: ls erstes holen wir uns dazu aus der Bibliothek das Objekt "eatable". Darauf basieren alle "egenstände" die irgendwie essbar oder trinkbar sind, also z.B. Fleisch, Zucker oder halt auch eine Flasche Wasser. Jetzt Modellieren wir diesen einfachsten aller egenstände zu einer Flasche. Zunächst nennen wir das "eatable" mal in "Flasche" um. Wir weisen dem egenstand eine 3D rafik für die Spielewelt zu und eine 2D rafik die ihn im Inventory repräsentiert. Dann legen wir verschiedene Objekteigenschaften fest: ------------------------------------------------------------------------- Flasche.ewicht = 100 g Flasche.Breite = 6 cm Flasche.Tiefe = 6 cm Flasche.Höhe = 15 cm Flasche.Farbe = transparent Flasche.Material = las Flasche.Verkäuflich = Ja Flasche.Tauschbar = Ja Flasche.blegbar = Ja Flasche.Qualität = 50 Flasche.Decay = 10000 Flasche.Inhalt = Wasser Flasche.ssbar = Ja -------------------------------------------------------------------------------- Wir haben also festgelegt wie roß und Schwer unsere Flasche ist, aus welchem Material und Farbe, daß man sie an NCs verkaufen kann, sie mit anderen Spielern tauschen kann und auch einfach ablegen kann. Die Qualität ist 50 und alle 10.000 Ticks wird von der Qualität eins abgezogen bis sie bei 0 unbrauchbar wird. Zuletzt haben wir der Flasche einen noch Wasser als Inhalt gegeben und sie als ssbar bzw. Trinkbar definiert. Jetzt muß tatsächlich ein wenig programmiert werden. Jedes Objekt "eatable" hat bestimmte rundfunktionen. Versucht ein Spieler ein solches Objekt zu essen wird in dem Objekt eine Funktion "Spieler_will_es_essen()" aufgerufen. Ist diese Funktion nicht da wird das Objekt ganz einfach gegessen und ist dann weg. In unserem Fall möchten wir aber nicht das die Flasche gegessen wird sondern nur das Wasser in ihr getrunken wird. lso müssen wir an dieser Stelle eingreifen um unsere Flasche zu retten Ich versuchs mal so gut es geht mit einer seudo-rogrammiersprache damit es für jeden verständlich bleibt. ------------------------------------------------------------------------------ Function Spieler_will_es_essen() { Flasche.Inhalt = leer Flasche.ssbar = nein Flasche.2D-Bild = leere_flasche.jpg Spieler.Durst += 100 return (NICHT_ZRSTÖRN) } -------------------------------------------------------------------------------- Der Inhalt der Flasche ist also nun leer. s ist nicht mehr ssbar und bekommt ein neues 2D Bild das eine leere Flasche zeigt. Der Spieler bekommt 100 unkte auf seinen Durst gutgeschrieben weil er etwas getrunken hat und schliesslich geben wir an das Objekt die Information zurück, dass es jetzt nicht zerstört werden soll. Die Flasche bleibt also nach dem trinken noch erhalten. In dieser rt gibt es noch viele weitere Funktionen bei denen wir eingreifen könnten. twa könnte aus der Flasche ein "Haufen las" werden wenn ihre Qualität 0 wird. Dazu könnten wir eine Funktion "egenstand_Qualität_abgelaufen()" schreiben die in jedem Objekt immer aufgerufen wird wenn die Qualität auf 0 sinkt. Wenn es sie nicht gibt geht das Objekt halt kaput und verliert jegliche Funktion. Wenn wir eine eigene schreiben könnten wir damit das Objekt durch ein Objekt "Haufen las" ersetzen. Weitere mögliche igenschaften In dieser rt funktionieren alle Objekte in einem MMOR. Hier mal eine paar interessante Funktion, die ein Objekt haben KNN (es muß nicht, aber wir könnten dort halt eingreifen und etwas „passieren lassen“: heartbeat() wird im Objekt mit jedem HeartBeat, also alle 3 Sekunden, aufgerufen. in ift-Objekt könnte das nutzen um dem Spieler alle 3 Sekunden Schaden zuzufügen und sich nach 20 Ticks selbst zu löschen. Objekt_wird_angegriffen() wird aufgerufen wenn das Objekt von einem nderen angegriffen wird. in NC Objekt würde hier reagieren aber auch ein Objekt wie Sprengstoff könnte "angreiffbar" sein. Objekt_stirbt() in einem NC wird das aufgerufen wenn seine esundheit auf 0 sinkt. Normalerweise wird ein NC einfach durch ein default Objekt "Leiche" ersetzt die dann mit dem im Objekt definierten Loot ausgestattet sein kann. s wäre aber vorher z.B. noch ein besonderer Todesschrei möglich. Objekt_halb_tod() wird aufgerufen wenn ein NC nur noch die hälfte seiner nergie hat. vtl. möchte er dann seine Kampftaktik ändern? Objekt_fast_tod() wird aufgerufen wenn ein NC nur noch 20% seiner nergie hat. Vielleicht flüchtet er dann oder er ruft um Hilfe. Spieler_will_es_anziehen() wird aufgerufen wenn ein Spieler versucht sich das Objekt anzuziehen. vtl. ist es ja gefährlich dieses Objekt anzuziehen und der Spieler bekommt einen elekrischen schlag. Oder das Objekt hat besondere Fähigkeiten und erzeugt z.B. ein nergiefeld um den Spieler herum. Man sieht, es gibt nahezu unendlich viele Möglichkeiten wie Objekte auf ihre Umgebung und auf die Spieler reagieren könnten. Und zum Mob des rauens Naja, in Objekt_stirbt() kann ich natürlich auch den Mob einfach "verschwinden" lassen und durch eine Version des gleichen Mobs ersetzen, die es als eist repräsentiert und weiter kämpft. Für den Spieler stellt es sich so dar als wäre der Mob nun zum eist geworden. s wurde auch mal gefragt wie es möglich ist das man Darth Vader nicht töten kann. In Objekt_halb_tod() könnte eine Horde Wachen aus einem Nachbarraum kommen und Vader Helfen. In Objekt_fast_tod() könnte Vader die Flucht antreten und durch eine Türe verschwinden die er hinter sich zusperrt. So gibt es noch viele weitere Objektarten im Spiel. Offensichtliche, wie einzelne egenstände oder mobs, und weniger offensichtliche wie etwa einzelne Missionen oder Buffs. .S.: In Wahrheit funktioniert es natürlich doch noch etwas anders aber das rinzip ist schon sehr ähnlich. (Quelle: gracjanski auf http://www.everquestii.info) |
|
Gedruckt: 26.12.2024 - 12:15:32 |