Abstract
Problem: How do you get programmers, designers, artists, and other disciplines on a game team to communicate effectively when they have fundamentally different working styles and social preferences?
Approach: Tim Cain draws on 44 years of industry experience across Interplay, Troika, Carbine, and Obsidian to describe practical strategies — particularly strike teams and co-location — for fostering cross-role communication.
Findings: Strike teams (small, purpose-built groups of 4–8 people focused on a single feature) are the most reliable general solution. For tightly coupled work like UX, physically seating the programmer, artist, and designer together in one room produces dramatically better results despite initial resistance. Different roles attract different personality types that require different accommodations.
Key insight: Cross-discipline communication always produces good results but is frequently difficult to achieve — the solution is structural (strike teams, co-location) rather than just cultural.
1. The Core Problem
Every game development team has programmers, designers, artists, producers, sound designers, and QA — and they all need to collaborate on shared features like combat, dialogue, or stealth systems. But these roles attract fundamentally different types of people with different communication styles, and many of them would rather not talk to each other at all.
The question (posed by a viewer named Boku) is: which roles need to communicate most, and how do you make it happen?
2. Strike Teams
Strike teams are Tim's primary, battle-tested solution. He's used them for decades across multiple studios.
A strike team is a small group (4–8 people, never more than 10–12) assembled for a very specific feature or area of the game. A combat strike team might include the designer who owns combat, the programmers implementing it, relevant artists, a dedicated producer (often an assistant producer), and occasionally sound and QA representatives — especially as the feature nears completion.
They meet regularly, sit around a conference table, and discuss progress on that one specific thing. QA joins to formulate test plans early. Sound joins to understand what audio they'll need. The key constraint is keeping the group small enough for comfortable conversation.
3. The UX Exception: Co-Location
While strike teams work well for most features, Tim found that UX requires something more intense. UX work involves such tight, constant feedback loops between design, art, and code that periodic meetings aren't enough.
3.1. Temple of Elemental Evil Discovery
At Troika, Tim noticed that a programmer, producer, and artist who happened to be seated next to each other in a row produced an exceptional combat HUD for Temple of Elemental Evil. The action bar that visually dropped as you spent movement points — showing exactly when you'd eaten into your action space — emerged from this organic, constant proximity. Tim considers it one of the best implementations of D&D 3.5 combat mechanics ever shipped.
3.2. Carbine: Doing It on Purpose
At Carbine, Tim deliberately replicated this by putting a UI programmer, UI artist, and UI designer together in a single room as a dedicated UX team.
They complained for about two weeks. By week three, they were producing noticeably better work and admitted they liked it. The magic was in the casual, constant feedback: the designer glancing at the programmer's screen and noting something didn't match the design doc, or the artist suggesting a better grouping of UI elements. These micro-corrections, happening in real time rather than in weekly meetings, compounded into significantly better output.
3.3. Outer Worlds: Refined Further
Tim repeated the process at Obsidian on The Outer Worlds. The designer and artist sat together (the programmer was nearby but not in the same room). He added a constraint: every interface had to be designed in grayscale first. Only after Tim approved the value structure could they add color — and only hue, not value changes. This ensured readability and accessibility while giving artists creative freedom within clear bounds.
4. Role Personality Generalizations
With 44 years of observation, Tim offers generalizations about what different roles need (with the caveat that these are generalizations):
4.1. Programmers
- Need quiet, focused environments — even need them
- Chatter, music, and distractions are devastating
- Reluctant to talk even to each other
- Once they discover pair programming or pair debugging, they appreciate collaboration
- Best housed in shared offices with doors (not open plan) and designated quiet hours
4.2. Artists
- Almost the exact opposite of programmers
- Chat constantly while working, often with music or movies playing in the background
- Can seemingly concentrate through noise and visual distraction
- Strongly prefer dark offices — to the point of covering windows with cardboard or foil
- At two different companies, building management filed complaints about blocked windows
- Tim's solution: blackout curtains on the inside, blinds still visible from outside
- Artists say darkness helps them see screens better and distinguish colors more accurately
4.3. Designers
- The hardest to generalize — a true mixed bag
- Some need programmer-level quiet; others thrive on artist-level interaction
- Often depends on the specific task: complex system design demands focus, while collaborative iteration benefits from noise
- Hardest role to assign office space for
5. Accommodating Introverts
Tim addresses team members who find interaction genuinely painful — whether they're on the spectrum, deeply introverted, or simply uncomfortable in groups. His approach is a mutual accommodation:
- They don't have to run strike teams or speak in meetings
- They don't have to be socially active
- But they do have to be present — to hear what's being discussed
- Tim commits to making accommodations for them, but asks them to accommodate the team's need for their presence in return
- Neither side gets to make absolute ultimatums
- If someone truly cannot tolerate any collaboration, solo development may be a better fit
6. References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=ptjU6Y0XUCE