If you're a classically-trained programmer, or a hacker who learned from classical programming texts or the effluvia thereof, you probably think of programs in terms of algorithms, and you think of a program as being concerned with inputs and outputs.
I think this is why gameplay programming can be so mysterious to a lot of people, because gameplay programming is traditionally not at all conceptualized in this way. Gameplay programming is all about update loops; there's no formalized inputs and outputs, there's simply "what changed since the last frame, and how should I change the state now which will carry over into the next frame", which is a very different way to think about programming. the game is a very gnarly data structure living in memory and the code's job is to keep it changing frame by frame in a way that adds up to game mechanics, even though in a traditional codebase those mechanics are only expressed through frame-wise incremental changes
I want to add onto here that even when you are using your more standard algorithmic approaches in gameplay programming, what they look like and eventually get surfaced as rarely looks like anything you'd find in a text book or in standard programming practices. Everything in a game is a function of time, nothing happens instantly (especially not on your ridiculously constrained time resources for calculations).
One of the algorithms I've found that is the closest in game programming (at least how I use it) to its more traditional implementations is A* (breadth first search optimized to care about a specific goal). You still call it and it outputs its path, which you can then move along (either in your environment or theoretical space). That path can then be traversed every frame until you reach your destination or need a new path because something changed that you need to factor into your path.
Where A* in game programming differs is how tight its operating budget is constrained. You have to be able to calculate whatever path you need in fractions of fractions of a second because even if you're not doing this every frame, you are doing those calculations on some frame and/or you are running a bunch of those searches simultaneously on different characters, different problems, etc, all with as little time spent as possible.
All larger abstractions having to break down into an incremental update over time makes everything more complicated and this is before you factor in that anything changing over time usually needs some kind of surfacing to a player. Your normal command line software doesn't need to have additional internal systems just to expose what is happening in this way.