4 ms·

Why is this a difference between "regular" programing and game play programming? Any kind of programming could have complex interactions between component. A fe

by tomerv 7y ago

Why is this a difference between "regular" programing and game play programming? Any kind of programming could have complex interactions between component. A few well known examples: OS kernel and drivers, VM manager, internet browser. The list is long, and there is a lot of programming of complicated products in the world - not everything is web development or CRUD apps.

Danieru 7y ago
Regular programming and game programming have different constaints and goals. 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.
- boomlinde 7y ago
  ”Regular programming” and ”regular programming” have different constraints and goals. Unless you think that e.g. a sound card driver and a web browser are developed with the same goals in mind and under the same constraints, you agree that games are not exceptional in this regard. 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.
- acomjean 7y ago
  I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems. 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.
- acomjean 7y ago
  I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems. 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.
  - int_19h 7y ago
    Games usually have state machines as well, but you can't have a single state machine for the whole world. So it ends up being a state machine per actor, usually - and every actor can potentially interact with most other actors.
- int_19h 7y ago
  If you think about it, games are by themselves are a prominent software engineering antipattern - what they model is a huge pile of global mutable state, where everything potentially depends on everything else, and changes happen asynchronously.
  - Danieru 7y ago
    Oh that is a good way of thinking about it.
jayd16 7y ago
In a game, you often want unexpected and whimsical emergent behavior. You want designers to build new and exciting things the programmer never expected. Game logic is about fun. Correctness is very low on the list of requirements. This is not the same kind of thing as bank software.

by tomerv 7y ago

Danieru 7y ago

Regular programming and game programming have different constaints and goals. 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.

boomlinde 7y ago
”Regular programming” and ”regular programming” have different constraints and goals. Unless you think that e.g. a sound card driver and a web browser are developed with the same goals in mind and under the same constraints, you agree that games are not exceptional in this regard. 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.
acomjean 7y ago
I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems. 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.
acomjean 7y ago
I’m not a game programmer, but in complex systems I’ve programmed in the the past there are state machines that help you avoid problems. 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.
- int_19h 7y ago
  Games usually have state machines as well, but you can't have a single state machine for the whole world. So it ends up being a state machine per actor, usually - and every actor can potentially interact with most other actors.
int_19h 7y ago
If you think about it, games are by themselves are a prominent software engineering antipattern - what they model is a huge pile of global mutable state, where everything potentially depends on everything else, and changes happen asynchronously.
- Danieru 7y ago
  Oh that is a good way of thinking about it.

jayd16 7y ago

In a game, you often want unexpected and whimsical emergent behavior. You want designers to build new and exciting things the programmer never expected. Game logic is about fun. Correctness is very low on the list of requirements. This is not the same kind of thing as bank software.