4 ms·

Oh I was on a project once where we decided to reduce scope. Dozens of distinct levels. The art team was well ahead of schedule, the software team way behind. S

Oh I was on a project once where we decided to reduce scope. Dozens of distinct levels. The art team was well ahead of schedule, the software team way behind. So the Producer cut the scope by removing any levels that had unique art features. That really helped us. I could write a book on game development project management anti-patterns. Unfortunately, there's too many warm bodies willing to sacrifice for there ever to be effective change. You can proselytize solutions to the problem all day long, but the truth of the matter is, the power structure doesn't want to change because the power structure believes it doesn't need to change. There's also a large number of anti-patterns missing from the paper: Lack of training (possibly falling under lack of knowledge) Not invented here syndrome Lack of adoption of new technology Rushing to adopt immature technology Early optimization Over engineering Under engineering Lack of architecture (could fall under planning, but this is more fundamental) Assumptions about how things will work Lack of experienced team members, across all disciplines (lack of knowledge?) Rework "Good enough" or as I hear it "It compiles and runs doesn't it?" Aiming for perfection Lack of repeatability in all aspects of the process (inadequate tools?)

deleted 5y ago
[deleted]
loup-vaillant 5y ago
Most of what you describe sounds like production problems, which were explicitly ignored by the paper (they focused on feature management and people management).
Cthulhu_ 5y ago
> Not invented here syndrome I feel like this is a big one that affects a lot of customers. There's so many games - from indies to AAA titles - where they show hubris by building their own engines; this has led to a lot of titles that just look dated and janky (top of my head it's games like Final Fantasy XV, Skyrim and Cyberpunk); these would all have turned out better if they picked an off-the-shelf engine instead of try and build and maintain their own. I mean I'm sure they're competent developers all, but they can't compete with e.g. Unreal or ID Tech. > "Good enough" or as I hear it "It compiles and runs doesn't it?" Is not actually the worst I think; it's not acceptable in AAA games (see Cyberpunk again, a case of over-reaching / feature creep / hubris), but for plenty of indie games, good enough IS good enough. I mean you mention aiming for perfection right afterward, and over-engineering before, and the main paper mentions feature creep; it's better to ship than end up in development hell, especially if performance is forgiving (e.g. 2d indie games on modern hardware).
- Arwill 5y ago
  >if they picked an off-the-shelf engine I would add an anti-pattern in contrary to that: engine duct-taping. There might be a specific solution in the engine for a problem, or in the underlying library/graphics API, which a developer could make use of/could unlock. But the level/game designers chose to build solutions on top of high-level engine features, which leads to poor performance, bugs, glitches and unwanted side effects.
  - meheleventyone 5y ago
    Also Too Much Middleware where every problem has been attempted to be solved by adding in a new generic library and you have a tangle of interdependencies between them with very different interfaces. Then you try to update one. Also any custom work to an engine where you still want to pull updates. I think on one project it would take one poor person two weeks to merge a new version of UE3.
    - maccard 5y ago
      > Also any custom work to an engine where you still want to pull updates. I think on one project it would take one poor person two weeks to merge a new version of UE3. UE4 has been around for almost 8 years at this point; There must be vanishingly small amounts of games still using UE3 in active development (cough _Rocket League_ cough). The upgrade path for UE4 releases is pretty straightforward these days - on my current project it's a half a day for one person to upgrade a major engine version and most of that is just syncing from empty to make sure everything works. We've gone from 4.25 to 4.26 to 4.27 with pretty much no pain points. (disclaimer: I used to work for Epic as a developer, but my experience above is from my time since.)
      - meheleventyone 5y ago
        Yeah it’s an example from the past, at the time it was due to the level of modification we made to the engine. This was at the time Epic was making Gears of War and we were using UE3 from its early beta and our project was quite different to Gears so the engine didn’t really support what we needed. These days for many projects it’s more about how much the underlying features you’re using have changed. Either way if you’re using an engine and have extensively modified it upgrading is always going to be a pain. It’s just there is less call to now.
