Challenges of Small Platform Dev

This is an outgrowth of what became a really big twitter thread.

We’re looking to develop games on two major tiers

  • Big, beautiful PC/XBox/PS5 games with our xbox360/PS4 style art.
  • Smaller, simpler, more portable games based on smaller consoles with scaled back art.

The trouble is that targeting group 1 with UE4 is really easy, but it’s much harder to target Nintendo, Evercade, Raspberry Pi, portables and small consoles of all sorts with UE4.
We’re totally on board with having 2 different engines for our base, but the issues is finding that lightweight engine. So far the issue is that the engines that excel at smaller hardware don’t work with xbox/ps5 at all (therefore it’d be a totally different codebase and art base between the xbox and switch versions, for example), and the ones that do larger hardware don’t work with ARM-based hardware properly.

  • Our first hope was Unity, since it’s a big solid engine that’s geared towards older/smaller hardware. Unfortunately, it doesn’t do Pi (or any other Linux/ARM) very well at all apparently. This means it wouldn’t work on all those great consoles out there that are so ideal for small game experiences, and currently just run Retroarch or similar.

  • Second hope was Godot, but unfortunately it’s not considered “compatible” with UWP by MS, therefore it is excluded from things like the Creator’s Program and requires porting.

  • Third was Game Maker which seems to tick many of the boxes but with a lot of limitations and a huge cost on top of a wacky proprietary language. Over a thousand dollars a year, regardless of sales.

So, tl;dr:
We’re still shopping for a low-spec engine that’s Linux/ARM/OMAP/x86 friendly that ideally supports at least xbox so that we don’t have 2 engines for console support.

3 Likes

Our dream small engine would allow supporting ES2/3 and Vulkan, not necessarily DirectX 10+


Example of ES2 vs ES 3.1 - as you can see ES2 is perfectly fine for Golden Axe/Castle Crashers/Double Dragon Neon style console gaming (which is largely 2D or simple 3D anyhow)

Vulkan is our ideal graphics lib, which is poorly supported in some engines. It just means that we want to make sure we can dev with an engine that supports OpenGL and Vulkan.

3 Likes

We did some basic testing with WebGL (unity’s answer), and found the performance on Pi at least to be extremely bad compared to UE4’s native AArch Linux compilation with Vulkan.

To recap everything we’re looking for:

  • Wide console compatibility with a shared code base
  • Small package size ( sub 50MB base )
  • Vulkan, OpenGL ES2 and 3 compatibility
  • Native Linux support on multiple architectures
  • Modest 3D support
4 Likes

Godot Engine - Vulkan progress report #7

Looks like Godot 4.0 may be the place to start!

Also, here’s the unofficial Raspberry Pi and Gameshell repos:
samdze/godot-gameshell: Godot export templates and instructions for the GameShell portable game console and other single-board computers (github.com)

hiulit/Unofficial-Godot-Engine-Raspberry-Pi: Unofficial Godot Engine binaries for the Raspberry Pi. (github.com)

1 Like

This is the main thing holding me back a bit on jumping into Godot right now:
image

1 Like

Updating this with a few others that have been tested and found problematic:

Phaser is small, light, and nice to work with but there is absolutely no way to secure assets with it. This means all our hard work and money invested in music, art, animation, is effectively just public domain as soon as the game is out.

Monogame is a great platform, however apparently there are a lot of issues with UI across non-windows platforms, to the point that this is a serious bone of contention with several devs.

We also looked into Stride, which seems to be an all-around great option… as long as we don’t have to publish for Linux in the immediate future. Linux support for it is currently poor.

The last option we checked out was libGDX which is ok, but it’s a pretty old library (2018), in Java, and seems to have no ready porting to most consoles.

Godot of course is still hard stopped right here:
image
As Godot moves past 3.4 (current) towards 4.0 (which drops all support for OpenGL) it actually places the Pi/ARM cutoff at the Pi4

1 Like