This will be the first of hopefully many Roadmap updates for the Universe Update.
The universe update requires a lot of groundwork, and while there have been already some things prepared and done over the last year, there is still a lot left as well as fitting the pieces together.
First of all, let me give you a rough outline of the timeline of the Universe update.
The update is going to be comprised of three Phases. Each phase primarily consists of similar types of updates.
In the following, I will talk about what has already been done, and what the next steps are.
There are several reasons for this: Java 11 is is not only more optimized on its own, it also provides new functions for cleaner code, game optimizations, as well as better compatibility. Furthermore, it is future proof, especially since a lot of newer versions of 3rd party libraries the game uses rely on a newer version of java. Another nice thing about it is that the runtime provided can be customized, meaning that we can deploy the game with a much smaller customized package that only contains the modules needed to run the game (and of course you would never have to install java to play the game).
Major libraries like hlsql (for databases) have been upgraded with new versions and the code had been refactored to support them.
Not only does lwjgl provide a closer interface to the hardware, it also comes with GLFW:
a universal interface, which is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop. It provides a simple API for creating windows, contexts and surfaces, receiving input and events.
GLFW is written in C and has native support for Windows, macOS and many Unix-like systems using the X Window System, such as Linux and FreeBSD.
Most of the upgrade work was already done in the background over the last year, so this major undertaking didn’t take as much time.
One major part of upgrading was also implementing some functionality (like text render management) that the previous version of lwjgl provided, since the new version is a lot less bloated, but instead a lot more modular and slick.
Another major advantage of lwjgl is that it comes with a lot of add-on libraries that can potentially optimize starmade or create new features like a faster compression lib. Also, Vulcan is fully available to us now.
Furthermore, there is a full library for Steamworks, which will make the planned implementation of steam functions (join game, etc) a lot faster and easier.
Status: DONE <- We are here
Since GLFW uses a whole different way to interface with input (keyboard, mouse, joysticks), I took the opportunity to rewrite StarMade’s input system to make it a lot more versatile, more responsive, and a lot less bug prone. The main advantage from the update, however, is that now every action in the game can be assigned to any device and button (including mouse wheel). This means firing with the keyboard, or switching slots with a joystick is now easily possible. The system can also handle modifier keys (key combinations), as well as any number of alternative inputs for an action.
Phase #2 is comprised of engine upgrades and system optimizations. There are a lot of plan to speed up block loading as well as block drawing by possibly a few magnitudes. This is necessary not only, but especially for the new planets.
This phase will also contain moving more things than ever to c++ code. I’m planning to move the physics to c++ fully, which will also natively support multiprocessor/threading.
Additionally, I’ll put the lighting calculations on c++ to speed up chunk graphics generation. With this, all processor heavy functions will be running in native c++, while maintaining the ease of project management that java provides.
On top of that, the graphics engine will be upgraded with a lot of functionality. Starting with simplifying a lot of block graphics data management, the main upgrade would be a new pipeline containing deferred rendering and dynamic lighting. Since dynamic lighting on its own never really works for voxel games of this scale, it will be built to be used in tandem with the baked lighting. This means that everything up close (or further away depending on the power of the graphics card) will be lit dynamically, meaning that light will look a lot better as well as affect other objects (cross entity lighting), while light in far away areas will be used the baked lighting as an approximation giving us optimal performance mixed with much better-looking visuals.
Another upgrade in phase #2 will be the content loader for sectors. If everything goes to plan, a sector switch will hopefully be virtually undetectable by a player.
This phase will also contain a rewrite of all the AI functions (might be moved to phase 3)
I will talk more in detail about Phase #2 when we get there.
TimeLine: This is in no way certain but I hope to finish with this phase in the first half of 2019.
The actual content phase. After phase #1 and #2, the engine should be in a great state. This phase includes redesigning the whole universe to a more condensed playing field filled with content and gameplay.
I can’t reveal too much about it yet since there are still some uncertain details that depend on the prior phases, but I will talk a lot more about more about these things in the updates during and after phase #2.
I hope that this will give you a nice overview of the current status of development. Everyone at Schine will continue to work at full power to make this the defining update to StarMade worthy of giving it the subtitle: StarMade 2020.
Thanks for playing StarMade,
- The Schine team
It looks like you're new here. If you want to get involved, click one of these buttons!