Posts by red51

Quote from Deirdre

Wenn es noch eine alte spielbare Java-Version gibt, dann wäre das Kopieren eigentlich nach dem Release noch jederzeit möglich oder?

Genau

Quote from Deirdre

Allerdings macht einmal geupgraded die alte Welt unspielbar oder geht ein Hin- und Her-Wechsel?

Wir werden dafür sorgen, dass neue und alte Welten nicht durchmischt werden. D.h. du könntest quasi die Version jederzeit wechseln, dann können die "Java Welten" mit der Java Version geladen werden und die "Unity Welten" mit der neuen Version.

Quote from TutMeistensNix

Schon wieder eine Änderung?

Meinst du das auf die API bezogen? Naja, als wir damals die Plugin API eingebaut haben, haben wir nicht geahnt, dass von einen Tag auf den nächsten unsere Verkäufe massiv einbrechen werden. 2018 lief sogar wesentlich besser als 2017 von den Verkäufen her, naja, bis Oktober zumindest.
Und der Wechsel auf die Plugin API war an sich eine richtige Entscheidung, zumindest hätten wir unter Lua niemals die gleiche Funktionalität gehabt - und die Anbindung Lua <-> Java ist äußerst suboptimal, aus Sicht der Performance.

Und ich muss zugeben, dass sowohl die Plugin API als auch die Lua API nicht ganz den Anklang gefunden haben, den ich ursprünglich erwartet hatte. Es ist sogar so, dass Leute eher verärgert waren, wenn sich ein Update in erster Linie auf eine der APIs bezogen hat. Entsprechend ist die API nicht der entscheidende Faktor beim Engine-Wechsel (wenngleich wir natürlich trotzdem die Plugin Entwickler nicht einfach so im Stich lassen werden).

Quote from TutMeistensNix

Wo von Lua auf Java gewechselt wurde wurde auch gesagt das Lua höchstens noch 1 Jahr läuft und alle haben sofort aufgehört Lua zu Programmieren.
Und, wie lange ist das her, bestimmt schon mehr wie ein Jahr...

Wo genau liegt da denn das Problem? Aus Sicht des Spielers ist das Vorhandensein der Lua API ja eigentlich nicht wirklich problematisch, da es das Spielgeschehen nicht beeinflusst. Es nervt lediglich mich, da der Source Code des Spiels dadurch unübersichtlich wird
Glaub mir, ich hätte Lua am liebsten schon längst rausgeworfen, aber wir wollten Lua nicht rausschmeißen solange es keinen AreaProtection Ersatz gibt.

Quote from TutMeistensNix

Bedeutet es auch das wir nun ca 1 Jahr keine Updates mehr auf das jetzige Spiel bekommen?

Wenn wir jetzt noch viel Zeit in die Java Version reinstecken, wird sich die neue Version nur verzögern (und effektiv ist diese Arbeit für die Katz, da dieses Feature dann ebenfalls in die neue Version eingebaut werden muss). Und dann wird es auch finanziell umso enger, da wir seit Oktober letzten Jahres rote Zahlen schreiben...
Ziel ist also, die neue Version so schnell wie möglich fertig zu bekommen. Wir arbeiten da jetzt zu zweit dran, aber es ist trotzdem ein riesen Berg Arbeit.

Quote from Deirdre

Warum nicht schon vor 3 Jahren auf Unity umgestiegen wurde, haben wir uns damals schon gefragt. Aber wie sagt man so schön: Besser spät als nie.

Das war tatsächlich etwas schwieriger. Damals hatte Unity einige gravierende Einschränkungen, die für ein Spiel wie RW äußerst problematisch sind. Rising World hätten wir damals mit Unity so in der Form nicht umsetzen können (nur mit vielen Abstrichen). Einige Einschränkungen gibt es leider auch heute noch, das kann aber mittlerweile mehr oder weniger in Kauf genommen werden (oder sagen wir es so: mittlerweile überwiegend die Vorteile die Nachteile). Und Unity entwickelt sich in letzter Zeit absolut in die richtige Richtung.

Quote from Bogus

Vielleicht sollten wir dann gleich anfangen eine WikiSeite zu erstellen *gg

Da triffst du tatsächlich einen wunden Punkt Vielleicht werden wir uns bei der neuen Version einfach an sowas wie Gamepedia orientieren.

Quote from lenko

Bestimmt kommen noch viele Fragen wie von @Devidian wegen der Plug-in oder auch was die Blaupausen angeht, bezw die Frage der bestehenden Texturen.

Ja, davon gehe ich aus, aber das ist ja auch nachvollziehbar Wir werden bestimmt in einigen Monaten mehr zur Plugin API sagen können.

Was die Texturen angeht: Die werden wir vmtl. alle überarbeiten müssen, da wir einen PBR orientierten Ansatz wählen wollen (das lässt die Texturen realistischer aussehen und verschafft ihnen mehr Tiefe, ist allerdings nicht so richtig kompatibel mit unseren bisherigen Texturen). Aber auch hierzu schreiben wir in Zukunft nochmal was. Wir werden definitiv bemüht sein, dass wir zumindest ähnliche Texturen haben werden (damit auch Blueprints nicht komplett durcheinander sein werden).

Quote from lenko

@red51 können wir euch als Community den irgendwie helfen ???

