10 Personas: Who Turian Is Built For

The biggest risk when building a tool is shaping it to fit only the maker's own style and preferences. But I always wanted Turian to be useful to the people who use it, not just to me. This article says who I am building Turian for, by name.

In 256 Gamedev Profiles I proposed a vocabulary for the people who make games: four layers, sixteen styles, and a four-letter profile for every maker. From that vocabulary, this article selects ten people, fictional but specific on purpose. Each has a day job, a profile from the vocabulary, and a pair of one-liners: what they love and what they hate. The love doubles as the dealbreaker, the single test that decides whether they stay. The hate is what makes them walk away without explaining why. Feature lists can be compared in tables; a love is what a person checks first and never stops checking.

Seven of the ten make games with their own hands. The other three, Gabriel, Isabela and Julio, never open the editor to make anything: they build the pipeline, pick the stack and measure the delivery. They are here because they act for dozens of makers, but the center of gravity of this list is the maker.

I am publishing it on purpose. Roadmap items and issues will use these names, and a tool that keeps its audience secret is asking that audience to guess.

This article introduces the people and what they ask for. Where Turian actually stands for each of them today, honestly including the gaps, is the companion audit.

The ten at a glance

Persona	Profile	Day job	Loves	Hates
Ana	P·W·I·J	High school	A first session, in her own language, that ends with something running	A step that fails without telling her why
Benjamin	C·P·A·J	Solo code-first indie	Control of everything, from asset loading to the build	A workflow that requires the editor
Carlos	I·W·I·C	Remote jam-born studio	Play-in-editor loops and hats that do not block each other	One hat blocking the other three
Daniela	A·P·I·J	2D/3D game artist	Fidelity: the asset she made, arriving as she made it	An import that quietly degrades it
Eduardo	I·W·C·J	Level designer	Crash-free sessions over a huge asset library	One corrupted file, whatever was fixed afterwards
Fernando	I·H·I·J	Economy designer	Balance in spreadsheets, no programmer in the loop	Asking a programmer to change a number
Gabriel	C·P·A·C	Tools and DevOps	Builds twice, headless, same bits, rollback one click away	A task that can only be done in the GUI editor
Isabela	C·H·A·D	AA studio president	Benchmarks with receipts, plain pricing, a hiring market that knows the tool	Hype that ships a demo and calls it a roadmap
Julio	C·H·A·C	AAA producer	Delivery that can be measured, split and consolidated	Surprises, and errors that pinpoint nothing
Mariana	C·S·T·I	Toolmaker	A versioned API and a store where packages survive versions	Breaking changes she did not cause

Ana

The teenage hobbyist

P·S·I·J: Prototyper, Shopper, Integrator, Journeyman.

Ana is sixteen and goes to high school in São Paulo. English is a school subject, not her language, and the internet's tutorials assume it anyway. She wants to make games for fun about the world around her: her classroom, her friends, the canteen queue. She follows every tutorial as if it were her only work. Pause, copy, unpause, repeat, and by the end of the evening there is a game.

She needs help with everything, and knows it: tutorials to follow, ready-made assets from the store, an editor she can drive by drag-and-drop, and little to no programming in between. She never starts from a blank canvas. She takes something that works, swaps the art, bends the rules until the game is about her friends, and shares the result. When a step fails, she assumes the mistake is hers.

Loves: a first session, in her own language, that ends with something running.

Hates: a step that fails without telling her why.

Benjamin

The solo code-first indie

C·P·A·J: Closer, Purist, Architect, Journeyman.

Benjamin is a solo developer with a shipping habit: two games out, a third in progress. His games are made almost entirely in code, the way he learned with MonoGame, and the terminal is where work gets done. The version control history is the project's diary.

Editors, in Benjamin's world, are for internal tools, and he builds his own. What he must have is control of everything: how assets load, where memory goes, what costs a frame, how the build is made. Studio is not the enemy; it is a window he opens rarely, and anything that can only be done by clicking is a bug in someone else's design.

Loves: control of everything, from asset loading and memory to performance and the build.

Hates: a workflow that requires the editor.

Carlos

The mini jam-born studio d

I·W·I·C: Iterator, Worldbuilder, Integrator, Conductor.

Carlos and three friends met at a game jam. The prototype won nothing, the friendship stuck, and a studio was born: four people, all remote, each with a role on paper and every hat in practice. One week Carlos is the programmer, the next he is in the level, and the week after he is merging somebody else's.

The studio runs on third-party assets, especially for systems, so the programming is mostly glue and the game itself. For Carlos, tuning is the work, and every second between an edit and a playtest is a tax paid a hundred times a day. The same instinct applies to the team: each of the four needs to ship their part without waiting for the others.

Loves: play-in-editor loops, and each hat shipping without waiting on the others.

Hates: one hat blocking the other three.

Daniela

The game artist

A·P·I·J: Alchemist, Purist, Integrator, Journeyman.

Daniela's day is a conveyor belt: Photoshop or GIMP, export; Blender if it is 3D, export again; import into the engine, tweak the materials; playtest; ok, next asset. Between her tools and the engine, a thousand round trips a year, and each one is a chance for something to drift.

She is an artist, not an engineer, and the engine's internals are not her business. What she cares about is fidelity: the asset she spent hours creating must arrive in the game the way she made it, same colors, same normals, same feel. An editor that offers the same visual functionalities as the tools she came from, materials, curves, color grading, is a major plus, because what she cannot see, she cannot fix. Her ok on the conveyor belt is a professional's ok; inside, nothing is ever quite as good as the picture in her head.

