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.
So I try to avoid giving broad advice on game production because there's so many variables that may or may not apply to a given person or situation, but I do want to lay down a few thoughts on this. I'm not really responding to gravis here specifically, but his post is good and is a sentiment I've seen a few times before - how on earth do you get from programming game tidbits into a full ass game that does stuff??
Smoke and Mirrors
I have done very little non-game coding, I don't know anything about web or any other coding, but I've shipped multiple games as the lead or sole coder, and I think if I could sum up the ethos behind all games is: it's all just god damn smoke and mirrors.
There's an understated rule of design and gamedev broadly and that is "if the player doesn't see it, it may as well not exist." This is also a somewhat self-evident truth but hides a lot of nuance when you apply it to the realities of production, like what code to actually write to make something happen on screen. A design example would be something like weather in a strategy game: should you actually simulate clouds forming or rain falling, or should you just randomly pick an effect? What actually needs to be shown to the player? In this scenario the player needs to know the weather because of some other effect on the game state, in that case they probably just care about the end point and not any intermediate process. Is enemy AI a highly complex graph with a dozen inputs, or a if-else tree that does something simple? More often the latter, because the on-screen result is usually the same. And in most ways, actually a better design anyway.
In gravis' ladder example, it really can be as simple as it's described: in a certain location, if the player is pressing up, the character moves up in the world. Any change you apply to an object's position is it's velocity, and any change to the velocity is the acceleration. Letting changes stack up across multiple frames creates motion. I hope I'm not coming across patronizing, I just want to emphasize that for 80% of cases, something this simple is all you need.
Planning For the Future
If you're asking "surely there's something in that middle complexity that is the Right Way To Do Things, and shouldn't I be doing that?" the honest answer is yes, but you probably don't need to for a while. As a few people in the comments of the original post have noted, the golden rule of game coding is only make what you need at the time. There are some notable exceptions to this rule, ie like networking or multiplayer where foundations have to be laid. But that class of problem is out of scope when you're making small games or when learning to make games.
Games are incredibly complex networks of code and data. It's impossible to know from the start what kinds of weird interdependencies will crop up as the project matures. Could you try to anticipate those kinds of things? Sure, probably a few but definitely not all of them. If you're making a sequel to the game you've already made, this is a lot more doable but still won't be perfect. And ultimately no one will be able to anticipate those problems for you.
This, I believe, is why game coding tutorials are all "How To Move A Sphere" or "Advanced A* Pathfinding for Non-Tessellated Grids". That fuzzy middle portion is very specific to each individual project. It's not particularly useful for me to do a tutorial on the interface architecture for my current game, because it's built for exactly what I need and nothing else. It's also weirdly compromised and janky, because of all sorts of assumptions I made and had to change down the line. For what it's worth I do wish this could change, but not in a way that unified things across games (thus allowing for tutorials) but just steadily improved the engine's underlying structure so that people can make their own systems with less fuss.
Iteration Advice
So it's hard to know what you'll need without having made it first. This is the impossible knot at the core of game coding, and only slowly starts to get better with experience. I have a few suggestions on how to get things moving without that experience:
➡️ Accept that your code will be messy. Perhaps there's a better way to achieve the goal, but if what's happening on screen looks right then your job is done.
➡️ Keep code as simple as possible. There's lots of code tricks to make things smaller, or more performant, or fancy compiler stuff, but the ultimate goal is readability. Your overall architecture will be messy, so readability helps to alleviate that for yourself who has to look at this in a year.
➡️ Get everything done a little bit before developing one thing too much. This is the number one thing I see that characterizes really junior gamedevs. Presuming your goal is to finish a game and understand how to architect code, you want the whole game to develop in lockstep, as opposed to having player movement be extremely polished and feeling great, but absolutely no AI or level design. Working on every aspect least a little bit will help you spot what needs to be done next and avoid nasty entanglements. The example of camera logic in gravis' post is a good one to look at here: if you saw the finished product of camera logic, it has all this complexity to make a camera feel nice, or not go inside a 3d object, and so on. But in the service of just getting something on screen, all a camera has to do is point at and follow an avatar, which is one or two lines of code. Get that done and move on, and eventually after you take four or five passes at improving the camera it will have all that complexity you see in a finished game. But for most of the time you won't actually need that while working on the rest of the game. This is the logic behind making vertical slices, and why you see devs say games suddenly become so much better in the final bits of production. For most of the time all the niceties aren't there because everything else is being worked on, then it all falls into place together.
➡️ The easiest way to learn something is to ask someone a direct question. Tutorials can only take you so far and are missing the context you're in, engines frequently go out of date, or documentation isn't maintained. As someone with a minuscule amount of formal programming instruction, I learned by asking other people what to do, even down to literally how to write syntax or whatever.
➡️ This dovetails with: only write the code you know very well! If you've heard of a terniary* but don't really understand it, don't use it. Eventually you will be comfortable enough to broaden your horizons a bit. For example I've been doing game code and C# for nearly a decade and only recently got a full grip on Actions and Functions, and my future code will be a bit better but I've gotten along just fine without them.
➡️ A repeat of the previous point, but for math: only use the math you know! If you don't know trig, that's fine, I didn't for years. After several more years, I know have a fuzzy understanding of calculus. It's rare to have a problem in game code that can only be solved with advanced math. Remember to just get something on screen, and ask direct questions for help.
➡️ Get creative with cutting scope. You can get a lot out of just reframing a problem. To use gravis' ladder example again, if getting ladders is really stumping you then ditch ladders and make them teleporters. The end result is pretty much the same, and the code is a lot simpler.
➡️ Lastly, to revisit those big problems that require foundational planning I mentioned above: for a simple single player game, usually the only ones you'll deal with are saving/loading and menu systems. These are the big two** that are common to every game, and benefit a lot from already knowing what you're doing and planning for the future. They are solvable problems though and I would encourage you not to stress about it too much. The end result might be a clunky and too-large save file or a messy menu system, but all sorts of games from experienced devs have this anyway. The best you'll be able to is learn from your mistakes, make some preparatory changes on the next game, and then uncover a whole new mess you couldn't have predicted, and repeat the cycle.
Wrapping Up
This ended up being a bit longer than I intended, and I'm sure for any specific person reading this you know half of it already. I've gone a bit broad at that expense so I apologize.
My ultimate point is: there's not a universally applicable Right Way to do it, why is why game tutorials have a huge gulf of complexity. Just do it the simple way, and if it looks right on screen then I promise that's good enough. I just didn't want to say that without backing it up with my reasoning and examples.
*https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/conditional-operator
**that I can think of right now, maybe controller support would be another