Video Game Project Management Anti-Patterns [pdf](arxiv.org)
arxiv.org
Video Game Project Management Anti-Patterns [pdf]
https://arxiv.org/abs/2202.06183
45 comments
> Lack of adoption of new technology
> Rushing to adopt immature technology
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.
> 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]
Most of what you describe sounds like production problems, which were explicitly ignored by the paper (they focused on feature management and people management).
> 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).
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).
>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.
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 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.
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.
> 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.)
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.)
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.
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.
That's fair, and those sorts of projects were _super_ common back in the UE3 era. That working model is also how most Unity projects are done - pick a version and stick to it.
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)
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)
Off the shelf vs. build your own is a trade off. Most organizations don't think through this trade off very well and hence both are anti-patterns because the result of the tradeoff can be bad either way.
We've reached a point where every AAA game is using the same Unreal engine version, with the same middleware components, and everything looks the same. I'm not sure this is really an improvement.
Is not like the previous games from Bethesda were looking much better using gamebryo, which is also the basis for their own engine.
Interesting paper. However, the "solutions" to some of the problems aren't really useful - e.g., the problem of excess scope has the solution of "reduce scope"; and the problem of under-estimated tasks has the solution of "estimate better".
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...
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...
Especially as reduced scope might torpedo the entire reason for the game to exist. A buggy game with a large scope may be orders of magnitude more successful than a well made small game.
Yeah - it's a lot easier to reduce scope when you're building a tool for people to do work with. You ask "can they do the job with this tool" and cut anything superfluous for the first release.
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.
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 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.
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.
Not every game's goal is to build an immersive world. And polish and scope are related but not the same thing - in fact the argument is often that with a small core you can afford to polish what you have a lot more.
Where does StarCitizen fit in there? It feels like such a good example I have to ask the question.
Star Citizen is a great example of how subjective all this is. Features have been delivered that most game developers would not even attempt. If your primary goal is smooth, polished, predictable progress then your scope and potential features will be more limited. In the case of Star Citizen it has a large player base even at the current extended alpha state.
I'd assume it has a lot to do with decisions made at the top (see track record): https://en.wikipedia.org/wiki/Chris_Roberts_(video_game_deve... (Disclaimer: I don't know the guy's management techniques or specifics, it's just a guess)
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.
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.
Sometimes there are exceptions to the rule. Star Citizen is definitely an outlier.
As someone who has played a lot of games (due to health issues), that is one kind of thinking that gives the whole industry a really scammy feeling. It only works because refunding is still frequently not possible. I'd much rather play a shorter game that works than a long buggy mess.
I don't disagree.
Or more recently, because you promised said scope in a kickstarter/early access phase.
This does not seem to apply to AAA companies marketing, for some reason.
This does not seem to apply to AAA companies marketing, for some reason.
I've had this happen to a lot of my hobby game projects. At first, the scope is too large because I have pie-in-the-sky ideas. I then recognize the large scope and try to pare down. Once I've reached something achievable, I find that it's basically a completely different game and doesn't seem fun anymore.
I've worked on a few different games and the one thing they've all had in common is that they are all still fun when you carve them back to their basic core loop. If your project wasn't fun at its core, it's unlikely to be fun when you've wrapped it in layers of other features
I don’t think that was the academic purpose of this paper - the point was to collect data and compare/map the problems/solutions present in software dev against game dev to see which universal mismanagement patterns are present in both, and which might be more unique to game dev. I imagine each problem/solution has plenty of its own research.
Estimates are always the elephant in the room. Especially large scope estimates. I don't think estimating more accurately is the solution, making software more predictable to write in the first place might be worthwhile. But the realistic solution is to manage around the practical reality that software estimates suck. Maybe don't plan release dates or milestones based on estimates, perhaps you could do it based on progress reports and a revised estimate after someone has actually started working on a task.
Underestimated Tasks
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.
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.
I'm on my third attempt to get (kinda) the same game out in 10 years,
I actually have a shot now (better design, reduced scope, better effects, loving companion).
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
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
It's too easy to fall into the trap of polishing to perfection, or going back to the drawing board.
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.
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.
Wait both adding and removing features are anti-patterns? Is waterfall the solution, then? Where finally we know exactly which features work well together before we write the first line of code?
Adding features means unplanned work whilst in development, and usually quite late in to development.
Removing features means wasted effort, hopefully at the design stage, but usually much later, after art has been created and code written.
Removing features means wasted effort, hopefully at the design stage, but usually much later, after art has been created and code written.
On the other hand, not adding important features you failed to plan for means leaving puddles of customer value on the floor.
Similarly, not removing unnecessary features means pouring even more wasted effort into something worth nothing.
Similarly, not removing unnecessary features means pouring even more wasted effort into something worth nothing.
Oh, I'm not saying these aspects don't have value, merely pointing out to the GP what they mean, and are not mutually exclusive on the same project.
Those are just items to blame when the game fails.
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.
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.
Hi guys. Author here (one of them). I'm so happy that the paper got here on HN without us doing anything. This is a big thing for researchers. Normally our papers end up in a dark corner of internet.
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
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
Super cool to see the paper! Given that some of the authors are in Montreal (a large video game development hub), do you think you'd ever continue this path with primary research?
Yes absolutely. Some of the authors are in the field since mid 2000s. As for me, I'm about to finish my PhD and try my luck researching game development. The dream is to build a video game research lab. But that might take some time.
Watched this documenatry [0] about the re-development (reboot) of "Killer Instinct":
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,"
[0] -https://www.youtube.com/watch?v=ks4eZoG94Vs
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,"
[0] -https://www.youtube.com/watch?v=ks4eZoG94Vs
[deleted]
How to read it?
Click the "PDF" link on the right, under "Download".
Or use this: https://arxiv.org/pdf/2202.06183
Or use this: https://arxiv.org/pdf/2202.06183
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: