Video Game Project Management Anti-Patterns [pdf]
arxiv.org
arxiv.org
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?) > Lack of adoption of new technology
> Rushing to adopt immature technology
> 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.
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).
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.
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.)
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.
From Epic's side, UE at this stage is pretty customisable even without modifying engine source directly. You _can_ modify the source, but it's not a requirement to make a game in UE these days; much of what you needed to modify the engine for can be done with plugins or just straight up in game code.
> These days for many projects it’s more about how much the underlying features you’re using have changed.
Yeah, definitely this. Epic in particular have also become more mindful about not pulling the rug out from under you (although it does still occasionally happen)
i guess it's useful to know the failure modes of projects, but would really like a real study on how projects that succeed navigate away from failure modes.
use google viewer if you don't want to download the pdf directly: https://docs.google.com/viewerng/viewer?url=arxiv.org/pdf/22...
What is necessary in a game is much less clear cut.
I feel like the trend towards minimalism in game design is a little misguided. When you're building a world for people to be immersed in little "unnecessary" features, or roadblocks, or redundancies in both setting and gameplay can make that world feel more real and engaging.
I think it depends, I for example hate "Extreme" realism, like for example in Kingdom Come: Deliverance picking flowers includes a lengthy animation, in Dragon Age Inquisition picking resources has the same flaw, first mods that appear attempt to speed the animation, or remove it... why do we need a grind simulator in this games, this would make sense in farming simulator maybe, as an option because it feels I am force to waste time doing repetitive things that are not enjoyable.
Crowdfunding is great when no VC will fund your track record. But it leads to even less incentive to produce a ROI. You can see evidence of this same pattern in the crypto ICO wave of 2017, where the business endgame was usually the raise, not the exit.
This does not seem to apply to AAA companies marketing, for some reason.
Feature Creep
Death March
Feature Cuts
Understaffed Team
Underbudgeted Project
Neglected [...] Design
Working on Multiple Projects
Yep, pretty much sums up my career, so far.
But sometimes I wonder if Jeff Vogel might be right when he says "please do something else with your life if you're not crazy about games" XD
I found working with Pico-8 pretty liberating, in that you're really limited in your options and toolkit. I'd get stuck in analysis paralysis if I were to build a game, I think.
Removing features means wasted effort, hopefully at the design stage, but usually much later, after art has been created and code written.
Similarly, not removing unnecessary features means pouring even more wasted effort into something worth nothing.
Scenario: One team in the project is under delivering. Cut scope and the game fails due to missing vital features, "the game failed since we cut the scope!". Don't cut scope and the game fails due to bugs or delays "the game failed since we didn't cut scope!". Both of those are the wrong answer, its just that people don't want to admit the real answer here.
This paper is a pre-print. We submit it to a workshop (GAS2022) and it is still in process of peer-review. So it will have many more changes until get accepted. Including some suggestions from here :D
Description from the link below:
"Killer Instinct is a fighting game seiries treasured by many and with its unique combat mechanics and cast of characters, it easily set itself apart from its contemporaries. And while Killer Instinct made a triumphant return in 2013, the road there was anything but easy,"
Or use this: https://arxiv.org/pdf/2202.06183