Python

[Panossa]

Hab leider keine Ahnung, was mit dem Phytonkram alles möglich ist. Habe noch nie jemanden gesehen, der das wirklich benutzt. Java ist da schon performanter bei (eh schon Java-)Servern.

 

[Aeogen]

Python macht durchaus Sinn. Wir entwickeln z.B. für unseren RPG in Java eine Quest-API, sowie Tools für einfache Dinge (z.B. reine Dialoge), die am Ende Python ausgeben. Wenn du (stages mit eingerechnet) hunderte Quests mit wenigen Entwicklern machst, ist Java nämlich keine Lösung. Es wäre zu schwer, ein ganzes Team einzuarbeiten, was in Python nur wenige Tage/Tutorials beansprucht. Zudem ist es riskant wegen der Möglichkeiten und wenn du einen hast, der nicht nicht so recht weiß was er tut, ist das Ergebnis im Normalfall sogar weniger performant.

Ähnlich Sinn macht in diesen Zusammenhang Denizen, wo man auch ständig auf Leute trifft, die sagen "Ich habe mich zwar nie damit befasst, aber das ist halt weniger peformant... ".
Da gibt es aber Leute, die (ohne zu übertreiben) hunderte NPCs und ganze Adventuremaps bei guter Performance auf Billigservern die Beine gestellt haben.
Es gibt umgekehrt ja auch genug Server, die auf eigene Javaplugins setzen und am Ende bei 30 Spielern zu laggen beginnen..

 

[Panossa]

Python macht durchaus Sinn. Wir entwickeln z.B. für unseren RPG in Java eine Quest-API, sowie Tools für einfache Dinge (z.B. reine Dialoge), die am Ende Python ausgeben.

Ich weiß echt nicht, ob Python die beste Wahl an dieser Stelle ist, aber es ist auf jeden Fall einfacher zu erlernen als Java, das stimmt schon. Spontan würde ich aber denke ich eher zu JavaScript greifen (da es dafür schon sowieso sowas wie APIs gibt...WorldEdit nutzt sowas ja auch). Oder Lua. Lua wäre wahrscheinlich sogar das Einfachste. Man muss nur aufpassen, in welcher Reihenfolge man Attribute oder Methoden initialisiert.

 

[Panossa]

Lua ist nicht mächtig genug und JavaScript viel zu gefährlich, um es Laien in die Hand zu legen (und die Datentypen sind sehr begrenzt).

Lua kann man mächtig genug machen. Und kannst du Beispiele dafür nennen, wieso JS gefährlicher sein soll als Python? Und inwiefern man durch "begrenzte" Datentypen "begrenzt" ist? Im Internet findet man dazu nur unter Anderem:
- Python standard lib hat vieles an board, bei JS muss man vieles erst importieren. (einerseits nerviger mit JS, andererseits sicherer bei JS, da man nicht so schnell unpassende Sachen verwendet)
- JS kann einfach mit JSON und Unicode umgehen
- JS ist bei Hardwarenähe schlanker (Notiz unseres JS Devs: konnte ich zwar nicht feststellen, aber es sind beide schlanker als Java)
- Module sind bei Python einfacher zu installieren

Also ich denke, es ist am Ende des Tages einfach eine Sache der Präferenz.

 

[Aeogen]

Meine Zeit als (JavaScript)Programmierer liegt inzwischen über 10 Jahre zurück, deshalb kann ich schwerlich präzise antworten. Das Hauptproblem war/ist eigentlich die fehlende Typsicherheit mit all ihren Folgen.
Mit Datentypen sind Typen wie integer, float und co gemeint. Hier ist zumindest das normale JavaScript schwer zu optimieren. Ich glaube es gibt hier was Zahlen angeht nur floats.
Und da ich dem nichts hinzufügen kann, sind wir uns am Ende des Tages wahrscheinlich trotzdem einig, dass Python für dieses allgemeine Szenario keine schlechte Wahl ist. Lg

 

[IvenThuer]

Ich finde auch das Python eine gute Wahl ist Minecaft Plugins zu programmieren, es ist:
-einfach zu programmieren
-nicht schwer zu verstehen.
Aber eine Sache stört mich an dem pogrammieren mit Python, man kann seine Plugins nicht mit denen von JavaScript verbinden z.B. ein Coin plugin (JavaScript) mit dem eine Kiste öffnen kann(Python). Das würde nur gehen wenn man javaScript versteht!!!

 

[Panossa]

-einfach zu programmieren
-nicht schwer zu verstehen.

Aber eine Sache stört mich an dem pogrammieren mit Python, man kann seine Plugins nicht mit denen von JavaScript verbinden z.B. ein Coin plugin (JavaScript) mit dem eine Kiste öffnen kann(Python). Das würde nur gehen wenn man javaScript versteht!!!

