Emre Guzel
Building Games That Make Players Smile
Emre Güzel co-founded a three-person game studio six months ago. In episode #5, he explains how they picked their first project, why he calls AI “a good servant but a bad master,” and the single mistake that gets beginners stuck for years.
What makes someone want to build a game studio?
Most founders in games are chasing a feeling they had as a player, not a business model.
Emre Güzel’s first computer ran DOS rather than Windows, and the first game he remembers finishing was the original Prince of Persia—crude by any modern standard, but the first one that told him a story. The decisive moment arrived a few years later, when his brother installed Diablo 2 on his first Windows PC. What stopped him wasn’t the gameplay—it was the opening cinematic, something he had never encountered before. He describes sitting in front of it, convinced he would be playing this game for the rest of his life.
That reaction is now, in effect, the product brief for his company.
“My main motivation is to put a smile on the player’s face.”
He’s realistic about how little of a founder’s day that covers. Running a studio, he points out, is a fundamentally different job than making a game: financing, runway, and reputation management arrive alongside the design work, and none of them existed when he was building things for himself.
His reference point is Bethesda—several studios under one roof, id Software and ZeniMax Media alongside it, and worlds large enough that a small team can’t meaningfully compare itself to them. The Elder Scrolls IV: Oblivion was the second game that reset his expectations. He also mounts an unfashionable defense of Starfield, arguing the reception was disproportionate to the work involved: an army of engineers spent years on it and received very little credit, which he finds both unfair and revealing a lot about how communities treat large releases.
So the motivation here is emotional first and commercial second—which is precisely why the business side has to be learned on purpose rather than absorbed by osmosis.
How do three strangers start a studio together?
Alignment on values comes before alignment on product.
The company began at a games conference, where Emre and his friend spent most of their time complaining. Not about a specific game, but about a pattern: decisions across the industry that seemed to be optimized for revenue rather than for the person holding the controller. Somewhere in that conversation, the complaining turned into a question—what would a game look like if you designed it purely for enjoyment? And then came the decision to build one.
The third co-founder was found in an online community, and he was complaining, too.
“We’re kind of three guys, three random dudes who got along, and we don’t like what’s been going on. And we basically want to make a change.”
What happened next is where it’s worth taking notes. Before writing any code, the three spent roughly two weeks doing nothing but talking—visions, expectations, life histories, and what each of them actually wanted out of the next few years. Emre describes the process as deliberately strict. Only once they were satisfied that their answers lined up did they open a project file.
For a team that had known each other for a matter of weeks, that upfront diligence was the substitute for years of shared history.
They were united in their objection, and it was easy to name. Emre singles out in-app purchases as the clearest example of the pattern they’re reacting against:
“I hate in-app purchases. I don’t like them because they progressively decrease the amount of enjoyment that the player is having.”
He frames monetization as one item in a much longer list of small design decisions that quietly make games predictable and boring. Removing those, in his view, is most of the work.
The product itself came from merging two halves. Emre wanted a Diablo-like top-down RPG; his co-founder had a storyline, which he pitched across four uninterrupted hours. Emre listened to all of it, enjoyed it, and concluded that his mechanics alongside that narrative would produce something the three of them would actually want to play. Roles then fell out naturally: one member is responsible for level design, story, and art direction; another handles visuals, level design, and code; and Emre writes the mechanics.
Thus, a three-person studio survives on value alignment rather than on a perfectly specified design document.
Should a new studio build a standalone game or a series?
A small team should invest in reusable technology first, then let player feedback decide the scope.
Rather than pouring everything into a single title, the team builds a framework that will let them produce games of the same type repeatedly. The intention is a series, not a one-off—a decision that changes what “finished” means for the first project, since a meaningful share of the work goes into building infrastructure that outlives it.
What comes after release is deliberately unresolved. They have plans, but Emre is explicit that those plans are contingent on what players say—because the studio’s entire premise is enjoyment, and it can only be assessed once people have experienced it.
So the first game isn’t really what you’re betting on—the framework plus the feedback loop is.
How do you choose a good outsourcing partner?
Look at the portfolio first, then test whether the partner is willing to talk back.
Emre’s filter has two steps, and it’s the second that eliminates most vendors. The portfolio tells you whether the work is good. The conversation tells you whether the studio on the other end actually understands what you’re trying to build—and, more importantly, whether they want to be part of it.
The failure mode he describes is a supplier who treats the project as somebody else’s: they deliver exactly what was specified, hand it over, and move on. Nothing is technically wrong with that, which is what makes it hard to argue with, but it means the client carries every creative decision alone.
What he’s looking for instead is closer to a co-author—a partner who discusses the brief, disagrees where it makes sense, and volunteers feedback that wasn’t requested.
So a good outsourcing partner is judged on the quality of their pushback, not only the quality of their work.
Can AI replace people in game development?
Not yet. At this stage AI is a tool, and treating it as anything more will backfire.
Emre’s summary of the current state is a borrowed line he keeps returning to:
“AI is a good servant but a bad master.”
He sees developers pushing it into art, audio, sound effects, and code, and he’s specific about where it stops being useful—on genuinely complex systems. It stops being helpful, and you end up working around it. That’s an observation about today rather than a claim about the ceiling—he’s the first to say the pace of progress is being underestimated and offers the analogy of describing a heart transplant to someone two hundred years ago.
His forecast until artificial general intelligence arrives is augmentation rather than replacement: faster development, more games shipped, and more people able to ship them. When asked whether that floods the market, he doesn’t pretend to know.
The more interesting limit he raises is conceptual. Could AI eventually generate a genuinely good game tailored to any individual? Only if it could first solve what “good” means—and Emre uses himself as a counterexample. The Prince of Persia he loved as a child would land badly with almost any player today. Yet at the time, it was the best game he’d ever played. Personal taste is that context dependent. For a system to generate a perfect game for one person, it would need to model that person, not the genre.
So AI’s ceiling in games is limited less by generation quality than by how well it can model a specific human being.
Why does AI sometimes slow development down?
Because it is persuasive before it is correct, and the cost only shows up later.
This was the most counterintuitive stretch of the episode. AI was meant to compress timelines. Emre argues that, in practice, heavy reliance on it often does the opposite. Developers lean on it too hard, and the development process gets slower, not faster.
The mechanism is confidence rather than capability:
“It can convince you that it is generating something really good, but in reality it is not, which makes you realize it afterward—and then you are basically losing a lot of time in the process.”
The output looks finished. You accept it, build on top of it, and discover the problem several steps downstream, at which point unwinding it costs more than writing it yourself would have. His counterweight is craft, and he frames it almost as a law of physics:
“If you love something, you naturally get better at it. And you are going to be better than the tools that we are using today.”
None of which means avoiding the tools. His own use is substantial—AI has largely replaced search for him, and he finds it most valuable at the beginning of a problem rather than at the end. When he’s designing a system architecture, he draws ideas from it and then synthesizes them himself, treating the model as a way of generating perspectives he wouldn’t have reached alone.
The productive pattern: AI for divergence at the start, and human judgment for everything after.
Should developers be afraid of AGI?
Emre says yes. But the risk he describes is a machine following instructions too literally, not a machine turning hostile.
First, the term. AGI stands for artificial general intelligence: a system that can think at least as well as a human across any task, rather than being good at one narrow job. Everything available today—including the tools discussed above—is narrow AI. AGI doesn’t exist yet, and Emre treats its arrival as the point where his forecast about “assistance, not replacement” would end.
When asked directly whether it frightens him, he doesn’t hedge. It does, and specifically because nobody can predict what such a system would do. His example is the standard one in AI safety, and he delivers it drily:
“Let’s say that you have ordered ‘Save humanity.’ Then, for the purpose of achieving that task, it’s not going to be very merciful, I should say.”
The point is that the instruction would be followed correctly. Give a sufficiently capable system a goal without constraints, and the most efficient route to that goal may be one no human would have chosen. The hosts note that this is more or less the plot of Terminator 2 and mention the Love, Death & Robots episode where machines conclude humanity isn’t worth keeping around.
Emre agrees on the shape of the risk but stays relaxed about the timeline—he doesn’t expect any of it within our lifetimes.
So the concern is real but distant, which is why the practical conversation stays anchored on the tools that exist now.
Is AR more interesting than VR for games?
Emre thinks so—and his argument is that augmented reality is underused rather than overrated.
Here are both terms in short. VR (virtual reality) replaces your surroundings entirely: you put on a headset, and you’re somewhere else. AR (augmented reality) leaves the real world where it is and layers digital objects on top of it through a phone camera or a transparent headset. Pokémon GO is still the best-known example.
When he is offered to pick any project in the world, Emre picks one that doesn’t exist: a D&D-style tabletop game built in augmented reality. The gap he describes is specific. The dungeon master says you’re standing in a dark forest, the night is black, the wind is coming from the north, and everyone at the table is looking at a flat grid and some miniatures. AR would let the players see the forest without leaving the table.
So why is VR the more popular of the two? Emre’s explanation gets at something deeper about why people play games. Most players are looking for an escape from daily stress, and VR delivers a clean break. AR asks you to stay in your own living room, which may simply be a weaker offer.
The counterargument in the episode comes from Anastasia, who describes a childhood Nokia game that used the phone camera to hunt virus molecules around the room—primitive, but genuinely exciting at the time. The speakers land on the same conclusion: AR’s problem isn’t the hardware. Its native genre hasn’t been found yet. Survival and hunting games get floated as candidates alongside tabletop.
What will the game industry look like in 5–10 years?
More developers, more games, and the lowest barrier to entry in the history of video games.
Emre’s forecast is short and optimistic. The knowledge required to build games is now available to anyone with an internet connection, at no cost, which he considers one of the genuinely remarkable facts about the present moment:
“Anyone these days can learn how to develop games through the internet. And it’s free.”
His conclusion follows directly: the next decade belongs to indie developers, in volume.
The game that shows him where the bar now sits is Elden Ring, and he makes no attempt to qualify it:
“It is absolutely an art. It is not a game, it is art.”
He describes being repeatedly surprised by it—convinced he had seen everything the game could show him, then watching the DLC trailer and being proven wrong again.
Asked who he’d like to hear interviewed, he names John Carmack: lead programmer on Doom, Wolfenstein, and Quake, author of the shadow-projection technique still in use today, and a man who walked away from games after two decades to work on AGI. What interests Emre isn’t the engineering. It’s the decision—he can’t imagine what would make someone abandon twenty years of work, and he’d like to hear it explained.
So the next decade belongs to small teams, while the standard they’re measured against keeps rising.
What advice would you give to a beginner game developer?
Pick one small project you actually want to play, and build it step by step.
This was the most direct answer of the episode, and it starts with an emotional problem rather than a technical one. Most people quit, Emre says, because they can’t learn fast enough—and the fix is consistency and willpower rather than talent.
The second failure is choosing the wrong first project. People try to build Elden Ring, quickly discover they can’t, and conclude they aren’t capable. The correct scope is something you genuinely believe you can finish, with one non-negotiable condition:
“You need to love to play the game that you’re building.”
The method is deliberately unglamorous:
Movement
Work out how to make a character move.
Combat
Then combat.
The next system
Then the next system. Each step teaches you both the problem and the tool, and the project pulls the learning along behind it.
And then there’s the trap that consumes years:
“It’s called tutorial hell. People are just continuously watching tutorials but never making anything.”
He calls it the worst thing you can do to yourself, and his entire advice can be boiled down to two words: do projects.
Does the path actually lead to AAA? He says yes, but through the technology rather than around it. You learn the basics, exhaust what the surface has to teach you, and eventually start wondering how the engine works underneath—what’s happening backstage with the tools you’ve been using. But there’s one realistic caveat: AAA titles need a small army of engineers, so the honest goal for an individual is contributing to one, not building one alone.
So the route to a large project runs through a series of small, finished ones.
What is the hardest part of making a game?
Everything that happens before the money arrives—and everything you have to say out loud to get it.
Here the hosts look at the question from a different perspective, and Anastasia answers it from the publishing side: the hardest part isn’t running out of money before the project is finished. What creates the real problem is that funding requires something to show, so you need a prototype or a demo before anyone will pay for the game that prototype is meant to become. You have to learn about the market and the competition, walk into a room with an idea you’re passionate about, explain why it’s different, and then defend it against people whose job is to find the holes. Being ready for criticism, she argues, is the hardest skill in the whole process.
Emre hasn’t hit negative feedback on his project yet, and he’s careful about how much that means:
“The idea itself is good, but the most important part is the execution of it.”
When it comes to knowing when to stop revising, his release bar is internal before it’s external:
“If we are not enjoying it ourselves, we are not satisfied with the product—and therefore we wouldn’t release it.”
For everything he can’t judge himself, the mechanism is early access, on the grounds that developers go blind to their own work. Players supply the negatives the team can no longer see.
So the hardest part isn’t developing. It’s funding it, defending it, and knowing when it’s done.
Conclusion
Emre Güzel’s studio is six to eight months old and has three people in it. It exists because three strangers agreed that too many games are designed for something other than fun, and the company they’re building is an attempt to prove the alternative works.
The practical takeaways from the episode:
- Align on values before you align on the product—two weeks of hard conversations bought this team the trust that usually takes years
- Build a framework, not a single title, if you plan to make more than one game
- Judge an outsourcing partner by whether they push back, not just by what they deliver
- Use AI for ideas and starting points—over-relying on it costs more time than it saves
- Escape tutorial hell by finishing one small project you genuinely want to play
- Your release bar is your own enjoyment first, player feedback second
Ultimately, the episode is an argument that fun is a design constraint, and that most of the industry’s disappointments come from optimizing for something else.
