MMORPG ohne großen Server?
-
schue schrieb:
Damit steht die Frage im Raum: Wie willst Du es anstellen daß jeder Client nur Daten von solchen Clients bekommt die für ihn aktuell relevant sind ohne das er dazu regelmäßig die Positionsdaten aller Clients erhalten muß?
Larko schrieb:
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.
-
1,2,3,4,5 stehen auf einem Fleck, um sie herum ist kein anderer client in der Nähe. Jetzt bewegt sich 3 von der Gruppe weg. Wen fragt er jetzt?
Mit wem kommuniziert ein Client wenn keine anderen Clients in seiner Nähe sind?
Wie findet ein neu eingeloggter Client andere Clients in seiner Nähe?
Was passiert wenn mal 100 Clients auf engstem Raum in der Spielwelt stehen?
Natürlich klingt die Idee, einfach nur mit den Clients in der Nähe zu kommunizieren auf den ersten Blick einfach, simple und so als ob das funktionieren könnte. Aber das tuen die meisten Ideen wenn man sie nur genügend abstrakt betrachtet. Dabei behaupte ich ja (noch) gar nicht es sei unmöglich.
Jedoch ist die Kommuniktaion so grundlegend wichtig für ein Morg, daß sie Hieb- und Stichfest funktionien muß. Das Zitat von Larko setzt implizit vorraus das alle Clients einigermassen gleichmäßig über die Spielwelt verteilt sind... Das dürfte aber in der Realität nahezu niemals der Fall sein. Vile eher wird es immer eine Ballung von Clients in bestimmten Regionen geben während gleichzeitig andre Regionen komplett leer sind...
edit: v***** stehr für v-o-r-r-a-u-s warum das einen badword-Filter trigger k.a.
-
Man kann ja auch "in der Nähe" mit "am nähesten in dieser Richtung" ersetzen, dann kann auch mal viel leerer Platz dazwischen sein.
vorraus
schreibt man voraus
-
Erst mal frohes neues Jahr!!!
Das ist ja was ich meine.
Es weiß keine Kiste wer grade in seiner nähe ist.
Dafür muss ja andauernd im bestand der Spieler herumgestochert werden.
Wenn das nun aber 1000000 Spieler sind und wir an einem harten Tag (sagen wir mal Tag der Arbeit...alle haben frei und sind am zocken) davon 300.000 online haben, und du zum vereinfachen ein Quasi Spieler/Zwischenknoten einrichtest, und der ganze 150 Spieler verwaltet (gehe davon aus du hast mit weniger Spielern pro Knoten gerechnet), hat der sich mit nicht weniger als 2.000 Rechnern auseinander zu setzten, die ebenfalls als Knoten versuchen miteinander zu kommunizieren.
Wenn die nun nicht alle mit allen verbinden sollen, sondern du weiterreichst, dann gehen wir mal hin und verbinden die Latenzen (120ms mal im Mittel angenommen...du wirst aber fiesere Router vor die Nase bekommen). Die Werte in Klammern sind die Gesamtzeit der Meldund:Spieler an Knoten (120ms)
Knoten an Spieler (240ms)
Knoten an Nachbarknoten (240ms)
Nachbarknoten an Spieler (360ms...schon ziemlich oll)
Nachbarknoten an seinen Nachbarknoten (360ms)
Spieler in dem 2.Knoten (480ms schon echt schlecht)
...
etc.
Wie gesagt...das sind jetzt Fälle, bei denen ich mit 150 Rechnern pro Knoten rechne...und das packt kein Client mit asyncronem DSL. Wenn du aber nur Knoten für 5 Rechner aufstellst (wolltest ja Kontrolleur für 2 oder mehr), dann kennen erst 125 Leute deine Daten nach 480ms...Da nicht alle Spieler ne direkte Backboneverbindung haben sind deren Leitungen entsprechend langsam. Das bedeutet, zzgl. der Rechenzeit um das Signal zu verarbeiten, das jeder der 150 Spieler die Nachricht schon technisch etwas später bekommt, da sie ja hintereinander weg und nicht simultan raus gehen. Ist zwar auch beim Server so, aber es addiert sich halt alles hoch... und du hast immernoch keine Möglichkeit genannt wie man da mit großen Spieleranzahlen hantieren kann.
Mach doch einfach mal ein Diagramm wie du dir soein P2P Netzwerk vorstellst, schreib mal Zahlen dran und dann schaun wir mal...
(Wichtig: Wie Clients untereinander, wie Knoten untereinander, wieviele je Untergruppe...ect).
-
@rüdiger:
Klar alle erhalten ein paar Zertifikate und schon ist alles sicher. Sag mal, von was träumst du eigentlich nachts...
Nur mal 2 Situationen:
-
Spieler A kommt online und behauptet: Ich habe Item XYZ im Inventar. Auf keinem anderen Client, der online ist, gibt es ein Profil von Spieler A mit Item XYZ. Was passiert jetzt?
-
Spieler A besiegt Gegner X (Wir nehmen mal an, alle Clients sind sich schonmal einig, das X wirklich tot ist). Er behauptet, dafür n Punkte zu erhalten. Meine lokale Rechnung ergibt m Punkte. Plötzlich kommt Spieler B und behauptet, n Punkte für die Aktion sind korrekt. Was passiert jetzt?
Da aller Client Code und Daten offen beliebig manipulierbar bei den Spielern liegen, kann sowas jederzeit passieren. Dann kannst du dein "Web of Trust" knicken. Einmal Bullshit-Bingo für mich! Nichts, aber auch gar nichts ist praktisch gelöst, in dem du irgend so Buzzwords in die Runde wirfst. Hobbyentwicklung eines P2P-MMORPG ist echt schon potenzierter Schwachsinn, einfach mal zwei "tolle" Sachen zusammengeworfen, von Typen mit NULL Plan.
Gruß, TGGC (\-/ has leading)
-
-
schrieb:Man kann ja auch "in der Nähe" mit "am nähesten in dieser Richtung" ersetzen, dann kann auch mal viel leerer Platz dazwischen sein.
Stimmt, daß wäre der nächste Gedankenschritt. Aber wie findest du den nähesten Client in einer Richtung X? Vergiß nicht, daß die Spielwelt mindestens 2D sein sollte. Du müsstest also aus deiner aktuellen Position und deinem Richtungsvektor den nähesten Client in dieser Richtung finden.
Dabei ist der Begriff "nähester" sogar ein größeres Problem als Du denkst. Auf einem Vektor ausgehend von deiner Position können sich schließlich mehrere Clients befinden und die Reihenfolge in der Du diese Clients findest steht in keinem Verhältnis zu deren Eentfernung von Dir. Du mußt also tatsächlich erst alle Clients auf dem vektor finden um dann den ermitteln zu können wer die geringste entfernung zu Dir hat...
Auch das läuft wieder auf einen "Fullscan" aller clients hinaus.
schrieb:vorraus
schreibt man vorausdanke, sowas sollte ich eigendlich selber wissen
-
schue schrieb:
Dabei ist der Begriff "nähester" sogar ein größeres Problem als Du denkst. Auf einem Vektor ausgehend von deiner Position können sich schließlich mehrere Clients befinden und die Reihenfolge in der Du diese Clients findest steht in keinem Verhältnis zu deren Eentfernung von Dir. Du mußt also tatsächlich erst alle Clients auf dem vektor finden um dann den ermitteln zu können wer die geringste entfernung zu Dir hat...
Auch das läuft wieder auf einen "Fullscan" aller clients hinaus.
Nein, du suchst nicht, sondern läst es dir sagen. Das Spiel fängt mit ganz wenigen Spielern an, jetzt kennt jeder jeden. Wenn es mehr werden, interessieren mich die die nicht mehr in meiner Nähe sind nicht mehr. Aber ein anderer, der näher dran ist, der kennt sie noch und wenn ich zu diesem hin gehe, dann sagt er mir sie.
Was natürlich ein viel größeres (unlösbares) Problem ist, dass jeder sich seine eigene Version compilieren kann, wenn der Sourcecode offen ist. Dann kann man sich z.B. eine Version machen, in der man nützliche Daten sieht die andere Spieler nicht sehen können (was ist in diesem Versteck, wieviel X hat Y...).
-
schrieb:Nein, du suchst nicht, sondern läst es dir sagen. Das Spiel fängt mit ganz wenigen Spielern an, jetzt kennt jeder jeden. Wenn es mehr werden, interessieren mich die die nicht mehr in meiner Nähe sind nicht mehr. Aber ein anderer, der näher dran ist, der kennt sie noch und wenn ich zu diesem hin gehe, dann sagt er mir sie.
Damit verlagerst Du das Problem, aber löst es nicht. Einfaches Beispiel: Wir nehmen drei Clients A, B und C die auf einer Linie stehen, aber relativ weit voneinander entfernt. es gibt noch mehr Clients in der Nähe von A und C, aber keiner der zwischen A und C steht ausser halt B. A dropped nun die Information über C weil dieser weit genug entfernt ist und C macht das gleiche, eben weil A weit genug entfernt ist. Soweit, sogut.
Jetzt bewegst sich A auf B zu und wenn A nah genug an B heran ist sagt B ihm, das da noch C ist. Soweit Ok.
Was aber wenn auch B sich in der Zwischenzeit bewegt hat und nciht mehr zwischen A und C steht? Wenn A sich dann Richtung C bewegt nähert kommt keine Info von B, weil B ja mittlerweile ganz woanders ist und möglicherweise selber C gedropped hat. Und schon geht C verloren.
Um das zu verhindern müßte B wissen, das A und C sich nicht mehr kennen und in dem Moment, wo B nicht mehr zwischen A und C ist die beiden wieder miteinander bekannt machen. Dafür mütße B aber Informationen über die Verbindungen von A und C haben...
-
nehmen wir an, A befinde sich in einer umgebung U. da wir keinen zentralen server haben, liegt U auf einem weiteren client C. C ist nun der server für alles, was in U stattfindet, und bestimmt, wer welche informationen braucht. C besitzt auch informationen darüber, wer die angrenzenden umgebungen von U verwaltet, und reicht diese an die clients weiter, die die umgebung verlassen. bedingt durch unsere architektur gibt es natürlich einschränkungen bezüglich der größe von U, und der anzahl der verbundenen clients. es bleibt auch die frage, ob es sinnvoll ist, dass ein client die umgebung verwaltet, in der sich sein spieler befindet, oder ob dies unabhängig sein soll.
-
nachtrag: ich hab's jetzt nicht gelesen, aber wem gerade langweilig ist: (bei mir geht aber nur die google-cache-version)
das scheint zumindest in die richtung zu gehen.
-
TGGC schrieb:
- Spieler A kommt online und behauptet: Ich habe Item XYZ im Inventar. Auf keinem anderen Client, der online ist, gibt es ein Profil von Spieler A mit Item XYZ. Was passiert jetzt?
Wie ich schon sagte, es werden keine Profile auf anderen Rechnern gespeichert.
- Spieler A besiegt Gegner X (Wir nehmen mal an, alle Clients sind sich schonmal einig, das X wirklich tot ist). Er behauptet, dafür n Punkte zu erhalten. Meine lokale Rechnung ergibt m Punkte. Plötzlich kommt Spieler B und behauptet, n Punkte für die Aktion sind korrekt. Was passiert jetzt?
Der Spieler bekommt ja die Daten von anderen Rechnern, mit eben einem Zertifikat. Nimmt er nun andere Daten, dann hat er kein Zertifikat dafür. Aber es ist wirklich eine gute Frage was passiert, wenn die beiden Kontroll-Hosts unterschiedliche Daten liefern. Vielleicht löst man das einfach über das Web-of-Trust und nimmt die Daten von dem Client, dem man mehr "vertraut". Solche Fehler können da ja mit in die Bewertung einfließen.
-
Ich klinke mich jetzt hier aus, denn es wird unrealistisch:
Welche zentrale Stelle soll denn feststellen welche Clients vertrauenswürdig sind? Die von den 10 Cheatern, die also Party zusammenarbeiten oder die von den 3 Schulfreunden die ganz ehrlich zocken? 10 zu 3 Stimmen...der Cheater gewinnt.
Zertifikate sind auch Murks...Soll man bei denn unzähligen von eigenenden Meldungen jedes mal auch noch neben der Kontrolle für die eigene Relevanzprüfung deren Zertifikate übertragen und berechnen...Wer nah und wer weit ist kann man ja noch relativ einfach klären (Vector berechnen und Größe vergleichen), aber für wieviele Rechner?
Wenn du keine Profile auf andern Rechnern speichern willst...doch n Server?
Oder jedes mal durchs Netz jagen?Rüdiger, stell doch einfach mal ein komplettes Konzept für so ein Netz zusammen. Einzelne Schlagwörter ins web werfen und die als durchführbar definieren ist etwas too simple!
Schreib doch mal in das nächste Posting welcher Rechner in welchem Fall was tun muß und dann können wir Bitgenau mal den WorstCase und ein realistisches durchschnittliches Kommunikationsvolumen berechnen. Aber so wie's jetzt läuft bringt der Thread nix!
-
jucks schrieb:
Games are different from previous P2P applications that
focus on the harnessing of idle storage and network band-
width, including storage systems [12], [33], [11], content
distribution [9], [20] and instant messaging [26]. Games
utilize the memory and CPU cycles of peers to maintain
the shared game state. Three potential problems must be
addressed to make this approach fully applicable in practice:
• Performance—games have frequent updates, that must
be propagated under certain time constraints. Further-
more, peers have limited bandwidth since they are
located at the edge of the network.
• Availability—replicating game states to improve avail-
ability has two potential problems. First, once a peer
goes offline, its state quickly becomes stale and the
replica becomes invalid. Secondly, because of high
update frequency, maintaining a large set of replicas
is a potential performance bottleneck.
• Security—both the prevention of account thefts and
the prevention of cheating during game play should
be considered. Distributing game states to the peers
increases the opportunities for cheating.
This paper discusses the first two problems in detail.
Our design prevents account thefts, the problem most im-
portant to the game industry, by centralizing the account
management at the server, and only distributing game states
to the peers. Although cheat-prevention is a major concern
for online games [4], it is a separate issue from the basic
performance and availability of P2P gaming. We will make
note of instances where cheat-prevention has influenced
our design, but the details and particulars are a subject of
ongoing and future work.
-
Wenn sich jeder alles ercheaten kann, warum sollte man ueberhaupt spielen? f'`8k
AutocogitoGruß, TGGC (\-/ has leading)
-
Alternativ könnte man auf das erzocken von Items etc zur Verbesserung der Charakterwerte und Profile gleich verzichten und mehr einen auf Rollenspiel machen.
Sprich man kann auf seinem Rechner schon sein Aussehen usw verwalten, aber wenn man sich da halt nen coolen Helm "erhackt", sieht man halt nur etwas besser aus(und wenn jeder damit rumrennt gibts eh was besseres) .Kann mir eh keiner sagen, dass ein Eisenhelm so viel weniger gut schützt als ein goldverzierter Polsterhelm der heiligen Stärke mit dem Juwel des reinen Herzens oder so... zumindest muss es nicht so sein und man kann genausogut halt nur ein reicher Schnösel sein, dem man halt seinen Helm mit Kopf drin wegnimmt und gut is.
-
Das Cheaten ist IMHO noch ned mal das gravierendste problem ...
Wenn man nen "dummen" server hat, hat man eigentlich immer viel Communication ueber die netzwerk schnittstelle ...
Und das im verhaeltniss zur anzahl der jeweiligen User.
Nen MMOPRG mit 100000 playern gleichzeitig auf einer Instanz /stadt sind. gibts ned. Einige arbeiten mit zonen ... einige mit so wandernden Blasen je nach position des Spielers ...Hat man nen Intelligenten Server, kriegt der client nur infos was er zu sehen hat und was nicht ... und der server kann filtern welche ereignisse von anderen playern (emotes, bewegungen etc) bei einem spieler ankommen und welche nicht.
Ist der server eher dumm, muss er immer alle daten einer "Zone" an alle player(clients) schicken ... der aufwand an netzwerk multipliziert sich also ...Wenn man nun mal schaut wie son rechenzentrum aufgebaut ist, was das fuer ne anbindung hat etc ... wird man schnell dahinter kommen wo der flaschenhals ist ... rechenleistung kann man eher relativ simpel aufbauen, einfach neue server hinstellen ... aber die Bandbreite des Rechenzentrums mal eben aufbohren iss nich. Wobei man bei bandbreite nur die die nach ausen geht sehen sollt, intern laessst sich natuerlich viel mit internen loesungen ... 5x gigabit Ethernet an einem cluster / server etc machen, wenn das zeugs eh im selben raum steht ...
Und bei nem gutgehendem MMORPG kommt man da sicher schnell an die kapazitaeten. Also die meisten "richtigen" MMORPGS optimieren mit Prio 1 auf den Netcode, dann erst auf die benoetigte rechenleistung.
Denk mal wenn man naiv rangeht und nen MMORPG proggt dazu nen dez. server in nem rechenzenter mietet mit vielleicht ner 100Mbit anbindung ans Inet iss man ohne intelligente Filterung vielleicht so bei ner niederen zweistelligen Zahl an CLients schon mal am Max, dann wirds mehr als laggy ....
Sei denn man schraubt die features runter, so das ehher nen pacman mit 100 playern rauskommt ^^ Glaub das waer scho zu realisieren ^^
Ciao ...
-
RHBaum schrieb:
pacman mit 100 playern rauskommt ^^ Glaub das waer scho zu realisieren ^^
also ich würde multiplayer-nethack spielen
-
Viiiiel interne Bandbreite schafft man z.B. ganz einfach durch Verwendung eines Blade-Servers
-
Also der Thread hier...ist echt zum totlachen! :->
Die Idee ein MMORPG über die Clients und ohne Server lösen zu wollen ist - sorry- SCHWACHSINN!!!
Nicht nur dass es technisch nicht möglicht ist sondern weil es so auch nicht funktionieren kann.1. wie soll ein Client x die IP von einem Client y wissen, wenn sich diese nirgendwo einloggen?!?!? Die Clients browsen sich bestimmt nicht von IP 1.1.1.1 bis 255.255.255.255 durch um zu sehen ob da einer gerade DIESES Spiel am laufen hat
2. FileSharing funct, weil es einen SERVER gibt an welchem du dich einloggst...sonst müsste man hier auch alle IP-Adresses des Internets nach dem Tool abfragen
3. Ohne Server gehts nicht... die Clients müssten sich zumindest an einem Server einloggen, damit er die IP an andere weiter geben kann.
Die Charakter-Daten MÜSSEN dann ebenfalls auf dem Server liegen...es macht NULL Sinn diese auf xxx Clients mit xxx unterschiedlichen Ständen abzuspeichern. Hinzu kommt ja noch die Möglichkeit der Manipulation der Daten4. Ohne dass ein Server die Daten hin und her schiebt geht es doch nicht!
Ein User mit 1 MBit DSL (128 KBit Upload) kann u.U. 5 oder 10 ander mitbedienen...das wars dann aber auch...laufen dann immer nur xx Leute durch die Gegend...mit Pings, welche in die Sekunden gehen können (je nach PC-Leistung der entsprechenden leute)...5. Server müssen nicht Schrankhoch sein!! Man kann mit einem Dual-Core AMD/Intel mit 4/8 GB RAM anfangen und später, wenn mehr Spieler da sind, dann die Welt auf mehrere Server aufteilen (4, 6, 8, 10....)
6. Ein Dual-Core Rechner mit 4 GB kostet nicht mal 1000 € mit vier 300er Platten (2 je gespiegelt!)
Standleitung und Traffic kann ich nichts zu sagen, weil ich mich damit noch nicht beschäftige7. In der Anfangsphase - die je nach Anzahl und Motivation 2 bis 5 Jahre mind. dauert - reicht auch ne normale 6 MBit DSL Leitung und ein Alter 2 Ghz PC...)
8. Wenn man für das Spiel nur 5 EUR verlangt, bekommt man fast alle der Spieler, welche sich überlegten WoW oder Ryzom oder sonst was zuzulegen, aber keine >12 EUR im Monat zahlen wollen/können
9. Weiß ich das alles, weil ich mich seit längerem mit dem Thema beschäftige und diese Woche selbst ein MMORPG mit einem kleinen Team anfange
10. Fettich
-
AlphaRay schrieb:
1. wie soll ein Client x die IP von einem Client y wissen, wenn sich diese nirgendwo einloggen?!?!? Die Clients browsen sich bestimmt nicht von IP 1.1.1.1 bis 255.255.255.255 durch um zu sehen ob da einer gerade DIESES Spiel am laufen hat
Zeroconf, bzw. dessen Wide-Area Erweiterung von Apple. Das sollte es IMHO tun.
AlphaRay schrieb:
2. FileSharing funct, weil es einen SERVER gibt an welchem du dich einloggst...sonst müsste man hier auch alle IP-Adresses des Internets nach dem Tool abfragen
bla, dasselbe wie 1.
AlphaRay schrieb:
3. Ohne Server gehts nicht... die Clients müssten sich zumindest an einem Server einloggen, damit er die IP an andere weiter geben kann.
bla, dasselbe wie 1.
AlphaRay schrieb:
Die Charakter-Daten MÜSSEN dann ebenfalls auf dem Server liegen...es macht NULL Sinn diese auf xxx Clients mit xxx unterschiedlichen Ständen abzuspeichern. Hinzu kommt ja noch die Möglichkeit der Manipulation der Daten
Das ist in der Tat ein Problem, aber das wurde auch schon als solches erkannt und diskutiert ...
AlphaRay schrieb:
4. Ohne dass ein Server die Daten hin und her schiebt geht es doch nicht!
bla, dasselbe wie 1.
AlphaRay schrieb:
Ein User mit 1 MBit DSL (128 KBit Upload) kann u.U. 5 oder 10 ander mitbedienen...das wars dann aber auch...laufen dann immer nur xx Leute durch die Gegend...mit Pings, welche in die Sekunden gehen können (je nach PC-Leistung der entsprechenden leute)...
Das ist ein weiteres Problem, das aber noch nicht wirklich angegangen wurde. Ich muss dir wohl oder übel zustimmen
AlphaRay schrieb:
5. Server müssen nicht Schrankhoch sein!! Man kann mit einem Dual-Core AMD/Intel mit 4/8 GB RAM anfangen und später, wenn mehr Spieler da sind, dann die Welt auf mehrere Server aufteilen (4, 6, 8, 10....)
Und? Es geht einfach um die technische Realisierbarkeit eines p2p-MMORPG Systems. Das es mit Servern funktioniert (egal wie groß oder bezahlbar) ist wohl hinlänglich bekannt...
AlphaRay schrieb:
6. Ein Dual-Core Rechner mit 4 GB kostet nicht mal 1000 € mit vier 300er Platten (2 je gespiegelt!)
bla, dasselbe wie 5.
AlphaRay schrieb:
7. In der Anfangsphase - die je nach Anzahl und Motivation 2 bis 5 Jahre mind. dauert - reicht auch ne normale 6 MBit DSL Leitung und ein Alter 2 Ghz PC...)
bla, dasselbe wie 5.
AlphaRay schrieb:
8. Wenn man für das Spiel nur 5 EUR verlangt, bekommt man fast alle der Spieler, welche sich überlegten WoW oder Ryzom oder sonst was zuzulegen, aber keine >12 EUR im Monat zahlen wollen/können
bla, dasselbe wie 5.
AlphaRay schrieb:
10. Fettich
bla, dasselbe wie ... ups
Ich find die Idee gut, aber das größte Problem sehe ich in den heftigen Latenzzeiten.
Allerdings sind AFAIK die Leute von id-Software bei der Implementierung einer p2p Netzwerkfunktion für Doom 3 im lokalen Netzwerk (!) gescheitert ...
