Ready to admit you can’t do everything alone? 👀
«Momentum» — is an original column from my Telegram channel. What you’re reading is an English translation of the piece I first published in Russian, so some turns of phrase may feel a little rough. Btw, it is just a way of structuring my own thoughts aloud, putting them in order and searching for a live dialogue. Enjoy the read! 😉
Preface.
I hate the idea of solo development. Not just “don’t like” — I despise it as a phenomenon that, for some reason, people love to romanticize. Not the games themselves, because I, like you, genuinely admire cases like Animal Well, Stardew Valley, Papers, Please, and many others. We all need a guiding star. But I hate how this path of the “suffering loner” gets normalized and even standardized, turning an exception to the rule into some supposedly attainable ideal.
And here’s what’s strange: no matter how many stories of these very “lone wolves” I read, there’s always a clear thread of gratitude to friends, family, early testers — the people they turned to for help. Yet when we turn the page, we somehow remember only that a single person, it turns out, suffered.
Consciously choosing the path of total isolation is the most thankless, destructive, and simply wrong thing you can do to your creative potential. You’ll ask:
«And what’s the alternative?»
Don’t be afraid to open your mouth and say a simple word: “help”! Don’t be afraid to admit your incompetence. Don’t be afraid to develop your communication skills and build new connections. I want this to be crystal clear — here’s the core meaning of this entire momentum in one sentence: I BEG YOU, stop thinking that asking for help is weakness, that a team is a crutch, and that a true creator must suffer alone. THIS IS A LIE!
(And a quick note for those who think I’m about to spend fifteen hundred words chewing on this one thought: NO. What follows will be entirely practical takeaways, which I want to validate together with you.)
Accepting the fact that people are different and that you physically cannot understand something as well as a person who has devoted their entire life to it — that’s not defeat, it’s a huge step toward maturity. Because you’ll only build the skill of seeing the world from every angle after decades of experience (and don’t get me wrong, I’m still on that road myself, but I know for sure from which point you must not start it).
And you’ll either walk that road by making the same mistake hundreds of thousands of times alone, or you’ll find people who will help you notice those mistakes — while you do the same for them. By trying to become a master of everything, you are guaranteed to become a master of nothing. You’ll simply scatter yourself across dozens of domains without ever going deep into the one you love most.
«Mastery is not at all a derivative of genius or talent. It is a derivative of time and effort applied to a given field of knowledge»
— Robert Greene, Mastery (c)
It is precisely from this desire to create, to delve deeper, and to grow together that this momentum was born. So this time, it won’t be just another monologue of mine. It’s our joint experiment with my friend and the programmer on our project, Eugene — a person whose mindset is the complete opposite of mine, and who will join this text a little later.
Together, we’ll try to answer honestly: how do you accept the fact that you may be an excellent game designer but a terrible programmer (and vice versa)? How do you turn your weakness not into a complex, but into a point of connection for another person? And how is it that social intelligence — not technical skills — becomes the force that allows two different views of the world to be assembled into one working project?
What’s behind the door?
So that our dialogue doesn’t turn into abstract philosophy, let’s agree on terms right away. Any game, from an indie gem to an AAA blockbuster, rests on two absolutely equal pillars: Concept (what and, most importantly, why we are making) and Execution (how exactly we are making it and for whom). Remove even one, and the whole structure will inevitably collapse.
And when one of these parts is missing, we get two classic types of failed projects.
- The first — Concept without Execution. Let’s call it a “theoretical game”.
- The second — Execution without Concept. That’s a “technical demo”.
A “theoretical game” can be brilliant. It can be laid out in a design doc, a pitch deck, or a presentation, with perfect loops and deep meaning. But for the player, it doesn’t exist. Its value is zero. It’s a dead project that never managed to be born.
A “technical demo,” in turn, can be impeccable. Working mechanics, optimized code, stable performance. But it’s… not fun to play. There is no purpose, no engaging experience, no soul. This is also a dead project; it was simply born a zombie: it moves, but it isn’t alive.
And before you decide that one of these failures is somehow “more noble” than the other, let’s face the truth. In the real world, with almost equal probability, people will think you’re out of your mind in both cases — whether you show an investor a brilliant idea in a presentation or a working gray box with a couple of mechanics. In response, you’ll most likely hear:
«Sounds interesting / looks cool. Come back when you have a game».
Both paths lead to the same dead end — a project that never became something cohesive. And if we dissect these failures, their key mistakes can be formulated as follows:
- The “theoretical game” mistake — ignoring technical constraints, overcomplicating systems on paper, and a complete lack of a feedback loop.
- The “technical demo” mistake — the absence of a clear gameplay loop, ignoring player motivation, and a fundamental misunderstanding of the project’s overall purpose.
Arguing over which failure is worse or whose contribution is more important is stupidly pointless and counterproductive. Both outcomes are failures. The problem lies in the mindset that pits them against each other. Real development begins when the team sits not opposite each other, but shoulder to shoulder, to look together at a shared goal.
This dichotomy of “Concept” and “Execution” runs through the entire industry. Behind the first stand game designers, artists, writers. Behind the second stand programmers, marketers, QA engineers. Every time these two camps stop talking, the game starts rotting from within.
Now that we agree on the rules of the game, it’s time to see what this very handshake between a game designer and a programmer looks like in practice.
The Game Designer’s View
If you ask ten game designers to define their profession, you’ll get eleven different answers, and each will be correct in its own way. Game design is not an exact science; it’s where psychology, mathematics, storytelling, and other no-less-important disciplines intersect (and we have to account for all of this, which is exactly what I try to cover in my blog!).
That’s why a rigid definition will always feel incomplete. But in day-to-day work, in conversations with the team, and in attempts to explain to yourself “what on earth are you even doing?”, you need some footing. A formulation that helps you feel the ground under your feet each day sounds roughly like this:
«Game design is the process of engineering a system of interconnected rules and mechanics that creates a space of meaningful choice for the player and, as a result, a unique interactive experience.»
Offering such definitions is a thankless and even tacky task. Any definition inevitably narrows and simplifies. But to understand how a game designer looks at a game — and how that view differs from a programmer’s — we need this starting point.
Let’s run a thought experiment. Imagine that, as a game designer, I don’t need to think about how the game will look, how it will sound, or whether it will be optimized at all (by no means do this in real life; it’s bad for the project’s health!). What remains in the end? What is the skeleton I’m designing?
At the core, there’s a continuous dialogue between the Player and the System. This is my starting point. I don’t think of them separately. When I form a mental image of the game, I must imagine how these two entities will interact, respond to each other, and change each other in the process. Who is the person on the other side of the screen? Why did they launch our game at all, and what goal are they pursuing? And how will our system of rules and mechanics respond to each of their actions to nudge them forward?
There’s a useful practice for storytellers and speakers. To stay on track and hold attention, you mark out key points of your story in your head beforehand. Then, as you speak, you pull a narrative thread from one point to the next, trying not to drop it and to keep the whole intact.
In essence, my job is the same, but at an interactive scale. I set up the same kind of “points” for the player: goals, rules, mechanics, challenges. But unlike a story, this “thread” is pulled by the player themselves, through their own actions and decisions. My task is to design that space with clear rules that lets them find and draw their own unique path.
Now to the point. Eugene and I will take turns answering three questions that lie at the core of how we work together.
What “truth” do I defend in the project?
My truth is the player.
My task is to give the player not what they ask for, but what they truly want, even if they can’t yet formulate it. Being the defender of the player means being the chief advocate for their experience within our project. I’m the one on the team who keeps asking the uncomfortable questions: «Will this be clear to the player?», «Why should they do this?», «What’s the actual joy in it for them?»
From here comes the “player experience” as a concept that, by the way, can be broken down into three components:
- Readability. The player must understand the rules of the world they’re in. They shouldn’t need to read a design doc to know that lava burns and a tall wall is impassable. My job is to ensure that my work, through the prism of the whole team’s work — from artists to programmers — forms a single, comprehensible feedback system for the player.
- Meaningfulness. Every player action should matter. A choice becomes meaningful only when it has a cost and consequences. Hold a card for a key combo or play it now? Upgrade current gear or save resources for something fundamentally new? Each such choice is a small brick from which the player builds their unique story.
- Value. The system must respond fairly to the player’s actions. If they make a smart decision, they should feel smart. If they make a mistake, they should understand why they failed. This is the core mechanism I’m watching over.
My “truth” is an attempt to create a common language for the whole team. When we all understand the specific experience we want to give the player, implementation debates become constructive. Instead of “like / don’t like,” we start speaking the language of “helps / hinders” in achieving our shared goal. Defending this principle is my main function. This clarity of purpose is the primary way I can help my colleagues avoid wasting effort. But how does that work in practice? That’s what’s next.
How does my work make the rest of the team’s life easier?
Given the context above, my main task here is to eliminate ambiguity and prevent work that will be thrown away. I must create such clear frameworks and such an understandable vision that everyone on the team can freely create and dive deep into solving problems in their domain, without wasting time guessing what others were thinking.
For this, we have a tool called documentation.
And let’s lock in a simple truth that somehow still needs explaining. Documentation is NOT optional. I don’t give a damn whether you work solo, in an indie team, or at a big studio. The process can and should differ, but its existence is mandatory. Refusing to maintain documentation is an admission of your own incompetence and a demonstrative disrespect for the work of others, and first and foremost, for your own.
Every time key decisions are made verbally and recorded nowhere, you plant a time bomb that will inevitably explode into arguments about “who said what,” or you’ll simply forget what you intended to do and where the problem is buried.
Maintaining documentation in any form. From a high-level vision/master doc to a detailed description of all mechanics in a design doc — is the absolute professional minimum. If your idea cannot survive being transferred from your head to paper in a way another person can understand, it is most likely a raw and half-baked idea.
Moreover, having a document protects the project from me. It forces me to carry a thought to its logical conclusion. If I can’t clearly describe a mechanic, it means I haven’t thought it through. It forces me to make decisions and record them instead of changing the concept on the fly five times a day and injecting chaos into the workflow.
Inextricably linked to this is providing context. We need to translate a design idea into our teammates’ language. So a task in the documentation never looks like “make mechanic X.” For a programmer, it will be supplemented with a description of the necessary logic; for an artist, with its functional and visual purpose. When the team understands not only what needs to be done and why it matters to the player, but also sees the task framed with their expertise in mind, they can propose more elegant and efficient solutions than I could have ever imagined.
Of course, this isn’t a call for mindless bureaucracy where form trumps substance. The “workflow” and depth of documentation are things the team should build for themselves. What’s obvious to one person can be utterly incomprehensible to another. Creating such a shared space where ideas aren’t lost and are always accessible — that is the result of competent game design work.
In short: I take full responsibility for the “what” and the “why” to completely free up the team to search for solutions in the “how.”
Where does my expertise end and another’s responsibility begin?
I bear full responsibility for ensuring the game’s rules are understandable, the player’s choices meaningful, and the systems interconnected. That’s the territory where my word is final. If a technical solution, an art asset, or a plot turn fundamentally breaks the core gameplay loop or misleads the player, it’s my direct duty to veto it and explain why it harms the project.
At the same time, the specifics of gamedev force each of us to have basic competencies in adjacent areas. We create a single, cohesive product, working on one “canvas.” My past experience in code, art, or audio exists to help me better understand the big picture and build a shared language with the team. This is a normal part of professional fitness: not mandatory, but desirable. It’s just important to remember that mastery can be achieved only by fully immersing yourself in one discipline.
My expertise finds concrete expression in the game design document. It’s the recorded vision of the concept. When implementation diverges from that vision, I come forward with the phrase, “we have a problem.” That’s the point where my solo work ends and a dialogue begins. We sit down and together look for a solution to this shared problem, which has no single culprit, only a misunderstanding or a technical constraint.
In this dialogue, I won’t crawl into the code or tell anyone how to write it. My questions are always aimed at the result: how does the implemented mechanic feel; does it solve the given task; is it clear to the player? Likewise, I expect the programmer to question my design: is the logic described clearly enough; have all edge cases been considered? Each of our gazes should be fixed on the final result, not on defending our own turf.
That concludes my part. I’ve tried to outline my position and my view of the process as honestly as possible. And now I hand the floor to my friend Eugene. He may speak with less refined phrasing, but he’ll give an honest, straightforward answer to the same three questions from the vantage point of “Execution.”
The Programmer’s View
A bit about myself. I’m Eugene. And I’m the guy who gets a hand on his shoulder and a quiet whisper in his ear:
«We want this mechanic!»
That’s where my work begins: deconstructing the task, estimating its complexity, finding its place in the project’s existing architecture, and spotting potential problems. Simply put, I pour some two-day-old, sludgy coffee into the game designer’s standard-issue mug and start thinking.
What does “thinking” mean for a programmer? First and foremost, it means translating the team’s “wish list” into the language of the engine and logic. In my case, this whole process rests on three simple, unbreakable rules.
Here they are:
- The text is the single source of truth.
- If you feel a mechanic will take half a year — discuss it.
- If you built it differently than intended — listen up.
What “truth” do I defend in the project?
My truth is the long-term health of the project. I’m the person who fights technical debt before it starts devouring time and sanity.
That means thinking through an architecture that won’t crack at the seams when someone comes up with a new mechanic, a character, redraws an asset, or adds a new line of dialogue. Keeping the code as clean as possible and maintaining the integrity of the whole system. I alone am responsible for the cleanliness and formation of logic, systems, and stability. I try to make sure things work, not on a “wing and a prayer.” The player doesn’t care how elegant my code is, but they sure as hell care when the game crashes.
All this engineering honesty isn’t some lofty philosophy; it’s blunt pragmatism. The ultimate goal is one thing: iteration speed. When the foundation is solid, the team can say “hey, let’s try it this way,” and we try it, instead of burying the idea because “the code won’t allow it.” No one but me is going to dig through this code, so it’s on me to keep it from turning into a dumpster fire.
The cause-and-effect is simple. Clean, predictable code means fast, cheap iterations. Tangled code means wasted time, blown deadlines, and buried ideas. My choice is obvious.
How does my work make the rest of the team’s life easier?
In any team, all roads lead to the programmer. Every idea, every asset, every sound eventually passes through code. I have to translate ideas into working code, but in a way that doesn’t require my constant presence later. If the team is waiting for me to make the simplest tweak, we are not making a game.
The practice is simple: anything that isn’t core logic should be configurable without a programmer. Damage, health, speed, colors, sounds — all of it should live in tables or components where anyone but me can change it. If you have to ping me to change damage from 3 to 4, I consider my job a failure. It means I didn’t build a flexible architecture; I built a dependency on myself. I build an environment where everyone can fulfill their role as effectively as possible.
For example: “How do we integrate a card system?” We add a card class, its parameters, and it’s done. “We need more flexibility.” No problem, we do another iteration of rework, add dynamic parameters. “WE’RE GOING TO HAVE N EFFECTS AND 400 CARDS.” No-prob-lem. We align on all the effects, their interactions, and parameters. A new iteration of the task, we break it down into more components and expand the mechanic again. And so on. We repeat this process until we’re satisfied with the result.
I provide the team with confidence. When something works stably, predictably, and transparently, it lowers stress, makes planning realistic, and gives the work meaning. Reliable code is like a solid floor under your feet: you don’t think about it every second, but it’s what allows you to move forward with confidence.
When they can assemble and tune content themselves, without me, they work faster. And I can focus on complex and interesting problems instead of being tech support for code tweaks.
Where does my expertise end and another’s responsibility begin?
My expertise is turning text into working code. Someone else’s responsibility begins when the text (the spec) is shit. I have three red flags for that.
- Something is unclear. If I read a task and don’t understand how it’s supposed to work, I stop. I don’t fill in the blanks. Even a tiny detail, be it a movement speed variable or a stat counter, can later interact with another mechanic, which in turn interacts with another, and so on, to infinity squared. In that case, you have to pause the task and go discuss the little question that popped up. It’s faster and cheaper than rewriting everything later.
- I can do it, but it’ll take six months. If six months is an acceptable timeframe for you, I have no questions. But if time has value, we need to talk. Not right away, though. First, I need to break it down into components and try to figure out the main bottleneck so the discussion can be more productive. At moments like these, I ask the main question every programmer should ask: “Is what we’ll get in the end really worth the cost?”. Sometimes the answer is “yes.” More often, we find a solution that’s ten times simpler.
- You asked, I delivered. I followed the spec to the letter. I show the result. A colleague says, “something’s off.” And that “something’s off” can let rot spread through the whole project. My expertise is making the system work. Theirs is making it feel right. I don’t argue with “feelings.” I ask them to show me what’s wrong, and together we find which “knob” in the code needs to be tweaked to fix it. Because in the end, they are the only one holding this entire infernal machine in their head.
Bottom line: discuss. It’s the only thing that works. And don’t delude yourselves: cool games aren’t made by lone geniuses, but by teams where people know how to talk to each other.
There are many repetitions about discussion in this text, but that is the main idea I wanted to share. Listen to your team, and before long you might just find yourselves at The Game Awards, standing next to your game designer who’s crying with joy!
Conclusion: Games aren’t built alone, but together.
First of all, I want to thank our programmer — Eugene. For agreeing to this experiment, spending the time, and stating his position honestly. And yes, to be fully transparent: I helped him tidy up his thoughts, but every word and every idea in his section is his own, which he personally approved. It’s important for me to say it as it is.
Originally, this momentum was conceived as a text about social intelligence in a game designer’s work — about how vital it is for us to develop empathy and learn to see the world through the eyes of the player, the programmer, the artist. But in the process, I realized that locking myself within my own profession is, once again, building a wall. Because “social intelligence” isn’t a game designer’s skill. It’s the glue of all gamedev of any complex collective creation, really.
I read a lot: Books, audiobooks, articles, postmortems — everything related to our industry. And I, like you, have heard the well-worn phrases about the importance of the team hundreds of times. But sometimes a cliché is just a truth confirmed so many times that it’s become grating. Valve builds teams of “T-shaped” people on this principle. Hideo Kojima says this when he talks about creating games not with “his vision,” but with “our vision” — the vision of the team. And Sid Meier, in my view, formulated this idea best:
«The dichotomy between someone else’s talent and your own is a cause for celebration, because the further apart you are, the more you can offer each other.»
For God’s sake, step outside of gamedev and you’ll hear the same thing. Steve Jobs said:
«Great things in business are never done by one person. They are done by a team of people.»
And John D. Rockefeller went so far as to say:
«The ability to deal with people is as purchasable a commodity as sugar or coffee and I will pay more for that ability than for any other under the sun.»
EVERYONE tells us this.
So what do we do? I sincerely admire anyone who managed to carry their burden from idea to release alone. But I will never trade the experience of shared victories and failures, arguments and insights within a team for the silence and illusory freedom of solo development. And I wouldn’t recommend it to you, either.
If, having read this far, you burn with the dream of making your own game or simply want to become part of gamedev, you’ll have to be honest with yourself. Ask yourself the question:
What, in all of this, is yours?
Designing a game on paper? Writing code? Creating art, audio, a story? What exactly are you willing to study and do for years to become a master at it? Now ask the second, even harder question:
And what isn’t yours?
Where are you objectively weak? Where are you uninterested? Where will you spend ten times the effort to get a result ten times worse than a specialist would? Admitting this isn’t weakness. It’s the starting point of professional growth.
And this advice is especially important if you’re at the very beginning of your journey. Look for people. Those you can learn from. You’ll be surprised how many experienced developers are willing to share their knowledge if they see genuine interest. And those who, like you, don’t know much of anything yet — so you can build something together, even the most useless thing on earth. That experience of shared failures and small victories will give you far more than years spent in solitude.
Because social intelligence is precisely this process of shedding a naive worldview and developing another, more realistic one — of the world, of people, and of yourself. And no, I am by no means urging you to lock yourself away in your own field. When necessary and when you’re interested, grow into adjacent ones. It won’t make you a master of everything, but it will teach you to speak with other masters in a common language.
Don’t be afraid to look for others. Right now, as you read these lines, hundreds of people just like you are burning with the same dream and are just as desperately afraid to take the first step. They think no one needs them, that their ideas are stupid, that their skills aren’t enough. Make that contact possible. Write, show, propose. In the worst case, you’ll get a “no.” But the price of such a mistake is merely experience. And the price of inaction is a dream, buried in loneliness.
And see you where the secrets are hidden → t.me/slepokNTe 👀