1. Sind die beiden Punkte nicht fast das Gleiche?
2. Ich glaube, um A und B zu verbinden, muss man normalerweise A und B verstehen, das ist schon richtig ^^'
Deswegen programmiere ich richtige Plugins. Da hat man viel Auswahl an Plugins, mit denen man sich "verbinden" kann und es geht meist sehr einfach.
(Okay, ich programmiere nicht nur deswegen in Java)

 

[Nitroskin_Network]

Ich finde auch das Python eine gute Wahl ist Minecaft Plugins zu programmieren, es ist:
-einfach zu programmieren
-nicht schwer zu verstehen.
Aber eine Sache stört mich an dem pogrammieren mit Python, man kann seine Plugins nicht mit denen von JavaScript verbinden z.B. ein Coin plugin (JavaScript) mit dem eine Kiste öffnen kann(Python). Das würde nur gehen wenn man javaScript versteht!!!

Och man du meinst wenn nur Java und ausserdem kann man in Python alles Möglich machen, dass in Java Plugins schon gibt!
Das ist mein neuer Acc(Begründung Sperrung), alles per PN an mich

 

[Panossa]

und ausserdem kann man in Python alles Möglich machen, dass in Java Plugins schon gibt!

Das ist mein neuer Acc(Begründung Sperrung), alles per PN an mich

Ich glaube nicht, dass die Python Lib von z.b. Denizen irgendwas beinhaltet, mit dem man Packets direkt manipulieren kann.

Und heißt das, du wurdest hier gesperrt und hast einen neuen Account gemacht? Ist das nicht irgendwie gegen die Regeln dieses Forums?

 

[Nitroskin_Network]

Ich glaube nicht, dass die Python Lib von z.b. Denizen irgendwas beinhaltet, mit dem man Packets direkt manipulieren kann.

Und heißt das, du wurdest hier gesperrt und hast einen neuen Account gemacht? Ist das nicht irgendwie gegen die Regeln dieses Forums?

Nein, das ist der Acc für unseren Server

 

[Chrisliebär❤️]

Python wird beispielsweise im wissenschaftlichen Bereich für Datenanalyse, Statistik aber auch für Neuronale Netzwerk gerne verwendet. Java bringt einfach ein riesen Monster an Tools mit und muss immer neu kompiliert werden. Außerdem gibt es leider sehr viele Menschen, die keine Lust auf starke Typisierung haben und Javascript ist einfach voller merkwürdiger Verhaltensweisen. Außerdem ist es soweit ich weiß noch immer fast unmöglich Javascript einfach mal so in eine andere Anwendung einzubetten, wenn diese nicht eh schon mit node.js läuft, was für so gut wie keine Software zutrifft.

Lua ist dabei eigentlich wo ganz anders anzusiedeln. Lua bietet sich für eingebettete Skriptsysteme an. So ein Lua Interpreter hat einen sehr geringen Speicherverbrauch und durch die sehr kleine Standardlibrary kann man so eine Lua Umgebung perfekt auf die Anwendung anpassen, in der sie läuft. Zusätzlich lässt sich die Sprache sehr gut Sandboxen und von außen kontrollieren. Das ist mit Python z.B. fast unmöglich. Dafür sind Libraries in aller Regel inkompatibel, wesshalb das einfach immer eine Insellösung für eine spezielle Software ist. Große Verbreitung hat Lua vor allem in Game Engines oder anderen Systemen, die sehr kurz gehaltene Logik haben, wie Chatbots, etc.

Für Minecraft selbst ist Python halt nicht geeignet, weil die großen Server nunmal eine Java API haben, aber für das Toolset um den Server herrum bietet es sich durchaus an, sofern man Entwickler hat, die es können.

 

[Panossa]

Lua ist dabei eigentlich wo ganz anders anzusiedeln. [...] Dafür sind Libraries in aller Regel inkompatibel, wesshalb das einfach immer eine Insellösung für eine spezielle Software ist.

Kannst du das vielleicht näher erläutern? Bzw was würdest du, wenn man NICHT Java für sowas wie Quests nehmen will, dafür empfehlen? Vllt irgendwas, was nicht JS, Python oder Lua ist? Bzw wie wäre das Ranking zwischen den dreien für die Funktion als Questskripte? Wie einfach kann man damit etwas Interessantes und brauchbares erschaffen bzw wie sicher ist es und wie performant?

 

[Chrisliebär❤️]

Kannst du das vielleicht näher erläutern? Bzw was würdest du, wenn man NICHT Java für sowas wie Quests nehmen will, dafür empfehlen? Vllt irgendwas, was nicht JS, Python oder Lua ist? Bzw wie wäre das Ranking zwischen den dreien für die Funktion als Questskripte? Wie einfach kann man damit etwas Interessantes und brauchbares erschaffen bzw wie sicher ist es und wie performant?

