fictive

my other thoughts right now about a gameboy rhythm game is that the pixel response times on the orignal DMG/CGB really impose a significant game design challenge for implementing hard difficulties without cramming a lot of objects on screen. i personally get kinda overwhelmed and have a hard time reading fast maps with lots of slow moving objects, i like a smaller visible window of time for hit objects. but usually that kind of thing is configurable, so it might not be unreasonable to say if you want to play difficult maps on original hardware you should just use a larger time-window to deal with the screen response time, or otherwise either use an IPS-modded DMG, an AGS-101, or an emulator. but maybe there's a way we can telegraph these things a long way out without making them just be a simple list of hit objects scrolling down stepmania style

so imagine you're making a gameboy rhythm game. the gameboy only has 4 sound channels and you kinda want to be using all of those for your song most of the time. but, people like hitsounds. its adds some tactility to the game which can be nice if you're into that. what're our options?

noise channel

the noise channel seems like a pretty good option. make a configurable oneshot noise you can play for the hitsound. because you're sequencing the rhythm game in time with the music, you can maybe also do things like

• dont include noise sounds in the actual song data that overlap with a hit object
  • which basically means dont include the noise channel at all on hard difficulties i guess
• potentially, include data for the noise sounds, but play them in response to player input. the sound that plays is whatever is in range to the hit object, falling back to the player's configured hitsound if theres no nearby ones. so the player is the percussion section
• just play both and let them fight lmao

channel toggle clicks

you can generate click sounds on the gameboy by changing a channel's outputs from on to off, or off to on. It's a pretty subtle sound if you already have a lot of percussion going but its more obvious during sections of less rhythm, which is maybe good in this case because imo hitsounds matter most to gamefeel during sections without a lot of existing rhythmic elements to reinforce the player's connection to the underlying song rhythm.

I tend to use L/R pans a lot on the pulse channels, but i could definitely toggle the noise channel off/on quickly and maybe also the wave channel (but that one would probably interfere with a lot more)

let the player play the melody

the idea here is that instead of the hitsounds being rhythmic, they're melodic. sequence your song but dont play the melody. instead, whenever the player hits a button, play a note based on where in the melody the song should be. this can be really fun if you're really good at keeping time with a song but has kinda strange gamefeel if you aren't

add-in cartridge hardware

Im not sure how well known this is, but gameboy cartridges could actually provide their own audio hardware similar to how NES cartridges could! you basically get a fifth channel this way. So if i were to make my own cartridge, I could provide hitsounds with hardware on it. Im not sure if everdrive emulates any add-in audio hardware though, so this might only work if i actually made my own cartridge and sold it

the easy way out: Super GameBoy

most people playing a gameboy rhythm game won't be using gameboy hardware, they'll be using an emulator. We live in current year and emulators implement SGB. SGB was a hardware device that let you play gameboy games on a SNES. What fewer people know is it let the gameboy game access the SNES's sound hardware.

So, I believe we can use the SNES hardware to play hitsounds, without having to worry about it interacting with our song playback at all! I know Sameboy implements this, im not sure what else. I would probably distribute a game like this alongside a copy of an emulator pre-configured to play the game as best as possible, which also means that hacking in enough SGB compatibility to make the game's hitsounds work is a quite reasonable task to make it work on an emulator that doesnt already support SGB (like i think gameyob doesn't do this on DS).

i wrote this game in java, 2 or 3 months after i started learning programming by making my first minecraft mod. it's not a very good game- but this is because I didn't yet understand how to come up with ideas for good games.

the code is bad. I haven't seen it in years, but it's probably really bad. Does that matter? No. When you're writing a game, the code only has to be good enough to finish the game. I was only able to make this because I didn't care about if the code was good.

"Good Code"

The thing that I wish I understood when getting into coding, is that what makes code "good" is situational. A lot of people giving programming advice online are doing so from the perspective of working in an "industry". Here's some common scenarios:

They are writing code on a medium or large team.

They need everyone on the team to be able to understand the code to make changes. They need people to be able to gain that understanding quickly by reading it, because people do not have a shared mental model. They don't necessarily read all the code other people write as its written. They might go on vacation for a week and need to catch up. They might have been hired on a few years into the project!

They are writing a project that will last a long time and need to be changed a lot over that time

Like an operating system. Or a bad startup app. Or an MMO. Or a game engine that just will not ever die coughbethesdacough. You need to be able to keep working on these for quite awhile, maybe indefinitely. And these projects often get really, really big as they expand to do all sorts of random stuff. The less of a project that can fit in your head, and the longer you need to work on it, the more you need to prioritize making it easy to rediscover the project piece by piece.

The program needs to run for a really long time without problems

Perhaps many times longer than it will take to even beat the game you're making. Are you memory leaking 50 megabytes of ram an hour? It'd be nice if you fixed that, but you probably don't actually need to care. Services Georg who runs 50 copies of their server and only restarts them once every two weeks definitely does.

Sometimes they are just elitist

and think that if the code doesn't meet some arbitrary standard they've set, it's not worth existing. stay away from these people.

Anyways, the point is,

these concerns are usually not the concerns of a small indie game you and a couple friends are putting together. Your code only needs to be good enough to

• make the game do what you want it to do
• make the game run where you want it to run however fast you want it to run
• let you make the changes you want to make up until the point the game is done

beyond that, dont worry about it. Seriously. I've seen so many people try to get into this stuff and fail to get anywhere because they spent all their energy worrying about writing the best code, constantly rewriting to make the code better and better.

Improving your developer skills is a worthy goal, but it can come later. On later projects, on more ambitious projects. Spend some time after you've made something, trying to rewrite a part of your project in a better way. Focus on improving the parts that genuinely frustrated you when making it the first time. See how you like your changes. See if its really better or not.

When you actually need to care the most

OK, here's where you need to care, for real: networked multiplayer, in memory-unsafe languages. Does your game do networking? Did you write the networking code yourself? Did you use C/C++? Great (sarcastic) news, you might accidentally write a bug that lets a player hack another player over the network.

My recommendation? Get help with the networking. Use a library for it. Be very careful with any data that comes from other players. Or, you know, maybe just use a different language. C and C++ are perhaps the most unforgiving languages for a newcomer to work with, in general.

Anyways, that's my anti-perfectionism post for the $TIMEPERIOD

because SDL has 3DS support just in there.

main downside: the SDL implementation cannot make use of the graphics hardware, it is all software. but the CPU is fast enough that for many 2D things this isfine. you miiight be able to use SDL for input/sound and then directly use the graphics hardware yourself without going thru SDL for that, I'm not sure actually