Schwer zu sagen... erstmal vielen Dank für die Unterstützung, aber erstmal fällt mir nichts unmittelbar ein. Wichtig ist, dass jetzt nicht alle Spieler aufhören RW zu spielen und es in die Ecke stellen, das wäre zumindest sehr schade. Ich möchte auch nochmal betonen, dass man auch ruhig an bestehenden Welten weiterarbeiten kann oder auch jetzt neue Welten erstellen kann, selbst wenn sie nicht mehr kompatibel bleiben. Bis die neue Version wirklich 100% einsatzfähig ist, dauerts ja immerhin noch ein wenig

Quote from Kassa

Ich denke mal die Leute brauchen einfach Action und schöne Grafik

Das denke ich auch. Die Grafik spielt einfach eine große Rolle, und gerade auf Screenshots oder in Trailern ist die Grafik mit eines der einzigen Argumente für oder gegen ein Spiel. Die jetzige Grafik scheint auf jeden Fall schon so einige Leute abzuschrecken (immerhin ist das ein sehr häufiger Grund, der bei Refunds angegeben wird).

Thank you very much for your feedback and support!

Quote from Avanar

If i understand right, in more or less 1 year we will have a rising world that will look like THAT, has a new world generation and several other reworked features?

Yes, that's our plan

Quote from Avanar

How are current plugins compatible?

Unfortunately I can't say much about that yet, since we're not sure about the new plugin API. In case the new plugin API uses a different language than Java, we're still planning to have some sort of wrapper for the old Java plugins. In this case servers have to install a JVM in order to use these plugins.
We've prepared something similar for the Lua scripts btw (so we could finally remove the Lua API), but never released it due to these upcoming changes^^

Quote from agiser

Good news but I guess it will no longer get updates

What do you mean exactly with "no longer gets updates"? Do you mean the current Java version? It's true that we're unfortunately no longer adding new features to it, since we really want to get the new version ready ASAP. But we're still going to release bugfixes and smaller changes for the Java version, unfortunately we have no ETA for the next update...

Quote from Lyandreth

If, as you say, we can still use our blueprints from our existing worlds though, I, for one, am more than happy.

Yes, we try our best to keep old blueprints compatible with the new version

Quote from joni909

with unity you can also test Vulkan API and such and VR and even both

That's true, VR will be much easier to implement (same about things like controller support, for example). We will also offer support for Vulkan.

Quote from joni909

I think you could always opensource or semi-opensource the old one too

It's something we take into consideration, although we're not quite sure about this. But if we make the Java version open source, it will only happen once the new version is ready

Quote from EvilNightWish

but Im a Linux user, and I hear what you say that it'll be multiplatform. but will you guys have us Linux users in mind, when putting the new engine in?

We definitely have Linux in mind Linux will be a main priority for the dedicated server, for example, so it's still fairly important for us. Although we're not 100% sure if we're still going to support OpenGL. The main API on Linux will be Vulkan, but that's not supported by old hardware, for example. Maybe we have to start a poll to get feedback about this (i.e. to find out how many Linux users would be affected if we really discard OpenGL).

Quote from EvilNightWish

Unity is still in a beta fase for Linux

AFAIK this only affects the Unity Editor, so this wouldn't matter for the final game

Quote from ArcticuKitsu

Has me wondering though if the player characters can be swappable now when using Unity [...] Being able to swap both player & NPC characters to use external models to be imported..... The MMD models, the .pmx files constantly giving us troubles... Yeah, those. If Rising World is using Unity then that should hopefully be possible in the future

It's definitely getting easier when it comes to importing/exporting models, especially when it comes to FBX models. Being able to replace player or npcs characters was originally planned for the API anyway, but since it required a lot of changes "under the hood", we will keep this in mind now when migrating to the new engine Can't say much about MMD files unfortunately, AFAIK Unity does not support this format, but it should be easy to convert these models to FBX (and Unity has great support for FBX).

Quote from ArcticuKitsu

Also, it shall be interesting seeing how terrain shall appear now. Hopefully mountains shall be more like mountains, and less like spiky daggers. Will we get our true world generation in this Unity version?

Yes, we're writing a completely new world generation algorithm. This affects biomes, mountains and caves. We will no longer see the unrealistic, steep mountain spikes in the new version

Quote from ArcticuKitsu

Shall be interesting to see what happens with VR now that you're using Unity. Maybe we can see some attempts at VR, even on the slightest (when the time is right). No rush.

Oh yes, VR is definitely much easier to implement with Unity. While it's still a low priority (our main focus is to get the new version ready as soon as possible), it's something that's on our todo-list (at least as a beta branch in Steam or something like that)

Quote from Redeye

Just hoping blue prints will work

It's really a high priority for us to keep old blueprints compatible

Quote from Redeye

question is this the same platform RUST runs on? I left Rust because of all the hackers. Is this new platform going to open up RW to a bunch of hackers?

Yes, it's the same engine. However, all important "decisions" regarding the gameplay are made by the server, so the server never trusts the clients (at least when it comes to important stuff - for example, a hacker can't just spawn an item to his inventory, since inventories are managed by the server). In addition to that, we're going to use IL2CPP, which compiles the game to C++, and therefore it's much harder to decompile and to modify.

Vielen Dank für das Feedback sowie die positiven und unterstützenden Worte

Quote from Kassa

Was wird dann aus der Java Version, wird die vielleicht Open-Source nach Unity Release?

