4 ms·

Maintenance as in "changing the behavior of code on demand" in games is not solved by modifying the code but in the data. As a game programmer I'd terrified if

Maintenance as in "changing the behavior of code on demand" in games is not solved by modifying the code but in the data. As a game programmer I'd terrified if I had to change the code every time requirements change because the requirements in games change dozen times a day. I'd rather give the tools to the game designers so they could implement their own requirements themselves. Maintenance as in "keeping the code around and reusing it for other projects" is quite important with the games. We go extra length to make code reusable by isolating it from 3d party libraries, compiler features and such.

the_af 10y ago
But this goes to reinforce the idea that the principles involved in coding games are very different than those for other software, doesn't it? Therefore, what works in games is not necessarily a good idea for business software, and viceversa.
- pandaman 10y ago
  I am not sure that modifying code instead of data is a good principle for anybody. I do agree that it depends on the goal you are trying to achieve. E.g. if I had been running a custom software shop or an embedded IT department developing some internal software I'd too make maintenance as complicated as possible so I could bill for more engineers/QA or have more reports to increase my profit/bonuses/political weight etc.
  - the_af 10y ago
    > I am not sure that modifying code instead of data is a good principle for anybody. In my experience, for in-house software, modifying (or adding) code happens all the time. It's so common I'm puzzled that you don't consider it a good principle. In fact, the alternative -- making software so flexible every possible behavior can be customized by modifying data alone -- leads to the "enterprise software" antipattern (as often mocked in The Daily WTF), where everything is needlessly flexible and complicated. Or maybe even the "inner platform effect"! Even for game development, I've read teams (often?) hack the engines they buy, like it was famously the case for Half-Life, which used a heavily modified Quake engine.
    - pandaman 10y ago
      Look at how many people make a game and how many people make in-house software (if you don't know how many people make a game - go to mobygames.com and look up credits for it). Consider functional complexity of one and another then consider the actual complexity of the code. John Blow, quoted above, gives few examples too (e.g. Facebook's client requiring a change in the OS because of running out of the class limit). Game teams sure hack the engines and modify the code all the time but these modifications are not in response to changing requirements. It's 99% bug fixes, optimizations and planned feature implementation and 1% behavior changes requested by design.
      - the_af 10y ago
        I honestly don't understand where you're going re: number of people. Care to elaborate? I won't argue with you about the 99% data, 1% behavior changes thing. I can't argue with unreferenced statistics :) I seriously doubt your percentages, though. In any case, for business/enterprise software development it's definitely NOT the case. Software changes are both very common and a reasonable activity, so common in fact that if you disagree with this I have to ask (if you don't mind me asking): do you work in software development, and if so, what kind of software? Edit: and to answer a previous remark of yours: writing new code for feature/change requests has little to do with "making software as complicated as possible". It's likely the opposite: software that does just one thing is easier & faster to write and maintain than needlessly "flexible" and "customizable" systems. If I wanted to make a mess -- and myself indispensable -- I'd definitely go the "extremely customizable, this thing does everything you want sir!" route ;)
        pandaman 10y ago
        There are several orders of magnitude of (man hours)/(functional complexity) difference between game companies and enterprise. Changing code is incredibly expensive compared to changing data. >Software changes are both very common and a reasonable activity, so common in fact that if you disagree with this I have to ask (if you don't mind me asking): do you work in software development, and if so, what kind of software? I do work in software development, as I said above I am a game programmer.

the_af 10y ago

But this goes to reinforce the idea that the principles involved in coding games are very different than those for other software, doesn't it? Therefore, what works in games is not necessarily a good idea for business software, and viceversa.

pandaman 10y ago
I am not sure that modifying code instead of data is a good principle for anybody. I do agree that it depends on the goal you are trying to achieve. E.g. if I had been running a custom software shop or an embedded IT department developing some internal software I'd too make maintenance as complicated as possible so I could bill for more engineers/QA or have more reports to increase my profit/bonuses/political weight etc.
- the_af 10y ago
  > I am not sure that modifying code instead of data is a good principle for anybody. In my experience, for in-house software, modifying (or adding) code happens all the time. It's so common I'm puzzled that you don't consider it a good principle. In fact, the alternative -- making software so flexible every possible behavior can be customized by modifying data alone -- leads to the "enterprise software" antipattern (as often mocked in The Daily WTF), where everything is needlessly flexible and complicated. Or maybe even the "inner platform effect"! Even for game development, I've read teams (often?) hack the engines they buy, like it was famously the case for Half-Life, which used a heavily modified Quake engine.
  - pandaman 10y ago
    Look at how many people make a game and how many people make in-house software (if you don't know how many people make a game - go to mobygames.com and look up credits for it). Consider functional complexity of one and another then consider the actual complexity of the code. John Blow, quoted above, gives few examples too (e.g. Facebook's client requiring a change in the OS because of running out of the class limit). Game teams sure hack the engines and modify the code all the time but these modifications are not in response to changing requirements. It's 99% bug fixes, optimizations and planned feature implementation and 1% behavior changes requested by design.
    - the_af 10y ago
      I honestly don't understand where you're going re: number of people. Care to elaborate? I won't argue with you about the 99% data, 1% behavior changes thing. I can't argue with unreferenced statistics :) I seriously doubt your percentages, though. In any case, for business/enterprise software development it's definitely NOT the case. Software changes are both very common and a reasonable activity, so common in fact that if you disagree with this I have to ask (if you don't mind me asking): do you work in software development, and if so, what kind of software? Edit: and to answer a previous remark of yours: writing new code for feature/change requests has little to do with "making software as complicated as possible". It's likely the opposite: software that does just one thing is easier & faster to write and maintain than needlessly "flexible" and "customizable" systems. If I wanted to make a mess -- and myself indispensable -- I'd definitely go the "extremely customizable, this thing does everything you want sir!" route ;)
      - pandaman 10y ago
        There are several orders of magnitude of (man hours)/(functional complexity) difference between game companies and enterprise. Changing code is incredibly expensive compared to changing data. >Software changes are both very common and a reasonable activity, so common in fact that if you disagree with this I have to ask (if you don't mind me asking): do you work in software development, and if so, what kind of software? I do work in software development, as I said above I am a game programmer.