I fear that this question is too difficult for me. Take a look at the screenshot below:
What you are looking at is a run of the Netwhack 0.7.0 codebase in Java using LibGDX. As you can see, the game renders and plays just fine.
What if I told you that I also have a C++ version that I just spent the last three days working on, and it looks exactly the same? It’s true. I spent the last three days rewriting the game in C++. The question is why.
I hate LibGDX
- LibGDX forces you to put game logic on the render thread. This means game logic can never update the screen. This makes simulating ASCII terminal string input virtually impossible.
- In order to fix Issue #1, I have to run the game in a separate thread. This breaks HTML5 compatibility. This removes the first reason to use LibGDX — it was the most portable library.
- LibGDX does not use standard keycodes, and does not give you a way to convert char to keycode. This makes it very difficult to handle function keys and arrow events alongside normal string input.
- The community has issues.
So here’s the thing with the community. When I went to reddit and tried to explain my problem, I was continually told that I was doing things wrong and that the real problem with the code was me — that I didn’t understand LibGDX and that I was trying to do the wrong thing. I got a lot of condescending “pro tips” from people who didn’t (or couldn’t) read my question. I will say this in LibGDX’s defense; it is actually possible to do what I want in one thread in LibGDX, but it would require re-writing the game engine as some sort of message-passing state machine. But I’m just not going to do that. Ok, so if I have to rewrite my game in Java and/or HTML5 to make it proper, then honestly rewriting it in C++/Allegro 5 looks far more attractive.
I love Allegro 5
Allegro! Of course. It’s the only other library I could find that is ultra-portable and allowed me to program in Java or C++. So anyways, I ran some tests. I barely got Jallegro working, but realized that Jallegro was going to be a pain to port, and that regular Allegro was better.
So I started rewriting the game in C++. Just to see how it would all work out. I mean, it was originally written in C++. So why not? It’s a data-driven game, once I had the display code up it would be short work to start adding in the methods.
And, let’s face it — Netwhack 0.6 was a pile of cruft. I could say I cut my Java teeth on it. There are many issues with the codebase. So maybe writing it over again is the best thing anyways.
But (there’s always something) I hate C++. That’s right. Here let me make that a heading:
I hate C++
C++ is a great language. But once you try Java you can’t go back. For one, header files are complete bull. Continuously having to put the class name before every member method is complete bull. Include files are bull. The whole thing stinks in comparison to Java. It’s true, admit it. C++ is a great language but the reason people develop faster in Java is because Java is closer to how the human mind wants to think about code. C++ makes you do things that are unnatural and there’s no reason for it. If you take out junk like reflection then Java could easily be compiled. People are just lazy and political. But enough. I hate C++, but I also hate LibGDX. And love Allegro 5.
I love Allegro 5
Allegro is the library I used way back in the day. The quirky, imperative-based structure of how things get done in Allegro is perfectly suited to writing a terminal simulator in C++ and then getting the hell out of the way, which is exactly what I need from it. Hey, I can write my own game loop, i’m not an idiot, thank you very much. In the end, the logic behind how Allegro 5 lets you do things makes more sense. This is how programming was done years ago, when people actually followed top down design and OOP programming practices. Nowadays it’s a LUA fest of GUI based “game engines”. God help us all.
Final thoughts. After hacking my way around LibGDX and writing the same code over again in C++/Allegro5, it’s true that both libraries are about equal in terms of features and performance. But if the only way to code sanely in LibGDX is to put your game logic in a separate thread, there is no longer any reason to choose LibGDX over Allegro from a purely practical standpoint. Both are just as portable and as powerful as each other.
Not having a reason to stick with LibGDX, I’m open to alternatives. I need time to think. For now I’ll continue working on both versions. At some point I am sure I will naturally feel more inclined towards one codebase or another.