Ich weiß nicht genau was dein Ziel ist, dein Einstiegspost gibt wenig her und unterwegs ist auch schon ein Beitrag verschwunden. Wenn du ein komplettes Questsystem haben willst, wie du das z.B. in World of Warcraft hast, dann ist Lua die Sprache der Wahl. Javascript und Python fallen da komplett raus, da sie dir keine Vorteile gegenüber Lua bieten und die Einbindung deutlich komplizierter ist und du auch sehr schwer dafür sorgen kannst, dass deine Questskripte keine Dummheiten anstellen, weil sie theoretisch Zugriff auf die gesamte Java Anwendung haben.

Ich weiß nicht ob das eine theoretische Frage ist, oder ob du wirklich ein Questsystem umsetzen willst. Das ist auf jeden Fall etwas, das SEHR viel Planung benötigt. Idealerweise sollte jede Quest abgekapselt sein. Du suchst vermutlich ein System, mit dem du in Lua einzelne Quests definierst. Dabei bekommt jede aktive Instanz ein Zustandsobjekt und Logik, mit der der Zustand verändert wird, wenn der Spieler bestimmte Ziele erreicht. Ich hab so etwas aber auch selbst noch nicht gemacht. Wenn ich das implementieren müsste, würde ich mich an World of Warcraft oder Ragnarok Online orientieren.

Für beide Spiele gibt es nachgebaute Server (oft Emulator genannt). Im Falle von WoW fallen mir mehrere ein, unter anderem MANGOS, wobei der normalerweise über C++ geskripted wird (scriptdev2). Andere Server benutzen aber auch Lua Skripte. Die offiziellen Server laufen sogar zu 100% mit Lua. Wenn du ein komplettes System haben willst musst du dir den C++ Code des Servers ansehen, der die Questlogik direkt entält, hier bekommst du vermutlich den besten Einblick in ein gescheites Questsystem, aber das dürfte auch am meisten Arbeit machen, deren System nachzuvollziehen. League of Legends benutzt ebenfalls Lua, wobei die Skripte hier als Anregung total nutzlos sind. Bei Ragnarok Online ist die Sache sogar noch interessanter, da hier der nachgebaute Server besser ist als das Original. Ich glaub zuletzt hieß das Projekt rAthena aber auch hier hilft dir Google. Das Questsystem von Ragnarok ist vergleichsweise billig und sie benutzen eine eigene Skriptsprache, aber das sollte kein Hinderniss sein. Das besondere ist hierbei aber, dass die Skriptsprache 1:1 dem der offiziellen Server entspricht, da leaken wohl regelmäßig die Serverdateien. In jedem Fall hast du halt nur Zugriff auf die Skripte, das heißt du musst dir ansehen, wie die Skripte funktionieren und damit auf das dahinterliegende System schließen. Im Endeffekt definierst du dir auch für bestimmte Questtypen feste Muster, die du einfach nur noch füllen musst, aber für komplexere Quests brauchst du trotzdem ein gescheites System.

Weiter Ideen habe ich jetzt erstmal nicht. Normalerweise arbeitet das Questsystem mit der selben API, mit der auch normale Spieldaten geskriptet werden, das fällt in Minecraft aber erstmal raus. Das ist von der eigentlichen Sprache allerdings komplett unabhängig, Lua bietet sich nur für solche Aufgaben an. Was du vielleicht auch noch machen kannst ist dir die Skriptsprache von Warcraft 3 ansehen (nicht den Baukasteneditor) um eine weitere Idee zu bekommen, wie man die Logik für die Events aufbaut.

Du kannst dein Questsystem natürlich auch mit Java schreiben, dann musst du es für jede Quest halt neu kompilieren, dass will man in aller Regel definitiv vermeiden. Vor allem weil es auch dazu verleitet blödes Zeugs zu machen und die Quests nicht richtig zu entkoppeln. So sollte es beispielsweise möglich sein ein Quest über ein Admininterface zurückzusetzen oder auch zu debuggen, falls es ein Fehler im Skript gibt.

Mit einem guten Questsystem kann auch ein Anfänger eigene Quests schreiben ohne dabei etwas kaputt zu machen, mit Java geht das nicht. Versteh auch nicht wirklich dein Problem mit Lua. Dass die Sprache Listen ab 1 zu zählen beginnt ist eigentlich das einzige, was einen wirklich sehr lange Zeit fertig macht. Alles andere ist vom Paradigma wie Javascript oder Python. Lua ist der Industriestandard für diese Aufgaben.

 

[Aeogen]

Mit Java 9 entfällt tatsächlich das Problem des neu Kompilierens größtenteils. Man könnte Quests auch als Module nachladen, bzw. austauschen. Problem ist dann halt, dass jeder der Quests umsetzen möchte, java beherrschen muss.

Für Minecraft gibt es eigentlich schon viele machtige Systeme. Das Mächtigste ist wohl das benannte Denizen, dass sich zusammen mit Anthonys QuestAPI, Sentries und co. sogar wie ein QuestPlugin anfühlt, also kaum Vorwissen braucht, obwohl es deutlich mehr Möglichkeiten gibt (nahezu alle). Wenn man allerdings an die Denizenskripte selbst ran geht, hat man hier Mittel und Werkzeuge, um den Server bzw. seine Daten irreparabel abzuschießen. Anders gesagt: Jeder, der die Skripte schreiben darf, hat volle Adminrechte auf Serverprozesse und -funktionen. Beispielsweise kann der Speicher manipuliert werden.

Wenn du selbst jede Quest umsetzen willst und sie einen hohen Individualitätsgrad besitzen, ist Java eine gute Wahl. Willst du diese Aufgabe auch nicht-Programmierern überlassen, wird es halt interessant. Wie meine Vorrednerin sagte ist LUA am ehesten für eine Sandbox und gut, also wenn du massenhafte überschaubare Quests hast, die Leute schreiben können sollen, die wenig Erfahrung haben. Bots werden oft in Lua geschrieben. Ebenso ganze Fabriken zum Steuern von Maschinen. Diese machen im Einzelnen ja auch recht einfache Aufgaben wie "Gehe von a nach b", "messe x","gebe Daten weiter nach c".
In der Minecraft-Welt befinden wir uns hier auf Ebene der QuestGuis, die direkt auf Citizens aufsetzen. Diese Plugins könnten allerdings mäßig programmiert sein und du machst dich von ihnen abhängig (denizen ist dagegen relativ versionsunabhängig). Sie sind schöner weise meist kombinierbar.

In beiden Fällen muss man schon Gründe suchen, warum man das Rad neu erfinden sollte, denn diese Lösungen machen fast alles möglich. Worauf ich in den letzten Beiträgen aber noch verwiesen hab, ist die dritte Möglichkeit, dass du Quest mit hohem Individualitätsgrad bei hoher Sicherheit willst. Ich rede dabei nicht von gezielter Sabotage - da ist wieder LUA besser, sondern vom Typischen "Die Leute vor sich selber schützen". Hier sind wir eben bei Python und co., also den typsicheren Skriptsprachen. Hier kannst du ganz gut einstellen, wie viel Macht der Skripter bekommt und im Zweifelsfall Teile in Java, Teile als Skript umsetzen.

Beispiel: Man soll zuerst das Vertrauen eines Sprengstoffexperten gewinnen und dann sein Lager in die Luft jagen. Das beginnt wahrscheinlich mit vielen Botengängen und Dialogen, was schnell geskritptet werden kann, bzw. in einer ingame-gui umgesetzt (die wiederum das Skript erzeugt). Reicht es dir, dass am Ende eine Explosion stattfindet und dabei vielleicht ein paar Sachen abbrennen, so kannst du das alles bereits mit lua/Plugins lösen. Wenn Partikeleffekte, Phasing (d.h. nur dieser Spieler sieht ab da an das zerstörte Haus), und weitere einmalige Elemente dazu kommen sollen, dann sind wir schon wieder bei Denizen, bzw. Java, denn hier gibt es keine Fertiglösungen und es macht auch keinen Sinn, eine zu programmieren, wenn sowas einmalig in deinem Spiel ist.

Ich glaube, dass die Kombination des Ganzen für Mammutprojekte wie dem Deinen sehr sinnvoll ist. Eine so große Karte braucht meist eine hohe Questquantität und viele lineare Minidialoge, für die ich großartige Programmierarbeit vermeiden würde. Hier sind wysiwyg-Editoren Gold wert. Diese werden nur zu kompliziert wenn, wie bei unserem Projekt jede Questline einzigartige Gameplayelemente, Verzweigungen, Bosse und co einführt. Hier muss entweder ein neues Tool für jedes Element her, oder man nutzt die umfangreichen Skriptsprachen. Alles in einem Toolkit unterzubringen ist jedenfalls keine Option.

 

[Panossa]

Ich arbeite mal wieder mit Zahlen:

1. Mit Java 9 entfällt tatsächlich das Problem des neu Kompilierens größtenteils. Man könnte Quests auch als Module nachladen, bzw. austauschen. Problem ist dann halt, dass jeder der Quests umsetzen möchte, java beherrschen muss.

2. Für Minecraft gibt es eigentlich schon viele machtige Systeme.

3. Ich glaube, dass die Kombination des Ganzen für Mammutprojekte wie dem Deinen sehr sinnvoll ist. Eine so große Karte braucht meist eine hohe Questquantität und viele lineare Minidialoge, für die ich großartige Programmierarbeit vermeiden würde. Hier sind wysiwyg-Editoren Gold wert. (...) Hier muss entweder ein neues Tool für jedes Element her, oder man nutzt die umfangreichen Skriptsprachen. Alles in einem Toolkit unterzubringen ist jedenfalls keine Option.

4. Diese (WYSIWYG) werden nur zu kompliziert wenn, wie bei unserem Projekt jede Questline einzigartige Gameplayelemente, Verzweigungen, Bosse und co einführt.

