Hi Bump!

Great topic and questions you raise here!

Allow me to share my two cents, for I'm new to the homebrew scene in the GBA as well.

I had that exact same question. And I'll share with you a thought that I read -- and I'm not sure, and forgive me for not searching, but I guess it was from Jonathan Harbour, in his excellent book that I now recommend to you as well: Nintendo: The Unoficial Guide -- and the gist was very simple:
-- You have a limited set of time to dedicate to your project: Where do you want to spend it? Executing your game idea, or creating a one shot game engine, that you and only you will actually care for it, even if you put the most intricate algorithms in it, you optimize it in 30% of the nanoseconds.. Well.. you spent all your time, and voila! you've the most spectacular game engine.. And your game is probably underdeveloped.

In the essence, the GBA is just a fine piece of electronic, and like any piece of electronic, it starts in the - of the battery, and ends in the + of the same battery; basically a computer, and like a computer, you need to understand it's interrupts, and control them, to control the flow of the electrons so the magic can happen.
What we all should be asking was how to I control those switches:
And to know all those switches and interrupts, or to know the important ones, read https://problemkaputt.de/gbatek.htm.

And finally use Assembler to do that. And in this forum you've got pretty good masters at it like @Velipso (if memory serves, his devlog to inky is an assembly primer)
Or you can soften the proccess, by using C, that just compiles everything to machine code and achieve the same goals in an easier way.
If you're into OOP (object oriented programming), go for C++, that is basically C on steroid, oriented to the OOP paradigm.

Allow me to go slightly off topic: To my students, I usually tell them that there's nothing that you can achieve with C++, that is not possible with C, except that magnificent OOP syntax :-) In the end, 90% of the programming languages you know, have libc underneath; so why not use C already? They save a lot of time, my students quickly reply. Do they, I snarkly get back. Return to me 5 years from now, when you're presented with a thing called library dependency hell, your project must go to production in two days, important unit tests are failing because of a bug in a dependency, so you must upgrade it, but your project depends on a bigger dependency that not compatible with the newest version of dependency B, but if you don't do, it'll break dependency C, etc. etc. etc.

These unproductive tasks are our day job. This is mainly the reason why I love GBA, retrotech, and basically, digital purism. Programming for GBA actually has a soothing effect on my day.

And now, returning to the GBA dev.
You've pretty good game engines and libraries that ease the tasks for you. Devkitpro is a complete solution; Butano is just wonderful, and is in C++. Personally, I'm using a library that eases a lot of processes and saves me a lot of time: libham, made by Emanuel “Tubooboo” Schleussinger. He implemented a very practical approach to the GBA game development process. It's not complete, and it doesn't seem that we're going to see more features than the already implemented, so it must be complemented by libhel (http://www.console-dev.de/project/hel-library-for-gba/), and other stuff custom made with the help of GBA Tech (I mean DMA programming)

For a more recent and complete approach, go for libtonc, or devkit pro.

@exelotl gave you a complete receipt of material for you to study, and must be in a folder in your hard drive.

Sorry for the lengthy response, only to demote you from going to a probably sterile adventure on reinventing the wheel.
I wish you the best of luck for your projects, and share your progresses! I too am starting to develop a project in GBA, and probably some more of the guys here; we'd love to know and learn how you're putting to use those GBA chips :-)

GValiente wrote:

Cool project!

If you're going to use HAM, you should use HEL too, it's going to help a lot with some typical JRPG tasks like big maps.

HEL link: http://www.console-dev.de/project/hel-library-for-gba/

Thanks!

I've just reached out Emanuel (author of HAM) for buying the full version of it. He replied with instructions, and now I'm waiting to ear further news.
Hel implementation is going to be next step.

I'm sorry for the lengthy, and maybe complex post, but its the best way I can explain.

For the maps, I'm doing something a bit different, inspired (not equal for they were brilliant, but inspired) in Elder Scrolls 2, that has gigantic maps (ohh.. the so many things we can learn from the
postmortem game design) : I'll design very few maps, to path between the spots are going to be auto generated. It's something on the making, and I must devlog write about that. Meanwhile I'm writing the main idea to ear your best experienced ideas:
I'm putting the main idea (there are a lot of hoops to jump, and finesses to consider, with which I'm struggling to contemplate)
Imagine this thing :

+-----+-----+
| 1 | 2 |
| 3 | 4 |
+-----+-----+

Biomas:
1 - shore, spring, forest;
2 - shore, winter, mountain;
3 - shore, spring, forest;
4 - desert, summer, desert;

Goal: you have to go from the shore to get something the mountains,

1. you pass through different biomas, like, 7 screens of different biomas,

Per screen

• must need to know the enters and exit spots, generated randomly when assigned a quest:

• generate the visual path dynamically;
• between the path, render trees and nature elements according to the bioma, and the weather (tweaks on the pallets should do ;-) )

This way, you must render with Tiled (or similar) the city from where you get the quest, and the shrine that is in the mountain.
All the in between are randomly generated with the same few tree, bushes and vegetation tiles (with a lot of mirroring, size, and pallet tweaks so they can look different from each other)

