![Game Developer Logo Game Developer Logo](https://eu-images.contentstack.com/v3/assets/blt740a130ae3c5d529/bltb8149045ecc9add6/664670498df30a26f54d5ed4/GDBlogs_Logo_FINAL.png?width=700&auto=webp&quality=80&disable=upscale)
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
How I developed good communication skills while working on Fastival
Communication can become challenging in work settings, especially in unfamiliar environments or urgent situations necessitating quick problem resolution. I'd like to share some lessons I learned from my first large-scale team game development project.
July 2, 2024
![Key art featuring a colorful purple character Key art featuring a colorful purple character](https://eu-images.contentstack.com/v3/assets/blt740a130ae3c5d529/blt213525d50979cd50/6682b6ed3a6e644f8757c196/Fastival_square.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Many people find it easy to communicate in calm and relaxed environments. However, communication can become challenging in work settings, especially in unfamiliar environments or urgent situations where the focus shifts towards quick problem resolution. During these times, communication problems often arise, leading to conversations stalling or ideas being poorly exchanged. I'd like to share some lessons I learned from my first large scale team game development project.
Lesson 01: Trust as the Foundation of Long-term Good Communication
As part of the Southern Methodist University (SMU) Guildhall program, I worked on a team of 47 developers to publish a carnival arcade racing game called Fastival (available on Steam). On the project, I served as the Art Producer. Right at the outset, I ran into the challenge of forming a good communication pipeline with the art team. This task was especially difficult because I had no prior experience working with artists before. Reflecting on my experience, I realized that the biggest challenge was creating trust within the team. Initially, they hesitated to share their thoughts with me because they did not know me or understand my specific role. I needed to take action to create trust within the team and facilitate communication.
To build trust, I began helping the artists with various tasks, even small ones. For example, I adjusted seat arrangements and lighting conditions after learning that the art team preferred to work in a darker environment. I also assisted them with questions related to Perforce (a version control software) and Unreal Engine 5. I approached the artists calmly and respectfully, patiently explaining concepts to those for whom English was a second language. My actions demonstrated my commitment to the team. Gradually, they started to view me as a helper and understood my roles better. With their trust, I was able to make further adjustments to team arrangements and the communication pipeline, such as forming sub-teams that included artists, programmers, and level designers.
Lesson 02: Camly Communicating in “Emergency” Situations
Moving on from my experience of creating trust within the team, I want to discuss another lesson I learned, which is calmly communicating in “emergency” situations.
During the first week of our alpha development, I discovered a problem, which was troubling several artists: some models imported into the game had black spots and appeared distorted. After class, I investigated the issue and suspected that Nanite, a recently applied setting in Unreal Engine 5, was to blame.
Excited about my findings, I messaged the group channel that night, urging everyone to disable the Nanite setting. However, my unilateral decision caught the attention of our professors, who expressed concerns. The next morning, I discussed the issue with our TGP2 Art Instructor. I tried to persuade the Art Instructor to adopt my solution. In response, he raised valid questions about other potential factors contributing to the problem. Unfortunately, our conversation did not yield much progress, as we were both entrenched in our viewpoints.
After nearly an hour, I decided to step back and consult with other team members, allowing the Art Instructor to investigate the problem independently. Later that day, we reconvened with the Art Instructor, this time with our game’s Software Development lead, a programmer experienced with Nanite, and a Level Design Professor. Together, we examined the issue and identified Nanite LOD as the likely cause of the black spots. Following a thorough discussion, we all agreed to address the issue in the next milestone.
This experience taught me why my initial communication with the Art Instructor failed and highlighted key principles of good communication:
Stay calm: Analyze the core issue, your understanding of the problem, and your proposed solution. Clear thinking is only possible in a calm state of mind.
Focus on the subject: During discussions, focus on the matter at hand rather than the individual. Avoid phrases like "I think you are wrong" or "You're not seeing the big picture," as they divert the conversation away from productive dialogue.
Step back when necessary: If communication stalls, take a step back to reorganize your thoughts and reassess the situation. Consider involving individuals with relevant expertise to facilitate progress.
Lesson 03: Communicating Across Disciplines
Another lesson I want to discuss is communication across disciplines, specifically between artists and level designers. During TGP2, we were divided into separate teams: Level Designers and Artists, and communication between these two groups was not smooth from the beginning. Both teams brainstormed independently and did not communicate with each other during the early production stages. This resulted in two different visions for the environment and the props that needed to be created. The problem became evident when we started integrating art assets into the levels; many level designers felt that the props did not match their designs and that their opinions were not respected.
Aware of this situation, I began to engage more with the Level Designers team, asking individual track teams about their visions and expectations. My goal was to ensure that the level designers felt respected so that we could move forward collaboratively. Then, I worked with the Level Design producer and leader to establish a communication pipeline for artists and level designers. We used Miro boards and Excel sheets to exchange ideas and reach mutual agreements on which assets would be delivered. During this process, I learned that a good way to communicate a proposal is to clearly explain how it benefits everyone. I explained the current situation sincerely and honestly and showed how the proposal could solve the problem to both teams and earned their supports.
Our efforts alleviated the issue and improved communication between Level Designers and Artists. However, because we implemented these changes halfway through the production stage, we did not have enough time to resolve every issue, and some decisions from either the art or level design teams still deviated from the pipeline. If I could go back in time, I would have the Level Designers and Artists work more closely together from the brainstorming stage. Establishing a clear and mutual vision from the beginning of the project is crucial and can prevent many problems later. This is an important lesson I learned as well.
Conclusion
Communication is an integral part of a producer's everyday life, and becoming proficient at it is a continuous learning process. A producer should not only be a good communicator but also facilitate effective communication within the entire development team. This is key to producing quality work and benefiting everyone involved.
About the Author(s)
You May Also Like