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.