Studio Survival Guide
Settling into a studio takes more than learning its tools. This guide covers the first few months, working across art and engineering, and keeping your workload manageable.
On this page
The 90-Day Plan Speaking Artist & Engineer Decoding The Jargon When You Break Something Crunch & Boundaries When You Feel Out Of Your DepthThe 90-Day Plan
Days 1-30: learn the workflow and make a small contribution. Set up the engine, version control, and documentation. Ask people to show you how assets actually move through the pipeline, including any manual workarounds. Keep a list of unfamiliar terms (the glossary may help) and choose a small fix you can review with the team.
Days 31-60: find a useful problem to solve. Watch artists work and ask why particular steps are needed. Keep notes on repeated tasks and workarounds. Pick a manageable improvement, try it with one person, and use their feedback before rolling it out further.
Days 61-90: propose a change with evidence. Explain the problem, its cost, the proposed approach, and the effort involved. Keep the first version small and make recovery straightforward. By this point you should have enough context to discuss the trade-offs with the team.
For example, replacing an old material-assignment tool may look straightforward until you find the unusual asset cases it supports. Ask its users about those cases before designing the replacement. Otherwise you may leave the team maintaining two tools instead of one.
Speaking Artist And Engineer
Artists and engineers may describe the same problem differently. Help each group understand the other's goal and constraints.
| Artists optimise for | Engineers optimise for | |
|---|---|---|
| Values | The result on screen, iteration speed, feel | Correctness, budgets, maintainability |
| A "bug" is | "It looks wrong" | "It violates the spec" |
| Fears | Tools changing mid-production, losing work | Unbounded content, silent workarounds |
| Won over by | Seeing it work on their asset | Numbers, edge cases considered, small diffs |
When discussing an artist's performance concern with engineering, bring a measurable example: which operation takes 40 seconds, under what conditions, and with which assets? When discussing a memory limit with artists, explain the visible consequence and the choices available. If you don't understand a requirement, clarify it before passing it on.
Decoding The Jargon
Studio terms often need local context. A vertical slice demonstrates a representative part of the game; content lock sets limits on new content; technical debt describes work made harder by earlier decisions. Ask what each means on your project, since teams use them differently. The glossary is a useful starting reference.
When Something Breaks
- Let the affected team know promptly. Say what is broken, what you're doing, and when you'll update them. For example: 'My change broke prop exports. I'm checking the rollback now and will update you in 20 minutes.'
- Restore a working path where you can. Check that a rollback is safe, then investigate from a stable state. The version-control guide covers the basics.
- Follow up with what you learned. Explain the cause, the fix, and any check you've added. Avoid promising it can never happen again; show how you've reduced the risk.
Crunch & Boundaries
Keep your workload visible and discuss priorities with your lead when requests compete. Explain the cost of taking on new work and agree what moves. If overtime becomes routine, raise the pattern and its impact rather than treating every deadline as an isolated exception. Your team's response will help you judge whether the situation is improving.
When You Feel Out Of Your Depth
Technical art spans enough subjects that you won't know all of them equally well. That's normal. Be clear about what you know, ask for help where someone else has more experience, and make a plan to investigate the rest. You can contribute without having an immediate answer to every question.