Hi everyone, and welcome to the fourth and final part of Sebastian’s fantastic content series on Game Dev Assembly. 🎮

We’ve taken a game from its earliest idea, through pre-production, production and closing. Now comes getting it into players’ hands. But as Sebastian explains, hitting that launch button isn’t the finish line. It’s the start of a whole new chapter. From certification and day-one patches to those crucial first 72 hours, player feedback and whether to keep investing in your game, there’s still plenty to navigate. In this finale, Sebastian gives us a practical blueprint for launch and post-launch. One last phase. One last big decision. Let’s bring this series home! 🚀

Launching isn’t really a phase. I think of it more as a checklist you work through, and it leads into what’s hopefully the longest stretch of your game: post-launch.

In the previous articles, I talked about how people sometimes misunderstand what some of the phases are actually about and how to deal with those problems. Launch and post-launch are different. From the moment you have your gold master, the work gets a lot more predictable. It’s a rather formulaic series of steps that mostly need to happen in order, plus a few concrete decisions about what kind of post-launch you’re looking at and how to manage it.

My goal here is to give you a high-level but concrete blueprint that you can follow, with the understanding that context matters and you’ll need to adjust, and that you can reuse on future launches.

Table of Contents

1. Launch

   1. Before Submission

   2. Certification

   3. Getting Ready for Launch

   4. Launching

2. Post-Launch

   1. The Kassadin Lesson

   2. To Keep Developing… Or Not?

   3. Wrapping Up the Project

3. Seven Phases with One Shared Idea

4. Closing My Content Series

5. Bonus: Get Access to the Game-Dev Cheat Sheet

Launch

Before Submission

Right out of the gate, you need to nail down a potential release date. You do this in the late production stage, ideally by reverse-engineering the date, the same way you did to figure out when to start closing. Say you want to launch a week before Thanksgiving in late November, then platform submission needs to happen about a month before that, and gold master should be ready a good two weeks before submission. Add slack for one failed certification round (failing the first one is very common, especially for first-timers. I touch on this in the following section). Do this math early and you’ll know if the date is realistic while you can still change course.

Also take a look at the calendar around your date. Sale weeks and Steam Next Fest weeks are packed with free stuff competing for players’ time. If an 800-pound gorilla is launching near your release window, that’s worth a conversation about moving the date. There’s never a perfect week or perfect release window. Just try to keep your ear to the ground, especially around direct competitor launches, and use stuff like the release calendar on steamdb.info to stay current.

In addition to having clarity around your potential release date, you need to consider your multi-platform staging. Larian shipped Baldur’s Gate 3 in multiple steps across 2023, based on when they thought each platform was ready: PC on August 3, moved up from August 31, then PS5 on September 6 once they hit 60 fps, then Xbox in December after sorting out split-screen on Series S. Their publishing director, Michael Douse, said releasing a finished PC build later just didn’t feel right. So they didn’t wait. The point is that you don’t force a perfect simultaneous release across platforms. But plan the staging deliberately, with a clear read on when each platform build is actually ready and what the commercial trade-offs are for each date.

Next up is getting your age rating certificates from boards like ESRB, PEGI, and USK. Most platforms require this before you can submit for certification, so tackle it first. Whether you’re purely digital or have a physical component, budget between two and six weeks per board per attempt. The process is simple, you fill out a questionnaire and provide a video of the game. Boards rarely reject classification, but they might put you in a higher age bracket than you wanted. If you think you might want to resubmit after changing the game to fit a different bracket, factor that into your timeline.

If you licensed music, a brand or someone else’s IP, a third party probably still needs to sign off on your gold master. Budget two to four weeks for this, depending on the relationship, the IP’s sensibilities, and how many licensors you’re wrangling with. Some licensors may also want to know your age rating, so the waterfall can get tricky.

Certification

Run a pre-cert yourself. Microsoft is the only platform holder I know of that publishes actual certification data, and on their list of top failing test cases, the number one reason for failure is stability: crashes and hangs make up 38% of failures. Title integrity is 14%, and account privileges is 11%. This is the low-hanging fruit. If you went through a proper closing phase, you’ve already worked on stability. So add one more pass against the top failing requirements and make sure nothing flagrant is slipping through because nobody tested for it.

Submit to certification. Sony calls their requirements TRCs, Microsoft calls them XRs (used to be TCRs) and Nintendo’s is LotCheck. Each process runs your build against several hundred test cases: crashes, save handling, achievements, store assets, privacy, controller conventions, and a long list of expectations they make very clear. You should have a checklist for all of them.

Games fail cert all the time. First-time submissions, new teams, experienced teams on a new platform, experienced teams shipping in a new genre. Plan for two, maybe three submissions.

Book the day-one patch slot. By launch, it’s been weeks or months since the build passed cert — valuable time to keep fixing bugs and prep a day-one patch. On Steam, you can push updates whenever. On consoles, a patch needs a mini-cert process where it’s tested to make sure the game isn’t fundamentally changed. Book your day-one patch a good one to one and a half months ahead.

Set up the storefront. This includes pages, pricing, localized copy, and preloads if your game is big enough to need them. On Steam, the page has to be public for at least two weeks before release, store review takes about a week, and Valve recommends submitting at least a week out in case they ask for changes. Console platforms need another 5 to 10 days. One thing to watch: the launch discount is probably the one piece you can’t fix retroactively. It can only be set before release, caps at 40% for 7 to 14 days, and starts a 30-day cooldown before you can discount again. Get that number right.

Send review and creator codes. Platforms generate promo codes only after the build passes cert, so press access depends on cert. Codes should go out one to two weeks before the embargo, longer if it’s a big or popular game. If you fail cert, the reviews you were counting on at launch won’t be there. The marketing implications speak for themselves.

Getting Ready for Launch

Understand and communicate known issues. Between gold master and successful cert, you keep fixing bugs and prepping the day-one patch, but whoever buys your game might not actually get that patch, especially with physical copies. So you need a list of known issues to share with players, including notes, workarounds where possible, and which issues the day-one patch fixes. Being upfront about this builds trust, funnels people toward the patch, and spares you some brutal reviews.

Create a launch week RACI. Launch week comes with responsibilities that are totally different from development. Capture in something like a RACI chart who handles what in those critical days after going live. This depends on your context, but here are common examples:

• Reading store reviews and community channels on a fixed cadence

• Monitoring crash reports and major issues, logging them, triaging, prioritizing, deciding what needs a patch vs. a hotfix

• Reviewing the backlog of feedback and major issues and turning it into prioritized tasks. Usually the game director, EP, QA director and whoever runs live ops

• Fixing issues, testing fixes, merging, testing Main

• Managing community sentiment day-to-day, aligning on messaging, handling fallouts

On a small team, one person might do all of this, and that’s fine. A bigger team needs more structure. What can’t happen is leaving these unassigned because nobody thought about them in advance and nobody feels empowered to solve problems as they come up.

If your game is online, write a runbook ahead of time covering the few things most likely to break and the steps for each. The person who gets called at 3am shouldn’t have to figure everything out from scratch. And check in advance that whoever’s on call actually has the credentials and access they need. Finding out mid-incident that the only person awake can’t deploy fixes is not fun.

Plan backend capacity. When the embargo lifts, wishlist emails go out all at once. If that one streamer with a million followers randomly picks up your game, your servers could take a massive hit. If any part of your game touches a backend, load-test for a significant surge. If you’re lucky enough for that to happen, be ready to capitalize. I won’t go deep here, but check out my live operations primer if you want more.

To recap, you’re typically ready to launch when:

• You have your age rating certificate

• The build passed cert on every relevant platform

• The day-one patch is ready and the submission slot is booked

• Storefront pages are approved, priced and final, with the launch discount set

• Review and creator codes went out on schedule

• The known-issues list is public

• You have clear responsibilities assigned for week one

Launching

Launching the game is a bit different depending on the platform. For instance, Steam has a “Release App” that you need to manually press yourself. On Xbox it’s different, you publish the product to the RETAIL sandbox in Partner Center after cert, and it goes on sale on the date you configured under pricing and availability. And Sony has the process under NDA, but the partner portal is pretty similar to Xbox’s.

Post-Launch

Launch was just a milestone with activities attached. Post-launch is the actual final phase. The point is to get the game to its best state and listen to what players are telling you, which includes reacting to bugs, feedback, communicating on forums, being present while they play.

Across every Steam release in 2023, the median game earned about 2.64 times its first week’s revenue by the end of year one. Launch is your biggest moment, but a game’s tail can be long and keep earning while you patch and improve, potentially for a very long time.

The first 72 hours are inevitably going to be about hotfixing issues as fast as humanly possible, and with little regards for release standards. That’s fine for a little while, but sooner or later, deploying untested or poorly tested fixes is going to break something critical. So at some point in the first week, it’s important to go back to a proper patching process with a more rigorous deployment protocol.

Try to fix critical issues one at a time. If you pile unrelated small fixes into the same patch, every extra change risks breaking something new. And keep in mind that console patches have to go through their own cert process, so a fix that maybe takes an afternoon to get through on Steam can take a week or two on console player. That’s just how it is. Also, I want to poke you to prioritize your bug-fixing efforts around the first couple of hours of the game, which is a part of the game that all players will see and that might impact your refund rate.

The Kassadin Lesson

For about a year between seasons three and four of League of Legends, a champion named Kassadin was absurdly overpowered. His kit had a point-and-click silence, a big magic damage shield and Riftwalk, which is a short-cooldown blink that lets him cross the map almost at will. Once he hit level 16, he could blink into a fight, silence the mid laner, delete the carry and blink out before anyone reacted. The kit was downright toxic, no counterplay at all, and the community responded by refusing to play against him at all. At the peak, Kassadin was banned in 95.3% of solo queue drafts. That number is insane.

At first we tried piecemeal changes: less damage, shorter silence, slightly longer cooldowns, higher mana costs. Patch after patch, nothing worked. The problem was the design of the kit itself, no number tweak could change that. What finally worked was a full-blown rework: stripping the silence out and adding a ramping mana cost to Riftwalk so he couldn’t blink forever. Design changes in a competitive game are much harder than they seem, and honestly pretty scary with a 100M players judging those changes, but in the case Kassadin, it’s what was needed.

Most post-launch work is small, cheap and easy to reverse. A redesign is bigger and scarier than a nerf, but that’s the lesson: listen to players, be judicious, take a reductive approach first. Don’t be afraid to acknowledge systemic problems that need real work. It happens more than you’d think, and pretending otherwise leaves players feeling unheard.

To Keep Developing… Or Not?

After a month or two, you’ll have a decent picture of how the game is performing: reviews, sales, refund rate, wishlist conversion, community sentiment, completion rate vs. churn. If expansion was always the plan, that work has probably been happening in parallel. This is when you decide to keep going or not. And if you do, what the scope is and whether the bang for buck is there.

A few questions to ask:

• Do we have metrics showing decent traction after week one?

• Is player sentiment positive?

• Are players spending enough time, ideally finishing the game, or churning early?

• Are there specific things (fixes, features, content) that enough players are asking for?

If the answers are yes:

• Exactly how much work do we commit to? Bug fixes, minor improvements, small DLC, major DLC, ongoing expansion?

• What’s the ROI?

• What’s the opportunity cost of doing this vs. something else?

• What does this mean for the team, who stays, who moves to the next project, do we have the right capacity?

Depending on what you decide, then the next big determination is what a sensible release cadence looks like for the team. What happens a lot in the industry is that marketing drives the calendar and teams may or may not be able to deliver on that calendar. This is not a hard mistake to avoid. Work with the team to figure out what their throughput can really be and only commit publicly to credible objectives. It’s always better to under-promise and over-deliver.

Wrapping Up the Project

Archive the game. It’s bureaucratic, I know, but if the IP finds success later (sequel, licensing, port to a new platform) you’ll want a clean record of what you shipped. Final build, full source code, last bug report, cert and ratings paperwork, localized builds, contracts and approvals. Store it somewhere safe and retrievable in five to ten years.

Run a postmortem. Hopefully you do regular retrospectives. Even so, one big post-launch retrospective where the whole team looks at the full arc of the project, finds things to celebrate, and figures out what to do differently next time.

Seven Phases with One Shared Idea

The reason I split game development into seven phases instead of the traditional four is that each phase has one job and one decision attached to it. When you bundle phases together, those decisions get muddy.

That’s the core argument across these four articles. Brainstorming decides which idea to pursue. Prototyping tells you if the idea is worth more work. Concept bolstering gets the team aligned. Pre-production lays the foundation. Production builds it, closing finishes it, and those two need completely different mindsets. Then comes the launch milestone and post-launch phase, mostly a sequence to work through, until you reach the support decision, the last big call you’ll make on your game.

What holds it all together is that in every phase, someone needs to make sure everyone understands what they’re doing and why. Make those calls deliberately, and you’ll spare yourself that nightmare of realizing midway through production that half the team is making one game and the other half is making another. I’ve been there. Hope this helps you skip it.

Closing My Content Series

That’s a wrap, folks. I hope you enjoyed the four parts containing the seven phases of game development. I will check in every now and then to update things if, and when, new information comes by, but I hope you have found it to be beneficial and will try out some suggestions in your current projects, or new ones you’ll be working on next! I also have a quick nugget for all of our readers - I created a phase-by-phase cheat sheet covering the objectives, activities, every deliverable, key roles, green light criteria, and pitfalls for each phase, plus my idea-assessment rubric for the brainstorming phase. I think this can double as a practical tool that you can take straight into your own projects.

Get Access to the Game-Dev Cheat Sheet:

Game Development Phases Worksheet

If you enjoyed Sebastian’s amazing content series on the phases of game development, or you’re a massive Assassin’s Creed fan, don’t forget to save your seat on September 21st, as historical consultant Glaire Anderson has a live interview with us and answers all of your questions on how she helped design the world in Assassin’s Creed: Mirage. Beyond being technical, getting in touch with culture, heritage, history, and civilizations is part of world-building in games.

RESERVE YOUR SPOT

Hello everyone! One of the greatest privileges of Game Dev Assembly is hearing from developers, like yourself, at every part of their journey. Each come with unique challenges, yet many feel that they don’t know what to learn next, or being overwhelmed by information online. This is why we're introducing a Developer Learning Paths series where we curate books around a specific goal, explaining not just what to read, but why each resource earns its place in the journey.

Our first learning path edition is on building and publishing your first Steam game. We hope these recommendations help you navigate the road ahead with a sprinkle of clarity and a whole load of inspiration. Let’s go 🚀

Stage One - Build Your Foundations

Before you think about publishing, marketing, or trailers, you need the skills to actually build a game. This stage focuses on learning your engine, creating assets, and understanding how everything fits together.

Blender for Beginners Part 1

Why read it? You will learn the fundamentals of modelling, texturing and navigating Blender so you can create your own game-ready assets instead of relying solely on placeholders.

Learning C# by Developing Games with Unity 6

Why read it? If you’re using Unity, this is an excellent introduction to scripting gameplay systems and understanding how code brings your ideas to life.

3D Game Development with Blender 5 and Unity 6

Why read it? This bridges the gap between asset creation and implementation, showing how Blender and Unity work together in a real production workflow.

Stage Two - Design Something Players Enjoy

As you’ve read in our previous industry signals, games are remembered because they’re fun. This stage is about designing engaging worlds, mechanics and player experiences.

3D Environment Design with Blender 5

Why read it? Learn how to build believable environments that guide players naturally while creating worlds that feel cohesive and immersive.

Building Open World Landscapes with Unreal Engine 5

Why read it? Even if you’re not building an open-world game, the principles of level layout, environmental storytelling and world construction are invaluable.

Godot 4 Best Practices (or Unreal Engine 5 Best Practices if that’s your engine)

Why read it? Good game design also depends on good project architecture. Learn how to structure systems that remain manageable as your game grows.

Stage 3 - Polish Your Game

The difference between a prototype and a game people remember is polish. Visual effects, shaders, lighting, optimisation and audio all contribute to the final experience.

Unity 6 Shaders and Effects Cookbook

Why read it? Create more visually striking games with shaders, lighting techniques and effects that elevate your game’s presentation.

VFX Made Easy with Houdini

Why read it? Master procedural visual effects, simulations and cinematic effects that can dramatically improve production quality.

Audio Mixing Cookbook

Why read it? Great sound design often goes unnoticed, but poor audio never does. Learn how to create cleaner, more immersive mixes.

Stage 4 - Prepare for Launch

Shipping isn’t just pressing the Publish button, but making sure your project is stable, maintainable and ready for players.

Unreal Engine 5 Best Practices (or Godot 4 Best Practices for Godot developers)

Why read it? Before launch, your project needs to be organised, optimized and maintainable. These best practices help you avoid technical debt and improve long-term stability.

Practical C++ Game Programming with Data Structures and Algorithms

Why read it? For developers building more complex systems, understanding efficient data structures and algorithms can improve performance and scalability.

Continue Your Journey

There isn’t a single correct path into game development, and every developer’s journey looks different. But if your goal is to ship your first game, this sequence gives you a structured roadmap instead of jumping between random tutorials and YouTube videos.

Explore the full Game Dev Assembly library and build the learning path that fits your own goals. And what’s exciting is every book in our library is currently 30% off, so there's never been a better time to start your next learning journey.

We hope you’ve found this edition helpful, and if you have any questions or want to share what your game development journey is like so far, feel free to drop a comment or message us directly. We’re always willing to listen. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

Just when you thought it couldn’t get any more exciting, we’re bringing one of the historical consultants behind 𝗔𝘀𝘀𝗮𝘀𝘀𝗶𝗻’𝘀 𝗖𝗿𝗲𝗲𝗱: 𝗠𝗶𝗿𝗮𝗴𝗲 to you on 21st September! If you’d like to join us for a 𝗙𝗥𝗘𝗘 online event and ask Dr. Glaire Anderson questions around building authentic game worlds, then register your interest and we shall look forward to meeting you on the day.

Hello everyone! 👋🎮 Welcome back to Game Dev Assembly. So far, Sebastian has shown us how to choose the right game to build and how to prepare a team to build it. Now comes the stage of actually making it. In Part 3 of The Seven Phases of Game Development, we step into production, where ideas become playable experiences and every decision starts carrying real weight. Sebastian shines a light on the idea that building a game and finishing a game require two completely different mindsets. To find out what they are, along with lessons from projects including BattleForge and Once Upon a Puppet, let’s dive right in 🚀

Pre-production ends with the team knowing how it's going to build the game, and production is where they finally get to build it. It's the longest and most expensive phase by a wide margin, rarely under twelve to eighteen months for anything that isn't mobile, and often three, four or more years for a bigger game.

In production you have two very distinct jobs. The first one is to build the game. The second one is to close it, which is the separate work of taking a game that already functions and getting it into a state that is legitimately ready for shipping. Across the industry, it’s very common to see teams bundle these two phases together, and that bundling comes with a price, because closing demands a completely different mindset than building. If the team doesn’t deliberately make the mental switch, they will most likely find themselves doing both jobs at once, and shooting themselves in the foot. They’ll inadvertently try to wrap up when in reality they should continue to explore creative ideas, and they’ll also keep exploring, iterating and adding to the game when in reality they should very much be closing the creative floodgates, focusing on polishing and fixing things.

In my opinion, that lack of clarity around which job you should actually be doing is one of the most common and least discussed causes of blown dates, worn-down people, and soured relationships with partners. So I treat building and closing as two very different and completely separate phases.

First, building.

Table of Contents

1. What Production Actually Is

   1. What You Do In Production

      1. Develop in Increments

      2. Test As You Go

      3. Check In and Sign Off

      4. Playtest With People Who Will Be Candid

      5. Review and Adjust the Plan

      6. Manage Risk As You Go

      7. Build the Community While Building the Game

2. What Closing Is

   1. What You Do In Closing

      1. Decide to Close and Cut to Must-haves

      2. Lock Features and Content

      3. Determine Gate Responsibilities

      4. Begin Stabilization

      5. Produce RCs Until One of Them Hits Gold

      6. How This Went at Flatter Than Earth

3. Two Jobs, Two Mindsets

What Production Actually Is

Up to now, the team has been in an exploration mode of sorts, arguing about what the game is and, with a little luck, proving it can be made. In production that argument is mostly settled and the work becomes building. Designers block out levels and flesh out mechanics, artists author assets, programmers write systems and game logic, narrative designers write the story and the key beats, audio designers build the soundscape, and on it goes. Whoever runs it spends their days keeping the work flowing, clearing roadblocks, and steering with good information.

The mistake I made early in my career, which I think many teams still make nowadays, is treating production as pure, 100% execution, as if the game were fully specified and all that’s left is to crank it out according to what the backlog says. Unfortunately though, that’s not how game development works. What you’re developing is engagement, fun, awe, and those are things you just can’t specify upfront. At least not enough. You can describe them, mood-board them, you can write thirty pages about the game, approximate mechanics and their intended impact on the player, but you still won’t know if the features you’re planning on building are any good until someone actually plays the game.

Game development is an ongoing act of creative exploration. Discovery through making is the work itself. So production is execution that keeps discovering, and almost everything about how you structure development comes from balancing those two things at once, building fast and at volume while staying vigilant about what the work in progress is telling you. Here’s another way of thinking about it: if you develop exactly the game described in that old game design document that you wrote before authoring a line of code, odds are the game won’t be particularly good. On the other hand, if you have no discipline and no direction, you’re going to explore creative ideas in perpetuity and you’re really going to struggle to ever ship the game. You need to internalize that those two forces are pulling in different directions in order to find the right balance between creativity and production efficiency.

What You Do In Production

Production is an ongoing series of activities. Five of them are a loop you run over and over, roughly once per increment. You build something, you test it, you get it checked in and signed off against clear conditions of “done”, you put it in front of players, then you take a look at the results and the feedback, and you adjust before building again. Two other activities run continuously underneath, from the first week of production, all the way to the last: managing risk and building your community.

1. Develop in Increments

The old-school way to structure production is around two major milestones: Alpha then Beta. Alpha meaning feature complete, every system and every feature is functioning, and the game is playable start to finish with mostly placeholder or very early-stage art and audio. Beta means content complete, all the assets in. From there to gold master, it’s polishing and bug-fixing. The logic, in theory, is that you prove the systems first and scale up all the content authoring once you’ve shown that they work.

That’s the model I inherited and that I used to structure production in my first couple of projects. The problem with that approach is that when you build a feature without its corresponding art, audio and narrative, it just plays differently once that context is integrated in the build. So a mechanic that feels fine in a gray box or with stand-in assets can easily turn out to need massive rework, or not work out at all. If you build a year’s worth of systems that way, you only find out if there’s something wrong at the eleventh hour, which is when it’s most expensive to fix. That’s completely antithetical to how we need to work to validate creative assumptions and minimize risk and rework.

So instead, I favor building the game as a series of small but fairly complete increments. Richard Lemarchand, a lead designer on the Uncharted games, calls this concentric development. Basically, what you do is build from the center outward. You take the one or two most fundamental features, the primary mechanics, and you bring just those to shippable quality first. For instance, for an adventure game with a central player character, that’s usually the character, the camera, and the movement controls. Not slapped together the way you would in a prototype, but with real art, animation, audio and feel, iterated until that small core is reasonably good. Only then do you build the next ring out, the secondary mechanics, and finish those before moving to the next. In this case, that could be the character’s climbing abilities, the items that the character can use, the dialog deliver system for the character, etc.

An increment in practice is a cross-functional slice, meaning a defined set of features plus the content that belongs with them, developed by a small team across design, art, engineering, audio, etc., and brought to that bar together. The slice comes together roughly at once, collaboratively, instead of each discipline working alone and hoping it all somehow fits well together at the end. And shippable quality doesn’t mean a hundred percent, by the way. Seventy or eighty is usually enough to see a feature come together as a whole. And since the last twenty percent of the work tends to take eighty percent of the effort, you get to play the thing early for a fraction of the cost.

The first increment is fundamentally your minimum viable product, the must-have systems and content. Then you prioritize the next, and the next, each one producing a playable slice of the intended experience even if it's small and imperfect. This way the team knows what the game feels like at every step instead of guessing all the way to Beta, and you can put a work-in-progress game in front of playtesters early enough to still act on what they say. Plus, Early Access, whether or not that's a part of your plan, becomes a viable strategic option, which is nice.

