The following blog post was written by members of the Gamasutra ?? s community, unless otherwise stated.
The ideas and opinions expressed are those of the writer, not Gamasutra or its parent company.
Good communication is important in all game development studios, including small ones. You might think that a small team isn’t affected by misunderstandings, but when you think about it, it can be misleading even with people near you (ask your wife). The only way to avoid misunderstandings within the team is to be like Eric Barron and make your own game. For everyone else, practicing good communication skills is the only way to reduce friction in team communication.
Good team communication can sound silly to worry about, given all that can go wrong in the game. But I’m convinced that I don’t have to go back to the memories to remember the interaction with my teammates, which should have taken five minutes. Instead, it took 30 minutes and both were exhausted.
The following case study describes some of the communication issues that you’ve noticed within your team and how to fix them.
With Mahirupba? (Is this difficult?)
No one is immune to lack of communication, so use yourself as an example. Often, when a new feature request comes in, we ask the developer, “Is this difficult?” And you will receive some of the following answers.
Answer 1: “Not so.”
Answer 2: “Yes, that’s difficult.”
Answer 3: “It’s not difficult, but it takes a long time to implement.”
Inevitably, this will lead to more questions when I try to figure out the difficulty of the task. In the end, I realized I was actually asking the wrong question. The last answer helped me to give me a clue as to what the better question really was.
In the context of my role as a project manager, what I really wanted to know was “how long would it take to implement this” so that I could evaluate if it was worth adding to the game. .. Ever since I realized this, I’ve been asking “how long” rather than “how difficult”. And each time these conversations started, I saved the team a minute or two.
Tatama unmemory (memory hits) and programmer jargon
A common problem that programmers have when talking to non-programmers is that they have jargon or are presumed to be understood by non-programmers. Terminology can be useful when it is clear that both parties understand what is being said, but when it becomes clear that there is a misunderstanding, it needs to be clarified further. It must be obligatory for those who use jargon to be clear about what they are trying to say. Below are some general responses given to me by our programmers. Initially, they were puzzling to me and it took me a long time to explain. Sometimes I forget the meaning, but it may be a sign that I’m getting older.
1. Memory hits: This basically means that this will increase the memory usage of your game and can cause some problems in the long run. It is still useful to track the amount of memory this actually uses and the actual danger.
2. This should be saved: This basically adds to the complexity of the game and makes the save file larger, but I’m trying to avoid this.
3. We need to “track” it: to be completely honest, this still sometimes confuses me.
The important thing to consider here is to clearly understand that jargon is a useful shortcut between two people who understand each other, but that jargon needs explanation if it is not understood. It means that you need to. by the way…
Technical explanation is not explanation
Often, when I ask programmers the impact of a problem, they answer with a * technical explanation *. It’s hard to really explain this, so you might want to make an analogy. Ask someone, “What if I throw this ball at your face?” The answer I really want and help is not * a physics explanation of acceleration, mass, wind resistance, etc. *. A useful answer is that the ball hits your face and hurts.
Similarly, when asked about the impact of design or code changes on the game, it’s better to explain how these changes affect the player / game than how the code changes. Probably easy.
The fewer words the better (not!)
Because many game developers are quiet and introverted, many of us accept the idea that saying as few words as possible is the most efficient way to avoid having to talk to people. This causes two problems when a quiet developer is asked to clarify something in the game / code.
1. The person they are talking to is either too meek or careless enough to keep asking clear questions. This ends the conversation very quickly, but it inevitably raises the issue of misunderstanding errors affecting the game.
2. The person you are talking to is not happy with your answer and may continue to ask questions until you are satisfied with the answer, creating a stressful and hostile environment.
Problem 2 is doubly unfair to the questioner, as not only is it tiring to both the quiet developer and the questioner, but he also has to spend his efforts to find the context and make sense. This is a lot of mental work.
My only advice here is to ask people to consider adding a clear context to the statement. This may require some additional effort on their part, but in the long run it can save a lot of time for everyone.
Zero information answer
And this is where I make a U-turn. Just as it is important to note that using as few words as possible is not the best way to communicate, you may use many words without actually giving useful information. Here is an example:
Zero information: The cost of company A and the cost of company B are very different.
This statement may be accurate, but it does not provide any practical information and the recipient is forced to ask follow-up questions.
Some information: Company A is cheaper than Company B
This sentence is short and provides immediate context. Company A is cheaper, so on the surface it’s good. The recipient can then ask follow-up questions such as “But do you offer the same level of service?”
Most useful information: Company A is cheaper than Company B, but I prefer Company B’s services.
This sentence immediately provides context and answers possible follow-up questions. It’s the perfect answer in terms of information efficiency.
Of course, you can’t always reach the highest level of information efficiency, but if you think a little about what you want to say before you type in, communication can improve significantly. This is especially useful when the conversation is chat or email. You don’t have to take immediate action, so take your time.
Zero information question
The back side of the zero information answer is the zero information question. This is when a colleague asks you a question but doesn’t provide you with the exact context of what the question is. Here is an example:
Zero information: Can I check the size of the test result panel? The numbers seem to be wrong. Some of them are not summed. Similarly, the total height of the student exam headers (right side) not the same As the height of the student grid.
This question may be accurate, but there is no contextual clue as to what the actual problem is and the recipient needs further investigation. Instead of saying something is different, say why you think the difference is wrong, and what you are assuming is the correct solution.
Some information: Can I check the size of the test result panel? The numbers on the student grid are shorter than the sum on the student exam results panel.
This is more convenient because you can quickly tell the recipient what the problem is and the recipient can investigate it.
Most useful information: Can I check the size of the test result panel? The numbers on the student grid are shorter than the sum on the student exam results panel. I think it’s the same height.
This is more convenient because it quickly tells the recipient what the problem is and what is expected.
Always remember, not say something is different. Provide context as to why they are different (That is, one is shorter / cheaper / faster than the other).
Pwede Naman (can / can)
My last example is a bit language specific, Filipino to be exact, but there should be cases of similar languages in other countries. Locally, “Pwede Naman” is an uncommitted catch-all term that can provide different meanings based on the context and the person who uses it. Someone’s “pwedenaman” may be yes, but I use it only to convey very vague feelings like “I think it’s okay …” in English.
This is fine for casual conversations, but I definitely hate it for decision-making contexts. Here’s an example when someone asks, “What do you think about adding this mechanic to your game?”
Zero information: I think that it is all right.
This gives no context or value judgment. It does not convey an opinion. If you’re not sure about the mechanic’s influence, it’s a good idea to say “I’m not so happy” or “If you spend more time thinking, you’ll be back again.” You are. “
Some information: I like it, but I have some concerns, or I think it’s a bad idea (concerns).
This clearly conveys how you feel about the mechanics (positive or negative) and your concerns about the design and what they are.
Most useful information: I like it, but I have some concerns, or I think it’s a terrible idea (concerns). I will explain next (concerns)
This is basically the same as the previous example, but with a detailed explanation of certain concerns and the use of stronger words to convey your feelings about the mechanic.
This bothered me so much that I brought it up at last year’s company outings and team building events and made everyone promise not to use the word “pwedenaman” again in the context of work. Did I succeed? Hmm … pwede Naman.
Multi-person teams need good communication to be successful, or at least to have a more harmonious work environment. This is even more important for small teams. In large organizations, poor communicators can be hidden or better communicators and team leaders can be assigned to facilitate communication. For small teams, there is no place to hide these issues. This is especially important if you are the leader of the team. You may not think you have a communication problem. Because people never tell you that. But in reality, people are too afraid to ask for an explanation, or they just make their own assumptions about what you mean, both of which have bad consequences in the long run.