Posts by paulevs

    Good day everyone, this suggestions thread is about forests.


    So, we already have good forests in Unity version, which are definitely better than in Java version. However, there is still a big room for enhancements as right now they don't look like real forests, and most foliage shading don't look like, well, a foliage, more like a solid objects. When I searched different game foliage implementations I found this thing:


    Comparing this implementation with existing forest I can conclude that there are several things that makes forest look realistic:

    1. Visible plant sub-surface scattering (leaves and twigs). I remember that current scattering is low as it didn't work fine at nights, as a result leaves of trees and bushes looks less like a foliage and more like a solid objects. So, well, I don't know if it is possible to solve at this point, but if it will be solved it will add +50% of realism to the trees. Even cartoon trees looks nice with sub-surface scattering :)
    2. A lot of small plants of different size. Rising World forests already have some, but much less than real forests have. I think that more random grass textures and different height variations of grass will partially fix that (we already have different grass, but looks like only one is generating in the world/in biome). As an addition there can be more bushes, small trees, large grassy plants (like Anthriscus, Chamaenerion, and other tall grasses)
    3. Other small natural objects - fallen branches, tree stumps, roots, twigs, small stones, etc. We already have some, but looks like most of them are generating in coniferous forest while other types of forests don't have small objects


    Small addition about object scattering. I don't know which scatter algorithm Rising World uses at this moment, but I want to suggest two good algorithms of natural scattering:

    1. Poisson Disc, it works fine for limited areas, but require modifications to work in infinity world. It is a good for ecosystem simulations as it can take into account plant size and density. There was an old article about ecosystem simulation
    2. Triangular grid. This is a simple (and cheap) algorithm that distributes object on triangle vertexes with random offsets. Since triangles are just offsetted squares it is very fast, and due to same thing it is easy to make it infinity or limit to area of any size.


    I also hope that with new plugin system we will be able to modify existing ingame objects and their shaders and scatter new objects in the world. In that case it will be possible to alter some assets and enhance forests, or add a lot of different custom plants to them ;)


    P.S.: Please enhance spruce assets, at this moment they are too yellow and don't have enough branches. I think that there are spruces in the world that looks like these, but I like spruces from the forum header much more than assets in the game. Probably I'm not the only one who think so :thinking:


    P.P.S.: If it will be possible to alter assets it will be possible to make nice game stylisations with plugins. Like Cartoony Risen World or Blocky Risen World, or any other variants that can be imagined

    When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

    Thanks for clarification :)
    Do you have plans to turn more parts into C++ code or it will remain C#?

    It's not using the built in enum class, but it works the same, and it's written in Java

    Technically you still can apply it even on Java enums, with using .ordinal() which will return enum index:

    Java
    public enum EnumFruits {
        APPLE, BANANA;
    }
    int weirdData = APPLE.ordinal() + BANANA.ordinal();

    But it will require more additional function callsm while in C languages you can use numbers directly, and cast them to enums too:


    C#
    Direction direction = APPLE + BANANA; // Direction is another enum

    I wouldn't really 'class' a enum as a data structure myself, more a data type

    Enum in Java is an Object, so it is included in data structure. Enums can be parent/child for each other, for example, or have other data types in hierarchy. And they can store data inside (which is a common practice in Java) while they are still an enum.
    Java itself have two types of data - objects and primitives. Enum is object in Java, while in C# it is a primitive, so it will have different behaviour.


    Brief example:
    You have enum of fruits, what will operation like APPLE + BANANA mean?
    In Java: syntax error, you can't use "+" operator on objects
    C languages: That's valid operation, I will just return a number for that

    So if your code in Java have a complicated enum structure it will be hard to port it into C languages, and more important - if this structure is a part of another library that you are using it will become much harder. From both code side and license side, and this is also a RW case as it uses JMonkey Engine, so it is related to JMonkey implementation of things which cannot be ported and must be carefully replaced with analogues


    they can be implemented in any language

    Technically this is true, but only for ideal abstract algorithm (and, I guess, for turing complete language). Most real tasks in huge projects are highly twisted with side libraries, different aspects of specific code language and many many small details. That's also a reason why most banks still use code from 70-80 on Fortran - it is almost impossible to port it on another language


    Addition: Red's post about languages and what parts of RW uses C++

    everything i have looked at about/for unity is c#

    C# is a scriptable language inside Unity editor while C++ is the language of Unity itself. It is possible to write code for Unity on C++, but this is not common practice - C# purpose is to make development simpler, but more limited. C++ was chosen due to two main reasons: it is required for JNI and it is much faster than C#. It is possible to run JNI in C#, but only for android, so most answers if you will ask "how to run Java in Unity" will be "You can't" as it is not completely supported on C# level

    Data structures as you know are the same whatever language you choose to write in.

    This is not correct, different languages have completely different implementation, brief example: in Java enums are objects, in C# it is numbers (which means that they can't store data, but can be casted one to each other and to numbers, same for C and C++), in scriptable languages there is no concept of enums at all. Different languages may have or not have concept of arrays, different indexing, may not have classes, have different ways of inheritance and so on.


    how do you know its C++ and not C#?

    From Red, it was mentioned on Steam and on Forum. This is also an only one choice to make possible run Java in Unity as it will require custom instance of JNI.

    C++ is also a good choice, as while Java and C++ have semi-equal operational time Unity C# was 40-50 times slower (worlgen tests from Steam)

    I'm guessing a lot of the code from Java will have been reused (rewritten) for Unity and improved upon during the rewrite. Java and C# are syntatically very close.

    Most code for current version is C++, not C#, so it will be different. Some parts will be logically equal, but this doesn't mean that they can be ported directly. C++ use many things that Java don't, like pointers, for example. And it requires manual garbage collection, so you will need to check for memory leaks much harder.


    Most old code was also based on JMonkey Engine things (like physics, lights, GUI, and so on), which will require complete replacement on Unity as this is different engine. Some changes related to it you can already see in possible GUI API description

    Please let us know if you're interested in a preview version of the API (specifically for the UI).

    Yes, we are interested in this :)
    Even if API is not complete it is a good way to start adapting to the new API together with new UI experiments


    The Internals class will provide a way to modify the Style of any game UI element. E.g. change the color of the health bar or the background color or image of any game menus.

    Will it make possible to change, for example, inventory size of a player or his hotbar? Or this will only affect visuals and API for inventory interactions will be separated?

    I think that in this case "postponed" just means "delayed do to lower priority". Technically there is a basis for moving structures, it is very similar to how blueprints are rendering before placement, but unlike blueprints together with rendering they should include collider. But this basis is not enough - there should be in-game tools to create these objects, survival-friendly mechanics, craft stations, GUI and so on, and all these things should be done from scratch as we didn't have similar mechanics in Java. So, things that already exists in Java have larger priority then completely new due to version switching

    I think that this suggestion was probably not noticed, so I bump it a bit


    So, small addition - if we will get clear brick texture (without mortar) we will be able to build custom arches


    Header-Shot_Arches_AR2_DSC_0635-scaled.jpg

    Sorry for my late response, I missed that post for some reason :wat: However, are these just blocks? Or is it a different element on the right side (e.g. the backface of a slope or something like that)? Was the element flipped/mirrored?

    These were individual blocks without mirroring, but probably with some rotations. Both surfaces are from stretched cubes. I'm not sure but probably if element is rotated or scaled with certain values it will get inverted normal


    Another screenshot:

    Probably there can be some changes in ores to make a good progression curve (for the future version):

    1. Different starting resource, the best is probably copper or bronze. This should make iron a bit more middle game resource

    2. Ore boulders can be rare, but you can find a small rocks (which will give you one resource during pickup) which will indicate large underground ore vein (same as in Vintage Story, Terra Firma Craft or 7 Days to Die). This will mark startup resources for the player, so it will be not too hard to find them, and this will make them a bit more hard to obtain. This should not be grinding and searching for hours, just a bit more effort to get basic resource


    it just feels like a game!

    Actually, this is a game, and like any other game it has gaming conventions, one of them is more frequent ore generation. It's not possible to build a furnace to smelt iron from rocks in field IRL using only small wooden table. Or make a lightbulb. Or make a circuit. Or dig golden vein that is 400m below your house. Games use conventions as IRL you can't do these things without huge civilisation industry background, and without proper knowledge, technology and a lot of time. There is a game genre that tries to replicate reality as much as possible - simulators, but Rising World is not a simulator, it is a survival building game, and like others game of that genre it share similar conventions with them.


    In the Java version there are also not ore stones, and nobody complained...

    In java version ores can generate on surface, in Unity - not. Ore stones (which has only iron) is a way for players to start progression as iron is a basic starting resource at this moment as Avanar mentioned above. All that you have without iron is a basic bench and stone tools, that's all. This is not enough even for collecting materials for your base.


    If you want to search iron for dozens of hours just to build a workbench - it's up to you, just change ore density in world settings (at this moment boulders are not configurable, but they will in the future), but please don't force all others play as you want. Rising World is not a game about grinding iron, and I hope it will not become such game. Finding resources for your needs is a good thing for survival games, but it should not be above specific limits. Previous version don't have iron boulders (they were rare), and ores were deep underground. As a result all that you have were stone toos and primitive bench. You were not able to even make a storage. And yes - you can require many hours up to several dozens just to find a starting amount of iron. I don't like such approach as the game transforms from fun and interesting into "iron searching simulator", which is boring. If someone want a world with rare/without ores - it is configurable, others deserve to play a fun game, not a grinding simulator

    The closest I can get is to resize a block but it doesnt really get thin enough.

    You can change size up to 0.01 units, you need to open a radial menu ('C' by default), chose scale and change it from 0.1 to 0.01, after that you can make any element much smaller

    What about some paintings?

    It is possible to load image, turn pixels into elements and then place in the game


    Don't stand too close, Ambient occlusion will kill your FPS ;)


    I have not seen any lakes, animals, or bandits on unity. i have also not seen any cave systems at all or dungeons. i went under ground in creative and see nothing at all. i flew around and see nothing. whats going on?

    To be honest it's a bit weird for me to see such posts.


    What did you expect from the version that is not finished and marked as beta? The game code is completely different from Java, most of the content and assets were created from scratch, and the current state required approximately two years to be created. You can't just switch the game from one engine to another - it is thousands of hours of work.


    Another fact is that the state of Unity version was discussed multiple times, in Steam, on Forum, its roadmap is on Trello, and in each location you can see complete information about each game update.


    So, I will repeat myself - it is weird for me to see such posts as all information is clearly visible and the reasons why the game is in this state and not in another are completely explained

    Looks like physics for some objects can get a random update, and decide that object don't have support, and collapse it (even if it has support or is attached). Or several attached objects. Or some dozens of ladders that were only one way to get out of mineshaft...

    Probably some objects (like ladders) should have more lightweight collapse conditions