Das wäre vielleicht eine Option, kann aber leider noch nicht viel dazu sagen. Wenn dann würde das natürlich in erster Linie in Frage kommen, sobald die neue Version fertig ist und die Java Version vollständig abgelöst hat

Quote from Devidian

der Ansatz mit unity ist sicher auch gut (Empyrion und 7 Days nutzen sie ja z.b. auch) aber ich hoffe das das Spiel nicht an tiefe verliert dadurch.

Also die "Einschränkungen" in den genannten Spielen ist in erster Linie eine Designentscheidung der Entwickler gewesen, d.h. von Unity gibts da nicht unbedingt Einschränkungen, die bspw. die maximale Welttiefe limitieren oder die Größe von Terrain-Blöcken. Tatsächlich hatte Unity vor wenigen Jahren noch Einschränkungen, die sich sehr negativ auf derartige Spiele ausgewirkt haben, das wird sicherlich für die genannten Spiele eine Rolle gespielt haben.
Aber wir werden den Detailgrad des Terrains beibehalten, und auch an der Gesamttiefe werden wir zumindest keine gravierenden Änderungen vornehmen. Wir haben jedoch darüber nachgedacht, evtl. die maximale Tiefe zu reduzieren, um nach oben hin mehr Raum zu bieten. Aber auch in dem Fall würde die Welt von der Tiefe her mindestens bis -500 gehen oder so

Quote from Devidian

Du hast in den FAQ geschrieben das versucht wird die aktuellen Plugins kompatibel zu halten, meines Wissens ist aber Unity C# und nicht Java, das müßte man dann konvertieren

