例如，《Words with Friends》：“不過是異步拼字遊戲罷了。”是的，正是如此，所以它成功了。
總而言之，以上就是我這些年見識過的開發人的個性的交流“技術”。多謝了在Epic、ChAIR和People Can Fly的同行們爲我提供的材料。我希望有遠見的開發人可以意識到這些問題，並相應地改正。我也希望此文能讓博得創意人員的會心一笑。
團隊成員之間的交流在遊戲開發過程中的作用不容小覷。有時候你得在3D Studio Max上完成工作，有時候又需要拿出來大家一起討論纔可能完成工作。
篇目1，Opinion: Negative developers and team stability
By Lee Winder
It doesn’t take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise morale and motivation. The following isn’t based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years.
Take of that what you will…
When you look at the make-up of a team, it will always be staffed by people who raise the game and by some who only bring it down. It’s the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It’s the individuality of these people who can take a project and make it fly or cause it to crash and burn.
One thing that’s clear is that it’s much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild-fire through a team whilst positivity acts more like treacle and can be much harder to spread around.
A negative attitude to work is a whole lot easier. Doing less, talking badly about the team, or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.
What defines a negative developer?
There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low-level complaining, pushing back against work requests for no good reason, or general slacking off during the day.
It could be a lack of skill development or even a backsliding in the quality of the work they are producing.
But it could also be an attitude that doesn’t gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it’s designed and implemented, and one or two developers will only work when they are told exactly what they need to do.
Maybe it’s a developer who doesn’t get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing.
At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They’re the ones who are difficult to deal with in usually many aspects of the development process…
Lets have a look at a few situations where a green developer is a ‘positive’ developer, red a ‘negative’ one.
In the first situation, we have two developers working side-by-side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don’t want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer.
In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard and not having to put in as much effort, will eventually start to slow down and equalize with the poorer developer.
It’s much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one.
When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn’t very encouraging.
Take the following situation:
Theres a tight balance here, but since it’s much easier for a developer to reduce the quality of their work rather than improve it, it’s easier to slide the wrong way, and at that point it’s very easy to see where this will go.
Based on a number of observations, it seems at though while a 3:1 ratio might get you some good results, it still brings risks because should one developer start to slip, it then becomes 1:1, which puts us right back at the start.
In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases, the negative developer didn’t change their attitude without help, but other developers didn’t slip due to the peer pressure of the other better developers.
But in all these situations, I’m not giving these positive developers enough credit. A good developer won’t always slack, they’ll continue working hard, producing great content and generally continue to fly high.
But take the following situation…
These developers are good for a reason, be that personal pride, ambition, or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable.
Great developers won’t stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave, you have a much higher chance of those left realizing they don’t need to actually work that hard to get through the day.
Solving the problem
There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you’re working in a region with sane labor laws.
Just drop them.
To be honest, I wouldn’t recommend this anyway. Simply letting someone go generally removes the problem, but it can leave a lot of holes on the team, and you hired this person for a reason, why not try and get that spark back?
Performance Management structures (you do have a Performance Management process don’t you?) within an organization can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team.
Identify the source of the problem. Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated, or do they just not want to be there?
Depending on what their answers are, you’ll have a good idea of where to go next.
Make sure goals are set. Define goals designed to turn the situation around, but don’t just set and forget about them (which happens far to often). Monitor them on a weekly or bi-weekly basis, setting very short-term goals to complement the longer term ones.
Define a fixed period of time. Don’t just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious.
Make it clear what the end results will be. Whether they are the chance to work on something different or whether it’s a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed.
Keep constant records. Make sure every meeting is documented and the progress or results of all the goals are recorded daily.
Let them go. While it is drastic, if improvements are not being made given all the opportunities you’ve given them, then there really is no other option. If you’ve bent over backwards to try and solve the problem and the developer hasn’t taken you up on the offer, then there really is nowhere else to go.
And even with those sane labor laws, the documentation you’ve been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn’t want the help.
So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers. Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalize at a level far below where they need to be or will simply leave.
It’s vital that as a group these developers are tackled fast, rather than when their effects start to be felt.
篇目2，Cliff Bleszinski’s Game Developer Flashcards
by Cliff Bleszinski
As of this summer, I’ll have been making games for 20 years professionally. I’ve led the design on character mascot platform games, first-person shooters, single-player campaigns, multiplayer experiences, and much more. I’ve worked with some of the most amazing programmers, artists, animators, writers, and producers around. Throughout this time period, I’ve noticed patterns in how we, as creative professionals, tend to communicate.
I’ve learned that while developers are incredibly intelligent, they can sometimes be a bit insecure about how smart they are compared to their peers. I’ve seen developer message boards tear apart billion-dollar franchises, indie darlings, and everything in between by overanalyzing and nitpicking. We always want to prove that we thought of an idea before anyone else, or we will cite a case in which an idea has been attempted, succeeded, failed, or been played out.
In short, this article identifies communication techniques that are often used in discussions, arguments, and debates among game developers in order to “win” said conversations.
These observations and monikers are not meant to be antagonistic; in fact, several of the approaches mentioned here are employed because of valid reasoning. For example, pattern matching can be a good way of avoiding making derivative products, and sometimes an edge case can, in fact, kill a solid idea. So here are my Game Developer Communication “Flashcards.”
“Pattern Match Dismissal”
This is when a developer immediately runs through his gaming/pop culture library in his head and finds the closest thing to compare it to (often, a bad or failed example) in order to shoot it down.
For example, in regards to Avatar, “You want to make a movie about blue people in a forest with a bad military and mechs? What, Smurf Ferngully Aliens?” The Gears of War franchise, pitched improperly, could be seen as the old ’80s schlock horror movie C.H.U.D.
This refers to using an edge case to block a potentially awesome idea. i.e., an Edge Blocker would shoot down the idea of having giant worlds in Skyrim because of a concern that you’d have to trek back to where you came from and that all that walking would get old. Obvious and clear fixes such as the gameism of “fast travel” can easily solve this issue, allowing for huge worlds.
Edge Blocking has variants:
“The Networker.” This is a way of shooting down an idea because it won’t work in an edge case or unique co-op situation — this is a variant of Edge Blocking. “How would Max Payne slo-mo work in co-op? Impossible!”
“Perfectionist.” Similar to Edge Blocking, this is when a developer finds one instance whereas a cool feature might not look absolutely perfect, e.g., an amazing melee move that occasionally will result in some minor clipping of characters into one another.
“Ne’er Do Well”
Or “I’ve never seen that feature done before, or done well. Therefore, we shouldn’t do it.” This one is pretty self-explanatory, and, in fact, can be the reason why an idea should be done. Following this logic only leads to “me-too” creation.
As a reference, a Locust population from the underground in Gears of War worked for many reasons, but we still had reservations about it. In the end, it helped differentiate the franchise from others that featured the usual aliens-from-above/space.
Most developers tend to use this technique, even when they believe in an idea, as a form of covering their ass. Often used by lawyers.
“It’s just X+Y”
This is when a developer dismisses another successful product, sour grapes style, because he can easily see the formula. The fact that the formula is so simple and obvious is often why said product is so successful.
For example, Words with Friends: “It’s just asynchronous Scrabble.” Yes, it is, and it’s brilliant.
This occurs when a developer hears an idea — good or bad — and says that it will fit nicely into a later version or sequel. This is code-speak for “I don’t think that idea is worth doing, so we’re going to shoot it down by saying we’ll do it later in order to make you feel better.”
“Toppling,” a.k.a. “Tower of Babel”
This technique is when a developer adds too many bells and whistles to a feature that was pitched as simple, but ultimately jeopardizes the feature altogether due to these additions. The feature “topples” under its own weight.
“Think of the Children!”
This is otherwise known as “Cascading Dependencies.” The tendency is to shoot down an idea because it will cause more work for other departments, such as animation, UI, or art. Often, features that are interesting and/or worth doing have these sorts of ramifications as they combine all disciplines.
This is a commonly-used term for the technique of over-thinking things to the point where nothing is actually done.
“Why Even Try?”
In other words, “How do we even compete?” Intimidated by the immense competition in any given space, a developer asks this as a way of giving up before even giving it the “old college try.”
“They Have N Developers!”
This is a phrase that is often used by a developer to cite a competitive team and how large their staff is on their game, and is used as a way of leading to “why even try?” The Epic Way has always been to put the best people on a task, with the best tools in the business, in order to work smarter.
“But this is how we’ve always done it!” In entertainment, and particularly in technology, innovation and re-thinking things is often quite necessary in order to stay alive. Becoming complacent and doing things the same way over and over again is a surefire way to induce failure.
Being a 20-year veteran of any regular business may be an advantage, but in technology, it can sometimes limit you. As a developer gets older, it’s crucial to keep an open mind and to always be learning.
“But We’re (Insert Studio Name)”
This is the battle cry of a studio that is ready to rest on its laurels due to a certain level of success and thinking they’re badasses. The moment folks at a studio start saying this, one can count the days until the studio implodes, because a younger, hungrier crew out there wants what you have and is willing to dream and make it happen.
“We Tried That Before”
Citing a previous failed attempt at an idea in order to kill a new (and potentially workable) permutation of said idea.
Your idea is great! In fact, it’s too cool and innovative. Therefore, we shouldn’t do it, because it sounds like a lot of work.
This is when a developer uses forms of jargon only native to his discipline in order to win an argument with a developer of a different discipline, e.g., a coder using code-speak to an artist, or a designer using designer lingo to an animator.
“The Tribal Leader”
This happens when developer believes in his discipline (art, code, design, etc.) over any other in the studio, so fuck those other guys.
“That idea is great but isn’t within the scope of the project.” Sometimes, the best features are the fringe ones that sneak in under the radar and not on the original schedule, unfortunately.
This is when a developer fails with a new feature or weapon and loudly suggests “balancing” it by changing it during a playtest, therefore often getting his way. Sometimes, people just suck with a sniper rifle and get destroyed by others, and that’s okay.
This is the person who hears your idea, seems like they didn’t initially hear it, then re-pitches the same exact idea in their own words as their own, forgetting where they originally heard it. This ultimately doesn’t really matter, as long as the cool idea comes from somewhere and is implemented well!
“Filibuster,” or “TL;DR Guy”
This is the person who responds to a design suggestion or discussion with three-page emails.
Eventually, you make a custom filter for this person.
This is the person who almost always seems to come across as a total asshole in email, even when they don’t really mean to because, frankly, email sucks.
This is a person who somehow manages to shut down all progress on an idea and comes up with his own completely new pitch that is subjectively better or worse, essentially trying to make everyone start over.
Someone who rejects an idea without having any sort of clear reason why: “I don’t know about that…” Often useful against the…
A designer who has a rush of excitement about an idea, but hasn’t thought through it fully in regards to its design and/or ramifications. Said designer simply expects everyone to have faith that the idea will wind up good instead of properly making the case for it. This is often common behavior with a younger, less experienced designer. Similar to…
This is when a designer refuses to admit that an idea just isn’t panning out, while endlessly iterating on it, using precious code and art resources, assuming someday, one day, it will be fun.
This an argument used that goes as such: “This chart of loosely related and completely unbiased data shows how your idea will never succeed, you’ll offend lots of folks, and it’s a direction we cannot afford to go in.”
This is a technique used by a coder in which said coder refuses to understand the pitched/desired feature until it is requested in the exact specific manner the coder wants to hear it.
The developer who intentionally (or unintentionally) misses the obvious and starves a potentially good feature until it is cut.
“Not My Idea, Not Going to Do It”
This is when a designer takes input from others and claims to want a call for ideas, yet quietly ignores anything he didn’t come up with himself.
The Gardener plants the seed of an idea early and then brings it up again many times in meetings and in casual conversations with individuals around the office. Eventually, the idea starts to take root and grows on people until it becomes an actual feature in the game and no one can remember where the idea came from in the first place. This is actually a very useful technique.
“Obvious Bug Guy”
This is when a developer is being shown a work in progress feature and, instead of thinking about where the feature is headed or what it can do, feels the need to point out obviously broken things that will clearly get fixed eventually, like Z-fighting.
This when a person has no clear, obvious boss or chain of command, and is often told by multiple people what he should be working or focusing on. One’s design director, executive producer and president may each have varying opinions about what to do, leaving said staff member confused.
This term refers to a spokesperson who pitches or promises a feature to the media, which puts the team on the hook to actually code said feature once they’ve gone public with it.
This is the term for the creative who wants to add whatever feature he saw in a recent popular game as a way of making the game better instead of trying other ways to innovate.
So, in conclusion, that’s the list of personalities and techniques that I’ve encountered throughout the years. Thanks to some of my peers at Epic, ChAIR, and People Can Fly for contributing to the list. I hope that aspiring developers can recognize these patterns and adjust accordingly, and I hope that established creatives are able to get a chuckle out of this.
篇目3，The Elimination of Waste: Lean Six Sigma applied toward Game Development
by Harvard Bonin
These days one must only search online to find many project management techniques that are prevalent within general software development but are not utilized often in game creation. While Scrum has made a strong push into game production, many other techniques remain on the sidelines. This is unfortunate since other methods from Traditional and Agile methodologies can be applied to our industry and could help yield positive results.
In this article I will not explain Lean Six Sigma in detail. There are plenty of materials available if you’re interested in pursuing further. Instead, I will focus on the core principles of Lean Six Sigma and show how it can apply to everyday game development.
LEAN SIX SIGMA PRIMER
Lean Six Sigma is a combination of two project management techniques called “Lean” and “Six Sigma”.
Lean: Focuses on delivering customer value efficiently above all other activities. Any activity that does not add value for the customer is removed from the process.
Six Sigma: Focuses on removing all defects and variation from the process.
In other words, both are seeking to eliminate “waste”. In Lean Six Sigma terms this waste is defined as “muda”. This is a Japanese term popularized by Toyota and means specifically “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”. Waste can appear in many ways. Idle time, rework, mismatched feature requirements, under and over communication, etc. Lean Six Sigma identifies eight (sometimes seven) types of waste.
There are many concepts underlying Lean Six Sigma. Entire development projects have been built around the techniques, equations and tools available within this framework but they are much too involved to explore in this short article. If you explore further you may notice that many of the concepts apply most directly to manufacturing. While this is true the core principles can still have a direct, positive impact on game production.
WHY WASTE MATTERS
In my experience, wasted opportunities are the single largest source of angst on teams. Wasted time, most of all. Continually striving to remove waste in all areas is a mindset that producers and project managers must develop and embrace. Many producers think that their main role is to lead projects through guidance, task-forcing and sheparding. They believe that they are like a general on a horse in front of an army, pointing their sword towards the enemy and yelling “charge!” While the role can have these elements, it’s shortsighted and limited. An experienced team probably already knows how to work well and the producer’s best use of time might be to focus on waste rather than march them toward a goal. Sometimes producers must let the team do what it does best and spend their own time bulldogging the blockers out of the process.
THE TWO DEADLY SINS
Throughout my career I’ve experienced many problem ridden projects. In fact, all my projects have been difficult. When they are completed the team usually turns to the post mortem to help shine a light on the many issues the production experienced. The the most frequent and impactful concerns often revolve around “communication problems” and “misaligned expectations”.
Communication Problems: Teams often complain that they weren’t aware of the project goals, dates, inter-departmental tasks or management expectations. This issue seems to arise on every project. Fortunately, it’s one that is the most easily fixed through discipline, techniques and a commitment to transparency from all involved. Most of all, producers and project managers must be acutely aware of this issue since it’s a main source of wasted time.
Misaligned Expectations: Often management and content creators are not in sync regarding the definition of “done” when creating features, art, code, etc. This misalignment leads to more rework on titles than most any other issue. The product owner, stakeholder, owner, etc. (whoever is the single source of creative control) must be clear in this communication to all content creators.
The commonality between these two issues is “waste.” Both issues are instrumental in creating wasted time. Time is the single most valuable resource available to product development. Since Lean Six Sigma focuses on waste removal (time creation) it’s particularly useful when applied to game development.
TIM WOODS: THE EIGHT KINDS OF WASTE
There are eight kinds of waste defined in Lean Six Sigma. An easy mnemonic to recall these is “TIM WOODS”.
Here is the academic definition.
T Transport: Moving people, products & information
I Inventory: Storing parts, pieces, documentation ahead of requirements
M Motion: Bending, turning, reaching, lifting
W Waiting: For parts, information, instructions, equipment
O Overproduction: Making more than is immediately required
O Over processing: Tighter tolerances or higher grade materials than are necessary
D Defects: Rework, scrap, incorrect documentation
S Skills: Underutilizing capabilities, delegating tasks with inadequate training
Consider your own daily game development experience. How may these types of waste definitions can be applied to help uncover your project’s inefficiencies? Here are some examples:
Transport: Does the transfer of assets take too long? Are build times lengthy and defect ridden?
Inventory: Is too much time invested on lengthy design documents that change the next day? Are there too many unpruned ideas out of scope that distract the team?
Motion: Is the environment set up to hamper communication? Are people working on highly iterative features physically sitting together? Are the tools accessible and effective? Is their workspace conducive to doing effective work?
Waiting: Is the team continually waiting for other departments to complete their work? Are they often idle?
Overproduction: Are the artists creating assets without confirmation of the end requirements? Will the assets be used? Are departments running ahead of others before requirements are specified?
Over processing: Are people making assets that are too highly detailed than what is required? Are they “gold plating” and polishing features that are the least impactful or important to the customer?
Defects: Is the code ridden with bugs? Is it extendable? Does the resulting work align with the expected work? Do the assets created align with the engine capabilities? Does the work match the expected grade?
Skills: Are tasks mismatched with the skillset of the team member? Are PHDs working on tasks a GED could accomplish? Or vice versa?
TIM WOODS: APPLIED
Theory and concepts are fine but they have little benefit unless they are applied toward tangible activities during development. Below you’ll find my game specific (incomplete) list of actions teams can perform to embrace Lean Six Sigma thinking and try to eliminate waste. None solve all project issues alone but taken collectively they may help teams significantly. No doubt you can add many more.
Conduct daily stand-ups: Short, ten to fifteen minute, well run Scrum stand-ups are useful. They promote face to face communication on a frequent basis and don’t require a large time investment. Infrequent and inaccurate communication is wasteful.
Replace weekly producer status meetings with risk meetings: Conducting a weekly status meeting where everyone goes around the room to provide updates are generally useless. The information should have already been known through regular communication and reports. Focused weekly meetings where each producer brings up their top three project risks and asks for guidance from the group can be very useful. Useless meetings are wasteful.
Prominently post goals/dates/values within the physical project space: Osmotic communication envelopes the team to ensure that no team member is confused about the macro goals. Put up posters, monitors, etc. to help keep the goals on the forefront of the team’s mind. Face to face, personal communication is best and the most iterative. Producers must take all opportunities to communicate the goal expectations to the team and stakeholders. Uniformed team members create waste.
Seat people working on highly iterative and collaborative features near each other: Team members working on the same feature, especially if it’s unknown and exploratory is critical to their success. Eliminate as much walking as possible and ease collaboration. The more unknown the feature, the closer they should be. Infrequent communication toward a focused goal creates waste.
Frequently communicate sprint, milestone and project goals face to face: While posting goals and values on the surrounding team walls is supportive, personal communication is best. It is the most iterative. An email may take a day or more for a response but face to face discussion iterates in real time. Producers and Product Owners must take all opportunities to communicate the goal expectations to the team and stakeholders. Communication delays via email or chat is waste.
Frequently communicate creative goals: As with due dates, the creative expectations must be shared continually. Generally, the “definition of done” lies with the Creative Director or Product Owner. They must be vigilant in sharing their requirements…often. Misunderstood creative goals create waste.
Make sure the definition of “Done” is clear to all content creators: One of the main roles of the Product Owner is to communicate their expectations surrounding a feature’s creative requirement and quality. Fast, measured decision making is vital. My continued belief (which is supported by Lean Six Sigma) is to follow the United States Marine’s “70% Rule”. If you think your plan has a 70% chance of working you must execute as quickly as possible. You can always adjust if it’s wrong. I’ve worked with too many creative directors that wait for the “perfect” plan. Navel-gazing creates waste.
Promote the value of transparent communication on all project related matters: I’ve worked in many companies that held core data about the project closely. They often felt the team couldn’t handle bad news or they might lose people to attrition. Being open and honest is not only ethical, it’s also good business sense. Teams must be fed the best information to help them work toward their goals. Keeping secrets, in most cases, is a mistake and can fester into discontented teams. Poor, infrequent communication creates waste.
Optimize the value stream: The project pipeline can be one of the biggest waste creators on project. Content creators must be able to review and iterate on their work as fast as possible. Broken builds, long asset transfers, etc. can significantly limit the ability of the team to do their best work. Long, broken value streams create waste.
Encourage content creators to show interim work: No one likes to show work that is undone. They may think that the reviewer doesn’t understand what it will evolve into or that they’ll get critiques about irrelevant issues the creator already intends to resolve. The creator and the reviewer must develop this trust. Frequent reviews on iterative work will help eliminate rework (waste) overall. Showing interim work reduces wasted time. Waiting to show work till it’s finished creates rework…and waste.
Attempt to eliminate rework resulting from creative review meetings: This point is similar to the previous one, however the ideal situation is that NO rework comes from “official” creative review meetings. This work should have already been reviewed and altered prior to the review meeting. The review meeting should be a bureaucratic “stamp of approval”, not a meeting to explore the creative director’s lofty new ideas. On nearly every project I’ve worked on content creators have complained that they must wait far too long for their work to be reviewed. Not only does this create waste in the form of idle time and possible rework, it’s a significant frustration for all involved. The Product Owner must delegate reviews to trusted team members. To do so, their requirements must be communicated clearly and their expectations must be established. Rework from infrequent creative reviews creates waste.
Streamline or eliminate meetings: If your team finds meetings useless you are probably not conducting them properly. There are many, many sources that outline the best way to run them. Proper agendas, specific questions to be answered, etc. People generally dislike meetings and find they are a waste of their time. Producers must study the many ways to hold effective meetings. Meetings should be about collaboration on solutions, not reiterating what everyone already knows. Inefficient meetings create waste.
Hack, in the right circumstances: Not every piece of code must be beautifully architected. Sometimes the team gets more benefit from experiencing a feature hands-on, even if the underlying code is messy. An agile adage states that teams should “fail frequently”. This means the team must prototype quickly so that they may iterate toward quality as fast as possible. Hacking code can get to an example feature faster. Over designing and massive system creation before the feature(s) is well known can lead to waste.
Stalk and assassinate open questions: The team must continually stack rank the open questions surrounding the project. The questions with the most impact and expected frequency should take the highest priority. The features with the highest value for the customer (gamer) should be placed at the front of the line. Killing open questions with religious fervor steadily removes uncertainty and risk from projects. Open questions are sources of risk on a project.
Focus work on customer needs: Teams must be vigilante in making sure they are creating features for their customers, not themselves. Activities that don’t directly correlate with customer needs should be removed. Sometimes people like to work on their own pet projects despite the value for the end user. Working on personal features that don’t align with the project end goals creates waste.
At the end of the day the producer’s foremost responsibility is to continually search for ways to make the project run more smoothly. “Kaizen” is a Japanese term from Toyota that evangelizes continuous improvement. Producers, Product Managers, Stakeholders and Content Creators must always be on the hunt for ways to improve their work process. It’s a mindset that must be practiced on all projects so that results can improve over iterations.
Lean Six Sigma, as noted earlier, is a very involved framework that includes graphs, equations, methods and techniques that are very involved. Teams may only need to understand the principles to gain benefit. More than a framework, it is a mindset. Waste is a project killer. The practice of finding and eliminating it is a mindset that all teams should embrace.
篇目4，Communication is a Game Development Skill (Part 1 of 2)
Today’s subject is an incredibly important one that gets a lot less attention than it should. Most videogame development guides and tutorials fail to acknowledge that communication is a game development skill.
Knowing how to speak and write effectively is right up there alongside knowing how to program, use Photoshop, follow design process, build levels, compose music, or prepare sounds. As with any of those skills there are techniques to learn, concepts to master, and practice to be done before someone’s prepared to bring communication as a valuable skill to a team.
Game Developers Especially
Surely, everyone in the world needs to communicate, and could benefit from doing it better. Why pick out game developers in particular?
“…sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it!”
I don’t meant to claim that only game developers have communications issues. But after spending much of the past ten years around hundreds of computer science students, indie developers, and professional software engineers, I can say that there are particular patterns to the types of communication issues most common among the game developers that I’ve met. This is also an issue of particular interest to us because it’s not just a matter of making the day go smoother; our ability to communicate well has a real impact on the level of work that we’re able to accomplish, collaboratively and even independently. Game developers often get excited about our work, for good reason, but whether a handful of desirable features don’t make it in because of technical limitations or because of communication limitations, either way the game suffers for it the same.
Whose Job is It?
If programmers program, designers design, artists make art, and audio specialists make audio, is there a communication role in the same way?
There absolutely is. There are several, even.
The Producer. Even though on small hobby or student teams this is often wrapped into one of the other roles, the producer focuses on communication between team members, and between team members and the outside world. Sometimes this work gets misunderstood as just scheduling, but for that schedule to get planned and adjusted sensibly requires a great deal of conversations and e-mails, followed by ongoing communications to keep everyone on the same page and on track.
The Designer(s). One way to think about the designer’s role in game development is to communicate with the player through the game. Indicating what’s the goal, what will cause harm or benefit, where the player should or shouldn’t try to go next, expressing the right amount of internal state information – these are matters of a game’s design more so than its programming. Depending on a game team’s skill makeup, in some cases the designer’s only direct work with the game is in level layouts or value tuning, making it even more critical that within the team a designer can communicate well with programmers, artists, and others on the team when and where the work intersects. On a small team when the person mostly responsible for the design is also filling one or more other roles (often the programming) communication then becomes integral to keeping others involved in how the game takes shape.
The Leads. On a team large enough to have leads, which is common for a professional team, the Lead Programmer, Lead Designer, or Lead Artist also have to bring top notch communication skills to the table. Those people aren’t necessary the lead on account of being the best programmer, designer, or artist – though of course they do need to be skilled – they’re in that position because they can also lead others effectively, which involves a ton of communication in all directions: to the people they lead, from the people they lead, even mediating communications between people they lead or the people they lead and others.
Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.
The Writer. Not every game genre involves a writer, but for those that do, communication becomes even more important. Similar to the designer that isn’t also helping as a programmer, a team’s writer typically isn’t directly creating much of the content or functionality, aside perhaps from actual dialog or other in-game and interstitial text. It’s not enough to write some things down and call it a day, the writer and content creators need to be in frequent communication to ensure that satisfactory compromises can be found between implementation realities and the world as ideally envisioned.
Non-Development Roles. And all that’s only thinking about the internal communications on a team during development. Learning how to communicate better with testers, players, or if you’ve got a commercial project your customers and potential new hires (even ignoring investors and finance professionals), is a whole other world of challenges that at a large enough scale get dealt with by separate HCI (Human-Computer Interaction) specialists, marketing experts, PR (public relations) people and HR (Human Resources) employees. If you’re a hobby, student, solo, or indie developer, you’ve got to wear all of these hats, too!
There are two main varieties of communication issues that we tend to encounter. Although they may seem like polar opposites, in reality they’re a lot closer than they appear. In certain circumstances one can even evolve from the other.
Challenge 1: Shyness
The first of these issues is that some of us can be a little too shy. Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.
It’s unfortunately very easy to rationalize shyness. After all, maybe the reason a talented, quiet person was able to develop their talent is because they’ve made an effort to stay out of what they perceive as bickering. Unfortunately this line of thinking is unproductive in helping them and the team benefit more from what they know. Conversation between team members serves a real function in the game’s development, and if it’s going to affect what gets made and how it can’t be dismissed as just banter. Sometimes work needs to get done in 3D Studio Max, and sometimes it needs to get done around a table.
Another factor I’ve found underlying shyness is that a person’s awareness of what’s great in their field can leave their self-confidence with a ding, since they can always see how much improvement their work still needs just to meet their own high expectations. Ira Glass has a great bit on this:
It doesn’t matter though where an individual stands in the whole world of people within their discipline, all that matters is that developers on the project know different things than one another. That’s inevitably always the case since everyone’s strengths, interests, and backgrounds are different.
Challenge 2: Abrasiveness
Sometimes shyness seems to evolve as an overcompensation for unsuccessful past interactions. Someone tried to speak up, to share their idea or input, just to add to someone else’s point and yet it somehow wound up in hurt feelings and no difference in results. Entering into the discussion got people riled up, one too many times, so after one last time throwing hands into the air out of frustration, a developer decides to just stop trying. Maybe they feel that their input wasn’t properly received, or even if it was it simply wasn’t worth the trouble involved.
As one of my mentors in my undergraduate years pointed out to me: “Chris, sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it! If you made the same point differently they might get behind it.”
He was absolutely right. Once I heard that idea, in addition to catching myself doing it, I began to notice it everywhere from others as well. It causes tension in meetings, collaborative classroom projects, even just everyday conversations between people. Well-meaning folks with no intention of being combative, indeed in total overall agreement about both goals and general means, often wind up in counterproductive, circular scuffles arising from an escalation of unintended hostility.
There are causes and patterns of behavior that lead to this problem. After 10 years of working on it, I’ve gotten better about this, but it still happens on occasion, and it’s still something that I have to actively keep ahead of.
It’s understandable how someone could run through this pattern only so many times before feeling like their engaging with the group is the cause of the trouble. This is in turn followed by backing off, toning down their level of personal investment in the dialog, and (often bitterly) following orders from the action items that remain after others get done with the discussion.
篇目5，Communication is a Game Development Skill (Part 2 of 2)
…if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously…
Last month, in part one, I identified a couple of common points of trouble that arise for videogame developers. Communication matters! If communication skills are in bad enough shape, no matter what other technical or artistic skills have developed it’ll be hard to get others to collaborate, and hard to get players and reviewers to hear about the work. On the other end of the spectrum, if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously, because being a good communicator is essential to winding up as a meaningful part of (or even starting and leading) any team of other developers who are bringing their own respective skills, experience, and inspiration into the picture.
Listening and Taking to Heart
You’ve heard this all your life. You’ll no doubt hear it again. Hopefully every time communication comes up this gets mentioned too, first or prominently.
Listening well, meaning not just hearing what they have to say or giving them an outlet but trying to work with them to get at underlying meaning or concerns and adapting accordingly, is way harder than it sounds, or at least more unnatural than we’d like to think. You can benefit from practicing better listening. I can say that without knowing anything about you, because everyone – presidents and interns, parents and kids, students and teachers – can always listen better.
There’s a tendency, even though we rationally know it’s out of touch with reality, to think of oneself as the protagonist, and others like NPCs. Part of listening is consciously working to get past that. The goal isn’t to get others to adopt your ideas, but rather it’s to figure out a way forward that gains from the multiple backgrounds and perspectives available, in a positive way that people can feel good about being involved with.
Don’t Care Who Wins, Everyone Wins
There’s no winner in a conversation.
This one also probably sounds obvious, but it’s an important one that enough people run into that it isn’t pointed out nearly enough. Development discussion doesn’t need to be a debate. Even to the extent that creative tension will inevitably present certain situations in which incompatible ideas are vying for limited development attention on a schedule, debate isn’t the right way to approach the matter.
In one model for how a dialog exchange proceeds, two people with different ideas enter, and at the end of the exchange, one person won, one person lost. I don’t think (hope?) that anyone consciously thinks about dialog this way, but rather it may emerge as a default from the kinds of exchanges we hear on television from political talking heads, movie portrayals of exchanges to establish relative status between characters, or even just our instinctive fight or flight sense of turf.
Rather than thinking in terms of who the spectators (note: though avoid spectators when possible, as it can often pollute an otherwise civil exchange with defensive, ego-protecting posturing) or an impartial judge might declare a winner, consider which positions the two people involved would likely take in separate future arguments.
If all of your prior references have led you to believe strongly about a particular direction, you only do that rhetorical position (and the team/project!) a disservice by creating opponents of it.
Whenever we come across as unlikeable, especially in matters like design, art, or business where a number of directions may be equally viable, then it doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling or person.
It doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling.
Be friendly about it. Worry first about understanding the merits and considerations of their point, then about your own perspective being understood for consideration. Notice that neither of those is about “convincing” them, or showing them the “right” way, it’s about trying to understand one another because without that the rest of discussion just amounts to barking and battling over imagined differences.
You Might Just be Wrong
Speaking of understanding one another: don’t ever be afraid to back down from a point after figuring out what’s going on, and realizing that there’s another approach that’ll work just as well or better. There’s a misplaced macho sense of identity attached to sticking to our guns over standing up for our ideas – especially when the ideas aren’t necessarily thoroughly developed and aren’t exactly noble or golden anyhow.
A smart person is open to changing their mind when new information or considerations come to light. You’re not playing on Red team competing against Blue team. You’re all on the same team, trying to get the ball to go the same direction, and maybe your teammate has a good point about which direction the actual goal is in.
You’re all on the same team…
The other side of this is to give the other person a way out. Presenting new information or concerns may make it easier for them to change their mind, even if that particular information or concern isn’t actually why they change their mind, simply because it can feel more appropriate to respond to new information then to appear to have been uncertain in the first place. Acknowledging the advantages in the position they’re holding doesn’t make your position seem weaker by comparison, it makes them feel listened to, acknowledged, and like there’s a better chance you’re considering not just your own initial thoughts but theirs too. When a point gets settled, whichever way things go, let the difference go instead of forming an impression of who’s with or against you. (Such feelings have a way of being self-fulfilling. In practice, reasonable people are for or against particular points that come up, not for or against people.)
When an idea inevitably gets compromised or thrown out, being a skilled communicator means not getting bitter or caught up in that. Don’t take it personally. It’s in the best interests of the team, and therefore the team’s members (yourself included), that not every idea raised makes it into implementation or remains in the final game.
Benefit of the Doubt, Assume the Best
A straw man argument is when we disagree with or attempt to disprove a simplified opposition position. In informal, heated arguments over differences in politics or religious/cultural beliefs, these are frequently found in the form of disagreeing with the most extreme, irrational, or obviously troubled members of the group, rather than dealing with the more moderate, rational, and competent justifications of their most thoughtful adherents. This leads to deadlock, since both sides feel as though they’re advancing an argument against the other, yet neither side feels as though their own points have been addressed.
Assume that the other person is coming from a rational, informed, well-intentioned place with their position.
When the goal is to make a more successful collaboration, rather than to just make ourselves temporarily feel good, the right thing to do is often the opposite of setting up a straw man argument.
Assume that the other person is coming from a rational, informed, well-intentioned place with their position, and if that’s not what you’re seeing from what has been communicated so far, then seek to further understand. Alternatively, even help them further develop their idea by looking for additional merit to identify in it beyond what they might have originally had in mind – maybe from where you’re coming from it has possible benefits that they didn’t realize mattered to you.
If the idea you may be holding is different than what someone else is proposing, welcome your idea really being put to the test by measuring it against as well put-together an alternative as the two of you can conceive. If it gets replaced by a better proposal that you arrived at through real discussion and consideration, or working together to identify a path that seems more likely to pan out well for both of you, all the better.
Your Frustration is With Yourself
This is one of those little life lessons that I learned from my wrestling coach which has stayed with me well after I finished participating in athletic competitions. Most of the time when people are upset or frustrated or disappointed, they’re upset or frustrated or disappointed mostly with themselves, and directing that at somebody else through blame isn’t ever going to diffuse it.
Even if this isn’t 100% completely and totally true in every situation – sure, sometimes people can be very inconsiderate, selfish, or irresponsible and there may be good reason to be upset with them – I find that it’s an incredibly useful way to frame thinking about our emotional state because it takes it from being something the outside world has control over and changes to focus to what we can do about it.
Disappointed with someone violating our trust? Our disappointment may be with our failing to recognize we should not have trusted them. Upset with someone for doing something wrong? We may be upset with ourselves for not making the directions or expectations more clear. Frustrated with someone that doesn’t understand something that you find obvious? Your frustration well may lie in your feeling of present inability to coherently and productively articulate to that person exactly what it is you think they’re not understanding.
If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it. Maybe they don’t follow your reference, or could better get what you’re trying to say if you captured it in a simple visual like a diagram or flow chart. Maybe they understand what you’re saying but don’t see why you think it needs to be said, or they get what you mean but don’t see the connection you have in mind for what changes you think it should lead to.
If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it.
Clarify. Edit it down to summary highlights (people often have trouble absorbing details of an argument until they first already understand the high level). Explain it another way to triangulate.
Provide a demonstration case or example. If there’s a point you already made which you think was important to understanding it but that point didn’t seem to stick, find a way to revisit it in a new way that leads with it instead of burying it among other phrases that were perhaps too disorganized at the time to properly set up or support it.
Mistaking Tentative for Definitive
Decisions can change. When they’re in rough draft or first-pass, they’re likely to – that’s why we do them in rough form first! It’s easier to fix and change things when they’re just a plan, an idea, or a prototype, and the more they get built out into detail or stick around such that later decisions get made based on them, then the more cemented those decisions tend to become.
There are two types of miscommunication that can come from this sort of misunderstanding: mistaking your own tentative ideas for being definitive, or mistaking someone else’s tentative ideas for being definitive. During development, and as more people get involved, projects can change and evolve a bit to reflect what’s working or what isn’t, or to take better advantage of the strengths and interests of team members.
If there was an idea you pushed for earlier in a project and people seemed onboard with it then, it’s possible that discoveries during development or compromises being made for time and resource constraints have caused it to appear in a modified or reduced form. It might even be cut entirely, if not explicitly then maybe just lost in the shuffle. Before raising a case for it, it’s worth rethinking how the project may have changed since the time the idea was initially formed, to determine whether it would need to be updated to still make sense for the direction the team and game has gone in.
Sometimes the value of ideas during development is to give us focus and direction, and whether the idea survives in its originally intended form is secondary to whether the team and players are happy with the software that results. It may turn out to be worth revisiting and bringing back up, possibly in a slightly updated form, as maybe last time was at a phase in development when it wasn’t as applicable as it might be now. Or it may be worth letting go as having been useful at the time, but perhaps not as useful now, a stepping stone to other ideas and realizations the team has made in the time that has passed.
People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise.
The other side to this is to make the same mistake in thinking about someone else’s ideas: thinking they are definitive when they are necessarily tentative. This happens perhaps because of how far off the idea relates to the future, and how much will be discovered or answered between now and then that is unknown at the time of the initial conception and discussion. If a project recruits people with the intention of supporting a dozen types of cars, but during development reality sinks in and only three different vehicles make sense in favor of putting that energy into other development necessity, those things happen. People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise. If early in a project someone is trying to spell out a vision for what the project may look like later, don’t take that too literally or think of it as a contract, look at it as a direction they see things headed in. Implementation realities have a way of requiring compromise along the way.
Soften That Certainty Away
A common source of fighting on teams is from a misplaced sense of certainty in an observation or statement which reflects value priorities that someone else on the team doesn’t necessarily share, or especially when the confidently made statement steamrolls value priorities of someone else on team.
Acknowledge with some humility that you only have visibility on part of all that’s going on, and that the best you can offer is a clarification of how things look for where you’re coming from or the angle you have on things. Leave wiggle room for disagreement. Little opening phrases like “As best as I can tell…” or “It looks to me like…” or “I of course can’t speak for everyone, but at least based on the games that I’ve played in this genre…” may just seem like filler, but in practice they can be the difference between tying the team in a knot or opening up valuable discussion about different viewpoints.
School surrounds people with other people that think and work in similar patterns, with similar values, often of the same generation. Outside the classroom, whether collaborating on a hobby game project, joining a company, or doing basically anything else in the world besides taking Your Field 101, that isn’t typically how things work. Often if your skills are in visual art, you have to work with people that don’t know as much about visual art as you. If your skills are in design, you’ll have to work with a lot of non-designers. If you have technical talents, you will be dealing with a lot of non-technical people.
That is why you are there. Because you know things they don’t know. You can spot concerns that they can’t spot. You understand what’s necessary to do things that they don’t know how to do. If someone else on the team or company completely understood everything that you understand and in the same way, they wouldn’t really need you to be involved. Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see. Teach a little bit.
That is why you are there. Because you know things they don’t know… Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see.
I refer to this as the consultant’s frustration because that’s a case that draws particular emphasis to it: a company with no understanding of sales calls in a sales (or design, or IT, or whatever) consultant, because they have no understanding of that and that’s why they made the call. A naive, inexperienced, unprepared consultant’s reaction to these situations is one of horror and frustration – how on Earth are these people so unaware of the basic things that they need to know? The consultant is there to spot that gap and help them bridge it, not to look down on them for it. Meanwhile they’re doing plenty of things right the specialist likely doesn’t see or fully understand, because that’s not the discipline or problem type that they’re trained and experienced in being able to spot, assess, or repair.
When you see something that concerns you, share that with the team. That is part of how you add value. You may see things that others on the team do not.
Values Are Different Per Role
The other side to the above-mentioned point is appreciating that other factors and issues less visible to your own vantage point may have to be balanced against this point, or in some cases may even override it.
Frustration can arise from an exaggerated form of the consultant’s frustration: a programmer may instinctively think of other roles on the team as second-rate programmers, or the designer may perceive everyone else on the team as second-rate designers, etc. This is not a productive way to think, because it’s not just that they are less-well suited to doing your position, but you’re also less-well suited to doing theirs. A position goes beyond what skills someone brings to move a project forward, it also brings with them an identity and responsibility on the team to uphold certain aspects of the project, a trained eye to keep watch for certain kinds of issues. The programmer may not be worried about the color scheme, the artist may not be worried about how the code is organized, the designer may not care about either as long as the gameplay works.
…a programmer may instinctively think of other roles on the team as second-rate programmers…
That’s one of the benefits of having multiple people filling specialized roles, even if it’s people that are individually capable of wearing multiple hats or doing solo projects if they had to.
In the intersection of these concerns, compromises inevitably have to get made. The artist may be annoyed by a certain anomaly in how the graphics render, but the engineer may have a solid case for why that’s the best the team’s going to get out for the given style of the technology they have available. The musician or sound designer may feel that certain advanced scoring and dynamic adjustment methods could benefit the game’s sounds cape, but the gameplay and/or level designer may have complications they’re close to about user experience, stage length, or input scheme that place some tricky limits on the applicability of those approaches.
One of the reasons why producers (on very small student/hobby/indie teams this is often also either the lead programmer or lead designer) get a bad rap sometimes, as the “manager” that just doesn’t get it, is because their particular accountability is to ensure that the game makes forward progress until it’s done and released in a timely manner. So the compromise justification that they often have to counter with is, “…but we have to keep this game on schedule” which is a short-term version of “…but this game has to get done.” If someone isn’t fighting that fight for the project, it doesn’t get done.
Be glad that other people on a team, when you have the privilege of working with a good and well-balanced team, are looking out for where you have blind spots. Push yourself to be a better communicator so that you can help do the same for them.
Too Much Emphasis on Role
After that whole section on role, I feel the need to clarify that especially for small team development (i.e. I can total understand military-like hierarchy and clarity for 200+ person companies) role shouldn’t pigeonhole someone’s ability to be involved in discussions and considerations.
While it’s true that the person drawing the visual art is likely to have final say on how the art needs to be done (not only as a matter of aesthetic preference, but as a side effect of working within their own capabilities, strengths, and limitations), that does not mean that others from the team shouldn’t be able to offer some feedback or input in terms of what style they feel better about working with, what best plays to their own strengths and limitations (ex. just because an artist can generate a certain visual style doesn’t mean the programmer’s going to be able to support it in real-time), and what they like just as fellow fans of games and media.
Does one team member know more about animation than others on the project? Then for goodness sake, of course that person needs to be involved in discussions affecting the implementation or scheduling of animation. But even if you’re not an animator, that you’ve accumulated a different set of media examples to draw upon, and have an idea for how that work may intersect with technical, design, or other complications, there’s still often value in being a part of that discussion (though of course still leaving much of the decision with whoever it affects most, and whoever has the most related experience).
It’s unhelpful to hide behind your role…
It’s unhelpful to hide behind your role, thinking either “Well, I’m not the artist so that isn’t my problem” or “Well, I’m the designer, so this isn’t your problem to worry about.” The quality of the game affects everyone who got involved with making it. You make a point of surrounding yourself with capable people that are coming from different backgrounds and have different points of view to offer. Find ways to make the most of that.
A related distinction to these notes about role is the concept of servant-leadership. Rather than a producer, director, or lead designer feeling like the boss of other people who are supposed to do what they say, it can be healthy and constructive for them to approach the development as another collaborator on the team, just with particular responsibilities to look out for and different types of experience to draw from. They’re having to balance their own ideas with facilitating those of others to grow a shared vision, they’re trying to keep the team happy and on track, that’s their version of the compiler or Photoshop.
Handling Critique Productively
When critique comes up – whether of your game after it’s done or of a small subpoint in a disagreement – separate yourself personally from the point discussed. When people give feedback on work you’re doing, whether it’s on your programming, art, audio, or otherwise, the feedback is about the work you’re doing, it’s not feedback about you (even if, and let’s be fair here, we could all honestly benefit from a little more feedback about ourselves as a work-in-progress, too!).
Feedback is almost always in the interest of making the work better, to point out perceived issues within a smaller setting before it’s too late to fix the work in time for affecting more people, or before getting too far into the project to easily backtrack on it. Sometimes the feedback comes too late to fix them in this case, in which case rather than disagree with it accept that’s the case and keep it in mind to improve future efforts (this isn’t the last game or idea you’re ever going to work on, right?).
Defensiveness, of the sort mentioned in the recent playtesting entry, is often counterproductive, or at lease a waste of limited time and energy.
Systems and Regular Channels
Forms and routine one-on-one check-in meetings can feel like a bureaucratic chore, but in proper balance and moderation they can serve an important function. People need to have an outlet to have their concerns and thoughts heard. People need to be in semi-regular contact with the people who they might need to raise their concerns with, before there is a concern to be raised, so that there’s some history of trust and prior interaction to build upon in those cases and it doesn’t seem like a weirdly hostile exception just to bring up something small.
In one of the game development groups I’ve been involved with recently we were trying to narrow down possible directions for going forward from an early stage when little had been set into action yet. From just an open discussion, three of the dozen or so ideas on the whiteboard got boxed as seeming to be in the lead. When we paused to get a show of hands to see how many people were interested in each of the ideas on the board, we discovered that one of the boxed items had only a few supporters – those few just happened to be some of the more vocal people in the room. Even introducing just a tiny bit of structure can be important in giving more of an outlet to the less outspoken people involved with a project, who have ideas and considerations that are likely just as good and, as mentioned earlier, probably weighing different sets of concerns and priorities.
Practice, Make Mistakes to Learn From
Seek out opportunities to get more practice communicating. In all roles, and at all scales. As part of a crowd. In front of a crowd. In formal and informal settings. Out with a few people. Out with a lot of people.
Now, for personal context: I don’t drink. I don’t go to bars or clubs. I’ve admittedly never been one for parties. This weekend I have no plans to watch the Super Bowl. I’m not saying you should force yourself to do things that you don’t want to do. What I am saying is to look for (or create) situations where you can comfortably exercise your communication abilities. Whatever form that may take for you.
Seek out opportunities to get more practice communicating.
Given a choice to work alone or work with a group, welcome the opportunity to deal with the challenges of working with a group. Attend a meetup. Find some clubs to participate in. When a team you’re on needs to present an update, volunteer to be the one presenting that update.
Communication is a game development skill. As with any other game development skill, you’ll find the biggest gains in ability through continued and consistent practice.