Zu 1) Inwiefern? Was genau hat Java9 da? Nichts, was ich in den Changelogs gesehen habe, an das ich mich noch erinnere, weist darauf hin.

Zu 2) Es gibt mächtige Systeme, aber wenn man sich z.B. gegen Python entscheidet, muss man eh ein komplett eigenes System machen. Zudem kommt, dass wir möglichst wenige "fremde" Plugins verwenden wollen, wobei Denizen eben so eins wäre.

Zu 3) Ich denke es ist schon recht klar, dass man auf einer Seite für simplere Sachen ein WYSIWYG System braucht, aber für interessantere Quests dann natürlich eigene Sachen programmieren muss.

Zu 4) Ich denke, dass man bei einem RPG Server, welcher was von sich hält, grundsätzlich von "einzigartigen Gameplayelementen", und zumindest "Bossen und co" ausgehen sollte. Verzweigungen sind vllt eher selten, aber ist bei uns wie bei euch wohl mit im Plan.

~Panossa

 

[Panossa]

Ich weiß nicht genau was dein Ziel ist, dein Einstiegspost gibt wenig her und unterwegs ist auch schon ein Beitrag verschwunden.

Damit wir hier alle auf dem gleichen Stand sind: Es geht um einen Server mit derzeit einer Map, die knapp größer ist als die von Skyrim. MMORPG, mit Quests, die auch noch einmal vom Komplexitätsgrad über dem von den mir bekannten MMOs liegen. Deswegen brauchen wir wahrscheinlich irgendwas, mit dem man irgendwie skripten kann. Mir ist auch klar, dass JS und Python an sich keine (großen?) Vorteile gegenüber Lua haben... nur die Sache ist: Für Python gibt es Denizen (und bestimmt mehr). Für JS gibt es zumindest Rhino, was eh z.B. in WorldEdit integriert ist.
Für Lua kenne ich allerdings kein Plugin, welches Libs o.A. zur Verfügung stellt. Heißt, man müsste wahrscheinlich einen eigenen Interpreter schreiben. Das an sich ist ja schon fast kompliziert genug, aber wenn man dann noch möchte, dass die Lib nicht "oberflächlich" ist, sondern vielleicht sogar Packetmanipulation (indirekt oder direkt) drauf hat, dann ist das noch einen Schritt komplizierter. (Besonders, wenn man sich dann noch Sorgen um die Synchronisierung der Dateien/Skripte, Autocomplete und anderen schicken Stuff machen muss)

 

[Chrisliebär❤️]

Rhino ist auch nur eine Library, die halt mit Java mitgeliefert wird. Wenn du Lua in Java einbetten willst, so würde ich LuaJ (http://www.luaj.org/luaj/3.0/README.html) empfehlen. Das habe ich kurzzeitig verwendet, bevor ich meine Entwicklung auf C++ umgestellt habe. Das bietet dir alles was du brauchst. Also die Einbindung der Sprache in die Anwendung ist in keinem Fall ein Problem, du musst dafür auch keinen eigenen Interpreter schreiben oder ähnliches. Das würde konkret halt so aussehen, dass du einen Adapter zwischen dem Eventsystem von Bukkit und deiner Skriptengine brauchst, der dafür sorgt, dass sich Skripte für Events von Bukkit registrieren können. Ein paar weitere Funktionen musst du vermutlich ebenfalls noch zur Verfügungstellen, beispielsweise für den Scheduler oder sowas. Hier bietet es sich dann auch an das Ganze zu trennen, so dass du über deine Skriptengine einzelne Skripte entladen kannst und alle registrierten Events automatisch gelöscht werden. Das ist das Sandboxing, das ich früher angesprochen habe. Ist sicherlich sehr mühseelig zu implementieren, aber du kannst damit den Zustand von Skripten oder Quests komplett einfrieren oder analysieren. Mit anderen Sprachen, die grundsätzlich tiefer mit der Anwendung verbundelt sind, funktioniert das nicht unbedingt so einfach. Das geht alles auch mit anderen Sprachen, doch mit Lua kannst du es halt ERZWINGEN und das finde ich persönlich das Killerargument für Lua.

Zu 2) Es gibt mächtige Systeme, aber wenn man sich z.B. gegen Python entscheidet, muss man eh ein komplett eigenes System machen. Zudem kommt, dass wir möglichst wenige "fremde" Plugins verwenden wollen, wobei Denizen eben so eins wäre.

Denizen ist aber schon fertig und getestet. Wenn du Glück hast, findest du sogar Leute, die es bereits benutzt haben. Das ist ein nicht zu unterschätzender Vorteil. Man muss aber auch sagen, dass du dich damit davon abhängig machst und es ggf. nicht anpassen kannst. Das ist insbesondere bei großen Projekten vielleicht ein Problem, doch dazu später mehr.

