We'll add this for the new version 
Posts by red51
-
-
Vielen Dank für das Feedback!
Wird man mit der Demo-Version auch die ersten Eindrücke von der API bekommen?
Nein, leider noch nicht
Also zumindest kein wirklicher Eindruck. Es ist zwar eine unfertige Plugin jar mit dabei (die man dekompilieren könnte) und auch eine eigene JVM wird bereits mitausgeliefert. Es wird vom Spiel aus aber noch kein Plugin geladen.Zumindest eine JavaDoc wäre mal schön, um schon mal inhaltlich zu wissen, was da alles kommt.
Naja, bis jetzt würde das nur die Dinge beinhalten, die wir bisher umgesetzt haben - da ist bis auf ein paar neue Events und Funktionen noch nichts atemberaubendes bei
Die "interessanteren" geplanten API-Features kommen erst noch.Wenn die API aber etwas näher rückt werde ich noch einen separaten Thread dafür erstellen. Darin werden die Neuerungen beleuchtet, vor allem aber auch die Hauptänderungen ggü. der Java-Version
Ich hoffe nur, daß es mit der Linux-Version nicht allzuviele Abstürze etc. gibt
Das hoffe ich auch
Unity legt offenbar keinen sonderlich großen Wert auf Linux (was extrem schade ist) und ich kann mittlerweile auch verstehen, warum die Rust-Entwickler den Linux-Support damals eingestellt haben 
Die aktuelle Version läuft auf unserer Testhardware unter Linux aber weitgehend stabil, ist aber übermäßig VRAM-hungrig. Es gibt unter Linux ansonsten noch einige "kleinere" Einschränkungen (zB kann die Auflösung nicht ohne Neustart des Spiels geändert werden - dieses Problem wurde bereits im Januar an Unity gemeldet).Wir versuchen alles, die Linux-Version so lauffähig wie möglich zu gestalten, uns sind aber in vielen Bereichen die Hände gebunden... während wir bei Java noch volle Kontrolle hatten und im Zweifel die Engine anpassen konnten, ist das bei Unity nicht möglich. Hinzu kommt, dass die Mühlen bei Unity teilweise sehr langsam mahlen, sodass man auch auf kleinere Bugfixes manchmal viele Monate wartet
Nichtsdestotrotz würde ich dich aber bitten, uns alle technischen Probleme mit der Demo zu melden. Generell würde ich erstmal abwarten, wie "schlimm" das wirklich ausfällt, denn tatsächlich spielt die jeweilige Hardware eine große Rolle (vor allem die Grafikkarte)
Ich möchte an der Stelle aber nochmal allgemein betonen, dass all diese Probleme natürlich "nur" das Spiel selbst betreffen. Der künftige dedicated Server für Linux hingegen wird keine Probleme machen (99 % der Probleme hängen mit dem Rendering zusammen, und das fällt ja logischerweise beim Server weg).
Wird man in der Demo in eine vorgefertigte Welt gesetzt (also eine, die bereits generiert wurde) oder kann man selbst die Welt generieren?
Die Demo wird mit einer vorgefertigten Welt kommen. Hier möchten wir erstmal nichts dem Zufall überlassen
Aber ein anderer Grund ist auch, dass in der vorgefertigten Welt bspw. auch bereits diverse Möbel und Lichter platziert sind, mit denen man interagieren kann. In einer frisch generierten Welt würden die natürlich fehlen und vom begrenzten Content der Demo wäre dann noch weniger zugänglich (bzw. hinter Konsolenbefehlen versteckt).Erst in einem der künftigen Updates wird es dann möglich sein, eigene Welten zu generieren. Evtl. erst nachdem Wasser drin ist, denn das wird auf die Weltgenerierung einen großen Einfluss haben.
-
Wie wäre es, wenn die Hacke Ackerboden erzeugt, ohne das das Gras direkt mit verschwindet
Meinst du damit tatsächlich den Ackerboden, den man mit der Hacke erzeugt (auf dem du anschließend Pflanzen anbauen kannst), oder meinst du nur den einfachen Erdboden, der durch die Harke entsteht? Ich bin mir aber nicht sicher, ob Gras in dem Fall weiterhin bestehen bleiben sollte... man kann ja nicht den Boden umgraben, ohne die Grashalme zu entfernen
Oder habe ich das falsch verstanden?Und Gras hätte die Eigenschaft direkt unter sich Ackerboden in grünen Erdboden zu verwandeln (hat was von Unkraut).
Über einen Mechanismus, dass Felder bzw. Ackerböden zusätzliche Pflege benötigen, könnte man evtl. nachdenken. Bei reinem Erdboden (also durch die Harke erstellt), zB Ackerwegen, könnte das hingegen schon ne Menge Arbeit für den Spieler bedeuten. Häufig werden ja viele solcher Wege angelegt, und auf großen Servern könnte ich mir vorstellen, dass man irgendwann nur noch damit beschäfigt ist, diese Wege vom nachgewachsenen Gras zu befreien
Das könnte möglicherweise frustrierend sein...Um Gras wachsen zu lassen könnte man Knochen ( Von Tieren und Fischgräten) im Mahlwerk zu Knochenmehl mahlen und es als Dünger zu verwenden ( macht aus Erde grüne Erde und lässt auf grüner Erde Grashalme wachsen/spawnen/erscheinen).
Dünger ist auf jeden Fall geplant. Dass man damit Grashalme spawnen kann wäre vielleicht eine gute Idee
-
Thanks a lot for your feedback
Whatever it is, it appears to be a singular object--not plural and un-owned.
Bigfoot confirmed
-
Kann nun wirklich nicht sein ,dass das Bausystem dann schon mit drinnen ist. Ich weiß nun wirklich nicht, ob ich schon soweit bin
Hehe, ja, absolut nachvollziehbar
Aus Rücksicht auf die Community passen wir auf, nicht zu viele Features gleichzeitig reinzubringen -
Echt schade das es bis dahin schon fertig ist
Hehe, lol, danke für den Hinweis, natürlich fehlte dort ein "nicht"
-
Hey folks! We're currently focusing on getting the first demo of the new version ready as soon as possible. The first version will be rather a "walking simulator", but it will serve as foundation for future updates. And the demo will still give a good impression of the gameplay and the technical component (graphics, audio etc) of the new version.
The last weeks we've been further improving the terrain generation. The game now generates more realistic, but also much smoother landscapes (i.e. no more "bumpy" terrain). Biomes (including proper forests) and dungeons are still missing, but the world is already more varied than in the old version.
We've also been working on the new building part. Our goal is to keep the freedom of the old system, but improve it to a extent that building becomes a lot less painful. Apart from fixing some issues of the old building system, we've reworked the way how snapping works from scratch. You will be able to change the rotation pivot of an element, and you will also be able to snap the object to a pivot of another element. As a result, creating curved structures will be much easier.
Unfortunately the building part won't be ready for the first demo release, but it will be available in a separate update shortly after.
We also spent some time on a new auto-updater/launcher (for the Standalone version) and on a Linux build. Unfortunately it looks like Linux/Vulkan support isn't Unitys greatest strength, which is a bit disappointing. We've discovered some bugs which are out of our control - most of the rendering stuff is "black boxed" in Unity and the source code of the engine isn't available. Only thing we can do in this case is to forward these issues to Unity, however, if you experience any issues or crashes with the Linux version of the game, please don't hesitate to contact us.
As always, you find more information on our Trello roadmap
-
Hey Leute! Aktuell konzentrieren wir uns darauf, die erste Demo der neuen Version so bald wie möglich fertig zu bekommen. Die erste Version wird zwar eher ein "Walking Simulator", aber als Grundlage für künftige Updates dienen. Und die Demo wird dennoch einen guten Eindruck des Gameplays und der technischen Komponente (Grafik, Audio etc) der neuen Version vermitteln.
Die letzten Wochen haben wir weiter an der Terrain-Generierung gearbeitet. Das Spiel generiert nun realistischere, aber vor allem auch "weichere" Landschaften (also kein zerkluftetes, unebenes Terrain mehr). Biome (einschl. richtiger Wälder) sowie Dungeons fehlen zwar noch, aber die Welt ist bereits jetzt abwechslungsreicher als in der alten Version.
Wir haben ebenfalls am neuen Bausystem gearbeitet. Unser Ziel ist, die Freiheiten des alten Systems beizubehalten, es aber soweit zu verbessern, dass das Bauen wesentlich angenehmer wird. Abgesehen davon, dass wir einige Probleme des alten Systems behoben haben, haben wir auch die Art und Weise, wie das modulare Platzieren funktioniert, von Grund auf überarbeitet. Es wird möglich sein, den Rotationspunkt eines Elementes zu verändern, und man wird Objekte an verschiedenen "Andockpunkten" anderer Elemente anheften können. Als Resultat wird das Bauen von runden Strukturen und Kurven deutlich einfacher werden.
Leider wird das Bausystem noch nicht bis zum ersten Demo-Release fertig sein, dafür aber in einem Folgeupdate verfügbar werden.
Wir haben auch etwas Zeit in einen neuen Auto-Updater bzw. Launcher (für die nicht-Steam Version) sowie den Linux Build gesteckt. Leider scheint es so, dass der Linux/Vulkan Support nicht unbedingt Unitys größte Stärke ist, was ein wenig enttäuschend ist. Wir haben ein paar Bugs entdeckt, auf welche wir allerdings keinen Einfluss nehmen können - der meiste Teils des Renderings ist quasi eine "Black Box" innerhalb von Unity und der Source-Code der Engine ist nicht verfügbar (anders als bei Unreal). Das einzige, was wir in dem Fall machen können, ist die Bugs an Unity zu melden. Aber wenn ihr Probleme oder Crashes mit der Linux Version entdeckt, zögert bitte nicht, uns zu kontaktieren.
Wie immer findet ihr mehr Informationen auf unserer Trello Roadmap
-
Lol, no, I'm not an atheist
I hardly believe the word "xmas" is primarily used by atheists Yet we don't want to put the game in a religious context -
Ihr habt aber auch strenge Wort-Definitionen
Mein Vokabular für vage Zeitangaben ist langsam echt aufgebraucht 
-
Unfortunately the behaviour of the sledgehammer (and crowbar) isn't determined by the HitDamageDefinition atm
Currently the ability to remove blocks without destroying them is hard-coded. This will change in the new version though. Currently the only workaround would be to emulate this behaviour by modifying the world (and spawning the appropriate block) manually via API, but that's a bit tricky.However, the ability to cut grass is already exposed to the hit definition, so it should be possible to create a more powerful weed whacker, for example
-
Aktuell gibt es dafür leider keine Events, aber die neue Version wird dafür ein passendes Event haben
Derzeit kann man die Änderung dieser Werte nur abfangen, indem man selber prüft, ob sich die Werte zwischenzeitlich geändert haben (zB in einem Update-Listener oder in einem Timer).
Eine Erhöhung dieser Maximalwerte war im Spiel zwar teilweise mal umgesetzt, aber nie vollständig implementiert, daher ist das über die API leider nicht direkt möglich. Auch hier wäre der einzige Workaround, Änderungen an diesen Werten selber abzufangen und zu beeinflussen (zB statt die maximale Health zu erhöhen, den jeweils erlittenen Schaden reduzieren).
In der neuen Version wird sich das wahrscheinlich teilweise ändern. Variable Maximalwerte werden dort zumindest schon für HP, Stamina und Atem (also wenn man sich unter Wasser befindet) berücksichtigt, allerdings noch nicht direkt verwendet. Für ein künftiges Skill-System wäre das aber vorteilhaft, daher wird das voraussichtlich dort noch rein kommen (und dann würde auch die API Zugriff darauf bekommen).
-
Just checking in on this. Is there an event for this yet?
Unfortunately this event isn't available in the Java version yet
It's still on our to-do list for the new version though -
Wird es den Lua-Wrapper noch geben?
Das kann ich nicht sagen, theoretisch möglich wäre das schon, kommt ein wenig auf die Nachfrage drauf an. Eigentlich wollen wir Lua aber nicht unbedingt als Skript-Sprache für RW pushen, da hier viel Performance verschenkt wird (Hauptproblem ist die fehlende Multi-Threading-Funktionalität, die für RW extrem wichtig ist). Aber auch wenn wir den Lua Wrapper anbieten, müssten bestehende Lua Skripte voraussichtlich trotzdem etwas angepasst werden, damit sie mit der neuen Version kompatibel sind
-
red51 , Wan ist bald?
Vermutlich irgendwann in den kommenden Tagen
Wir haben in den letzten Tagen etwas länger als geplant am neuen Standalone-Launcher gesessen (betrifft zwar nicht die Mehrheit der Spieler, aber muss ja trotzdem gemacht werden^^). Im Laufe der kommenden Woche dürfte die Ankündigung soweit sein. -
Mich würde Mal die WASSER Frage interessieren. Wird es da auch gleich Wasser geben ? Wie sieht es mit dem Fließverhalten aus ? Mir würde das Fließverhalten so wie bei mc komplett reichen. Würde heißen das es dann so 6-7 Blöcke weit fließen kann, aber auch das wenn man am Ufer gräbt, sich der Wasserspiegel automatisch angleicht was ich am wichtigsten dabei finde.
Wasser wird es in der Demo leider noch nicht geben, bisher haben wir noch nicht viel am Wasser gearbeitet
Der erste Release mit Wasser wird aber dafür dann direkt dynamisches Wasser beinhalten. Unser bisheriger Zeitplan (kann sich natürlich noch ändern) sieht so aus, dass wir jetzt zunächst die erste spielbare Version auf Vordermann bringen (hier und da noch Feinschliff am Terrain und Vegetation, und noch viele Kleinigkeiten [zB zumindest ein einfaches Settings-Menü usw]), danach steht das Bausystem im Vordergrund (also es in eine Release-fähige Form bringen), und dann möchten wir uns um die Spielerfiguren und Item-Animationen kümmern (in dem Bereich gibts noch einige ungeklärte Fragen). Danach kommt der Multiplayer zum Abschluss (prinzipiell ist der schon drin, aber es fehlt noch richtige Player-Sync und ein dedicated Server), und vmtl. wird es dann in Richtung Wasser und sowas wie NPCs gehen.Rising World sieht so realistisch aus, warum denn dann beim Wasser zurückstecken? Hat dieses Spiel doch gar nicht nötig, auch wenns länger dauert.
Ich würde mir auch realistisches Wasser wünschen, aber wie Avanar und lenko schon sagen, das ist in dem Umfang leider (noch) nicht möglich. Dazu müssten einzelne Wasserpartikel (oder Tröpfchen, wie Avanar beschreibt) simuliert werden. Es wären zwar vmtl. auch hinreichend gute Ergebnisse möglich, wenn diese "Tröpfchen" etwas größer ausfallen (sagen wir mal 5x5cm), aber sowas ist im großen Stil leider nicht umsetzbar. Es gibt zwar viele nette Wasserdemos auf YT, aber hier gehts immer nur um sehr kleine Bereiche. Es wäre also mit heutiger Hardware auf jeden Fall umsetzbar, dass man eine Wanne voller "realistischem" Wasser hat, oder vielleicht ein ganzer Teich. Alles darüber hinaus stößt aber an die Grenzen. Ein ganzer See mit "realistischem" Wasser, der leerläuft und eine Höhle flutet, wäre schlicht unmöglich (zumindest in dieser Form).
Bei RW kommt hier sogar noch ein anderes Problem hinzu: Die Änderungen müssen irgendwie gespeichert werden. Wenn die Auflösung des Wassers also so genau ist, dass jeder einzelne (große) Tropfen gespeichert wird, würde das enorm viel Speicherplatz benötigen. Wenn ein "Wassertropfen" 0.05 Blöcke groß wäre (würde gehen, wäre aber schon ein sehr großer Tropfen), wären das pro Block 20x20x20, also 8000 "Tropfen". Wasser würde fürs Speichern also bis zu 8000x mehr Speicherplatz benötigen. Im Multiplayer kommt hier die Synchro hinzu, die Tropfen müssten also auch synchronisiert werden (und verursachen entsprechend bis zu 8000x mehr Traffic).
Sowas ist wie gesagt mit heutiger Hardware im kleinen Maßstab möglich, aber nicht für ganze Spielwelten. Und wenn eine persistente Welt oder Multiplayer hinzu kommt, sieht es erst recht düster aus
How to place different water in Unity
Unfortunately this has nothing in common with actual water
This is basically just a static surface that looks like water, but it has no behaviour like water. In fact this video just shows how to drop a ready-to-use asset (which wouldn't be compatible with RW anyway) into the scene editor Rising World has a randomly generated world, which means the world is generated at runtime. It's not available in the editor (because the world always looks different, depending on the selected seed). The scene in our editor is basically completely empty
So in RW, water has to be generated programmatically. And it has to be actual "3D" water (if this makes any sense). While most games with a static, pre-designed world can simply declare the whole area below a certain elevation (e.g. sea level) or below a surface as "water", this wouldn't work in RW (since there could be always a cave under a pond, for example).
Biggest issue is to implement flowing water though. RW has a modifiable environment, so water has to react to a changing environment. Flowing water is computationally very expensive, especially in a multiplayer world (where everything has to be synced with other players). There aren't many games out there that have to deal with this issue, so of course there is no solution for this available somewhere "out-of-the-box"
Ich würde auch gern einen oder mehrere Wasserfälle in Rising World sehen, vieleicht gibt es da ja mal die Möglichkeit das man Wasserfälle in verschiedenen Größen als Objekt setzen kann, somit wäre der Wasserfall zwar statisch aus einer Textur, für mich aber eine klare Alternative
Das wäre definitiv umsetzbar
Natürlich bis zu einem gewisssen Grad eingeschränkt, aber in vielen Situationen dennoch geeignet. Wir könnten darüberhinaus auch ein "Wasser-Objekt" anbieten, also quasi nur eine einfache, skalierbare Wasseroberfläche. Die würde sich zwar nicht wie Wasser verhalten, aber wie Wasser aussehen. Damit könnte man zumindest auf kleineren Flächen Wasser "faken" (zB Wasser in einer Badewanne, oder in einem Eimer, oder einer Tränke etc). -
i can say that some models do crash it. i have been using this plugin to test .obj and .dds textures for the customitemloader before i worry about the itemdef and icon files. ive had some .obj files not allow the server to boot as well it will load it then crash the server and not allow it to restart. i could try to find the error logs if it would help in any way
Can you maybe send me one of the models in question (+ the according texture) via PM? If there is an issue with the model, maybe it's something the game can catch (so at least it doesn't crash anymore)
If you have an additional error log, that would also be helpful -
Heißt es dann, dass ich mit einem Plugin ein Auto programmiere und das Plugin auf einem Server installieren kann wenn die API die Funktion dafür hat?
Wenn die API das unterstützt, dann ja
Wobei es natürlich auch immer einen gewissen Spielraum gibt, den man dabei hat. Denn auch wenn es in der API keine direkte "FügeAutoHinzu()" Funktion gibt, so kann man versuchen, das anderweitig umzusetzen: In dem Fall könnte man zB das Modell eines Autos laden (das kann die API bereits) und darauf warten, dass ein Spieler damit interagiert. Das Plugin könnte sich nun für diesen Spieler merken, dass dieser in einem Auto sitzt, und die Spielerposition entsprechend regelmäßig updaten (an die Position des Fahrersitzes setzen). Wenn der Spieler nun zB die Vorwärtstaste betätigt, dann könnte man das Auto-Modell (mitsamt) Spieler nach vorne bewegen, beim Lenken entsprechend drehen usw. Bis hierhin ist alles auch mit der jetzigen API bereits möglich. Schwieriger wird es, das Auto an das Terrain anzupassen und Kollisionen richtig zu behandeln (wenn der Spieler zB gegen eine Wand fährt). Hier sind zwar einzelne Funktionen für sowas bereits in der API (zB raycast()), aber das wird trotzdem kompliziert - und stößt teilweise an die Grenzen. Neue Funktionen, die im Laufe der Zeit zur API hinzukommen, werden das sicherlich einfacher machen, aber es würde sich bei so einem Unterfangen trotzdem um ein sehr umfangreicheres Plugin handeln.Anders sieht es aus, wenn es bereits Fahrzeuge im Spiel gibt: Dann kann die API eher die Funktionen dazu bereitstellen (womit die Umsetzung eines solchen Plugins 100x einfacher wird). Dann könnte ein Plugin zB sein eigenes Modell einfügen, das Verhalten an das eines im Spiel bestehenden Autos anpassen, und das wars dann auch schon
So funktioniert das derzeit zB mit den Custom Items: Man kann recht einfach eine neue Spitzhacke oder ein neues Schwert einbauen (weil es sowas bereits im Spiel gibt), aber wenn man einen Flammenwerfer einbauen möchte, wird es kompliziert (weil es keine noch Mechanik für sowas im Spiel gibt).Du musst dir das immer so vorstellen, dass die API quasi nur bestehende Funktionen bereitstellen kann. Wenn du eine Funktion in der API aufrufst, kümmert sich das Spiel im Hintergrund um den Rest. Daher kann die API prinzipiell nur das bereitstellen, was das Spiel auch bereits kann.
ZB über ein Plugin eigene Sounds abspielen ist möglich (weil das Spiel weiß, wie man Sounds abspielt), aber bspw. Gamepad-Support über ein Plugin einbinden ist nahezu unmöglich.
Von den Dingen, die das Spiel kann und weiß, versuchen wir, so viel wie möglich über die API zugänglich zu machen, aber fehlende Funktionen fallen meist erst dann auf, wenn man selber ein Plugin schreibt (was wir aus Zeitgründen ja nicht so häufig machen). Dafür haben wir entsprechend die API-Wünsche Sektion^^
-
Die Grenzen zwischen Mods und Plugins sind manchmal fließend, und auch der "Mod" Begriff wird häufig weit gefasst. Auf RW bezogen kann man es sich aber so vorstellen:
- Eine Mod wäre eine Modifikation der Spieldateien. D.h. irgendjemand würde zB das Spiel dekompilieren, irgendwas am Code ändern, und die geänderten Dateien dann quasi als "Mod" zur Verfügung stellen. Hier sind generell keine Grenzen gesetzt. Nachteil ist, dass mit nahezu jedem Update des Spiels die Mod inkompatibel wird (sofern die modifizierten Spieldateien vom Update betroffen sind). Außerdem muss für den Multiplayer jeder Spieler (sowie der Server) die gleiche Mod installiert haben. Mehrere Mods parallel zu benutzen ist auch immer etwas schwierig, vor allem, wenn die Mods die gleichen Spieldateien oder Stellen im Code verändern. Zudem ist das Erstellen einer Mod auch ziemlich kompliziert, da der dekompilierte Code schwer leserlich ist und über keinerlei Dokumentation verfügt
- Plugins hingegen verwenden die vom Spiel bereitgestellte API. Die API ist quasi eine Schnittstelle, die bestimmte Spielfunktionen nach außen trägt (und Plugins auch über versch. Ereignisse informiert, zB wenn ein Spieler Schaden bekommt usw) und über die die Plugins dann mit dem Spiel kommunizieren können. Vorteil ist, dass Plugins nach Spiel-Updates in den allermeisten Fällen kompatibel bleiben (es sei denn die API verändert sich). Auch reicht es im Multiplayer aus, wenn das Plugin auf dem Server installiert ist, da es ohnehin nur dort ausgeführt wird (und der Server sich um die Synchronisierung mit den Clients kümmert). Mehrere Plugins zu verwenden ist auch weit weniger problematisch als bei Mods, und Plugins zu erstellen ist - im Vergleich um Erstellen einer Mod - tausendmal einfacher, da die API einfach aufgebaut, öffentlich einsehbar und gut dokumentiert ist. Nachteil von Plugins ist, dass nur Dinge gemacht werden können, die die API auch bereitstellt. Derzeit erlaubt die API zB Custom Items einzubinden, aber zB noch keine Custom NPCs. Die API wird aber mit jedem Update umfangreicher und bietet mehr Freiheiten. Auch haben wir dafür die Sektion im Forum "API Wünsche" eingerichtet, in welcher Plugin-Entwickler auf fehlende API-Funktionen aufmerksam machen können
Modding (also klassisches Modding) war in RW schon immer möglich und wird auch immer möglich bleiben, aber hierfür sind fundierte Programmierkenntnisse, viel Zeit und Geduld sowie Nerven aus Stahl nötig. Daher ist unsere Priorität, die Plugin-API voranzutreiben.
Die neue Version ist zwar in C# und C++ geschrieben, aber für die Plugin-API werden wir weiterhin auf Java setzen. Wir haben uns zwar lange Gedanken dazu gemacht, aber Java bietet in diesem konkreten Fall mit Abstand die meisten Vorteile:
- Java ist schnell, also spürbar schneller als Skriptsprachen wie zB Lua. Zwar nicht ganz so schnell wie C++, aber mit einer C++-API hätten wir wohl die Büchse der Pandora geöffnet (einerseits ist der Umgang mit C++ schwieriger als mit Java, das würde vmtl. viele Leute abschrecken, andererseits können schon minimale Fehler in Plugins das Spiel zum crashen bringen - ohne, dass man herausfinden könnte, dass der Fehler von einem Plugin verursacht wurde)
- Java läuft quasi in einer eigenen Umgebung, d.h. wenn ein Plugin Amok läuft, wird nicht sofort das Spiel in Mitleidenschaft gezogen (*natürlich kann ein Plugin das Spiel trotzdem durcheinander bringen, aber zwischen Spiel und Plugins ist quasi ein sehr großer "Sicherheitspuffer")
- Die alte API kann weitestgehend übernommen werden und auch bestehende Plugins müssen nur minimal angepasst werden, damit sie mit der neuen Version kompatibel wird. Das gilt auch für die Dokumentation, die haben wir im Laufe der Zeit mit vielen Beispielen gefüllt, und es wäre doof, wenn man wieder bei 0 anfangen müsste
- Java ist als vollwertige Programmiersprache deutlich mächtiger als die meisten Skriptsprachen. Es gibt richtiges Multi-Threading (was allein für das Spiel enorm wichtig ist), richtiges I/O Handling, Netzwerkfunktionalitäten, und wenn man es wirklich Ernst meint auch die Möglichkeit, Java mit C++ bzw. nativen Libraries zu koppeln und mit ihnen zu kommunizieren
Über Java ist es grundsätzlich aber auch möglich, Skriptsprachen einzubinden. Wir haben damals begonnen, einen Lua-Wrapper als Plugin zu schreiben (damit wir Lua endlich hätten rauswerfen können, durch den Wrapper hätten Leute aber weiterhin Lua Skripte laden und benutzen können). Wenn man das benutzt fallen die Geschwindigkeitsvorteile natürlich wieder weg (denn die Skriptsprache wäre dann wieder der Flaschenhals), aber der Vorteil von Skriptsprachen ist natürlich, dass diese einfach zu bedienen sind
-
Thanks Celtic Hummingbird
On the water textures. Can you use the ones in the java version?
Well, basically water in RW isn't just a texture, instead it's a result of multiple render passes (to achieve the final look, including depth-based transparency, refractions, reflections etc)
We'll probably take a similar approach for the Unity version, but rendering works totally different there. In addition to that, shaders use a different language in Unity (HLSL [the DirectX shader language] instead of GLSL [the OpenGL shader language]), so we have to rewrite them from scratch anyway^^
