I can't speak to any of the low code approaches, but I do know it wouldn't be that hard for a GBA implementation once you learned the hardware (and the resources for learning it are pretty good). Each hexagon could be its own sprite (probably even with the text on them already, to make it super trivial), and then you can probably just DMA them into the appropriate place in memory during vblank. So then it's just the game state/logic. All of which is pretty straightforward in C, though there is tooling around other languages as well.

https://github.com/gbadev-org/awesome-gbadev has a buncha resources, though I can personally attest to Tonc as being everything you need for getting up and running (at least it was years ago when I used it, but the GBA hasn't changed since then; just the tooling and environment may have gotten better)

Yes, out of all the old systems, I think the GBA is the easiest to program for. The design is more streamlined/modern overall so that you don't have to worry about things like bank switching and the GPU has a cleaner design than the SNES.

The BIOS, graphics, and audio firmware fit nicely with the 32bit ARM architecture such that all you have to do is poke data into the right address (usually a #define'ed pointer in C) and it DMAs to the hardware.

And unlike later consoles, there's no operating system or significant copy protection to deal with, you link in a crt0.s to put everything at the right address, load the rom into an emulator, and it will start displaying your game. When your ready, you pop a flashcart into your hardware and it will probably work too. It's all very nice.

Thank you! I'll check it out.

I wasn't actually asking for anything low-code, I'm fine with coding, just hoping I can mostly stick with a C/C++ style approach without having to dig too deep into understanding the memory and registers and other things on a hardware level.

I've done some reading of materials on the hardware before (NES and GB mostly), and it's interesting, I just don't have the mental bandwidth at the moment to turn that casual understanding into usable code.

Maybe eventually I can get to that point, but for now if I can get by with mostly my game logic and some function calls to various wrappers for the hardware functionality, the better.

That link doesn't work well, just says it's not compatible with my device. There's a link that goes to some seo spam. Name not very googlable. Do u have a link to some screenshots/play video?

I have a video for the sequel when I released it on Xbox 360, although that's not what I linked to at first. The first link is Newgrounds, an old flash animation/game website that I first released the original game on 17 years ago (oh man, it's really been that long?).

https://youtu.be/Yqe0hS7AvOE

I'm also currently working on a new version for desktop and hopefully eventually consoles that uses 3D models, larger maps, 8 team local support, map editor, hopefully either a campaign or challenge mode (eventually, maybe not on first release), and hoping to add support for up to 150-ish stream viewers to join various teams and play on one of the 8 teams (where they vote for moves kind of like in Twitch Plays Pokemon).

Here's a year old video when I was just starting the project, I desperately need to make a newer video (hopefully this weekend finally):

https://youtu.be/0IAx9fsBuus

But I still would love to have a weekend project at some point of making a retro version.

This could probably work with GBA. One issue is the small 240x160 resolution, meaning the design has to be compressed. Also, you probably wont be able to use sprites for everything, it doesnt support that many. But you could probably use 8bit backgrounds. GBA allows multiple tile-based background layers, with mode 0 or mode 1 you could implement a lot of effects when using sprites on top (https://problemkaputt.de/gbatek.htm#gbalcdvideocontroller).

Either use a clever way to map your game board to 8x8 tiles, or use a large number (4/8 bit paletted color) tiles so that you can just draw arbitray images (like a bitmap, but its set up in tiles). Or just give up on trying to exactly match the hardware and just draw the hole thing using a bit map mode (e.g. mode 4, with 256 color palette and double buffering) - but that also means implementing the parallax effect by hand (since theres only one layer).