How important is it for Firaxis to admit mistakes or acknowledge failure?

[Kenshiro70]

I’m a technical product manager myself

Ooh, a Tech PM. Not a common set of skills. Here's a question for you (and it's relevant to the discussion as a whole):

What are the risks to building on a single, standards-based tech stack that needs to be deployed across multiple platforms?

(Hint: think holistically - it's not just about the game code)

Bonus question: Which of those risks do you think Firaxis anticipated?

 

[Core Imposter]

I am not a technical product manager but as a project manager delivering publicly funded neighborhood improvements in urban, suburban and rural areas you immediately risk discontent as you simply can't deliver the same utilization benefits to the differing architectural builds and population profiles. Inevitably you have to adjust your product to meet expectations of equity and fairness. So, you are building at a level that could be described as the lowest common denominator and leaving a lot of value on the table in terms of what you could have delivered for certain groups. And this is magnified by the scope and scale of the project because everything evolves in time and the whole build has to land on a moving target.

If you push ahead and maximize benefits to those who could utilize them, you will lose the rest, so your choice is to do a bang up job for some or a mediocre job for everyone. Politics requires the mediocre route. Now we must decide if Firaxis was bent and guided by some overarching mandate or had the luxury of optimal design.

 

[Kenshiro70]

You've just nailed a major risk - Least Common Denominator (LCD). And LCD has multiple flavors:

1. UI - the most obvious one, but since consoles don't really have the concept of a "hover" action, that would explain why tool tips were so anemic at the start. And that's just one of many UI issues we've all seen.
2. Resources - map sizes were dictated by the constraints of a ten-year-old processor (the Switch 1 Tegra chip), and probably AI capabilities as well.
3. Security - consoles have built-in security to lock down assets so that you can't make free versions of paid content (i.e., copies of paid leaders). Uh oh, PC's don't. Hello Denuvo!
4. QA - testing code on multiple platforms is resource-intensive (=requires development of platform-specific automated test harnesses plus test scripting). But what if we ensure most of our "patches" are really just stat changes? Easy peasy!

There's more risks, of course, but hopefully that's enough to illustrate the subtle yet powerful impact that the "single stack" development decision had. And while enterprise software companies have Architects tasked with understanding the risks of those approaches, game companies generally don't. It's very likely that Firaxis found those out far into development, too late to change course, with the end result being that the issues ended up contorting the game.

Take from this what you will; my primary point is that the issue of blame and accountability is not as black and white as it first seems.

 

[protocol7]

Yep! Sorry I’m late to reply but it’s the quirks of every system. The abstraction library you’re using probably blurs them and supports the least common denominator. Anything nice and unique to any platform gets unsupported.

And at the same time, the quirks of each system mean system specific bugs come up anyway, and you can spend all your time fixing them even though you’re using a cross-compatible (in theory) library. If you don’t control the library, you’re waiting on someone to fix them. If you can fix them because it’s open source for example, then you’re spending time working on a compat library instead of your game.

It’s a trade off but one that would have been understood going into it, not something they were the first people ever to discover

 

[stealth_nsk]

Firing decision makers for making poor decisions around shipping early seems like a great way to send a message and make it clear to your decision makers that you aren’t the kind of company that makes poor short-term decisions around shipping games early, if you accidentally became one by hiring people who think that way.

I’m a technical product manager myself, and would expect to be held accountable if I made some terrible product decisions. The reason this is important, including applying the same rule to myself, is because the worst places I’ve ever worked are ones where people with poor decision making or execution skills get moved around and/or protected instead of dealt with. It’s a sure way to end up on a crap product death spiral.

The only person who said anything about developers is you, and you’re the one who decided their argument can be discarded except the part about developers, so it kind of seems like you’ve made something up to be mad at in your message telling everyone to chill.

But anyway, the main point was learning from mistakes. These are just my opinions on holding teams accountable, which was a tangent in the first place, and others may disagree. The person we are replying to said something much more interesting than something that boils down to firing developers. Especially since they didn’t even say that.

Oh, I somehow missed this post. I currently work as tech PM myself.

I have quite opposite opinion on the topic. Companies which fire people for their mistakes, cultivate "play it safe" culture, where people never make bold decisions. To learn from mistakes, the company needs to allow making mistakes in the first place.

The reason for firing people should be professional incompetence, not mistakes. It's much harder to assess, but it results in much healthier results.

P.S. The best surgeons usually have highest death rate among their patients, because they deal with the most difficult cases.

 

[protocol7]

I’d have categorised this as professional incompetence, but otherwise agree with you.

 

[Kenshiro70]

Yep! Sorry I’m late to reply but it’s the quirks of every system. The abstraction library you’re using probably blurs them and supports the least common denominator. Anything nice and unique to any platform gets unsupported.

Sure, and that's the point - write once, deploy everywhere. As they aren't a shooter game there's a much less pressing need to optimize framerates by using platform-specific features.

And at the same time, the quirks of each system mean system specific bugs come up anyway, and you can spend all your time fixing them even though you’re using a cross-compatible (in theory) library.

Yes, and not just bugs but even tiny differences in implementation that only matter in certain situations (and may not have been encountered by other users) can come into play. And suddenly you have a tech tree with arrows that don't line up.

It’s a trade off but one that would have been understood going into it, not something they were the first people ever to discover

Some of the issues would have been known. And if they had been using the libraries in isolation, they'd have been fine. Combine multiple libraries and the number of users with a similar setup quickly dwindles. Then you're in uncharted territory because of the interactions that come into play.

When you do platform work you are upstream from everything and the impact radiates out to all aspects of game development. You've nailed some of the key code-related risks. What are the non-code risks? Those can be just as impactful to the released game as the code-related risks. It should be a fairly easy question to answer - as you say you wouldn't be the first to discover them.

 

[Kenshiro70]

Oh, I somehow missed this post. I currently work as tech PM myself.

Wow, lightning strikes twice. Feel free to chime in on the question I posed on the risks of a cross-platform development tech stack. The more you look the more you realize it had a non-trivial impact on the game as a whole.

 

[protocol7]

Maybe just say what’s on your mind directly?

 

[Kenshiro70]

Maybe just say what’s on your mind directly?

Because the concepts are much more meaningful when you work them out for yourself, and they apply not only to Civ VII but also can be used in your day job.

And I've got not one but two sharp Tech PMs who can demonstrate to people why the Tech PM role is so critical. I couldn't possibly pass up an opportunity like that.

 

[stealth_nsk]

Wow, lightning strikes twice. Feel free to chime in on the question I posed on the risks of a cross-platform development tech stack. The more you look the more you realize it had a non-trivial impact on the game as a whole.

I'd just add that it's a matter of strategic decision. From the announce, Civ7 has huge focus on consoles and multiplayer. To me it looks like they are aiming to increase their audience through those directions and as I said, it's too early to tell how bad this aiming was.

What I haven't discussed already is how good aiming with Switch 2 was. Since Firaxis worked with Nintendo, I guess they knew about S2 release before official announcement and I wouldn't be surprised if one of the factors to release Civ7 in February was to have some sales for both S1 and S2. I wouldn't be surprised if lower priority for larger maps was also aligned with Switch releases. Anyway, S2 is a superhit already and Civ7 is one of the few games which let players get maximum out of it.

So, from strategic point of view, I don't see mistakes at all. I see bold and interesting strategic decisions, which led to some negative consequences which company now have to face.

 

[kaspergm]

I'll still stick to my opinion that the problem with the game is not that it was shipped early. The problem is it was build around a bad core design idea. But either way, changing the developers moving forward would probably be a good move. Not necessarily because they did a bad job with Civ7, but because Civ7 highlights the fact that when you have the same people develop three iterations of the same game in a row, there's a big risk they start to become tired of the game and want to liberate their creativity in ways that is not ... healthy ... for the franchise.

And don't get me wrong, I fully understand that the developers want to make a new game after having worked on Civ for more than a decade, but then they should move on to making a new game instead of changing the existing game in order to satisfy their creative itch.

 

[Askia Muhammad]

They acknowledged their more experimental features didn’t “land as well as they believed” (not exact quote) in their June check-in. I don’t think it’s going to do anything to help. They just need to keep the updates coming and making as many of the less popular features either optional and/or customizable as possible.

 

[UWHabs]

I'll still stick to my opinion that the problem with the game is not that it was shipped early. The problem is it was build around a bad core design idea. But either way, changing the developers moving forward would probably be a good move. Not necessarily because they did a bad job with Civ7, but because Civ7 highlights the fact that when you have the same people develop three iterations of the same game in a row, there's a big risk they start to become tired of the game and want to liberate their creativity in ways that is not ... healthy ... for the franchise.

And don't get me wrong, I fully understand that the developers want to make a new game after having worked on Civ for more than a decade, but then they should move on to making a new game instead of changing the existing game in order to satisfy their creative itch.

It is slightly ironic that the biggest complaints are probably areas which strayed further from the traditional civ mold, which you usually associate with fresh blood not familiar with the franchise, and not a dev team that's been there for a long time. But yeah, maybe your point being that since they already had their like 10-15 years with the franchise before, they maybe tried to shake it up too much, if only to not be accused of making "civ 6.5" and being "too safe", and that landed hard.

 

[TylertheDestroyer]

I'd just add that it's a matter of strategic decision. From the announce, Civ7 has huge focus on consoles and multiplayer. To me it looks like they are aiming to increase their audience through those directions and as I said, it's too early to tell how bad this aiming was.

What I haven't discussed already is how good aiming with Switch 2 was. Since Firaxis worked with Nintendo, I guess they knew about S2 release before official announcement and I wouldn't be surprised if one of the factors to release Civ7 in February was to have some sales for both S1 and S2. I wouldn't be surprised if lower priority for larger maps was also aligned with Switch releases. Anyway, S2 is a superhit already and Civ7 is one of the few games which let players get maximum out of it.

So, from strategic point of view, I don't see mistakes at all. I see bold and interesting strategic decisions, which led to some negative consequences which company now have to face.

No it's not, look at the player counts and user reviews...

We don't have to wait to realize that a vast majority of people buying Civ games are not buying them for multiplayer, just like we don't need time to reveal that Firxais has not increased the series' audience.... they're actually doing the opposite. This game is no where on the charts for best selling Switch 2 titles either.

Your "bold and interesting" strategic point of view seems to be to excuse Firaxis for all the obvious mistakes and poor choices they've made, I don't think 2K's shareholders are going to share the same enthuasism.

 

[aelf]

It is slightly ironic that the biggest complaints are probably areas which strayed further from the traditional civ mold, which you usually associate with fresh blood not familiar with the franchise, and not a dev team that's been there for a long time. But yeah, maybe your point being that since they already had their like 10-15 years with the franchise before, they maybe tried to shake it up too much, if only to not be accused of making "civ 6.5" and being "too safe", and that landed hard.

Since they had a long lead time for development, they were probably also worried about being out competed if they went to market with an offering that could be seen as stale by then. That kind of consideration does come into play in managing a product.