MMORPG ohne großen Server?
-
rüdiger schrieb:
Im Grunde sieht es ja so aus, das der Status eines Charakters ja eh mehreren Clients bekannt ist (macht ja keinen Sinn, jedes mal die Daten neu zu verteilen). Wenn nun ein Charakter seinen langfristigen Zustand verändert (zB ein Level-Upgrade) oder der Spieler vom Netz getrennt wird, dann erstellen alle Clients die die Daten des Charakters spiegeln ein Zertifikat mit ihrem Schlüssel. Der Client des Spielers sieht den privaten Schlüssel überhaupt nicht. Die Zertifikate werden dann nach Möglichkeit weiter verteilt und wenn es geht auch an den Spieler weitergeleitet.
Die Zertifikate lösen aber nicht das eigentliche Problem. Angenommen es tritt ein Ereignis ein, dass die Daten des Charakters beeinflusst (z.B. besagtes Level-Upgrade). Dann muss jeder Client, der die Daten dieses Charakters repliziert, nicht nur dieses Ereignis mitgeteilt bekommen, sondern jeder Client muss überprüfen, ob das Eintreten dieses Ereignisses auch legitim ist. Und wenn man näher drüber nachdenkt, wird man feststellen, dass auf diese Weise alle Aktionen eines Benutzers übermittelt und redundant geprüft werden müssen. Ich glaube kaum, dass die daraus resultierende Komplexität sinnvoll bewerkstelligt werden kann.
-
byto schrieb:
Und wenn man näher drüber nachdenkt, wird man feststellen, dass auf diese Weise alle Aktionen eines Benutzers übermittelt und redundant geprüft werden müssen. Ich glaube kaum, dass die daraus resultierende Komplexität sinnvoll bewerkstelligt werden kann.
Ja, ich sehe da jetzt kein Problem.
-
kennst du mmorpgs? "jedwede aktion" beinhaltet mindestens eine legalitätsprüfung jede sekunde. pro objekt. sind schon 2 für einen spieler und seinen mob. wenn er fünf gegner hats sinds 6. wenn es sich um eine gruppe handelt... usw.
die komplexität explodiert da.
-
thordk schrieb:
kennst du mmorpgs? "jedwede aktion" beinhaltet mindestens eine legalitätsprüfung jede sekunde. pro objekt. sind schon 2 für einen spieler und seinen mob. wenn er fünf gegner hats sinds 6. wenn es sich um eine gruppe handelt... usw.
die komplexität explodiert da.
Es muss ja nicht jeder Spieler die Aktionen aller anderer Spieler prüfen. Es reicht ja, wenn jeder Client zwei oder drei weitere Spieler prüft (kann man ja sogar relativ gut verteilen im p2p, so das ein schneller rechner mit schneller internet anbindung mehr prüft, als eine lahme gurke an einem lahmen modem).
So komplex kann eine Prüfung ja nicht sein, da es ja auch auf den Servern eines Server basierten MMORPGs durchgeführt werden muss und die haben ja noch eher Probleme mit Rechenleistung.
Ich sage mal, bei einem P2P-MMORPG muss man sich um Rechenleistung eher weniger sorgen machen und Netz-Anbindung dürfte in der heutigen Zeit ja auch immer weniger ein Problem sein.
-
wie wäre es wenn der server alle ips von allen spielern kennt und die spieler dem server alle paar ms den genauen standort des charakters mitteilen, und der server dann den spielern die ips der anderen spieler mitteilt welche sichtbar für ihn sind. ab dann könnten die spieler, die sich gegenseitig sehen die dinge unter sich ausmachen. spieler die sich nicht sehen brauchen ja auch untereinander nichts miteinander ausmachen.
die spieler könnten dann gegenseitig auf sich aufpassen und so sicherstellen das keiner cheatet.
wenn ein spieler alleine irgendwo ist und ihn keiner sehen kann muss der server die aufgabe übernehmen.
-
welcher Server?
-
rüdiger schrieb:
welcher Server?
das es nicht ganz ohne server geht haben wir ja schon festgestellt. ich denke so würde der server mit relativ wenig last auskommen.
-
rüdiger schrieb:
welcher Server?
wenn man unbedingt will, geht das auch ganz ohne zentralen server. genauergenommen das komplette gegenteil: ganz viele server. "distributed parallel multihosting": ein spieler kann nur areale betreten, die er kennt. kennen bedeutet, dass er die ip des arealhosts kennt, oder von seinem derzeitigen host diese beziehen kann. (über eine neuartige technologie, manchmal "hyperlink" genannt.) dieser host ist für alle clients im areal zuständig, und bestimmt, wer was mit wem abklären muss. ein zentraler server würde so nicht mehr nötig, aber immer noch sinnvoll, um startschwierigkeiten und inselbildungen zu vermeiden.
-
@lckjvask...:
Ok, aber wie läuft das dann weiter?
Ich sehe 2 Möglichkeiten:
A) der "Arealhost" verwaltet nur eine Liste "wer ist hier". Alles andere läuft p2p, und jeder ist Replication-Master für "seine" Objekte, also seinen eigenen Character, etc. Replication-Master für NPCs ist der "Arealhost". Updates werden vom Replication-Master für das jeweilige Objekt an alle Spieler in der Area + den "Arealhost" versendet.
der "Arealhost" verwaltet nicht bloss die Liste "wer ist hier" sondern verteilt auch alle Updates. Der Replication-Master eines Objektes schickt seine Updates an den "Arealhost", und dieser verteilt es an alle anderen Spieler in dieser Area.Soweit so gut. Nun laufen 500 Spieler "auf den Hauptplatz" (eine Area halt).
Bei A: jeder Spieler-PC muss Updates über seine Figur an 500 Peers schicken, der "Areahost" muss noch dazu Updates über die ganzen NPCs an 500 Peers schicken. Der "Areahost" ist dabei nicht unbedingt das Problem, denn wer "Areahost" macht kann man ja anhand der Bandbreite auswählen. Die Spieler PCs gucken u.U. aber doof wenn sie über eine ADSL Leitung mit vielleicht 64 oder 128kBit Upload Updates an 500 Peers schicken sollen. Weiters können die Daten nicht "gepackt" werden, jedes Update an jeden Peer ist ein eigenes Paket, was wieder Bandbreite vernichtet.
Bei B: die Spieler-PCs müssen bloss Updates an den "Areahost" schicken, bloss der muss jedes eingehende Update der 500 Spieler an alle anderen 499 Spieler verteilen. 500*499 -> mächtige dicke Zahl, das wird ein PC mit normaler Internetanbindung nicht so schnell packen.
B denke ich kann man streichen, aber A...?
Möglich wäre es sicher, aber das "massive" in MMORPG stellt u.U. einiges an Anforderungen an die Leitung der Spieler.@all:
BTW: um das besser abschätzen zu können, und weils mich jetzt gerade interessiert: weiss jmd. wie viele kleine UPD Pakete (sagen wir 16 oder 32 Byte Nutzdaten) man pro Sekunde über eine ADLS Leitung mit z.B. 64kBit Upload rausbekommt? Also nicht theoretisch, sondern unter realistischen Bedingungen. Und die 2. interessante Sache wäre: hat jemand irgendeinen Anhaltspunkt dafür mit wieviel verlorenen UPD Paketen man bei so einem Online-Spiel rechnen sollte? Eins in 10, in 100, ein 1000? Oder noch mehr/weniger?
-
Interessante Analyse hustbaer!
Darüber hinaus sollte aber noch bedacht werden, dass die Pakete nicht nur verschickt sondern zunächst berechnet werden. In Anbetracht der Tatsache, dass ein durchschnittlicher Spieler-PC bei momentanen MMORPGs alleine schon durch die Grafik-Engine ausgelastet ist, dürfte das schwierig werden.
-
Sorry Jungs wenn ich da mal den Spielverderber spiele, aber das ist eigentlich ziemlich dumm:
1.Woher sollen die anderen Spieler wissen wo sich jeder grade befindet?
N Auraprinzip, das vom Server berechnet wird ist da schon viel eleganter.
Der Client sendet jede Statusänderung seiner Bewegung an den Server und der teilt diese nur den Spielern mit, die das auch interessiert. Wenn jeder Spieler jeden anderen Spieler ständig über den Kram informieren würde, dann ist das ziemlicher Murks. Server müssen ja nicht ganz nebenbei noch 3D Kram, Sound, etc berechnen, sondern tun zu 90% nichts anderes als auf die Positionierung und Plausibilitätsprüfung von Positionen zu achten. Ich stell mir grade die FPS-Zahlen für n MMORG mit 1500 Spielern vor, das Peer-to-Peer läuft...autsch...2.Exploits!!! Wer soll den checken was da ok läuft und was nicht? Wer verwaltet die Accounts der Spielerkonten (und damit meine ich nicht Abrechnung sondern ITEMS, HP, etc)? Wer sperrt Spieler die ein "falsches Spiel" treiben?
3. Updates...
Wenn da was geupdatet werden muß und alle sind immer online?!? Na toll. Da fliegen dann auch Berge an Paketen durch die Luft....Zu Urfrage:
Ja, ein MMORPG geht auch auf einem Server, aber nur mit begrenzten Spielerzahlen (bis ca. 1000), danach sollte man für Updates, Accounts, etc eher zu einem ServerGrid tendieren.
-
Die Idee war nicht, dass jeder mit jedem kommuniziert, sondern nur mit denen in der Nähe.
1 2 3 4 5 6 7 8
3 kommuniziert mit 1,2,4,5. Geht er näher zu 4, fragt er diesen wer in dieser richtung noch ist, der sagt ihm 6. Und dann kommuniziert er auch mit 6, dafür mit 1 nicht mehr usw.
-
Woher soll aber 7 wissen wer sein nächster ist...
und dann wer noch alles dabei ist...
Woher wissen 7 & 8 dass sie nicht nur die einizen beiden sind?
Bei wem logged sich 9 ein wenn er spielen will?Mag zwar n netter Gedanke sein...so ohne Server, aber:
Server kosten nun wirklich nix mehr.
Du hast keinen Overhead an Messages die hin und her gehen, etc.Nehmen wir doch mal 4:
Woher weiß 3 überhaupt wo 4 ist? Von einer alten Nachricht von 1 oder der neueren von 2???Teil die Welt in Cluster auf.
Setzt die Kanten überlappend.
Wenn du mehr Spieler hast, als ein Server packen kann, dann haste auch locker die paar Euro für einen zweiten Server
Rechenbeispiel:
1000 Spieler zu 10.- = 10000.- p.Monat
Ein Serverschrank 40HE inkl. Strom 800.- pro Monat = Rest=9200.-
Die 1000 Spieler kannste je nach Netzwerktraffic/GameProto locker über einen Server laufen lassen (kleinen Server für den Anfang 1000.-...kann nachher immer noch für Accounts oder sowas eingesetzt werden.)
Rest 8200.-
Traffik bei dem Aufkommen für ca. 0,50 pro GB.Jetzt hängts von dir ab, was du aus der Kohle machst.
Mit wenig Webtraffic bleibt viel über, mit nem blöden Proto zahlste drauf.Was soll eigentlich der Grund sein, warum die Peer-to-Peer gehen willst?
Sag nicht, weil es nix kosten soll...
Womit willste dann die Systemadmins/Guides (die den Ablauf überwachen), die Coder (die das Game aktuell halten), die Grafiker (die riesige welten bauen) und die Skripter und Leveldesigner dauerhaft bei der Stange halten?
-
TsPaddy 10€ zu zahlen kostet schon überwindung, nicht der betrag sondern das zahlen ansich und der ganze aufwand usw. (für den betreiber und den kunden)
der markt ist schon gesätigt, da kann man nur noch was gewinnen über "kostenlos"
außerdem ist ein nicht-p2p-mmorpg keine herauforderung und nix neues
Womit willste dann die Systemadmins/Guides (die den Ablauf überwachen), die Coder (die das Game aktuell halten), die Grafiker (die riesige welten bauen) und die Skripter und Leveldesigner dauerhaft bei der Stange halten?
das ist ganz einfach, du läst wettkämpfe zwischen deinen spielern machen wer das schönste neue Monoster designt hat, bezahlt wird er in gold, außerdem erhalten freiwillige mitarbeiter sonderskills und dürfen items tragen wie sonnenbrillen
man muss sich nur ankucken wie viel zeit die spieler in solch mmorpg investieren, wenn man es schaft nur ein bruchteil dieser zeit in dir richtige richtung zu lenken ...
-
Autsch...das sind jetzt mehrere Denkfehler auf einmal:
1. Spieler spielen. Entwickler entwickeln. Spielwelten, die von Spielern frei mitgestalltet werden können sehen i.d.R. grauselig aus (wie SecondLife).
Wenn du Entwickler haben willst, dann gibts 2 Optionen:
a- du bezahlst und bekommst Leistung
b- alle machen das freiwillig und das Koordinieren gleicht einem unmotivierten Haufen Ameisen.
Du kannst natürlich immernoch deinen Spielern das Angebot machen, aber viel wird da nicht an echtem Highend Zeug kommen.2. Nicht das Arbeiten ohne Server ist die Herausforderung...
...die Herausforderung ist für den Spieler möglichst viel Spiel mit möglichst resourcenschonenden Mitteln zu erstellen.3. Der Markt ist gesättigt ist auch mehr als falsch!
Wieviele Spieler zocken heute noch Ultima Online? Nicht viele??? Warum nicht?... Ach ja, das Spiel ist nicht mehr UpToDate! Und das gleiche wird irgendwann WOW, EQ, etc passieren. Man darf also nicht von Sättigung sprechen, sondern eher von Evolution.4. Nicht die Netzwerkarchitektur verkauft das Spiel...es sind die Inhalte!
Wer keinen Content liefert, der kann ne noch so abgefahrene Technik haben; Die Sache wird den Bach schneller runter gehen, als die QuestDesigner nachlegen können.5. Ein nicht p2p MMORPG ist sehr wohl immer was neues! Neue Grafikeffekte, größere Welten, mehr Spieler, CleverGizmo-Itemkram, etc... Wie gesagt, ein MMORPG ist ein Spiel und das ist für den Spieler da und nicht für den Programmierer!
Noch was zu den 10.-
Wenn deine Spielwelt was hergibt, dann bekommste die auch. Wenn deine Spielwelt nix hergibt, dann bekommste nichtmal Spieler!
-
TsPaddy schrieb:
Sorry Jungs wenn ich da mal den Spielverderber spiele, aber das ist eigentlich ziemlich dumm:
"Sorry" TsPaddy "aber das ist eigentlich ziemlich dumm" was du schreibst. Das System hat sicher viele Probleme, aber alle Probleme die du aufzeigst, haben wir während der Diskussion schon einmal gelöst...
Die Daten werden nur zwischen in einem gewissen Umkreis ausgetauscht und von jedem Spieler noch an die Kontrolleure weiter geleitet. Wobei man auch ohne Probleme Leute mit schneller Anbindung als Nachrichten-Forwarder benutzen kann. So das jemand mit einem Modem nicht 100 Leuten seine Position schickt, sondern nur 2 oder 3 Leuten, die dann die Nachricht weiterleiten.
Woher ein Client wissen soll, mit wem er sich verbindet? Ganz einfach: Der Client wird einfach so weit durchgereicht, bis er für die anderen Clients lokal genug ist.
Updates dürften auch kein Problem sein. Man kann eben nicht von jetzt auf gleichen Updaten, wenn man das Protokoll ändert, sondern setzt für das Update eben einen Termin fest. Wer bis dahin nicht upgegradet hat, kann sich eben erst nach einem upgrade verbinden.
-
Sorry, aber das ist von hinten durch die Brust ins Auge:
Das hin und her reichen beschleunigt das ganze nicht.
Das kreuz und quer updaten ist auch nicht grade Leistungsfördernd.
Das Napsterbeispiel (denke ihr meint typische Downloadportallösungen) ist für Realtime nicht zu gebrauchen (wenn ich erst nur kontakt zu 5 Spielern habe, dann sehen ich 5 Leute...nach und nach werden es immer mehr und wenn zwei den gleichen Raum einnehmen, weil das vorher nicht klar was in Ermangelung von bekannten Clients, dann geht das wilde gehoppel los oder die Correctionmessages türmen sich...Also mal ganz ehrlich: WAS SOLL DAS BRINGEN?
Ihr redet nur über das "wie"...was ich vermisse ist das "warum"!
Ich kann mir eine Dampflok vor's Haus stellen um damit mein Kaffeewasser heiß zu machen, aber das geht mittlerweile auch einfacher und eleganter!
Kann mit nicht mal einer einen echten Vorteil zu einem Gameservermodel sagen?
Und wenn das die 50.- für einen Server (inkl. 1000GB Traffic) pro 500 Personen sein soll, dann gute Nacht.
Ernste Frage: Wer tut sich so einen Wust für umgerechnet 0.10 pro Spieler an (wenn der Traffic überhaupt voll wird)?
Alleine der Mehraufwand beim Proggen würd mich schon dazu bringen auf die 50.- zu pfeifen und es klassisch zu lösen.ALSO: EINEN ECHTEN GRUND!!!
-
TsPaddy schrieb:
Also mal ganz ehrlich: WAS SOLL DAS BRINGEN?
Ihr redet nur über das "wie"...was ich vermisse ist das "warum"!Manche Leute haben einfach Spass daran neue Ideen zu durchdenken und neue Probleme zu lösen.
Warum sollte es weniger Aufwand sein Serversoftware zu schreiben, die eine ordentliche Lastverteilung macht und tausende von Usern versorgen kann, als das ganze für Clients zu programmieren?
-
Sicher, aus kommerzieller Sicht macht eine Server-Lösung Sinn. Aber wenn man ein freies oder nicht kommerzielles MMROPG entwickeln will, ist ein Server eben nicht finanzierbar! (Der Unterschied ob ein Nutzer im Internet 10€ oder 0.10€ zahlt ist zur Zeit eben deutlich kleiner, als der Unterschied zwischen 0€ und 0.10€ ...)
Vor allem kann ein P2P-Netz auch richtig groß werden, da die "Server-Leistung" mit jedem Client wächst, während bei einer Server-Lösung die "Server-Leistung" mit jedem Client schrumpft.
MancheLeute schrieb:
TsPaddy schrieb:
Also mal ganz ehrlich: WAS SOLL DAS BRINGEN?
Ihr redet nur über das "wie"...was ich vermisse ist das "warum"!Manche Leute haben einfach Spass daran neue Ideen zu durchdenken und neue Probleme zu lösen.
Warum sollte es weniger Aufwand sein Serversoftware zu schreiben, die eine ordentliche Lastverteilung macht und tausende von Usern versorgen kann, als das ganze für Clients zu programmieren?
-
Der TsPaddy hat da schon Recht. Es gibt keinen wirklichen Grund sowas zu entwickeln, weil es andersrum ja bewiesenermaßen besser funktioniert.
Gruß, TGGC (\-/ has leading)