sondern vielleicht sogar Packetmanipulation (indirekt oder direkt) drauf hat, dann ist das noch einen Schritt komplizierter. (Besonders, wenn man sich dann noch Sorgen um die Synchronisierung der Dateien/Skripte, Autocomplete und anderen schicken Stuff machen muss)

Skripte haben unter keinen Umständen jemals irgendwelche Netzwerkpakete anzufassen. Das sind vollkommen verschiedene Abteilungen. Netzwerkpakete sind Aufgabe der Netzwerkschicht, wenn du da bestimmte Effekte realisieren willst, gehört das in eigene Klassen gekappselt, die das Skript als Blackbox benutzt. Von Autocomplete wirst du nur träumen können. Diese Seperation in Aufgabenbereiche ist ein ganz wichtiger Schritt, wenn du ein großes System erzeugen und warten willst. Ich empfehl dir dringendst, dass du zuerst mit ein paar der existierenden Systeme arbeitest. Nicht nur für Minecraft, schau dir andere Spiele an. Schreib Skripte und Quests für diese Systeme. Du machst mir aktuell nicht den Eindruck, dass du eine Vorstellung davon hast, welche Daten du überhaupt austauschen musst oder wie sich so eine eingebettete Skriptsprache anfühlt. Außerdem würde ich dir auch empfehlen einen kleinen Prototyp vorher zu entwickeln, sofern du wirklich dein eigenes System implementieren willst. Irgendwas kleines um mit der Binding API deiner gewählten Umgebung vertraut zu werden.

Zu 1) Inwiefern? Was genau hat Java9 da? Nichts, was ich in den Changelogs gesehen habe, an das ich mich noch erinnere, weist darauf hin.

Java 9 bringt nach aller Vorraussicht ein Modulsystem mit, dass es dir erlaubt Jar Dateien inklusive Inhalt dynamisch zur Laufzeit zu Laden aber auch zu Entfernen. Ersteres ging mit ein paar bösen Tricks schon länger, aber letzteres war nahezu unmöglich. Stellt dich aber im Endeffekt vor die selben Probleme, wie alle anderen Skirptsysteme. Du musst in der Lage sein, die Objekte, die von einem Skript erzeugt werden restlos aus dem Speicher zu entfernen, das heißt sämtliche Listener oder ähnliches müssen vor dem Entladen raus, ansonsten hast du dadurch keine Vorteile. Dafür ist es notwendig, dass du genau verfolgst, welche Skripte welche Daten im System verteilt haben und diese am besten als Teil der Schnittstelle automatisch entfernst.

Dann noch so ein paar eher persönliche Dinge, die man vielleicht mal Ansprechen sollte:

Mir ist auch klar, dass JS und Python an sich keine (großen?) Vorteile gegenüber Lua haben... nur die Sache ist: Für Python gibt es Denizen (und bestimmt mehr).

Das sollte keine Rolle Spielen. Du wählst einmalig das System, mit dem du deine Quests und Skripte erledigst. Ich mein, was ist hier genau das Arugment? Du wirst niemals an den Punkt kommen wo du deine Skripte plötzlich auf ein anderes System migrierst. Egal was du wählst, du bist an das anfänglich gewählte System mit seiner Programmiersprache gebunden. Dass andere Systeme andere Sprachen benutzen spielt dann keine Rolle mehr.

MMORPG, mit Quests, die auch noch einmal vom Komplexitätsgrad über dem von den mir bekannten MMOs liegen.

Zu 3) Ich denke es ist schon recht klar, dass man auf einer Seite für simplere Sachen ein WYSIWYG System braucht, aber für interessantere Quests dann natürlich eigene Sachen programmieren muss.

Glaubst du nicht, dass jedes Entwicklerstudio das ebenfalls von ihrem eigenen Produkt glaubt? Das ist schlicht eine Selbsttäuschung. Du wirst den Großteil aller Quests in einem ganz einfachem Schema von Baukastenelementen abbilden können und bedenke, dass eine Quest mit vielen Teil nicht automatisch komplex ist. Das sind auch alles nur einzelne Bausteine. Mit einem WSYIWYG Editor kannst du beliebig komplizierte Questsysteme erstellen, die Frage ist nur, ob die Zeit, die du in den Editor steckst am Ende wieder dadurch gewonnen wird, dass Nichtprogrammierer dafür Quests für dich erstellen können und das bezweifle ich ehrlich gesagt, von daher würde ich das nicht machen.

Es geht um einen Server mit derzeit einer Map, die knapp größer ist als die von Skyrim.

Das ist etwas, dass ich sehr oft sehe, wenn sich jemand total übernimmt. Wenn eure Map größer ist als Skyrim, dann hoff ich auch, dass euer Team größer ist. Skyrim war schon mehrere Jahre in Entwicklung, ich seh nicht warum ihr da als vermutlich unerfahrenes Team nicht mindestens doppelt so lange brauchen solltet und ob bis dahin Minecraft noch wirklich gespielt wird? Vor allem auf dieser Version? Was ist wenn die Plugins, die ihr benutzt und fest integriert habt plötzlich keine Updates bekommen und ihr daher nicht updaten könnt? Vielleicht erstmal kein Problem, doch wenn eure Version dann 4-5 Jahre alt ist könnte das zum Problem werden.