2. Test As You Go

QA isn’t a phase you bolt on before launch, and it isn’t one person’s job. It’s a discipline the whole team practices from the first serious check-in. If you fix a rendering bug the day it’s written, it costs an hour of someone’s afternoon. Three months later, that same bug isn’t one bug anymore. A dozen things have been built on top of that bug, and now you’re potentially touching everything you built on top of it.

Several kinds of testing run in parallel here: functional, integration, regression and compliance against the console requirements. Performance testing belongs in that list too, and it has to happen on the hardware (or virtualized simulation) your players actually own, instead of on the powerful machines you typically develop with.

Underpinning all this is the release pipeline. A continuous-integration setup typically rebuilds on every commit and runs a few smoke tests, like whether or not the game launches and clears the first level without falling over. That catches the worst hard-stoppers within minutes instead of at the next milestone review.

3. Check In and Sign Off

Work is really, truly only done when it’s integrated into the build, tested in context, major bugs addressed, optimized against its memory and performance budgets, and signed off by the corresponding lead or director. Merely checking in code or assets does not mean that the work is done.

When a team treats “checked in” as done, it’s inadvertently pushing that work into the closing phase. Every half-finished feature is essentially unscheduled work nobody is tracking, and it still has to be done at some point. If you spend a year developing like that, you may very well find that closing the game needs twice as long as planned, and when that happens, crunch and stress ensue, and the game quality takes a hit. That pile of not-quite-finished work is technical debt, and the most cost-effective time to deal with it is while you’re still on the task.

4. Playtest With People Who Will Be Candid

To some degree, we can say that internal QA can tell you if the game works. Playtesting, on the other hand, tells if the game “works for the player”. As soon as you have a work-in-progress build of the game, put it in front of people who are not in the dev team and take note of what they do, what they say, and how they say it. Do they lean in, lose track of time, start suggesting things unprompted? Or are they being politely patient with something that just isn’t working? Behavior can tell you a lot that you just can’t get from a survey.

I encourage you to start earlier than feels comfortable. The temptation here is perhaps to wait until the game looks and plays better, but by the time that happens, you may have already spent a lot of time, effort, and money on something that clearly was never going to work. A rough slice of the game, tested at seventy percent today, enables you to effect change fast and more affordably than having to rework an entire set of systems and features.

5. Review and Adjust the Plan

After developing and standing up a certain amount of work, you get feedback from sprint reviews, milestone reviews, and playtests. The work then is twofold:

1. Determine if your plan is still on track.

2. Determine what to do next, based on the latest feedback and information you gathered.

To understand if you’re on track or not, compare what has actually been completed against what the plan expected to be completed by that point. You do that by looking at your velocity, which is essentially how fast the workload in the backlog is dropping, how much work is left and how much time is left, which is most likely informed by your budget. If you have 100 points worth of work left, 10 months left of runway, and your velocity is 5 points per month, even though you assumed it was going to be 10 points per month, then you’re only going to be able to complete half of the remaining work.

This simple math precedes any decisions you make next, but you do need to figure out why you’re not making progress the way you thought you were. This is where you do some root-cause analysis and try to understand if the estimates weren’t right, if you’re at the mercy of some scope creep, if you’re taking too long to iterate, if your design assumptions are just not being validated, or something else. It could be a million things, so the work is getting to the bottom of it and making intelligent decisions contextually.

Then there’s determining exactly what work to do next. The reviews and the playtests tell you things. Sometimes it’s a failed creative assumption that requires going back to the drawing board, sometimes it’s a feature that works but still needs tinkering with, and sometimes it’s a new idea, a creative opportunity that no one considered, or a small feature that you didn’t think much of but that players absolutely love.

So the best you can do is test early, listen to players and make decisions fast. A mistake that I know has sunk entire projects is struggling to kill an idea that is just not working. The sunk cost fallacy can be incredibly strong if you’ve spent years of your life deeply invested in something. But also failing to capitalize on new creative possibilities and rigidly sticking to a plan can leave tons of creative value on the table, ultimately leading to a mediocre game. It’s a challenging balancing act.

You take those inputs judiciously, adjust the backlog against your velocity and runway, and make the best decisions you can with the information you have at your disposal. That said, I do want to poke you to cut early rather than late though, because if you wait until you’re out of runway, then it’s fundamentally game over. To this end, I typically try to empower the executive producer over the game director when these difficult calls are on the table, because making dispassionate, highly analytical decisions is part of the job and they suffer the creative loss less.

Battleforge is the calmest production I’ve been part of probably in my entire career, and this discipline of re-balancing the plan and being deliberate about production viability and creative exploration, is a big reason why. This was a real-time strategy game with a collectible-card component, and ideas poured in constantly from the creative leads: new features, new maps, and new ability synergies. The production director’s skill was to constantly triage all that, collaborating with the game director and separating the ideas that deepened the game from the ones that were really a second game trying to be born, and he held that line without ever making the team feel unwelcome to bring the next idea. Very little crunch, scope that scaled at a sane pace, partners delivering roughly on time, and a deadline that held.

With the plan adjusted and the priorities re-set, you go back to the top and build the next increment. That's the loop that you go through dozens of times until the game is done.

6. Manage Risk As You Go

Risk is the first of the two activities that are ongoing, that never stop. In my opinion, the projects that get hurt the most are usually the ones in which the team keeps their risks in their heads instead of on a lightweight risk register that exposes possible issues clearly and promptly. It doesn’t have to be a bureaucratic endeavor, just five to ten of them will do: a description, likelihood, impact, possible mitigation, an owner, and a follow up date. That’s it.

I care much more about the conversation that produces the register than about the register itself. I’m talking about the meeting in which someone finally dares to say that funding is running dangerously low, or that the core loop is still not fun, while there’s still time to do something about it. These regular chats around risk force you to confront reality with candor and humility, and that’s where the value truly is.

7. Build the Community While Building the Game

Community is the second ongoing activity in production, at least for indie and AA games, and teams treat it as a launch task when it’s really a production task to be started early on, usually twelve to eighteen months out, or as soon as you’ve got something that communicates how the game plays and feels. It’s also not really optional if you’re raising money, because a live community answers the traction question better than any pitch slide about market size. It just maximizes your chances with publishers and investors, and it strengthens your negotiating position.

People follow games in development because they want to be part of something while it’s still being created. So I strongly encourage you to share the process, and not just the wins. Show them the prototype that didn’t work, the concept that took eleven passes, that one feature you were sure about early but eventually relented and killed. And when you change something based on player feedback, tell them you did that. I’ve seen that to have built trust and community faster than anything else, probably because it proves their opinion has legitimate value and can inform the outcome of the game. Just don’t go dark when things get hard. That’s exactly when teams do that, and exactly when the audience is paying closest attention. Even a two-line "we're deep in the final push, sorry about the radio silence, more soon" keeps the silence from being perceived as abandonment.

What Closing Is

“It works and it’s fun” and “it’s shippable” are two potentially different things. At some point the loop stops. The last feature is in, the last bit of content is authored, and the work changes character completely. This is closing, sometimes called “finaling”, and it takes the game from functionally complete all the way to a gold master a platform will accept.

Teams struggle with closing because they have to switch gears completely, and more or less overnight. All through production the team has been in creation mode, exploring, iterating, saying yes, building new things, exactly as they should. Closing the game requires that the team pumps the brakes on all of that. No new features, no new content, no more creative exploration. From here the work is rigorously driven by checklists, bug trackers, certification requirements, and a fairly strict set of criteria that determine when the game is done. For people who got into this because they love building things, which is most developers, that’s a harder adjustment than it sounds. If the team doesn’t make the mental switch, they can inadvertently enter this weird, hazy loop of continuing to build while also trying to finish the game, taking one step forward and two steps back, blowing the deadline over and over again. All with the best intentions at heart.

It’s also the roughest stretch of the project, emotionally. The creative work is behind you, and you spend your days on stabilization, certification, and playing the same level for the fourth hundredth time hunting the one bug that crashes it on one console. If the team walks in already spent from a production that crunched, you’ve got very little left for the phase that demands the most patience.

What You Do In Closing

Unlike production, this one really is a sequence. You decide to close and cut to must-haves, you lock, you work out who is responsible for which gate, you stabilize, and then you produce release candidates until one of them is good enough to submit. Each step opens only when the one before is properly finished.

1. Decide to Close and Cut to Must-haves

You reach an understanding of when to start closing by working backward from the deadline. You start at your release date. On console, you need to budget for first-party certification, which can go from a couple of weeks to multiple weeks and rarely passes on the first submission, especially your first time. Before certification you need a gold master, before that, you go through a run of release candidates (RCs) that get progressively better, before that you go through a stabilization period in which you fix all lingering major and critical bugs, and before that, you go through feature and content lock phases. Each has a minimum length, depending on the type, scale and complexity of the game. If that math puts your start date behind you, take it as useful information, not as an annoyance: either the release date moves or the feature set shrinks. Both are legitimate choices.

Once you’ve determined that it’s time to start closing, you bring your core leadership together, the game director, the discipline leads and the executive producer, and you go through the backlog with one simple question: what’s required to finish this game, as opposed to what we would like to do to make this game optimal? Everything that isn’t a must-have goes on the chopping block. That’s a hard conversation for a game director who has nurtured the vision for three or four years, but if you don’t formally decide it’s time to wrap up, the team will understandably keep adding things in perpetuity.

Then you need to agree on how you’ll handle surprises, because there will be surprises. I mentioned this earlier: my take is that in closing, it is the executive producer who should hold the final call instead of the game director. I know that feels backwards. But the goal in this phase has changed. It’s to ship the game, and when shipping and making the best possible game pull against each other, the person accountable for the schedule and the budget is the right one to break the tie.

And then you tell the whole team, not just the leads. Explain what closing means, what changes about how decisions get made and why. Be honest and transparent. People take a cut feature far better when they know from the start it was a possibility.

2. Lock Features and Content

Feature and code lock comes first. That means no new features, no new systems, no major changes to what exists, bug fixes and deliberate certification work only. Then content lock: art, audio, writing. If the game is localized or voiced, a late line change can easily cascade through localization and recording pickups in the final weeks, so I strongly advise that you consider locking writing with feature lock or even earlier. After that, a short polish window for very minor improvements on existing content, and then you’re in stabilization.

3. Determine Gate Responsibilities

Something that I learned over the years is that closing needs a few roles that production doesn’t. Someone has to decide which builds qualify as release candidates, and to prioritize ruthlessly when two fixes compete for the same engineer. That’s usually the game director. The main branch gets locked down at this point too, with the technical director or a release manager approving every check-in and merge, one by one. And your QA lead should co-sign the candidates alongside the director, because a build shouldn’t really go to certification just because the game director likes it. They’re the ones playing it on every configuration all day. My advice is that you also try to tighten up the meeting cadence, with a weekly risk review and a bug triage that starts weekly and moves to daily as you stabilize further.

Closing also usually requires a smaller team than production, which tends to surprise teams. The impulse that at least I experienced in the past is to go “all-hands-on-deck”, but people who care and who have the best intentions end up finding work, which isn’t always the work on the critical path. So at this stage it’s also important to deliberately decide who’s on the closing team and where everyone else goes, whether that’s concept brainstorming on the next project, DLC, or some much needed time off.

4. Begin Stabilization

This is where most of the closing time actually goes, on bug fixing, performance and memory. I found it challenging but immensely useful to make check-ins atomic at this point: one ticket, one check-in, one build, approved before any potential merge into Main. A late check-in with three engineers’ unreviewed changes that interact badly can be just the thing that pushes an already tired team over the edge.

Oh, and keep QA analysts and playtesters on a short loop. A bug that looks trivial in the tracker can actually be disastrous when you see it in context, and vice versa. It’s incredibly hard to make good calls if you don’t have a good feel for what’s happening with the game, and no one knows better than them.

5. Produce RCs Until One of Them Hits Gold

As you go through stabilization, you evaluate release candidate builds against the gold master criteria. In theory, each candidate should be a cleaner, better, and more stable version than the last. If that’s not happening, then something structural is wrong, and it’s imperative that you look into it before it gets worse.

The criteria for gold master aren’t mysterious, in my opinion. The build needs to meet certification requirements on every target platform, run on the target hardware at the target frame rate, fit in memory without leaking, have no showstoppers and no unapproved major bugs, and play from start to finish without breaking. When a candidate clears all of that, that’s your gold master and you submit, expecting certification to bounce you at least once.

The criteria won’t tell you when the game is good enough, and that subjective call is part of the work of closing the game. Any game can be improved forever, so a qualitative call on whether the game delivers on its promise or not, needs to be made by the executive team. This is one of the things that I’ve found hardest about this stage. Teams that have spent years on a beautiful video game can find it really hard to stop, which isn’t weakness so much as what happens when people care, which is a fantastic problem to have. Your director wants one more pass on the opening level, which is what good directors do. Your artist has been staring at the same bad texture for eight months and would quite like to fix it before the world sees it. Neither of them is wrong. But the slow drip of one more pass is what keeps games from shipping, so you need to work as a team to hold the line and do what’s best for the project, not for a specific discipline or a moment in the game.

How This Went at Flatter Than Earth

Once Upon a Puppet is a project in which we went through all of this. The trigger was budget, which informed a clear must-meet release date. The team was making good progress in production, but the risk of overshooting our budget and deadline was real, so I worked with the team to move us all into closing mode in a very deliberate way. I set hard deadlines on the remaining milestones and treated the remaining time as fixed timeboxes, so whatever got done in the box is what shipped. We put hard feature and content locks in place, and reset the objective toward bugs, optimization, and launch prep, unless we badly missed a specific creative bar.

Our creative director was immensely passionate and creative, and kept pushing for improvements the whole way, and that push and pull was healthy, which is what the executive producer and game director relationship should look like within reason. He'd tell me a change would be great, and I'd tell him we didn't have the time. He'd tell me something wasn't meeting our quality bar, so we'd cut something else and buy the time to get it right. It only works when there's no concept of winning or losing in those exchanges, just thoughtful tradeoffs in the best interest of the game.

Two Jobs, Two Mindsets

So, in a nutshell, production is where a prepared team builds the game. Closing is where that same team, now tired and quite likely a bit worn out from the journey, has to finish it anyway. Most of what goes wrong here comes down to being in the wrong phase at the wrong time, or in both at the same time, so the switch demands a clear and deliberate decision.

If you do both with your eyes open, you come out with two things, not one. There’s the game, but there’s also a team that rode the whole thing with you and now knows it can do it again. Which is a more valuable outcome than we give credit for, because shipping isn’t the finish line most teams assume. Part 4 is the launch itself and the long life a game has once it’s in the hands of players.

Until Next Week…

We hope you enjoyed this issue as part of Sebastian’s fantastic content series. If there’s one lesson we’ve taken away from this issue, it’s that we should know when to stop building a game.

Sebastian reminds us that production and closing are two very different phases, each demanding a different mindset. Production is about creativity, experimentation, and discovering what makes the game great. Closing is about discipline, focus, and making the difficult decisions that get a game over the finish line. Trying to do both at the same time is where so many projects lose momentum, miss deadlines, and burn out their teams.

Next week, we’ll wrap up the series by exploring the final phase of the journey: Launch and Post-launch. We hope you’ll join us for the final chapter.

Warm regards,

The Game Dev Assembly Team

Hi everyone! 👋 Welcome to another edition of Industry Signals by Game Dev Assembly. For years we have treated being indie as the underdog where you had a small team, a limited budget, and a big idea, and the hope that players would eventually find it. That romanticized version of indie development still exists, but now the market has changed around it. Making a brilliant game is no longer the only job since developers are building audiences before launch, learning how Steam works, shaping recognizable studio identities and making decisions that could determine whether they survive beyond one release.

This week, we’re looking at four signals changing what it takes to build and sustain an indie studio. Let’s get straight into it. 🚀

Indie Studios Are Becoming Businesses Earlier

When we think of indie development, we imagine a small team shuts itself away, pours everything into the game and starts thinking about the commercial side when launch is close. That approach is becoming harder to survive.

Today, serious indie teams are thinking about the business much earlier. They’re asking who the game is for, how it will reach them, what it should cost and how long the studio can afford to build it. They’re managing wishlists, publishers, platform relationships, contractors, community spaces and launch campaigns, often while doing the actual development too.

It can feel like creativity is taking a backseat, but really, all this means protecting that creativity with better decisions.

Look at how studios such as Landfall have turned playful experiments and April Fools’ releases into part of a recognizable studio strategy. Its annual tradition has produced multiple games and strengthened the relationship between the studio and its audience.

Or consider Poncle, which grew out of the success of Vampire Survivors. Rather than immediately pouring everything into one enormous production, it has expanded through smaller teams, updates, collaborations, publishing activity and multiple projects. You can read more on how poncle is approaching its next stage of growth.

Even Balatro, which is often described as a solo-development success, has benefited from demos, player feedback, publishing support and a carefully managed launch. LocalThunk’s detailed development timeline shows that breakout success can look spontaneous from the outside while being built through years of iteration behind the scenes. You can read the complete Balatro development timeline.

The signal here is that being commercially aware doesn’t make your studio less independent, but gives it a better chance of staying independent.

Visibility Is Becoming More Valuable Than Another Feature

When a game isn’t gaining traction, the instinct is to keep adding another mechanic, another level, another character, and another few months of polish. But they mean very little if your players never reach the store page.

The uncomfortable reality is that a solid game with strong visibility can outperform a more ambitious game that launches quietly. That’s why indie teams are becoming much more deliberate about demos, festivals, creators, store-page presentation and wishlist growth.

Steam itself treats wishlists as more than a vanity metric. Players who wishlist a game can be notified when it launches or goes on sale, while developers can track additions, deletions and conversions through Steamworks. See how Steam’s wishlist reporting works.

A demo can now act as an entire marketing beat of its own. It gives creators something to stream, players something to discuss and developers an opportunity to learn which parts of the game are connecting. But simply entering Steam Next Fest is not a visibility strategy.

The teams that benefit most often arrive with momentum already behind them. They have tested the demo, gathered feedback and started building an audience before the festival begins. Read this practical guide to preparing a game before Steam Next Fest.

Recent benchmark analyses also show just how uneven festival results can be. Some games leave with significant wishlist growth, while many struggle to move beyond the lower rows of the event. Explore the Steam Next Fest wishlist benchmarks.

This is why marketing can’t begin two weeks before launch.

The hook of the game, the first seconds of the demo, the capsule art, the store-page language and the moments players want to share are all becoming part of development.

In a nutshell, another feature might by all means make the game better, but a stronger route to discovery might determine whether anyone gets to play it.

A Studio’s Personality Is Becoming Part of the Product

Players used to follow publishers, franchises and famous creative directors. Now, they’re following small studios and individual developers more and more each time.

They’re catching onto how a team speaks, what they sense of humor is like, and they enjoy following development stories, mistakes, experiments and strange internal jokes. By the time a game launches, the audience may already feel that it knows the people behind it.

Aggro Crab is a strong example. Its public voice is irreverent, self-aware and unmistakably its own. That personality shapes how players understand the games they produce.

Landfall has built something similar through its unusual prototypes, free releases and annual traditions. The studio’s experiments feel connected because the audience recognizes the thinking behind them. Read how Landfall approached discovery around its games.

But personality doesn’t require putting a developer’s face everywhere.

LocalThunk has remained anonymous while still building an identity that players recognize. The voice, design choices and openness about Balatro’s development have created a relationship with the audience without turning its creator into a traditional influencer. Read why Balatro’s creator chooses to remain anonymous.

That distinction matters. The lesson isn’t that every developer needs to become a content creator, but studios benefit when people can feel something consistent behind the work.

A clear personality helps players remember the studio between releases. It turns development updates into stories rather than announcements. Most importantly, it gives the next game a warmer starting point.

So the drive-home signal is that your studio doesn’t need the loudest voice. What it needs is to sound like nobody else.

The Goal Is Shifting From One Hit to a Sustainable Studio

The classic indie dream is built around the breakout game where a project takes of and changes everything, and gives the team the freedom to keep creating. But building an entire business around that possibility is risky.

For every visible breakout, there are many thoughtful, well-made games that never find enough players. Even when a hit arrives, sudden success can create new problems such as larger expectations, rapid hiring, expensive follow-ups and pressure to repeat something that may have depended on timing as much as planning.

So why not build a studio that can continue thriving and not just build a game that can succeed?

So you’d be choosing a smaller scope, maintaining a manageable team or reusing technology across projects. It could mean building a back catalogue, taking selective contract work or releasing smaller games between larger productions.

Grey Alien Games offers a useful counterpoint to the hit-driven story. In a GDC talk, developer Jake Birkett described sustaining the business over more than a decade through multiple releases, a back catalogue and the long-term sales of older games. Watch “The No Hit Wonder: 11 Years and Still Going.”

We’re also seeing successful studios resist the temptation to turn every win into one enormous bet. Poncle’s expansion is based around multiple smaller teams and projects rather than a traditional AAA structure. Aggro Crab has spoken about how rapid, lower-risk development changed the way it thinks about operating as a studio. Read how making PEAK influenced Aggro Crab’s production philosophy.

Sustainability rarely looks dramatic because it looks like controlled costs, reusable knowledge, a realistic production schedule, and an audience that carries over. A team that still wants to work together when the project ends.

That may not sound as exciting as betting everything on a breakout hit, but surviving long enough to make the next game could be the most important creative advantage of all.

Your Move This Week

As you think about your current or next project, ask yourself:

• Are we building an audience while we build the game?

• Can a new player understand the hook within seconds?

• What would make someone follow our studio after this release?

• Are we adding features because players need them, or because stopping feels uncomfortable?

• If this game performs well, are we prepared for what comes next?

• If it doesn’t, have we built anything that carries into the next project?

The indie scene may be more crowded than ever, but the teams breaking through are building smarter.

If you took a crack at answering these questions, let us know what you think! Drop us a comment or send us a message. We’d love to hear where you think game development is heading next. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

For our Godot people in the house, join us for a FREE live “Ask Me Anything” on 15th August 2026 with Robert Henning, who is a Godot educator, founder of GameDev Journey, and author of Godot 4 for Beginners and Godot 4 Best Practices.

This is for anyone learning, teaching, or building with Godot. Whether you’re just getting started, working on your first few projects, or looking to improve the way you structure and maintain your games, this sesh is a chance to ask questions directly to Robert. Sign Up Here.

Hello everyone! 👋🎮 And welcome back to Game Dev Assembly.

Part 2 of Sebastian Cardoso’s Seven Phases of Game Development series is here, and this time we’re tackling one of the most misunderstood stages of all: pre-production. Sebastian explains why this phase is about more than building a vertical slice. It’s where teams test their tools, pipelines, leadership, budgets, technical risks and production plans before the real scale-up begins.

It may not always look like progress, but this is the groundwork that can save a project from costly problems later. Let’s go in and get our creative juices flowing 🚀

After the three phases of concept discovery, the team comes out knowing what the game is and isn’t, as well as with a rough throwaway build that proved the idea is worth making. But none of that proves yet that the team can actually build the whole game, at scale and at the intended quality. And none of that is likely to have helped a great deal with any potential fundraising effort.

So pre-production is the phase in which the team gets ready to build and empower themselves to raise funds, if needed.

It’s also the phase studios get wrong the most. Many, if not most teams, think pre-production is about building a vertical slice. It’s not. While building a vertical slice is indeed something that you may want to do, to varying degrees depending on the needs of the game and the team, that’s not the goal of this phase at all. Instead, it’s preparation, meaning the not-so-glamorous work of building the scaffold that lets production be effective and efficient.

That misconception can be inordinately expensive. Preparation doesn’t necessarily feel like progress. Validating the toolset, designing and stress-testing pipelines, and getting the team behind the vision, are things that don’t immediately produce something exciting in-engine. And so they get cut short, or the focus shifts to whatever is more tangible and already plays. But that’s akin to setting sail on a boat that isn’t seaworthy yet, and then plugging holes in the hull to keep the water out while you’re in the middle of the ocean. Suffice to say, it’s not a recipe for success.