baud147258 5y ago
> Lack of adoption of new technology > Rushing to adopt immature technology How do you balance such things (and under/over engineering, good enough vs perfection)?
- Datenstrom 5y ago
  These are caused by this: > Lack of experienced team members, across all disciplines (lack of knowledge?) You learn to balance these things from being experienced enough to have shot yourself in the foot by each a few times, or having studied history enough and apprenticed under a expert who explained their decisions in detail. Edit: except in the case where the problem stems from management not listening to the experienced experts, in that case nothing you can do but leave really.

deleted 5y ago

[deleted]

loup-vaillant 5y ago

Most of what you describe sounds like production problems, which were explicitly ignored by the paper (they focused on feature management and people management).

Cthulhu_ 5y ago

> Not invented here syndrome I feel like this is a big one that affects a lot of customers. There's so many games - from indies to AAA titles - where they show hubris by building their own engines; this has led to a lot of titles that just look dated and janky (top of my head it's games like Final Fantasy XV, Skyrim and Cyberpunk); these would all have turned out better if they picked an off-the-shelf engine instead of try and build and maintain their own. I mean I'm sure they're competent developers all, but they can't compete with e.g. Unreal or ID Tech. > "Good enough" or as I hear it "It compiles and runs doesn't it?" Is not actually the worst I think; it's not acceptable in AAA games (see Cyberpunk again, a case of over-reaching / feature creep / hubris), but for plenty of indie games, good enough IS good enough. I mean you mention aiming for perfection right afterward, and over-engineering before, and the main paper mentions feature creep; it's better to ship than end up in development hell, especially if performance is forgiving (e.g. 2d indie games on modern hardware).

Arwill 5y ago
>if they picked an off-the-shelf engine I would add an anti-pattern in contrary to that: engine duct-taping. There might be a specific solution in the engine for a problem, or in the underlying library/graphics API, which a developer could make use of/could unlock. But the level/game designers chose to build solutions on top of high-level engine features, which leads to poor performance, bugs, glitches and unwanted side effects.
- meheleventyone 5y ago
  Also Too Much Middleware where every problem has been attempted to be solved by adding in a new generic library and you have a tangle of interdependencies between them with very different interfaces. Then you try to update one. Also any custom work to an engine where you still want to pull updates. I think on one project it would take one poor person two weeks to merge a new version of UE3.
  - maccard 5y ago
    > Also any custom work to an engine where you still want to pull updates. I think on one project it would take one poor person two weeks to merge a new version of UE3. UE4 has been around for almost 8 years at this point; There must be vanishingly small amounts of games still using UE3 in active development (cough _Rocket League_ cough). The upgrade path for UE4 releases is pretty straightforward these days - on my current project it's a half a day for one person to upgrade a major engine version and most of that is just syncing from empty to make sure everything works. We've gone from 4.25 to 4.26 to 4.27 with pretty much no pain points. (disclaimer: I used to work for Epic as a developer, but my experience above is from my time since.)
    - meheleventyone 5y ago
      Yeah it’s an example from the past, at the time it was due to the level of modification we made to the engine. This was at the time Epic was making Gears of War and we were using UE3 from its early beta and our project was quite different to Gears so the engine didn’t really support what we needed. These days for many projects it’s more about how much the underlying features you’re using have changed. Either way if you’re using an engine and have extensively modified it upgrading is always going to be a pain. It’s just there is less call to now.

baud147258 5y ago

> Lack of adoption of new technology > Rushing to adopt immature technology How do you balance such things (and under/over engineering, good enough vs perfection)?

Datenstrom 5y ago
These are caused by this: > Lack of experienced team members, across all disciplines (lack of knowledge?) You learn to balance these things from being experienced enough to have shot yourself in the foot by each a few times, or having studied history enough and apprenticed under a expert who explained their decisions in detail. Edit: except in the case where the problem stems from management not listening to the experienced experts, in that case nothing you can do but leave really.