--

Was du suchst ist ein Skriptsystem. Dass du damit Quests machen kannst, ist ein praktischer Nebeneffekt. Für mich klingt das alles so, als ob du dich da massiv übernimmst, das ist aber deine Entscheidung. Auf jeden Fall ersparst du dir sehr viel Arbeit, wenn du bestehende Systeme wie Denizen benutzt, auch wenn du dabei das Risiko in kauf nimmst, dass du plötzlich auch Denizen mit Updates versorgen musst. Wobei ich sagen muss, dass Denizen, nachdem ich es mir kurz angesehen habe, absolut dreckig aussieht. YAML ist eine Sprache zum Beschreiben von Datenstrukturen, nicht zum programmieren. Ich würde da absolutt die Finger von lassen und was vergleichbares suchen. Wenn du etablierte Skriptsprachen verwendest, findest du überall Hilfe, wenn du ein Problem hast. Für diese Insellösung findest du nichts und dazu bietet Denizen nicht mal wirklich eine saubere Trennung der Skripte, du kannst da ebenfalls beliebig kaputte Skripte bauen.

 

[Panossa]

1. Rhino ist auch nur eine Library, die halt mit Java mitgeliefert wird. Wenn du Lua in Java einbetten willst, so würde ich LuaJ (http://www.luaj.org/luaj/3.0/README.html) empfehlen.

2. Glaubst du nicht, dass jedes Entwicklerstudio das ebenfalls von ihrem eigenen Produkt glaubt? Das ist schlicht eine Selbsttäuschung.

3. Das ist etwas, dass ich sehr oft sehe, wenn sich jemand total übernimmt. Wenn eure Map größer ist als Skyrim, dann hoff ich auch, dass euer Team größer ist.

--

4. Was du suchst ist ein Skriptsystem. Dass du damit Quests machen kannst, ist ein praktischer Nebeneffekt.

5. Auf jeden Fall ersparst du dir sehr viel Arbeit, wenn du bestehende Systeme wie Denizen benutzt, auch wenn du dabei das Risiko in kauf nimmst, dass du plötzlich auch Denizen mit Updates versorgen musst. Wobei ich sagen muss, dass Denizen, nachdem ich es mir kurz angesehen habe, absolut dreckig aussieht. YAML ist eine Sprache zum Beschreiben von Datenstrukturen, nicht zum programmieren. Ich würde da absolutt die Finger von lassen und was vergleichbares suchen. Wenn du etablierte Skriptsprachen verwendest, findest du überall Hilfe, wenn du ein Problem hast. Für diese Insellösung findest du nichts und dazu bietet Denizen nicht mal wirklich eine saubere Trennung der Skripte, du kannst da ebenfalls beliebig kaputte Skripte bauen.

1. Danke!

2. Klar behauptet das jedes Studio von sich, aber ich weiß halt auch, dass der derzeitige Plan nicht von normalen Quests ausgeht. Zumindest die Quests, die ich bisher in MMOs gesehen habe, sind meist echt seehr flach. Vor Allem, weil man da meist bis immer keine Verzweigungen hat. Ich behaupt auch nicht, dass Unsers so krass besonders ist, aber es ist zumindest laut Plan nicht (so) flach.

3. Der derzeitige Plan sieht nach "etwas größer als Skyrim" aus. Wir haben erst kürzlich ein paar unnötige Gebiete weggestrichen und das wird auch wahrscheinlich noch einmal passieren. Oder öfter. Ich wollte nur symbolisieren, dass es sich dabei nicht um sowas wie eine Multiplayer Adventuremap handelt, sondern schon etwas größer ist.

4. Dann mal gucken, wie man sich so einen Interpreter zusammenbastelt.

5. Ich werde wahrscheinlich eh kein Denizen auf diesen Server lassen. Aus anscheinend bereits vielen Gründen.

~Panossa

 

[Aeogen]

Als du das letztes mal sagtest, sie sei 60% als die von Skyrim, hab ich mich aus dem Gespräch zurückgezogen, zumal du mich auch sehr oft missverstehst (oder wie beim posting auf yt gar nicht) und ich keinen Streit will. Man kann nicht alles machen, außer man zieht Gelder wie StarCitizen ran. Das Bauen der Map ist nämlich gar nicht das Problem, sondern das Beleben und das technische.

Wie schon mal erwähnt brechen viele sehr bekannte rpg-Servern bei 30 Leuten schon in die Knie und machen daher einen Mirror, bzw. extra lobbys und verwässern damit das "multi" und das "massive" im mmo. Das Beleben ist aber das Schwierigste bzw. Unglaubwürdigste in diesem Zusammenhang.
Bei Skyrim willst du von A nach B, was geradeaus 10 Minuten dauert, aber ständig lenkt dich irgendwas ab, bzw. zum Erkunden ein, sodass du am Ende eine Stunde gebraucht hast. Dazu hat ein großes Team mehrere Jahre gebraucht und es ist mehrere Male nicht so gut gelungen.
Das erste Elder Scrolls ist das wohl größte RPG ever aber erst ab Oblivion machte es bei den Spielern klick, sodass man gerne über 1.000 Stunden spielt, wenn das rl es zulässt.
Mit AddOns waren auch Morrowind, die aktuelleren Fallouts und Oblivion höchstens so groß wie Skyrim. Und schon hier musste man "Nachteile" einkaufen, etwa, dass Gegner mitskalieren müssen, weil man nie weiß, wo der Spieler als nächstes hin will. Außerdem investiert man stundenlange Arbeit für wenige Minuten Gameplay. Solche Probleme hatten die Gothic/Risen/Zelda-Reihen z.B. nicht. Durch Längsschnittdesign bei den Quest (Quer=ein Zeitpunkt, Längs=über zeit) hat man die selben Stellen mehrmals besucht und eine Bindung zum Ort und zu den Charakteren aufgebaut.
Hier ist es z.b. auch traurig, wenn jemand stirbt. Bei eso ist einem das relativ egal..

Generell sind das zwei verschiedene Philosophien beim Gamedesign: Die letzteren Beispiele wurden (außer Gothic 3 und wahrscheinlich Elex) von vorne nach hinten entwickelt. Man hatte also erst die Story/Idee und sich dann gefragt, was man hinzufügen kann um das zu "Gamifizieren". Hier kann jede Minute des Gameplays getestet, verdichtet, optimiert werden.
Bei der anderen Herangehensweise nimmt man ein Rudel Gameplayfeatures, prozedurale Elemente und ein automatisiertes Balancing, rührt kräftig und hofft, dass der Eintopf am Ende schmeckt. Elder Scrolls konnte über 10 Titel lang wachsen und hatte zwischendurch vieles, was wenig spaß machte und schief gehen kann. An hunderten Ecken fehlt feinschliff. Viele Bugs wurden nie behoben, eine Erinnerungswürdige Mainquest fehlt bis heute (bzw. zeigten die kleineren Welten der Addons/Mods, dass mehr geht). Trotzdem war und ist es ein Hit.

Bei TESO sieht man vielleicht noch besser, wie fragil so ein System ist.

Dass die Quests einfach sind, passt dabei ins Gameplay und ist bei der Größe einfach die einzig sinnvolle Option: Es handelt sich nämlich allesamt um "töte, suche, bringe, rede mit"-Quests. Allerdings immer so gut verpackt, dass dir das nicht auffällt, wenn du nicht analytisch darüber nachdenkst. Letztlich ist es bei Narrationen doch immer so, dass nicht die Story selbst das Wichtige ist, sondern wie sie erzählt wird. Die Geschichten von Serien sind für den Kenner irgendwann immer die Selben, aber die Charaktere und Dialoge machen sie bestenfalls recht einzigartig..
Witcher 3 ist ein gutes Beispiel. Im Kern sind die Quests auch nicht komplex, aber eben gut geschrieben und überraschend von der Idee her. Übrigens ist das Spiel auch ein "hybrid" in meinem Klassifikationssystem, weil hier eine große Welt auf linerares Storydesign trifft. Systeme wie Alchemie sind dabei auf das, was gebraucht wird zugeschnitten und nicht wie bei eso ein in sich geschlossenes System, das unabhängig von der Story ist.

Mass Effect Andromeda zeigt, wie einfach alles schief gehen kann, obwohl die Einzelelemente gut sind. Trotz vielstufiger Quests hat sich am Ende alles wie Abfrühstücken angefühlt, wenn man sich nicht exakt so verhalten hat, wie es die Entwickler gehofft haben. (Es gab zb eine quest, die die nächsten Stages triggert. Bis dahin waren alle quests on hold und plötzlich hatte man wieder 30 Quests offen, die man teilweise wieder vergessen hat/die einem egal geworden sind und die man nun abfrühstückt, obwohl sie in sich gut waren). Die pure Masse hat das Gesamtwerk zudem abgewertet.

4.5. Ich glaube, dass diese Aussage ein guter Grund ist, keinen Interpreter zu machen. Es könnte sich nach vielen Monaten als Zeitverschwendung heraus stellen. Vielleicht schaut ihr euch vorher die vorhandenen Lösungen mal genau an. Quests, Quester, QuestGui und wie sie alle heißen (auch wenn letzteres wieder Denizen ist, aber eben als wysiwyg-Editor). Dann merkt ihr vielleicht auch, ob ihr wirklich mehr braucht... .