MMORPG ohne großen Server?
-
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.
-
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.