Table of Contents

1. The Purpose of Pre-production

   1. Prepare and Align

      1. Technical Setup

         1. Tech Stack

         2. Pipelines

         3. Technical Preparation

      2. Leadership, Culture and Team

      3. Documentation

      4. What Crysis 2 Taught Me About Pre-production

   2. Prove You Can Hit the Quality Bar

   3. Develop a First Playable or Demo

   4. The Exit Gate

   5. The Big Foundation

2. About the Author

The Purpose of Pre-production

Doug Pennant, in the excellent The Pocket Mentor for Game Production, frames the whole early lifecycle as a question-and-answer sequence. Concept discovery is where you find the questions. Pre-production is where you answer them. That’s the simplest way of putting it that I’ve seen in a while. The team naturally walks out of concept discovery with a pile of open questions about how the game should be built and how much it should cost. The main job of this phase is to answer enough of those questions that a full team can start work on with confidence.

I typically structure those questions as three goals:

1. Prepare and align. Build the solutions and tooling that enable production, and get the team to agree on and buy into the plan, the standards, and what the game is and isn’t. This is by far the bulk of the phase.

2. Prove you can hit the quality bar. Use a vertical slice, a narrow cross-section of the game built to final quality, to set the quality bar. Then answer critical benchmarking questions and, just as important, learn how fast the team can actually produce at that quality level.

3. Develop a first playable or demo. Start work on a first playable running on code that you mean to keep. If you need funding, turn that into a demo, which is a polished version good enough to convince a publisher or investor to pay for production. Most indie teams need this.

As a rough rule of thumb, not gospel, the time distribution should be roughly half on preparation and fifteen percent or so on the vertical slice, with the rest going to the demo, or to a first playable if you’re not fundraising. Those numbers can and do change with the game, team, and context. What seldom changes is the priority. A team that starts production with tested pipelines, written standards, known risks and alignment will out-produce a team with a beautiful slice and no foundation, every single time.

As for how long the phase should last, you’ll often see pre-production pegged at somewhere between ten and twenty-five percent of total development time, which I definitely find to be on the low end. A team working on a sequel, or on a relatively simple or small game with a well-understood production ahead of it, doesn’t need that much pre-production. An open world game, a very systems-heavy game, or one that requires a mountain of bespoke content is in serious trouble without a beefy pre-production. And if you need completely new tooling and pipelines for a AAA game on top of that, pre-production might need a good third of your development lifecycle.

Prepare and Align

As mentioned, this is the bulk of the phase. It has two parts: you build all the solutions that enable production to go well, and you get the team ready to leverage those solutions.

“Solutions” in this case is everything a team needs in place so that on day one of production they can simply work, and at a good clip. From a technical perspective, it’s chiefly the tools and the asset pipelines required to author content, features, and mechanics. From a human perspective, it’s aligning on values, intended behaviors, and being deliberate about leadership.

Also, there’s a stack of necessary documentation (that doesn’t need to be long, by the way) that sets standards and single sources of truth for each discipline: the art bible, the design and level design documents, the technical bible, the narrative and audio guides, the QA plan, the production methodologies, the marketing and community plan, etc.

And of course, the actual planning for production: how much work there is, how long it will take to complete, who you hire and when, how the team is chartered and led, what the roadmap looks like, outsourcers identified and tested on real work, and more.

Technical Setup

I’d argue that the technical setup represents the bulk of pre-production time. I think about it across three dimensions: the tech stack, the pipelines and the wider technical preparation.

Tech Stack

The tech stack is the engine and everything that plugs into it, and most of it you don’t build, you choose. Think of it as a pyramid: the lower the tier, the more a change of mind costs you later.

At the base is the engine, because every other choice inherits from it. Unreal, Unity, Godot or something else, the question isn’t which is best in the abstract, but which best suits your game, your competencies and your existing stack.

Then source control, decided by how much binary weight your game shoulders and how many people touch it at once. Git suits a code-heavy project with modest assets, Perforce is better if you’ve got large binary assets and many creators working at once. It’s as consequential a choice as the engine.

Above that is the content-authoring tools, where most of the team works: Blender, Substance Painter, Maya and the like, plus audio middleware like FMOD or Wwise once you’ve got adaptive music. This tier fragments across disciplines, so Stack Interface is a handy current catalog if you want the bigger picture.

Near the top is QA and profiling (Unreal Insights, Godot’s profiler), which follow from your engine, and the launch tools like Steamworks and analytics that you can leave until last. I urge you to stand profiling and memory management up early, although you can’t work towards a memory or performance budget that you can’t measure.

The overarching job in pre-production is to prove the toolset works together, and the lower the tier, the earlier you need that answer. Build your own tech only when it’s central to what makes your game yours, because rebuilding a solved problem is a ludicrously risky proposition.

Pipelines

A pipeline is the path one asset takes from a developer’s tool all the way to the running game. Take a 3D character, for instance. It starts life in a tool like Maya, from there it gets sculpted, unwrapped, baked, textured, rigged, animated, exported and imported, then given levels of detail and collision and profiled against a budget. Throughout this process, it changes hands between artists, technical artists, engineers and tools at nearly every step, and every hand-off is a place an export setting, a file convention or a memory budget can potentially fail. The studio Mighty Bear Games makes a good point when they say that creating the asset is only about forty percent of the work. Getting it correctly and repeatably into the game is the other sixty. That sixty percent is the pipeline.

Designing the pipeline means settling the dull specifics up front. A convention for file names, so an asset reads the same to every tool and every person, like type_description_v01. Versioned folders, so nobody overwrites the good copy. The branch an asset lives on and the review and merge cadence that pushes it forward, usually feature branches with review at check-in rather than a free-for-all merge at the end. And an automated check at each stage that catches a broken export before it reaches anyone downstream.

Teams tend to skip validating pipelines, which defeats much of the purpose of pre-production. You need to push one real, finished asset of each type the whole way through before ramping up for production. That’s where you fix everything that breaks, and then profile the result on your lower-spec target device, because that’s where the frame-rate and memory problems actually surface.

Technical Preparation

Technical preparation is how you intend to build. It’s the planning work, mostly decisions that are cost-effective to make now and miserable to reverse once a large team is committing code every day.

The architecture comes first: how the systems are structured, what talks to what, where the modular boundaries are. Bob Nystrom’s Game Programming Patterns has a useful test, which is how easily the structure absorbs change, since most of a long production’s cost goes on changing code you already wrote. So keep it flexible while you’re still finding the game, and optimize once you know what you’re optimizing for. In practice that means a feature-based project structure, where everything for the player, or the inventory, or one enemy lives together rather than scattered by file type. That makes a feature easy to find and easy to cut.

Then there’s the language and the coding standards that go with it. The standards don’t have to be exotic. The boring, proven ones do most of the work, SOLID, DRY, keep it simple, as long as the whole team signs up for the same set instead of each engineer bringing their own. Alongside that, the code review guidelines: who reviews what, when, what a reviewer is actually checking for, and how quickly a review has to come back. Review latency is one of those numbers nobody defines upfront but everybody ends up suffering dearly.

The performance and memory budgets belong here too. These are ceilings you commit to up front, taken off the weakest hardware you support and divided down to a number per scene and per subsystem that developers check against as they go. If you skip setting them, you can find yourself GPU-bound three weeks from launch, with nothing left but to rebuild entire scenes. I’ve been there and it’s not fun.

Then the mechanics of how work reaches the build. You want a branching strategy and release pipeline, or CI/CD, so code moves into a tested build without everyone stepping on each other, and automated testing so a build-breaking change gets caught at check-in, not a week later. Round it out with build data-mining for useful gameplay analytics, an in-game bug reporting tool and training for non-engineers, who are the real customers of all this technical preparation.

Leadership, Culture and Team

Two of the three most expensive things to get right in game development aren’t technical, but human. That is, how the team is led and the culture that team works in. Both get set very early in development, like in pre-production, whether you do it on purpose or leave it to chance, and both are far easier to build and get right now than to repair once a hundred people depend on them.

Let’s start with leadership. My definition is that leadership is the work of creating the conditions in which other people can do their best work and get results. That means clarity, shared direction, empowerment, encouragement, and constructive accountability. It also means enough safety that people tell each other the truth rather than merely stay diplomatic.

The reason to care about leadership now, in pre-production, is simple. Production is potentially a multi-year marathon, and the conditions that let a team do good work under that kind of sustained pressure seldom assemble themselves once the pressure is high. You either lay the foundation for a well-led production while things are still calm, or you find yourself scrambling, trying to embody a definition of good leadership that no one else agrees with five days before Gamescom, when things are very much on fire. So pre-production is the perfect time to decide, discuss, and socialize who leads, how they lead, what being well-led actually looks like for this particular team, and then you start practicing and embodying it before the stakes get high.

Culture is the other half, and pre-production is where you have a chance to build it deliberately instead of inheriting whatever forms by accident. At its core, culture is a set of shared values and behaviors the team actually agrees on and demonstrates day in and out. Teams that settle up front on what they stand for give themselves the best possible chances to stay coherent under pressure.

Team charters that capture what the team values, how decisions get made, how disagreements are handled, etc., can be a useful here, but culture is mostly lived, not written. So preparing to embody a good culture requires leaders modeling the values rather than writing about them, actively protecting candor so people keep raising problems, and holding a real standard of behavior instead of tolerating anything as long as results show up. All that is culture, and the fastest way to wreck it is to let your most productive person behave badly, because within a week the whole team understands that the values are optional.

When you get this foundation right, trust tends to deepen across the entire production. When you neglect it, you risk the opposite, which Patrick Lencioni mapped as the five dysfunctions of a team: an absence of trust kills honest debate, which hollows out real commitment, which removes accountability and sinks results.

Documentation

The last thing preparation produces is documentation, which has a bad rep because useless documentation is tragically far too common.

The purpose isn’t to write and own documents just for the sake of it. It’s to turn decisions into standards, so that questions get answered once instead of fifteen times by fifteen people who each answer differently. Each discipline ends up with its single source of truth: the art bible, the design and level design documents, the technical bible, the narrative and audio guides, the QA plan, the production methodology, the marketing and community plan.

Good documentation is short, specific, and used. The test isn’t length, but whether somebody can act on it and be empowered by it. An art bible that says “keep it stylized and consistent” is fluff. You need one that gives the export settings, file conventions, memory budget per asset type, reference images, authoring guidelines, and examples of what bad looks like. A good guide can mean the difference between an environment artist shipping something usable in their first month or having their work bounced back twice and starting to second-guess themselves. And these documents have to adapt as you develop the game and learn, so keep them dynamic and up to date. A level design bible six months out of date is worse than no bible at all, because people follow it only to get things wrong with confidence.

What Crysis 2 Taught Me About Pre-production

Crysis 2 is a useful example for me, because the team did really strong pre-production on most fronts but still got caught by the one area that, for various reasons, did not get the level of preparation that was needed.

This game was a sequel going from PC-only to PC and multiple consoles. This was a seasoned team and the references, benchmarks, guidelines, bibles, and asset pipelines were all solid. In some cases, truly exceptional. But the team was new to console, and the proprietary engine wasn’t console-ready at the time. So the team did the pre-production it could, especially given the time constraints, and moved into production. Some of that’s perfectly normal: you don’t remotely move every discipline into production on the same day. It’s not a switch that you flip for the studio. Some functions are ready before others, and starting the ready ones while the rest finish preparing is absolutely fine.

But the staggered start wasn’t the problem. The problem was that an entire platform’s worth of technical de-risking never happened at all. Console test pipelines, memory and performance budgets for console hardware, streaming from disc, a developer-friendly profiler, the certification requirements, all of it was skipped in pre-production and pushed into production, which is the most expensive place to learn all this. The game didn’t run on console at first. Scenes had to be extensively reworked because they’d been built to powerful PC specs rather than the tighter console limits. Planned feature work also had to be cut so the team could scramble to learn and accommodate console memory management, disc streaming, and certification in the middle of building the actual game.

Crysis 2 shipped, and shipped to critical and commercial success. None of this is about blame. A key part of preparation that happens in pre-production is de-risking the things that you don’t yet know how to do, and a whole new platform with a whole new architecture is just about as risky as it gets. In hindsight, it’s clear that was one of the highest-priority works of the phase, not something to find out about later. That was a really tough challenge and I’ve held on to this lesson the rest of my career.

Prove You Can Hit the Quality Bar

The vertical slice typically has two fairly specific jobs:

1. Prove and benchmark the quality bar.

2. Prove that the team can hit it at a credible pace they can keep.

It’s very much not one of each major thing in your game, whether that’s systems, features, mechanics or items of content. It’s primarily one of each major thing that you still have an open question about, like: can we make it look and play like that, or can we reach that quality in a reasonable timeframe? But plenty of things don’t need benchmarking at all: a team developing a comparable sequel on the same platform, at the same specs, already knows where the quality bar is for most of the game and has a clear reference for production velocity.

So what goes into the vertical slice is whatever you need to benchmark, what you want to measure production speed against, and/or what you want to de-risk by taking it all the way to final quality. Built that way, the vertical slice tests a subset of the production cycle once and pulls a lot of pipeline and process problems into the open before the full team is in place.

Geoff Ellenor, a creative director at People Can Fly, warns about exactly this. Don’t leave pre-production with a vertical slice “made with none of the tools and processes that you need for a successful production.” A vertical slice like that only proves your most senior people can handcraft one polished area, under unique non-production conditions, at a clip that may not be realistic for other developers in production. So when you work on the vertical slice, seek to test production processes, tools, and pipelines, do leverage your best developers to hit a high quality bar, but also try to have the actual developers who are going to have to replicate that output be a part of the vertical slice work, so that you can have a more realistic approximation of future velocity.

Finally, I’d be remiss not to mention that so much writing on pre-production treats the vertical slice as the deliverable of the phase, the thing it’s all building toward. And it’s not. It’s just one goal out of the three. Chasing a complete, glossy vertical slice that accounts for every system and feature is very much to the detriment of the infrastructure that the whole production depends on.

Develop a First Playable or Demo

By now you’re doing a lot at once, and in parallel, a build is starting to come together, because of course you need something playable as early as you can get it. And a fair question at this point is: what exactly are you supposed to be building in pre-production?

You have two clear options here: you can develop a standard first playable catered to your internal production needs, like building the game’s tech and systems foundation, addressing the biggest risks, doubling-down on a novel element of the game that needs to be validated, or you can focus your build on demonstrating as best as possible what the game is supposed to play, feel and look like, so that investors might fund the remainder of the project. These two options serve two very different goals.

Let me give you an example. Say you’re making something like Dave the Diver. You assess that scuba diving and catching different fish is the most technically complex challenge and the game’s main differentiator, especially the depth progression as you scuba farther and farther from the surface. So that’s what your first playable focuses on: it’s the biggest unknown and the thing you most want to de-risk. Internally that’s the right call.

But that first playable doesn’t show the loop yet, and a fundraising demo has to show the loop. For Dave the Diver, the loop is diving, catching a few fish, then coming back to the bar, selecting the night’s dishes, serving sushi, making some money, buying new gear and then using it to dive deeper or chase different fish next run. So in this case, you still work on the diving part, but perhaps just enough to showcase it and not much more, and then shift your effort to things like inventory management, customer behavior at the bar, basic item progression, authoring really nice assets for the bar, etc.

Both perfectly valid, both different goals. As a rule of thumb though, every game should get its core loop working and testable as early as possible, but the route to get there varies.

The Exit Gate

Pre-production is also the last practical moment to reasonably cancel a project before ramping up the team and committing the better part of the budget. So this green light is the last low-cost decision available to you.

You’re typically ready for production when:

• The tech stack is architectured, discussed and stress-tested.

• Every tool and guide is documented and signed off by the discipline directors.

• Every pipeline has been run end-to-end with a real asset.

• The vertical slice provides valuable quality benchmarks and an initial production velocity starting point.

• The memory and performance budgets are set against the target specs.

• The critical technical risks you found have been addressed or explicitly accepted.

• The team had valuable conversations and made agreements about leadership, values, and behaviors (ideally with ways to measure those in production).

• Outsourcers are identified, tested on real work, vetted and on-boarded.

• The development team for production is hired and on-boarded, or clearly penciled in to join on schedule.

• Working agreements and milestones with the publisher are in place, if you’ve got one.

• The funding to ship is secured.

The Big Foundation

Pre-production produces a team that walks into production already knowing how they’re going to build this game, so the only questions left are how fast, how well, and how adaptable they are as new creative opportunities and challenges arise, not whether it can be done at all. Every question you settle now, with a few people in a room, is a question you’re not settling later with a hundred people waiting on the answer while the burn rate is astronomical.

Skipping this phase doesn’t dodge the work, mind you, it only pushes it into production, where the unvalidated pipeline, the unset budget, and the leadership and culture you never established all get paid for at the highest price.

Production is next phase which we’ll walk through in Part 3. It’s the longest phase of the development process, and it’s also where a prepared team gets to find out how much all this invisible work was truly worth.

About the Author

Sebastian Cardoso is a COO and executive producer with 20 years in the games industry, including leadership roles at Riot Games, EA, and Crytek. He’s the founder of Game Studio Unlocked, a fractional consultancy that brings executive leadership to indie studios around the world. He also writes a newsletter on Substack on how to effectively lead and run game studios.

Until Next Week…

And that’s a wrap, folks! The message we’re driving home is skipping preparation does not remove the work. It only pushes it into production, where every mistake becomes harder and more expensive to fix.

From technical setup and team culture to pipelines, documentation and funding, pre-production is where a studio proves it’s truly ready to build the whole game.

In Part 3, Sebastian moves into Production, where the challenge shifts from preparing the team to building at scale, controlling scope and knowing when it’s finally time to stop creating and start shipping.

We hope you enjoyed this edition and we’d love to capture your thoughts and experiences, so feel free to like, comment, and share with your teammates or game dev friends.

Warm regards,

The Game Dev Assembly Team

Hi everyone, and welcome back to another edition of Game Dev Assembly’s Industry Signals 🎮 For the longest time, it felt like we had to keep doing things bigger, such as bigger studios or having bigger budgets. But the signals we’re seeing today tell a different story.

Players are paying more attention to who makes a game, not just what they’re making. They’re sticking around for worlds that grow over time, appreciating genuine craftsmanship, and backing studios they believe in. The next competitive advantage could be building something people genuinely care about and have a journey with in an evergreen way. Are you curious? Dive in and let’s find out 🌊🔍

Smaller Studios Are Becoming Premium Brands

We would like to think that the bigger something is, such a game studio, the bigger the product will become, such as a game. This meant having more employees, bigger budgets, and more snazzy and ambitious roadmaps.

But we’re starting to see another path emerge. Studios like Supergiant Games, LocalThunk (the creator of Balatro), and Mobius Digital have built something that’s arguably even more valuable than scale. They’ve built trust.

Players go beyond buying their latest game based on it looking interesting, where their decisions are also driven by their trust in the people making the game.

Take a look at the success of games like Hades, Balatro, and Outer Wilds. Each came from relatively small teams, yet each studio has built an identity that players actively follow.

Maybe the goal isn’t becoming the next Ubisoft anymore. You might want to first think about becoming the studio that players want to know and look forward to whenever game trailers come out.

In the future, your studio’s reputation could become just as valuable as the games themselves.

Games Are Becoming Smaller, But Living Longer

While smaller studios could become more valuable, smaller games could just as well.

We’re used to perceiving success as launching a game with as much content as possible. However, gradually, more studios are releasing games with a focused core experience, then expanding them over time through meaningful updates rather than trying to ship everything on day one.

Look at games like Schedule I, Abiotic Factor, and Core Keeper. Each launched with a clear vision, then kept players engaged by adding features based on community feedback rather than sticking rigidly to a fixed roadmap.

This reduces risk for developers while giving players a reason to keep coming back.

It also changes how we think about launching a game. We go from asking, “Is it finished?”, to asking, “Is it ready to start growing?”

In a nutshell, think of launch day as the beginning of the conversation with your players, not the end of development.

Human Craftsmanship Could Become a Selling Point

As most, if not all of us, are already aware, AI is becoming part of everyday development. It used to be the hype a couple of years ago, but is it the interesting story today? We don’t think so.

The more interesting question is whether players will begin placing greater value on the things they know were made by people.

We’ve already seen growing conversations around handcrafted animation, orchestral soundtracks, practical concept art, and real performance capture.

It’s similar to what happened in music and photography. As technology became more accessible, handcrafted work became something people won’t take for granted anymore, and they actively appreciated it.

Could games follow the same path?

One day, made by humans might become a feature worth talking about.

Developers Need To Build Worlds, Not Just Games

In one of our previous Industry Signals edition, we touched on how Hollywood is treating games as franchise infrastructure.

But what can game studios do to benefit from this knowledge? You could be spending less time thinking about a single release and more time thinking about the universe around it.

We’re seeing games expand into art books, animated series, tabletop games, novels, soundtracks, merchandise, and creator-made content. Even indie developers are beginning to think beyond one launch and ask how players can stay connected to the world they’ve created.

Take Deep Rock Galactic. It has grown beyond the original game with spin-offs, a board game, merchandise, and an incredibly active community. Cult of the Lamb has done something similar by extending its identity through comics, collaborations, and physical products.

So you have to think of a game not being the entire experience, because it’s becoming the entry point.

So think about how the strongest intellectual property of the future may not be the biggest game. It’s the world you create that players want to keep coming back to, regardless of the format.

What This All Adds Up To

These signals seem like they’re unrelated at the first instance, but they’re actually pointing towards the same idea. The future of game development requires you to be intentional where studios have to build stronger identities instead of just expanding.

Games are also becoming long-term experiences instead of one-time releases. Players want to see more of worlds, creators, and communities, and not just have products put in front of them.

Perhaps meaning and intention is where the industry is heading next.

Your Move This Week

Take five minutes to think about your own project.

Ask yourself:

• Would players recognize our studio for something beyond this game?

• What part of our game feels unmistakably human?

• Could players create stories around our game without us?

• Are we building a launch... or the beginning of a long-term journey?

• If our game became a world, what else could exist inside it?

Drop us a comment or send us a message. We’d love to hear where you think game development is heading next. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

Hello everyone! 👋🎮 Welcome back to Game Dev Assembly. We’ve been a lil’ quiet, but we were cooking up something for you. We’re excited to kick off a new four-part series with Sebastian Cardoso, COO, executive producer, and former leader at Riot Games, EA, and Crytek.

Across this series, Sebastian will introduce his Seven Phases of Game Development framework, a practical approach built from two decades of experience leading game teams. Each part explores a different stage of development, the mistakes teams commonly make, and the lessons that can help you build stronger games. In Part 1, we’re starting with Concept Discovery. Let’s jump in!

Most teams picture game development as a handful of big phases. You come up with the concept, get ready to build it, then you build and finish it. That's a fairly reasonable structure, and it's roughly the model I inherited early in my career. The problem is that this old picture glues several distinct phases into one, when each of those phases has its own job to do and its own decision to make. Bundle them together and those decisions are made vaguely, if at all. That's why I prefer to structure game development around seven phases rather than four.

For this article, let’s take the typical first phase in the lifecycle of a game production. Concept Discovery gets usually treated as one big block of work, when in reality, it’s three separate and different jobs. If you blur them, the team might just commit to building a game without ever thoroughly and deliberately checking if the idea is truly credible and a good fit. Which is arguably the most expensive mistake in game development, because you can lock yourself into potentially years of building the wrong thing.

The three phases have different and distinct objectives:

1. Brainstorming and feasibility: coming up with ideas and working out which ones are worth building.

2. Prototyping: making something rough and playable, to find out whether the best of those ideas actually, truly holds up when you play a bit of it.

3. Concept bolstering: turning the surviving idea into a well-articulated, socialized and agreed upon game concept, which is solid enough to build a plan and a budget around.

Pulling them apart and treating them as individual phases is well worth the organizational effort. These are the fastest and least costly phases in the entire production lifecycle of a game, and most of what they produce is meant to be thrown away. You’re not building the game just yet. You’re learning and trying to find out, as quickly and cheaply as possible, if this game idea is worth spending more time on.