From the start of the adventure, when you approach a border of the screen, the screen starts to be generated, and it caches the generated screens so they don't look that different of the way back :-)

Thank you so much for your encouraging words, Sean!

You're absolutely right—developing an RPG is indeed a significant undertaking. Given our limited time together, I can't promise specific deadlines, but the journey itself is what truly matters to us. It's all about cherishable moments with my child, creating stories and artwork together. I hope to leave my child with lasting memories of our collaboration and a tangible keepsake — a finished game cartridge he can revisit anytime.

I also wanted to commend your work on Inky and your recent games. They are truly inspiring! I especially enjoyed how accessible yet challenging Inky was—it's easy to understand but hard to master, which is perfect for engaging players deeply. Your newer releases have a different flavor that challenges me in new ways, making me eager for what you'll create next.

Dad'n Son Games will be way more straightforward. The first one is set to release next month, so stay tuned!

Hi devs!

Hope everything is great with you, your chips are well conditioned and your memory optimized :-)

I'm new to the GBA development, but not new to programming (it's actually what I do and teach for a living, for some years).

Dad'n Son games, the genesis

I'm creating a new project that allows me to spend some more quality time with my kid, while keeping inside the subject, and teaching him some stuff :-)
I'm calling it Dad'n Son Games. He also likes good old retro games and we play together some times. One day I challenged him to do our own (retro) new-old games ourselves: he designs, make some draws, shares his ideas, etc., I'm responsible to convert those ideas to bits and bytes.

It's been going for a couple of months now. After work and school, after dinner, an hour or 2 per day, we make some draws, record the music, we share ideas, and we do stuff.

GBA

For the purpose, I thought that GBA is the perfect platform for it. For A LOT of reasons -- when creating the official website, I'll put them there. I was a kid his age in the 90s, so SNES or Genesis would be more appropriated for some reasons, but GBA makes the bridge so much better.
For now lets say it fulfills the purpose of a videogame: "So what is a videogame? The American Heritage Dictionary defines a video game as "an electronic computerized game played by manipulating images on a video display or television screen", to quote the brilliant Jonat
han Harbour in his excellent Programming The Nintendo Game Boy Advance: The Unofficial Guide.
Don't need to put a lot of bells and whistles on it, I like simple and reliable stuff: to do a videogame, GBA is just that: the closest I can remember to bridge between my generation and his (while keeping faithful to that retro feeling).
A GBA game runs a modern browser and mobile phjone, thanks to the most excellent emulators we have nowadays.

GBA development simplicity

Since VIM is not an IDE per se, I'm doing it with the most reliable IDE I've found till today, and I was missing it, being this the best opportunity I get back to it purposefully: MS Visual C++ 6.0 (blazing fast with todays resources).
For the fun, I'm trying to stay faithfull to the technology used at the time: using windows 2k and Windows XP SP3 machines; paint shop pro;openMPT, etc. When not possible, or convenient -- afterall its an hobbie, not a job -- I'm using GIMP, LMMS. Everything either registered (for personal use) or open-source software that is freely available for educational purposes.
Following @velipso suggestion, I might write some stuff about the theme of a dev log.

Lib

For this one I'm going with the deprecated libHAM. It's simple, runs flawlessly inside the retro environment, it gets the job done of showing and manipulating pixels.

Plans

The main goal is to produce from the ground up a JRPG. I find it a great way to tell some stories while teaching some stuff, while spending quality time with the kiddo: it's my job as a dad, and it's very fun to do it -- we may thank LOTR and the Hobbit the same urge; and the comparisions end there: I'm no artist by no means, but.. lets see what happens, For the moment, I'm enjoying the experience, and we look forward to get together at the end of the day to work on some ideas.

I'll try to stay close to the 100% original material: illustrations, music and sfx.

To give you a context for the first game, I lecture programming in college as well. This semester I was lecturing C.
For the students project, I challenged them to do a Connect-4 type of game; and they challenged me back. I saw an opportunity to raise the Dad'n Son iniciative, while preparing a proper response to their challenge :-)
To gain momentum in my GBA development journey and set up a solid foundation, I completed the Aaron Rogers tutorial, read the Jonhathan Harbour book, read the Tonc tutorial, and get going adventuring to do a Connect-4 type of game. I've recycled some illustrations I already hadaquired from a professional artist for a previous custom game, and "borrowed" a music that I think its perfectly suited for the theme :-)

By now, it already allows for a two player game. I'm wrapping it up, so it can run other mini-games we have in mind to do with our Rollies.

Our goal is to be doing the games and sharing them with the world as they get done.

Wrapping it up

This wraps up the main idea of our project, and we’re thrilled to be sharing it with you as we prepare for our very first release—something we’re excited to share soon!
I'm writing to share you my experience and hear from you as more experienced devs. Maybe we can create stuff together , and put our GBA games in a better spot

This is a familiar and happiness oriented project. Here’s a sneak peek of what we’re working on. We’d love to hear your thoughts!

-
-