If I had to rebuild Asqare today, which framework would I choose?

Clearly I would use an existing one instead of rolling my own. There are lots of choices out there.

• Godot is one obvious choice. It’s even officially listed in the Using a game engine on Android guide.
• libGDX is another obvious choice for something lower level. It’s not a “full stack” game engine, yet it’s a good foundation for someone to roll their own renderer.

For Jump!, the idea was to use scenes to implement everything in Godot. It’s a Godot thing, which just happens to export to Android. Some functionality can be provided by plugins, such as the screen sharing/export provided by GodotShare.aar → this is done by generating an “aar” library, and making it available to Godot..

For something like Asqare, the native Android implementation has some advantages as the gameplay screen is a view in an actual activity. It would be nice to know how to implement that level of integration using Godot. E.g. ideally a scene is just one view, or maybe one fragment, which is controlled by an otherwise “pure” Android app. That is, I want the reverse: instead of adding android library functionality to Godot, I’d like Godot to generate a library that I integrate in an external android app. This mode doesn’t quite seem supported but this seems the closer we can get:

https://docs.godotengine.org/en/3.5/tutorials/export/android_custom_build.html# 

The obvious cons here is that this implies we now have to deal with two tools/frameworks and they might have incompatible release schedules or requirements.

Generally speaking for all these small games, there’s a strong desire to reorganize them in a clear MVP or MVC pattern -- model-view-presenter or model-view-controller. MVC makes the most sense here: the model is the core gameplay, which can be coded in a separate library (e.g. an aar import), the view is an android skeleton and/or godot, and the presenter is godot.

It’s worth pointing out that games like Asqare and even Nerdkill are already architectured like that.

In a sense that seems to run contrary to the default Godot game implementation: Godot naturally tends to architecture a game around its scene graph as being the directing entity. The scene graph is the model. Furthermore entities in the scene graph embed part of their own logic such as collision and event handling.

In the Asqare case, that’s not incompatible with the MVC pattern: the “core” Asqare  game can be modeled as a board representation (an array of e.g. integers) and a function computing the name board state as well as a list of view updates. The presenter part in Godot would basically map each board cell to a sprite entity. Updates are actions like select (implemented as blinking or rotating a sprite), vanish, or animate an entry. This is the way the game is currently implemented in its Java micro “game engine”, even though it’s all hard coded functions and nothing is really generic.

From that description, it does read like using Godot for Asqare would be a bit of a stretch actually:

• Godot drives the android app creation, instead of being an embedded view/fragment.
• Godot strives to be the model with its scene graph.

The only benefit of using Godot is to use it as an animation engine (and without having to learn a new one). That’s more or less what using libGDX would do.

I should make the point that Nerdkill on Godot does make a lot of sense. The “scene graph is the model” works fine for Nerdkill.

But what about Asqare. If not Godot, then what?

What do I want, ideally?

• Some kind of scene graph thingy.
• An animation engine with some basic effects.
• Optional: 3d support with an orthographic top view. Would allow to draw elements in Blender and animate them without having to render them to static image maps
• The cons of that is the added complexity of a 3d GL view.

What if we took a different approach? Kotling game engines:

• MiniGDX: https://gamefromscratch.com/minigdx-kotlin-game-development-framework/
• Besides the name, this has no affiliation with libGDX. It uses ljgl and al.
• This is just a one-person game engine with no pedigree and no support team.
• Same person has contributed to libKTX.
• libGDX is well known and documented.
• Does both 2d and 3d.
• https://libgdx.com/wiki/jvm-langs/using-libgdx-with-kotlin
• https://libktx.github.io/
• Korge: https://korge.org/ 
• https://gamefromscratch.com/korge-engine-kotlin-powered-open-source-game-engine/
• Korge is a set of libraries + some IJ plugin.
• It focuses on 2d.
• Kotlin-is-fabulous indoctrination is a cons.
• That Flutter-simple-game thing?
• Meh to Dart.
• No desire to use it long term.
• Android Jetpack Compose?

In my case, looking at the long-term, say I update an app next in 5-10 years:

• The IDE project may be obsolete. E.g. some of my projects still use Eclipse.
• The project configuration may be obsolete, even if the IDE is still the same.
• Example: gradle groovy now vs maybe gradle kotlin later.
• Who knows about stuff from e.g. Godot?
• The language could become obsolete.
• Example: go1 projects not compatible with go1.5, etc.
• C# has the same issue. I expect Kotlin to have the same issue.
• Java has this “legacy” thinking model which saves it for now.
• Who knows about GDScript?
• Library support for Android and older API models changes.
• Compat library is min 14 these days.
• A lot of stuff at G is min 21.

Having an app/game that depends on e.g. Godot + Android means to have to deal with all that, times 2, for each platform, plus their intersection.

---