Generally speaking, writing your own games for retro consoles starts with C code. You’ll need to feed that through a console-specific tool-chain, and there’s certainly going to be some …
I can wholeheartedly recommend C for 8-bit platforms, endorse 6502 assembly as brilliant and rewarding, and tell anyone new to retro game dev to pick any other system besides the NES. It’s a fucking nightmare. VRAM is only accessible during vblank and will jank up your screen if you try doing too much per frame. The sound chip will eat inputs if you try doing sample playback. Splitscreen of any kind is nightmarish without a mapper chip. Everything has errata - VRAM reads will return junk once per frame, because go fuck yourself. Every color that’s not blue is ugly, anything saturated has “dot crawl,” and the palette grid is a bitbanging headache that only gets hidden by CRT overscan.
None of this is aided by cc65 being a jumped-up assembler macro. It is instant. It’s the fastest goddamn compiler I’ve ever used. But some C will generate absolute dogshit assembly, for reasons inscrutable to mortal men. There’s documentation - it’s wrong. It tells you how to put variables in zero-page and it’s lying. There’s a fastcall convention that still shoves registers onto the stack. There’s no sane way to place things at specific memory addresses, or even page-align arrays, which you’d think might be kinda fucking important for a compiler suite that supports one architecture. But I really cannot overstress how stupidly fast it is, to where checking any of this bullshit by modifying and rebuilding is quicker than any debugger.
So.
Uh.
If this setup eases any of that - great. Otherwise start with a Game Boy game and GBDK.
I wrote the only first-person shooter on NES.
I can wholeheartedly recommend C for 8-bit platforms, endorse 6502 assembly as brilliant and rewarding, and tell anyone new to retro game dev to pick any other system besides the NES. It’s a fucking nightmare. VRAM is only accessible during vblank and will jank up your screen if you try doing too much per frame. The sound chip will eat inputs if you try doing sample playback. Splitscreen of any kind is nightmarish without a mapper chip. Everything has errata - VRAM reads will return junk once per frame, because go fuck yourself. Every color that’s not blue is ugly, anything saturated has “dot crawl,” and the palette grid is a bitbanging headache that only gets hidden by CRT overscan.
None of this is aided by cc65 being a jumped-up assembler macro. It is instant. It’s the fastest goddamn compiler I’ve ever used. But some C will generate absolute dogshit assembly, for reasons inscrutable to mortal men. There’s documentation - it’s wrong. It tells you how to put variables in zero-page and it’s lying. There’s a fastcall convention that still shoves registers onto the stack. There’s no sane way to place things at specific memory addresses, or even page-align arrays, which you’d think might be kinda fucking important for a compiler suite that supports one architecture. But I really cannot overstress how stupidly fast it is, to where checking any of this bullshit by modifying and rebuilding is quicker than any debugger.
So.
Uh.
If this setup eases any of that - great. Otherwise start with a Game Boy game and GBDK.