When We Have a Better Cross-Platform Plan for Minicraft+
Ben Forge
Previously, I mentioned that we should not work on mobile support with Java in the current Java project, but lately, there has been a discussion that LWJGL could still work with mobile. Now, I am going to reemphasize that we should not, especially when we do not have much resources and effort.
Natives options on the customized download page on LWJGL.com
Well, if you refer to the official LWJGL website, it does say it could support "Linux arm64", which Android is based on. However, if you take a look into this issue, you should be able to understand more: the support for Android is not fully integrated. It clearly shows that it is still not a working direction to support mobile platforms using Java and LWJGL. At the moment, it might not be a good idea to use Vulkan, as the development can be complex and problematic as well. LWJGL may also not work well on Android. So, OpenGL would still be chosen in this sense while there is no need to use OpenGL ES.
Java bytecode interactions with OS through JVM (source)
You may think we can "compile" the code to platforms that do not support JVM by themselves, but I would still not suggest that. Certainly, it is not an optimal solution. JVM, or Java Virtual Machine, is literally a kind of virtual machine, coming with a runtime. Under such runtime, it executes the Java bytecodes rather than machine codes or other things, and the runtime operates with the OS and other entities. Hence, optimization and functionalities often rely on the runtime, while LWJGL is optimizing based on it. In this sense, compiling to platforms without JVM support is unable to guarantee Java program support (packaging is different from this), so when there could be potential incompatibilities and potential stealthy bugs, why should we use this way for production? Thus, it can just be adding vast amounts of work without great benefit blindly.
Then, for the library or framework choice, we would choose LWJGL mainly because Minecraft uses it. What about other libraries? I know there is GLFW, but I prefer not to use it instead of LWJGL since LWJGL already utilizes GLFW for OpenGL support. So, why use a library over a mature library using it? It renders it pointless. Anyway, LWJGL already made bindings to it, and we even make more use of other supported features from LWJGL like bindings, so we can just go with LWJGL. There is no more discussion about other platforms anymore. Thus, the choice is over.
JVM Architecture Diagram (source)
By the way, even when working on the Java project, we can still build a native library to make use of the language or runtime advantages. Like using Rust for computation-intensive tasks such as physics. As C/C++/Rust is not really object-oriented, the memory management can be optimized quite well without the garbage collection part, causing some potential performance issues. Here, the Java part could be reduced a bit while increasing performance.
In addition, if you say bindings to libraries are just as similar as binding other platform libraries, I would not say it is entirely wrong, but I would choose not to stick with it. It eventually falls to the question of how it is executed in production regardless of libraries. Native libraries are supposed to be supported, but not the JVM. For example, there is GraalVM, which can be considered to be used to compile native executables or images, but it is not generally a satisfactory direction for normal software, especially games. It is not always clever to cross-compile anything to anything since not everything is truly compatible with each other, making it even harder to compile code from one architecture to another.
Different plans for Minicraft+ Java and Cross-Platform projects
Moreover, we plan to support both client and server for desktops but no server for other platforms. Indeed, servers are usually hosted on "servers" or computers, though there might be "LAN servers" locally like in Minecraft. Maybe it is still possible to standardize the protocols between different versions, but they may have minor differences in functionalities. For this Java project, we can then focus on both implementations for better workflows to get it done. Working on supporting other platforms is not what we should be doing now, as that is for much later.
Speaking of differences, there could still be differences between them; one of them is modding. Compared with desktops and JVM, modding in mobiles and consoles is not quite optimistic, except with APIs (like plugins, etc.), like some officially moddable games nowadays. It is also possible to have APIs like in Bedrock, which may not support "modding" (with mod loaders). I may discuss more about the topic of modding Minicraft+ later when it is the time.
Apart from platforms, we are planning to upgrade the Java version of the Java project. It is a big change and a must for our continuous development, though it could be a concern to some users. We will do it soon for our later 2.3 version progress, you may head over here for more information.
Currently, this project is still targeting desktops, and bare Java is not quite optimal (without Android API) with mobiles. While there are always ways to do tasks generally in every programming language theoretically, it is more vital to examine how easy/hard and how complex to implement in reality. Working in production does not like plane experimenting, where costs and efficiency are somehow not in high priority. There is no point in going for a tough path when we do not have much effort and a continuous amount of resources, but instead, a way more efficient and optimal (an expected way) method, which could be more productive and realizable.
Cover asset credits:
Subscribe to my newsletter
Read articles from Ben Forge directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by