Es geht zwar damit der Performancevorteil verloren, nämlich dass Plugins in derselben Sprache wie das Spiel geschrieben sind und daher kein Wrapper oder irgendwelche Konvertierungen nötig sind, aber wir müssten uns eh wieder eine eine Sprache festlegen (auch wenn diese Sprachänderungen bei unseren API's langsam witzlos werden). Ironisch wäre, wenn wir zu Lua zurückkehren. Vielleicht bleiben wir aber sogar bei Java.
C# können wir für die Plugin API nicht direkt verwenden, da wir IL2CPP verwenden werden, wodurch der finale Code in C++ umgewandelt wird.

Aber bei der Kompatibilität beziehen wir uns tatsächlich auf die Java-Plugins. Falls Java nicht mehr die Sprache für unsere die neue API sein wird, wäre in dem Fall zwar nötig, dass der Server eine JVM installieren müsste, aber damit blieben alte Plugins ohne Änderung lauffähig. Wir haben an etwas Ähnlichem für die Lua Scripte gearbeitet, was allerdings aufgrund der Änderungen hinfällig geworden ist. Versprechen können wir das aber leider nicht

Quote from Devidian

Werdet ihr rechtzeitig mit den aktiven Plugin-Entwicklern zusammen arbeiten um daran zu arbeiten, oder werden wir am Ende vor vollendete Tatsachen gestellt ?

Definitiv! Sobald der Kurs hinsichtlich der Plugins und der API feststeht, werden wir das mitteilen. Wir werden versuchen, die Plugin-Entwickler so gut es geht in diese Sache einzubinden. Wir werden die Plugin-Entwickler definitiv nicht einfach im Regen stehen lassen.

Quote from Devidian

Ich hatte noch einige Pläne mit weiteren Plugins und meinen bestehenden, ich frage mich aber jetzt ob es sich lohnt noch Zeit zu investieren wenn ich diese eh komplett neu schreiben muss oder sie ggf. auch überflüssig werden.

Das ist schwer zu sagen. Also grundsätzlich wird die Java Version ja noch ca. 1 Jahr lang die "Hauptversion" bleiben (auch wenn es bis dahin schon was Spielbares der neuen Version gibt), d.h. hier könnten Plugins auf alle Fälle noch zur Geltung kommen. Danach wird die Java Version zwar auch weiterhin verfügbar sein, aber wie es dann mit der API bei der neuen Version weitergeht kann ich nicht sagen.

Quote from Devidian

- 7 Days hat zum Beispiel eine Terrain-Physik - also keine schwebenden Blöcke, ist sowas dann auch für RW geplant?

Mehr Rückmeldung von der Physik-Engine wäre auf jeden Fall wünschenswert, und bei Unity haben wir tatsächlich eine wesentlich mächtigere Physik-Engine (wenngleich Terrain-Physik nur bedingt damit zusammenhängt). Ich kann noch nicht viel dazu sagen, so eine Implementierung wäre aber eh weitgehend unabhängig vom Engine-Wechsel

Quote from Devidian

- Bevor die neue Version in den Public test geht, wird es ein Alpha-Test Team geben? Wenn ja wo kann man sich bewerben? Fehler finden ist meine Lieblingsbeschäftigung

Also sobald die erste spielbare Version fertig ist, werden wir sie als Beta in Steam öffentlich zugänglich machen Die erste spielbare Version wird eh noch sehr eingeschränkt bleiben und noch keinen Ersatz für das jetzige Spiel bieten, aber jeder könnte sich das einmal anschauen um einen Eindruck davon zu gewinnen (und Feedback zu geben sowie Bugs aufspüren)

@Alex74: The amount of used memory highly depends on the amount of buildings and custom images in your world (and plugins also have an impact on that, especially if they add custom models). According to the log file, you've already assigned 8 GB to the game, although the game cannot use that much RAM anyway (since your system only has 8 GB), so there is unfortunately no room for further optimizations
What sort of "lag" do you experience exactly? Is the overall framerate low, or do you experience stutter/freezes? Do you play in singleplayer or multiplayer?

Quote from Brandon_lee19

Is there any free decompiler software that you can recommend?

For Java, you could use JD-GUI or Luyten

Dear Community!

It's about time to let you know what's currently going on, and what the future of Rising World will probably look like. Sorry for the wall of text!

Some of you may remember that we mentioned some traffic changes on Steam last October. Valve changed the algorithm that decides which games are promoted and which are not. There aren't many details known about how the algorithm works exactly, but it seems that the algorithm is mostly favoring top-sellers now - there are lots of other serious indie developers out there who were negatively affected by the algorithm change.

We lost a lot of our visibility "over night" and therefore our game sells a lot worse than before. Of course it's up to Valve to decide what's best for the store, but this change makes it much harder for us to survive - especially in combination with the introduction of Steam Direct in 2017.
The development of Rising World is not about making money, but of course we have running costs and have to pay bills just like everyone else. We will never abandon Rising World, no matter what happens, but if we're having trouble covering the costs, this will inevitable slow down development - to a point that becomes unacceptable. But even if we somehow make it to the 1.0, it would be a pity if the journey ends at this point (since there is still so much unused potential in this game).

It couldn't go on like this, so we had to find the best solution for the community and the game.

To cut a long story short, we decided to move Rising World to another engine. This allows us to bring Rising World to a new level (from a technological point of view). Graphics isn't everything, but it still plays a big role when it comes to the first impression of the game. But moving to a new engine also allows us to release the game on more platforms - for example consoles. Of course the PC will still be our main platform, but being able to bring the game to consoles (or maybe even something like Stadia) could ensure the future of the game.

We are sure that the vast majority of players will benefit from this measure in the end, since the result will be a much more polished game. The bad news is, that moving to another engine means a rewrite of the game. This sounds worse than it actually is, though. When implementing a new feature, most of the time is spent on the conceptual design - and there is no need to redo that now in this case. The actual implementation, i.e. the "programming part" is in fact the smallest part.

But apart from that there are several "core mechanics" that had to be reworked anyway, for example the world generation. It makes sense to use this opportunity to do that now.

Nevertheless, it will still take some time until the "new version" is ready. In order to speed things up, we have a new fulltime dev now (so we're two people focusing on the programming/implementation part). This wasn't really an option before, since the game already consists of more than 250k lines of code, and getting used to it would take a lot of time.
I'm still afraid that it will take up to 1 year until the current version of the game can be fully replaced by the new version (but at this stage, it will already feature the reworked core mechanics). But once we have a playable version, we will make it accessible (as "Beta" in Steam) - we're confident that this still happens this year.

We already have some preview screenshots we want to share with you. Please keep in mind that these are some very early screenshots, but they give at least a rough idea how the game could look like in the future:

Just to avoid any misunderstandings: If you already own the game, there is of course no need to buy it again. Once the new version is ready, it will replace the current version and you will be able to access it.
However, the Java version will still be available (as well as the according server files). Once the new version replaces the current one, the Java version will be moved to a separate Beta branch in Steam which will always be accessible (it will also be available for standalone owners). So if you don't like the changes and want to stick to the old version, that will be possible. We are still going to provide bugfixes for the Java version.

If you have any questions, suggestions, or if you think that it's a bad idea to move to a new engine, please let us know Either leave a comment here, or create a new post in the forums.

We've set up a small FAQ by the way which provides some more information: https://forum.rising-world.net/thread/10171

As explained in our recent announcement, we're going to move Rising World to a new engine. Here you find some related questions & answers and more information about this change.

Which engine are you planning to use?

We're migrating to the Unity Engine. This engine made a lot of progress in the past years and became powerful recently. And it's quite customizable. In addition to that, it was a requirement for us that the new engine has support for as many platforms as possible, and in this regard, the most obvious choices are Unreal and Unity.

Why not Unreal Engine?

Originally we wanted to move to the Unreal Engine (because it looks very promising), but back then it was missing one important feature which is crucial for Rising World: Texture Arrays. At first we took the approach to change the source code of the Unreal Engine and implement Texture Array support, but maintaining a customized version of such a "huge" engine (especially keeping it up-to-date) can be quite time consuming (especially when targeting multiple platforms) and we could run into unforseeable issues in the future.

Does that mean Rising World turns into an Asset Flip?

No, definitely not. One advantage of Unity is its versatility. We will stick to our approach to implement all relevant features on our own, while we can still benefit from the powerful rendering pipeline, physics and tools of the Unity Engine.

What are the advantages of this change?

Moving to a new engine allows us to provide better graphics, better lighting (including proper shadows) and a better physics engine compared to the current one. We have more control over the animations and we will be able to put a bigger focus on many small details (e.g particle effects like smoke affected by physics/collisions etc).
And since we're rewriting the game, we can finally focus on so many changes that were put on the back burner in the past, i.e. changes that required a rework of certain mechanics anyway (e.g. improved world generation, better networking, better UI etc).

Another advantage is that we can now switch the graphics API to DirectX, Vulkan and Metal. OpenGL is a great API, but we're often facing driver issues and incompatibilities (especially when it comes to older graphics cards).

What happens to the Java version?

Once the new version is ready, we will move the current Java version to a separate beta branch in Steam, so it will still be available (as well as the according server files). It's our intention to provide at least bugfixes for the Java version.

What about old worlds? Will they still be compatible?

We're currently implementing a completely new world generation algorithm from scratch, unfortunately it will not be compatible with old worlds (but of course you can still play old worlds with the Java version).

However, it's our goal to keep blueprints compatible with the new version, so you can create at least blueprints of your important buildings and use them in the new version.

It will take some time until the new version is ready, so there is definitely no need to stop playing now.

Will Mac and Linux still be supported?

Yes! However, we're going to drop OpenGL support. On Mac, we will use the Metal API instead, and on Linux, we're going to switch to Vulkan. As a result, you need a Vulkan-compatible graphics card when using Linux, and on Mac, you need at least MacOS 10.13

What about the hardware specs? Can I still run the game?

Better graphics of course leads to higher system requirements. However, if your computer meets the current minimum requirements of the game (as stated on our storepage), you should still be able to play the new version of the game.

But one thing that changes significantly is the file size of the game. This means that you will need more hard disk space.

What happens to the Plugin API?

We will still use Java for the new API. In fact most parts of the current API stay compatible, but there will be some smaller changes - this means existing plugins need to be updated for the new version.
We will provide more information about the new Plugin API and the changes in the near future.

Liebe Community!

Es ist an der Zeit euch mitzuteilen, was momentan los ist und wie die Zukunft von Rising World wahrscheinlich aussehen wird. Sorry für diese lange Textwand!

Einige von euch erinnern sich sicherlich, dass wir Traffic Änderungen auf Steam letzten Oktober erwähnt haben. Valve hat den Algorithmus geändert, welcher entscheidet, welche Spiele präsentiert werden und welche nicht. Es sind nicht viele Details darüber bekannt, wie der Algorithmus genau funktioniert, aber es scheint so, als würde er jetzt überwiegend Top-Seller präsentieren - es gibt viele andere ernsthafte Indie-Entwickler da draußen, die negativ durch die Algorithmus-Änderung betroffen sind.

Wir haben einen Großteil unserer "Sichtbarkeit" im Store quasi über Nacht verloren und entsprechend verkauft sich das Spiel nun wesentlich schlechter als vorher. Natürlich muss Valve entscheiden, was am besten für den Store ist, aber durch diese Änderung wird es wesentlich schwerer zu überleben - vor allem in Verbindung mit der Einführung von Steam Direct 2017.
Bei der Entwicklung von Rising World geht es nicht nur ums Geld, aber wir haben natürlich auch laufende Kosten und müssen wie jeder andere auch Rechnungen bezahlen. Wir werden Rising World niemals aufgeben, egal was passiert, aber wenn wir Schwierigkeiten haben, die Kosten zu decken, dann wird das unweigerlich die Entwicklung verlangsamen - bis zu einem Punkt, der inakzeptabel wird. Aber auch wenn wir es noch irgendwie bis zur 1.0 schaffen, wäre es sehr schade, wenn die Reise an dieser Stelle enden würde (da in dem Spiel noch so viel ungenutztes Potenzial steckt).

So konnte es nicht weitergehen, also mussten wir die bestmögliche Lösung für die Community und das Spiel finden.

Um es kurz zu machen, wir haben uns dazu entschlossen, Rising World auf eine andere Engine zu portieren. Das ermöglicht uns, Rising World auf ein neues Level zu bringen (aus technologischer Sicht). Grafik ist nicht alles, aber sie spielt dennoch eine große Rolle wenn es um den Ersteindruck des Spiels geht. Aber indem wir die Engine wechseln, sind wir auch in der Lage, das Spiel auf mehr Plattformen anzubieten - zum Beispiel Konsolen. Natürlich wird der PC weiterhin unsere Hauptplattform bleiben, aber in der Lage zu sein, das Spiel zu Konsolen zu bringen (oder vielleicht zu etwas wie Stadia) könnte die Zukunft des Spiels sichern.

Wir sind uns sicher, dass die große Mehrheit der Spieler von dieser Maßnahme letztenendes profitieren wird, da das Resultat ein wesentlich aufpolierteres Spiel sein wird. Die schlechte Nachricht ist, dass der Engine-Wechsel bedeutet, dass wir das Spiel neu schreiben müssen. Das hört sich allerdings schlimmer an, als es eigentlich ist. Wenn wir ein neues Feature implementieren, dann geht der Großteil der Zeit für die Konzeptionierung drauf - und das muss in dem Fall ja nicht nochmal gemacht werden. Die eigentliche Umsetzung, also der "Programmierteil", ist tatsächlich der kleinste Teil.

Abgesehen davon gibt es mehrere Kernmechaniken im Spiel, die ohnehin überarbeitet werden müssten, zum Beispiel die Weltgenerierung. Es macht natürlich Sinn, diese Gelegenheit jetzt zu nutzen.

Nichtsdestotrotz wird es etwas dauern, bis die "neue Version" fertig sein wird. Um die Dinge zu beschleunigen, haben wir nun einen neuen Vollzeit-Entwickler (sodass wir nun zwei Personen sind, die sich um die Programmierung/Implementierung kümmern). Das war vorher nicht wirklich eine Option, da das Spiel bereits aus mehr als 250k Codezeilen bestand, und die Einarbeitung sehr lange gedauert hätte.
Ich fürchte dennoch, dass es bis zu 1 Jahr dauern wird bis die aktuelle Version vollständig durch die neue Version ersetzt werden kann (aber dann wird sie bereits die überarbeiteten Kern-Mechaniken bieten).
Doch sobald wir eine spielbare Version haben, werden wir diese als "Beta" in Steam verfügbar machen - wir sind zuversichtlich, dass das dieses Jahr geschehen wird.

Wir haben bereits ein paar Vorschau Screenshots der neuen Version, die wir euch nicht vorenthalten möchten. Bitte bedenkt, dass dies sehr frühe Screenshots sind, aber sie geben zumindest einen groben Eindruck darüber, wie das Spiel ungefähr aussehen wird:

Um Missverständnisse zu vermeiden: Wenn du das Spiel bereits besitzt, musst du es selbstverständlich nicht nochmal kaufen. Sobald die neue Version fertig ist, wird sie die jetztige Version ersetzen und du kannst direkt darauf zugreifen.
Die jetzige Java Version wird trotzdem verfügbar bleiben (ebenso die zugehörigen Server Dateien). Sobald die neue Version die jetzige ersetzt, werden wir die Java Version in einen separaten Beta Branch in Steam verschieben (welcher auch für die Standalone zugänglich sein wird), welcher immer verfügbar sein wird. Falls du also von den Änderungen nicht überzeugt bist und lieber bei der alten Version bleiben möchtest, wird das definitiv möglich sein. Wir werden für die Java-Version weiterhin Bugfixes anbieten.

Falls du Fragen oder Vorschläge hast, oder wenn du denkst, dass es eine schlechte Idee ist, zu einer neuen Engine zu wechseln, lass es uns bitte wissen Schreib einfach einen Kommentar, oder erstelle einen neuen Beitrag in unserem Forum.

Wir haben übrigens ein kleines FAQ aufgesetzt, welches ein paar weitere Informationen bieten wird: https://forum.rising-world.net/thread/10169

Wie in unserer letzten Ankündigung erläutert, werden wir Rising World zu einer neuen Engine portieren. Hier finden sich einige zugehörige Fragen und Antworten sowie weitere Informationen zu dieser Änderung.

Welche Engine werdet ihr benutzen?

Wir werden zur Unity Engine wechseln. Diese Engine hat in den letzten Jahren viele Fortschritte gemacht und wurde in letzter Zeit recht mächtig. Und sie kann durchaus angepasst werden. Abgesehen davon war es für uns eine Bedingung, dass die neue Engine so viele Plattformen wie möglich unterstützt, und in dieser Hinsicht sind die offensichtlichen Kandidaten Unreal und Unity.

Warum nicht die Unreal Engine?

Ursprünglich wollten wir sogar die Unreal Engine verwenden (da sie sehr vielversprechend aussieht), doch zum damaligen Zeitpunkt fehlte ein wichtiges Feature, welches für Rising World unabdingbar ist: Texture Arrays. Anfangs wollten wir noch den Ansatz wählen, den Source Code der Unreal Engine zu ändern und selber Texture Array Support integrieren, aber eine angepasste Version der Engine zu pflegen und aktuell zu halten kann durchaus Zeitintensiv werden (besonders wenn man mehrere Plattformen anpeilen möchte), und es könnten unerwartete Probleme in der Zukunft auftreten.

Heißt das, dass Rising World ein Asset Flip wird?

Nein, ganz sicher nicht. Wir werden bei unserem Ansatz bleiben, alle relevanten Features selbst zu implementieren, während wir dennoch von der mächtigen Rendering-Pipeline, der Physik und den Werkzeugen der Unity Engine profitieren können.

Was sind die Vorteile des Wechsels?

Indem wir zu einer neuen Engine wechseln werden wir in der Lage sein, bessere Grafik, bessere Beleuchtungseffekte (einschließlich vernünftiger Schatten) und eine bessere Physik-Engine (im Vergleich zur jetzigen) zu bieten. Wir werden mehr Kontrolle über die Animationen haben und wir können mehr Augenmerk auf viele kleine Details legen (zB Partikel-Effekte wie Rauch, die durch die Physik bzw. Kollisionen beeinflusst werden etc).
Und da wir das Spiel neu schreiben, können wir uns endlich auf Dinge konzentreiren, die in der Vergangenheit auf die lange Bank geschoben wurden, d.h. Änderungen, die ohnehin eine Überarbeitung bestehender Mechaniken benötigten (zB eine verbesserte Welt Generierung, besseres Netzwerksystem, bessere UI etc).

Ein weiterer Vorteil ist, dass wir bei der Grafik-API nun zu DirectX, Vulkan und Metal wechseln können. OpenGL ist eine großartige API, aber wir sahen uns in der Vergangenheit häufig mit Treiberproblemen und Inkompatibilitäten konfrontiert (besonders wenn es um ältere Grafikkarten geht).

Was passiert mit der Java-Version?

Sobald die neue Version fertig ist, werden wir die Java-Version in einen separaten Beta Branch auf Steam verschieben, d.h. sie wird weiterhin verfügbar bleiben (ebenso die dazugehörigen Server Dateien). Es ist unsere Absicht, zumindest Bugfixes für die Java-Version anzubieten.

Was ist mit alten Welten? Werden sie kompatibel bleiben?

Wir arbeiten momentan an einer von Grund auf neuen Welt-Generierung, leider wird diese mit alten Welten nicht kompatibel sein (aber natürlich können diese weiterhin mit der Java-Version gespielt werden).

Dennoch ist es unser Ziel, Blueprints mit der neuen Version kompatibel zu halten, sodass man zumindest seine wichtigen Bauten sichern und in die neue Version übertragen kann

Es wird noch etwas dauern, bis die neue Version fertig ist, also gibt es absolut keinen Grund, jetzt aufzuhören, zu spielen.

Werden Mac und Linux weiterhin unterstützt?

Ja! Allerdings werden wir OpenGL nicht länger supporten. Auf Mac werden wir stattdessen die Metal API verwenden und auf Linux Vulkan. Das bedeutet gleichzeitig, dass unter Linux eine Vulkan-kompatible Grafikkarte benötigt wird, und unter Mac wird mindestens MacOS 10.13 benötigt.

Was ist mit den Hardwareanforderungen? Läuft das Spiel noch auf meinem Rechner?

Bessere Grafik führt natürlich zu höheren Systemanforderungen. Wenn dein Computer aber die derzeitigen Mindestanforderungen des Spiels erfüllt, dann wird es auch möglich sein, die neue Version des Spiels zu spielen.

Doch eine Sache, die sich auf jeden Fall signifikant ändern wird, ist die Dateigröße des Spiels. Das heißt, dass wahrscheinlich mehr freier Festplattenspeicher benötigt wird.

Was passiert mit der Plugin API?

Wir werden weiterhin Java für die neue Plugin API verwenden. Tatsächlich werden weite Teile der alten API kompatibel bleiben, allerdings mit einigen kleineren Änderungen - d.h. bestehende Plugins müssen auf jeden Fall für die neue Version geupdated werden.

Wir werden in naher Zukunft mehr Informationen zur neuen Plugin API sowie den kommenden Änderungen posten.

Ja, leider benötigen alle unsere Tools die JVM Also Server, Rcon, WorldConverter etc. Die sind nämlich meist nur wenige MB groß, hier hätte es sich nicht angeboten, nochmal eine 200MB JVM mitzuliefern.

The proper "Steam way" would be indeed workshop support for blueprints. That's probably the best solution for this. Basically that's planned, but unfortunately I have no ETA for that yet...

Having a separate forum there would only work if the majority of people are willing to post their blueprints both on Steam and here. I'm not sure if that's really going to happen

Quote from Brandon_lee19

I guess source codes that require editing to make mods perhaps?

The source code is indeed only available to us. If this was an open source project, the source code would be accessible for everyone (but then there'd be no point in selling the game)

However, the code can still be decompiled. You're allowed to do that for modding purposes, but the code is partly obfuscated, so doing any changes is possible though, but quite complicated.

Quote from Brandon_lee19

I'm just curious, If I were, say to make a plugin to make Glass Planks and Beams, how would I do so?

That's a little bit tricky, but you could spawn a glass pane in the inventory and then execute the size command with the Player.executeConsoleCommand() method

Quote from Bad Bee

Kann man den Bäumen nicht beibringen nur unter bestimmten Bedingungen zu wachsen? Als Beispiel, sie müssen mindesten in jede Richtung einen Block Erde/Sand etc. um sich herum haben (2x2 oder 3x3 Blöcke) sonst wachsen sie nicht? Oder sie wachsen nicht wenn sie nur in einem einzelnen Block stehen oder müssen nach dem setzten mindestens 1x mit Wasser versorgt werden, so ähnlich wie bei der Papierherstellung?

Das ist an sich langfristig geplant, also dass Pflanzen generell nur unter bestimmten Bedingungen wachsen (genügend Licht, Wasser etc). Ich weiß allerdings nicht, ob das in jedem Fall insoweit verlässlich ist, dass nicht doch plötzlich eine Pflanze im Innenraum anfängt zu wachsen (weil zB das Wasser in der Badewanne nahe genug ist, und auch das Licht brennt)

Ein "Anti-Wachstums-Elixier", wie @Smoka vorschlägt, wäre da vielleicht eine gute Möglichkeit, um das ganze von der Spiellogik her (nach welcher das Spiel am besten ohne Konsolenbefehle auskommen sollte) halbwegs plausibel rüberzubringen. Mit dem nächsten Update kommt aber zumindest als vorläufige Lösung erstmal der oben angesprochene Konsolenbefehl

Grundsätzlich sind Portfreigaben unter DS-Lite tatsächlich nicht möglich, da kein richtiges IPv4. Hier gibts leider keine wirkliche Chance, von außen über die IPv4 zuzugreifen (da nunmal keine richtige IPv4 vorhanden ist)

Manche anderen Spiele (zB 7d2d) verwenden optional für den dedicated Server das Networking von Steam, in dem Fall wird der Netzwerktraffic von Steam gehandled. Das kostet Performance, aber funktioniert dafür auch bei DS-Lite (und auch sonst wenn kein normales Routing möglich wäre, zB wenn man sich generell hinter einem NAT befindet), da der Traffic über die Steam Server läuft.

Da Rising World kein reines Steam Spiel ist, können wir sowas leider nicht anbieten In dem Fall wäre es sonst nicht möglich, dass Standalone-User mit Steam-Usern zusammenspielen könnten

AFAIK bietet Unitymedia aber seit einiger Zeit seinen Kunden auf Wunsch auch richtiges Dual-Stack an (also mit richtiger IPv4), ich weiß nicht, wie es bei anderen Kabelanbietern in der Hinsicht so aussieht...

Quote from Joerg-nbg

Es gab eine Zeit, da war viel angekündigt, was das Spiel alles können soll, wenn es fertig ist. Von Technick, Elektrik ect... war auf der Homepage die Rede. War gerade auf der Homepage, da ist davon nichts mehr zu finden

Meine Güte... Wir haben damals eine "abgespeckte" Roadmap auf unserer Homepage angeboten, welche einen groben Überblick über die geplanten Features geben sollte. Der Direktlink funktioniert noch, und auch über die Wayback-Machine ist der Link immernoch aufrufbar (hier von Anfang 2015): https://web.archive.org/web/20…e/page/more/features.html

Da diese Liste aber irgendwann überholt und nicht mehr aktuell war, haben wir sie entfernt und stattdessen über den gleichen Link (wenn man also auf unserer Homepage auf "Features" geht) diese Seite eingerichtet: https://steamcommunity.com/app…ns/0/3559414588270238365/

Diese Seite enthält eigentlich einen korrekteren Ausblick auf die geplanten Features, aber auch hier ist nichts in Stein gemeißelt

Quote from Joerg-nbg

Da war es noch als Early Access-Spiel angeboten. Hab gar nicht mitbekommen, wann es diesen staus verlassen hat. Die Leute die es damals unter diesen Versprechungen von vielen Jahren (2014) gekauft haben, sind zu Recht enttäuscht

Das Spiel ist immernoch im Early Access, d.h. es ist nicht fertig. Abgesehen davon, dass eine Roadmap nicht zwangsläufig etwas mit "Versprechen" zutun hat, sind eigentlich alle dieser damals angedachten Features weiterhin geplant.

Quote from Joerg-nbg

von dem was damals versprochen wurde, sind wir weit entfernt.

Auch wenn die alte Liste wirklich unvollständig und zu Recht nicht mehr regulär über die Webseite aufrufbar ist, so sind mittlerweile die meisten der damaligen Features sogar umgesetzt. Die wohl prominentesten Features, die laut dieser Liste noch fehlen, sind Züge, fließendes Wasser, und das Stromsystem. Allerdings würde ich Spieleentwicklung nur ungerne so in schwarz und weiß unterteilen.

Wir haben im Laufe der Zeit viele Dinge umgesetzt, die auf der Liste nicht aufgeführt waren. Und wenn sich die Community mehrheitlich für oder gegen ein Feature ausspricht, dann versuchen wir das zu berücksichtigen.

Unfortunately you cannot replace regular construction textures with a transparent glass texture, since regular blocks and planks do not support transparency. However, of course you can replace the textures of glass panes (as well as the according normal map, which is used for the refraction effect)

Quote from Brandon_lee19

Is there a source code of some kind that is only available to the Developers? Someone on discord said that there is a source code,

What do you mean exactly with "source code" in this particular case?

Ich kann den Fehler reproduzieren. Er scheint i.V.m. Blöcken aufzutreten, sobald sie gedreht werden - aber auch hier nur unter ganz bestimmten Umständen (und offenbar auch nur bei größeren Bauten, die aus Blöcken bestehen). Das scheint ein Fehler zu sein, der wie es scheint schon von Anfang an drin ist Ich habe dafür leider keine unmittelbare Lösung parat, d.h. das würde frühestens mit dem nächsten Update behoben

Grundsätzlich hat die auf dem System installierte JRE keinen wirklichen Einfluss auf die Sicherheit (denn hier spielen potenzielle Sicherheitslücken keine Rolle, da ein Programm, welches auf deinem System ausgeführt wird, keine Sicherheitslücken braucht, um Schaden anzurichten). Sicherheitsbedenken gibt es eher beim Java Browser-Plugin, allerdings sollte das heutzutage eh nicht mehr verwendet werden (und ist standardmäßig in den meisten Browsern deaktiviert).

Rising World verwendet Java 8, allerdings muss für die Steam-Version kein Java auf deinem System installiert sein, denn RW bringt seine eigene JVM mit. Solange du nicht die Standalone oder einen RW Server auf deinem PC ausführst, kannst du also jede beliebige Java-Version installieren (oder Java ganz deinstallieren).

Falls du unabhängig davon Java installieren oder updaten willst, solltest du grundsätzlich die 64 Bit Version installieren, da du ein 64 Bit Betriebssystem hast. Die neueste Version 8 findest du hier: https://www.java.com/de/download/manual.jsp (siehe "Windows Offline (64-Bit)")

Quote from Deirdre

Ja, es lag an den beiden Plugins, habe diese gelöscht. Allerdings hieß mein Plugin-Ordner schon plugins

Freut mich, dass es jetzt funktioniert Möglicherweise fehlte einem der Plugins eine Dependency o.ä? Manche Plugins im Forum erfordern ein zweites bestimmtes Plugin, damit sie korrekt funktionieren.

Dass der Ordner "plugins" heißt ist aber korrekt. Deswegen schrieb ich ja oben, ihn testweise in "_plugins" (mit dem Unterstrich davor) umzubenennen, dann wären die Plugins nämlich auch nicht mehr geladen worden