If you approach all three of these phases as one larger, vague concept discovery phase, you run two risks. First is not being deliberate about the specific objective that each phase is really there to accomplish. In game development, clarity is priceless, so the more specific you can be, the better. And second is you lose something that the three phases afford you when approached one by one, which are three concrete, separate, and low-cost chances to catch a bad idea before realizing after two years of development that this game is going nowhere.

Let’s start with the first one.

Table of Contents

1. Brainstorming and Feasibility

2. Prototyping

3. Concept Bolstering

4. Small Phases, But Big Impact

5. About the Author

Brainstorming and Feasibility

This first phase does two things: it generates and shortlists ideas that the studio should actually prototype, and it says no to all other initial ideas. You want to settle on a strong idea, obviously, but it’s just as important to avoid committing to a weak one, and that second goal tends to be easily and quickly forgotten in the excitement of a good brainstorm.

Here’s how I run it, using a real example. At Flatter Than Earth (FTE), around the time we were finishing our previous game, we ran a studio-wide brainstorm. Before anyone pitched, I set a few constraints so people wouldn’t propose things we could never build, which would just be a waste of time and creativity. It had to be a PC or console game, buildable by a twenty to thirty-person team and not dependent on a mountain of bespoke content authoring. It also had to fit the studio’s highly creative and whimsical spirit, which ruled out things like racing games, shooters and military strategy. Everyone worked from the same short pitch template, so we could compare ideas on the same terms. Each pitch covered six things:

1. What the game is?

2. What makes it different?

3. What is the core loop?

4. Who it’s for?

5. Why we should make it?

6. What are the main risks?

Anyone could pitch, alone or in a small group. We gave it around forty-eight hours, and it was an energizing couple of days. Every pitch got a few minutes to present and a few minutes of Q&A, and then the studio voted. The vote didn’t exactly determine what idea to pursue, but it was very helpful in showing us where the interest was clustering.

Then the promising ideas went to a small group of us: the CEO, me as COO, the design director, the head of business development, and the art director. What we did then is we took each idea and ran it through a feasibility check across five areas:

• Market. Where the genre is in its lifecycle, how big the audience is, how games like this actually make money.

• Trends. Which platforms, technologies and business models are rising or fading, and whether there’s an undeserved group of players we are perhaps well-positioned to serve.

• Competition. How crowded the space is, who’s strong and why, and what nobody is doing well that potentially we could.

• Development. If it matches our skills and experience, if the scope is realistic, and if we’d be leaning on one irreplaceable person to pull it all off.

• The gut check. If the team is really excited, if it’s an ambitious but credible next step for the studio, and what trusted outside voices think of it.

For the scoring in that feasibility check, we used a simple rubric that rated each idea across those five areas (from 1 to 5), weighting the ones that mattered most more heavily (from 1 to 10). Neither the rubric nor the score made the decision for us, but it did two useful things. First, it forced a like-for-like comparison of our opinions, and second, it exposed the idea everyone loved but couldn’t quite defend when challenged. Those two things fostered valuable conversations that helped us better align with what we were seeing in each of the ideas.

Saying no to the rest is far and away the highest-return decision in all of game development, before anyone has spent major time, money, energy, talent or emotional investment. At FTE, I went back to each developer and then the whole studio afterward and walked through, idea by idea, why each one we passed on wasn’t the right call for us at the time. The reasons varied, from too big or too small, to too crowded a market, to off the studio’s spirit, to too heavy on systems. The team had a say in the process and understood the reasoning, which made the cuts far easier to accept than if they had been made cryptically and without context. Closing that loop and honoring the creative effort with clarity and transparency is important for the team to remain engaged and be able to buy into the chosen ideas.

Done well, this phase gives you a clear, defensible decision and a team that understands it and can buy into it, even the people whose idea didn’t ultimately come out on top.

Done badly, the team falls for an idea during the brainstorm and treats it as already decided. The feasibility check turns into theater, and the numbers get arranged to justify a choice that was really made on emotion days earlier. The team isn’t genuinely involved, have no way of understanding why certain decisions were made, and ultimately feel disenfranchised.

Finally, while I’m deliberately trying to be detailed with this explanation, this is a fairly short, simple and straightforward process. So be on the lookout for a common mistake, which is making this overly bureaucratic: too many sign-offs, a committee to satisfy, a formal pitch process before anyone is even allowed to build a prototype, etc. A heavier process absolutely doesn’t produce a better decision here. The forty-eight hours, fun pitchathon and the five-person review at FTE worked because they stayed fairly light.

You’re typically ready for the next phase when:

• The brainstorm produces an idea that is clear, with a legitimate differentiator, commercially viable, and an identifiable audience.

• The idea fits the studio’s vision, skills and finances.

• There are no major or obvious strategic problems left unaddressed.

• Leadership agrees on why this idea deserves the next round of investment.

• You could credibly raise money against it.

  ---

Prototyping

You now have one or two ideas out of the brainstorm that survived the feasibility check. You’re probably very excited about them and you’re ready to start developing the game. Don’t though. Take a beat, build a quick throwaway prototype first, and let it show you what a document cannot. This is the most efficient way possible for you to test if the idea actually works once you play it.

I like to give a small team of two, three or four people, depending on the game idea, one week to rapidly prototype one idea. It needs to run in-engine, any code generated is throwaway, and you leverage mostly blockouts and placeholder art. The prototype only exists to answer a few very specific questions (and depending on the game, some of these may be more important than others):

• Is the core loop engaging within the first few minutes and does it continue to engage afterward?

• Does the core differentiator accomplish the job of setting this game apart?

• Do the main mechanics and/or core features hold up under normal play, or do they fall apart?

• Are there obvious technical problems?

• Does this feel like something this team can realistically pull off?

Anything that can’t be answered in about a week or so, probably belongs to a later phase.

While the team prototypes, the leadership team continues the feasibility analysis. The prototype doesn’t replace the market, cost or funding thinking, but it informs it, and vice versa. By the time the prototype is playable, you want creative, technical and business considerations all visible at once, so the greenlight decision is clean.

When the week is up, everyone plays the prototype, hands on the controller or keyboard. What you do is watch how people behave when playing, not just what they say. Do they lean in without being asked? Do they lose track of time? Do they show spontaneous curiosity? Do they start suggesting improvements before anyone prompts them? Or is the team being a little mum and polite, and the body language just says “meh”? That tells you just as much if not more than a feedback form ever will. And that informs whether you’re good to move forward, or invest another week in the prototype, drop it, prototype another game idea or go back to the drawing board.

Let me give you an example. At Riot, we prototyped a lot of champions for League of Legends. One was Zed, a ninja assassin. On paper his combat kit looked great. As soon as the team prototyped it and played it in the game, it was clear it wasn’t quite delivering on the fantasy and the abilities were not synergizing as expected. None of that showed up on paper, but all of it became rather clear after just a few playtests. The team didn’t kill the idea, and they didn’t force the original design through either. They were candid about what was and wasn’t working, and determined that the champion was worth iterating and the kit reworking, which they did until it came together. So the act of playing something in-engine tells you the truth quickly, and being transparent and humble about what that shows, then iterating, is usually the right response to a prototype that isn’t quite there yet.

Done well, a prototype gives you a concrete, more well-rounded assessment, whatever that turns out to be, yay or nay. It also gives you the peace of mind that you put the idea to the test, and you didn’t just run with a paper concept without giving it a proper analysis. And you also get clarity for yourself and the team to determine next steps together.

Done badly, the prototype is fun for five minutes and goes nowhere (and you still pursue it). Or it slowly grows just-in-case features until you’ve accidentally started production. Or even worse, you treat the prototype code as something to keep, which means you’ve actually started building a game before you made a deliberate decision about whether this is the right idea to pursue or not.

You’re typically ready for the next phase when:

• The prototype gets the core of the game across in minutes.

• The loop and/or the differentiator is clearly working, or you understand well enough why it isn’t.

• The technical unknowns are out in the open rather than still hidden.

• You have an honest sense of what worked, what didn’t, and what it means for the next step.

Concept Bolstering

Now you have something that plays. Good. The immediate next questions are: do you and everyone involved, truly understand the game well enough to build it? Are you genuinely aligned on what this game is and isn’t supposed to be?

You already brainstormed and prototyped the idea, so understandably you may be wondering why answering these questions is at all necessary. Why not just go into pre-production already? Well, it’s because in my experience, the number of people and teams that discover in pre-production or even production that they’re not aligned, that they’re fundamentally not working on the same idea, is positively astonishing. And so is the cost of realizing it at such a late point. The alignment and clarity question is inevitable, so you’re better off asking it and answering deliberately and early.

So there are two goals at this point. The first is to turn your promising prototype into a shared, written-down understanding of the game, clear enough that the team, a publisher and an investor would all picture the same thing without ambiguity. And the second is to continue to work on the prototype and continue to learn past what a very quick one-week hack couldn’t quite tell you.

The alignment documents are initial treatments, rough enough to change and learn quickly from, rather than finished bibles. While this is contextual, they typically entail things like a design treatment, an art treatment with mood boards, a narrative treatment, an early technical assessment, a ballpark effort, and a capacity plan, etc.

This is also the time in which you put together a first draft of the product strategy, which I like to simplify into three short presentations that the whole team can hold in their heads: a product strategy overview (target player, value proposition, market opportunity), a high-level vision of the game (at the level of vision, pillars, target fantasy, user experience, what the game is not), and a game overview (loops, core features, main systems).

Alongside that documentation, you turn the prototype into a more coherent build, still not production code, just a clearer expression of the experience that enables you to dig deeper into what matters most. Maybe that’s expounding on the core loop, some unanswered questions, some technical risks, possible behavioral dynamics, spatial analyses, or testing the audiovisual impact of some higher quality assets.

The example I’ll use is Ryse: Son of Rome at Crytek, where I helped the team during pre-production. There were some strong multiplayer ideas on the table that didn’t quite fit the schedule. It was only when we did some basic planning of the effort and the team’s capacity that the real conversation started: if those multiplayer ideas don’t fit, and unfortunately they didn’t, then what exactly is this game? What matters most? That question forced the team to have valuable discussions about what the game was, and just as importantly, what it wasn’t. As the art bible, the design document, and the level design document took shape, the constraints of the time and capacity informed one decision after another. The vision was strong from the start, so driving for that clarity and that alignment under real constraints is what turned that vision into a team that actually agreed on the game and was able to move forward.

Done well, you can explain the game without hand-waving, the documents make your open questions obvious, the team believes in the game rather than just going along with it, and the bolstered prototype closes the deal.

Done badly, you start writing production code or authoring final art while you’re still meant to be building understanding, spending money you can’t get back on a game that isn’t settled yet. A subtler but common mistake here is authoring a stack of thorough-looking documents that never quite say what the game is, and produce no value and no clarity for the team. If you can’t explain the game simply and have it hold together, you don’t understand it well enough to build it.

You’re typically ready for the next phase when:

• The team agrees on the creative concept.

• Leadership agrees on the business, market and commercial case.

• The build supports the case for making this game.

• No major creative or strategic red flag is still unaddressed.

• The team believes in the game, rather than just going along with it.

Small Phases, But Big Impact

None of this is glamorous. Three fast phases, lots of throwaway work, and the main thing you produce is often on an idea you should not be pursuing. It doesn’t feel like building a game, and that’s exactly why teams rush through it. But this is some of the most important work you’ll do on the whole project. Every no you reach here is one you didn’t have to discover midway through the expensive stretch, after hiring twenty people and spending potentially millions.

If you do these three phases with your heart and your head, you maximize your chances of building a strong foundation for your project, with a game worth building, with a team that’s aligned on what the game is, clear on why it’s going to be great and truly bought into the idea. That’s legitimately not an easy thing to do well and it pays off in spades as you get into the expensive stretch.

That stretch is where Part 2 begins. Pre-production is the phase teams misunderstand more than any other, and it’s where all this early discipline pays off.

About the Author

Sebastian Cardoso is a COO and executive producer with 20 years in the games industry, including leadership roles at Riot Games, EA, and Crytek. He's the founder of Game Studio Unlocked, a fractional consultancy that brings executive leadership to indie studios around the world. He also writes a newsletter on Substack on how to effectively lead and run game studios.

Until Next Week…

As you found out in this article, good game development doesn’t start starts with making better decisions. The best progress isn’t always to write more code or create more assets. Sometimes you have to take a step back and know when to challenge an idea before you’ve invested months of work into it.

Did you enjoy the launch of this series? Do you feel it’ll benefit a teammate or other game developers you know? Feel free to share it with them. And stay tuned for Part 2 next week when we'll explore the pre-production phase, which Sebastian believes is misunderstood more than any other.

Today we’re going to briefly touch on what authenticity looks and feels like in games. When we talk about it, the conversation usually starts with the details. Does the armor match the time period? Is the architecture historically accurate? Did the developers get the weapons right? Those things certainly matter. But making a game look and feel authentic doesn’t stop there. It runs deeper than visual accuracy.

Social engineering is about manipulating people’s emotions. Identify the susceptibilities that hackers use to exploit people.

This NINJIO Insights Report dives into the key emotional susceptibilities that make social engineering work and offers concrete steps that your security team can take to equip your workforce to resist cyberattacks.

Download the Guide

We wonder if the world feels lived in, whether its people have believable traditions, values, routines, and histories, and whether players feel like they’re stepping into a place that has existed before they even knew about it. The challenge is that many games still draw from a relatively small slice of history.

We’ve spent decades exploring medieval Europe, Viking legends, ancient Greece, feudal Japan, and post-apocalyptic America. These settings have produced some of the most memorable games ever made, but they don’t represent the full richness of human civilization. There are countless cultures, empires, scientific achievements, artistic movements, and everyday stories that rarely make it into mainstream games.

When developers do decide to explore less familiar cultures, another question quickly follows. How do you do it well?

For many studios, the instinct is to start researching towards the end of production. They collect visual references, read a few articles, perhaps visit a museum, and begin recreating what they see. But authentic representation isn’t something you can simply layer on at the end.

It’s woven into almost every creative decision, from world-building and environmental art to character design, dialogue, architecture, music, clothing, social customs, and even the small details players don’t consciously notice.

That’s why more studios are beginning to see historians and cultural consultants as creative collaborators, whereas before they would have been perceived as only fact-checkers. Rather than limiting ideas, they expand them. They introduce stories that aren’t widely known, uncover details that make environments feel unique, and challenge assumptions and open up entirely new ways of thinking about a setting.

As indie developer Rami Ismail has discussed, Muslim representation in games has often been surprisingly narrow. Too frequently, Muslim characters or Middle Eastern settings appear through the lens of conflict, violence, or political instability, while overlooking centuries of scientific innovation, architecture, philosophy, literature, trade, and everyday life that shaped entire civilizations. We are now reminded that representation isn’t about avoiding stereotypes, but about recognizing the incredible variety that already exists.

The games industry is uniquely positioned to bring these stories to life because games allow players to experience cultures rather than simply observe them. Players are active participants who walk through a city rather than just watch it like you would a movie. They listen to conversations, solve problems, explore neighborhoods, meet characters, and gradually understand how a world functions.

When that world has been built with care, players notice. Everything feels internally consistent. The architecture reflects the culture, the customs feel authentic, the people feel like they belong, and together those details create a world that feels complete.

Perhaps the most exciting part is that this isn’t only relevant for large AAA studios. Indie developers can benefit just as much. Whether you're building a historical adventure, a fantasy world inspired by real cultures, or a sci-fi universe set hundreds of years in the future, bringing different perspectives into the process can make a huge difference. It's not about having a massive budget; it's about being curious, asking the right questions, and involving people with the right expertise from the start.

Games are played by people all over the world, and players are becoming more curious about stories they haven't seen before. They want to explore new places, learn about different cultures, and experience worlds that feel fresh instead of revisiting the same settings over and over again. For developers, that’s not a limitation; it’s an opportunity!

There are still thousands of stories waiting to be explored.

That’s exactly why we’re excited to welcome Dr Glaire Anderson for our upcoming Game Dev Assembly live session. Drawing on her experience as one of the consulting historians and an art historian on Assassin's Creed Mirage, Glaire will share how historical research became part of the game's creative process. She'll talk about why bringing cultural expertise into development early can lead to richer, more believable worlds, and how studios of any size can do the same.

If you’re interested in creating worlds that players genuinely believe in, this is a conversation you won’t want to miss. Sign up here. It’s free to attend. Please share it with your game dev friends too.

Until our next issue, stay awesome, stay connected, and keep creating 💜🎮

Warm Regards,

Game Dev Assembly Team

Hi everyone! Welcome back to another edition of Game Dev Assembly Industry Signals 🎮 Some of you might think the biggest shifts in game development start inside studios, but it’s important to keep an eye on whether they’re actually starting with players. How people discover games, decide what to play, spend their time, and even define value is changing faster than many development practices.

This week, we’re stepping away from engines, funding, and production pipelines to look at something even more important: how player behaviour is evolving, and what those shifts mean for the games we build. Let’s get into it. 🚀

Players Are Buying Fewer Games…

… but spending more time with the ones they love. One of the biggest stories of 2026 is that players are becoming much more selective.

Recent market analysis from Newzoo highlights how player engagement is increasingly concentrated around a relatively small number of titles, while Circana’s monthly reports continue to show established games dominating player time. If you’re curious, both reports make for fascinating reading.

You can also see this yourself by browsing Steam’s Global Charts, where many of the same titles remain among the most-played week after week.

Players aren’t looking for another game, but their next obsession.

It’s normal to think you’re competing against new releases, but this signal tells you that your real competition is against the games which players already don’t want to stop playing.

Communities Are Becoming the Product

Ten years ago, community supported the game, but today, it’s part of the game.

Discord servers, modding communities, creator challenges, community events and fan art are becoming central to long-term success rather than nice extras.

The GDC State of the Game Industry Report continues to highlight community engagement as an increasingly important part of development strategy, while marketing expert Chris Zukowski regularly explores why building an audience before launch has become one of the strongest predictors of success on How To Market A Game.

So think of your community as your game’s biggest features, and not just as your marketing department.

Co-op Continues to Outperform Expectations

Take a look at some of the biggest breakout successes over the past couple of years. Games like Lethal Company, Content Warning, and more recently Peak all have something in common.

They’re designed to create stories between friends.

We don’t know if this is a nostalgic yearning of the past where real, interconnected experiences are more in demand. But these kinds of games are made up of funny failures, unexpected moments, and shared chaos. They’re experiences players want to send to someone else.

Take a look at their Steam pages and you’ll quickly notice that the player reviews often talk less about mechanics and more about the memories players created together.

Sometimes players are looking to buy somewhere to spend Friday night with friends.

Watching Games Is Becoming Part of Playing Them

Playing is only half the experience now.

Millions of players discover games through Twitch streams, YouTube videos and creator clips before they ever visit a storefront. Recent reports from Stream Hatchet continue to show gaming dominating livestream watch time, while YouTube Gaming and Twitch remain some of the biggest discovery engines in the industry.

You need ask, “Would someone watch someone else play my game?”

In a nutshell, games increasingly have two audiences made up of players and spectators.

Decision Fatigue Is Becoming a Design Problem

Modern players make hundreds of decisions every single day.

Then they launch a game that asks them to manage battle passes, crafting systems, currencies, inventories, daily quests and progression trees before they’ve settled into the experience. Meanwhile, games like Balatro, Animal Well, and Dredge prove that focused experiences can still captivate millions.

Design educators such as Extra Credits and developers writing on Game Developer have increasingly explored how reducing cognitive load can improve onboarding and long-term enjoyment.

Players are simply looking for fewer reasons to feel overwhelmed. Sometimes the best design decision is removing complexity, not adding it.

Local Culture Is Becoming a Competitive Advantage

After many years of seeing studios aiming for universal appeal, now we’re seeing the opposite.

Games rooted in authentic culture are standing out: Black Myth: Wukong introduced millions of players to Chinese mythology. Kingdom Come: Deliverance II leans heavily into medieval Bohemian history.

Regional showcases at events like Gamescom and GDC are also giving more visibility to studios from Latin America, Southeast Asia, Africa and Eastern Europe.

Rather than trying to appeal to everyone, many of these games succeed because they feel unmistakably authentic. Your local culture may be one of your biggest creative advantages.

What This Means

While putting this edition together, something stood out to us, we recognized that none of these signals are really about technology. They’re about people.

Players are becoming more intentional about where they spend their time, who they spend it with, and what experiences they choose to invest in. They’re gravitating towards games that feel authentic, communities that make them feel connected, and experiences that respect their time.

Perhaps that’s the biggest signal of all. As developers, it’s easy to get caught up in new tools, new engines, and new trends. But the studios that thrive over the next few years may simply be the ones that understand their players better than anyone else.

🚀 Your Move This Week

We want you to give a crack at asking yourself:

• What emotion does my game create?

• Why would players return tomorrow?

• Would people enjoy watching someone else play this?

• Does my community have reasons to interact without me?

Then test one assumption with real players this week and share it with us. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

Welcome back, everyone 🎧 This week, we’re kicking off a special two-part mini-series, On Listening, Awareness, and Why the World Outside Your Studio Matters, with game audio expert and author Paul Renard.

In Part 1, Paul takes us on a journey that starts on the streets of Paris. Through the act of listening, he explores why some sounds stay with us, why others disappear into the background, and what game developers can learn from the world around them. This issue offers a fascinating perspective on one of the most powerful, and often overlooked, tools in game development. So put on your headphones, turn up your speakers, and let’s dive in. Enjoy the read! 🚀

Table of Contents

1. The Day I Started Listening

2. Audio as an Afterthought

3. Players React Before They Think

4. Hearing Is Not the Same as Listening

5. We Capture What Cannot Be Heard

6. Sound Needs Something to Say

7. The Skill Trap

8. Taste Is Something You Build

9. Four Things Worth Carrying

10. About the Author

The Day I Started Listening

It was a Tuesday morning, somewhere between Lamarck Caulaincourt and the center of Paris. Nothing special about the day. I wasn’t on my way to a session, wasn’t thinking about anything in particular. Just walking.

And then I started listening.

Not hearing, which is what we do by default, the passive background processing that keeps us from bumping into things. Actually listening. There was a bus pulling away from a stop, that low diesel exhaust note that feels more felt than heard, somewhere below the chest.

Behind it, almost immediately, an electric scooter weaving through the gap it left, nearly silent except for the faint whir of its motor and the specific texture of its tires on slightly damp asphalt. A woman walked past in heels, the rhythm precise and unhurried on the stone pavement. A few steps behind her, a man in sneakers, same pace roughly, completely different texture. Softer, rounder, almost no attack at all. Someone was arguing on the phone across the street, voice cutting through everything else without trying. And next to him, a kid, maybe eight years old, walking next to his mother, completely silent, watching the bus disappear.

None of that was designed. And yet my ear moved through all of it without fatigue, without wanting any of it to stop. Because nothing stayed the same long enough to become wallpaper.

I’ve been working in game audio for years, across AAA titles, indie projects, film, and post-production. And I can tell you that the most useful thing I’ve done for my work as a sound designer had nothing to do with a plugin or a mixing technique. It was learning to actually listen to the world and then asking why it works the way it does.

Audio as an Afterthought

I think most people who work in game audio have been in this situation at least once. The project is deep into production, most of the big decisions are locked, and audio is brought in to pull everything together. It makes sense logistically. But it means sound is reacting to a finished world rather than helping to build one.

What I’ve noticed in those situations is that the issue is rarely the quality of the work. The assets are clean, the implementation is solid. What’s harder to solve at that stage is meaning. A cut-scene can look exactly right and still feel like something is missing, not because the audio isn’t there, but because it was never given a brief beyond “support what’s on screen.” Without knowing what a moment is supposed to make the player feel, it’s genuinely difficult to build sound that carries that feeling. You end up filling space rather than shaping experience.

Getting audio into the conversation earlier, even just the questions, what does this moment feel like, what should the player sense here, changes what gets built. Not always dramatically, but in ways that accumulate across a whole game.

