been watching a lot of speedruns and thinking again about how the way they break apart game design challenges my assumptions about how games are made
in the NES era in particular, I had always assumed that monsters were almost 100% RNG. it turns out they're more like 0% RNG. I'm not sure *why* I assumed that, because I knew better
When the NES was my only console, I played a small handful of games countless times. I never got good at any of them but for the parts I knew, I never got surprised. I would get my ass kicked by enemies I *knew* were coming.
Blaster Master for instance I could basically snapshot things with my eyes closed. I still took tons of damage because it was *stupefyingly* hard to avoid taking damage from the enemy placement in that game, but I knew where it all was.
What I now know is that Blaster Masters levels were very tightly coupled to the graphics processor in the machine. the NES breathed tilemaps, so, presumably, the monsters were just stored as an extra plane of the games tilemap
it really seems like *most* NES scrollers were designed that way. Probably most SNES ones as well. The data layout is probably a lot simpler than I ever imagined. And in that context, randomness is actually much more work
The levels had to be designed anyway. Good places for enemies to appear would have needed to be picked. Manually placing enemies may have been *less* work than coming up with an RNG system that didn't put enemies in places that made the game unwinnable
In fact, I think the games that DID use RNG for enemy placement are mostly known as legendary kusoge in which you can die for no reason no matter how good you are.
Some (not all, and that's ok) speedrunning is an act of what I would call casual reverse engineering, like when you see a yellow traffic light and a crosswalk warning light blinking in perfect unison and think "ah, they both run off one controller"
I think I get more understanding of The Whole Enchilada out of this casual RE than I do out of reading instructional material from developers, because it doesn't work its way up from the bottom, where you can easily think "ok but at some point it'll get more complex"
even the best NES games rarely had more than 6-7 enemy entities, and all the talk about "despawning" in speedruns has to do with the games internal garbage collection deciding "ok we need to free up that entity since the player escaped it"
But when you read gamedev tutorials as a neophyte *this is not an idea you think is likely.* Like you see someone declare an array of 9 objects for enemies and you're like "ok, that's neat for play-play, but how do you dynamically allocate it for a *real* game"
but even now *it may very well be* how it's done. or better put: why not do it that way? if it worked for some excellent old games, will it truly not work now?
part of why I've bounced off of gamedev so hard is because I have the kind of brain that wants permanent solutions for things, and stuff like "uhhh loop over this array to see if there's an enemy object available" feels fundamentally Wrong
it doesn't scale, and that petrifies my subconscious and makes it think "you're wasting your time, this is all pointless, do it right or don't do it at all" in a category of effort where there simply *is* no right way
if you're writing a bullet hell then yeah maybe you need dynamic allocation but you might also just need to make a 4096 array, shrug off the miniscule RAM implications (it's 2018 not *actually* 1989, who cares if it's the 'wrong' approach) and dead reckon everything
a thing i'm thinking about: i keep wanting to make a NES style platformer but the complexities of dynamically loading screens as you move from place to place just sends my brain into a circle, and i realize suddenly that i could literally just load one PNG for the entire game
put everything in memory at all times. manually define a "room ID" for each object and turn off its Think when I"m not in that room. don't dynamically load enemies, just make a 4096 array of enemy objects and if i add more, make the number bigger.
because then like, the routine for scrolling from one screen to another can be to fucking CameraX++ on every Tick() until CameraX = Room.X * 320. fucking done.
i've mentioned this but I find both Unity and Gamemaker's camera controls, such as they are, godawful and impossible to understand. i was dicking around with unity again the other day and man, making a 2D game is just pulling teeth
i spent several years beating myself up for not getting unity but i have no fucking clue how anyone makes sense of this shitheap. i spent 5 hours trying to write a tick routine to make the camera follow the player and ended up only getting anywhere with magic numbers.
