Biases in production
We make decisions each second. In the process of developing and marketing games, the quality of these decisions can have huge impacts. As flawed human beings, we all possess a variety of prejudices, make snap judgments, and base decisions more of feeling, rather than pure rationality. There are rigorous experiments done in the domain of behavioral economic decision-making, and sources for them are provided at the end. These are cognitive mistakes we are prone to even if we are aware of them. Why? It’s because we are human beings and emotions, and impulses outcries are part of us, and they make us who we are.
In the early 1970s, Amos Tversky and Daniel Kahneman introduced the term ‘cognitive bias’ to describe people's systematic but purportedly flawed patterns of responses to judgment and decision problems (source Science Direct).
Below I will try to use what I’ve learned and put it to the test (in some cases being wrong, without even knowing it). Still, I believe, rationality and critical thinking should be the main drivers in decision-making when working on games.
You probably read, heard, or discussed some of this along your path, so what I’ll try to do in this post to provide a practical case on what can happen in game development and collaborations in the industry
Framework: Decisions related to the game creation process - Choosing backlog items to work on in a Sprint, design and feature choices, negotiating an art style, UI placement, tools and processes used in the development, improvements to “n”- and business decisions (see Demarcation article) - negotiations of milestone delivery dates, deliverables required for each milestone, marketing initiatives, resource distribution, budget negotiations between parties and so on. My approach for deconstructing these biases in five parts is as follows. For easier visualization of the teams I’m speaking of, below are examples of an indie game studio and publisher
Game developer: A small studio, working on its next success story and trying to find the right publisher ready to help them achieve it. The team covers all aspects to get the game market ready (outsource contractors are available as well). It is not their first development rodeo, they worked on games and for other studios before.
Game Publisher: The publisher has employees across all departments - production, design, art, localization, marketing, user acquisition, and so on. A stakeholder from each department is present and has ownership over a particular area of expertise, while the executives provide the final say on any decision that has been agreed upon.
The examples below are meant to have a comedic tone are (sometimes) absurd. I hope it can bring an “Aha” moment to the reader
Fundamental Attribution Error - it is easy to assign faults to individuals, teams, departments, and groups hastly, without introspection. So next time when a feature didn’t play out or a deadline was missed, before assigning the blame game - accountability and responsibility - think if it wasn’t a hasty decision to do it.
Game dev example: Mia wrote a bad script that “Needs to be corrected because she never listens and has an inflated ego”. Angelo forgot that in the previous Sprints he had a similar hick-up, but in his rationale, it only happens to him when running late to an appointment.
Self-Serving Bias - I’m leading this initiative (new feature, marketing campaign, design choice, etc.) and the fact is - It is great because I took charge of it. In case it works out, there’s no chance of a random event ever contributed to its success - experience, hard work, and expertise led to the result. Now if the initiative failed, it’s because the market and players didn’t respond well to it, it was in fact “Mary and Joe that pushed me to do it.”
In-group favoritism - Imagine the game developer and publisher debating presented above (this happens within teams as well). A design choice or milestone delivery date is being debated. While it is a win-win collaboration, both parties can sometimes be at fault, due to the protection and rationalization “our way of doing things” in their company, and team. Thus each tribe will most likely support their group’s arguments, while trying to negate the “outsider side” of the argument.
Bandwagon effect - the Hypercasual growthtrend, Vampire Survivors massive appeal lead to many teams to try their mettle in developing and publishing them. It’s easy to find ideas - a monetization feature, gameplay mechanic, game jenre (Battle royalePub bandwagon) that just seem to lead to success. Devs and publisher spend a huge chunk of time, to work on something just because of it’s mass appeal. It’s not a bad idea to jump on the bandwagon, if it is Be very careful when jumping on the band wagon, as it can lead you to stack your chips in one pot , meaning it is very context dependent. Maybe you should stick to what your team’s specific knowledge is good at. When thinking to copy or reproduce, remember no two teams are alike.
Groupthink - as part of an interconnected world (modernity) where game developers and publishers can work together across oceans and time zones, groupthink becomes an ever-present bias. We want to have a deep skill try and great customization and narrative component, everyone thinks so, except you. In conflict-avoidance cultures, it can come in a variety of ways - the majority of the designers from my team think so, the boss said so and we “align in decisions”, yes “I don’t want to say this feature is above our current skill-set, because I will stand out”. All decision comes with upsides and downsides. One approach to contain this bias is called aggregated independent judgments - each stakeholder taking part in a decision makes up their own mind on a topic, and only after verifying it with the group.
Halo Effect - We all have people that we look up to, and they have some influence on the way we make decisions in a certain domain. This can be a co-worker, games industry personality, journalist, Streamer, teams, and companies, that you really like (or hate). Mara believes George is a great artist, not just because they are close friends. Objectively speaking he made all the right calls in terms of the visual style of the game. Maybe he is too hands-on and too harsh on the lightning effects, wants the Chapter IV story ark to be rewritten, and the promotional trailer… he is never wrong, right? We can be biased towards seeing those we care about or have a dependency with, someone they are not in all circumstances. Context matters. Just because Jon Romero said so, you shouldn’t go off running implementing, and doing everything that resembles his approach. really like.
False Consensus - beliefs in game developement are highly subjective matter. Let’s take the belief of the “majority rule” that leads to the “right course of action”, approved by all. I don’t want to speak against this decision, taken in the department I work in (especially if it comes from someone with a position of authority or experience), because disturbing the consensus would make her appear as “divirgent from the group’s” position.
Developer interview upon a game’s release example: We should not have done this feature, but the entire team was on board with it, except Josh (he quit). Now it just seems like a waste of time, nobody uses multiplayer in our story-focused single-player game.
Curse of Knowledge - Have you ever had valuable knowledge to share, but never had the right words to put your idea out there, assuming the person you’re talking to is “on the same page”? For example: “I thought you knew you how to write the script, directly in the backend tool. This way it wouldn’t be required to create prefabs instances in Unity, as you could’ve just placed all the inventory items in the JSON. Now we need to redo everything so it works as expected” - said the senior programmer to the junior. “OMG it’s so simple, I thought you knew that.” No AI will replace decent communication between colleagues. Abstractions don’t help Juniors to create better working code, art, presentations, docs, roadmaps, etc. Don’t assume people have the same level of understanding as you, just because of their Job description. Approach any “task” as a new experience, and where knowledge is the same aligns. Otherwise, take a minute or two to explain.
Image source: 50 Cognitive Biases
Credits: Artwork created by Tanya Timosina
