Copy
View this email in your browser
Like Vikings? Like Dungeons & Dragons? My campaign book, player options, and new monsters are available for pre-order. If you are interested, just head over here: https://arcanumworldscanada.pledgemanager.com/projects/raidersoftheserpentsea/participate/?ref=mail

The Lazy Designer: The Next Game

Chapter 6 (Part 2)


Accountability

This is a topic that does not directly relate to game engines but is centered around how a team builds games. I'm going to touch on the idea of accountability, starting with a general overview of what I like about accountability and why I think it is important and then digging into some specifics with my experiences in the game industry. Perhaps it may trigger you to think of methods in which the game building process itself might support transparency (or even obfuscate information, when necessary).

An Accountable World

When making a decision I need reasonable data beforehand. I read reviews on products before I buy them. I talk to those I know who own the product. I visit the company's website and look at how they engage with consumers. Can I easily contact them? Do they respond?
I like systems that make individuals and companies accessible to me. I like the promise of accountability.
After leaving BioWare, several factors drew me towards joining the Empire Avenue team as a consultant. I knew some of the team members from having worked with them at BioWare. I also enjoyed the 'buy' mechanic that introduced me to many interesting people around the world. And I like the implicit accountability system.
I reward users by buying shares in them. Because I can read a user's content streams (their twitter and their blogs) I can make a judgment... is this somebody I support?

An Accountable Team

Why is accountability important to game development? After having worked years in the game design industry I have seen the damage that poorly designed infrastructure, misguided direction, and secrecy inflicts.
How do we create an accountable environment?

The Pipeline

The data pipeline — from creation to manipulation to insertion into the game world — the pipeline is the path data takes from creation to usability. At first it might seem hard to associate the pipeline with the concept of accountability discussed above. But a weak pipeline wreaks havoc on the game development process because it hides the mistakes creators make.
A common error I saw was data being mangled. Basically an artist or a designer built content then pushed it to the pipeline and along the way it became garbled. At best this would create a hard-to-catch bug in the game. At worst it might bring the entire build down, making it impossible for quality assurance to playtest the latest build or content producers to add and test their new content.
Very often the build was garbled because the creator of the content had made a mistake in its creation.
So how do we make the pipeline accountable? First the pipeline should be able to detect that garbled data is going to be generated... trying to limit corrupt data from entering the pipeline. Secondly it should inform the user of what might have caused the error so that they can efficiently correct it.
Still problems might remain (and it is not always desirable to put too many delays in pushing new resources into the pipeline). Only the creator knows an error has occurred at this point. This might not seem like a major issue (after all the user is fixing things, right?) but often individuals try to cover up repeated errors because there's an assumption that I'm doing it wrong.
But sometimes they are not doing anything wrong. Sometimes the pipeline is at fault and is misrepresenting the problem. The users assume they — not the process — are the problem. And so they try again and again and again... when in reality the actual issue might be simple for a programmer to solve.
This is why I feel it is important to log changes (and especially failures). This log should be accessible by the entire team. This is not about shaming. The primary goal of the list is not for departments or managers to single out an individual who constantly makes mistakes (though we should understand as employees we do have an obligation to reduce failures in our own work, especially failures that affect the entire team). The primary goal is to improve the pipeline.
A dedicated pipeline programmer can examine the logs and determine if particular individuals are having problems submitting content. Examining the details they might realize there's a configuration issue on that user's machine and its not a user error at all! A frustrated artist might look at the logs and realize that all the artists working with a particular resource are having problems... something the programmer might not have caught. A manager might look at the logs and better realize why delays in her schedule are happening.
Visibility is important. Let the entire team work to repair pipeline problems.

Decisions

A similar process should be used with decision making. There should be a list of major decisions (especially when previous decisions and direction have been reversed). These turning points should be identified on the schedule. Those agreeing to the decision should be listed.
The entire team, if not the entire company, should have easy access to this information.
Yes, it creates headaches and invites arguments... individuals will feel compelled to point out what they consider to be flaws with the decision. But a team that has ownership over a product will work longer and harder than a team that is kept in the dark and working on a product they do not care about. And occasionally real solutions that were never thought of by the decision makers might emerge from the rest of the team. I've seen it happen.
Often a management team will hide their decision making process when they are not confident in the decisions they are making.
In all fairness this is not the only time decisions might be hidden. If a particular decision seems infused with the potential to cause a drawn out battle it might be wise to delay the decision announcement or to announce it with a "the matter is decided, there will be no discussion of it" sub note. While transparency can be beneficial we do have to be cautious that it does not lead to a conflict-charged environment where everybody debates everything and nobody makes games.

The Individual

As a team member you can help push for accountability by always being accountable yourself. Make it clear through whatever means your team is using what you are working on and the delays you are experiencing. If you need help to meet your deadlines, explore options. If there is a particular aspect of the pipeline or your work environment that is causing delays do not suffer in silence. Talk about it... whether with peers or management.
Problems never* fix themselves. I have seen many hard working developers banging their head against pipeline problems that could have been mitigated but instead the designer decided to live with the problem. Never accept that attitude in your team environment!
Okay, occasionally problems do fix themselves. But that's generally scary.

That's it

Accountability needs to be built into the core of the company. With it, I believe, that game development can become a less expensive and more satisfying experience, just as I believe the consumer-brand relationship can become more satisfying. Shoppers should know what they are getting into when they give their money to a brand; employees should understand the company that they are giving their time to.
Yes, I realize there's always a lack of manpower and a lack of money but adding accountability — presenting more data about how the team works to the entire team — is not expensive. More often than not with a little bit of extra light shone on the work they are doing the team will figure out and solve most of their own problems without incurring a great deal of additional overhead.

Caveat on Transparency

When I first released this section onto my blog a reader left a well informed comment listing some situations in which transparency is ill advised. Many of these I do agree with, such as the need to hide employee information (compensation and performance reviews) from other employees. This personal information when openly available does introduce the risk of dividing employees, which is never what we want. We are all human and prone to judging others, I know in the few situations that a team member learned about other team member's compensatory bonuses, for example, that it lead to unhappy employees and some in-fighting.
So do assess the potential fallout of revealed information. Primarily in this section I was focusing on shedding light on decision making and the game development pipeline.
In the next newsletter, we compare the pipelines of a couple games, starting with that of Baldur's Gate 2, the first videogame I was a designer on. Thanks for reading, please let me know if you have any feedback!
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Copyright © 2022 YourOtherMind Media, All rights reserved.


Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp