i used to try to make videogames from time to time and arguably i still do but less frequently. a thing that never stops bothering me - and this is not a Subchost, i just got to thinking about it again cause i saw some posts - is how "it's easy to get started making a game with (tool) and (tool)" is such a common thing to see, and more importantly, seems to work for a lot of people.
it feels like there are two types of people: those who realize that if you want to climb a ladder in a platformer, you need to detect whether the character is over the ladder, then whether they're pressing up, then how fast they should move, then whether there's an obstacle within that many units of their head, and so on and so forth - and people who don't, and I'm mostly the latter.
every time i have tried to make a videogame, it has never been a problem of tooling. the most complete videogame i ever made was written in raw C + SDL. sure, i was spending a lot of effort i didn't have to, but that didn't bother me; effort was not the problem. the problem was and always is that i just fundamentally don't grasp how games work
this connects back to a larger problem i've always had with programming. when i tried to learn how to Do It back when I thought that's what I was going to do with my life, I found exactly two kinds of tutorials:
-
How To Make Your First Class
-
Debugging & Optimizing Multi-Thread Object Locking In A Multicore Template Environment
and absolutely nothing in between. and even in more recent years, i see a lot of stuff that's like "okay, so after you code the logic for your player character," and I'm like "okay but what is that." it all just feels like draw the rest of the owl.
and i don't think this is anyone's fault! i am not mad at anyone for not explaining what seems manifestly obvious and unavoidably apparent to them. but, there is still this disconnect, and it's always made me feel stupid. and that's ironic, because apparently videogames are stupid.
every single time i find out how a part of a game works, i am flabbergasted by how brazenly dumb it is. if you're making a 2D game (and you aren't using a black-box physics library) apparently the way movement has always worked is, "if you're moving slowly, then increment the player's position by 1 pixel per frame. if you're moving quickly, then increment it by more pixels." this seems so absurd to me!
despite having thought of doing it that way at age ten, it just... felt like the incorrect solution. i look at super mario: I don't see him moving three pixels per frame. he looks like he's moving perfectly smoothly across the screen, and all I could think to ask for years was "how do you move one pixel per frame... a lot of times per second?" but i knew that the framerate was locked, and... that's where the thought process ended for me, with no answer. the idea of skipping pixels seemed, and still seems, completely wrong to me. surely that would make the gameplay jittery??
and surely it would break collision, right? what if you move 3 pixels forward and that skips over a 1-pixel obstruction? are you just going to perform three per-pixel collision checks per frame?? that can't be right! that can't be how you do it! that's like slicing a loaf of bread using a pocketknife. but apparently yes, that is one way to do it. it feels so wasteful!
what happens if you do miscalculate and end up with a character inside an object? yes, sure, i thought of "just calculate a vector to push them out of the object" when i was 12, but... it feels wrong! that can't be how you do it! it turns out that's how everyone does it.
everything about how actual games work feels completely barbarian, everything is a hack, a brazen hatchet job with tons of failure modes, and yeah, it turns out that is how everything is really done, but... I don't know how to push past that.
I don't know how to sit down and deliberately create functionality that sets off every alarm bell in me that says "if you were doing this the right way, it wouldn't be this finicky. the fact that you're experimentally adding and removing pixel offsets here and there means you need to throw this all out and figure out an Objectively Correct Solution For All Situations, because that's how programming works." like, yes, I could ignore that feeling, but then how would I ever make a decision about how to do anything? i can't just pick the first thought that enters my head because most first thoughts are wrong. how do i know what's wrong, and what's "videogames are just like this :)"?
more examples: for like the first ten years that i was thinking "how does megaman work" i had two impressions in my head:
-
okay, we are obviously only seeing part of the game world. when megaman moves, our view of it moves. so there has to be a complete game world somewhere, and a "camera" panning over it
-
but no, that's never how this stuff works, i KNOW it can't be like that. but... does that mean they're just materializing bits of the world as we move forward? that seems impossible to keep track of, and then all the weird arithmetic to figure out how the player interacts with it, and...
and of course that's exactly how it does work. i've seen the code to do this, but it seems impossibly complicated. the idea of loading a world on the fly just feels unimaginably failure-prone. come on! that's a hack! that's obviously not how you do it!
and, yeah, i mean, newer games often don't, I'm sure! i imagine a lot of modern 2d platformers do in fact have the entire map loaded into a "massive" 2D bitmap, or tiled onto polys, and let D3D culling sort it out. objects and enemies still need to appear dynamically though, and hell, the camera has to be programmed.
if you're making a 2D game in a 3D engine, then you might actually have a camera object - and even that's complicated because, while you might think "oh i'll just group the camera with the player sprite, done," that's not how anything has ever worked. in reality, the camera in any game (that anyone's heard of) has complicated logic: it stops moving when you get near the edge of a screen, it often doesn't move up or down when you jump, and it definitely doesn't follow the player sprite perfectly.
the first time I ever saw this acknowledged was in some series of gifs on a (japanese?) website a few years ago that overlaid well known 2D games (mario, metroid, etc.) with colored boxes to illustrate how the camera e.g. lags behind the player when you change direction, until you get X% across the screen, where it begins following you again.
i looked at that and said "but wait, doesn't that mean that the camera logic is full of all these if statements that say, if character less than this distance AND character minus X pixels is not less than the width of the current room...?" it, again, seemed absurd to me that this per-frame action would contain a huge stack of nested ifs to figure out whether to move the camera and which direction - and this isn't even addressing the need to lerp the movement, which is Math, and i'm really bad at math!
so yeah like. i am not calling for any changes. most gamedevs seem to be getting what they need. it's just, i think, if you've Always Wanted To Do This but never seem to get anywhere... you're not alone? i guess that's what I'm saying?
