fjaoaoaoao
Chieftain
- Joined
- Oct 27, 2014
- Messages
- 51
You're absolutely right; there's no black and white and people do wear multiple hats. But if I didn't de-duplicate, the number jumped to 34. Because it was such an important item, I scrutinized each of those 34 people individually when I winnowed them down to 12.
Also, I view Designers as the game industry equivalent of Product Managers on the enterprise side. At the end of the day, the requirements a PM documents and the gameplay mechanics a Designer creates become the authoritative statement on how the game plays. Both the PM and Designers are directing the engineers on the results they need to program to create. In effect, they are are "spending" a developer's time (=£££) when they do this. For that reason, there's only a limited number of people with that spend authorization.
As to the issue you raised around the ratio, fewer developers means they have less time to consider and deal with the exception cases. They spend most of their time handling the "golden path" case (i.e., when everything goes right), but when there are interactions with other systems, error conditions, and additional permutations (e.g., new Leaders and Civs) they don't have the time to anticipate those situations and create a robust solution in advance. Add in a brutal schedule, and it's very likely the code will need more upkeep later, which over time builds up a level of tech debt that slows down new development.
Sorry if I'm babbling on a bit - it's not every day that someone shows enough curiosity about these things that they'd be interested in discussing it. You made my day.![]()
I see the intended parallel between designer and product manager, and while that works as a general statement connecting to other abstractions, it sort of falls apart when trying to do a detailed analysis of a specific use case.
Also, a designer could very well be the one handling, analyzing, and communicating non-golden path scenarios.
Metadata: Amazing, but too much of a good thing
...This approach is enormously powerful, because it allows you to create and test new buildings quickly, as long as they follow the basic template. ...This is where you can get too much of a good thing. If you could make five new buildings by following the template versus adding a new attribute to the template, which would you do? Did I mention that you've got to get four civs delivered this month for the next DLC? So you can see how over time there starts to be a bias towards using the existing templates.The problem is that from the player's perspective, what a designer would call "template", the players call "cookie cutter". Humans are very good at pattern recognition, and if you overuse the existing cookie cutters, they'll notice. It doesn't matter if this cookie has sprinkles on it and that one has green food coloring if the basic recipe is the same.That's essentially what's happened with the Leaders and Civs. They've got too many "+1 Food on improvement adjacency" abilities instead of unique abilities. Open up the "leaders-gameeffects.xml" file and read through it, and you’ll see that I mean. In fact, if you look at the 1.1.0 and 1.1.1 patch notes, the majority of items were tuning of parameters rather than code changes.The end result is that Leaders feel like cheap knock-offs of one another. It's hurting replayability because they don't feel that different to play.The only way out of this trap is that Firaxis will have to ratchet back on the template usage and enforce a ratio of 2 template-based abilities allowed for every new unique code-based ability.
That over-reliance on metadata is one of the more subtle traps and reasons that designers and developers can fall into.
I see how overreliance on metadata can end up just being busy work for the designers, and I also think it's a fair argument to make that fixating on metadata encourages spitting out copycats. But that's just speculation as to what the devs are doing as well as speculating the impact of metadata on design. One could argue metadata could also very well free up time and cognitive space so they can more easily do other work, they just need to be conscious and deliberate in doing so. The inclusion of a possibility of a behavior doesn't automatically detract from the possibilities of other behaviors. It certainly influences a kind of design, and it's hard to argue against that happening here because of how the game came out, but my issue is the issue of onus. Who is influencing the design? In a large org that creates a legacy product for a large customer base, it is not merely those with design and developer titles. It feels a bit unfair to describe metadata is a trap or reason that a designer/developer falls into when there are also very clearly structural and environmental reasons that encourage it.
In other words, you are sort of posing metadata as a temptress that beguiles designers/developers and the designers/developers are not skilled enough to recognize this as an issue, rather than describing metadata as just a tool that they happened to overuse for design, not necessarily a reflection of their design or development skill. So I like the mention of metadata as it adds some insight into some potential pitfalls, but I feel the wording on this is too conclusive and a little bit uncharitable to the designers/devs.
Last edited:


