picking up stuff + GUI

Quote from Lonelobo

Also a realy small question: why did u (@red) programmed this game in java and not c++

Of course, I can only speak for myself and the RW dev team will answer this point but, while I am a C++ developer more than anything else, I arrived at the same conclusion of the RW dev team (this was before I knew of RW): Java has some important strong points over other languages, for instance regarding portability across platforms; the Java VM is practically identical in all platforms and ensures a highly constant context.

Arguments could be made for Java being slightly less efficient than C++, but the literature has shown that the gap is reducing and might be marginal in applications where the graphic output is going to be the bottle neck.

Add the availability of nice (and platform-independent!) libraries like LWJGL or JMonkey and the choice seems easy.

There are alternatives but, for instance, the most fashionable nowadays, i.e. Unity, is actually a messy behemoth with heavy cross-platform issues.

Quote from Lonelobo

I dont think this game is limited at the graphics output atm, my system is literly doing almost nothing and i still get low fps. And i know its alpha atm and so non/almost non optimaizations are in place.

And more or less this would affect the intermediate dev stages, whichever the programming language chosen.

Quote from Lonelobo

java is also know for not alowing 100% system usage thanks to its virtual machine.
Also C++ in combo with sfml (for example) are also great cross-platform not to mention vulkan for taking things the next level.

Sure, there might be alternative (if I am not mistaken, SFML only supports 2D graphics, though). Still, in many cases, they require separate compilation, debugging, deployment and distribution for each platform, something which might be beyond the resources of a small dev team.

Quote from Lonelobo

And the core engine jmonkey is written in opengl & c++ i think?

As far as I know, JME is mostly (or entirely?) in Java.

That said, I am not arguing that Java is the panacea of all the problems; unfortunately, there is no such a think. More modestly, that it is not such a strange choice, as sometime someone seems to imply.

Quote from Lonelobo

In this version off the game its not possible to pick up certain stuff (wooden beams / modern lamps etc..), while other stuff can be picked up easly (scaffoldings...)

Right now construction elements (i.e. planks, beams) can't be deconstructed, this will be added in the future Apart from that, you can't remove certain objects, like lamps, although that's actually intended behaviour: Once electricity is implemented, lamps are going to require proper wiring and a power source, so in other words, it's going to require much more effort to use lamps. So since it's quite easy to use lamps now, we wanted to have at least a small limitation by preventing players from picking them up^^

Quote from Lonelobo

also in the future is the gui going to be remade?

Probably there won't be a full rework of the gui, but I guess we're going to enable people to customize it (especially when it comes to the position of certain gui elements)

Quote from Lonelobo

Also a realy small question: why did u (@red) programmed this game in java and not c++?

Basically @Miwarre hit the nail on the head: Java offers great portability.
Although Java has a bad reputation, it is unfounded. It had some serious flaws in the 90s, but since then, things have changed dramatically. In terms of performance, there wouldn't be a big difference between Java and C++ (although first we have to be clear about the term "performance": if we are talking about the speed of computations, there is no difference between the various high level languages, your CPU can calculate "1+1" always at the same speed^^). Although Java is a little bit more "limited" when it comes to memory management, due to its automated garbage collection process, one have to say it actually does a good job. Having full control of these things *might* result in a better performance (or better memory management) though, but this only applies if you know what you're doing. Many big C++ projects use garbage collectors as well, and I doubt they're doing a better job at all^^
The formula "higher abstraction == less control == worse performance" might be true in certain cases theoretically, but then we could also decide to write our applications in Assembly, for example
Speaking about memory, there is indeed a minor "disadvantage" in Java: The overhead of the VM, which is unavoidable. But this is nothing to worry about, it's maybe 50 mb or something like that, which shouldn't be a big deal nowadays. You have to keep in mind that every language has advantages and disadvantages.

Quote from Lonelobo

I dont think this game is limited at the graphics output atm, my system is literly doing almost nothing and i still get low fps

Your framerate depends on various factors. On the one hand, the performance of your CPU of course (not only the number of cores matter [and the "type" of a core, there is a difference between AMD and Intel, for example], also the clock speed, and especially the amount of work that is done per clock cycle), but also your graphics card, your RAM, your VRAM and your harddrive (and - of course - the state of your system, installed software etc).

Quote from Lonelobo

java is also know for not alowing 100% system usage thanks to its virtual machine.

This isn't true. Where do you get these information?

Quote from Lonelobo

not to mention vulkan for taking things the next level

Vulkan is still in an early state. Besides the fact that the Vulkan API wasn't available when we started developing RW, even now it wouldn't make much sense if a game fully relies on Vulkan. I'm confident that Vulkan is going to be great, but right now it's too early to concentrate on it. Furthermore, many old graphics cards don't even support Vulkan (Radeon 7000, 6000, 5000 series etc, Geforce 500, 400, 300, 200 series etc), and apparently there are several people out there who have even older hardware