Note: Do not repost the full translation. Please use the first two paragraphs and link to this translation.When reporting on this translation you must mention that it was translated by Source Gaming. For additional information, please read this post.
Source Gaming does not run ads on its website. If you enjoy our translations, please consider donating to our Patreon. It helps us afford new things to translate! Even if you can’t donate, say thanks on Twitter! It’ll make our day!
As a game grows in scale, the space it’s developed in often needs to grow as well. In these cases, how can a director give instructions to their team, which may be made up of hundreds of people?
There aren’t necessarily a lot of games that get to the scale where these methods are used, and the chance to talk about them doesn’t come up often either, so I’m going to try to compile concrete examples based on my own experience.
My seat isn’t closed off from the rest of the team, so there isn’t a Director’s Office so to speak. It’s more like a Director’s Station placed in the room. In the middle of the room, there is a wall or a window.
My seat has two monitors: a large computer monitor and a monitor that shows the game in its current state. This kind of setup applies to handheld game development as well.
Next to me is a large television facing the rest of the staff that’s used for going over what they’re working on. With the flip of a switch, I can project what is on either of my monitors to the large television next to me. This allows the area in front of the television to be maintained as a gathering space.
Of course, instructions for each department are given beforehand and when a staff member brings forward a deliverable, it goes through numerous checks before it becomes my turn to take a look.
When it’s my turn to look it over, I don’t call the staff members in charge of a department to come to my desk directly. Instead, they submit an email called a ‘Director Request.’ These requests are sorted by my email folder and then looked through. Numerous requests come in each day, so it would be pretty chaotic if I started calling them up case by case. I try to deal with them as soon as I can and not stretch them out all day.
When I get an email, I take a quick look at the content that is relative to the director. If it’s a model, I’ll play around with it in a 3D modeling tool. If it’s a specifications document, I’ll check it and add some marks. If it’s UI-related or a piece of artwork, I’ll pull it up on my monitor and take a look. If it’s an animation, a stage, or an effect, I look at it in-game. If it’s sound, I get out my headphones… and so on. After a quick check, once I have an understanding of the problem areas and objectives, I’ll call the corresponding staff members over.
Of course, the staff members directly involved come to my desk and sometimes tens of other related staff members gather around too. We use the large television to go over points and I explain the adjustments that should be made. There is a microphone to make sure everyone can hear as well as other small tools we might need like pointers, a whiteboard, and posable figures.
It’s turned into a system where everyone can listen, ask questions, and share at the same time.
Before, things that were told to the various heads of planning could take on a totally new meaning by the time the information was transferred to the programmers. After seeing that, the importance of everyone being able to listen together became apparent.
The explanations are all captured with voice recorders or on video and are valuable for preventing inconsistencies as the information is dispersed within the teams. I don’t necessarily ask them to do that but it just kind of happens.
The checks continue in this manner one by one, but sometimes things change depending on the situation. We may need to use a sound booth, go to a separate room, or force our way to the section we want to talk about. We’re always sharing information when we gather for these checks which seems to cut down on the number of meetings we need to have.
Well… I tried writing this based on real examples. This isn’t the method I used from the start and it also wasn’t something that I learned from someone. It’s something that has evolved over time through experience and is something I want to modify to be more effective. I want to know more developers’ methods and workflows! And that’s the truth.