Players React Before They Think

Something I find endlessly interesting about sound is how early it works. Before a player has consciously registered what’s happening, their body has already responded to a shift in the ambient texture, a low frequency building quietly under the music, a sudden absence of sound where there was sound before. We evolved to process audio fast. It’s one of our oldest survival systems.

That means sound has a kind of access that other design elements don’t. It can prepare a player for something before they see it. It can make a space feel unsafe in a way they can’t quite explain. It can signal that something has changed in the story before the narrative has said so explicitly.

When I think about the sounds I remember most from games I’ve worked on or played, they’re almost never the loudest ones. They’re the ones that felt inevitable, that fit so precisely into their moment that they seemed to come from the game’s world rather than from a design decision. A small ambient shift. A silence that arrived at exactly the right time. Those things stay because they were working on a level the player wasn’t fully conscious of.

Hearing Is Not the Same as Listening

This is a distinction I come back to a lot, especially during production when things are moving fast and the temptation is to check boxes rather than ask harder questions.

Hearing is passive. Does the sound trigger correctly? Is the level right? Is there anything technically wrong? Those questions matter, but they’re not enough on their own.

Listening is asking what a sound is actually doing to the player. And one of the most useful tests I know is also one of the simplest: remove the sound and see what changes. If the scene reads the same way without it, if the player’s experience isn’t measurably different, then that sound isn’t doing what it needs to do yet. It might be technically present and correctly implemented and still not be earning its place.

Some of the decisions I feel best about in my own work have been removals. Taking something out and discovering that the absence was more powerful than the presence. That only happens if you’re actually listening rather than just checking.

We Capture What Cannot Be Heard

There’s something that connects that habit of active listening to the more practical side of sound design work, something I don’t think gets talked about enough.

When a cinematographer wants to show something the naked eye can’t see, they reach for a different tool. A macro lens to isolate detail that would otherwise blur into the background. A thermal camera to make heat visible. A high speed camera to stretch a single moment long enough to actually see what’s happening inside it. The camera isn’t just recording reality. It’s extending perception, showing us something we couldn’t have accessed on our own. And those images tend to be the ones that stay with us, precisely because they reveal something that was always there but never seen.

Sound works the same way, and some of my favorite moments in this work have come from that exact impulse. Placing a contact microphone against a surface most people would walk past without a second thought. Lowering a hydrophone into water and hearing the world that exists just underneath it. Tucking a small capsule mic inside a piece of machinery and discovering a texture that has been running continuously, completely unheard, for years.

What those microphones do is extend listening beyond the range of normal human attention. But before you can use them that way, you have to be able to imagine what’s there. You have to ask: what is happening inside this object, at this scale, from a perspective that doesn’t exist in ordinary experience? What would I hear if I could be smaller, closer, further inside the source? That question is an act of imagination before it’s a technical decision. And it comes directly from the same habit as that Tuesday morning walk. The street trains the ear to notice. The microphone extends it to places the ear alone can’t reach.

The sounds that come back from those sessions often have a quality that’s hard to manufacture any other way. Something that feels discovered rather than assembled. And that quality, even processed beyond recognition, even layered into something completely abstract, tends to carry through into the final product. Players feel it without knowing why. It’s part of what makes a sound world feel real rather than just accurate. There’s a difference between those two things, and it lives in the details that only close listening can find.

Sound Needs Something to Say

The clearest path to generic audio, in my experience, is designing without narrative context. Not because the work is careless, but because a mood label isn’t the same as a brief.

“Mysterious forest” tells you a category. It doesn’t tell you what the player just experienced before entering this area, what they’re about to discover, what they should feel in their body as they move through it. Sound built on a category will feel categorically correct and emotionally vague, because it was never given anything more specific to work with.

The conversations that have shaped my work most weren’t about sound at all. They were about story. What does this character know right now? What doesn’t the player know yet? What should the next thirty seconds feel like emotionally? When those questions are answered, the sound almost tells you what it needs to be.

When I was writing the Audio Mixing Cookbook I had the chance to sit down with Charles Deenen, one of the most respected sound designers and re-recording mixers working across film, trailers, and games. We talked for a long time about narrative, emotion, and what sound is actually for. At some point he said something I haven’t stopped thinking about since:

“A sound needs to make sense before it tries to impress.”

That landed for me because it names something I’d felt but hadn’t articulated. The instinct to make something impressive isn’t wrong. But if the sense isn’t there first, the impression doesn’t stick. It just fills space.

The Skill Trap

There’s a lot of excellent technical education in the game audio world, and I think that’s genuinely valuable. Knowing your tools, understanding implementation, being fluent in a mix session, all of that matters and takes real time to develop.

But something I’ve had to be honest with myself about over the years is that technical fluency and creative judgment are not the same thing, and one doesn’t automatically produce the other. Judgment is knowing which of your technically correct options is the right one for this specific moment. It’s knowing when silence is the answer. It’s knowing when the sound you spent the most time on is the one that needs to go.

That’s not something you learn from a tutorial. It comes from shipping work, watching players, being wrong, and paying enough attention to understand why. It develops slowly and it’s worth taking seriously as its own kind of practice, separate from the technical side.

Taste Is Something You Build

Which brings me back to that Tuesday morning in Paris. The bus, the scooter, the heels, the sneakers, the man on the phone, the silent kid. The reason none of it was fatiguing is that the contrast was constant. The electric car only registered because the diesel just went by. The voice cutting through the street only worked because the woman next to him wasn’t making a sound. Nothing was impressive in isolation. Everything earned its place through relationship.

That’s the system I try to keep in mind when I’m designing for a game. Not a set of individually impressive assets, but a texture with a shape. Something that has a floor as well as a ceiling, space as well as density, moments of quiet that make the moments of impact actually land.

And the way I’ve found to develop that instinct is specific and unglamorous: watch players. Sit with someone who has never touched the game and don’t say anything. Watch when they hesitate, when they ignore something, when they react to something they can’t explain. Test with and without sound. Mute a scene mid-playtest and notice what you suddenly understand about it. Ask what you’re reinforcing with every sound, and whether that’s actually what the moment needs.

Taste isn’t a personality trait. It’s trained judgment. And it gets trained through attention, over time, one honest decision at a time.

Four Things Worth Carrying

1. Ask the narrative questions before the sound questions. What should this moment feel like? What does the player need to sense here? Those answers are the brief.

2. Test for removal as well as presence. If a sound’s absence doesn’t change the experience, it hasn’t found its purpose yet.

3. Think about time. A sound that works beautifully once might work very differently after a player has heard it two hundred times. That’s a different design problem and worth solving early.

4. Sit in playtests and watch. Not the screen. The player. Their reaction will tell you more than any technical note.

The sounds players remember are usually the ones they never consciously noticed. They just felt something, and didn’t know why. That’s the work.

About the Author

Paul Renard is a sound designer working across AAA games, film, and music technology. He is the founder of Renard Sound, an educational channel where he shares his vision and approach to creating high-quality game audio, and has collaborated on sound libraries and content with Tonsturm and synthesizer instrument libraries with Arturia. His recent credits include 007: First Light, Fragpunk (Molinare), and Project Windless, a fantasy open-world RPG with Krafton Montreal. He also works with Wargaming and is currently active across several other game projects. He is the author of Audio Mixing Cookbook, by Packt Publishing in 2026. With almost a decade in audio and game audio specifically, Paul's expertise spans creature, robot and character sound, magic and sci-fi abilities, cinematic layers, world-building ambiences, VO design, foley, and audio mixing and implementation.

Closing – Until Part Two

And that’s a wrap on the first part of our mini-series on sounds.

Paul truly challenges us to think differently about sound. It’s something we have to try not to add at the end of development, but instead, allow it to quietly shape how players experience a game from moment to moment. The most memorable sounds are the ones players don’t consciously notice at all. They simply feel their impact.

We’ll continue the conversation with Paul in an exclusive interview, where we’ll explore the stories, lessons, and experiences that have shaped his approach to game audio. We’ll talk about the realities of working across AAA and indie projects, how sound influences player psychology, and why creative judgment is often just as important as technical skill.

If this week’s issue has you paying a little more attention to the sounds around you, then you’re already thinking like a sound designer.

Until then, keep listening and creating.🎧

Warm regards,

The Game Dev Assembly Team

From Hollywood’s growing investment in games to the rise of UGC platforms, showcase ecosystems, and genre mashups, let’s explore where the industry is heading next. 🚀

🎬 Hollywood Is Treating Games as Franchise Infrastructure

Paramount launched Paramount Games Studio and revealed Teenage Mutant Ninja Turtles: The Last Ronin with PlatinumGames during Summer Game Fest.

What does this mean?

For years, games based on movies and TV shows were treated as promotional tie-ins. A film would launch, a game would appear alongside it, and that was usually the end of the relationship.

That appears to be changing.

More and more, entertainment companies are viewing games as permanent extensions of their intellectual property rather than temporary marketing vehicles. Instead of simply licensing characters to external developers, they’re building dedicated gaming divisions, hiring experienced development partners, and creating games designed to stand alongside films, television series, comics, and streaming content.

Why? Because games offer something other media cannot, which is hundreds of hours of engagement. A player might spend two hours watching a film. They might spend fifty hours inside a game world. That makes games one of the most powerful ways to deepen audience attachment to an IP.

In a nutshell, games are becoming a core pillar of franchise strategy, not just merchandise.

🧸 Wholesome Mascot Games Are Coming Back

Spyro: A Realm Beyond was announced as Spyro’s first original game since 2008, with Toys for Bob positioning it around joy, optimism, and family-friendly play.

For much of the last decade, the industry chased scale and engagement, so things like bigger worlds, darker stories, more systems, and more retention mechanics.

But recently, it seems that players are craving something different. The return of franchises like Spyro isn’t about nostalgia alone, but reflects growing demand for games that feel approachable and emotionally uplifting.

After years dominated by live-service ecosystems, competitive multiplayer experiences, and mature themes, colourful mascot games offer simple joy.

This trend isn’t only appearing in family-friendly games, but across the industry where we’re seeing players responding strongly to titles that carry personality, charm, and emotional warmth over complexity.

After years of dark, mature, live-service-heavy releases, publishers may be rediscovering colourful, character-led games with broad emotional appeal.

🧩 UGC Platforms Are Becoming Parallel Game Economies

Naavik’s 2026 UGC report says Roblox, Fortnite, and Overwolf paid developers around $2.2B in 2025, up 47% year-on-year. Roblox also reported creators earned over $1B globally through DevEx from March 2024 to March 2025.

For most developers, it has been about building a game, launching it, and then selling it. Platforms like Roblox are introducing a different model. Instead of building a game and then finding players, developers can build directly inside ecosystems that already contain millions of players.

This means discovery, monetization, and community work differently. In some cases, creators are treating these platforms less like game engines and more like marketplaces. The opportunity really is to create experiences inside an existing economy.

As developers, the question you should think about is less of “Should I launch on Steam?” but “Should I build inside an existing player ecosystem?”

🎪 Showcases Are Becoming Discovery Infrastructure

Summer Game Fest week now includes SGF, Day of the Devs, The MIX, Women-Led Games, publisher showcases, and sponsored industry events. Xsolla specifically positioned its SGF presence around helping developers connect with media, publishers, creators, and players.

Many developers still think of events as moments where they release a trailer, an announcement, and a chance to make an impression. Nowadays, showcase ecosystems are becoming more interconnected.

Summer Game Fest week alone now consists of dozens of overlapping opportunities, each serving different audiences, communities, creators, media outlets, publishers, and investors.

What matters is to show up, and show up repeatedly. Each time you appear, you’re compounding awareness.

In a nutshell, the showcase calendar is becoming part of the marketing stack. Visibility has gone from being one big trailer to a network of curated moments.

🕹️ Third-Party Developers Are Re-Evaluating Nintendo

Ampere reported Switch 2 helped third-party Nintendo game sales reach $2.3B, up 76% year-on-year, while Newzoo’s earlier Switch 2 data suggested selective opportunities for enhanced ports, narrative games, and non-traditional Switch genres.

Historically, many third-party studios viewed Nintendo platforms differently from PlayStation, Xbox, or PC. The assumption was that only certain genres worked well within Nintendo’s ecosystem.

But the Switch changed that perception. And early signs suggest the Switch 2 is expanding it further since the audience has matured, hardware limitations have reduced, and player expectations have become broader.

And because of this, developers are beginning to ask whether Nintendo should be treated as a primary platform instead. The success here appears tied to design philosophy rather than genre, as games which emphasize readability, portability, strong art direction, and intuitive controls often perform well.

In a nutshell, developers who understand how people play on portable devices may find themselves well-positioned for the next wave of growth.

👾 Genre Mashups Are Becoming the Indie Differentiator

Day of the Devs showed games blending roguelikes with fighting games, rhythm games with platformers, horror with live-action, and fishing with post-apocalyptic adventure.

A decade ago, indie success stories were built around doing one thing exceptionally well. Today, it’s harder to stand out. Players are exposed to thousands of new games every year. As a result, familiar genres struggle to generate attention on their own.

One response we’re seeing from developers is unusual combinations because it creates immediate curiosity. The moment players hear the pitch, they want to know more.

And the kick here is that the best genre mashups are easy to explain. They need not be complicated.

In a nutshell, indies are not just competing through smaller scope anymore, but through unusual combinations that are easy to pitch and hard to copy.

🚀 Your Move This Week

Take a moment to ask yourself:

• If you were launching your game today, where would players discover it?

• Which ecosystems are most relevant to your audience: Steam, Nintendo, Roblox, Fortnite, creators, showcases, or something else?

• Could your game’s concept be explained in a single sentence that immediately sparks curiosity?

• Are you building a product, or are you building a community around it?

• What opportunities might you be overlooking by focusing only on traditional publishing paths?

And as always, we’d love to hear your thoughts. Drop a comment or send us a message. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

In Part 4, Jay brings everything together into a practical system you can run week after week. You’ll learn how successful studios create self-reinforcing growth loops, why community should be treated as infrastructure rather than an audience, which metrics actually matter, and how just a few focused hours each week can build momentum long before launch day. If the first three parts explained the engine, this is the owner’s manual. Let’s close out the series. 🚀

Table of Contents

1. A Quick Recap

2. The Content → Player → Content Loop

3. Community as Infrastructure, Not Audience

4. The Weekly Cadence

5. The 3 Signals That Tell You It’s Working

6. When to Bring in Help

7. You Need Loops, Not Virality

8. Game Launch Readiness Scorecard

9. About the Author

A Quick Recap

We’ve covered a lot of ground over the last three weeks.

First, we named the failure pattern: most studios don’t have a marketing problem, they have a marketing leadership problem. Then, we laid out the six-component engine that solves it. Last week, we put real, concrete numbers on where players actually find games now, what wishlists are really worth, and how to work backward from a revenue target you can defend.

This week, we quite literally close the loop.

After walking studios through everything we’ve covered in Parts 1, 2, and 3, they usually ask me different versions of the same question: “Okay, but what does running this actually look like? Day to day, and week to week, when I have a build to ship and a kid to feed and 1,000 other things demanding my attention?”

Fair question! Let’s answer it now.

The Content → Player → Content Loop

Has anyone ever told you “work smarter, not harder?” Well, you’re about to hear it again. And to be clear, I’m not saying that you don’t have to work hard (you do), nor am I saying that the studios that win at scale don’t outwork the studios that fail. But in this industry, hard work is the bare minimum; the table stakes, the price of entry. No, the successful studios do something else on top of that: they build a loop that does some of the work for them.

The loop, in one sentence, is:

Content brings players, players make content, content brings more players.

Look at the tail of any breakout indie hit from the last few years. Lethal Company (the four-player co-op horror game from solo developer Zeekerss) generated 507 times its first-week revenue in its first year on Steam, the largest long-tail multiplier of any 2023 release. Pizza Tower hit 22.5x, while Class of ‘09: The Re-Up hit 106x. The median across all 2023 Steam releases, on the other hand, was just 2.64x.

What separates the breakouts from the median? They’re not spending more on ads, I’ll tell you that much. The breakouts win because their players became part of their marketing engine: streamers played the game, their viewers clipped the funniest moments, those clips spread to TikTok and Twitter (X), new players bought in, the new players streamed it themselves, the clips kept spreading, and so on and so forth. The flywheel turned, and turned, and turned, and turned… to the tune of 22.5x to 507x revenue.

That’s what the content → player → content loop actually means in practice. Or, to simplify:

1. You ship some content: a demo, a trailer, a build, or a clip.

2. Some players engage with it.

3. The ones who engage produce their own content about the experience: streams, clips, fanart, memes, and Reddit threads.

4. That content reaches new players, who join the cycle.

Each turn of the loop costs you less effort than the last, because the players themselves are now part of the engine.

Note that the question isn’t just how to make your game go viral; that’s not a strategy I’d bank my launch numbers on (and, by extension, my livelihood and that of my teammates). Viral moments are flashes in the pan that strike basically at random and are hard to transmute into sustained momentum unless you already have a robust marketing engine that’s well-calibrated to scale with virality.

Instead, ask yourself: what about your game gives players a reason to make content about it? If you can answer that, and deliberately design for it, the loop will start to spin before you know it. But without it, no amount of marketing budget will save your launch.

Community as Infrastructure, Not Audience

Nearly every studio makes a critical category mistake about community, which I want to directly address here.

A Discord server with 2,000 members where only 10 people talk and the rest lurk is not a community. It’s a list. Or, in the best case, merely an “audience.”

An actual community is when the members talk to each other about your game, without you in the room. In an actual community. players post fanart for other players instead of just the dev team. Or three other players try to debug something before you’ve even seen the bug report. In a real community, inside jokes form (that you didn’t write), and members defend the game to skeptical outsiders without even being asked.

This is categorically different from an “audience,” which means it requires categorically different inputs from you.

“Audiences” only want broadcasts. You post, they react, and the conversation ends there. Communities, on the other hand, need infrastructure: channels that work, conversations with momentum, and recurring rituals that give people compelling reasons to come back to you instead of doomscrolling TikTok for the next six hours. Whether you host weekly screenshot Saturdays, pin a thread for the game’s active speedrun leaderboard, or conduct a monthly playtest where the same regulars know each other by handle, a community has a distinct culture that you cultivate, not a feed you merely populate for an “audience.”

If you treat your Discord as just another channel to post the trailer to, you are merely managing an audience. And in return, you will only get audience-level results: modest reach, and middling amplification that will quickly decay after launch. But if you treat your Discord as community infrastructure, you are building something that will compound. Your players will show up to launch having already bonded, both to each other and to the game, and will leap into action to purchase, review, and promote your game the instant it launches. That’s the difference between a Discord that moves 3,000 units and one that moves 30,000, even if they have similar raw member counts.

Community is the only marketing asset you build that will market for you when you’re asleep. So treat it with the respect and gravitas that it deserves.

The Weekly Cadence

Now, it’s time for the most practical advice I can give you: what does running this engine actually look like in a given week, when you also have a game to make?

I’ve cooked up a working cadence that any indie studio, no matter what size, can sustain for the entire pre-launch year. It assumes one person currently owns marketing (whether that’s a solo dev, the founder, or a designated lead). Adjust as needed to your particular context:

Monday (45 minutes): Plan the week. Ask yourself:

• What content am I shipping this week?

• What channels does it go to?

• Who needs to hear from me (creators, press, partners), and what’s the ask?

Block the time you need on your calendar now, before the rest of the week eats it. Remember, this game isn’t going to sell itself!

Tuesday (60 minutes): Actually make the content. One devlog post, one short clip, one screenshot, one community post. Don’t let “perfect” be the enemy of “done”; not all of it has to be polished, and in fact, most of it shouldn’t be! Polished marketing reads like marketing, but rough marketing reads like a human.

Wednesday (30 minutes): Engage. Reply to everyone who’s commented on your posts in the last week, comment on three other games in your genre that you’ve played and you actually like, show up in at least two Discord servers where your players hang out. This is the cheapest and most underused growth lever indies have at their disposal.

Thursday (60 minutes): Outreach time. Send out two cold pitches to creators, and at least one follow-up to a creator who didn’t respond last time. Schedule one coffee chat or call with another dev in your genre. In this industry particularly, who you know matters more than what you know, and networking compounds the same way community does: slowly at first, then all at once.

Friday (30 minutes): Measure the results. Look at the numbers we’ll cover in the next section. Note what changed, what surprised you, and what you’ll do differently next week. Then, close the laptop and go for a walk (or get back to building the game; after all, if it doesn’t get made, then everything we’ve covered is moot).

That’s about ~3.75 hours per week, less than half a day of effort. Most studios I talk to are spending zero hours per week on this… until 90 days before launch, then they panic. But even consistently spending three to four hours each week, for the full year before launch, will outperform any panic-mode launch sprint.

Don’t optimize for volume; the trick is consistency. A system running at 70% every week beats a campaign run at 100% twice and zero in between.

The 3 Signals That Tell You It’s Working

Dashboards are fun, yes. But they can also be distracting at best, and overwhelming at worst. Fortunately, you don’t need a dashboard! You only need three numbers… but you need to check them weekly:

1. Net daily wishlist additions (rolling 7-day average): This is your engine’s velocity. If it’s growing week over week, the engine is working. If it’s flat, you’re maintaining. And if it’s declining, something has gone stale and needs your immediate attention. Steamworks gives you this number for free under the Wishlists tab, by the way.

2. Community activity (not size!): Specifically, how many unique members participated in your community this week? And “participated” means posted, commented, or reacted. A Discord with 500 members and 80 weekly active is healthier than a Discord with 5,000 members and 8 weekly active. The first signals a healthy and thriving community infrastructure, whereas the second is just a glorified list.

3. Creator coverage in the last 30 days. How many creators have either streamed, made a video about, or posted about your game in the last 30 days? You don’t need huge channels (which is good news, because let’s be real, the biggest streamers are not going to cover your game), but you do need consistent coverage. One 20k-subscriber YouTuber covering you every two weeks beats one 500k hit followed by six months of silence.

That’s it! Just three numbers to track. Most studios track none of them; and if they track any metrics at all, it’s meaningless vanity metrics like follower count or post engagement. But tracking these three metrics on a weekly basis will give you a far clearer picture of whether your launch will succeed than even your total wishlists, to say nothing of any vanity metric, ever will.

When to Bring in Help

The cadence I just described is more than sustainable for one focused person, carving out two to four hours a week. Many founders can handle that themselves. Some, however, can’t… or shouldn’t.

Here is how I think about when to bring in help:

You’re ready to bring in strategic help when:

• You’re 3–12 months from launch and your wishlist trajectory is below where the math says it needs to be.

• You can articulate the work that needs to happen, but you don’t have the time to actually do it.

• You’ve made it through Parts 1 through 3 of this series and you can see clearly which of the six engine components are weakest in your studio, but you’re stuck on how to fix them.

You’re not ready when:

• Your game’s core gameplay isn’t validated yet. (Marketing a game that players don’t enjoy is both developmental and marketing malpractice.)

• Foundational creative decisions are still in flux: genre, core gameplay, target player. (Marketing strategy work assumes those are settled. External help can help you sharpen how your game shows up in its market, but no external marketer can help you decide what game you’re making. That’s your call as a studio.)

• You’re hoping a hire will let you avoid thinking about marketing at all. (It won’t. If anything, you’ll be more involved, not less.)

The first hire (assuming you hire the right person) is rarely a community manager, and almost never a paid ads specialist. You should first hire whoever can hold your launch’s strategic picture (the engine itself) in their head, and make sure all six components are firing in the right sequence. And the reason this is so important, is that this is the role that determines whether any other subsequent hires succeed.

If you’re at that point and you’d find it useful to walk through your own engine with someone who’s done this many times, I run a focused half-day session called the Speedrun Strategy Session. It’s both diagnostic and prescriptive, and for only $8,000, you walk out with a clear, written plan for the next 90 days. Details and booking at calendly.com/jay-spawnpointmarketing/free-consult — start with a free 30-minute consult to see if it’s a fit.

You Need Loops, Not Virality

