4 ms·

> The boss comes in and says "Hey, change of plans. The player is now a car." Stupid decision-making is why I will never work in games. With regular coding, yo

> The boss comes in and says "Hey, change of plans. The player is now a car." Stupid decision-making is why I will never work in games. With regular coding, you can iterate towards the domain and so long as you keep your wits about you and never make the same mistake twice, never be subjected to such a demand. In the arts, everything's got to hew to some asshole's vision. The people building it can never really know what's going on in his head and the asshole never understands how much work it is to change things to fit the evolving vision. Killer features on games are rarely evident from day one, game shops seem to always wind up looking like sausage factories.

dragonwriter 11y ago
> Stupid decision-making is why I will never work in games. With regular coding, you can iterate towards the domain and so long as you keep your wits about you and never make the same mistake twice, never be subjected to such a demand. In the ideal environment, perhaps; all too often in real environments, radical shifts in requirements not discoverable by advance consideration of the domain can happen outside of games (sometimes, because there are radical shifts in the domain -- if your system is automating implementation of corporate or government policy, whims of policymakers can change things as radically as "the player is now a car").
- vinceguidry 11y ago
  I work for a marketing company, I'm well aware of shifting whims. You can build flexibility into your infrastructure if you really need it. You come up with a model for how things are likely to change in the future and work modularity into your codebase. This approach doesn't really work for games. Everything is so interdependent, modularity that allows for all possible ways for the system could change would slow it down to a crawl. There's just no way to avoid expensive, painful rewrites.
  - yoklov 11y ago
    This is somewhat true, but you structure the code in a way so that rewriting any one part is easy. You keep your modules fairly large, your abstractions thin, and the code very literal. It's much easier to do a total rewrite on code that's like this than when you abstract it out a great deal. It's very quick to write code like this, and the maintenance cost of this isn't as large as you might think (honestly, after you get used to it, you often end up preferring it. It's very, uh, blunt, for lack of a better term). Edit: Worth noting that these rewrites aren't always due to a change in creative direction. There are often ones for technical reasons.
Retra 11y ago
This is why you need to be that asshole yourself and make your own games to your own vision.
- vinceguidry 11y ago
  Doesn't fix the lack of stability.
Rusky 11y ago
Game engines can just as easily be "iterated towards the domain" with "your wits about you." This post hints at several ways of achieving that. Artistic direction is normally accommodated at a higher level in data and scripting anyway.

dragonwriter 11y ago

> Stupid decision-making is why I will never work in games. With regular coding, you can iterate towards the domain and so long as you keep your wits about you and never make the same mistake twice, never be subjected to such a demand. In the ideal environment, perhaps; all too often in real environments, radical shifts in requirements not discoverable by advance consideration of the domain can happen outside of games (sometimes, because there are radical shifts in the domain -- if your system is automating implementation of corporate or government policy, whims of policymakers can change things as radically as "the player is now a car").

vinceguidry 11y ago
I work for a marketing company, I'm well aware of shifting whims. You can build flexibility into your infrastructure if you really need it. You come up with a model for how things are likely to change in the future and work modularity into your codebase. This approach doesn't really work for games. Everything is so interdependent, modularity that allows for all possible ways for the system could change would slow it down to a crawl. There's just no way to avoid expensive, painful rewrites.
- yoklov 11y ago
  This is somewhat true, but you structure the code in a way so that rewriting any one part is easy. You keep your modules fairly large, your abstractions thin, and the code very literal. It's much easier to do a total rewrite on code that's like this than when you abstract it out a great deal. It's very quick to write code like this, and the maintenance cost of this isn't as large as you might think (honestly, after you get used to it, you often end up preferring it. It's very, uh, blunt, for lack of a better term). Edit: Worth noting that these rewrites aren't always due to a change in creative direction. There are often ones for technical reasons.

Retra 11y ago

This is why you need to be that asshole yourself and make your own games to your own vision.

vinceguidry 11y ago
Doesn't fix the lack of stability.

Rusky 11y ago

Game engines can just as easily be "iterated towards the domain" with "your wits about you." This post hints at several ways of achieving that. Artistic direction is normally accommodated at a higher level in data and scripting anyway.