MMORPG ohne großen Server?
-
rüdiger schrieb:
... schrieb:
Und wenn die Character bei mehreren gespeichert sind und die dann zufällig net on sind, kann man dann net spielen??
Man muss halt für eine hohe Redundanz sorgen
hmm, heißt also jeder bekommt eine andere Software? Wie soll dann so ein Spiel gestartet werden, wenn der 1. Client nur einen Teil des gesamten Spiels hat? Ich denke, jeder sollte, wenn man schon so ein Spiel macht, eine Kopie der gesamten Software bekommen. Oder man richtet "Master-Clients" ein, die dann die gesamte Kopie haben und auch darüber Updates gezogen werden, wo wir dann wieder bei den Servern wären
Wenn jeder nur einen Teil des Programms bekommt, dann muss ja auch irgentwo ein Count mit der häufigkeit des Vorkommens verschiedener Pakete laufen, damit nich jeder z.B. das "Programm 1" hat. Über diesen Counter werden dann über den Downloadserver(^^) die verschiedenen Teile des Spiels verteilt.
Achja der Counter muss ja auch auf einem Server laufen (:
-
Jay schrieb:
rüdiger schrieb:
... schrieb:
Und wenn die Character bei mehreren gespeichert sind und die dann zufällig net on sind, kann man dann net spielen??
Man muss halt für eine hohe Redundanz sorgen
hmm, heißt also jeder bekommt eine andere Software? Wie soll dann so ein Spiel gestartet werden, wenn der 1. Client nur einen Teil des gesamten Spiels hat? Ich denke, jeder sollte, wenn man schon so ein Spiel macht, eine Kopie der gesamten Software bekommen. Oder man richtet "Master-Clients" ein, die dann die gesamte Kopie haben und auch darüber Updates gezogen werden, wo wir dann wieder bei den Servern wären
Wenn jeder nur einen Teil des Programms bekommt, dann muss ja auch irgentwo ein Count mit der häufigkeit des Vorkommens verschiedener Pakete laufen, damit nich jeder z.B. das "Programm 1" hat. Über diesen Counter werden dann über den Downloadserver(^^) die verschiedenen Teile des Spiels verteilt.
Achja der Counter muss ja auch auf einem Server laufen (:Geht ja um die Daten einzelner MMORPG-Mitglieder, also nicht um konkrete Spiele-Daten.
Aber vermutlich wäre es besser die Daten über Kryptographie abzusichern, als über die Verteilung.
-
@Jay
naja, "ohne server" heißt ja vermutlich, dass das spiel komplett auf den clients berechnet wird. die notwendigkeit eines zentralen ip-verteilers/verwalters haben wir vorhin schon festgestellt, und um den kommt man auch nicht umhin, wenn man z.b. eine einheitliche mmorpg-welt haben will. es ist aber in dem sinne kein server, da das spiel an sich nicht drauf läuft.
und es wäre wohl sinnvoller, jedem client dieselbe software zu geben. durch eine ausgeklügelte verwaltungstechnik sollte es nun möglich sein (oder auch nicht...) dass sich die clients untereinander einigen, wer für welchen (geographischen) bereich zuständig ist: wenn sich dort mehrere spieler aufhalten, dann verwaltet der entsprechende die kommunikation/synchronität etc. wenn sich viele spieler anhäufen, müsste man natürlich irgendwie lastaufteilung machen, was sicher nicht so einfach ist.
man könnte natürlich auch ein komplett dezentrales netz machen, wo jeder client auch ein server ist, seine eigenen (zufällig generierten oder benutzererstellten) levels anbietet, die aber mit anderen levels anderer benutzer verbunden sind. das bringt natürlich ziemliche probleme mit sich (was passiert z.b., wenn einer den netzstecker zieht? gibt's dann das level nicht mehr? -> unpraktisch. sicherheitsrisiken wären dann auch noch.)
-
... schrieb:
Und wenn die Character bei mehreren gespeichert sind und die dann zufällig net on sind, kann man dann net spielen??
Ich würde den Character bei dem entsprechendem Client und bei ein paar anderen die per Zufall bestimmt werden speichern. Ist also immer wenigstens eine Version vorhanden und fals eine weitere Vorhanden ist kann man ja vergleichen um Cheater zu finden. Ist nicht sicher, dass immer jeder gefunden wird, doch die Wahrscheinlichkeit sollte hoch sein.
Ich würd die Computer in einem Ring verbinden. Dann müsst der Client der dem Ring beitreten will nur eine Hash vom Character rund zu schicken. Jeder Client im Ring stimmt dann entweder für den Beitritt, dagen oder enthält sich. Fals es mehr dafür oder gleich viele wie dagenen dann darf der Client der Rund beitreten.
Somit würde man auch dem Problem aus dem Weg gehen, dass ein Client einen anderen blockiert dadurch, dass er absichtlich fälschlich einen Character als falsch erkennt.
Periodisch und beim Logout würde dann der neue Hash rund geschickt. Die anderen Clients löschen den alten Hash und bestimmen per Zufall ob der neue gepeichert wird oder nicht.
Gegen Absturz sind solche Ringe jedoch nicht stabil. Vielleicht bei jedem Client die Ips der paar nächsten Clients speichern.
Viel mehr als Pokermultiplayer kann ich mir auf diese Weise aber aus Bandwidthgründen nicht vorstellen. Nicht rundenbasiert wird meiner Meinung nach nicht gehen. Ein sehr einfaches RPG wäre vielleicht auch noch drin.
-
Damit dieses Zufallsprinzip aufgeht benötigt man doch von Anfang an eine große Anzahl an Spielern, oder Spieler die immer eingeloggt sind, sonst könnte es ja passieren, dass man sich einloggen will und keiner den Spieler kennt, da alle die den Spieler kennen offline sind.
Würde die Spielerdaten Zentral verwalten, da ein zentraler Ansprechpunkt sowieso da sein muss und die Last dafür wäre auch nichts im Vergleich zu einem richtigen Server in einem c/s System.Halte das ganze aber trotzdem für unrealistisch mit der derzeitigen Bandbreite.
-
@Larko:
Wieso stellst du die Frage eigentlich - bloss interesse, oder willst du sowas programmieren, und hast keinen geeigneten Server dafür? IMHO ist ein zentraler Server die einzig brauchbare Möglichkeit. Was der dann alles übernimmt ist eine andere Sache. Also ob der z.B. auch die ganze Auswertung übernimmt, also berechnet wer wieviel Damage nimmt etc. - das muss z.B. nicht sein.Es hat auf jeden Fall viele Vorteile wenn es einen Rechner gibt der im Prinzip "alles weiss", also weiss welche Spieler sich z.B. so nahe sind dass sie ich sehen müssen etc.
Ich kann und will nicht behaupten beweisen zu können dass es ohne Server nicht geht, aber ich stelle es mir verflixt kompliziert vor. Vor allem dass dann auch noch alles deterministisch und mit halbwegs annehmbaren Latenzzeiten über die Bühne geht.
----
Wenn du sowas selbst programmieren willst, und keinen Server hast der mehr als 10 oder 20 Spieler verdauen kann, würde ich trotzdem vorschlagen fang einfach an, und zwar MIT Server, denn so schnell wirst du nicht in die Verlegenheit kommen mehr als ein paar Spieler supporten zu müssen. Und mit ein wenig Geschick lässt sich normalerweise irgendwo was anmieten, das Geld kannst du ja ggf. über die Spieler organisieren.
-
Jay schrieb:
Ein Server muss aufjedenfall her, woher sollen die Clients den wissen, wo sich die anderen Clients befinden?
muss nicht sein. Napster verwendete auch keine Server, und funktionierte trotzdem (und man konnte trotzdem mit anderen Clients Daten austauschen)
Außerdem schluckt sowas bei großen Games dann unnötig viele Ressourcen. Ein Freund hatte mal einen Ragnarock-Server(oda wie des heißt) laufen, der hat dann >1,5 GB Ram geschluckt. Bei nur einem Client müsste das doch dann theoretisch alles beim Client laufen, da würden ne menge nicht mitspielen können.
Na ja.... wenn 1 Server 100 oder mehr Leute bedient, muss der schon was leisten. Wenn du allerdings auf jedem Client was machst, dann muss jeder einzelne Client viel weniger tun, und braucht damit wesentlich weniger Power. Im Prinzip wuerds ja ausreichen, wenn jeder Client 1 anderen bedient. Dann hat jeder Client einen anderen, der ihn bediehnt.
Man kann auch soweit gehen, dass jeder Client 2 andere Leute bediehnt. Das sollte die Rechner auch nicht in die Knie zwingen, die Bandbreite sollte auch noch kein Thema sein und man hat Redundanzen (jeder wird von 2 Clients bedient). Wie so ein Protokoll konkret ausschauen soll, darueber kann sich wer anderes gedanken machen
-
Beim Filesharing hast du den Riesenvorteil zeitlich ziemlich ungebunden zu sein.
Klar will man möglichst schnell fertig werden, aber wenn es ne Stunde mehr dauert isses auch fast egal.
Bei einem Spiel oder etwa einer Webseite ist dies nicht der Fall, deswegen setzt sich freenet usw (für legale Inhalte )auch nicht so richtig durch.Wobei dem, der ein ein p2p mmorpg erschafft, sicher einiges an Ruhm und Geld gewiss ist.
Das man es gegen Cheater absichern kann zeigt ja auch etwa freenet wieder, aber man muss einfach sagen, die Internetverbindungen sind schon für das normale Browsen zu langsam(juhu, ich bin nach 5 Minuten fertig udn kann die Webseite ansehen), für mmorpgs wird es noch viel viel krasser, also wird das wohl noch ein paar Jahre dauern.Und für jeden der es hinbekommt ein mmorpg zu erschaffen ist ein Server das geringste Problem, besonders bei heutigen Serverpreisen.
Was halt geht ist das Spiel über Instanzen etc laufen zu lassen, also fünf Spieler treffen sich in einer Stadt die auf einem zentralen Server liegt und ziehen dann los um in einem Level zu kämpfen, wo ausser ihnen niemand ist.
Inventar usw dann noch über Server verwalten, Rest übernehmen die Clients.
So reicht dann ein Bruchteil der Serverleistung und die Spieler sind immer noch an dich gebunden und müssen zahlen.
-
folgender fall:
jemand cheatet sich auf seinem rechner einen char zusammen und "überzeugt" seinen client, dass dieser char legal wäre. dabei hält er sich an gültige regeln. er simuliert also beispielsweise ein spieldauer von 30 tagen und setzt den charakter auf einen bestimmten level.
jetzt verbindet er sich mit anderen rechnern und diese bekommen die info über den charakter verwendet. sie kennen ihn nicht und wollen deshalb überprüfen, ob es sich um einen legalen char handelt. logischerweise wird kein anderer "server" diesen charakter kennen, ausser dem server des cheaters.
wie soll mit so einem charakter nun verfahren werden? mir fällt keine methode ein, wie ohne dedizierte server, die immer verfügbar sind, eine solche überprüfung sicher gemacht werden könnte.
-
Die Frage war ja "ohne großen Server"
Ein par Daten wie eben die Charaktere können dann ja abgespeichert werden. Das Spiel soll halt einfach auf den Clients und nicht auf dem Server selbst laufen.
-
Mal was anderes. Ich spiele ganz normal ohne cheaten. Mein Charakter ist auf meinem und weiteren 4 Rechnern drauf. Zur Zeit sind aber nur 2 der weiteren Rechner Online. Jetzt zocke ich, mein Charakter verbessert sich bekommt neue Gegenstände, was weiß ich. Am nächsten Tag gehe ich wieder online und will spielen. Diesmal sind aber die beiden anderen Rechner online, die wärend meiner letzten Onlinerunde offline waren. Was passiert?
-
Helium schrieb:
Mal was anderes. Ich spiele ganz normal ohne cheaten. Mein Charakter ist auf meinem und weiteren 4 Rechnern drauf. Zur Zeit sind aber nur 2 der weiteren Rechner Online. Jetzt zocke ich, mein Charakter verbessert sich bekommt neue Gegenstände, was weiß ich. Am nächsten Tag gehe ich wieder online und will spielen. Diesmal sind aber die beiden anderen Rechner online, die wärend meiner letzten Onlinerunde offline waren. Was passiert?
Alle Clients müssen ihre Chars untereinander Synchronisieren. Müsste sowieso passieren, damit z.B. die gleiche Quest nicht 2x erfüllt wird. D.h. sobald ein neuer Client connected, erhält er ein Update mit allen Informationen. Solange die Userbase nicht riesig ist, sollte so ein Update im 1 - 10 MByte Bereich liegen, was noch akzeptabel ist. Sonst müsste man halt ein "Supernode"-Konzept einführen oder so.
Damit ist auch thordk's Problem gelöst.
-
Helium schrieb:
Mal was anderes. Ich spiele ganz normal ohne cheaten. Mein Charakter ist auf meinem und weiteren 4 Rechnern drauf. Zur Zeit sind aber nur 2 der weiteren Rechner Online. Jetzt zocke ich, mein Charakter verbessert sich bekommt neue Gegenstände, was weiß ich. Am nächsten Tag gehe ich wieder online und will spielen. Diesmal sind aber die beiden anderen Rechner online, die wärend meiner letzten Onlinerunde offline waren. Was passiert?
Deswegen würde ich ja Kryptographie vorschlagen. Dann muss man den Charakter auch nicht mehr verteilen. Die Clients signieren einfach den Hash der Daten des Charakter. Wenn man dann noch eine Art Web-Of-Trust implementiert, kann man sogar verhindern, das ein Cheater mehrere Clients laufen lässt, die sich gegenseitig die Charaktere validieren.
Aber eines sollte klar sein: So ein Netzwerk-Protokoll lässt sich nicht mal eben entwerfen und zumindest Grundlagenwissen über kryptographische Protokolle sollte vorhanden sein.
-
rüdiger schrieb:
Deswegen würde ich ja Kryptographie vorschlagen. Dann muss man den Charakter auch nicht mehr verteilen. Die Clients signieren einfach den Hash der Daten des Charakter.
Aber wenn die Clients ihre eigenen Charakterdaten signieren, dann muss dem Client ja der private Schlüssel bekannt sein. Dann können die anderen Charaktere mit dem öffentlichen Schlüssel die Daten auf Echtheit überprüfen. Nur wie soll das vor Cheaten schützen? Das bedeutet doch, der private Schlüssel ist im lokalen Programmcode enthalten und somit potentiell für den Cheater sichtbar.
Oder habe ich Dich falsch verstanden?
-
Blue-Tiger schrieb:
Helium schrieb:
Mal was anderes. Ich spiele ganz normal ohne cheaten. Mein Charakter ist auf meinem und weiteren 4 Rechnern drauf. Zur Zeit sind aber nur 2 der weiteren Rechner Online. Jetzt zocke ich, mein Charakter verbessert sich bekommt neue Gegenstände, was weiß ich. Am nächsten Tag gehe ich wieder online und will spielen. Diesmal sind aber die beiden anderen Rechner online, die wärend meiner letzten Onlinerunde offline waren. Was passiert?
Alle Clients müssen ihre Chars untereinander Synchronisieren. Müsste sowieso passieren, damit z.B. die gleiche Quest nicht 2x erfüllt wird. D.h. sobald ein neuer Client connected, erhält er ein Update mit allen Informationen. Solange die Userbase nicht riesig ist, sollte so ein Update im 1 - 10 MByte Bereich liegen, was noch akzeptabel ist. Sonst müsste man halt ein "Supernode"-Konzept einführen oder so.
Damit ist auch thordk's Problem gelöst.
weisst du wie riesig charakter files bei nem durchschnittlich umfangreichen mmorpg werden? wenns sehr viele features bietet, werden die sogar gewaltig groß. das war z.b. der grund, warum swg ursprünglich nur einen spielercharakter pro server zugelassen hat.
für ein update untereinander müssen ja nicht bloß die simplen userfiles übertragen werden (aussehen, items, stats etc.), es müssen die gesamten charakterprofile ausgetauscht werden.
halten wir es mal im rahmen und sagen, dass pro charakter maximal 100 kb verbraten werden dürfen, wobei dies jegliche info über diesen beinhalten muss. dann bist du bei 1000 spielern schon bei 100MB an nutzerdaten.
-
nochmal anmerkungen dazu. ich will nicht sagen, dass es nicht auch ohne "großen" server lösbar ist, ich sehe aber einige probleme, die stolpersteine bilden.
- charakterfiles werden u.U. sehr groß. ein kompletter abgleich zu definierten zeitpunkten erscheint dadurch inpraktikabel. alternative wäre, auf kryptographie zu vertrauen und charakterfiles nur lokal zu speichern. dadurch ist ein client aber nicht gegen manipulationen im laufenden betrieb geschützt. hier müssten also methoden gefunden werden, die manipulationen auch als solche erkennen können. mitunter nicht ganz einfach. wie unterscheidet ein client einen "simulierten" mob kill inklusive xp und loot von einem regulären?
- latenz und regelkonformität: jedwege aktion muss abgesegnet werden. es wäre ein wenig "unfair", wenn irgendein spieler plötzlich stärker als alle anderen ist, weil sein feuerball INT_MAX schaden anrichtet. geringster ansatz wäre, dass lediglich ein zufällig ausgewählter server/spielerrechner eine gegenkontrolle durchführt. allerdings sind p2p verbindungen u.U. sehr latenzbelastet. dies vervielfacht sich, wenn mehrere server aus gründen der sicherheit abgefragt werden müssen.
- game update convenience. wie sollen updates eingespielt werden? wie in p2p börsen? aber wer macht den anfang? wahrscheinlich nicht unüberwindbar, aber nicht trivial lösbar. denn woher weiss der nächste server, der auch noch "alt" ist, dass es eigentlich schon ne neue version gibt?
- kleiner nebeneffekt: datensicherheit und portabilität. mmorpgs leben auch davon, dass man von jedem platz aus seinen charakter spielen kann. sollte dieser aber nur auf dem heimischen rechner gespeichert sein, wie soll man dann an ihn rankommen? bei der alternative der verteilten charakterspeicherung könnte es passieren, dass zufällig niemand online ist, der deinen charakter liefern könnte. und der super-gau, der in akribischer kleinstarbeit hochgezüchte uberchar verschwindet im wink eines augenblicks, als die festplatte ihren geist aushaucht.
-
thordk schrieb:
weisst du wie riesig charakter files bei nem durchschnittlich umfangreichen mmorpg werden? wenns sehr viele features bietet, werden die sogar gewaltig groß. das war z.b. der grund, warum swg ursprünglich nur einen spielercharakter pro server zugelassen hat.
für ein update untereinander müssen ja nicht bloß die simplen userfiles übertragen werden (aussehen, items, stats etc.), es müssen die gesamten charakterprofile ausgetauscht werden.
halten wir es mal im rahmen und sagen, dass pro charakter maximal 100 kb verbraten werden dürfen, wobei dies jegliche info über diesen beinhalten muss. dann bist du bei 1000 spielern schon bei 100MB an nutzerdaten.Hmm.... das kommt auf's Design des Spieles drauf an. Ich denk durchaus dass man einen Charakter auf auch auf 10 kb oder weniger bringen koennte. Verlangt dann halt zum einen, dass die Programmierer wirklich kein einziges Bit verschwenden, und dass beim Design Abstrichte gemacht werden muessen (keine selbst definierbaren Skins oder gott bewahre sogar Texte, keine total ausgefallenen Eigenschaften, ...). Man muss das eben von vorn herein mit einplanen. Dass ein "Professionelles" Spiel sowas macht halt ich eh fuer unwahrscheinlich, aber da es hier - vermut ich mal - eh um ein Hobbyprojekt geht, ist das ganze wohl noch tragbar. Man muesste dann logisch auch noch andere Tricks verwenden, z. B. inaktive Chars nach einer Weile loeschen, ...
Aber stimmt schon, riesige Spielermassen wird man durch so ein Verfahren kaum verwalten koennen. Was mir dabei eben noch einfaellt waere
* Die einzelnen Clients haben nicht die Daten aller Chars, sondern nur die von ein paar. Von allen Chars wissen sie aber, welche(r) Client(s) diese Daten haben, und sie koennen sie bei Bedarf nachladen. Es muss nur sichergestellt werden, dass es ausreichend Kopien der Chars im Netz sind. Und jeder Client muss, bevor er offline geht, all seine Chars an andere Clients uebertragen. Wenn allerdings dann im Extremfall nur mehr 1 Client online ist, muss dieser wirklich die Daten aller Chars besitzen.
Wenn von jedem Char zu jeder Zeit (ausgenommen Extremfaelle, wenn nur mehr 1 Client online ist) 5 Kopien im Netz sind, muesste ein Cheater alle 5 Kopien (auf allen 5 Clients) austauschen, um seinem Char neue Werte zu geben.
* Das Einfuehren von "Supernodes", aehnlich wie's z. B. in Napster war: Clients, die mehr Verwaltungsaufgaben uebernehmen. Dafuer muesste man sich dann halt auch wieder Sicherheitskonzepte ueberlegen (wie kann ich garantieren dass Supernodes vertrauenswuerdig sind, ...)Hmm... tjo... Ich halts nach wie vor fuer moeglich, aber ich glaub, Serverbetrieb waer echt einfacher
-
byto schrieb:
rüdiger schrieb:
Deswegen würde ich ja Kryptographie vorschlagen. Dann muss man den Charakter auch nicht mehr verteilen. Die Clients signieren einfach den Hash der Daten des Charakter.
Aber wenn die Clients ihre eigenen Charakterdaten signieren, dann muss dem Client ja der private Schlüssel bekannt sein. Dann können die anderen Charaktere mit dem öffentlichen Schlüssel die Daten auf Echtheit überprüfen. Nur wie soll das vor Cheaten schützen? Das bedeutet doch, der private Schlüssel ist im lokalen Programmcode enthalten und somit potentiell für den Cheater sichtbar.
Oder habe ich Dich falsch verstanden?
Nein, das hast du falsch verstanden.
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.
Wenn man dann ein Web-of-Trust hat, also das Leute anderen Spielern ein vertrauen aussprechen können (oder dies teilautomatisch über die Spielzeit läuft), dann kann man nicht eben mit 10 Clients Online gehen und sich selbst zertifizieren.
thordk schrieb:
- charakterfiles werden u.U. sehr groß. ein kompletter abgleich zu definierten zeitpunkten erscheint dadurch inpraktikabel. alternative wäre, auf kryptographie zu vertrauen und charakterfiles nur lokal zu speichern. dadurch ist ein client aber nicht gegen manipulationen im laufenden betrieb geschützt. hier müssten also methoden gefunden werden, die manipulationen auch als solche erkennen können. mitunter nicht ganz einfach. wie unterscheidet ein client einen "simulierten" mob kill inklusive xp und loot von einem regulären?
Die Charakterdaten sollten ja eh verteilt werden. Ich sehe jetzt nicht unbedingt, warum Charakterfiles sonderlich groß werden. Sicher, wenn man eigene 3D-Modelle oder Grafiken erlauben will, aber das kann man ja auch lokal beim Client belassen.
- latenz und regelkonformität: jedwege aktion muss abgesegnet werden. es wäre ein wenig "unfair", wenn irgendein spieler plötzlich stärker als alle anderen ist, weil sein feuerball INT_MAX schaden anrichtet. geringster ansatz wäre, dass lediglich ein zufällig ausgewählter server/spielerrechner eine gegenkontrolle durchführt. allerdings sind p2p verbindungen u.U. sehr latenzbelastet. dies vervielfacht sich, wenn mehrere server aus gründen der sicherheit abgefragt werden müssen.
Man verteilt einfach das rechnen. Die Aktionen werden eben gegenseitig bewertet und dann nach dem Mehrheits-/Geschwindigkeitsprinzip abgesegnet. Wobei es da natürlich auch reicht, wenn jeder Client im Grunde Berechnungen für zwei/drei andere Charaktere durchführt. Sonst wird das vermutlich zu viel.
- game update convenience. wie sollen updates eingespielt werden? wie in p2p börsen? aber wer macht den anfang? wahrscheinlich nicht unüberwindbar, aber nicht trivial lösbar. denn woher weiss der nächste server, der auch noch "alt" ist, dass es eigentlich schon ne neue version gibt?
Das halte ich für das geringste Problem
- kleiner nebeneffekt: datensicherheit und portabilität. mmorpgs leben auch davon, dass man von jedem platz aus seinen charakter spielen kann. sollte dieser aber nur auf dem heimischen rechner gespeichert sein, wie soll man dann an ihn rankommen? bei der alternative der verteilten charakterspeicherung könnte es passieren, dass zufällig niemand online ist, der deinen charakter liefern könnte. und der super-gau, der in akribischer kleinstarbeit hochgezüchte uberchar verschwindet im wink eines augenblicks, als die festplatte ihren geist aushaucht.
man kann den Charakter ja noch zusätzlich verteilen. Bietet natürlich keine 100% Sicherheit, aber man sollte seine Daten eben noch selbst sichern
-
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.
