Originally, when I read the article, I thought that the issues described may be a result of bad software design.
But maybe it’s because applications are about strictness, and games are about freedom.
In application programming, you should be in a defined state most of the time, and make state transitions short and atomic.
In guess that in games, you are really in one huge, never-ending state transition.
This is not the same kind of thing as bank software.
Yes regular programming could indeed add a system where numbers might be animated. During the animation maybe you want another system to be able to change the number. Maybe the number disappears, make sure you're front end can handle not having the requested data arriving. Maybe you want systems which add extra fields to user data, maybe you want anytime a user attempts login that there is a 1% chance they receive a reward determined by their "user rank".
All these are "possible" but do not happen in regular programming. If a user attempted to log into your application, and instead a window popped up saying "you have died from starvation, please recreate your account and play again" rightly so your users would be angry, not impressed.
Different constraints and goals lead to different priorities. Games on a per screen basis have a lot more budget available. Imagine if your application's login screen took 2 months to program and required the full time effort of multiple artists.
It’s very hard especially if functionality gets added mid process (the companion can die now).
I had a piece of code log (“you should never get here”) once before crashing. Some programmer long gone put a constraint check with that strange note.
It’s hard especially if functionality gets added mid process (the companion can die now).
I had a piece of code log (“you should never get here”) once before crashing. Some programmer long gone put a constraint check with that strange note.
IMO it is more useful to think of software and its development as simply more or less complex.
Also, your whole post basically ignores GP’s argument that not everything is either a CRUD app or a game. Maybe it would serve your argument better if you took care to read and respond to his.
The type of programs where things like this occur are called simulations.
Much of what player consider progress in games is the industries ability to add more complexity. If you look at the contemporary equivalent to chess that would be the spin-off of MOBAs: AutoChess.
AutoChess may bare a similar name to chess but it is a vastly more complex game. In theory AutoChess could have been created on the NES, but no one would have understood how to keep the implementation reasonable.
Instead it took a progress, from Chess we got turn based strategy games. From TBS we got real time strategy games. From the early RTS games, we got the story rich Warcraft. From Warcraft came extensive modding support and story based characters. With said mod tooling and characters a series of mods became what we now know as LoL and MOBAs. Another decade and another set of mod support brought AutoChess.
Yes simulations are complex games, but what used to be a defined genre is now an aspect of most big games. Western RPGs certainly try to push the boundary of coplexity, as to tycoon or simulation games. Still, all genres are tending towards more complex systems.
In regular programming scopes are small, small enough for programmers to accomodate all expected logic. In games interaction scope is unlimited, or atleast that is what the game designers want.
If you try to program every expected system interaction you would never finish. So instead game programming is about making systems flexible. For example, as far as the gameplay code is concerned the inside of players ship is just yet another level. The bounds of any level are defined by what the map designers have layed out, not any pre-planned "ship area".
There are no meetings where project managers request "more playable area for level 7".
Likewise the systems programmer who made the furniture system was not the script writer who created the ladders. The script writer likely thought it was brilliant and elegant to split the entrances and exits, because in game programming it was indeed brilliant. It allowed the save system's existing code to handling what would have otherwise been special handling. It allowed the existing combat logic to handling what would otherwise be special handling.
Of course regular programming is different. In regular applications if a user's data is being sent to a server there is no secondary system which needs to be allowed to kill this data. Nor is there any save system which needs to be able to save and restore an in-progress action.
Games programming is all about figuring out ways to allow more varied and more complex interactions without exploding the implementation exponentially.