Wow, we’ve covered quite a lot of ground, haven’t we? Before we wrap up, I want to leave you with one last nugget. If you remember nothing else from our time together, this is what I most want you to leave this series with.

Successful studios don’t get there by being lucky, or by going viral. They don’t get there by spending more on ads, or having a bigger team, or knowing the right person at Valve.

They get there by running a system. One that starts before greenlight. A system with six interlocking components (timing, Steam page, community, wishlists, creators, leadership), each reinforcing the others. A system grounded in actual numbers, not hopes, and a weekly cadence that anyone can sustain. A system with three signals that tell you whether it’s actually working.

You don’t need to be a marketing expert to run it. But you do need to know it’s there, name someone to own it, and protect a few hours a week to keep it running. That’s the whole game, pun absolutely intended.

Remember, marketing is a leadership problem. Ergo, the fix is leadership.

Go build the engine.

Game Launch Readiness Scorecard

If you want to see where your studio sits across all six components right now, the Game Launch Readiness Scorecard will show you in four minutes: absolutely free, no spam, no upsell, just a number, a tier, and your top three priorities: scorecard.spawnpointmarketing.com

And on Tuesday, June 9th at 9:00 AM PT, I’m running a free 60-minute live session with Game Dev Assembly: Building a Marketing Engine for Your Game (Without a CMO). We’ll walk through the engine live and run a Q&A. If this series resonated with you, the live session is where we go deeper. Sign up here.

Thank you for reading this series. It’s been a privilege to write it for you.

GG,

~Jay

About the Author

Jay Rooney is a founder, marketing strategist, writer, and lifelong gamer working at the intersection of game development and growth. He is the founder of Spawn Point Marketing, a fractional CMO practice serving indie and AA game studios, where he helps founders build the marketing systems that turn good games into successful launches.

He previously co-founded Digi-AI, an AI-native mobile developer he scaled from zero to 700,000 users with no paid advertising, the case study that grounds much of his current work on community-driven, systems-led growth. He teaches graduate marketing communications at Golden Gate University in San Francisco.

His work focuses on pre-production marketing strategy, community building as long-term infrastructure, and the leadership decisions that determine whether a launch succeeds twelve months before it happens. He writes about gaming culture and studio strategy in Game & Word, an award-winning newsletter, and publishes the Spawn Point Marketing Substack on fractional marketing leadership for studios.

He got his start in the games industry by reviewing games for Level Up Media, and also shipped an indie game as a narrative designer (Tavern Simulator), because he believes the best game marketing comes from people who have sat on the dev side of the table.

Closing – The Engine Is Yours Now

And that’s a wrap on our four-part journey through game marketing.

If there’s one thing we hope this series leaves you with, it’s that successful launches aren’t built in the final weeks before release. They’re built through hundreds of small decisions, repeated consistently over time.

You don’t need a massive budget, a publisher, or a viral hit. You need a system, a plan, and the discipline to keep the engine running.

We hope this series has given you the tools to do exactly that.

Until next time, keep building, keep learning, and keep shipping. 🚀

Warm Regards,

Game Dev Assembly Team

But the truth is that the games industry isn’t disappearing. It’s moving. This week, we’re looking at signals that suggest the global map of game development is being redrawn, and what that could mean for studios, developers, and the future of the industry. Let’s get into it 🚀

🌍 The Industry Is Relocating

For the past two years, most conversations have focused on layoffs. But new workforce data compiled by industry analyst Amir Satvat tells a more nuanced story:

• Global gaming employment grew just 0.6% over the last four years.

• North America’s gaming workforce declined by 11.5%.

• Employment growth increasingly came from regions outside traditional development hubs.

• Countries such as India, Türkiye, Saudi Arabia, and parts of Southeast Asia continue expanding their game development ecosystems.

At first glance, these numbers seem contradictory. How can global employment remain stable while North America experiences significant contraction?

Because the jobs aren’t necessarily disappearing. They’re moving.

For decades, the industry’s center of gravity was concentrated around a relatively small number of locations, such as California, Washington, Texas, Canada, Western Europe, and Japan.

Today, that concentration is weakening. Studios are increasingly exploring regions with lower operating costs, growing talent pools, supportive government programs, and expanding local ecosystems.

In a nutshell, the games industry may not be getting smaller, but may be becoming more distributed.

🌎 New Development Hubs Are Emerging

This shift isn’t happening in theory. It’s already visible in the games reaching players.

Countries such as Brazil, Türkiye, Poland, Romania, Indonesia, and Vietnam are producing increasingly successful projects, while attracting greater attention from publishers, investors, and outsourcing partners.

Why? Several factors are converging:

• They have lower development costs.

• They have growing local talent pools.

• They have better access to global distribution.

• They have stronger regional funding initiatives.

• They have remote-first production models.

This trend is significant because these regions are no longer viewed solely as outsourcing destinations. They’re becoming creators of globally successful intellectual property.

And as more games emerge from these regions, the industry may see entirely new creative influences, genres, and design philosophies enter the mainstream.

The next breakout hit may not come from San Francisco, Montreal, or Tokyo, but may come from somewhere the industry wasn’t paying attention to five years ago.

🏢 Studio Location Matters Less Than It Used To

The rise of remote and distributed development has accelerated this transition.A studio today can:

• Hire artists in Southeast Asia.

• Engineers in Eastern Europe.

• Designers in North America.

• Community managers anywhere in the world.

All without maintaining a large physical headquarters. For developers, this means the job market is becoming increasingly global. Talent is no longer competing only within local ecosystems. Studios are increasingly hiring across borders, and developers are increasingly competing across them.

This creates new opportunities. But it also raises the bar.

The ability to collaborate across disciplines, cultures, and time zones is becoming just as important as technical skill.

📊 More Developers, Fewer Studios

At the same time, another signal is emerging. Recent German industry data showed game industry employment reaching a record high of more than 52,000 workers.

Sounds like good news. But there’s a catch.

While employment grew, the number of game companies fell, small studios declined, and micro-studios declined even faster. Meanwhile, larger studios continued growing.

For years, the dominant narrative was that game development was becoming increasingly democratized with better engines, better tools, and lower barriers to entry. And while that’s still true from a production perspective, running a sustainable game business appears to be getting harder.

There are rising development costs, funding pressure, discoverability challenges, and market saturation. Together, these forces are creating an environment where operational resilience increasingly matters as much as creativity.

In other words, more people are working in games, but fewer companies are employing them.

🏗️ The Great Consolidation Continues

Germany isn’t an isolated case. Across the industry, we’re seeing similar patterns:

• Funding concentrating around proven teams.

• Publishers becoming more risk-averse.

• Service providers expanding.

• Larger studios absorbing talent released through layoffs.

• Investors prioritizing sustainability over aggressive growth.

This doesn’t mean independent studios can’t succeed, as many still do. But the environment is becoming more demanding. Having a great game is no longer enough. Studios increasingly need strong financial discipline, clear positioning, sustainable production models, and early audience traction.

The era of growth at all costs appears to be giving way to an era of survival through operational excellence.

🧩 What This All Adds Up To

Viewed separately, these signals seem unrelated. But together they tell a bigger story. The games industry is entering a new phase where:

• Talent is becoming more globally distributed.

• New development hubs are emerging.

• Geography matters less than it once did.

• Competition is becoming international.

• Growth is concentrating around resilient businesses.

The industry isn’t simply recovering from recent disruption, but it’s reorganizing itself. And that reorganization may ultimately prove more important than any individual layoff announcement or funding round.

🚀 Your Move This Week

Take a moment to ask yourself:

• If your studio hired today, would geography matter?

• Which emerging regions are producing games you admire?

• Are you building a business that can survive industry consolidation?

• How would your studio compete in a truly global talent market?

The answers may reveal more about your future than the latest industry headline.

And as always, we’d love to hear your thoughts. Drop a comment, start a discussion, or send us a message. Game Dev Assembly is your space, our collective space.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

Welcome back to Game Dev Assembly, folks! 👋🎮 Over the last two weeks, Jay Rooney challenged some of the biggest assumptions developers make about marketing. He showed us why marketing failures are often leadership failures, then he unpacked the six-part engine that powers successful game launches. But how do you know if any of it is actually working?

This week, Jay takes us into the numbers that reveal whether your game is building real momentum or quietly drifting toward a launch-day disappointment. The data in this issue may surprise you, and it may change how you think about wishlists, discoverability, and where players actually find games today. And once you see the math, you’ll never see marketing the same way again. Let’s dive in and find out 🚀

Table of Contents

1. A Numbers-First Approach

2. Where Players Find Games in 2026 (It’s Not Where You Think!)

3. What Are Your Wishlists Worth?

4. Working Backward From a Revenue Target

5. Steam’s Concentration Makes All of This Worse

6. What’s Next?

7. About the Author

A Numbers-First Approach

Over the past few weeks, we’ve named the failure pattern behind most under-performing indie launches, and we’ve laid out the six-component marketing engine to remedy it. This week, we’ll get into the math that underpins the engine’s logic.

Most marketing advice for indie devs feels useless because it skips numbers, leaving you instead with basic and generic advice like:

All of which are true, reasonable, useful, and utterly impossible to act on without knowing how much community, how many clips, and which creators calibrated against what your launch actually needs to look like, and expressed in concrete numbers that will be different for each game, for each team, in each genre, and on each platform.

In this issue, we’ll put numbers on all of it. Specifically, we’ll break down three sets of numbers in particular:

1. Where players actually find games now,

2. What wishlists actually convert to, and

3. How to use both to work backward from a defensible revenue target.

If you read nothing else in this series, read this one (with a calculator app open… unless you can do it all in your head, the math whiz that you are).

