The next #onetagperweek should be "choice", which captures those big decisions that were known to be big at the time of writing. Like "I'm going to do it on the #nintendoDS" or "I will start small, no megaman-X-scoped project this time"
http://sylvainhb.blogspot.com/search/label/choice
I say "should" because it will draw me into discussing how each of them have been kept or dismissed over the 10-18 years that followed, and that's going to take more than one week :P
like the initial choice on how-to-manage VRAM while scrolling barely lasted 1 month, but the way to associate properties to tiles stayed unchanged for 15 years.
I've chosen to leave behind the #libmikmod for DS despite I knew mikmod for a long time and go for a somewhat-obscure, custom homebrew developed library called #libntxm
http://sylvainhb.blogspot.com/2008/02/ntxm-play.html
(I still have to dig into the community-maintained revival of that library, though)
Possibly the boldest #gamedev choice I've made : let behaviours be part of game data, not part of the engine.
http://sylvainhb.blogspot.com/2008/05/bounce.html
It worked, it powers #BilouSchoolRush without slow downs on a 66MHz cpu.
But over time, state machines become more complex with tricky corner case to debug, and still no comfortable editor to tweak them from my sofa although they are parsed on the DS.
Introducing the "cando()" concept in the #GameEngine might have been equally important, although not as bold.
http://sylvainhb.blogspot.com/2009/02/world-collisions.html
because it allows to scan a target area for some properties and have, have different set of properties for monsters (and build them cages) ... but most of all because for the first time, I gave myself a game engine where I could take care not to end up in walls.
(granted, this wouldn't have worked on a 8-bit or 16-bit system)
And a choice that maybe wasn't that good (or at least, it cost me lots of debugging time): making the engine able to process heterogeneous delays in an animation. https://sylvainhb.blogspot.com/2009/05/moon-walk.html
It makes any character stick-to-the-ground like a walking Lemming, but it also occasionally made them stick to the walls, or make quantum leaps to other part of the screen...
http://sylvainhb.blogspot.com/2009/07/les-plate-formes.html
don't let yourself fooled by the title: this one is about the idea of splitting entity behaviour (like hero jumping) into parametric reusable micro-behaviour (like "apply gravity", "apply momentum" and "track dpad state") so that most of it can be reused e.g. by a jumping monster.
(tricky to illustrate, unfortunately)
Oh, and back then, having asymetric roles for hitbox and hurtbox was thought as a choice... http://sylvainhb.blogspot.com/2009/06/les-collisions.html
So far I managed to live with only HERO and EVIL casts, but sometimes at the expense of "EVIL look for EVIL" or arbitrarily making bridges "HEROes" when a "HOOK" or "GROUND" additional cast might be what the scenario truly needs.
Some "brainstorming" had happened about it, but no coding yet.
@PypeBros did you consider libxm7? 😅
https://github.com/sverx/libxm7
edit: uhm, got to fix that link in the readme, please use archive.org at:
https://web.archive.org/web/20190122024428/http://wcms.teleion.it/users/cgq/nds/libxm7/
@sverx I know I did at the time, but it wasn't open-source yet, so I stuck to my own modified NTXM. (there should be logs of that somewhere in gbadev forum).
and since then, the time available for homebrew coding has shrunk again ... but I'll have to give it a #codestudy anyway, just for the sake of a blogpost about it ;-)
@asie my biggest concern with libntxm is the way it auto-creates sub-sampled copies of the instruments to accomodate for NDS audio hardware, regardless of whether these are effectively used by the song or not.
That means the memory footprint for the audio samples is twice that of the file...
PypeBros
sverx🗩
asie