All right, what’s the gamedev stack for Skymagi?

Rather than walk you through my weeks of unending research, pro/con lists, or god-forbid write an architecture-decision-record…

I chose Java / LibGDX.

I’ll be using Ashley for an ECS framework.

Why would you willingly choose to write a game in Java in 2020?

— Probably me in two four years

It’s a fair question. Unity / C# have taken the market by force for indie developers, Unreal / C++ hold dominion over games with high realism, and even Godot is now a favorite in the scene.

The truth is, I want to understand every part of my game. I want that level of control. And while Unity and Unreal’s engine royalties are not high, I’m not sure if I want to trust my game in another company’s hands. RTS games are not a good fit for either engine, and with mechanically intensive features, I suspect I’ll fight the systems frequently. So instead, I’ll fight myself constantly.

But why Java?

• I write Javascript/Typescript for a living, so not that.
• C# and Monogame look great but licensing complexity and microsoft are not my ideal.
• I love Rust, but libraries seem less mature/supported.
• LibGDX has everything I want, and Minecraft will guarantee LWJGL will be supported forever.
• I’ve written a lot of Java.
• Z Garbage Collector looks like it’ll solve FPS stutter problems Java can have.

Are those good reasons? Absolutely not. I’ll have to write my own shader support, shaders, rendering, entity lifecycle, collision (oh god), navmesh (oh GOD), networking (kill me NOW), pixel scaling, and I’ll write all of them worse than a full team of engine devs will.

But I’ll have freedom. I won’t have unnecessary systems I don’t need, and I can make whatever I want.

If you look at Steam games, something like 80-90% of Indie games are made with Unity or Unreal. If you filter it to the top 200 indie, about 40% made their game from scratch/libraries instead of an engine. The quality that comes from writing your own engine is noticeable, and the creativity/flexibility is greater. It also guarantees this will take a few years to make, but I’m in the long haul.

Time to get started

Mage drawn by my lovely sister as a placeholder.

Now time to set my meter-scale for these mages and get the viewport rendering properly…

Oh, and if I’m going to do pixel art, I probably won’t want mipmapping. If I do vector art, I’ll want it.

So, first mechanics done: Movement and Selection.

I also setup LibGDX’s TexturePacker, which builds spritesheets from individual images, and a build tool called Packr to make a .exe

Which made adding animations pretty simple…

Tiles

With the basics of the game setup, I wanted to introduce a tile system. Even if I decide to do unconstrained movement, a tile system will make actually creating maps and castles much easier.

And immediately, I run into a kind of issue rarely seen with engines. The mapping between my spritesheet and render resolution caused tiny red lines between all my tiles:

The texture was 256x256, but it was rendering around 64x64 and there was no bleed edge, so while it was mipmapping, it was getting no pixels. It looks like the texture packer has an option to bulk-scale all textures and ensure there’s margins / no overlap. With those solutions, I fixed the issue.

And now we have our first Castle!

Of course, castles will want complexity. I think an angled top-down perspective would be best.

While a true top-down perspective is likely the best for tactical complexity, angled top-down has a nostalgic factor, it isn’t as difficult to build as isometric, and there are many castles in this art style to reference.