Loves: fidelity: hours of Photoshop or Blender arriving in the game exactly as she made them.

Hates: an import that quietly degrades what she spent hours creating.

Eduardo

The level designer

I·W·C·J: Iterator, Worldbuilder, Curator, Journeyman.

Eduardo mixes and matches given assets into levels, UI menus and the spaces between them. For him it is all about composition. When the composition is right, he reaches further, for particles and tweens, because the point is conveying art in a multimedia form, and a static picture is only the beginning.

He lives inside other people's work: consolidating the new inventory as the artists deliver it, playtesting combat animations as they land, keeping a crowded scene consistent with kits, prefabs and variants. Undo is sacred, and the library is the work of years.

Loves: crash-free sessions over a huge asset library.

Hates: one corrupted file, whatever was fixed afterwards.

Fernando

The economy designer

I·H·I·J: Iterator, Hermit, Integrator, Journeyman.

Fernando balances a game economy: damage curves, drop rates, prices, the numbers that decide whether a player stays. He has opinions about all of them and a spreadsheet to prove each one. His tools live outside the game: import and export in custom formats, numbers typed in by hand, sliders, statistics, analytics.

He works mostly outside the game editor and prefers it that way, in tools built for whole tables rather than single values. A request that begins with "ask a programmer" ends a week later with the wrong value, so the game has to take the numbers as they are.

Loves: balance in spreadsheets, no programmer in the loop.

Hates: asking a programmer to change a number.

Gabriel

The DevOps

C·P·A·C: Closer, Purist, Architect, Conductor.

Gabriel owns the build farm at a mid-sized studio and chose the stack on his own authority. His dashboards tell him where every build is, which of the four targets it is heading to, Android, iOS, PC or console, and how to roll any of them back. He has not opened the editor this quarter, and the game shipped anyway.

He loves APIs and the headless life, and his rule is simple: anything the pipeline needs must be doable from the command line, because a feature that exists only in the GUI editor does not exist for CI. If a build from a clean checkout differs on Tuesday from Monday's, that is not a mystery, it is a defect in somebody's process. Magic is a liability. Manual steps that live in one person's head are an incident waiting to happen.

Loves: builds twice, headless, same bits, with rollback one click away.

Hates: a task that can only be done in the GUI editor.

Isabela

The AA studio president

C·H·A·D: Closer, Hermit, Architect, Director.

Isabela runs a new studio formed by people who left an AAA company together. She decides the toolchains based on the skills the team already has, and without passion, which is deliberate: passion is a fine reason to make a game and a terrible reason to pick a stack. She meets the studio's work during periodic milestone and sprint play-testing sessions, and that is enough.

She does not have the luxury of loving an engine. A stack decision is four spreadsheets: the price, per seat or royalty, the license terms, the ecosystem her team will live in, and the hiring market, because what the next three hires already know will matter more than any feature list. She lived through the hype cycles, and knows what adopting somebody else's excitement costs a forty-person team. Roadmaps without receipts are marketing.

Loves: benchmarks with receipts, plain pricing, and a hiring market that already knows the tool.

Hates: hype for its own sake, the kind that ships a demo and calls it a roadmap.

Julio

The AAA producer

C·H·A·C: Closer, Hermit, Architect, Conductor.

Julio coordinates several teams through issues and tickets, and opens the game for one reason: to check that a feature works, never to build one. He is a bit proficient in every tool on the pipeline, which is exactly as much as the job needs. What he needs to know is who ships what, how big the next patch is and how long a build takes.

His week is versioning, splitting the work, consolidation and the review. If it can be measured, it can be managed; if it cannot, it will surprise everyone at the worst moment. His quietest wish is also his loudest: warnings and error messages that pinpoint the problem, because a team that cannot name the failure spends its review guessing.

Loves: per-team delivery that can be measured, split, consolidated and reviewed.

Hates: surprises, and error messages that pinpoint nothing.

Mariana

The toolmaker

C·S·T·I: Closer, Shopper, Toolsmith, Influencer.

Mariana's role on the team is building tools and plugins that help everyone else make the game, and she knows the editor APIs better than anyone in the building. One of her internal creations turned out so robust that she put it in the marketplace, more by accident than by plan. It found a dedicated fan base, made an extra buck for the studio, and now she serves internal and external clients with the same code.

She ships on a rhythm and tells the world about each release. Her two fears are one fear twice: a breaking change in the engine is a support ticket she did not cause, and a lost reference after an update is a refund request.

Loves: the editor as a documented, versioned API, and a store where packages survive versions.

Hates: breaking changes she did not cause.

What the ten ask for together

Read the ten side by side and three requests keep coming back:

Everything the editor can do, the command line can do. Benjamin, Gabriel, Julio and Isabela will never agree on an editor, but they agree on a pipeline.
Identity that survives change. Mariana, Julio and Eduardo all need to be able to rename, move and update without breaking what depends on them.
Numbers, not adjectives. Isabela, Julio and Gabriel will not take "fast" or "reproducible" on faith. Every claim should come with a measurement and a way to repeat it.

These three requests are the spine of the roadmap. Wherever a roadmap item or issue names an audience, it names one of these ten.

The people are the easy half. The companion audit goes persona by persona through what each of them finds in Turian today, what they love and hate, and what I still owe them.