Converting from Swing to LWJGL

After postponing for a long time, I have finally decided to update the engine to use LWJGL (Lightweight Java Game Library) for rendering instead of the Swing API. If you don't know about either of these tools, Swing is an older Java API used for creating GUIs and desktop applications. You can kind of get away with using it for simple game development but it's not a great solution for a longer-term game project, as the API is not designed with game development in mind.

Funnily enough, the thing that finally pushed me over the edge and convinced me to make the switch was hating my UI elements in my engine. They are hard to create, style, and layout, and I wanted to find a good UI library that wasn't Swing. I also wanted something intended for game development. There are some 3rd party libs out there but I found that they were either defunct or lacked great support. I knew that switching to LWJGL would allow me to use ImGUI (Immediate Mode Graphical User Interface), which is a library written in C++ that pairs with OpenGL that allows users to quickly create GUIs (which I am planning on using for engine UI elements). There are bindings for Java.

This engine has origins in Swing because I created it for a college 2D game programming course where all of the students were already familiar with Java and Swing as it was the main language of choice for the computer science students at that college, at least at the time. It was easier to get us programming our game engines faster if we used a language and framework that everyone was already familiar with, especially since, generally speaking, OpenGL is harder to learn.

With Swing, it is actually quite easy to get something off the ground and drawing pixels to the screen faster than with something like OpenGL, but it's still not a great idea to keep it in a serious project for a variety of reasons.

Here's the quick-and-dirty on the drawbacks of Swing and the pros of LWJGL:

Drawbacks of Game Programming with Swing

• Limited internet resources for game development
• JavaFX, a newer version of Swing, is more supported. Swing is old and the API is designed for older versions of Java.
• Not programming directly on the GPU, so not performant for more complicated games
• Input handling such as event handling for responding to keyboard input is designed for GUI desktop applications, like writing a word processor program, rather than for games. On that note, there is no native Java support for controllers, and 3rd party controller input support is limited, though there are options such as https://jinput.github.io/jinput/ which the current build of the engine is using
• Components that don't necessarily gel well with game development. Swing has Components such as JInputs and JButtons that can be used to create a GUI and listen to events, but in my opinion, the way these objects are controlled by Swing to create a layout is not very intuitive, and creating a clean and beautiful menu (by modern UI standards) with them is difficult. The "look and feel" of these components is also somewhat dated, at least without significant tweaking. Instead of using these, I found myself in essence writing my own UI code using my engine's representation of game objects and game components, but this ended up being quite tedious and not as flexible as using a well-documented, standalone UI library.

Benefits of Game Programming with LWJGL

• A wide breadth of internet resources to draw from for learning considering it is a collection of popular tools such as OpenGL, which are widely used in languages such as C++. OpenGL is undoubtedly the backbone of many game engines. It might also make it easier to port the engine to C++ later, if I choose to do so.  
• Great learning opportunity. Since OpenGL is so widely used, the patterns learned from using it are easier to apply outside of Java game development. Using it can help with getting a job in the game industry.
• More modern than Swing -- still in use.
• Performant. OpenGL allows the programmer to write instructions directly to the GPU. Programmers can also write shaders for tasks such as generating blended lightmaps or creating particle effects.

So, as you can see, there are many obvious benefits of making the switch to LWJGL, and also many reasons to move away from Swing. These lists are by no means comprehensive; however, there is one downside I haven't mentioned yet, and that's time.

Programming your own game engine is not easy, and after you've accumulated a significantly sized codebase, it becomes harder to re-architect large chunks of the codebase, such as the way rendering is handled. And of course, the goal is to actually create a game with the engine, and not just program tools all day. If you yourself are considering a significant re-architecture of your codebase, or perhaps porting your code to a different language, don't forget to take that into account.

I hope you found this post useful, and if you are programming your own game engine in Java, Kotlin, C++, or any language for that matter, I'd love to hear your thoughts in the comments if you agree with my assessment of Swing vs. LWJGL. Wish me luck on my porting from Swing to LWJGL!

Best,

Chris