Where Players Find Games in 2026 (It's Not Where You Think!)

Let’s start with what might be the current decade’s most important shift in game discovery: the players you are trying to reach are not finding new games where we’ve always assumed they’re finding them.

According to Bain & Company’s 2025 global gaming survey of more than 5,000 players worldwide, players said they discovered new games in the following ways:

• 24% through online content creators or influencers

• 14% through social media posts

• 12% through traditional digital storefronts

Did you notice? Players are now twice as likely to discover a new game from a YouTuber, Twitch streamer, or TikToker as they are from the Steam store itself. Meanwhile, social media (the channel most studios spend the most active marketing time on) comes in second. And storefronts, where most organic discovery used to happen, comes in third.

This one single chart should completely restructure the way you think about where to point your marketing engine at. If creators drive twice as much discovery as the Steam store, then your creator and discovery strategy (Component 5 from Part 2 last week) should now be your single largest channel. And if your Steam page is not where players are discovering you, then your Steam page is doing a different job; these days, it’s where players you found somewhere else decide whether to wishlist or buy. Which makes its job not to generate awareness, but to convert it to sales (so optimize it accordingly!)

That distinction makes this the most important tactical decision you’ll make for marketing your game. Clock it now.

What Are Your Wishlists Worth?

Pretty much every studio overestimates this number. Tell me (perhaps in the comments), how many of your pre-launch wishlists actually became first-week sales?

GameDiscoverCo, run by industry analyst Simon Carless, ran the most comprehensive study of this question to date. His team crunched the numbers on every Steam game with at least 25,000 wishlists at launch over a recent twelve-month window. And what did they find?

• The median wishlist-to-Week-1-sales conversion rate was 0.15x — Translation: a game launching with 100,000 wishlists should expect roughly 15,000 first-week sales as its median outcome.

• For games priced over $10, the median drops to 0.10x — So at a $20 price point, those 100,000 wishlists drop to about 10,000 first-week sales.

• For games launching with over 10,000 wishlists (a lower bar), the median is 0.17x — Smaller wishlist pools seem to convert at slightly higher rates, but with much wider variance.

There are two things I want you to take from this. First, the actual conversion rate is far lower than most devs assume. I’ve had founders sit across from me (well… insofar as a video call on a screen is technically “across” from me), not in the least ironically convinced their 30,000 wishlists would translate into 30,000 sales. But the reality, what you should honestly expect, is closer to 4,500… and after Steam’s 30% cut, that leaves only ~$31,500 net at a $10 price point by the end of Week 1.

Second, there’s an insane amount of variance around the median. Carless himself notes the spread runs from roughly 0.01x on the low end to over 1.0x on the high end. Co-op games with viral momentum (PEAK, R.E.P.O., Mage Arena) have even hit conversion rates of 7x to 29x!!! Sequels and “boutique indie” titles, on the other hand, often significantly under-perform the median. So, where will your specific game land within that distribution? Well, that entirely depends on how well the marketing engine’s other five components are firing.

Working Backward From a Revenue Target

Now, let’s make all this math concrete and actually useful for you. Once you have a conversion benchmark, you can stop guessing whether your wishlist count is “good” (which begs the question… “good” relative to what?), and start calculating whether it’s good enough.

Let’s get hypothetical. Imagine, if you will, an indie premium game launching at $20:

• Target: $250,000 gross revenue in Week 1, enough to recover a modest budget and fund the next project.

• Steam’s 30% cut leaves $175,000 net to the studio.

• At $20 per copy, that’s roughly 8,750 units sold in Week 1.

At the GameDiscoverCo median of 0.10x for games priced over $10, you need approximately 87,500 wishlists at launch to hit that target as a median outcome.

That is the actual number. It’s not 30,000, it’s not even 50,000, and it’s certainly not “a lot.” You need roughly 87,500 wishlists. And to actually reach 87,500 wishlists by launch from a standing start, you need to average ~240 daily wishlist additions for at least a year,1 which means you need a live Steam page, an active community, and an operational creator strategy… NOW. Not in the last 90 days before launch.

Now, run this same math for your game:

1. Revenue target,

2. Divided by Steam’s net cut,

3. Divided by your launch price,

4. Divided by your conversion rate benchmark.

You will end up with a wishlist target that is almost certainly much higher than what you’ve been hoping for. But that’s just the way it is, I’m afraid… like it or not, this is the actual gap that you have to close (as a wise person once said, “deal with reality, or reality will deal with you”). And now that you have this number, you also know exactly how aggressive your beat cadence has to be from here to launch.

Are you feeling disheartened right now, or demoralized? Don’t be. I get it, these are daunting numbers and the economics of this industry are absolutely brutal, but don’t let this discourage you. By running this math, you’ve swapped out “we should do more marketing” for “we need to generate roughly 240 net wishlists per day for the next 12 months.” That is a real plan! The first version is not. You’re already ahead of most of your peers, and you should stop for a second and recognize that.

Steam’s Concentration Makes All of This Worse

Here’s one more number to really drive home the gravity of what you’re facing: Steam controls the dominant share of PC digital distribution, with multiple industry analyses putting it at roughly 75% of the global market. This means that there is no “Plan B” for PC distribution at scale. The Epic Games Store, GOG, and Microsoft Store combined do not even begin to approach Steam’s share.

This means two things for your engine:

First, your Steam page is not one of several store pages. It is the store page. The other PC stores can be valuable supplements (particularly Epic for their occasional exclusivity deals), but if you treat Steam as anything less than your primary commercial surface, you’ve completely misread where the money lives.

Second, Steam’s algorithm is not a neutral force. The platform actively prioritizes games with strong launch signals, such as wishlist velocity, review velocity, concurrent player counts, and demo engagement. Games that show up at launch with weak signals get suppressed in the discovery queue, which quickly compounds. Meanwhile, games with strong signals get amplified, which also compounds.

This is why the math at the top of this article is so important. A launch that lands above the median outcome doesn’t just earn the extra revenue from that performance; it also earns visibility, which earns more sales, which in turn earns more visibility. And the reverse is also true: the algorithm buries under-performing launches before the team has time to course-correct.

Your engine has to be running before launch, because launch is the one moment Steam is actually paying attention. After that, the algorithm has decided (and, in most cases, moved on).

What’s Next?

Next week in Part 4, we close the series. We’ll get you into a groovy cadence by showing you what running this engine actually looks like week-to-week, how content and players reinforce each other in a loop, and how to know when to bring in strategic help versus when to keep pushing solo.

In the meantime, if you want a structured way to see how your studio scores across all six components of the engine, that’s what the Game Launch Readiness Scorecard does! Four minutes, free, and it tells you which of the six categories is dragging your score down the hardest: scorecard.spawnpointmarketing.com

And on Tuesday, June 9th at 9:00 AM PT, I’m running a free 60-minute session with Game Dev Assembly — Building a Marketing Engine for Your Game (Without a CMO) — where we’ll walk through the full engine live, with a working Q&A. Sign up here.

See you next week for the finale.

GG,

~Jay

About the Author

Jay Rooney is a founder, marketing strategist, writer, and lifelong gamer working at the intersection of game development and growth. He is the founder of Spawn Point Marketing, a fractional CMO practice serving indie and AA game studios, where he helps founders build the marketing systems that turn good games into successful launches.

He previously co-founded Digi-AI, an AI-native mobile developer he scaled from zero to 700,000 users with no paid advertising, the case study that grounds much of his current work on community-driven, systems-led growth. He teaches graduate marketing communications at Golden Gate University in San Francisco.

His work focuses on pre-production marketing strategy, community building as long-term infrastructure, and the leadership decisions that determine whether a launch succeeds twelve months before it happens. He writes about gaming culture and studio strategy in Game & Word, an award-winning newsletter, and publishes the Spawn Point Marketing Substack on fractional marketing leadership for studios.

He got his start in the games industry by reviewing games for Level Up Media, and also shipped an indie game as a narrative designer (Tavern Simulator), because he believes the best game marketing comes from people who have sat on the dev side of the table.

Closing - Until Next Friday

And there we are, folks! 📈🎮

Now we have put real numbers behind the decisions that determine whether a game gains momentum or disappears into the noise.

Did you find this series useful so far? Which parts made you stop and think? Where did you get an aha! moment? How will you make decisions differently in marketing your game? Feel free to drop a comment and share your thoughts and journey with us.

Part 3 is perhaps the most sobering chapter yet. But knowing the numbers is only half the battle. Get ready for Part 4 next week when Jay unpacks the growth loop for a successful launch, how you can make players part of the marketing engine itself, and how to keep up the momentum long after launch day.

See you next Friday for the finale 🚀

Warm Regards,

Game Dev Assembly Team

Hi everyone! 👋 Welcome back to Part 2 of our mini-series with Jay Rooney 🎮 Last week, we unpacked how most failed launches aren’t caused by bad games but by marketing decisions that happen far too late. This week, we move from diagnosis to framework.

Jay breaks down the Six-Part Marketing Engine that sits behind successful game launches, not flashy growth hacks or post more on social media advice, but the systems, timing, and momentum-building decisions that shape whether players ever discover your game in the first place. You’ll start seeing why some launches compound while others stall out, why certain communities explode organically, and why discoverability is rarely about luck alone. So buckle up because we’re in for a ride. Let’s go 🚀

Table of Contents

1. Intro to the Six-Part Cure

   1. Marketing Timing

   2. Steam Page and Store Presence

   3. Community

   4. Wishlist Momentum

   5. Creators and Discovery

   6. Marketing Leadership

2. Reminder: An Engine, Not a Checklist

3. What’s Next

4. About the Author

Intro to the Six-Part Cure

Last week, we named the disease: most studios don’t have a marketing problem, they have a marketing leadership problem. The decisions that determine whether your launch works are made (or skipped) 12–18 months before launch, and most studios aren’t aware those decisions are being made at all.

This week, we start on the cure.

Before I administer the first dose, I want to be very clear: there is no single tactic that can fix a missing marketing engine. Posting more on TikTok won’t do it, and neither will a bigger trailer budget or a last-minute press push. What works is six interlocking components, each running in parallel, and each starting earlier than will likely feel comfortable. Together, they form the engine. Miss one component, and all the others get weaker. Miss four (which is roughly the median I see), and you’ve shipped a game into the void.

Here are the six components. I’ll go over what they are, why they’re on the list, and what “good” looks like for each of them.

1. Marketing Timing

What it is: When you start marketing your game in earnest, relative to launch.

What “good” looks like: A studio starts making strategic marketing decisions in pre-production, and has written a complete go-to-market plan by the time the game’s vertical slice is done. The Steam page goes live no later than 12 months before launch, and by alpha, the team is consistently shipping content to a defined audience.

What I usually see: A studio “starts marketing” four to six months out. They post a trailer, set up a Twitter, push a Steam page live, and call it a campaign. But by then, the algorithm doesn’t have enough signal to help them, the community doesn’t exist yet to amplify said signal, and they’re asking creators they’ve never spoken with to cover a launch in three weeks.

The bottom line: Games that launch successfully have been visible to players for a year or more before launch, and their studio has shipped demos, grown email lists, built communities, and earned creator coverage long before the button that says Add to Cart goes live. The studios that launch duds were usually trying to compress all of that into the final 90 days. Sorry, but it can’t be done.

Marketing Timing is the most critically important component of the engine. Get this one wrong, and the other five can’t compensate.

2. Steam Page and Store Presence

What it is: Your Steam page, and everything that goes in it: capsule art, screenshots, trailer, description, tags, and all the crucial optimization details most studios never touch.

What “good” looks like: The game’s Steam page goes live early (ideally before vertical slice), and the studio constantly iterates and optimizes it. Capsule art is tested against competitors in the game’s tag set. Oh, and speaking of tags, the team deliberately chose them and didn’t go straight for the auto-suggestions. The description was written for the player skimming the page (not the publisher the studio’s pitching to), and the trailer hooks said player in the first three seconds.

What I usually see: A page filled out in a single afternoon, never revisited, with a capsule designed by whichever developer lost the rock-paper-scissors round.

The bottom line: Your Steam page is not a checkbox. It’s the most-visited marketing asset your game will ever have, and on a platform where the vast majority of PC game revenue is concentrated, it’s the single most important conversion surface in your funnel. Every wishlist, every sale, and every algorithmic boost from Steam itself flows through it. If you treat it as an afterthought, you’ll neglect your highest-traffic landing page and ultimately leave money on the table.

We’ll go deeper on the math behind this in Part 3. For now, let’s move on.

3. Community

What it is: The group of people who care about your game before launch, and who you’ve built a genuine relationship with.

What “good” looks like: The game has a healthy Discord (or comparable space) that the studio started 12 to 18 months before launch, with a core of diehard players who know each other. The team consistently post devlogs, playtests, and AMAs that draw the same faces back, week after week, and the server is bursting with irreverent memes and inside jokes that the devs didn’t write.

What I usually see: A Discord set up six weeks before launch, posted to Twitter, and treated as just another marketing channel. It has maybe 200 members, only 10 of whom are active, and conversation dies whenever a dev isn’t actively prompting it.

The bottom line: Community is not an “audience,” because an “audience” consists of people who merely consume what you make. A community, on the other hand, is people who talk to each other about what you make. The difference shows up at launch: a community converts into sales, amplifies your announcements, defends you in hostile subreddits, and forgives you for screwing up. Audiences, at best, just scroll past (and at worst, they pile on).

This is the second most important component of the engine, because it’s the only marketing asset that truly compounds. Every other component produces linear returns, but a community at scale produces exponential ones: players bring players, who bring more players, who in turn bring even more players. But the compounding only kicks in with a long enough runway, which is why studios that start communities at three months before launch never see the curve bend.

4. Wishlist Momentum

What it is: Not just your wishlist count, but your wishlist trajectory: how fast it’s growing, when it’s growing, and how much of it you should expect to convert at launch.

What “good” looks like: The studio knows their wishlist count, knows their Week 1 conversion expectation (and where that benchmark comes from), and is actively running content beats designed to drive the trajectory upward in the final 90 days.

What I usually see: A wishlist count that someone occasionally glances at, with no model behind it. No idea what 25,000 wishlists translates to in launch revenue, and no idea whether they’re tracking ahead of or behind their launch target.

The bottom line: Wishlists are one of those metrics studios are always told to optimize, to the point of it being increasingly called a vanity metric. Well, they’re not a vanity metric, and they’re actually quite important! But they’re not a crystal ball, either. They’re a forecasting tool; a highly imperfect one, but useful nonetheless. Industry conversion benchmarks let you work backward from your revenue target to know how many wishlists you need by launch, and from there you can work out how aggressive your content cadence needs to be in the final months. Without that math, you’re just guessing whether you’re on track… but with it, you can plan.

As with the Steam page stats, we’ll get into the actual conversion numbers and what they mean for your own revenue forecasting in Part 3.

5. Creators and Discovery

What it is: Your relationship with the content creators who will shape how players hear about your game.

What “good” looks like: The studio has a list of creators in the game’s genre that they’ve been paying attention to for months, and with whom they’re building genuine relationships (no cold pitches!). The marketing team has developed a clear plan for how creators will get their hands on the game (whether through Keymailer, Lurkit, Terminals.io, or direct outreach), what assets they need, and what coverage windows they’re targeting around demos, Next Fest, and Launch.

What I usually see: The studio sends batches of cold emails to a spreadsheet of 200 YouTubers they built from a Google search the week before launch, and get zero responses. There’s no press kit, they’ve paid $5,000 for a PR agency, blast a templated press release to its entire media list, and the founder’s confused as to why “press doesn’t cover indie games anymore.”

The bottom line: Press isn’t dead, but for indies and AA studios, content creators have replaced it as the dominant game discovery layer. Bain’s consumer research on game discovery puts creator-driven discovery, as a share of how players find new games to play, at 24% (over twice as high as through digital storefronts!). This means your Next Fest performance, launch week visibility, and long-tail community growth are now downstream of creator coverage in a way they weren’t five years ago.

Studios who secure creator and media coverage for their games don’t necessarily have the biggest PR budgets… but they do build real relationships, for months in advance, with creators who actually play games in their genre.

6. Marketing Leadership

What it is: A single, named person who owns marketing strategy as their primary responsibility, not as a side hustle.1 Yes, one person (not “everyone does a little marketing!”), and it has to be an actual person (not “we’ll figure it out together”).

What “good” looks like: The studio has someone on its team whose job is to make strategic marketing decisions early enough for the other five components to actually function. This person can be a publisher partner, a part-time hire, or a fractional CMO (oh, hi!). What they cannot be is “eh… we’ll all kind of think about it.”

What I usually see: The studio has distributed marketing across the entire team as collective optional homework. Everyone is responsible, which means no one is. Decisions get deferred until they default into “we have to launch in 90 days, what do we do?”

The bottom line: This is probably the most neglected component amongst the studios I talk to, which is a problem because this is the one that determines whether the other five even happen. The marketing leader operates the marketing engine. Without an operator, the engine sits in the garage; but with one, even a modest setup can yield compounding returns.

As for why this is the component that most studios are most reluctant to address? If I’m being blunt, it’s because addressing it means admitting that the founder/creative director/producer wearing the marketing hat at 11pm on a Tuesday (again) is not sustainable. But it rarely is.

Reminder: An Engine, Not a Checklist

Most marketing for indies guides make the mistake of presenting these as a list of things to do. But they aren’t; they’re an engine. I deliberately chose that term, because like an actual engine, all the components reinforce each other:

• Strong Marketing Leadership makes early Marketing Timing possible.

• Early Marketing Timing gives the Steam Page time to accumulate algorithmic signal.

• A live Steam Page captures wishlists from players found through Creators and Discovery.

• Engaged Community members become the players who clip moments that get picked up by Creators.

• All while Wishlist Momentum gives you the trajectory data to know whether the engine is actually running.

If you pull any one of these out, the others get weaker. And if you add them in the wrong order (say, by building a Discord before you have a Steam page or a defined audience), then the energy you input dissipates instead of compounds.

This is also why common fixes like hiring a community manager or stepping up press outreach rarely fix underperforming launches on their own. The engine is missing other components; adding more horsepower to one cylinder doesn’t help when the other five aren’t firing at all.

What’s Next

Next week in Part 3, we’ll get into the math behind the engine: the actual numbers that should drive your decisions on where to prioritize your limited resources. We’ll break down the share of game discovery sources, demystify conversion benchmarks and revenue concentration (important stats that most marketing advice skips), and learn how to use them to figure out what to focus on first.

In the meantime, if you want to see how your studio scores across all six of these components right now, the Game Launch Readiness Scorecard does exactly that. It’s free, takes about four minutes, and gives you back a tier rating, a numerical score, and your top three recommendations for what to fix first: scorecard.spawnpointmarketing.com

And on Tuesday, June 9th at 9:00 AM PT, I’m running a free 60-minute session with Game Dev Assembly — Building a Marketing Engine for Your Game (Without a CMO) — where we’ll walk through this engine live, with a working Q&A. Sign up here.

See you next week for Part 3.

GG,

~Jay

About the Author

Jay Rooney is a founder, marketing strategist, writer, and lifelong gamer working at the intersection of game development and growth. He is the founder of Spawn Point Marketing, a fractional CMO practice serving indie and AA game studios, where he helps founders build the marketing systems that turn good games into successful launches.

He previously co-founded Digi-AI, an AI-native mobile developer he scaled from zero to 700,000 users with no paid advertising, the case study that grounds much of his current work on community-driven, systems-led growth. He teaches graduate marketing communications at Golden Gate University in San Francisco.

His work focuses on pre-production marketing strategy, community building as long-term infrastructure, and the leadership decisions that determine whether a launch succeeds twelve months before it happens. He writes about gaming culture and studio strategy in Game & Word, an award-winning newsletter, and publishes the Spawn Point Marketing Substack on fractional marketing leadership for studios.

He got his start in the games industry by reviewing games for Level Up Media, and also shipped an indie game as a narrative designer (Tavern Simulator), because he believes the best game marketing comes from people who have sat on the dev side of the table.

Closing - Until Next Friday

And just like that, the engine is starting to take shape 🚀

Part 2 moved us beyond vague marketing advice and into structure. Jay laid out the six interconnected components that sit behind successful launches, and perhaps more importantly, showed why most studios struggle when even one of those pieces is missing.

If Part 1 was the wake-up call, this was the blueprint.

But next week is where things get even more practical. In Part 3, we move into the numbers behind the engine: where players actually discover games in 2026, what wishlists truly convert into, and how studios can work backward from revenue goals instead of relying on guesswork and hope.

And fair warning… some of those numbers may completely change how you think about launch planning. Stay tuned for next week’s issue. The math behind discoverability is coming 👀

Warm Regards,

Game Dev Assembly Team

Howdy folks 👋 and welcome back to another edition of Game Dev Assembly Industry Signals 🎮✨ For years, the industry chased more. We’re talking bigger worlds, bigger teams, bigger content pipelines, and bigger monetization systems.

And now? Players value ownership like the good ole’ days, focused experiences, and memorable design. Developers are rethinking how they build communities, distribute games, and survive in an increasingly crowded market.

This week, we’re going from subscription fatigue and direct-to-player ecosystems, to the rise of retro aesthetics, regional dev scenes, and games that actually respect player time. As always, we’re here to connect the dots so you can stay ahead of where the industry is heading 🚀

💸 Subscription Fatigue Is Becoming a Real Problem

Players are starting to hit a wall. Not just with Netflix and Spotify, but with gaming subscriptions too. Services like Microsoft’s Game Pass helped redefine player expectations over the last few years. But now, more developers are openly discussing the downside:

• Lower perceived value per game

• Faster player churn

• Less ownership mentality

• Shorter engagement windows

Meanwhile, more players are returning to buying games outright, collecting physical editions, and supporting games directly through platforms like Patreon and Kickstarter.

More and more do players want experiences they feel they own, not endless libraries they barely touch.

🛒 Direct-to-Player Models Are Quietly Growing

A growing number of indie studios are trying to reduce dependence on storefront algorithms entirely. Instead of relying only on Steam, they’re building email lists, discord communities, patreon memberships, direct merch ecosystems, and web shops.

Why?

Because storefront visibility is volatile.

Owning your audience is becoming more valuable than renting attention from platforms. Multiple indie developers discussed rising wishlist volatility and unpredictable discovery swings tied to Steam visibility cycles.

In a nutshell, audience ownership is becoming a competitive advantage.

🎮 Retro and Low-Spec Design Is Quietly Winning Again

One of the strongest under-the-surface shifts right now is games are becoming less obsessed with technical realism. Instead, we’re seeing growing success around retro aesthetics, stylized visuals, low-spec compatibility, and lightweight performance.

Why?

Because players want readability and vibe, hardware costs remain high globally, Steam Deck optimization matters more, and portability is increasingly influencing design.

Games with intentional simplicity are increasingly standing out in a sea of hyper-polished realism.

So remember, the direction in which you take your art is outperforming raw graphical power.

🧠 Players Are Rewarding Games That Respect Their Time

A growing frustration growing across player communities is that games that feel like chores.

Live-service fatigue is becoming more visible:

• battle pass exhaustion

• infinite progression systems

• daily-login pressure

• bloated open worlds

Meanwhile, tightly scoped experiences are earning stronger player goodwill. This is one reason games like Balatro, Dredge, and Dave the Diver resonate so strongly.

They feel focused, intentional, and respectful of player time.

The drive home message is players are gravitating toward games with stronger pacing and lower friction.

🌍 Regional Development Scenes Are Becoming More Influential

This week also reinforced a longer-term shift, which is that more breakout development scenes are emerging outside traditional hubs.

We’re seeing increasing visibility from Latin America at Gamescom and Game Developers Conference, Southeast Asia (such as Black Myth: Wukong), Eastern Europe (such as Manor Lords), Turkey, and Africa.

Smaller teams in these regions are benefiting from lower production costs, online distribution, creator ecosystems, and global communities.

And importantly, they’re often bringing fresher creative perspectives.

The long and short is, game development is decentralizing culturally and geographically.

⚠️ Infinite Content Is Losing Its Appeal

For years, the industry chased scale with endless maps, infinite crafting, and hundreds of hours of content.

But players increasingly talk about wanting memorable experiences, intentional design, emotional payoff, and games they can actually finish.

Completion is becoming emotionally valuable again, and it’s changing pacing decisions, game length, and content strategy.

In a nutshell, more content no longer automatically means more value.

🚀 Your Move This Week

Ask yourself:

• Does your game respect player time?

• Are you building an audience you actually own?

• Would your game still stand out without graphical fidelity?

• Are you designing for endlessness, or memorability?

Why don’t you share your answers with us either by dropping a comment or shooting a message to us? This is your game dev space; our game dev space.

The industry used to optimize for more scale, content, systems, and monetization. But if we put ourselves in players’ shoes, they’re searching for something smaller and more meaningful instead. If this edition resonated with you, feel free to hit like and share it with your teammates. We always welcome your presence and thoughts.

Until next week, keep creating and stay awesome.

Warm Regards,

Game Dev Assembly Team

🎤 The Complete Game Marketing Roadmap: From Idea to Post-Launch Success

Don’t forget to tune in to our free event this Saturday with from .

📅 May 23, 2026 (Saturday) | ⏰ 10 AM ET | Free

GRAB YOUR TICKETS TODAY

Hello everyone! 👋🎮 We’ve officially launched our first mini-series focused on solving real problems game developers go through. Over the next few weeks, we’re teaming up with Jay Rooney, founder of Spawn Point Marketing, former indie dev, and a marketer who scaled a startup to 700,000 users without paid ads, to break down why so many good games still fail to break through, and what studios can actually do about it.

In Part 1, Jay dives into the uncomfortable reality behind failed launches: most studios don’t have a marketing problem; they have a marketing leadership problem. If you’ve wondered why great games still disappear into the void, this issue is going to hit hard.

And this is only the beginning. The next parts will explore the marketing engine itself, the metrics that matter, and the workflows studios can use to build momentum before launch. Buckle up; this is going to be an exciting ride!

Roughly 20,000 games were shipped on Steam in 2025. Of these, almost half got fewer than ten reviews, and around 2,200 got zero.

When this happens to a studio, their first instinct is usually to blame the market, however leadership decides to frame it:

“Too many releases.”

“Too much noise.”

“The algorithm decided we didn’t matter.”

Those are comforting narratives, and if nothing else, the diagnosis feels true. It even has supporting data! There really are more game releases than all the world’s players could possibly play through, at a time when audience attention really is more fragmented than ever before. And although it feels dirty to say so bluntly, Steam really does pick winners.

But all those excuses (and again, I hate to be so blunt, but they really are just excuses) point at the wrong problem.

Most studios don’t have a marketing problem, they have a marketing leadership problem. Chances are, if you’re reading this article, so do you. And until you see the difference, no amount of tactical advice is going to save you from the brutal economics of a market that sees over 20,000 annual launches (of which nearly half are functionally invisible to their consumers).

This is Part 1 of a four-part series on why game marketing fails for studios that deserve better, and what to do about it. Today is the diagnosis. Over the next three weeks, we’ll build the cure: a repeatable, scalable marketing system, honed through my own experience launching and scaling into crowded markets, and sharpened by both the latest industry data and my deep knowledge of video games and the people who play them.

Table of Contents

1. Why Most Indie Games Fail After Spending Years in Development

2. Why Posting More on Social Media Doesn’t Grow Your Game

3. Why Shareable Gameplay Moments Matter More Than Features

4. The Hard Truth? Good Games Fail all the Time

5. It’s a Leadership Problem, Not a Marketing One

6. What’s Next?

7. About the Author

Why Most Indie Games Fail After Spending Years in Development

Here’s a rough picture of almost every failed indie launch, in slow motion, from start to finish:

A team comes up with a brilliant game idea, and spends two to four years heads-down on building it. Throughout this time, marketing is nothing but a vague “future problem.” Finally, around six months out from launch, someone (usually whoever has the least to do that week) says, “Um… you guys? We should probably start marketing this.” So a Twitter/X account appears, and a Discord server goes up. The team posts screenshots and stitches together a trailer. The Steam page goes live, but it’s treated as a checkbox: filled in, then forgotten. Next Fest comes around, so the team submits a demo. And then, the moment of truth: launch day arrives. The team gathers around a projector in the conference room, staring at the wishlist counter and the review page and the dashboard… refreshing… refreshing… refreshing…

Then, 48 hours pass and the launch window closes. The algorithm moves on, and discoverability decays. Eventually, the team moves on to the next project, telling themselves they’ll “do marketing better next time.”

Every step in that sequence seems reasonable in isolation. But together, they form the most predictable failure pattern in the industry. The trap isn’t that any individual decision was wrong, it’s that nobody ever made the strategic decisions that determine whether marketing can even work to begin with. Those decisions were just defaulted into.

This is the pattern. It’s structural. It constantly plays out, in thousands of launches each year. And it’s why the same mistakes keep repeating across studios that have nothing else in common.

Why Posting More on Social Media Doesn’t Grow Your Game

When studios in this trap ask for help, the most common advice they get is some version of “post more.” How many of the following variations of the same basic advice have you been given, or even given to others?

• Make more clips!

• Be more active on Twitter/X!

• Try TikTok!

• Get on Bluesky!

• Post your dev logs on YouTube!

This advice has become so universally repeated, for so long, that we don’t even notice it anymore. It’s become as invisible as the very air we breathe. It also doesn’t work, not because posting is bad (it isn’t; in many cases, you really should post more!) but because posting is a tactic, and the people giving this advice are putting tactics before strategy. Or, to use a game dev analogy: they’re trying to animate unrigged models, or writing dialogue before finalizing the character sheets.

A sound marketing strategy answers, at the very minimum, the following questions:

• Who is this game for?

• Where do those people already gather?

• What about the game will get them to lean in?

• What do we need from them at each stage of awareness?

Tactics are the things you do after you answer those questions. Posting more on social media without an underlying strategy to guide you is like throwing darts in the dark and being told you just need to throw faster.

If your TikTok clips aren’t converting, you don’t have a content problem, you have a positioning problem. And not even the most aggressive posting cadence will fix it. Unfortunately, this common-sense diagnosis is not common knowledge amongst indie game developers; the generic and inapplicable advice has proliferated so thoroughly it has become the default (“My wishlists must be flat because I’m not posting enough!”). And so it doesn’t even occur to indie developers that the actual problem is upstream of the content they post, and that they need to answer the above five questions at the start of development (not after the trailer drops); and the worst part is, it isn’t even their fault! They just don’t know, because nobody ever told them (or, if they have heard, they don’t believe it because it goes so against the conventional knowledge that it feels counterintuitive).

Fortunately, this is starting to change, and I do see an increasing awareness in the indie scene that marketing issues need to be addressed, on a strategic level, much earlier in the development cycle than has long been the norm. But this is bitter, hard-earned insight, paid for in failed launches and disbanded teams. And, of course, knowing you have to address marketing early is a different beast than knowing how to address it… which means that, in the absence of standardized frameworks and best practices, this knowledge is also painfully earned through trial-and-error, lost revenue, and studio closures.

If I can help just one talented, hardworking team avert disaster by avoiding the mistakes I see teams make time and time again, this series will have done its job. And if I can help make marketing-as-development-discipline the norm, and not the exception? …Well, that would be my greatest contribution to this medium and this industry that I love so dearly.

Why Shareable Gameplay Moments Matter More Than Features

There’s a related failure mode that runs alongside the tactics one: studios market what they built, not what players will share.

When a developer talks about their game, they usually lead with the systems they’re proud of. Maybe they want to show off their procedural generation’s scale and granularity, or the mind-bogglingly complex and intertwined dialogue tree they wrote. Or maybe they’re proud of the near-infinite depth their crafting system enables.

I’m not denying how hard it is to build these things, and the team should feel proud about building them. But, that being said…

Players don’t share systems, they share moments. Think about the fondest memories from your favorite games: hearing “Yearnings of the Wind” in Chrono Trigger for the first time, pulling off a successful six-hour raid in World of Warcraft after weeks of planning, seeing Ganondorf turn into Ganon in Ocarina of Time, finally defeating Malenia in Elden Ring, or the first time you saw Aerith’s death scene in Final Fantasy VII.

Now, look at the types of moments other players share online. Hearing that iconic music track for the first time… an unexpected co-op victory with someone on the other side of the planet… obtaining that 1 in 10,000 legendary drop… that one boss that made them repeatedly swear out loud… a scene that makes them cry every time they play through it… that is what players clip, screenshot, and recommend in a Discord server at 1am.

The gap between what devs build their marketing around and what players actually transmit to each other has become one of the industry’s most expensive blind spots. If a game has a brilliant feature set but zero shareable moments, it will be all but completely invisible to the world. But another game with modest features and one unforgettable 30-second sequence will spread like wildfire.

You don’t have to dumb your game down. That’s not what I’m suggesting, so don’t get it twisted; this isn’t about that. But you do have to be honest with yourself about what travels in 2026, and you have to be deliberate and intentional about designing it in your game.

The Hard Truth? Good Games Fail all the Time

Again, I hate to be so blunt here, but an industry in as deep a crisis as ours owes it to itself to discuss this honestly and with clear eyes, no matter how painful the truth undeniably is.

A game can be genuinely good (well-designed, well-made, and well-reviewed… at least, by the few people who play it) and still fail commercially. This happens constantly, and it is the most demoralizing manifestation of our industry’s overall failure pattern, because it punctures the developer’s last line of defense: if I just make the game good enough, the rest will sort itself out.

[Narrator Voice:] It will not sort itself out.

I’m sorry, but the data is unequivocal on this. Industry analysis of 2024 Steam releases found that roughly 85% of indie revenue went to the top 10% of titles. On Steam, the middle does not exist. There is the top tenth, and there is the long tail. There is nothing in between.

What separates the games that make it into that top tier from the ones that die in obscurity is almost never “the better game won.” Both groups contain great games. What separates them is that the winners had a marketing engine running for over a year before launch. They had:

• A Steam page accumulating wishlists,

• A community shipping clips,

• Relationships with creators who were committed to covering the launch, and

• Momentum the algorithm could detect.

The studios that hit launch day with no engine in place don’t lose because their game is bad. Often, and tragically, they lose because by the time launch arrives, the launch is already over. It had been over for months. Specifically, the decisions that determine launch outcomes are made 12 to 18 months earlier. Most studios aren’t aware those decisions are being made at all, but they are being made… even if it’s not by them (and lest we forget: not making a decision is, in and of itself, a decision).

It’s a Leadership Problem, Not a Marketing One

Now, we can finally name what’s actually happening.

When marketing fails for a studio, it almost never fails because the social media manager wasn’t trying hard enough, or because the trailer wasn’t cut quite right. It fails because nobody in the studio was making strategic marketing decisions early enough for any of those tactics to work. Positioning, audience definition, channel strategy, community architecture, and launch sequencing are all leadership decisions, and most studios decide them by default, by accident, or not at all.

This is the leadership problem. And it’s specifically a marketing leadership problem, because every studio has plenty of leadership in other domains. The creative director, the technical lead, and the producer are all leading. But there is rarely a person whose job is to strategically think about how this game finds its audience, and to make decisions accordingly with enough lead time to matter.

And no, the fix is not to hire a CMO. Most studios at this stage cannot afford one and don’t need one. The fix is to name the role, even if the role is held by the founder for a few hours a week. Someone has to own this, the way someone owns engineering, art, design, and production. If nobody owns it, the work that produces a successful launch never gets done.

What's Next?

Now that I’ve diagnosed the problem, the rest of this series will walk through the cure.

In Part 2, we’ll lay out the six components that make up a working marketing engine: the things a studio needs in place long before launch, and what “good” looks like for each.

In Part 3, we’ll dig into the numbers underneath the engine: what conversion rates, discovery sources, and revenue patterns actually mean for how you should prioritize your time.

And in Part 4, we’ll close with the cadence and the signals: what to do every week to keep the engine running, and how to tell whether it’s actually working.

If you want a head start, I built a free Game Launch Readiness Scorecard that diagnoses where your studio sits across all six components of the engine in about four minutes. It exists because so many of the conversations I have with studio founders go better when we both have a shared map of where the gaps are. You can take it at scorecard.spawnpointmarketing.com.

And if you want to talk through the system live, I’m running a free 60-minute session with Game Dev Assembly on Tuesday, June 9th at 9:00 AM PT — Building a Marketing Engine for Your Game (Without a CMO). We’ll go deeper on the engine itself and run a Q&A. Sign up here.

See you next week for Part 2.

GG,

~Jay

About the Author

Jay Rooney is a founder, marketing strategist, writer, and lifelong gamer working at the intersection of game development and growth. He is the founder of Spawn Point Marketing, a fractional CMO practice serving indie and AA game studios, where he helps founders build the marketing systems that turn good games into successful launches.

He previously co-founded Digi-AI, an AI-native mobile developer he scaled from zero to 700,000 users with no paid advertising, the case study that grounds much of his current work on community-driven, systems-led growth. He teaches graduate marketing communications at Golden Gate University in San Francisco.

His work focuses on pre-production marketing strategy, community building as long-term infrastructure, and the leadership decisions that determine whether a launch succeeds twelve months before it happens. He writes about gaming culture and studio strategy in Game & Word, an award-winning newsletter, and publishes the Spawn Point Marketing Substack on fractional marketing leadership for studios.

He got his start in the games industry by reviewing games for Level Up Media, and also shipped an indie game as a narrative designer (Tavern Simulator), because he believes the best game marketing comes from people who have sat on the dev side of the table.

Closing - Until Next Friday

And there we are, folks! We have kicked this series off with a bang. Did you expect it to be this blunt and juicy? Has it made you step back and think about how you’re planning and executing marketing during the design phase?

Part 1 is the wake-up call. Great games fail because marketing is treated like a last-minute task instead of a core leadership function. Jay has laid out the real problem behind invisible launches, flat wishlists, and games that disappear despite years of hard work. But now that the diagnosis is clear, next week we move into the cure.

In Part 2, we’ll break down the six-part marketing engine that successful studios build long before launch day arrives, from community and creator relationships to Steam presence, wishlist momentum, and marketing timing itself.

Stay tuned for next week’s issue. This is where the system starts coming together.

Warm Regards,

Game Dev Assembly Team

Hi everyone, and welcome to another edition of Industry Signals by Game Dev Assembly! 🎮✨The game space is entering a different phase right now. AI is moving deeper into development workflows, funding conditions are tightening, and studios across the industry are being forced to rethink how games are built, staffed, and sustained long-term. There’s a noticeable shift toward leaner teams, faster production cycles, and more sustainable business models, and the ripple effects are showing up everywhere from tooling to publishing strategy.

In this week’s edition, we’re breaking down the biggest signals shaping where game development appears to be heading next. Let’s get into it 🚀

🤖 AI Adoption Is Moving From Experiment to Core Pipeline Infrastructure

Major publishers and platform holders are now publicly positioning AI as embedded production tooling rather than optional research and development.

🔍 Key Signals

• 🕹️ Sony PlayStation AI roadmap via Tom’s Guide: Sony confirmed internal AI tooling for facial animation, QA, modeling, and workflow automation across PlayStation Studios.

• 💭 PC Gamer coverage of Sony AI strategy: Industry skepticism remains high despite executive optimism.

• 🛠️ Unity AI Open Beta analysis via Creative Bloq: Unity is aggressively integrating AI directly into editor workflows, signaling tooling competition with Unreal and Godot.

• 📈 Reuters report on Morgan Stanley AI forecast: Analysts estimate AI could reduce development costs by ~50% and generate $22B in industry profit upside.

Strategic Interpretation

In a nutshell, the industry is no longer debating whether to use AI. It’s now focused on where AI creates the most value across the development pipeline. Studios are balancing automation with the need to maintain creative identity, while smaller teams are increasingly able to compete at a much higher level thanks to faster workflows, leaner production pipelines, and lower development costs enabled by AI tools.

Expect:

• Faster prototyping cycles.

• Reduced outsourcing spend.

• Smaller content teams.

• Increased emphasis on creative direction and systems design over asset throughput.

💰 The Funding Market Is Favoring Leaner, Mid-Budget, High-ROI Games

The strongest investment signal this week is the continued institutional pivot away from bloated AAA risk profiles toward efficient indie and AA production.

🔍 Key Signals

• 💵 $100M indie fund led by Hooded Horse CEO via GamesRadar: A new $100M fund is targeting indie and strategy projects with sustainable budgets and breakout potential.

• 🧾 Game Developers Turn to Self-Funding via Games.gg: Developers are increasingly self-financing projects as publisher capital tightens.

• 🏗️ Indie Devs News May 2026 via MEAN CEO: Studios are moving toward contractor-heavy operating models and lean internal teams.

• 🚪 Ivy Road shutdown coverage via GamesRadar: Even prestige indie teams with proven talent are struggling to secure financing.

Strategic Interpretation

Investors are becoming far more selective, with growing preference for studios operating in proven niches, maintaining lower burn rates, and shipping games faster. There’s also stronger demand for projects with evergreen monetization potential, community-driven growth, and PC-first business models that offer longer-tail revenue opportunities and lower distribution risk.

Genres currently benefiting:

• Strategy

• Survival crafting

• Roguelites

• Cozy/lifestyle

• Extraction/systems-heavy multiplayer

• Mod-friendly games

📉 Layoffs Are Still Defining Industry Psychology

Despite isolated financial wins, the workforce environment remains unstable.

🔍 Key Signals

• 📊 2026 State of the Game Industry layoff data via GameDeveloper.com: 28% of developers experienced layoffs over the past two years. Nearly half remain unemployed.

• 🎤 GDC 2026 industry trends summary: Designers were among the hardest-hit roles.

• 🏢 Build A Rocket Boy layoffs via PC Gamer: Another major restructuring around the troubled MindsEye project reinforces investor intolerance for under-performing AAA bets.

• 💥 Wikipedia summary of 2022–2026 game industry layoffs: AAA development costs exceeding $200M are increasingly unsustainable.

Strategic Interpretation

Studios are optimizing for leaner operations by maintaining smaller permanent teams, relying more on external production partnerships, extending financial runway, and prioritizing safer IP bets alongside reusable live-service ecosystems. As a result, the industry is placing greater value on adaptable, multidisciplinary developers who can operate across multiple areas of production.

🧩 Unreal Continues Gaining Momentum While Unity Still Repairs Trust

Unity’s AI push is meaningful, but trust damage from prior pricing controversies continues influencing engine choices.

🔍 Key Signals

• 📜 Unity historical licensing backlash overview: Continued migration toward Unreal and Godot is still being discussed in industry analysis.

Strategic Interpretation

The engine landscape is becoming more clearly defined across the industry. Unreal continues to dominate high-fidelity AAA and AA production with strong enterprise credibility, Godot is gaining momentum among indie developers through its open-source model and growing community trust, while Unity remains highly influential in mobile development as it pushes further into AI-assisted workflows and editor experimentation.

🌐 Publishers Are Prioritizing Evergreen Franchises and Live Ecosystems

The strongest financial performers remain long-tail ecosystems.

🔍 Key Signals

• 📈 EA FY26 performance summary: EA cites strong results from FC, Apex Legends, and Battlefield.

Strategic Interpretation

Publishers are increasingly prioritizing games that can generate long-term recurring revenue through seasonal engagement, user-generated content ecosystems, and strong cross-platform retention. Existing player communities have become one of the industry’s most valuable assets, with publishers favoring projects that can sustain engagement well beyond launch rather than relying solely on one-time sales.

Greenlight conditions for new IP remain difficult unless:

• Development scope is controlled.

• Marketing is community-native.

• The concept is streamer/social friendly.

⚖️ Regulation and Consumer Ownership Pressure Are Growing

Game preservation and ownership rights are becoming a bigger political issue.

🔍 Key Signals

• 🛑 Stop Killing Games movement overview: EU and California efforts are pushing publishers toward clearer end-of-life obligations for online games.

Strategic Interpretation

The growing focus on consumer ownership and game preservation could push publishers toward stronger offline fallback support, greater accountability around live-service shutdowns, and clearer digital ownership policies. Over time, preservation-friendly design may also become a strategic advantage as regulators and players place increasing pressure on how online games are maintained and retired.

👀 Most Important Watchlist Items Over Next 90 Days

Watch closely:

• AI-native production pipelines.

• Unity AI adoption metrics.

• Further consolidation or closures.

• Funding announcements for mid-budget games.

• Regulatory movement around live-service shutdowns.

• Labor organization and unionization activity.

• Unreal vs Godot adoption in indie space.

🚀 Your Move This Week

• 🤖 Audit where AI could meaningfully reduce production friction in your current workflow.

• 💰 Re-evaluate project scope and burn rate against today’s tougher funding environment.

• 🎮 Focus on mechanics and community features that encourage long-term retention, not just launch-day traction.

• 🛠️ Reassess your engine and tooling strategy based on your studio’s actual long-term needs.

• 🌱 Prioritize flexibility, as multidisciplinary skills and lean production models are becoming increasingly valuable across the industry.

• 👀 Keep a close eye on AI tooling, funding shifts, and live-service regulation, as these are likely to shape the next major wave of industry change.

Then share your findings with us. Drop a comment in this edition or send us a message when you have done any of the above. Game Dev Assembly is your space; our collective space.

🎤 The Complete Game Marketing Roadmap: From Idea to Post-Launch Success

Most games don’t fail because they’re bad. They fail because no one sees them.

We’re doing a live session with from on how to fix that.

📅 May 23, 2026 (Saturday) | ⏰ 10 AM ET | Free

BOOK YOUR TICKET

And that’s it for today. Stay tuned for the next industry signals where we bring you the latest news and deliver it in a meaningful and relevant way. If you feel this edition can benefit your teammates or anyone you know in the games industry, feel free to pass it on.

Warm Regards,

Game Dev Assembly Team

Good day everyone! 👋🎮 How are we all doing? Welcome to yet another Game Dev Assembly edition, and this one is truly magical ✨ What does it really take to build a game from scratch? For Vishnu, it started with curiosity, a YouTube video, and zero experience in Unity. What followed was a journey filled with experimentation, failed optimizations, frozen screens, late-night debugging ☕💻, and eventually, published games on the Play Store. All of this happened because he decided to stop consuming and start creating. If you want to learn how he built two games with Unity, dive in and read the latest issue🕹️

Table of Contents

1. How It All Started

2. My First Unity Game

3. Where I Got Stuck

4. My Second Unity Game

5. Things I Wish I Knew Before I Started

6. Practical Advice for Beginners

7. List of Tools and Resources I Used in My Journey

8. Parting Words

9. About the Author

How It All Started

Since childhood, I’ve been very fond of playing games and used to spend hours doing it. When I started my career as a developer, I wanted to create a game of my own. That’s when I thought, ‘Hey let’s try to make one!’

So in 2023, I built my first trial game in Kotlin language. It’s just a simple game developed using Kotlin code in Android Studio IDE. During that stage, I understood that it wasn’t the right approach in creating a mobile game. It was difficult to add graphics as the whole game depended on the code. The drawbacks of the game were:

• It wasn’t responsive to different mobile sizes

• It wasn’t easy to add graphics

• It was completely dependent on code, so the code became complex

• Integrating with other features were a bit difficult

Then I researched how to create a high-quality mobile game. This helped me understand there are multiple game engines to build such games easily. One of the most common game engine is Unity. There are many other engines, but Unity is the most selected one by developers and is beginner-friendly.

I had no experience in Unity or C#, which is the backend code that’s compatible with Unity. So I started learning about Unity until I realized it’s better to try something out in it than watching learning videos. Once you try Unity, you can learn on the go.

And because of this, my first two games were born.

My First Unity Game

My first Unity game was Godspeed. It’s an endless runner game similar to subway surfers/temple run. But what makes it unique from others is that it has a career feature where players can try to complete 20 exciting levels. The journey of building Godspeed from scratch, for someone who has zero knowledge in Unity, was simple. I learned how to make this game using a YouTube video by Jimmy Vegas. This video clearly explains how to build a game from scratch.

🔸Choosing Whether To Build For Computer or Mobile

First, you need to finalize whether you’re building a computer or mobile game, and whether it is a 2D or 3D game. Unity has multiple templates that you can select based on your requirements. Once you select the template, Unity prepares the project and handles all dependency and compatibility configurations (things we need not be concerned about). I selected the 3D mobile template. What I learned from this game is that we have everything available free of cost to create a simple game.

🔸The Design Challenge

For the design, I needed good-quality graphics, from the environments to the obstacles, characters, and audio. I used the Unity Asset Store, where you can import assets directly into Unity for free (though paid options are also available).

🔸Main Character and Animations

For the main character, I used Mixamo. Since my game is a running game, I needed a character with a running animation. Mixamo made this incredibly easy. You can download characters, attach animations like running, walking, jumping, or cheering, and use them directly in your game, all for free.

Next, I wanted the character to actually move, not just play an animation. That’s where a C# script comes in. I created a script and attached it to the character so it would move forward. Even though I have coding experience, I had no experience in C#, so I used ChatGPT to generate the script.

🔸All About UI

Then came the user interface. In Unity, all UI elements sit inside something called a Canvas. This is essentially the front end; the part users see and interact with. When a user clicks a button, the action is handled by backend logic written in C#. Connecting the frontend and backend is straightforward in Unity, mostly involving simple drag-and-drop.

🔸Handling Data

For storing player data and scores, I used Firebase Realtime Database. I chose Firebase because it’s beginner-friendly and integrates easily with Unity. It stores data in a simple key-value format, which works well for games.

🔸Revenue: Something Nobody Talks About

One common misconception I had to learn early on is about revenue. We don’t earn money from downloads. Revenue comes from in-app purchases or ads. I integrated Unity Ads into the game using a C# script (again with help from ChatGPT). Once integrated, Unity Ads handles everything, from fetching ads to displaying them.

🔸Game Testing

Testing was another important step. While Unity allows you to test features within the editor, real insights only come when you test the game on an actual device. This is where you truly understand performance issues, identify bugs, and see how the game behaves in real-world conditions. Something that works perfectly in Unity might not work the same way on a phone.

Finally, deployment turned out to be much simpler than I expected. I created a Google Developer Console account (a one-time $25 fee), set up my app with screenshots and descriptions, and uploaded the game as an .aab file from Unity. That’s all it took to get the game onto the Play Store.

Where I Got Stuck

• Design: I spent hours dragging assets from the Unity Asset Store into my game, testing what looked good without any real plan. That’s when I realized that features don’t matter if the game doesn’t look good. I had two choices. Either I use ready-made assets (fast but limiting) or create my own (powerful but skill-heavy). Since I had no 3D experience, I stuck with the Asset Store.

• Maintenance: After publishing, players started finding bugs I never saw. That’s when it hit me that you don’t truly test a game until real people play it. Godspeed had too many assets and too little optimization. I was experimenting, not refining. Looking back, optimization is everything.

• Performance: The game ran perfectly on my phone, but froze on my friend’s. His device couldn’t handle it. Too many assets, inefficient code. Even small things mattered, like using Update(), which runs ~60 times per second, for tasks that didn’t need it. Those mistakes added up quickly. Fixing them made the game lighter and more stable.

• Data Reloading: Then came another question of what happens if a player deletes the game? Without a login system, all their data is gone. I decided to integrate Google Play sign-in so player data could be restored. It took time and effort, and honestly, for a simple game like mine, it wasn’t strictly necessary. But I did it anyway because I wanted the experience to feel complete.

My Second Unity Game

This is when Egg Rush came in. This time, I wasn’t starting from scratch; I was starting from experience.

One thing I had learned by now is that the most important part of a game is the idea. A game can be very simple and still be a huge hit. What matters is how it makes the player feel. They need to feel addicted, entertained, and excited to play again.

That’s how Egg Rush was born. It’s simple, but fun. Five chickens randomly lay eggs, and the player catches them. Players can compete with others worldwide, making it competitive. On top of that, it has 60 levels of fun challenges.

I followed the same approach as Godspeed, starting with a 3D mobile template in Unity. I used the Unity Asset Store for environments and audio. Since I couldn’t find a suitable animated character for free, I created the chicken using Meshy AI. For UI button images, I used Leonardo AI. The C# scripts were created with the help of ChatGPT. For the database, I switched to Firebase Firestore, and for ads, I integrated Unity Ads.

But this time, I focused on what I didn’t do before: optimization.

I tested the game on multiple devices before publishing, making sure it didn’t lag or get stuck. I added assets carefully, one by one, and removed anything unnecessary. I optimized the code as much as possible, using the Update() method only when absolutely required, and ensuring no condition was running more times than needed.

Switching from Firebase Realtime DB to Firestore made a big difference. Earlier, to show the top 100 players and the current user’s rank, I had to download and process all the data on the device. Now, Firestore handles it with powerful queries on the server side, making it faster, cleaner, and with less memory usage.

I also paid attention to smaller details. If a game object had any unnecessary component, I removed it. These small optimizations may seem minor, but together they make a huge difference.

One major improvement was using object pooling. Earlier, in Godspeed, objects were constantly created and destroyed, which affected performance. In Egg Rush, I reused objects instead. For example, instead of creating and deleting eggs repeatedly, I created a set of eggs at the start and reused them; disabling and reactivating them as needed. This significantly improved performance.

After all these changes, the game felt much lighter. When I tested it across multiple devices, especially low-spec ones, the difference was clear. I published Egg Rush on the Play Store in 2026. And this time, it wasn’t just about building a game; it was about building it better.

Things I Wish I Knew Before I Started

Looking back at this journey, I realized that many of the things I once believed about game development weren’t actually true. The biggest misconceptions are:

Practical Advice for Beginners

As a beginner, don’t start by creating a big game. Start simple. Make a small game first. Learn from it. Experience it. Then move on to something bigger.

The reason is if you begin with a big project, you’ll likely get stuck in the middle without fully understanding the basics or the standard approach. As the game grows, it quickly becomes complex, and once that happens, maintenance becomes very difficult.

One more thing I learned along the way is to try to log and record every issue you face during development. It may not seem important at the time, but later, it helps you avoid getting stuck in the same place again. Even though we have AI to resolve issues quickly, some problems still take time. Finding the exact solution isn’t always instant, and those recorded learnings make all the difference.

List of Tools and Resources I Used in My Journey

If you enjoyed my story and can relate and benefit from it, you can also use the following tools and resources. The best part is they’re FREE. The only thing is that you’ll need an efficient and more powerful computer to run Unity Game Engine and a Developer Console (for Play Store only; $25 one-time fee).

Parting Words

To be honest, my journey of game development is not a successful one. My first game was not a hit, yet I chose to develop another one. And now my second game is also not a hit yet. But I continue to aim to market it and make it successful.

For me, game development isn’t just about revenue, but passion. Something that I do with all my heart. When I see someone playing the game I had developed, it gives me the same joy I felt when I played hundreds of games in my childhood, knowing that, someday, some kid is going to enjoy their childhood playing my game.

So to all the game devs out there, find your motivation. It should come from within ourselves. People may doubt us and make us question our worth, but what matters is our passion to create something. If you lack motivation, just think why you had started. If the game is a failure, maybe try something different. The only way we are going to achieve success is through trial and error.

Just make it exist first, and you can always make it better.

As a wise panda once said, “There is no secret ingredient. It’s just you. You have to believe in yourself. That’s the secret.”

💖 Thanks for reading.

About the Author

I’m Vishnu U Pillai, and I love coding and exploring. I’m a Computer Science Engineer currently working as a Senior Software Engineer at Allianz Technology (Trivandrum, Kerala). I am primarily a Backend Developer specializing in Java. I’m also an indie game developer, with published games including Godspeed and Egg Rush, and the founder of the online fashion brand Aalila.

From childhood, I have always been very fond of playing games. I used to spend hours playing computer and mobile games. Over time, I wanted to create a game of my own; an actual product of my own. An idea that someone would love and feel entertained by; something that would make their time special, just like many games did for me.

While I haven’t achieved any major notable milestones yet, I see my journey itself as meaningful. If receiving prizes in coding contests at college tech fests counts, then yes! More importantly, creating three games, one application, and launching an online clothing business feels like a big achievement for me personally. I’m aiming to achieve even more in the near future, and I’m happy to part of Game Dev Assembly’s community to help me get there.

Please check out my games and give them follow:

🥚 Egg Rush

Egg Rush is a fast-paced arcade game that puts your reflexes to the test.

Five chickens sit high above the ground, laying eggs — and it’s your mission to catch them before they hit the ground.

Download Egg Rush on Google Play

ᯓ🏃🏻‍♀️‍➡️Godspeed

Godspeed is a high-octane 3D endless runner game where every second counts and survival is your only goal.

Swipe left, right to dodge deadly obstacles and keep moving at breakneck speed. And collect coins as you run!

Download Godspeed on Google Play

Closing - Until the Next Edition

And that’s a wrap, folks. How did you find Vishnu’s journey? Was it helpful? Does it make you think of your own game development projects? Do you think Vishnu is on the money when he talks about having love, passion, and motivation for building games?

Every game starts with a simple idea.

All it takes is curiosity, the courage to try, and the willingness to keep going even when things don’t work the first time. Vishnu’s journey reminds us that creation rarely begins with expertise. It begins with passion, experimentation, and persistence 🎮✨

Whether you’re building games, writing code, designing worlds, or simply exploring a new idea, this issue is a reminder that you don’t have to start perfectly. Feel free to drop your comments, and like and share this issue. And if you want to share your own story, get in touch with us.

Until next time, keep building, keep learning, and keep creating 🚀

WAIT! There’s more…

We have an exciting event lined up for you. And it’s FREE to attend! Are you ready, peeps? We’re bringing Jordan in the house who has spent years working in the indie space and has launched a marketing agency to help games take off and attract players.

After reading Umut and Berkay’s story, you will realize marketing your game is an absolute must, and Jordan will break this down in a simplified way.

GET YOUR FREE TICKET

Our hosts at Game Dev Assembly and Jordan look forward to greeting you and holding a game-changing session! Get it? ;) Sign up fast before tickets run out!

