Quit Your Job to Make Games? – What Charlie Brandick Learned Going From Teacher to Valorant Game Director to Indie Founder:
A lot of people want to quit their job and make games. Fewer people think carefully about what that actually requires before they do it. Charlie Brandick, founder of Quetzal-Core Games, has been on both sides of that decision, spending over a decade moving from elementary school teacher to junior game designer to Valorant game director before stepping out to build his own studio.
He joined Dan Long on the IndieGameBusiness® podcast to talk about what he knows now that he wishes he had known at the start, what the games industry actually requires of people who want to work in it professionally, and what separates developers who build something that lasts from those who burn out or stall out before they finish.
Passion for Games Is Not the Same as Doing It as a Job:
The first thing Charlie addressed directly is the gap between loving games and being prepared to make them professionally. His point is not that passion does not matter but that passion alone does not translate into the skills and habits the work actually demands.
When you are passionate about something, you can pick it up and put it down. You can be as excited about it as you want on your own terms. When it is a job, you need to plan. You need to execute. You need to collaborate. You need to manage time, people, budgets, documentation, and scope. None of that disappears just because the thing you are building is a game.
He named a few things developers commonly bring into their early outreach that signal they have not yet made this shift:
- Saying you are passionate about games on a resume. Everyone applying for a games job is passionate about games. It is not a differentiator.
- Claiming you have a great idea. Everyone working on a project believes their idea is great. What matters is whether you can execute on it and what tangible skills you bring to a team.
- Saying you have been a gamer since childhood. Being a longtime player does not translate into being able to build, ship, or maintain a game professionally.
What does matter is being able to point to something concrete: a completed game jam project, a working prototype, experience organizing people under pressure, skills that transfer from another field. Charlie’s background in audio production and Photoshop gave him immediate contributions to make at Seismic even before he had formal game development experience. His organizational habits and people skills from teaching turned out to matter just as much as technical ability once he was inside a studio.
Work on Other People’s Projects Before Your Own:
One of Charlie’s most consistent pieces of advice is something many aspiring developers resist: before you try to recruit people to your project, go work on someone else’s.
His reasoning is practical. Everyone in early game development has their own idea they are excited about. Walking into that community and expecting others to get excited about your idea, do your work, and subordinate their own projects to yours is a misread of how the community actually operates. The people who build real relationships and accumulate real skills early on tend to be the ones who show up and offer help first.
That is how Charlie got in. He did not start with his own project. He found someone working on something and offered his time. He did not get paid. He learned. The skills he picked up in that experience, Git, Unity, how development teams actually structure work, turned out to be the exact skills the studio later asked him about in what turned out to be a job interview.
Beyond getting in, working on other people’s projects exposes you to habits and systems you would never develop on your own:
- How other teams structure their Unity hierarchies and why it matters for collaboration
- How experienced developers handle Git commits, naming conventions, and version control in a way that makes large codebases searchable and manageable
- How different people run meetings, write documentation, and organize files, showing you both what works and what to avoid
- How teams handle scope, disagreement, and failure, which are skills you can only learn by being in the room when those things happen
Charlie’s wife, a technical rigger with AAA experience, looked at how his team was handling Git commits on the current Quetzal-Core project and suggested a simple bracket-based naming convention that made the history dramatically easier to search. She learned it at her job. He adopted it immediately. That kind of knowledge transfer only happens when you are actively working with people who have more experience in a specific area than you do.
Understanding Platforms Before You Commit to One:
Charlie has developed on practically every platform available: mobile, VR, AR, PC, console, theme park rides, and AAA titles. That breadth gave him a clear-eyed view of what each platform actually demands and where the realistic audiences for each live.
His take on platform choice for developers trying to reach the largest number of people is straightforward: go where people already are. Players already have phones, computers, tablets, and consoles. The barrier to playing something on those platforms is essentially zero. Newer or more experimental platforms, VR and AR in particular, carry structural barriers that are not about the quality of the games but about the hardware, the setup requirements, the physical toll, and the affordability of the experience.
He described VR as persistently five years away and AR in games as even further out from mass adoption. His view is not that these platforms are bad but that developers who want to work in those spaces need to be motivated by a genuine belief in the platform itself, not just a desire to make a game. If the platform does not have the carrying capacity to sustain itself, there is no future for games built on it regardless of quality. Making a game that brings new people to VR is a different, harder, and more valuable goal than making the game you personally want to play in VR.
When to Seek a Publisher Versus Self-Publishing:
A question that came in during the live session asked when a small team or solo developer should seek a publisher versus self-publishing. Charlie gave a thoughtful answer that resisted a simple formula.
His starting point was that the right answer depends on what you have and what you understand about your market. Before you can make a meaningful decision about publishing, you need to be able to answer a set of questions honestly:
- Who are your market comparables and how many copies do those games sell?
- What is the realistic market size for your genre and audience?
- What is the typical time to market for games in your category?
- How often do comparable games update after launch and what does that require from the team?
- Do you have the ability to do user acquisition or run a soft launch in a small region to gather early feedback?
- What needs to be true visually or interactively for someone to understand your vision well enough to fund it?
For some games, a handful of strong screenshots and a clear comp set are enough to communicate the vision to a publisher. For others, especially puzzle games or experiences with mechanics that are hard to read in static images, a playable demo is not optional. A publisher considering funding a project needs to be able to understand and get excited about the vision, and whatever you show them needs to be enough for that to happen.
He also pointed to a growing trend in the indie space: building a compressed vertical slice or mock gameplay footage in a short window, then spending five to fifteen thousand dollars marketing it through platforms like TikTok, YouTube Shorts, and jester.gg to test wishlist response before committing to full production. This approach treats early marketing as product research rather than promotion, giving developers real market signal before they have invested years of work.
His core recommendation regardless of which path a developer chooses: talk to people who do this for a living. Marketing firms, publishers, fellow developers, community members with relevant experience. Gather multiple perspectives, ask specific questions, and make a judgment call based on actual information rather than assumption.
Having Realistic Expectations of the People Working With You:
One of the most human parts of the conversation was Charlie’s advice on working with collaborators, especially in early development when monetary compensation is not yet in the picture.
His central point is that every person working on a project has a life outside of it with real needs, real constraints, and real circumstances that change over time. A developer who recruits collaborators without thinking carefully about what those people actually need to sustain their involvement will eventually find themselves abandoned, and the departure will feel sudden even though the conditions that caused it were visible the whole time.
Specific guidance he shared:
- Do not try to recruit someone who tells you they need health benefits and stable income if you cannot provide those things. They may get excited in the short term, but they will leave the moment a paying opportunity appears.
- Check in regularly with anyone working without monetary compensation. Ask how they are doing, whether their availability has changed, and whether the project is still a realistic fit for them.
- Be genuinely grateful for the time people give you. Someone helping out of belief in the project is offering something that is not contractually obligated, and treating it as though it is will erode the relationship.
- When something goes wrong or someone leaves, examine whether your expectations were realistic before concluding that the other person failed.
He reflected on his own early career tendencies: high expectations of the people around him, frustration when those expectations were not met, and a slow realization that not everyone had the same skill breadth he had built up and that expecting them to perform as though they did was not fair. His approach now is to identify what a person does well, support them through their weaknesses, and look for opportunities to help them grow rather than measuring them against a fixed standard.
The Advice Charlie Wishes He Had Received at the Start:
Asked what he would tell his earlier self about the game development journey, Charlie returned to the theme of understanding where other people actually are rather than measuring them against your own expectations or experience.
Everyone in game development is trying hard. Sometimes that is not enough, and that is okay. Sometimes it is exactly enough, and you need to be grateful for it. Sometimes it exceeds what you expected, and you need to temper your assumptions accordingly.
His closing advice for anyone starting out or considering making the leap:
- Reach out to people. Reach out to fellow developers, community members, people whose work you admire. Ask questions and actually listen to the answers.
- Be excited about other people’s ideas, not just your own. The developers who get the most out of early-stage communities are the ones who show up to help, not just to recruit.
- Give more than you receive. When working with collaborators, aim to give them the better end of the deal. The relationships you build that way are the ones that actually hold together under pressure.
- Know what you know and know what you do not know. Being honest about your gaps is not a weakness. It is what lets you fill them.
- Support people through their struggles rather than around them. The most important thing in collaborative work is taking care of each other as people first.
Want more insights like this?:
Join us for our IndieGameBusiness Sessions, taking place on September 30th from 9am – 5pm Eastern or hop into the IndieGameBusiness® Discord to connect with Charlie and other industry pros.
The IndieGameBusiness® podcast drops new episodes regularly, covering the business side of making and selling games. Subscribe to the newsletter to get episodes, Discord events, and industry news straight to your inbox. Subscribe now