From creators driving discovery and games designed for shareability, to faster player attention, mid-scope wins, and why building in public is becoming the norm, we’re not here to throw headlines at you, but connect the dots so you can make smarter decisions as a developer. Let’s get into it 🚀

🧑‍💻 Creators Are Becoming the New Publishers

We’re seeing more games grow because of individual creators, not marketing teams.

Take Markiplier. When he played Lethal Company, the game saw massive spikes in attention: clips, memes, and streams followed almost instantly. Or look at how CaseOh has driven visibility for smaller, chaotic indie titles just through raw reactions. These creators aren’t just covering games. They’re deciding which games break through.

Some benchmarks to understand the shift:

• A single mid-tier creator (100K–500K subs) can drive 10K–50K views per video

• Viral TikTok clips regularly exceed 100K–1M+ views even for unknown games

• Steam traffic is now heavily influenced by external sources (social and creators)

One creator can outperform an entire marketing campaign.

🎥 “Playable Spectacle” Is Beating Traditional Design

Some of the most talked about games right now aren’t just fun to play, but fun to watch too. Games like Content Warning and Lethal Company exploded because they generate chaos, player reactions, and unscripted moments. These are clip machines.

Why that matters:

• Short-form platforms reward high reaction moments in <15 seconds

• Videos with strong hooks in the first 3 seconds perform significantly better

• Shareable gameplay leads to exponential organic reach

That’s why they dominate platforms like TikTok and YouTube.

If your game doesn’t create moments, it won’t create reach.

🧩 Mid-Scope Games Are Quietly Making a Comeback

Not everything needs to be AAA or tiny indie. Games like Dave the Diver sit right in the middle with its focused scope, clear identity, and strong execution.

It wasn’t trying to do everything. It just did one experience really well, and that resonated. Similarly, Dredge succeeded with a tight gameplay loop, a unique tone, and controlled scope.

Both these games show that you don’t need massive scale to win. Why this works:

• Lower development cost

• Faster production timelines

• Stronger focus on a single experience

Meanwhile, on Steam:

• ~14,000+ games release annually

• The majority earn under $1,000 revenue

This means:

• Over-scoping leads to higher risk

• Focused scope results in a higher chance of completion and success.

Tight and well-defined games outperform bloated ones.

🔄 Live Iteration Is Replacing Long Dev Cycles

Developers are no longer disappearing for years. They’re building with players. Look at how Hades (by Supergiant Games) used early access: constant updates, player feedback loops, and iterative improvements.

Or how Baldur’s Gate 3 built momentum long before launch through extended early access and community input.

Why this works:

• Early builds generate initial wishlists and feedback

• Frequent updates keep communities engaged

• Iteration reduces the risk of building the wrong thing

Games with active communities can generate thousands of wishlists pre-launch, and regular updates increase retention and visibility.

The earlier you involve players, the better your outcome.

🧠 Player Attention Is Fragmenting Faster Than Ever

Players are jumping between games more than ever. Which is why games like Balatro work so well. They have an immediate hook, fast gameplay loop, and quick satisfaction. You don’t need hours to get it. You get it in seconds.

Some benchmarks to understand this:

• Players often decide within the first 5–10 minutes whether to continue

• Drop-off rates spike early if the hook isn’t clear

• First-session experience is now critical

Your first five minutes matter more than your last five hours.

🛠️ Tooling Is Lowering the Floor…

… but raising the bar.

Yes, tools are making development easier. But that also means more competition. Which is why only games that stand out, like Lethal Company, cut through. They’re memorable, shareable, and different.

Steam alone reflects this:

• Thousands of new titles every year

• Increasing difficulty in standing out

Making games is easier than ever. Standing out is harder than ever.

🧩 What This All Adds Up To

Let’s connect it:

• Creators are driving discovery

• Games should be designed for sharing

• Players need to decide faster

• Devs benefit from iterating publicly

In a nutshell, games need to be seen, shared, and talked about.

🚀 Your Move This Week

Try one of these:

• Ask: “Would someone clip this moment?”

• Improve your first 5 minutes

• Reach out to one creator in your niche

• Turn one mechanic into a shareable clip

Then share with us what happens. That’s it. Drop a comment in this edition or send us a message when you have done any of the above. Game Dev Assembly is your space; our collective space.

🎤 The Complete Game Marketing Roadmap: From Idea to Post-Launch Success

Most games don’t fail because they’re bad.
They fail because no one sees them.

We’re doing a live session with from on how to fix that.

📅 May 23, 2026 (Saturday) | ⏰ 10 AM ET | Free

BOOK YOUR TICKET

And that’s it for today. Stay tuned for the next industry signals by us where we bring you the latest news and deliver it in a meaningful and relevant way.

Warm Regards,

Game Dev Assembly Team