Recently, that pipeline moved into Unreal. The ceiling for quality and ambition moved with it.

I’m now directing AI agents through terrain creation, forests, lighting, materials, streaming, builds and engineering work inside Unreal Engine 5.8. Claude or Codex leads, based on token / usage amounts they have in use, the world and engine work, whilst agents at both ends run parallel engineering and review lanes. I’m setting direction, reviewing the actual game and pushing the quality further.

The results have made me considerably more optimistic about what one developer can attempt. AAA or AA? Yes, it’s doable if you have what it takes to get there with current state of AI.

A current editor capture showing the relationship between the central mountain, slopes and open terrain. The environment is still in this picture very much WIP.

These are actual engine captures in my article. The agents assembled and configured the environment using Unreal systems and existing assets. I’m showing them with more quality as well as with work in progress (WIP) states to show how things look in practice.

World Before Details

The world I’m building has a central mountain, river valleys, forests and open ground. I’m keeping the game I have in mind for this private for now. Instead of going to game details, the production findings are useful and something I’m sharing here.

Real geography has been an especially useful starting point.

Elevation data gives relationships that are difficult to invent convincingly through random terrain noise alone. Ridges connect, valleys have direction, and the landscape has an underlying structure before anyone adds grass.

From there, the agents can process the data, adjust scale, smooth selected areas and help shape the terrain around the experience you want. You still need to decide where players travel, what they can see, and which landmarks orient them.

For anyone trying this, establish coordinate systems, elevation units and the map origin early. Check the geodata license as well, if you’re opting for it. Unreal’s georeferencing tools can help when geographic alignment matters. You don’t need to reproduce a real location exactly to benefit from its terrain as well.

It’s of course doable to do anything from scratch, but I really enjoyed working with geodata.

An earlier river valley pass. Geographic structure gives the world a coherent backbone; banks, water appearance and vegetation remain art direction decisions. In the image still lots of work is at WIP state.

Agent Access

An agent needs more than permission to click around the editor.

MCP provides a tool connection through which an agent can inspect and operate supported parts of Unreal. The useful setup combines that bridge with editor Python, C++ extensions, commandlets, build tools and visual evidence.

Epic already provides editor automation and a Remote Control API. MCP is an additional integration layer whose capabilities depend on the bridge you’ve installed or built.

Python handles repeatable content work. Headless jobs run supported operations without the editor interface. C++ can expose capabilities that the scripting layer doesn’t offer. Where access is awkward or missing, agents can build small wrappers around specific operations / tools / plugins, with clear inputs, logs and results / outputs.

I’d want wrappers for loading a region, inspecting materials, running a build, launching at a named location and collecting evidence. A successful operation should leave a reusable script or recorded procedure behind (future me appreciates this considerably).

Headless doesn’t automatically mean every editor feature works without rendering. Visual validation still needs a rendering session, and some jobs need particular assets or worlds loaded. Match the tool to the operation. Keep development bridges local and separate from the shipped game.

What AI Still Does Poorly

Whilst AI has MCP and there’s a possibility to create wrappers to access everything beyond what MCP originally grants, it’s not still enough for success.

In Unreal, the AI context window and its suppressions lead fast to deviations by the models. They get stuck easily on details as well, from which they start new routes that lead away from the focus. This needs high amount of attention to the detail over how you’re organizing the work, incl. new conversation / thread initiations past e.g., 6-12 hours of work sometimes.

Whilst you see these results, they are from small snapshots. On a larger scale your world map can look like a mess if you haven’t monitored AI’s work.

If you go beyond recommended windows and suppression loops, you need to really be wanting to crack something special in your threads, which should formalize as the centerpiece for future success, as otherwise you’re going to spend tokens / usage for poor ROI. The larger amount of tasks main AI model operates for you, the easier it deviates in Unreal from its track.

Unreal (and I’m assuming Unity as well) behave with AIs totally different ways than Godot. Somehow Godot still works more fluently for longer work. Unreal MCP is still at beta / experimental state, so it might be also just because of that.

Serious Quality Ceiling

My rendering experiments combine Lumen, Nanite, Virtual Shadow Maps and Temporal Super Resolution.

Lumen supplies dynamic indirect lighting and reflections. Forests and valleys benefit enormously from lighting that makes surfaces belong to the same world.

Nanite supports detailed geometry and fine grained streaming. Virtual Shadow Maps handle detailed shadows, whilst TSR reconstructs the image across frames. Together, they’re a strong foundation for ambitious environments. They still need tuning around materials, foliage, motion and hardware.

The project findings report roughly 70–100 FPS in a cooked Windows build on an RTX 5080 at Epic quality. That’s still something that needs optimizations as well as quality uplifts being maintained hand to hand. The screenshots aren’t a controlled benchmark, and that figure doesn’t establish performance on ordinary PCs or consoles.

A current spruce forest editor capture. Tree spacing, fallen wood, ferns and lighting all contribute to the scene; material and ground detail work is still WIP.

I’ve also experimented with mesh terrain alongside Nanite and the established Landscape route. Mesh terrain offers interesting authoring possibilities, but experimental features need their own packaged build validation before becoming the foundation of a large world.

Nanite Landscape is another option. It retains additional Landscape data at runtime, so enabling Nanite doesn’t remove the need to budget memory. I’d compare terrain approaches in one representative area before committing the entire map.

From Snapshot to Global

With Unreal + AI, I’d begin with references, a biome palette and a curated asset library. Decide what e.g., the forest should feel like before asking an agent to populate thousands of trees.

Then prove one area containing terrain, vegetation, rocks, lighting and a playable route. Inspect it at player height, from above and from a distance. Give the agents concrete feedback about density, silhouette, scale and visibility.

Once that area works, turn its accepted choices into reusable rules.

PCG is useful for distributing grass, flowers, debris and other detail according to those rules. Generate static layers ahead of time where appropriate, and reserve runtime generation for content that benefits from it.

Keep landmark placement and route composition deliberate. A forest needs clearings, sightlines and changes in rhythm. More scatter doesn’t automatically produce a better place.

A separate forest detail experiment using rocks, roots, ferns and smaller vegetation. This is one type of a local composition worth proving before extending it across a biome.

Wind deserves the same attention. Use a coherent direction and response across vegetation, then validate each asset family’s implementation. Unreal’s newer Nanite foliage documentation includes an experimental Dynamic Wind route. Existing material driven approaches remain relevant too. Choose deliberately and measure their cost.

Plan For The Size

I and my agents have made plenty of mistakes whilst exploring this. The useful outcome has been a clearer understanding of the architecture a world like this needs.

Partitioning became necessary once we hit memory limits. I’d bring that decision upfront in the next project already.

World Partition loads relevant parts of the world. HLOD provides representations of distant content. Plan both, including what the player sees beyond the loaded area.

The editor also needs manageable regions and quick ways to switch between them. Agents can build those controls, along with reports showing missing coverage or expensive content. That’s a much better production experience than repeatedly waiting for the entire world to load or crashing the editor or computer.

A terrain study showing large landforms and valley space. Macro composition needs to work before surface detail carries the scene.

Build In Conversation

A cooked build prepares the content for the game outside the editor. Our pipeline has produced one, alongside scripted launches, captures, log checks and soak tests.

I’d keep that loop close to every significant change: build, visit known locations, inspect visuals and performance, then expand the accepted solution.

Agents can automate those checks and investigate deeply when something fails. In this project, that has included reading engine source and writing diagnostic tooling. Human review still catches composition, movement and atmosphere that a clean log can’t judge.

A vegetation study. Still images show density and materials; movement needs separate checks for wind, stability and temporal artifacts.

More Capability, More Ambition

The agent setup works best when ownership is explicit. Frontier model leads the Unreal work; another can investigate, review and engineer in parallel. Bounded tasks, shared project notes and recorded decisions keep the lanes connected. Every task doesn’t need the most expensive model or the whole project history. Sol 6.1, Luna 6, Sonnet 5.5 and Haiku 5.5 work for things they do best, instead of Opus 5.5, Fable 5.1 or Astra 6.

I’m still directing the experience and deciding what passes. The agents increasingly handle the implementation that gets us there.

These tests make AA and AAA visual ambition feel reachable for a much smaller production setup. A finished game still needs gameplay, animation, content, performance and release quality to match its environments. I’d say that’s achievable past this scale of a world map hurdle, as I know it already from my experiments with e.g., Godot.

I’m increasingly excited about AI. Better tools, reusable world recipes and more capable agents let me push further whilst keeping control of the result. Next comes more composition, broader performance testing and tighter connections between the world and the playable experience.

The more I build, the more I discover what these systems can do. That keeps changing what I’m willing to attempt.

It has also a flaw. It’s hooking to try building ongoingly more ambitious things, whilst overall you might not be needing that all. For some games much more easier artistic choices can matter more. Players judge ultimately.

The latest phase moved the line again. It actually moved it that much that I had even thought to not just write about latest developments, as that would give advantages for others to adapt to things faster, even through the inertia our industry has. I decided to do it anyhow as my blog’s purpose is partially to educate everyone in our industry, and I really hope it’s appreciated. It’s also one way to show my work for everyone.

So, I’ve now used the pipeline to polish gameplay, build a working meta game and UI in just a couple of days, get multiplayer running across real computers, work through network and voice issues, and clear graphics optimization that once looked like its own development phase.

That’s the headline for me. AI is becoming useful across the whole game, not only in the parts that make a good demo.

How one agentic pipeline moved from gameplay polish into meta systems, UI, multiplayer and performance.

Multiplayer didn’t end the experiment. It validated the pipeline to the end point. What isn’t doable anymore? Well, all things kind of seem to be “cracked”, so nothing really. Or, well, I still think 3D models + animations are going to be a challenge for some time, as they require lots of work to be optimized for game development usage. Despite that comment, overall the statement here is that everything’s becoming doable with the speed of current developments we’re witnessing weekly.

The Experiment Became A Game

Getting gameplay to work is one thing. Making it feel great is another.

The latest work has been about the second part. Input timing, camera response, animation transitions, aiming, movement recovery, collision, impacts, sound timing and the small visual reactions that tell the player the game understood what happened.

AI has been almost excellent in this loop because the agent can move from a precise playtest observation into code, configurations, assets and tests without losing the relationship between them. The not so almost part? Some things break from time to time, which you need to fix quickly.

I play the game. I explain what feels or works wrong. The agent follows the system through the implementation, proposes a bounded correction, runs the relevant checks and prepares another build. Then I play again.

It’s basic work. A lot of work. But given how fast I does an iteration, that loop can move remarkably fast.

It works best when the feedback is concrete. Asking AI to make combat feel better is too vague. Explaining that the recovery lasts too long, the remote pose disagrees with the aim, the impact arrives before the animation or the camera loses the target during a particular transition gives the agent something it can solve.

The important change is that the agent isn’t only creating the first version anymore. It’s staying in the loop while the game gets better. That impacts much more to the equation than another fast prototype.

Meta Game In Just A Couple of Days

The speed of the meta game surprised me.

Menus, progression, meta, economy, saved state, navigation, settings, screen transitions and the UI connecting those pieces were developed in just a couple of days. They weren’t disconnected visual concepts. They were working systems connected to the actual game and its data.

That would’ve sounded like a fairly irresponsible schedule not long ago. I managed to get every feature and system done I wanted. In “the old world” I would have needed to fight against stakeholders and everyone who would be implementing it; all for good reasons that I also understand well and have always taught everyone to follow.

AI was strong on all sides of the work. It built underlying state and data flow, then helped shape the screens that expose them to the player. I could move between product direction, design direction and visual feedback without translating every decision through a separate implementation chain.

The human part still matters. A screen can contain every required control and still feel wrong. The hierarchy can be flat. The first decision can be unclear. The interface can technically respond to every resolution while still lacking visual rhythm.

So I approached UI like gameplay. What should the player understand first. What do they need to decide. What can wait. What should feel immediate. What should stay out of the way. I did a whole bunch of UX validation myself as well.

Once those points and decisions needed were clear, the agents were able to produce and iterate the interface extremely quickly.

A real settings implementation for the meta. AI handled both the system underneath and much of the visible production work, whilst some parts of the scene use commercially available assets.

This is one of the places where the technology already feels amazing. The distance between a design decision and a working screen is shrinking fast. The final layer of taste still benefits from human review, but the amount one person can direct is completely different now.

Multiplayer Became Solvable Challenge

Multiplayer was the biggest proof that I wanted to clear with a solid pass. And I just got it.

In terms of the practical work over it, obviously, it forced the pipeline to deal with several computers, network delay, event ordering, ownership, recovery and different versions of the same moment. A single player game can let one machine agree with itself. Multiplayer asks several systems to arrive at the same truth / view.

We encountered issues around authority, movement replication, aiming, spawning, joining, leaving, reconnecting, network changes and voice state. Some callbacks arrived after the state that created them had already ended. Some recovery paths worked in one situation and kept old state alive in another. A movement or aim value could look correct on the sender and still be interpreted differently by the receiver.

These weren’t signs that AI couldn’t do multiplayer. They were the normal class of multiplayer problems, discovered and resolved through an unusually fast AI assisted workflow.

Two clients sharing the same rainy world during multiplayer testing.

Some of the answers lived all the way down at byte level. Position, direction, velocity, timestamps and actions eventually become bytes travelling between machines. The sender and receiver need to agree on what every byte means, when it applies and who is allowed to decide it. There’s even “a budget” for all this to consider.

The agents were able to trace those paths, compare the state on both sides and implement fixes. My role was to keep the work anchored to the architecture and the player experience.

We mapped authority explicitly. Which machine owns each decision. Which state is predicted. Which state is confirmed. What can be retried. What must be cancelled. What happens when an old message arrives. What the player should see while the system recovers.

We followed the bytes. We compared what was written with what was read. We inspected ordering, timestamps, generation identifiers and the lifetime of requests. We read engine, platform and service manuals madly because the correct answer was often already documented somewhere (finding the correct page was occasionally the actual boss fight).

Every problem became easier when it had a reproducible path, evidence from both sides and a written contract for the intended behaviour.

The result is the optimistic part. Multiplayer is doable with AI now. Not as a magic prompt, but as real engineering that agents can understand, execute, test and improve when the pipeline gives them the right context.

The Project Taught The AI How To Build The Project

The full documentation system became one of the strongest parts of the pipeline. Like, as an example, without it getting through multiplayer implementation with a clean pass would be hell of a fight for someone.

To get easy wins with AI, documentation is big part of the equation. Like in a case of multiplayer, without proper documentation AI wouldn’t have been able to pull every piece of every corner together. Documentation is lots of work of course… but it can be also done just with AI nowadays, with human directing.

How documents are used? How they improve the pipeline? Here are some examples:

• The game design documents explain the player experience and the logic behind it.

• The technical documents describe authority, state, data, boundaries and recovery.

• The art documents explain the visual target and what can’t be lost while code or performance changes.

• Test plans define what working means across two machines instead of only inside an editor.

These documents are not just created / assisted by AI. They are also maintained by AI. This makes them being more than paperwork. They’re production memory shared by every model that enters the project.

When an agent works on movement replication, it can understand the intended feel of movement. When it changes a loading flow, it can see the technical lifecycle and the player facing goal. When another model reviews the result, it doesn’t need the whole history retold from scratch.

This was especially important in multiplayer. A larger prompt wouldn’t have been enough. The agents needed stable architecture, terminology, decisions and acceptance criteria that survived across sessions and models.

The game became easier for AI to build because the project itself became easier for AI to understand. That’s a very powerful loop everyone needs to crack for their projects.

The Latest Models Feel Like A Real Production Bench

The model releases have been arriving at an almost unreasonable speed.

GPT-6 Sol and GPT-6.1 Sol have been highly effective under the hood. Architecture, debugging, code changes, tests and long trails through state and data fit them well. Sol 6.1 has also been reasonably capable visually in my own work, so it can stay with more of a task before I route a dedicated visual pass elsewhere.

Claude Opus 5.5 and Claude Sonnet 5.5 also look highly relevant for game development. Opus fits harder open ended reasoning and broad review as well as for visuals. Sonnet looks strong where speed, cost and visual iteration matter together.

Astra continues to impress me in visual judgment, spatial reasoning and broader creative work. Opus 5.5 is at same level. Opus 5.5, Sonnet 5.5 and Astra also seem all overall capable on graphics and UI based on what I’ve seen shared on X (formerly Twitter) and what I’ve seen while improving this game.

I don’t see this as a single model competition. I see a production bench.

For example, Sol can investigate architecture and fix the machinery. Astra can inspect the scene and reason visually. Opus can challenge a complex plan. Sonnet can move quickly through a defined implementation or presentation pass. Another model can review the result independently.

The shared documentation keeps all of them working on the same game. Model routing is a real advantage, not a workaround.

Performance Optimization Moved Fast

Performance work has also become much more manageable.

Resolution scaling, quality profiles, graphics defaults, capability checks, frame pacing and support around NVIDIA DLSS and AMD FSR moved from open questions into implemented and testable systems quickly.

The agents didn’t only add graphics options. They built ways to inspect the effective mode, preserve fallbacks, protect lower end hardware and compare behavior across different computers.

Distinction matters. A menu can say one thing while the renderer does another. A powerful desktop can hide a problem that appears immediately on a laptop. Performance work becomes reliable when the configuration, logs and real experience agree.

AI was able to implement much of that structure, trace issues through it and react to the measurements. Human testing still decided whether the result looked and felt right.

This is another area where the practical value is easy to see. Work that could’ve become a long specialist detour became a focused part of the same pipeline.

Unity And Unreal Has Opened Their Doors

Most used engines are moving in the same direction.

Unity now has official agent integrations, including its Codex plugin, which gives Codex Unity specific skills and ways to verify work inside a project. Unreal Engine 5.8 includes an experimental Unreal MCP server that can let clients such as Codex and Claude work with the editor, inspect UI, change scene content and run automation. Godot has been already there for a while.

These integrations are important because they reduce the distance between reasoning and the actual engine state. The agent can increasingly inspect what exists, make a change and verify the result in the environment where the game lives.

I’m planning to port or rebuild a focused part of this game in Unreal at some point. The goal is to see how far the same design documents, art direction, gameplay logic and production pipeline can lift the look and feel while keeping the development loop fast. If the test succeeds, I may just continue taking the experience further there. Either way, it will show what the pipeline can carry across engines and where a more engine specific approach creates the biggest gain.

I’m not interested only in whether AI can place an object in Unreal. I want to know whether it can help preserve a game’s identity while rebuilding enough of it to clear a higher quality bar. Based on the progress so far, that’s a serious test rather than a fantasy. And, I think, it’s all achievable.

AI Game Development Is Today A Production Advantage

I don’t mean with the headline here that pressing one button and receiving a commercial game is what everyone should be doing.

Today, a directed pipeline can now carry e.g., gameplay, meta systems, UI, multiplayer, performance, documentation, testing and builds at a scale that would’ve required a very different setup before.

The technology is amazing across all of these fronts. It becomes even better when I stop asking it to guess and instead give it architecture, visual direction, examples, acceptance criteria and real evidence from the game.

My work becomes more directorial. I define quality. I play. I decide what matters. I choose when to stay with one model and when another pair of eyes will improve the result. The agents handle an enormous amount of analysis, implementation, correction and verification.

The more I do this, the more nuances and limitations I discover. That knowledge doesn’t make the tools feel smaller. It lets me get more out of what they can already do.

I’m still scared, hungry and excited at the same time (which is probably why I keep pushing it).

What I’m Taking Forward

AI can stay with gameplay beyond the first prototype and help polish it through repeated playtest loops.

Meta systems and UI can move incredibly fast when every screen has a clear purpose and the data contracts already exist.

Multiplayer is doable when authority, state, failure recovery and acceptance are explicit. Byte level debugging still matters, and agents can do it remarkably well when both sides of the evidence are available.

Full game design, technical and art documentation gives several models shared memory and makes every implementation pass better.

Sol 6.1 is strong under the hood, whilst a bit slow still. Astra, Opus 5.5 and Sonnet 5.5 expand the visual, spatial and review capabilities available to the same pipeline. Sonnet 5.5 probably fits well under the hood as well.

DLSS, FSR and broader performance work can move quickly when real hardware and measured results stay in the loop.

Unity and Unreal giving agents deeper official access raises the ceiling again, whilst Godot has been already there.

Overall, games can be made. With what quality? Pretty much all targets in mind, with right pipeline.

The Line Has Moved

The interesting question isn’t whether AI can generate a prototype anymore. It can.

The more useful question is whether AI can keep working after the prototype. Can it improve the feel. Can it build the meta layer. Can it produce the UI. Can it make multiplayer work across real machines. Can it chase a byte through the network, read the manual, fix the architecture, improve performance and preserve the game’s visual direction.

From what I’m building now, the answer is yes.

It still needs direction, testing and taste. That’s not a weakness in the idea. That’s game development.

What has changed is how much of that development a small human led pipeline can now execute.

The game is playable. The meta game works. The UI works. Multiplayer works and continues to improve. Performance work that once looked intimidating is becoming a bounded task. The newest models are broadening both the technical and visual ceiling.

That’s more than a promising demo. That’s a new way to build games. And realizing where I can go, I’m becoming hesitant on sharing these learnings.

This time the battlefield for me was around building actual experiences, and…, well, getting towards building actual games.

• This meant, for example, that:
  Combat had to feel responsive.

• Levels had to work from player height.

• UI had to explain increasingly real systems.

• Sound had to support actions rather than sit in a folder.

• Different models had to take over work from each other without burning the whole budget on rediscovering the project.

The good news is that the pipeline can do much more than it could even a short time ago. The less comfortable news is that pushing past the demo exposes a second game layered on top of game development itself.

What changed when agents had to finish combat, build coherent levels, create sound and justify their own cost.

Which model should I use, how much context should it read, when should I pay for more capacity, and how many weak rolls should I accept before changing the approach?

That last part is starting to look suspiciously familiar to anyone who has designed free to play economies, or… well, RNG machines.

Game Fought Back

Getting a character on screen is easy (it’s especially easy if you use mixed pipelines, e.g., existing assets with AI doing implementation; you have to hack your ways still) compared with making an attack feel right.

The combat work forced the agents to deal with problems that a still image never reveals. A sword animation can look fine whilst the real collision misses the target. A bow can reach a ready pose whilst an actual mouse click fails to release it. An enemy can technically face the player whilst its weapon points sideways. A fire effect can exist and still cover the wrong part of the screen, play from the wrong audio position or fail to tell the player what is happening.

These are small problems… until there are fifty of them.

The useful shift everyone needs to learn is to stop treating combat as one feature called combat. Execution needs to be sliced into actions, contacts, timing windows, camera behavior, input paths, feedback, damage rules, animation states, audio cues and rejection cases. The agents could then build tests around each piece. One pass checks dozens of directional melee cases. Another checks archer alignment across twelve headings. Another uses actual mouse input instead of calling the fire function directly, which is how it can found defects that automation could miss.

Early combat video. This is more useful than a beauty render. The character, weapon, camera, input, HUD and playable world all have to interplay well at the same time.

The same pipeline eventually handles physical blade sweeps, a bounded close range allowance for hits, wall and rear rejection, projectile contact, burning, extinguishing, death, reset and enemy behavior. Sixteen packaged regression suites, over time passed, in one accepted build.

That sounds impressive because it is. It still doesn’t prove that combat feels good, though.

Automated tests can tell me whether the blade hit, whether the wall blocked it and whether the enemy entered the correct state. They can’t fully tell me whether the attack has weight, whether a bow release is satisfying or whether fighting the same enemy for the twentieth time becomes boring. I can push more of the mechanical QA to agents, but… I still have to play and direct the feel. Otherwise what I’m doing would just work poorly.

Focused proof scenes are intentionally ugly. They make one behavior visible and repeatable before it disappears into the complexity of a full level.

Astra Saw The Level

The difference between e.g., Sol and Astra became especially visible in level work (during the last week or so at the time of writing this article).

Sol has been useful for bounded implementation, repairs, test writing, data work and tasks where the desired structure is already clear. It can move quickly when the contract is good. In my experiments it has also been easier to keep on routine work without spending the most expensive model capacity on every file.

Then, something I’d call even magical, happened. Astra arrived with a noticeably stronger ability to hold a larger visual and spatial problem together. It was better at reading reference images, keeping architectural intent alive across a longer implementation and understanding that e.g., a level is viewed from several distances. It could work with the engine, generate evidence cameras, use Blender when needed and continue through technical validation without losing the visual goal as quickly.

The strongest example was a large world pass. Astra helped turn plans for roads, walls, terrain, districts, bridges, interiors and underground spaces into a scene that could be inspected and traversed. One version covered a playable area more than a kilometer across. Route audits ran through thousands of samples. Actual controller tests walked entrances, stairs and longer paths rather than merely checking whether coordinates existed.

Astra was much better than Sol at seeing the relationship between terrain, roads, buildings and the wider composition.

This is where Astra did genuinely well. The output stopped looking like a collection of objects and started looking more like a place. It handled hierarchy, routes, silhouettes, conditions and evidence with more confidence than my earlier passes.

It also made still very visual mistakes.

Walls were reversed. Roof pieces inherited awkward pivots. Grass entered floors. Procedural guards looked like farm rails inside a civic underground space. A ceiling compressed the room. Furniture faced backwards. Large repeated surfaces still lacked the richer prop composition of the reference.

The first controller tests passed routes that my visual review still rejected.

Later tests exposed stair corners and a missing bypass that screenshots alone had not found. This is the real level pipeline. Plans, generation, traversal, cameras, human review, correction and another run.

The structure works and the route exists. Final composition, lighting, materials and local storytelling still need taste rather than another victory message from a test runner.

One large prompt still doesn’t make one large level. Astra simply got Codex much better at helping me build the smaller proofs and keep them connected.

The Nerf Was Visible

Astra came in. Amazed everybody. But, then Astra changed.

I saw what looked and behaved like a clear nerf. This was visible to lots of people if you followed any of it in LinkedIn, X (prev. Twitter), etc. The same kind of work became less coherent. Visual judgement flattened. Instructions that had previously survived a long task started falling out of context. More effort produced less convincing results.

I can’t inspect the hidden model or prove exactly what changed behind the service. I can compare output in the same production workflow, and the drop was obvious enough that I stopped trusting the earlier expectation.

OpenAI later said the issue was fixed and reset eligible usage. That was the right response. It also showed why model capability has to be treated as a moving dependency rather than a permanent property of the pipeline.

A model name isn’t a quality guarantee. The pipeline needs saved evidence, fixed test scenes, accepted reference images and small benchmark tasks that can reveal when behavior changes. Otherwise I may blame my prompt, my scene or myself for a service change I can’t see.

After the fix, Astra again felt closer to the model that had impressed me. But, given what happened, I’m making more sure I’m not designing the workflow around blind faith that every future run behaves the same.

But, did Astra still got where it was? I slightly doubt it, as some visual tasks that should have been easy failed to meet Astra level quality I had first. For scenarios like this, my pipeline and workflow overall allows me to up things to the quality I want, which makes having a proper handbook in place golden.

Blender Works (Slightly Better) Until Finishing Starts

Astra is clearly more visual than the models I was using earlier. It can look at a render, notice broad spatial problems and operate tools such as Blender through an agentic workflow better than older models. That matter, as if wanted, it turns Blender from a specialist room into a production tool that an agent can enter, change and leave with evidence.

The limit remains still at the final ten percent, which has a rude habit of containing half the work in practice.

Blender automation is good at deterministic operations. Pivots, hierarchy, transforms, separation, batch export, LOD generation, material assignment and repeated renders are excellent agent tasks. Ambiguous topology, deformation, hands, cloth, subtle silhouette cleanup and artistic material repair are less predictable. The tool works, kind of, but the agent still needs a very explicit definition of what good means, plus images that prove it. Can it still get to the goal always? Not always.

UI Learnings

Same learnings, as for Blenders / Level Design, apply to UI.

Astra can produce a functional interface and has become better at reading screenshots, spacing and hierarchy. But, it still lacks depth in UI design.

It often solves the information architecture before it solves the experience. Screens can become technically complete, dense and consistent whilst still feeling like a development tool rather than a polished game.

Some early UI studies.

UI needs direction on what the player sees first, what can stay hidden, how actions feel, how the screen behaves at different sizes and where the game earns visual drama. Those are design decisions. A model can execute them well once they exist. It’s still unreliable at inventing all of them from “make it premium.”

Music Worked Faster Than Sound Effects

Sound has been another useful reality check.

Generated music already works surprisingly well for creating a direction, mood and usable first pass. Services such as Eleven Music can generate complete instrumental structures, allow section editing and provide commercial use under the relevant plan and terms. I can get much closer to the intended emotional lane without spending days / weeks searching e.g., through stock libraries.

Sound effects are more complicated. ElevenLabs Sound Effects supports prompted effects, controlled duration and looping. That makes it interesting for ambience, creature ideas, magic, impacts and layers. But, it doesn’t remove the need to study whether the result works in a game mix.

A good isolated sword sound can be too long once attacks overlap. A dramatic fire sound can become exhausting in a loop. Footsteps need variation, material identity and timing. Player sounds may need to stay centered whilst world sounds remain positional. Transients, tails, silence, loudness, occlusion and voice limits matter more than the prompt that created the file.

Music found its lane quickly. Sound effects still need more study because the real test is repetition, timing, layering and fatigue inside play.

One recent audio pass produced 63 compact mono variants and a 28 second listening reel. Automated QA checked file structure, peaks, loops, routing, variation and teardown. I could verify that the system behaved correctly, but overall I could same time hear that things needed lots of re-work and iterations. Headphones are still the acceptance gate.

My current view is simple. Generated music is already useful if the license is right and the art direction is specific. Generated sound effects are promising, but need more comparative testing before trusting them as the default source. Recorded libraries, generated layers, procedural treatment and selective human editing / producing can all exist inside the same pipeline, and overall I think it still should, until something changes.

Multi-Model Pipelines

The biggest gain isn’t Astra by itself. Overall in building something feasible with quality, it’s the ability to route work between models and tools.

Sol can handle many bounded coding, repair, data and test tasks. Astra earns its cost on visually difficult, spatially large or unusually coherent work. Local and openly released models can take private or repetitive asset jobs when their quality is sufficient. Specialist services can generate music, sound, images or 3D sources. Deterministic scripts keep successful results reproducible after the chat is gone.

That setup also protects quality.

One model can implement whilst another reviews. A cheaper model can prepare the evidence before an expensive model makes the judgement. An agent can resume from a compact continuation record instead of rereading every design document. A failed experiment can return a short finding rather than consuming another full context window.

The expensive model shouldn’t be the default employee sitting in every meeting. It should enter when the task can use what makes it expensive.

This requires discipline.

Every handoff needs the goal, exact files, accepted references, constraints, tests, known defects and the definition of done. Without that packet, a multi model setup becomes several intelligent strangers repeatedly touring the same repository.

The Token Casino

The cost model bothers me more as the pipeline gets better.

OpenAI’s current API pages list Astra at 10 dollars per million input tokens and 50 dollars per million output tokens. Sol is listed at 4 and 20 dollars. That’s a clean 2.5 times difference in API price.

Subscription usage isn’t that clean.

Included allowance, reset credits and direct token pricing are different things. Buying extra capacity doesn’t translate neatly back to what the subscription allowance represented. The comparison becomes harder exactly when the user is in the middle of work and wants the result finished.

I dislike that. It starts to resemble a free to play dark pattern even if that isn’t how the product team describes it.

AI is also a variable reward / RNG machine with some outputs still.

I send a difficult prompt, wait, and sometimes get a jackpot. Sometimes I get an answer that burns time and capacity. One brilliant result after several weak ones makes the next attempt feel emotionally justified. Anyone who has worked with game monetization, or with a RNG-based game, should recognize the loop. Uncertainty creates anticipation. A strong output creates an adrenaline spike. The next button is already there.

That doesn’t make the technology bad. It means serious users need e.g., cost controls that work against the psychology of the product.

AI addicts? They probably already exists. Having an addict as your employee? Phew, that’s gonna be expensive ride to look through.

My “automated” defense is a model budget before the task, a stop rule for weak rerolls, visible usage by task type, checkpoints before capacity runs out and a cheaper fallback path. If Astra misses twice, the answer isn’t automatically more Astra. The task may need a smaller contract, a better reference, a deterministic tool or human judgement. Beyond these, my defense is understanding how overall the casino works as well, and realizing you need to retain control as well. Sounds like an addict talking? Oh boy.

Paying for more tokens can absolutely be rational. Hiding the real comparison behind several kinds of allowance makes that decision worse than it needs to be.

Best Practices

Something to think about along the lines of this article:

• Use e.g., Sol for work that is already understood. Save Astra for visual reasoning, large spatial tasks, difficult synthesis and final review where the capability difference matters.

• Benchmark the model inside the real pipeline. A model can change. Keep small repeatable tasks and accepted images that reveal the change quickly.

• Make things like combat prove itself through input and play. Function calls, animation states and collision checks are useful, but an actual player path must still work.

• Build things such as levels through plans and slices. Finish one street, room, combat space or route before multiplying the pattern.

• Treat audio as a runtime system. A good file is only the source. Repetition, timing, routing, loudness and fatigue decide whether it belongs in the game.

• Track cost by outcome. Tokens per accepted feature, tokens per fixed defect and tokens per rejected visual pass tell me more than a monthly total. If token tracking is hard, just think it in percentages of your subscriptions’ usages.

• Keep the human rejection right. Agents can do most of the execution. I still decide when something is boring, ugly, confusing or simply not good enough.

• Don’t let the house win. Stop at the right step to… well, think.

The Pipeline Delivers

I can see that the pipeline is working.

I can get gameplay, combat, levels, UI, audio, testing and builds much further with agents than I could by manually operating every tool.

Astra raised the ceiling, especially for visual and spatial work. Models such as Sol keep a large amount of production moving at a lower cost. Specialist and local models give me more lanes instead of one provider deciding what is possible that week. Movement between Claude and Codex is doable, as your repo / process is managed right.

The result isn’t push button game development. It’s directed production with a strange new workforce whose skills, memory, price and mood can also change while I’m using it.

The more I build, the more capable the setup becomes because every failure can turn into a test, a tool, a reference or a routing rule. I’m no longer asking whether AI can help make a game. As I’m seeing it first-hand, it clearly can. Think I mentioned it already in my first article.

The harder question is whether I can keep the quality bar high, the costs visible and my own judgement intact. So far, yes.

This article is the “less tidy” continuation to it, incl. covering what happened once I started feeding that pipeline real 3D work.

The short version is that AI can already make much more of a game than most people probably realize.

It can also create a beautiful trap.

A tank model can look finished in a render, until its turret has to rotate. A character can be auto-rigged, until its hand has to grip a weapon. A world can be technically complete, until I look at it from player height and it feels like someone arranged a city on a board.

Example of what happened when attractive 3D outputs had to become movable, optimized, testable and shippable. Noticeable flaws.

This is where the hype usually cuts to another video.

I have been trying to stay in the annoying middle instead: after generation, before acceptance, where assets need to become controllable, optimized, animated, playable and repeatable.

Model Trap

The tank experiment (referencing the image above) gave me two almost opposite results.

In one lane, an agent reconstructed a vehicle directly in Blender through geometry rules and code. It produced clean moving assemblies, usable pivots and three controlled levels of detail. The technical structure was unusually good for an automated pass. It was also only approximately faithful to the visual reference. The agent could calculate widths, angles, wheel spacing and symmetry, but some ambiguous shapes in the concept views became mathematically sensible guesses rather than the exact design I had in mind. Meaning, in practice, that agent’s try to solve everything through math, resulting in results that visually look imperfect.

This is probably one of the best results visually an agent can provide through referencing given references whilst it builds a model through math. Most of the time it’s still a miss instead of a hit.

In another lane, a paid online generation service produced a model that looked more closer to the source. Great. Except the hull, turret, gun, deck and a surprising amount of hidden geometry behaved like one fused object.

Example of a paid generated model.

That is acceptable if the model only needs to sit in a render. It isn’t acceptable if the turret needs to turn, the gun needs to elevate, parts can be damaged, skins must be changed independently, or collision needs to follow the mechanical structure.

The problems the models bring for you if you try to shoot too far.

Separating the turret became geometric surgery.

Simple plane cuts opened broad holes, pulled pieces of the deck into the wrong object and exposed areas for which no texture or hidden surface had ever been generated. The pipeline then had to classify triangles, reconstruct the deck, create a turret socket, close undersides, repair seams and prove that the separated parts still looked like the original when reassembled.

An exploded diagnostic is far less glamorous than a beauty render, but it tells the truth: which parts are actually independent, whether the deck survived or not agent’s fixes… and where repair geometry was required ongoingly when you were trying to crack your model pipeline.

This is one of the clearest lessons so far. If an asset needs to articulate, break, swap parts or accept gameplay attachments, one should define that hierarchy before generation. Generate, for example, the assemblies separately where possible. If that isn’t possible, assume that a visually stronger fused source may still require a proper reconstruction rather than a clever cut.

The better-looking output was not automatically the cheaper output. The cleaner technical output was not automatically the better art. Both are useful, but for different things. And, with AI, this is really what one needs to understand.

Generated Characters

My first serious fantasy-character experiment was equally educational.

The generated character had a coherent face, silhouette, armor language and material idea. It was the kind of result that makes online 3D generation look solved.

But, underneath, the raw model had roughly two million triangles, more than a thousand disconnected components and well over one hundred thousand boundary or non-manifold edges. The file was over 100 MB before becoming part of a game.

That doesn’t make the generation bad. It makes it a high-resolution source, not a runtime character.

The local pipeline rebuilt it into a closed master, created new UVs, baked PBR textures and produced several LODs. One automated bake was technically successful and visually wrong: too dark, with the gold and skin tones flattened. The validation script could confirm that files existed, dimensions were legal and maps were connected. But on some occasions, it looked like the character had lost its identity. I rejected the pass and the material work was corrected.

A strong visual source, but not a production character yet. Topology, materials, LODs, rigging, animation contacts and runtime appearance all remained separate problems.

Past finding way to optimize my models, I wanted to rig and animate them.

The auto-rig function, through a paid online service, gave me a useful skeleton with full vertex weighting and sensible influence limits. But it wasn’t perfect. Like, it didn’t have finger or thumb bones, whilst rigid armor and cloth were still part of one deforming surface.

A sprint motion gave me something useful through animation pipeline, also within the paid service. But, when you wanted something working and ready, a roll didn’t properly read as a ground roll, on top of facing many issues. Weapon contacts weren’t believable, and open hands made some actions look immediately artificial.

Again, the pipeline worked, kind of, from technical perspective. But, the result simply didn’t pass the quality bar for me.

This distinction matters because agentic workflows are very good at announcing that a task completed. Export succeeded. Import succeeded. AnimationTree in Godot loaded. No missing vertex weights. Those are real achievements, but none of them mean the character looks good when it attacks.

Human QA isn’t the embarrassing leftover in this setup. It’s needed to get the creative side right. Did I get it right? Over time, yes, which took lots of stubbornness as a secret sauce.

AI Sees The Scene As Numbers Before It Sees A Place

There is a wider pattern behind both examples.

The agents I’m using usually interact with 3D through code, transforms, mesh data, bounding boxes, material slots, ray tests, camera positions and validation rules. In other words, they see a lot of the scene as math before they see it as a place.

That is a huge strength when the problem is measurable.

An agent can enforce a pivot position, calculate wheel placement, generate three LOD budgets, align modular walls, check clearance, place sockets, compare object dimensions and render the same evidence cameras every time. These tasks are repeatable and frankly not where I want to spend my own time, especially if I want to build an autonomous pipeline.

The same strength becomes a limitation when the instruction is “make this area feel imposing” or “keep the face attractive whilst reducing the mesh.”

The agent needs those goals translated into evidence it can work with: exact reference views, skyline anchors, scale relationships, protected features, rejection examples, player-height cameras and someone willing to say that the technically valid result still feels wrong.

Models can infer a lot, but they can’t calculate their way out of every ambiguity. If the front and side references disagree, the model still has to invent the missing truth. If the design brief says “premium” without showing what premium means here, it can only average ideas it has seen elsewhere.

The useful loop is therefore not prompt, generate, done. It’s contract, build, render, inspect, reject or approve, update the contract, and repeat. Less magical on social media like LinkedIn. Much more useful in a production folder.

Environment Is Not One Prompt Either

A newer world-building experiment pushed the same lesson into a much larger scale.

Agents assembled a substantial playable environment from asset packs, engine-built pieces and scripted scene structure. Roads, walls, districts, interiors and traversal could all be created and validated without me manually placing every object. That is already a major change in what one person can attempt.

Whilst it’s magical, the first wide overview still looked too much like a technical board.

The terrain ended in hard rectangles. Large forms felt isolated. Repeated wall sections exposed the construction pattern. The city had objects, but not enough density or hierarchy to feel lived in. Automated traversal was happy. My eyes weren’t.

This is the kind of result I find more interesting than a one-shot in-game world. It’s already a bit navigable and editable, if you plan it right in your pipeline. Its audit can be from here pointed to specific work needed next.

The better answer was not to ask for “more detail” and reroll the whole map. It was to put an architectural plan in place: districts, road widths, elevation changes, skyline anchors, support-building density, river and wall relationships, camera views and the order in which smaller areas should be finished.

That gives agents a structure they can execute. It gives me smaller creative decisions to review as well. You get over time better results. One street can prove the materials and prop density. One gate can prove scale and navigation. One interior can prove lighting. Those pieces can then become patterns for the rest of the world as you get them right.

One-shotting a large map looks fast right up until everything is wrong.

Hybrid Pipeline

For now, the most honest production answer is a hybrid one. It’s what I actually spotted first time on my LinkedIn feed today, which makes it clear I’m not the only one who has noticed this.

As in various game development tasks, sometimes, some coherent asset packs are still extremely useful. They give the pipeline commercially reviewed, engine-ready families of buildings, props, materials and animations. Agents can catalogue them, assemble them, create variations, validate performance and build tools around them.

Generated assets can provide custom characters, vehicles, props and visual sources that don’t exist in the pack. In-engine geometry is often the fastest answer for terrain, collision, greybox structures and gameplay-specific pieces. Blender scripts are excellent for deterministic changes and repair. A focused amount of targeted human work can solve the final deformation, paint, composition or animation issue that would otherwise consume days of agent experimentation.

That mixture isn’t a failure to achieve “pure AI game development.” Purity is not the product, and honestly things will still take time to get to pure purity on it. The game is the product.

What is still changing is the ratio. I don’t need to personally execute every technical step in Blender or the engine. I can direct the quality, choose the source, reject weak passes and ask the pipeline to reproduce the accepted solution across libraries. The human work moves upward and becomes more selective, even when it doesn’t disappear.

This hybridization will probably matter less in some lanes as generation becomes more controllable. Human correction could over time probably shrink as tools learn to preserve topology, materials, rigs and style through iteration. But I wouldn’t plan a current project around “probably.” Today, the hybrid route is how I get further without quietly lowering the quality bar.

Open Models are Close

I’ve also been testing locally runnable and openly released models through hosted services, including TRELLIS.2 and Hunyuan3D through online platforms giving me access to them for testing.

Both show how quickly the base technology is moving. TRELLIS.2 is designed around a representation that can handle complex topology, open surfaces and PBR attributes. Hunyuan3D separates shape and PBR texture generation and describes itself as a production-oriented system. These are meaningful advances, not toys.

In my own tests, they have still sat a little behind the strongest paid models for the exact outputs I was trying to turn into game assets. “Behind” here doesn’t necessarily mean a worse demo image. It can mean less predictable geometry, another repair stage, weaker texture consistency, a more awkward interface, service restrictions or simply a longer path from result to something I can use.

When possible, running models like these locally also has a cost even when the download is free: hardware, setup, storage, maintenance, inference time, licenses and the engineering needed to connect it to the rest of the pipeline. TRELLIS.2, for example, currently documents a Linux and NVIDIA setup with at least 24 GB of GPU memory. Hunyuan’s terms and availability also need to be checked for the service, territory and intended commercial use (they have restrictions on usage in EU, etc.). “Open” is not a substitute for a license review.

Still, this gap can move quickly.

More investment, better training data, stronger controllability and production-focused tooling can change the ranking. A local model that’s slightly weaker per generation may even become the better pipeline component if it’s private, repeatable, scriptable and cheap to run many times.

My rough estimate (and also few others’ who I’ve talked about this), based only on what I’m seeing now, is that the next 6-12 months will remove several painful steps. It may take a bit more before generating, separating, correcting and iterating many ordinary game assets starts to feel boringly reliable rather than like a research project.

This isn’t a prediction that every 3D problem becomes perfect. Hair, hands, topology, thin surfaces, moving assemblies and consistent art direction will keep finding new ways to be difficult.

But I would be equally surprised if the tools looked unchanged one to two years from now.

Learnings About Assets

My current learnings about trusting an asset are practical:

• Decide how the object must behave before asking how it should look. Moving parts, breakable sections, sockets, materials and gameplay states belong in the generation contract.

• Generate or author smaller pieces when the hierarchy matters. A fused beauty model is a source, not necessarily a shippable asset.

• Keep deterministic scripts behind successful live tool work. If an agent repairs a mesh through Blender, the repair should be repeatable without reconstructing a chat session.

• Automate the numerical QA and preserve human visual QA. Topology, triangle counts, weights, pivots and package checks are machines’ work. Things like appeal, motion, scale and feel still need eyes and play.

• Build worlds through plans and slices. Prove one street, room, combat space or biome pattern before multiplying it.

• Keep more than one lane. Generated, procedural, licensed and selectively human-made sources should be able to compete rather than forcing every problem through one favorable model.

• Test the asset inside the game early. The final judge is not Blender, a provider preview or a validation report. It’s the playable build.

• Be prepared to iterate and being stubborn. Very much needed if you want quality. Luckily we Finns tend to have this thing called “Sisu”, which helps us to overcome different obstacles.

Keep these in mind. Otherwise your lessons will be time-consuming. Though, the deeper you go, the more you just need to learn through experimenting.

Scared And Excited

The strange part is that the more I do this, the less simple my opinion of AI becomes.

I discover more limitations every week: what a model misunderstands, what a tool quietly changes, which “production-ready” export is missing something basic, and how much quality can disappear between the original generation and the playable runtime.

At the same time, understanding those limitations lets me build more, not less.

Once I stop expecting one model to solve the entire problem, I can combine what different agents, services, local models, scripts, asset packs and engines are already genuinely good at. The boundary becomes clearer, and I can push it on purpose.

That makes me a bit scared, hungry, and excited at the same time.

Scared because the capability is moving faster than most production structures. Hungry because every solved step opens three more things I can attempt. Excited because a person with direction, taste and enough stubbornness can already build things that previously required a very different size of investment.

I do believe this will create structural changes in the game industry. Not because a prompt suddenly replaces a studio, but because the shape of a studio, the value of a tool, the speed of prototyping and the amount a small directed team can own are all starting to move. Art direction and QA don’t become less important in that shift. In my experience they become more important, because generated volume without judgement is just faster noise.

The magic is not one-shotting a game. It’s learning where one-shotting stops working, turning that knowledge into a pipeline, and then discovering that I can still build far more than I could before.

• What if I didn’t begin by choosing a game engine and learning its editor?

• What if, instead, I first designed the relationship between myself and AI agents that would build the game for me… and, eventually, from that go developing games with an autonomous AI pipeline?

The goal was never set to remove direction, design, fun or any form of taste from game development. It was almost the opposite, on top of pushing and reviewing capabilities of current models and AI in general for game development.

How I’m turning for this pipeline experiment, without lowering the quality bar, AI agents, game runtimes, asset tools, documentation and approval gates into one repeatable production system.

Whilst I wanted to see capabilities of current AI models, I also genuinely wanted to spend more time on the game itself, incl. e.g., player experience, product direction, art direction, systems, economy, playability, quality and the decisions that make a game fun. In this equation, the agents should take on as much of the implementation, testing, tooling, packaging and repetitive production work as possible, whilst I would stay in control.

That sounds straightforward until the work starts (especially with the intention to boldly focus on a 3D pipeline, instead of taking over any easier 2D considerations first).

A capable agent can produce a lot of code quickly, but a game is not a pile of code. It’s a runtime, an asset pipeline, a content system, a build process, a QA discipline, a release operation and, often, a live product when it gets released (if it gets released at all, as killing projects / directions fast is part of the process for getting to a release in some occasions). If those pieces, among other, aren’t joined together, speed in one place only results in creating cleanup work somewhere else.

Thus, my first real deliverable became a handbook.

Ongoing Journey

My journey is currently, at the time of writing this article, an ongoing one.

This is the first piece about that journey.

Here, on this article, I’m focusing on the handbook, as well as to the the pipeline and the technology choices around it. In my next potential articles I will go deeper into my first project-based findings from two different project try-outs, incl. what the agents actually built, which asset lanes worked or failed, how the local and hosted generation experiments behaved, and where the quality gap still is (for now; however, this assumably might chance within next let’s say 6 to 12 months).

Handbook Before a Build

The handbook began as research into a Codex-leaning game development stack. It grew quickly, past this, into something closer to an operating contract for every project that follows, which consists of multiple “full funnel” considerations, incl. “everything” from early ideation to very detailed legal frameworks, and so on.

As the handbook came together, it basically in its full format defines the order of work:

1. First we choose the platform, stack and pipeline for the specific game.

2. Then we build the smallest useful set of design and technical documents.

3. Then we prove the risky parts before committing to the larger implementation.

Only after these steps we move through other stages, incl. an MVP stage, content tools stage, backend infra, commercialization, release and potential live operations.

That order matters. Agents are excellent at expanding a specification. They are also perfectly capable of expanding the wrong specification. On top of that, agents are “good” on doing same for many other things, which just overall results to wrong results and attention points, especially if you’re just starting with a new pipeline (though, over time, as you work more and agents have more project-to-project context, you’re able to build some form of factories shooting farer from the beginning).

The handbook therefore asks agents to use gates. A new engine, paid service, account, external upload, proprietary dependency, open-source license, backend or publishing destination doesn’t quietly become part of a project because it was convenient for one task. It has to be proposed, researched and approved. The same applies when the game changes from web to native PC, from offline to online, or from a local proof to a commercial release. And, which is in my book a big thing to validate very early, no commitment to e.g., a 3D asset pipeline isn’t made before it’s proofed that models are generated or made properly, models are optimized, textures for models are made right and look correct, rigging / auto-rigging works as indented and animations also find their place over time fitting with the quality targets of a game. Depending of a case, as an extra step, it’s good on some occasions just to try out an asset pipeline integration, as early as possible, with the engine you’re using or have created with AI over a chosen tech stack. If something isn’t feasible, I’ve found myself to making e.g., re-scope, re-quality and even no-go decisions very often, along with seeing what AI models actually can do (and cannot… at least yet).

The document also tries to ask making interruptions survivable. Current context, decisions, task state, evidence, recovery instructions and the next exact action live in the repository rather than in one conversation. If an agent runs out of usage, a task pauses, or I deliberately move work to another model, the project shouldn't need to be reconstructed from memory alone.

This is less fancy than generating a dramatic boss fight from a prompt. Whilst I’d say it’s work-work, it has also been one of the most valuable parts of the work, as by that you get controlled outputs over time.

What The Pipeline Changes In Practice

The central piece is that I’m not treating an AI agent as an occasional assistant. I’m treating agents as a production layer that still needs direction, boundaries and review.

My role is closer to a combination of Product Director, Creative Director, Design Director, Technical Director and Art Director. I define what the player should feel, what the game must prove next, where the quality bar sits and which compromises are acceptable (if any).

The root agent keeps the overall project intact. Subagents or other models receive bounded “task packets” and return files, evidence, risks and a clear handoff. Sometimes subagents are used to push the root agent do something better, like 3D asset modeling through Blender MCP, which I’ve found useful as otherwise the root agent gets lazy in terms of performing against set targets, resulting to e.g., non-usable assets.

The focus of all this is autonomy without invisible / uncontrolled drift.

For example, “make the first tank” is a weak task. A stronger prompt specifies the authoritative reference, silhouette and proportion requirements, object hierarchy, pivots, triangle budgets, LODs, material rules, export formats, evidence views, allowed tools, forbidden actions and acceptance owner. The agent has freedom inside that box usually, but in some occasions it also needs to be controlled, which is in many cases the case with e.g., Codex doing something with Blender that I don’t see acceptable. More importantly, agents / models doesn’t have freedom to quietly redefine the box.

The same logic applies outside art. Gameplay parameters should live in readable configuration. Content should be made through tools that I can operate. QA should include automated play, not only code inspection. Builds should be reproducible. Licenses and provenance should be recorded from the moment a dependency or asset enters the project. Store releases, analytics, privacy, localization and live operations shouldn’t arrive as a surprise during the final week.

I’m still adjusting the handbook as the projects expose new gaps. It’s a working system, not a fancy ceremonial / political document.

Why A Web Stack Can Be Attractive

A web-first stack is compatible with agentic development.

The code is visible, modular and easy for coding models to inspect. A browser build can be launched quickly and shared without an installer. The same front-end technologies can power the game, a launcher, internal dashboards, a level editor and other WYSIWYG tools. Automated browser testing and screenshots fit naturally into the workflow. For a 2D game, a 2.5D game or a well-scoped 3D experience, that is an attractive production surface.

Three.js is especially attractive when I want control over rendering and architecture without adopting a large ready-made editor as the center of the process. Physics can come from a library such as Rapier, while gameplay data, UI and tooling remain ordinary web code. There is no need to teach a human a complicated editor if the agents can build the exact editor the game needs.

One of my first projects began with this kind of feasibility work. The browser surface was useful for proving an oblique 3D scene, deterministic update ideas, physics, performance instrumentation and the beginnings of a director-facing tool.

An early browser feasibility surface. It was useful because runtime, planning controls and evidence could live in one inspectable web tool.

Of course, the web also creates its own debt.

Proper-looking 3D has to survive very different browsers, GPUs, memory limits and input conditions. Loading (some times instant) is part of the experience. Texture compression, shader compilation, asset streaming, caching and fallback behavior matter immediately. Browser audio and pointer capture have user-gesture rules. Mobile browsers add another performance envelope. And, as you look into the possibilities, portals such as Poki or CrazyGames introduce separate SDK, advertising, save, package and approval gates.

Three.js is moving toward WebGPU through its newer renderer, with WebGL 2 as a fallback, but its own documentation still describes that renderer as experimental. Some existing material and post-processing approaches need to be rebuilt around its newer node and shading systems. That doesn’t make it unusable. It means the renderer choice itself needs a project-specific proof rather than optimism.

The web stack gives remarkable reach and control. It can also turn engine work, content tooling and compatibility work into the same problem. For some games that is exactly the freedom I want. For others it is a distraction from combat, feel and content.

How Godot Can Enter the Picture

Godot has became a solid native direction in some of my first bounded comparisons.

It is free and open source, has a capable 3D runtime, a readable scene system, strong scripting and direct exports for desktop and mobile. It gives the agent more engine-level structure than a collection of web libraries, whilst remaining much easier to automate and inspect than a closed ecosystem built around opaque binary assets.

The important part is that choosing Godot doesn’t have to mean that I personally spend every day operating the Godot editor.

In the one of my try-out’s direction, the browser can remain the director surface: map planning, parameters, asset library, validation and evidence. A narrow local bridge can compile approved data into the native Godot runtime, run the scene and return captures or metrics. Blender can sit behind another controlled boundary for asset construction. The runtime may be Godot, but the daily product and content tools can still be purpose-built around my role as I want.

The Godot choice became became very visible with e.g., character work. On this side, as I learned about 3D character modeling possibilities, I also had to opt to test a paid model generation service through its API. This service’s raw Warden character, seen below, is so far the strongest visual produced. The optimization, cleanup, rigging and animation work counts as well, especially when it comes to preserving the original model’s appearance in the playable runtime. A technically cleaner model that loses the face, materials or silhouette isn’t acceptable.

The raw character source used in one of my early game experiments, generated by a 3rd party web service. This is the strongest current appearance source, not a finished or accepted production character, on top of which I’m still trying to figure out how far I can push Codex + Blender or Claude + Blender pipelines.

Godot is not a universal answer either. Its web export currently targets WebGL 2 through the Compatibility renderer rather than the more advanced desktop renderers. Native Android, iOS and PC builds have a materially different performance and feature envelope. Some engine resources are friendly to version control, whilst imported assets and scene changes still need discipline. Agents can operate the engine, but visual inspection cannot be replaced by a successful command-line exit code.

My current view is simple: the stack should be selected per game after a short, measurable spike. A browser-native stack, Godot, or e.g., a hybrid of a web director and native runtime can all be correct. Making one of them the permanent answer before seeing the game would defeat the purpose of the pipeline.

And, indeed, nowadays I guess you can opt better already for Unity-leaning pipelines and choices as well, which is still something I’ll approach at one point, when I really need that.

Blender MCP Is A Bridge, Not an Art Director

Whilst we have all these fancy integration layers, Blender is where large part of the 3D production problems become concrete.

An MCP connection can let an agent inspect a Blender scene, execute controlled Python, change objects and materials, render evidence and export assets. This is a meaningful step toward agent-operated 3D production. It can remove a great deal of manual clicking, especially when the task can be expressed as geometry rules, transforms, validation and repeatable scripts.

But, It doesn’t magically give the agent taste, spatial consistency or a production-ready topology. I would even call some models very lazy on this, delivering just assets that go immediately to trash.

In my tests, the useful pattern has been to treat MCP as a live bridge and deterministic Blender scripts as the durable result. The project keeps a canonical Blend file, exact build and export scripts, reference renders, technical reports and validation output. If a live MCP call stalls or produces a weak change, the project doesn’t become dependent on an unrecoverable chat action.

There’s also a security point here. A Blender bridge that can execute Python is powerful by definition. It should be project-scoped, local, restricted to the minimum required integrations and treated like a development tool with real access… not like a harmless chat plugin.

The same principle will probably apply to many creative MCP tools: use the connection for interaction, but save the real work as inspectable assets, scripts and evidence. Though, even this is something to consider, I’ve seen many just looking past it and accepting the consequences, and just vibing.

The Multi-model Experiment

With one of my latest try-outs, I’m now testing another part of the pipeline: deliberately using more than one agent or model without letting ownership become ambiguous.

In this one, Codex remains responsible for the project state and integration. Claude is being tested currently in an isolated 3D asset-generation and reconstruction lane through Blender pipelines. The experiment gives Claude an authoritative six-view reference board about a wanted asset, a detailed asset contract, a separate output directory and measurable evidence requirements. It can’t overwrite the active runtime model. When the candidate is complete, Codex reviews it independently before anything enters the game.

This test-bed already has a local playable combat playground I’m iterating forward in steps. The asset lanes can change without sacrificing the working game. With agent-leaning development pipeline, I can make gameplay changes / iterations within couple minutes for some things I’m requesting, on top of which bigger systemic tasks still take… well, just few more minutes. It’s kind of magical compared to how “things were done previously”, which is something that easily hooks you to engage with AI models and potentially with their token monetization.

This is for now a safe early multi-model setup rather than being one where I’m asking two models to work vaguely on the same project. The latter is achievable, of course, but requires own handbook.

Different models may prove stronger at different kinds of reasoning, coding, visual reconstruction, research or review. I want to retain that flexibility and, well, optimism towards the future.

Claude isn’t permanently “the art model,” and Codex doesn’t need to perform every task simply because it started the repository. What matters for now is that one root agent owns coherence, every delegated task has a contract, and integration happens through evidence and approval.

A work-in-progress reconstruction candidate from the isolated Claude lane. It is useful evidence even when it isn’t yet close to the visual authority (though, it looks already better than what I managed to get through Codex + Blender pipeline past multiple iterations and try-outs).

There’s, of course, cost arguments and considerations as well. Parallel agents can shorten elapsed time, but they can also multiply context reading, token use and conflicting changes. I’s tracking delegation as an economic decision: read-heavy discovery can happen in some occasions in parallel, whilst shared files need a single writer and tasks should launch in dependency waves rather than all at once. Beyond these, I have many token economics considerations in use, to optimize the token spending, to make sure I get per focused token usage as high quality output as possible. The metric is here output quality against token spending, which I’m ongoingly optimizing as well.

Local And Open Models Can Belong In The Pipeline

Some asset pipelines can benefit from local or open-source models. I have already tested local generation lanes as part of my experiments.

The attraction is obvious: lower recurring cost, more control over inputs, the possibility of keeping confidential material on the workstation and freedom to build repeatable workflows around the model. A local image, 3D, audio or e.g., a texture model can become one stage in a larger Blender and validation pipeline rather than a separate website that must be operated manually.

However, “open” doesn’t automatically mean commercially usable, free in practice or good enough. Code, model weights, training restrictions and generated outputs may have different licenses. Hardware and setup time are real costs as well. Reproducibility can be poor, and a technically valid mesh can still be far from the art direction. For that reason I’m keeping this high level here. My possible next project-focused piece might cover the local and open model question in more detail, including where it helped, where it failed and how I’m thinking about commercial licensing, provenance, hardware and quality gates.

The Uncomfortable Truth About 3D

Based on the first tests, the technology for reliably producing proper-looking, game-ready 3D through agents is still young. This requires for anything you do lots of pushing, multiple iterations, and multiple asset pipeline try-outs to find a fitting pipeline and workflow to generate everything in masses. I’m ongoing testing and optimizing everything around it, on top of which I’m for some games just making kill decisions instead of spending time on something that isn’t just possible yet.

Yet, where we are standing, it’s already possible to produce striking concepts, rough meshes and impressive isolated results. The harder problem is, as I’ve kind of pointed out, the full chain: consistent art direction, controllable geometry, clean topology, UVs, materials, rigging, animation, LODs, collision, pivots, engine import, runtime lighting, performance and repeatability across an entire asset family.

One attractive render can hide a model that fails from the side. One correct pose can hide broken motion. One automated export can hide a weapon socket, collision shape or material that fails in play.

I don’t want to solve that by simply accommodating lower quality and declaring the limitation an aesthetic in some of my game try-outs and projects. There are valid games built around roughness, abstraction and procedural charm, but that should be a creative choice, not an excuse made after the pipeline fails.

Whilst this is the “truth” today, I’m pushing the tools against a higher bar and looking for combinations that make the quality repeatable: better references, multi-view contracts, smaller reusable asset families, deterministic finishing, independent review, runtime captures and earlier playable tests. Sometimes that will mean using an external generation service. Sometimes a local model. Sometimes direct procedural construction. Sometimes a human-made source asset may still be the most economical answer for some,

The interesting work is finding out where each boundary really sits. And, once found, using it as an advantage for a fitting project rather than for re-scoped quality target ongoingly.

Recommendations

If I were starting another AI-led game project tomorrow, I would keep these rules:

• Design the working system before the production rush. Decide who owns direction, which files are authoritative, how agents hand work over and what requires approval.

• Choose the stack for the game, not for the trend. Before heavy investments, prove the hardest rendering, input, asset, performance and shipping risks with a bounded spike.

• Demand evidence, not completion language. A playable capture, repeatable test, manifest and measured comparison are more useful than “implemented successfully.”

• Keep one root owner and isolate experiments in your first projects. Other agents and models should return candidates; they shouldn’t silently become parallel project owners. When you over time build more context and learnings, try more wilder boundaries in controlled manner.

• Separate durable artefacts from live agent actions. Save scripts, configs, canonical source files, decisions, recovery notes and the next exact step.

• Treat cost as part of design. Token use, hosted generation credits, servers, asset licenses and build infrastructure all need budgets and cheaper fallback lanes.

• Keep the player in the loop. The pipeline exists to produce a better game faster. When the process starts optimizing itself instead of the experience, it’s time to stop the madness and just play the damn build.

I’d also keep the game independent from the development agents by default. Codex, Claude or local models can help produce the game. They don’t need to be running when a player launches it, unless the design genuinely requires runtime AI.

What’s Next

One thing goes without saying, I’m exploring the AI magic. My next potential articles on the topic might move from the operating model into the projects themselves. Let’s see over time.

If I go deeper into evaluating my journey so far, I think for my readers it’s still best to look into things from lenses of pipeline laboratories: browser versus native runtime decisions, Godot and Three.js, the Blender and MCP work, Codex vs. Claude experiments, local and hosted models for different purposes, animation and reference-matching problems, and the places where I spend time proving things (and realizing the truths no-one is fancy on stating out loud).

That last part still, though, matters. A failed experiment that is recorded clearly will save more time than a successful demo that cannot be repeated.

This remains a learning process. Every part of the pipeline reveals details I hadn’t appreciated enough from the outside: browser behavior, asset provenance, animation contacts, build recovery, visual QA, context cost, licenses, store requirements and how much useful “project memory” an agent actually needs. I expect the handbook to keep changing as the work becomes more real.

For now, my strongest conclusion is that AI agents can already carry much more of game production than occasional code generation suggests. The challenging part isn’t making them busy. It’s building a system in which their work remains directed, inspectable, recoverable and aligned to quality targets to become a game. That’s the pipeline I’m iterating ongoingly.

Things like 3D pipelines will still need some maturity time. It can be some time, or little more, but seeing where we are, think we should be soon’ish there.

But, underneath all of them, there is another economy that studios rarely model directly: Trust.

Players continuously decide whether they trust the game, its systems, other players, and the people operating it. They decide e.g., whether an offer is real, whether a probability is fair, whether their progress is safe, whether rules will remain understandable, whether a purchase will keep its value, whether another player can exploit them, and whether a failure will be handled properly.

Most studios treat these things as separate UX, community, customer-support, economy, or communication problems. I think that is too narrow.

Trust behaves much more like an economy:

• It can be accumulated.

• It can be spent.

• It can be transferred.

• It can be protected.

• It can be concentrated around certain systems, features, people, and brands.

• It can also collapse much faster than it was built.

And, when trust collapses, the damage doesn’t remain inside one feature. It spreads into progression, retention, regularity, social behavior, monetization, community sentiment, and the players’ willingness to invest more time into the game.

That’s why trust shouldn’t only be understood as a soft brand concept. It should be understood as economic infrastructure.

Trust Is Economic Infrastructure

I would define trust in games as:

The player’s confidence that the game, its systems, its operators, and its participants will behave within understandable and reasonably fair expectations over time.

This doesn’t mean that everything needs to be generous. It doesn’t mean that players must always win, receive the best reward, avoid losses, or agree with every decision. A difficult game can be trusted. A highly monetized game can be trusted. A game with harsh loss systems can be trusted. Even a game built around deception between players can be trusted.

What matters is whether the player understands the contract.

An extraction shooter can say:

If you enter the raid, you may lose everything you carry.

That can be trusted if the rules are consistent.

A gacha system can say:

This reward is rare, these are the probabilities, and this protection guarantees an outcome within a defined number of attempts.

That can also be trusted if it works exactly as communicated.

A subscription can say:

You receive these benefits while active, renewal works like this, and cancellation changes these things.

Again, that can be trusted.

Trust is not the absence of friction, uncertainty, loss, scarcity, or monetization. Trust is confidence in the rules surrounding them.

And, once this confidence exists, players are more willing to make investments:

• Time investments

• Emotional investments

• Social investments

• Progression investments

• Creative investments

• Financial investments

• Identity investments

This is why trust is kind of like an infrastructure. It supports almost every other form of value creation inside the game.

Trust Has Sources and Sinks

Traditional game economies have sources and sinks. Currency enters through rewards and exits through spending. Resources enter through production and exit through e.g., crafting, upgrades, losses, and maintenance.

Trust behaves similarly.

Trust sources can include:

• Consistent rules

• Clear probabilities

• Stable pricing

• Honest communication

• Predictable progression

• Fair compensation

• Protection systems

• Reliable customer support

• Transparent changes

• Secure player-to-player interactions

• Delivery on promises

• Respect for earlier player investment

• etc.

Trust sinks can include:

• Hidden changes

• Misleading offers

• Fake discounts

• Unclear probabilities

• Unexplained nerfs

• Broken purchases

• Unstable progression rules

• Unaddressed exploits

• Inconsistent moderation

• Poor compensation

• Sudden value destruction

• Systems that punish players for believing what the game previously taught them

• etc.

The difficult part is that these sources and sinks do not have equal weight.

A game may build trust through months of stable operation, then spend a large amount of it through one badly handled economy change. A studio may communicate honestly for years, then create doubt through e.g., one misleading monetization surface. A social system may work well for thousands of trades, then become distrusted because visible scams are left unresolved.

Trust accumulation is slow. Trust destruction can be immediate. This asymmetry is important because it means trust can’t be treated like a resource that is always easy to regenerate.

Some trust losses are recoverable. Others permanently change how players interpret the game.

Predictability Is More Important Than Generosity

Studios sometimes try to repair low trust with generosity. More rewards, better events, free currency, compensation gifts, larger bundles, and temporary discounts. These can help, but generosity isn’t the same thing as trust.

A game can be generous and still feel untrustworthy. If rewards change without explanation, offers use artificial urgency, progression is constantly rebalanced, and player investments are repeatedly devalued, generosity may only make the system feel temporarily less painful.

Predictability is usually more foundational.

Players want to understand:

• What their actions produce

• What an item is worth

• How progression changes over time

• What can be lost

• What is protected

• What a purchase includes

• What happens after a mistake or failure

• Whether the same rules apply tomorrow

This doesn’t require complete certainty. Games need surprise, tension, mystery, discovery, and changing conditions. But uncertainty should be designed. It shouldn’t feel like the rules themselves are unstable. A player can enjoy uncertain outcomes when they trust the outcome system. They struggle to enjoy outcomes when they are uncertain whether the system itself is honest.

Transparent Value in Monetization

Mobile strategy example: a premium offer showing its contents, quantities, purchase limit, duration, and value structure directly inside the game.

Monetization is one of the clearest places where trust becomes economic. Every offer asks the player to believe something.

The player may need to believe that:

• The price represents real value

• The discount is genuine

• The bundle contents are useful

• The timer means what it says

• The item will retain some relevance

• The purchase will be delivered correctly

• The offer is appropriate for their progression state

• A better offer will not immediately make the purchase feel foolish

• etc.

If these beliefs repeatedly prove correct, monetization becomes easier to understand. Players don’t need to re-evaluate the entire commercial relationship every time a store surface appears.

If these beliefs repeatedly prove wrong, every offer gains friction.

The player starts asking:

• Is this actually discounted?

• Will this be cheaper tomorrow?

• Is the item about to be nerfed?

• Does this bundle contain filler?

• Am I being shown a different price because the game thinks I will pay more?

• Will this purchase become obsolete next season?

That hesitation is trust friction. It may not appear directly e.g., in an economy dashboard, but it affects conversion, purchase frequency, long-term value perception, and willingness to consider new monetization formats.

Transparent monetization doesn’t mean removing commercial design. It means making commercial design legible.

This can include:

• Exact bundle contents

• Comparable quantities

• Clear purchase limits

• Honest discount references

• Visible duration

• Upgrade or duplicate handling

• Refund and delivery expectations

• Relevance to the player’s current progression

The strongest offer isn’t always the cheapest offer. Sometimes, it’s the offer the player can evaluate without suspicion.

Note: This connects directly with what I covered in article 73 about earning monetized value through gameplay, progression, regularity, mastery, and social engagement. An earned offer only feels valuable if the player trusts the conditions through which it was earned.

Probabilities, Protection, and Perceived Fairness

Mobile RPG example: visible rarity rates, guaranteed reward progression, pity protection, and duplicate conversion before spending.

Random reward systems aren’t automatically untrustworthy. Players often enjoy randomness. Randomness creates anticipation, stories, surprise, collection tension, and different progression paths.

The trust problem begins when randomness feels unreadable, selectively communicated, or structurally unfair.

There is a major difference between:

I didn’t receive the reward I wanted.

And:

I don’t trust how the game decided what I received.

The first can be part of the entertainment. The second damages the system itself.

Protection systems help because they make negative outcomes bounded.

Examples include:

• Pity progression

• Guaranteed rarity thresholds

• Duplicate conversion

• Bad-luck protection

• Choice after repeated failures

• Visible probability changes

• Reward history

• Previewed outcome pools

• Confirmation before spending

• etc.

These systems do more than improve expected value. They create trust boundaries.

The player may still experience disappointment, but they understand that disappointment can’t continue indefinitely or outside the communicated rules.

This is important because perceived fairness is not produced only by mathematical fairness. A mathematically correct system can still feel unfair if players cannot see, understand, or verify its logic. Visibility matters, memory matters, and protection matter. And, in many cases, actually the interface communicating probability is part of the economy itself.

Player-to-Player Trust Needs Systems

PC MMORPG example: seller reputation, trade history, escrow, item inspection, delivery guarantees, and dispute protection supporting a player marketplace.

Trust doesn’t exist only between the player and the studio. It also exists between players.

This becomes especially important in games with:

• Trading

• Auction houses

• Guild treasuries

• Crafting contracts

• Player services

• Carry systems

• Resource lending

• Shared progression

• Creator marketplaces

• User-generated content economies

Many games want rich player economies, but they underestimate how much economic activity depends on trust infrastructure. If players fear scams, manipulated prices, fake items, unreliable delivery, account theft, or unresolvable disputes, the economy becomes smaller than its theoretical design.

Players trade only with friends. They avoid high-value exchanges. They move activity into external communities. They create manual reputation systems outside the game. Or, they simply stop participating.

Games can support player trust through systems such as:

• Escrow

• Verified delivery

• Item inspection

• Trade history

• Reputation signals

• Role permissions

• Transaction logs

• Price histories

• Limits for new accounts

• Dispute handling

• Reversible confirmation stages

The goal isn’t to remove every possibility of deception. In some games, deception is part of the fantasy.

The goal is to make the boundary clear.

If betrayal is intended gameplay, players should understand where betrayal is possible. If a marketplace is presented as secure infrastructure, security shouldn’t depend on the player detecting every trick manually.

That distinction protects both the fantasy and the economy.

Compensation Is Economy Design

PC extraction shooter example: restored loadout, returned insurance, rollback protection, an incident timeline, and compensation after a service failure.

Games fail. Servers go down, items disappear, purchases are delayed events break, exploits damage economies, match results are lost, and/or progression is rolled back. Players lose resources through circumstances that weren’t part of the intended game.

The question isn’t whether every failure can be prevented. The question is what the game teaches players after failure happens.

Poorly handled failures teach:

Your investment isn’t safe, and the game may not protect it.

Well-handled failures teach:

The system failed, but the relationship still works.

This is why compensation is economy design, not only customer support. Compensation determines how much trust is returned after the game has consumed it through failure.

Good recovery can include:

• Restoring the actual lost value

• Returning insured or protected items

• Explaining what happened

• Showing the recovery timeline

• Applying compensation consistently

• Differentiating affected and unaffected players where appropriate

• Protecting players from having to prove obvious system failures individually

• Giving additional value when the disruption created meaningful opportunity cost

The amount matters, but the logic matters more. An arbitrary gift can feel disconnected from the loss. A recovery that clearly maps to what happened feels like the system understands the damage. Speed also matters.

Silence creates speculation. Speculation spreads distrust beyond the players directly affected. Once players believe that losses may not be recognized, they begin reducing future investment before another failure even happens.

The economy then suffers twice:

• First from the incident.

• Then from players protecting themselves against the next one.

Social Trust and Shared Ownership

PC strategy example: visible contributions, treasury history, withdrawal permissions, proposals, voting, and safeguarded group purchases.

Social systems often ask players to share value before giving them enough tools to trust how that value is controlled. Guild members contribute currency, items, time, event progress, territory, crafting materials, strategic information, and social labor.

Yet, in many games, visibility and accountability remain surprisingly limited:

• Who contributed?

• Who withdrew?

• Who changed permissions?

• Who proposed the purchase?

• Who benefits from the result?

• Who can reverse a mistake?

When these questions are difficult to answer, social trust depends too heavily on personal relationships and external tools. That can work for small groups, but it scales poorly.

Social trust systems can include:

• Contribution histories

• Treasury ledgers

• Role-based permissions

• Withdrawal limits

• Voting thresholds

• Proposal systems

• Audit trails

• Shared purchase safeguards

• Leadership succession rules

• Recovery from inactive or abusive leadership

These systems may look administrative, but they create gameplay. They allow groups to take larger risks, pool more resources, plan further ahead, and build more meaningful shared ownership. Trust expands the scale of cooperation.

Without trust, players optimize around individual safety. With trust, they can create institutions. That is a major difference for e.g., guilds, alliances, clans, creator groups, and persistent social worlds.

Trust Across Progression and Live Operations

Players also build expectations through progression. Every system teaches them what investment means.

If upgrading a character is consistently valuable, players trust upgrades. If collecting a category repeatedly leads to devaluation, players become cautious. If battle pass rewards retain relevance, players trust future passes more. If seasonal resets respect long-term investment, players are more willing to begin the next season. This means progression design has a trust memory.

Players remember:

• What happened to earlier investments

• Whether previous promises were kept

• How often systems were replaced

• Whether catch-up invalidated effort

• Whether balance changes respected sunk resources

• Whether endgame goals remained meaningful

• Whether paid progression retained relevance

• etc.

This is one reason why technically reasonable changes can still create negative reactions. The studio may evaluate the new system by its future performance. Players evaluate it through the history of what they already invested. Both views matter.

A progression change isn’t only a new mathematical model. It’s also a renegotiation of the relationship between the game and existing players. Live operations should treat it that way.

Trust Can Be Spent, But It Cannot Be Sold

Strong games sometimes have enough accumulated trust to make difficult decisions. They can rebalance economies, remove exploits, change progression, increase prices, retire content, reduce overpowered rewards, delay features, reset systems, and ask players to accept temporary inconvenience for long-term health. This is trust being spent.

Players may not like the decision, but they are willing to believe that there’s a reasonable explanation behind it.

The danger begins when studios mistake this tolerance for unlimited permission. Trust isn’t a permanent entitlement. It can’t simply be converted into short-term revenue over and over again.

A studio may get away with one aggressive offer, one poor communication cycle, one underwhelming update, or one disruptive economy change because players still trust the broader relationship. But that doesn’t mean the decision was free. It may have consumed trust that was needed later.

This creates a hidden form of economic debt:

• The dashboard may show successful revenue.

• The community may show manageable sentiment.

• Retention may not move immediately.

Yet, the player’s threshold for the next mistake has changed. That’s why short-term performance can hide long-term trust consumption.

Measuring Trust Indirectly

Trust is difficult to reduce into one metric. That doesn’t mean it can’t be observed.

Possible trust signals include:

• Offer hesitation and delayed conversion

• Reduced willingness to pre-purchase

• Lower participation in e.g., random reward systems

• Increased refund behavior

• Lower marketplace activity

• More external price checking

• Increased support contacts before purchases

• Players holding resources instead of investing them

• Declining guild contributions

• Reduced adoption of new progression systems

• Stronger negative response to small changes

• Players waiting to see whether others are harmed first

• etc.

These behaviors can look unrelated. Together, they may indicate that players are protecting themselves.

And self-protection is often what low trust looks like inside a game economy:

• Players keep currency liquid.

• They avoid long-term commitments.

• They purchase only proven value.

• They reduce social exposure.

• They wait before adopting new systems.

• They stop believing future promises until the results are visible.

This is economically rational behavior when trust is low.

The Risks of Designing Around Trust

Trust shouldn’t become another manipulative optimization surface.

The goal isn’t to manufacture the appearance of fairness while preserving hidden systems that work against the player.

There are several risks:

• Trust theatre: showing badges, guarantees, or transparency language without meaningful protection

• Selective transparency: revealing favorable information while hiding important conditions

• Reputation abuse: allowing coordinated groups to manipulate trust signals

• Overprotection: removing uncertainty, responsibility, or meaningful risk from gameplay

• Inconsistent recovery: compensating visible groups while ignoring quieter affected players

• Trust segmentation: giving clearer or fairer treatment only to high-value players

• Communication inflation: explaining everything so often that important messages lose weight

Trust systems need to be real:

• A guarantee should guarantee something.

• A reputation signal should be difficult to manipulate.

• A compensation process should recognize actual damage.

• A transparent offer should provide information that helps the player make a decision, not only info that helps the game close the sale.

Otherwise, the trust layer becomes another trust sink.

Why Trust as a Game Economy Matters

Games ask players to invest continuously. They ask for time, attention, learning, emotion, relationships, identity, creativity, and money. The deeper the game becomes, the more of these investments begin to overlap. Trust is what allows the player to make those investments without evaluating every system as a potential threat.

When trust is high:

• Players commit further into progression

• Players participate more actively in economies

• Players experiment with new systems

• Players make longer-term purchases

• Players cooperate with more people

• Players tolerate reasonable uncertainty

• Players recover from failures more easily

• Players believe that future investment may still matter

When trust is low, the opposite happens:

• Players become defensive.

• They hoard.

• They wait.

• They avoid.

• They reduce social and financial exposure.

• They interpret ambiguity against the game because earlier experience taught them to do so.

That’s why trust should be designed, protected, monitored, and repaired like an economy. Not because trust should be monetized directly. But because almost every sustainable form of monetization depends on it.

The strongest games don’t simply convince players to spend. They create systems in which players feel safe investing more of themselves. And, in long-running games, that may be one of the most valuable economies of all.

That’s the basic version of earning.

It works. It’s familiar. It’s understandable. And, in many games, it’s still one of the cleanest ways to connect engagement and monetization without forcing every valuable moment into a direct payment moment.

But, I think, the industry often stops too early here. Because, earning through in-game economy is only one way of letting players earn monetized value. It’s not the whole design space.

There are more advanced ways of doing the same thing:

• Players can earn better offers.

• Players can earn discounts.

• Players can earn subscription access.

• Players can earn VIP eligibility.

• Players can earn premium tier openings.

• Players can earn exclusive purchase rights.

• Players can earn temporary monetized utilities.

• Players can earn monetization surfaces themselves.

This differentiation matters. How? Because, once the monetized part of the game becomes earnable through gameplay, progression, meta systems, social systems, and feature engagement, monetization stops being only a store layer sitting on top of the game. It becomes part of the game’s progression language.

Not just:

Play → earn currency → buy item.

Instead:

Play → prove intent → unlock better commercial possibilities.

That is a very different design philosophy.

The Basic Model Is Currency Earning

The most common model is simple. The player plays the game, earns currency, and eventually spends that currency on something valuable.

This can be, e.g.,:

• Soft currency

• Premium currency

• Event currency

• Crafting materials

• Battle pass XP / currency / points

• (Store) tokens

• Guild points

• Loyalty points

• Resource fragments

This model is useful because it creates a familiar bridge between engagement and value. The player understands that time, skill, attention, or consistency creates progress. The developer understands how to price the economy, tune the earning curve, and control the pacing of value creation.

But there is also a limitation. Currency earning tends to turn monetized value into an economic conversion problem. The player isn’t really earning the monetized surface. They’re earning a substitute for purchasing power, which might get you access to the monetized surface fully or lightly.

That may sound like a small difference, but it’s not.

In many cases, a currency system asks:

How much value can the player earn before they should pay?

A more advanced earning system asks:

What commercial relationship has the player earned the right to participate in?

That question opens up much more interesting design space.

Earning System

I would define this as:

A system where gameplay, progression, behavior, loyalty, social participation, or meta-system engagement unlocks monetized benefits, monetized access, monetized options, or monetized rights that would otherwise be unavailable, weaker, more expensive, or less personalized.

This isn’t just “free stuff”. That is an important note. If the system is only giving away paid value without any strategy, it’s discounting. If it’s creating a more meaningful relationship between engagement and monetization, it can become a retention, conversion, loyalty, regularity, and personalization system at the same time.

The player should not feel:

The game is begging me to buy.

The player should feel:

I have earned a better way to engage with the game.

That’s where the concept becomes more engaging, which might eventually feed the monetization’s performance as well.

Earning Discounts and Discount Tickets

Mobile puzzle example: an earned discount ticket connected to regularity and mastery.

The most obvious version is discount earning.

A player completes milestones, reaches progression thresholds, participates in events, returns regularly, helps a guild complete a goal, plays a specific mode, or engages with a new feature. As a result, they earn a discount ticket, discount token, personalized offer reduction, store coupon, bundle modifier, or limited-time price improvement.

On the surface, this sounds simple: play more, get cheaper stuff.

But the better version is more nuanced. Discounts shouldn’t only reward activity. They should reward meaningful intent.

For example:

• A player who upgrades the same hero repeatedly earns a discount on that hero’s premium skin.

• A player who participates in a new mode earns a discount for a mode-specific starter bundle.

• A player who returns for multiple days earns a limited discount on a reactivation bundle.

• A player who contributes to a guild milestone earns a group-related offer.

• A player who reaches a deep progression point earns a discount on a long-term convenience feature.

• A player who tries a feature but doesn’t convert earns a second-chance offer that is cheaper, smaller, or more relevant.

This is much more interesting than general discounting because the discount becomes contextual. It’s tied to player behavior. It’s earned through interaction. It can feel like recognition instead of random price pressure.

The danger is also obvious.

If players learn that everything becomes cheaper by waiting, you have trained them not to buy. If players learn that weak engagement produces strong discounts, you have trained the wrong behavior. If players learn that discounts are fake, inflated, or always available, the system loses trust.

So, to avoid basic mistakes, discount earning should be designed around:

• Specific behaviors

• Clear eligibility

• Real value

• Limited frequency

• Personal relevance

• Non-destructive pricing

The discount should feel like the game saying:

You have reached a moment where this offer makes more sense now.

Not:

Please buy, we are lowering the price again.

Earning Subscription or VIP Access

Mobile strategy example: a season milestone opening a VIP/subscription trial.

The second major opportunity is earning subscription and/or VIP access.

Most subscription systems are still built around a very static idea. Subscribe, get benefits. Pay monthly, receive the package. Upgrade tier, receive better package. Cancel, lose the benefits. That’s understandable. It’s clean commercially.

But, games can do something more dynamic because games already have progression systems, behavior data, social structures, and long-term engagement patterns.

Players could earn:

• Temporary VIP access

• Subscription trial days

• Subscription tier openings

• Reduced subscription entry prices

• Upgrade eligibility

• VIP streak protection

• Partial subscription benefits

• Group subscription rewards

• Seasonal subscription boosts

• Premium feature unlock periods

The important idea is that subscription doesn’t need to be only a purchase decision. It can also be a progression destination.

For example, a player could earn three days of VIP by completing a difficult event chain. Another player could unlock eligibility for a higher subscription tier only after reaching a certain account level. A guild could collectively earn a one-week VIP trial for members who contributed meaningfully during a season. A highly regular player could unlock a discounted monthly subscription offer because their behavior already indicates that the benefits would be relevant.

This changes the psychology of subscription. Instead of asking the player to imagine the value of VIP from outside the system, the game lets the player experience it from inside the system. This is effective because subscription value is often abstract before the player has lived with it. Daily rewards, faster progression, exclusive cosmetics, queue priority, extra slots, expanded storage, bonus missions, ad removal, premium event access, convenience features, and enhanced social tools can all look small when listed in a store. But, when those benefits touch the player’s actual routine, they become easier to understand.

This is especially powerful for regular players who have not yet monetized. They may not be unwilling to pay. They may simply not have had a reason that felt concrete enough.

Note: Interested about what I’ve covered about Regularity when it comes to finding more about regular players and their behavior? Check out my article here (https://gamesalchemy.substack.com/p/71-regularity):

Earned VIP access can create that reason without forcing the conversion too early.

Note: Interested to read what else I’ve covered relating to subscriptions? Check out these articles for starters:

Earning the Right to Buy

PC MMORPG example: mastery-based purchase rights for a prestige vendor.

Another underused model is earning purchase rights.

This can sound strange at first because most monetization design tries to reduce friction. If the player wants to buy, why make them earn the right to buy? But in some systems, earned purchase rights can increase perceived value, reduce store noise, and make monetized items feel more integrated into progression.

Examples:

• A cosmetic becomes purchasable only after mastering the related character.

• A prestige bundle unlocks only after reaching a season rank.

• A founder-style offer opens only after participating in a new feature’s early period.

• A high-value convenience item becomes available only after the player has reached the point where it actually solves a real problem.

• A premium upgrade path opens only after a player has proven commitment to a mode.

• A subscription tier becomes visible only when the player has outgrown the lower tier.

This isn’t about hiding monetization to be clever. It’s about sequencing monetization according to readiness.

Many games show players too much, too early. The store becomes a wall of unrelated commercial surfaces. The player sees offers for systems they don’t yet understand, cosmetics for characters they don’t care about, bundles for modes they haven’t adopted, and subscriptions for routines they haven’t built.

Earned purchase rights can make monetization feel less like a supermarket and more like an achievement path.

You played this. You mastered this. You joined this. You committed to this. Now this premium option is relevant.

That can be more elegant than constantly pushing the same offers to everyone.

Earning Better Store Logic

Mobile simulation example: earned store flexibility, offer reservation, rerolling, and loyalty boost logic.

Another way to think about this is that players can earn better store logic. Not just better prices. Better relevance.

For example, a player who has engaged deeply with one archetype shouldn’t see the same store as a player who rotates between many archetypes. A player who plays socially shouldn’t see the same offers as a solo optimizer. A player who values cosmetics shouldn’t be treated exactly like a player who values progression convenience. A player who comes back during events shouldn’t be treated exactly like a player with daily regularity.

The earning layer could unlock:

• More relevant offer slots

• More personalized bundles

• Choice-based offers

• Build-your-own bundles

• Delayed payment windows

• Loyalty multipliers

• Store rerolls

• Offer reservations

• Upgrade paths

• Trade-in systems

This is good because the player isn’t only earning an item. They’re earning a better commercial interface. For example, a player could earn the ability to reserve an offer for 48 hours. Another player could earn one monthly bundle reroll. Another could earn the right to convert an unused discount into a different category. Another could earn a loyalty multiplier on direct-to-consumer web store purchases, if the ecosystem supports it. This can make monetization feel more player-centric without simply lowering prices.

In many cases, flexibility may be more valuable than discounting. A player may not need a 20% cheaper bundle. They may need the bundle to contain the right character, the right currency, the right upgrade material, or the right timing.

Earned store logic can solve that.

Earning Monetized Features Temporarily

PC extraction shooter example: squad engagement unlocking insurance, gear discounts, and premium stash access.

Games can also let players earn temporary access to monetized features.

This is different from earning currency and different from earning a discount. The player earns the use of a feature that normally belongs to a paid layer.

Examples:

• Temporary Ad removal

• Extra inventory slots for a weekend

• Premium queue access for an event

• One-time auto-claim

• One-week advanced analytics for strategy games

• Temporary crafting acceleration

• Extra loadout slots

• Premium matchmaking filters

• Additional social slots

• Expanded guild tools

This can work well when the feature is hard to understand before use.

Some convenience features aren’t emotionally powerful in a store description. They become powerful only after the player experiences how they reduce friction. A temporary earned unlock can act as a playable demonstration.

But again, there is a design risk. Like, for example, if the temporary access is too generous, it may replace purchase. If it’s too weak, it may fail to teach value. If it’s given at the wrong moment, the player may not notice it.

The best timing is usually when the feature solves an active problem:

• Don’t give extra storage before the player cares about storage.

• Don’t give faster crafting before crafting has become a bottleneck.

• Don’t give advanced guild tools before the player has a guild role.

• Don’t give premium matchmaking filters before matchmaking quality matters.

Earned feature access should arrive when the player can feel the contrast.

Earning Social Monetized Value

PC strategy/social example: guild engagement opening optional group offers without forcing social pressure.

There is also a social version of this, in which players can earn monetized value together.

This can include:

• Guild discount tickets

• Team store unlocks

• Group subscription trials

• Shared VIP weekends

• Clan bundle eligibility

• Co-op challenge coupons

• Referral-based offer upgrades

• Community milestone rewards

• Spectator-driven boosts

• Creator-linked store benefits

This has a different emotional texture than individual earning. When a group earns monetized value together, the offer can become part of the social story. The guild didn’t just earn resources. The guild earned access. The team didn’t just complete a task. The team opened a better commercial opportunity. The community didn’t just generate activity. The community changed the reward surface.

This is especially relevant for games with clans, guilds, alliances, parties, creator communities, and spectator ecosystems.

The key is to avoid turning social pressure into monetization pressure.

If one player’s payment is required for everyone else to benefit, the system can become socially uncomfortable. If the group earns the opening together and each player can choose privately whether to act on it, the system is cleaner.

The social layer should create relevance, pride, and timing. It should not create shame.

Note: Interested about social monetization itself? Check out what I’ve written about the topic in these articles:

Earning Payment Flexibility

One of the more interesting future directions isn’t earning cheaper value, but earning more flexible payment structures.

This can include:

• Installment-style access

• Prepaid subscription extensions

• Delayed purchase windows

• Trial-to-paid (upgrade) paths

• Earned renewal protection

• Tier upgrade credits

• Pause-and-resume rights

• Loyalty-based grace periods

• Commitment discounts

• Regional price-sensitive offer formats

This isn’t equally available on every platform, and developers need to work within e.g., platform, legal, tax, and consumer protection constraints. But, conceptually, the design space could be important.

Some players aren’t blocked by value. They’re blocked by timing, commitment, trust, liquidity, or uncertainty. An earned monetization system can respond to that.

A highly regular player might earn a better long-term subscription offer. A returning player might earn a prepaid VIP extension instead of an auto-renewing offer. A seasonal player might earn a one-season commitment price. A player who has already purchased several related items might earn a clean upgrade credit into a larger bundle.

This isn’t just pricing design. It’s relationship design.

The game is saying:

Because of how you engage, we can offer you a better structure.

That can be very powerful if done transparently.

Earning Through Meta Systems

The most natural home for this design isn’t always the store. It’s the meta.

Progression systems, achievement systems, mastery systems, collection systems, event systems, guild systems, battle pass systems, regularity systems, and long-term account systems are all better places to originate earned monetized value than the store itself.

Why? Because, the store is where the player evaluates the offer. The meta is where the player earns the meaning of the offer.

A discount earned through a mastery path feels different from a discount randomly shown in a pop-up. A VIP trial earned through a season milestone feels different from a generic free trial. A premium tier opening earned through long-term progression feels different from a store tab asking the player to upgrade on day one.

The same commercial value can feel completely different depending on where it comes from. This is why I think earned monetized value should be designed as a systems layer, not only a monetization tactic.

The earning source matters:

• Gameplay mastery creates one meaning.

• Progression depth creates another.

• Regularity creates another.

• Social contribution creates another.

• Feature adoption creates another.

• Seasonal participation creates another.

• Comeback behavior creates another.

Each source can unlock a different kind of monetized value.

The Design Principle: Earned Relevance

The best version of this isn’t “earn discounts”. The best version is earned relevance.

A player should earn monetized value that makes sense because of who they’re becoming inside the game.

• If they’re becoming a collector, they earn better collection offers.

• If they’re becoming a competitor, they earn e.g., competitive cosmetic prestige and event access.

• If they’re becoming a guild contributor, they earn group-related value.

• If they’re becoming highly regular, they earn subscription opportunities.

• If they’re becoming a mode specialist, they earn mode-specific premium openings.

• If they’re becoming a returning player, they earn recovery paths.

• If they’re becoming a creator, they earn e.g., creator-linked commercial tools.

This is more respectful than generic monetization because it listens to behavior. It also has likely better business logic because the offer is attached to demonstrated interest.

The player doesn’t receive value because the game wants to push revenue today. The player receives value because the game has observed a meaningful moment. That’s a much healthier foundation.

The Risks

There are real risks.

• The first risk is discount dependency. If players learn that engagement always produces discounts, pricing discipline breaks.

• The second risk is entitlement inflation. If every system gives monetized benefits, players may start seeing paid value as something that should always be earned for free.

• The third risk is complexity. Too many tickets, coupons, trials, store modifiers, and unlock rights can make the economy harder to understand than it needs to be.

• The fourth risk is unfairness. If some players receive better commercial opportunities without clear logic, others may feel punished.

• The fifth risk is regulatory and platform friction. Subscription offers, discounting, auto-renewal, prepaid access, tiering, regional pricing, and external store ecosystems all have constraints. The design has to respect those constraints from the beginning.

• The sixth risk is bad personalization. A personalized offer that feels relevant is good. A personalized offer that feels manipulative isn’t.

So, this means, that the system needs rules.

Earning systems should be:

• Transparent enough to trust

• Limited enough to protect price integrity

• Contextual enough to feel relevant

• Useful enough to teach value

• Rare enough to feel earned

• Simple enough to understand

• Optional enough to avoid pressure

This isn’t a place for messy dark-pattern design. If anything, earned monetized value requires more care than normal store design because it sits closer to the player’s emotional relationship with the game.

Why Earning Monetized Value Matters

The future of game monetization isn’t only about inventing new things to sell. It’s also about inventing better ways for players to arrive at monetized value.

Many games still treat monetization as a separate destination. The player plays the game, then eventually gets sent to the store. The store tries to convert them. The game continues.

Stronger systems can make monetization part of the journey. Not in an aggressive way. In a more integrated way.

The game can say:

• You played enough to understand this.

• You progressed enough to need this.

• You contributed enough to unlock this.

• You returned enough to deserve this.

• You specialized enough to want this.

• You became regular enough for this to make sense.

That’s more interesting for a player than a static store. It’s also more human. Because, players don’t all reach monetization readiness at the same time, through the same motivations, or with the same needs. Some players need trust. Some need context. Some need proof. Some need social meaning. Some need timing. Some need flexibility. Some need to feel that the game recognizes their behavior. Earning monetized value can serve all of those needs.

The basic way is still valid. Let players earn currency. Let them spend it. Let the economy create clear paths between engagement and value. But don’t stop there.

There is a larger opportunity in letting players earn the monetized parts of the game more directly:

• Discount tickets

• VIP openings

• Subscription trials

• Premium tier eligibility

• Store flexibility

• Purchase rights

• Temporary paid-feature access

• Group offers

• Upgrade credits

• Offer reservations

• Payment flexibility

• Personalized commercial surfaces

These aren’t just monetization tricks. Designed well, they can become retention systems, regularity systems, loyalty systems, progression systems, social systems, and personalization systems.

The strongest version isn’t about making paid value cheaper. It’s about making paid value earned, contextual, and better timed.

And, if games are already systems for shaping behavior, progress, identity, and belonging, then monetization should probably learn to participate in those systems more smartly.

When most people hear the term “UGC”, they think about:

• Cosmetics

• Mods

• Sandboxes

• Level editors

• Creator tools

• Player-made maps

• Games inside games / platforms

And honestly, that’s fair. That’s what UGC has largely meant for the past two decades.

We’ve seen massive successes built around that model:

• Roblox

• Fortnite Creative

• Minecraft

• Skyrim modding

• Garry’s Mod

• Counter-Strike

• Halo Forge

• Dreams

• VRChat

But those ecosystems are incredibly difficult to build. You’re not just building a game anymore.

You’re building:

• Creator tools

• Moderation systems

• Marketplace infra

• Discovery algorithms

• Social platforms

• Distribution ecosystems

• Monetization frameworks

• Live-service operations at platform scale

And the reality is simple. Most studios are never going to become Roblox. Most studios are never going to become Epic Games. Most studios are never going to build the next Minecraft. And for every legendary Skyrim-style modding ecosystem, there are lots of of abandoned editors, unsupported mod kits, and creator systems that never generated meaningful retention or long-term value.

The industry has started treating UGC as if the only future is players becoming developers, or developers needing to mitigate their strategies inside current UGC ecosystems. I don’t think that’s true. The future isn’t just Roblox.

I think the future of UGC is systemic, collective, persistent and deeply integrated into “the living simulation of the game world” itself. That’s where Collective Reality Systems come in.

Collective Reality Systems

Collective Reality Systems are systemic game architectures where players continuously shape e.g., the world, narrative, ecosystems, AI behavior, encounters, economies, social systems, and progression together synchronously and/or asynchronously.

Instead of players explicitly creating content through editors, they influence systems that generate emergent experiences. That’s a very different philosophy from traditional UGC.

Traditional UGC says:

Players create content.

Collective Reality Systems say:

Players influence systemic reality.

And that distinction changes everything.

Because now:

• The world itself becomes the content surface

• Multiplayer becomes part of the simulation

• Persistence becomes memory

• Community behavior becomes gameplay

• AI becomes adaptive ecosystem design

• Emergence replaces static authored repetition

Players don’t just play the world anymore. They deform it. Collectively.

The Shift From Content Creation To Systemic Influence

Most traditional UGC focuses on explicit creation. Build a map, make a skin, script a game mode, and/or upload a mod.

Collective Reality Systems focus on indirect authorship.

Players influence things such as:

• World states

• Ecosystems

• AI behavior

• Narrative progression

• Environmental transformation

• Encounter evolution

• Event escalation

• Economy systems

• Social systems and structures

Players aren’t necessarily “making content” (unless scoped to that inside to a system, which is part of the collective reality approach). They’re shaping a living system. And that’s a much more scalable fantasy for e.g., many modern AAA games. Especially immersive ones.

The Different Layers Of Collective Reality Systems

So, what are these systems? Based on my research, there’s plenty of examples to give, which I’ve listed below. And, when you’re looking into this list, keep in mind that these systems can exist individually or combine together into larger ecosystems.

Collective World States

• Players collectively shape the world state over time.

• Things such as regions, factions and anomalies evolve based on player actions.

• The world can unlock, collapse or transform globally.

• Shared progression creates persistent community impact.

Environment Manipulation / UGC

• World / environment layouts evolve through player interaction; AND/OR players modify existing spaces, routes and mission areas.

• Environmental changes that affect gameplay and exploration.

• Controlled UGC systems maintain curated world quality.

Collective Environment & World States

• Players / communities shape both environments and global progression.

• Things such as world corruption, weather and territories evolve dynamically.

• Local actions contribute to larger systemic world changes.

• Persistent world states create shared live experiences.

AI-As-Ecosystem

• AI evolves as part of a living world ecosystem.

• The world state influences enemy behavior and adaptation.

• Collective player actions shape the ecosystem over time.

• AI becomes part of the “narrative” and “progression” loop.

Collective Narrative Systems

• Story progression reacts to collective player behavior.

• Narrative paths evolve through global player / community actions.

• Players indirectly influence future story developments.

• Shared narratives creates evolving world (and its history).

Mission / Encounter UGC

• Players influence how encounters and missions emerge.

• Systems generate evolving challenges from player activity.

• Encounters can e.g., spread, mutate and persist globally.

• Community behavior shapes future mission ecosystems.

Events UGC

• World events emerge dynamically from player actions.

• Events evolve based on participation, outcomes and interplay with other systems.

• Global systems react to victories, failures and activity.

• Players collectively influence live world / events pacing.

Sync Echo Systems

• Players experience real-time synchronized world reactions, and/or take part in them synchronously or asynchronously.

• Actions instantly affect nearby players and environments.

• Echo systems spread events, signals and disturbances live.

• Multiplayer actions create shared emergent moments.

Ghosts / Residue UGC

• Players leave persistent traces within the world.

• Things such as ghosts, loot and memories travel between players.

• Residues create asynchronous shared experiences.

• Player actions become discoverable world content.

Faction / Social UGC

• Communities shape factions, influence and e.g., territory control.

• Social structures evolve through player collaboration.

• Group actions affect e.g., world politics and progression.

• Collective identity becomes part of the world state.

Market / Economy UGC

• Players drive economy, trade and resource ecosystems.

• Open, focused or mixed ecosystems.

• Supply, demand and e.g., scarcity evolve dynamically.

• Economic activity impacts world systems and progression.

• Markets become player-created systemic content.

Settlement / Hub UGC

• Shared hubs evolve through player progression and activity.

• Communities shape social spaces and functionality.

• Hubs visually and systemically reflect player behavior.

• Persistent settlements create shared long-term identity.

AI Design / Manipulation UGC

• Players create, mutate or influence AI entities.

• AI behaviors evolve through systemic experimentation.

• Created entities can spread into shared gameplay spaces.

• Enemy ecosystems emerge from player-driven manipulation.

Companion / AI Partner UGC

• Players spahe evolving AI companions over time.

• Companion behavior adapts to player choices and actions.

• AI partners can develop unique identities and roles.

• Companions become persistent and player-generated content.

Character UGC

• Players create unique identities through systemic customization.

• Characters can evolve procedurally through player-made choices.

• Visuals, traits and e.g., behaviors adapt dynamically.

• Character creation becomes part of the shared ecosystem.

Crafting UGC

• Players generate weapons, gear and artifacts systemically.

• Crafting combines procedural and player-driven creation.

• Generated items influence gameplay and e.g., world economies.

• Crafted content can spread between players globally.

Ritual UGC

• Players perform rituals that alter the world state.

• Rituals can unlock e.g., events, anomalies or transformations.

• Collective participation amplifies systemic outcomes.

• Ritual systems create emergent shared experiences.

Skill / Talent UGC

• Players shape unique builds through open progression systems.

• Skill combinations generate emergent playstyles and identities.

• Build diversity evolves through community experimentation.

• Talent systems indirectly create player-generated archetypes.

Why This Matters

Everyone knows (or should, at least, by now) modern AAA development is hitting a wall. Budgets are exploding. Development cycles are getting longer. Content pipelines are collapsing under the weight of infinite engagement expectations. Studios are trying to solve retention through more handcrafted content.

That doesn’t scale forever.

Especially if your game relies heavily on e.g.,:

• Cinematics

• Voice acting

• Narrative production

• Custom animation

• High-end environments

• Scripted sequences

You can’t outproduce player appetite infinitely. Or, well, with Gen AI you could to some / far extend probably serve players through expensive content, but the use of it can backfire in multiple ways, if executed poorly.

In terms of providing smarter solutions, for everyone’s consideration, systemic reality systems change the equation.

Because now, through it things happen:

• Players generate e.g., pressure

• Communities generate the variance

• AI generates adaptation

• Persistence generates memory

• Systems generate evolution

The game creates long-term engagement through interaction itself, and not only through content drops.

The Difference

This approach doesn’t try to turn every player into a developer. That’s important. Most players don’t actually want to become level designers.

They want to:

• Leave a mark

• Affect the world

• Discover stories

• Influence outcomes

• Build identity

• Create consequences

• Feel part of something larger

Collective Reality Systems let players do exactly that, without forcing them into e.g., creator tools.

Why This Direction Can Be More Interesting For AAA

Trying to compete directly against Roblox or Fortnite Creative is brutally difficult.

Those ecosystems already have:

• Network effects

• Creator communities

• Discovery systems

• Monetization ecosystems

• Social infrastructure

• Infinite content throughput

But Collective Reality Systems open a very different strategic direction.

The value no longer comes from:

• Massive creator platforms

• User-made game quantity

• Asset marketplaces

• Endless editor tooling

It comes from:

• Emergence

• Persistence

• Shared simulation

• Ecosystem evolution

• Community pressure

• Dynamic world states

• Living multiplayer realities

That’s a much less saturated space. And honestly, a much more exciting one.

Especially for studios focused on:

• Immersion

• Atmosphere

• Narrative worlds

• Systemic gameplay

• Psychological experiences

• Persistent multiplayer ecosystems

The Future Of UGC

I don’t think traditional UGC disappears. Mods, creator tools, cosmetics, sandbox systems, and player-made experiences will continue to thrive.

But I do think the next major evolution moves away from:

Players making content.

Toward:

Players collectively shaping systemic realities.

That’s where games start feeling alive. Not because developers endlessly push handcrafted updates. But because millions of players continuously shape the same evolving simulation together.

The players become:

• The instability

• The memory

• The ecosystem pressure

• The narrative catalyst

• The evolutionary force

And that creates something far more scalable than traditional UGC. It creates collective authorship. And honestly... that might be one the most interesting future games have right now.

The games industry talks endlessly about retention. D1, D7, D14, D30, D90, D180, D360, and so on. Retention curves. Funnels. And, as the list goes on… session counts, and session times. Sometimes, in some cases, even things such as re-engagement.

Yet, strangely, one of the most important long-term engagement concepts is rarely discussed directly: Regularity.

Not retention as an event. Regularity as a behavioral state and pattern.

Why it should be discussed more? In short, because there is a major difference between a player returning to a game and a game becoming part of a player’s life and habits.

Retention and regularity are not the same thing.

A player can technically be retained while having an unstable relationship with the game. They might binge heavily during updates, disappear for days, return through obligation, or only engage when e.g., event tension spikes. From a retention dashboard perspective, things may look acceptable. From a systems perspective, the ecosystem may still be unstable.

Regularity is different. Regularity is about consistency of emotional and behavioral connection over time. It is about how naturally a game embeds itself into routines, habits, rituals, social structures, and cognitive space.

The strongest live-service games rarely survive purely because they have good retention. They survive because they build regularity.

A game that quietly becomes part of somebody’s morning coffee, lunch break, evening unwind session, weekly social gathering, or persistent mental landscape is operating at a very different level than a game that simply manages to pull players back occasionally for e.g., entertainment purposes.

This distinction matters far more than many studios realize. Because regularity creates stability. And stability creates scalability.

Retention Measures Return, Whilst Regularity Measures Life Integration

One of the more interesting things about regularity is that the industry often measures fragments of it without explicitly treating it as the central objective.

Retention partially reflects regularity. Session counts partially reflect regularity. Session times partially reflect regularity. And even things like community activity partially reflects regularity.

But these metrics are usually analyzed separately, as disconnected KPI surfaces, instead of being understood as parts of a larger behavioral system. The result of this is that many games accidentally optimize for spikes instead of rhythms.

This becomes especially visible in modern live-service ecosystems. Large updates temporarily inflate engagement. Events create bursts of activity. Reward structures attract players back into the game. Some monetization moments artificially create urgency. And the list goes on.

But underneath those spikes, the underlying behavioral regularity may actually be weak. This is why some games feel constantly alive while others feel temporarily activated.

The difference is not always retention. Often, it is cadence stability.

Session Interval Variance (SIV)

One useful way to conceptualize regularity is through something I would call Session Interval Variance, or SIV.

At a high level, SIV measures how consistent player engagement rhythms are over time. Think about two players:

Player A

• Plays eight hours on Saturday

• Disappears for four days, and returns after an update or event

Engagement for Play A is highly volatile.

Player B

• Plays twenty to thirty minutes almost every evening

• Maintains stable engagement timing

Player B naturally integrates the game into routine behavior.

Traditional metrics may value Player A heavily because total playtime is high. But, from a systems perspective, Player B represents far stronger regularity. The game has successfully synchronized itself with that player’s life rhythm.

Lower variance between play intervals often signals stronger behavioral embedding. The game no longer relies entirely on stimulation spikes or external reactivation pressure. It becomes naturally integrated into routine behavior.

This matters because routine-based engagement tends to be more resilient, emotionally sustainable, predictable, and healthier for long-term ecosystems.

Habit Persistence Score (HPS)

Retention asks whether players returned.

Habit persistence asks whether behavioral rituals survived.

There is a meaningful difference.

A player logging in every day does not necessarily mean a stable habit exists. They may simply be responding to e.g., missing rewards.

But, if players consistently participate in the same social activities, progression loops, market behaviors, guild interactions, co-op sessions, crafting routines, and such, then the game has created recurring behavioral anchors. This is where games become sticky.

Easy examples of habit persistence:

• Weekly MMO guild raid nights

• Nightly extraction runs with friends

• Morning auction house checking

• Seasonal reset / prestige preparation

• Daily community interaction during e.g., work breaks

These are not merely engagement loops anymore. Instead, they are recurring structures inside players’ lives. The strongest ecosystems often succeed because they maintain these rituals for years. Not because they maximize short-term engagement spikes.

Baseline Engagement Stability (BES)

One of the major blind spots in modern live-service design is that many ecosystems optimize around peaks instead of stability. Big events, big updates, big collaborations, and other big “beats”.

But regularity-oriented ecosystems often optimize around cadence consistency instead. This is where Baseline Engagement Stability, or BES, becomes useful.

At a high level, BES measures how stable player engagement remains without major external stimulation. In other words, it asks: "How healthy is the ecosystem when nothing extraordinary is happening?”

This matters enormously because many games unknowingly rely on continuous stimulation injections to maintain engagement. Once event cadence slows down, engagement collapses because underlying regularity was never truly established.

Healthy ecosystems tend to maintain:

• Stable concurrency

• Stable social activity

• Stable progression engagement

• Stable return behavior

• Stable community participation

Even between major updates.

Cadence Amplification Ratio (CAR)

Obviously, baseline stability alone is not enough for live-service ecosystems.

There is another important layer: How effectively do updates and events amplify existing regularity instead of artificially replacing it?

This is where something I call as Cadence Amplification Ratio, or CAR, becomes useful conceptually. CAR measures how much engagement rises during updates and events relative to the baseline regularity, or BES, of the ecosystem.

A healthy ecosystem usually has:

• A stable baseline

• Controlled amplification during updates

• Smooth stabilization afterward

An unhealthy ecosystem often has:

• Weak baseline activity

• Massive event spikes

• Rapid collapse after content consumption

The difference matters enormously. One creates long-term ecosystem health. The other creates dependency on perpetual stimulation.

This becomes especially visible in games where players are highly active during launches but psychologically disconnected between updates. The game starts feeling less like a living world and more like temporary content consumption.

The strongest ecosystems avoid this trap because updates amplify habits instead of replacing them.

Cognitive Occupancy

There is also a more abstract layer to regularity that is harder to measure directly but incredibly important: Cognitive occupancy.

This refers to how much mental and emotional space a game occupies even when players are not actively playing. Some games remain alive inside players’ minds continuously. Others disappear immediately after logout.

This often becomes visible through e.g.,:

• Discord participation

• Theorycrafting

• Community activity

• Fan culture

• Content creation

• Social discussions

• Market speculation

• Identity attachment

This layer is difficult to universally quantify because every ecosystem expresses it differently.

What matters is recognizing that these signals often move in parallel with long-term ecosystem health. In some cases, community weakening even appears before major engagement decline becomes visible inside the game itself.

Communities frequently detect ecosystem fatigue earlier than dashboards do. Because regularity is not merely mechanical. It is also emotional.

Regularity, Immersion, and Proximity Design

This is also why regularity connects deeply to immersion.

Immersion is often discussed aesthetically:

• Graphics

• Audio

• Worldbuilding

• Narrative fidelity

But behavioral immersion may actually matter more for long-term ecosystem health.

A truly immersive game maintains continuity inside the player’s cognitive world. The player never fully disconnects from it emotionally. Their relationship with the game persists between sessions.

This is also why regularity often strengthens monetization willingness in healthier ways than aggressive extraction systems do. Players who maintain stable emotional continuity with a game tend to spend more naturally over time because the ecosystem feels persistent and personally meaningful.

The relationship becomes less transactional and more infrastructural. The game starts functioning more like a long-term environment than a temporary product. This also strongly connects to proximity design.

Note: Interested about what I’ve wrote about Proximity Design? See more from below article (https://gamesalchemy.substack.com/p/59-the-power-of-proximity):

The closer a game positions itself to e.g.,:

• Emotional rhythms

• Social identity

• Cognitive habits

• Lifestyle structures

• Recurring behavioral patterns

The stronger regularity tends to become. Games stop competing purely through stimulation. They begin competing through relevance to lived experience.

Regularity Creates Predictability

This eventually leads toward one of the most important business implications of all: Predictability.

Regularity creates predictability across the ecosystem, including:

• Predictable concurrency

• Predictable economy behavior

• Predictable matchmaking quality

• Predictable social activity

• Predictable monetization

• Predictable content demand

And, predictability is one of the foundations of scalability.

A game with stable behavioral rhythms is significantly easier to:

• Operate

• Expand

• Balance

• Monetize

• Sustain long-term

Than a game built entirely around volatility spikes.

Ironically, many studios become obsessed with highly granular KPIs while overlooking the larger systemic question: Is the game actually becoming part of players’ lives?

Because ultimately, that is what many of the greatest long-term games achieved. Not merely retention, but behavioral permanence.

Ethical Regularity

There is an important ethical dimension to regularity that designers should think about more carefully. Because there is a meaningful difference between building healthy behavioral permanence and building unhealthy dependency.

Regularity itself is not inherently good.

Games can absolutely create regularity through:

• anxiety

• obligation pressure

• aggressive FOMO

• social punishment

• compulsive reward structures

• excessive scarcity pressure

• behavioral exhaustion loops

And many modern systems unfortunately do exactly that.

This is especially important to realize because regularity is psychologically powerful. Once a game successfully integrates itself into somebody’s daily rhythms, emotional structures, and routines, it begins influencing real behavioral patterns at scale.

That creates responsibility.

The healthiest forms of regularity usually emerge when players genuinely want to return because the ecosystem provides:

• comfort

• meaning

• social belonging

• emotional continuity

• self-expression

• relaxation

• mastery

• curiosity

• creative or social fulfillment

Not because players feel psychologically trapped. This distinction matters enormously.

There is a major difference between a game becoming part of somebody’s life in a healthy, enriching way vs. becoming behaviorally compulsive through pressure-driven design.

As designers, it is important to think carefully about where that line exists for each ecosystem. Because ultimately, the strongest long-term ecosystems are usually not the ones that maximize extraction.

They are the ones players genuinely want to keep living inside.

Regularity Index (RI)

This is where a larger framework like a Regularity Index, or RI, becomes useful conceptually.

Not as a single perfect KPI, but as a systems-level perspective combining:

• Cadence consistency

• Ritual persistence

• Baseline stability

• Update amplification health

• Cognitive occupancy

• Social continuity

• Behavioral predictability

The goal is not to reduce regularity into one number. The goal is to stop viewing engagement as fragmented surfaces and start understanding it as ecosystem behavior.

Because games are not only content systems. They are also behavioral systems. And the strongest behavioral systems do not merely retain attention, they become rhythms people live inside.

Even modern multiplayer games still fundamentally operate this way. Battle royales, MOBAs, extraction shooters, competitive sports games, co-op games, and even many MMOs still rely on relatively static match boundaries. The player enters a predefined social container, the system stabilizes that container for a certain amount of time, and then the container dissolves.

Procedural (fully procedural, or semi-procedural / mixed) worlds can fundamentally challenge this structure. And, well, whilst the article focuses on procedural design directions, if you think really about some of e.g., MMOs’ worlds’ scales and/or systemic directions, what I’m writing here could be very well applicable to them, with the ability to sustain persistence in the world design. Applications isn’t, this said, just in the procedural side of things, given the world scale, size, and design is proper enough.

As worlds become more larger, dynamic, procedural, adaptive, and/or systemic while possibly (not needed in all cases) having fully, or mixing, persistent handcrafted areas with evolving procedural spaces, static matchmaking starts feeling increasingly artificial. The moment players hit a loading screen or a hard lobby transition, the illusion of a living world can collapse. The multiplayer layer stops feeling like reality and starts revealing itself as infrastructure.

This is where the future of multiplayer design becomes interesting. Not because matchmaking disappears, but, because matchmaking stops behaving like “a menu system” or as “traditional system”. Instead, players move through persistent and/or procedural worlds where multiplayer groupings dynamically emerge, merge, split, and dissolve based on geography, tension, objectives, and (social) proximity. The match itself stops being the product, and the topology of social interaction becomes the product.

New Layer for Matchmaking

In my earlier article about matchmaking as the hidden engine of monetization and retention, I explored how matchmaking systems already should shape emotional pacing, progression curves, engagement loops, social tension, and monetization pressure, instead of just focusing on optimizing themselves symmetrically through skill-based means.

Most matchmaking systems today shouldn’t simply trying to create fairness. They should be aiming to support proper economy design approaches, and create e.g., emotional states. Basically, modern matchmaking should act as a hidden orchestration layer beneath the game itself.

But, even current and these “modern” systems still largely operate within “static” boundaries. They optimize players inside “predefined molds” instead of dynamically shaping the structure of multiplayer reality itself.

The next evolution goes much further.

Instead of asking: “Which players should enter this lobby?” The system should begin asking: “Which social structures should emerge inside this world right now?” This shift is what is needed for some future games, changing everything, exploring experiences and game worlds in new ways, instead of traditional ways.

The player no longer consciously enters lobbies. Instead, the world continuously orchestrates all things required, while the system behaves less like traditional matchmaking and more like an ecological simulation engine. Or, perhaps more accurately, like “an invisible multiplayer director”. Continuously shaping probabilities. Building (social) emergence instead of enforcing structure.

Note: Some of this technology could benefit from AI Game Master concept, which I’ve wrote more about here:

The World Becomes Matchmaking

Traditional multiplayer games separate the world and the matchmaking system into two different layers. The matchmaking system assembles players first, and the world is loaded afterward.

But, procedural and/or systemic multiplayer worlds invert this relationship: the world itself can become the matchmaking system. Geography and its underlying systems can start shaping things like social behavior. As this goes by, the player “density” becomes fluid. And, in many cases, specifically considering how to tie-in procedural and/or systemic world-driven experiences together in a multiplayer setting, objectives become (social) “gravity”.

In terms of the gravity pulling things together, players naturally drift toward e.g., resources, danger, “in and out” points, conflicts, trading, hubs / (social) hotspots, events, threats, rare opportunities, safe heavens, and such, as the design for a game goes.

Instead of static lobbies creating encounters around these things players are pulled towards to, the environment itself begins generating these encounters organically. The world (and procedural) layer simply stabilizes, amplifies, and orchestrates these convergences. This is in where multiplayer topology generation emerges.

Multiplayer Topology Generation

Most multiplayer games think in terms of servers, instances, and matches. Future multiplayer systems, build around procedural and/or systemic means, incl. new types of world-building methods, need to be thought as living ecosystems.

The important thing is no longer: “Who joined the server?” The important thing becomes e.g.,: “How social density flows through space and time?” This creates a very different design challenge.

Instead of just designing maps, developers begin designing e.g., social flows, migration routes, compression points, isolation corridors, density spikes, emotional pacing through geography, and more, as the needs come. The topology becomes dynamic. Like, for example, some areas become overcrowded “warzones”, others become lonely “wastelands”, trade hubs become (temporary) social centers, resource scarcity creates migration waves, environmental changes redirect “populations” naturally, and/or so on.

The multiplayer experience stops being statically authored and starts behaving more like “procedural civilization flow”.

Dynamic Social Instancing

This is where the discussed methods become truly powerful, and here’s one of this article’s selling point.

In traditional multiplayer games, lobbies are fixed objects. You enter with a predefined group → you stay with that group → you leave with that group.

In procedural, and/or, in just new types of multiplayer worlds, social groupings can become fluid. Players dynamically pack and unpack from multiplayer clusters as they move through the world.

A player entering a dense area may gradually merge into a larger social instance without ever noticing a transition. Another player moving into “remote wilderness” may slowly separate into a lower-density simulation layer. Groups moving toward common objectives may naturally converge into temporary large-scale encounters before dispersing again afterward.

The important part is that the player doesn’t feel “static” matchmade. The player feels like they’re moving through a continuous world and a living experience.

This creates something fundamentally different from traditional instancing. In some designs, as I foresee it, by right design choices, the whole experience can actually start feeling persistent, even though its social topology is constantly shifting underneath the surface. And, that’s a game-changer and a big selling-point (like, here, before this, I’m sure you’ve thought this is just simple design and dynamic framework, but I’m pretty sure you didn’t get this far thinking what’s the real unique selling point a new tech. like this could provide for your game).

(Social) Anchor Spaces

In some designs, one of the most important aspects of this “structure” is the relationship between procedural space and/or fixed environments. Like, you can have all probably just procedural in some designs, but in many cases, not everything should be procedural. And, when this comes into question, we can use these fixed spaces as (social) anchor spaces for social and other actions.

This means that fixed areas serve as stabilizing anchors for multiplayer flow, incl. cities, hubs, zones, guild zones, raid entrances, social gathering points, economic centers, narrative landmarks, and such, as the design goes.

These locations act as multiplayer “compression points”. As players move through procedural space, the world naturally funnels populations toward these anchors. This creates recurring (social) encounters without requiring static servers or predefined matches. Players repeatedly cross paths, recognize others, encounter social guilds, witness things, observe economic shifts, form temporary alliances, and such.

The world starts generating social memory naturally. Not because the game forces interactions, but, because topology itself creates recurring convergence.

Population Density Control

One of the biggest immersion problems in procedural games, in terms of risks generated by poor design, is population inconsistency. Like, a giant world can actually be and/or feel empty. Or artificial, or disconnected.

Dynamic social instancing solves this in a fascinating way. Instead of statically assigning player counts to servers, the world controls social density procedurally. Some regions intentionally become e.g., crowded, chaotic, safe, unsafe, and such. Others become e.g., isolated, quiet, survival-focused, resource-rich, and so on.

This creates emotional pacing through population flow itself. The player isn’t just traversing terrain, the player is traversing (social) states.

The Death of “the Lobby”

Ironically, the future of lobbies, in games requiring new strategies, may be about “the disappearance of lobbies” altogether. Or, more accurately, lobbies just stop being isolated waiting rooms and become embedded social states inside the world itself.

A crowded city may effectively function as a lobby. A migration route may function as a temporary matchmaking corridor. A faction warzone may organically generate large-scale PvP clustering. A remote wilderness area may intentionally dissolve players into smaller survival-focused groupings.

The lobby becomes spatial. And once that happens, indeed, multiplayer games begin feeling less like matches and more like living worlds (and in some cases even more persistent).

The future multiplayer games that truly evolve the medium may not even be the ones with the biggest maps, the most realistic graphics, or the most advanced AI NPCs. They may be the games capable of generating living social topology at scale. Worlds where players don’t simply join matches, and instead of that, they continuously flow through dynamically orchestrated reality.

Not lazy in production values, content pipelines, monetization systems, or live operations. We’ve become incredibly efficient at building retention loops, scalable economies, progression systems, optimized engagement structures, and high-frequency live ops.

But, when it comes to understanding actual human social behavior and translating that into meaningful game and systems design, we’re still operating at a surface level. Most social game design isn’t actually social. Underestimating or not prioritizing social design, among many other things, is at least partially one of the reasons why we’re seeing some of the current events taking in place in our industry.

What We Consider as Social Design?

We often “confuse” interaction with social depth.

A clan donation feature is considered social. Sending lives or decorations to another player in a puzzle game is considered social.

Snapshots from Toon Blast and June’s Journey.

Continuing, lightweight co-op events are considered social. Leaderboards are considered social. Even many so-called “community events” in games ultimately come down to players individually contributing points into a shared meter, without having players truly interacting with one another in meaningful ways.

These systems are not bad. But, they are lazy design solutions when it comes to what social truly could be in games.

Some of these systems are elegant and well-designed for what they are trying to achieve. But, when we compare them against how humans actually behave socially in the real world, the gap becomes obvious very quickly.

What We Miss?

Humans attend events to be entertained, to meet friends, to meet new people, to observe others, to gain social status, to feel part of something larger, and sometimes simply to exist around other humans. Social behavior is emotional, expressive, spontaneous, messy, and in some cases e.g., identity driven.

Most games still barely scratch the surface of this.

Ironically, some of the deepest social experiences in games still come from genres that accidentally allow human behavior to breathe naturally. MMORPGs, sandbox games, roleplay servers, and social deduction games often create stronger social memories not because their systems are more advanced, but because they create environments where players can socially live and move.

That distinction matters enormously.

Social Presence Is Underestimated Design Layer

One of the most underestimated concepts in game design is social presence. The feeling that other humans exist around you. Not just as teammates, or opponents, but as part of “a living social environment” (multiple formats of such can exist).

You can already see this desire emerging in communities around games like ARC Raiders. Many players are not only talking about extraction mechanics or combat systems. Some simply want social hubs where they can see other players existing together. They want downtime spaces, identity spaces, and ambient social environments where the world feels socially alive. This is one of the reasons, on top of deeper meaningful mid to end-game systems missing from meta side, why the game has seen ongoing “churn” in its engagement. Like literally, if you put in let’s say 100 to 150 hours, at least, past that there’s not much meaningful things to do.

Current engagement data from ARC Raiders, from SteamDB.

Humans naturally seek social presence. Social media companies understood this years ago (although, now, I don’t think some of them anymore does, like when you look into Facebook, it’s full of Ads and “recommended” content instead of any social interaction, on top of which if they add (or added already) AI agents to supplement the circulation of content, they’re going to dig a grave for themselves at some point, when people finds out how unmeaningful as a platform it becomes when they’re on a hunt for more revenue by any means; which shows a lack of understanding, well, social design). Games, surprisingly, largely did not understood it to even this level.

Note: Something I’ve wrote here that relates to presence, if you’re curious to explore more this topic:

Apps Have Discovered Social

This is where the comparison with other industries becomes extremely interesting, if you have “certain lenses” on, when you look into things creatively.

While games were becoming masters of progression systems and retention mechanics, the app ecosystem was mastering human interaction systems. Social platforms optimized for e.g., identity expression, visibility, proximity, discoverability, reputation, conversation, parasocial behavior, and creator ecosystems. They became somewhat sophisticated at understanding why humans socially engage with one another.

Then, on top of this, apps started learning from games.

Gamification is raising its head everywhere. Systems, progression, engagement structures, rewards, retention mechanics, and live servicing is spreading across the app economy.

As an example, Duolingo has been exploring gamification deeply as part of its experience.

At the same time, games barely have evolved toward becoming more socially native, or even taking inspiration from app-like experiences (or, to say, going for “applifying” themselves).

The crossover mostly happened in one direction. Apps became more game like while games largely have been lazy to become more socially sophisticated, among other things they could have expanded towards to.

This becomes especially obvious when you look at the mobile market. Many mobile games still rely on social systems that feel detached from how people actually behave socially in digital environments today. Meanwhile social apps, creator platforms, and even productivity apps continuously evolve around human interaction, self expression, and community dynamics. I’ve literally attended some events where developers talk about social side of things, but it’s just talk without execution (probably partly because there’s not much capital flowing for innovation as well, when instead of that it’s flowing towards e.g., the ecosystem in Turkey, and probably next to just another ecosystem, e.g., Southeast Asia; though, considering Deconstructor of Fun’s latest article (Why Apps Are Beating Games for Investments: https://www.deconstructoroffun.com/blog/why-apps-are-beating-games-for-investments), app-like games could be possibly cracking doors for becoming “a thing” for investors, if you creatively approach the pitch and premise).

Games Still Treat Social As An Additional Feature

Games still often treat social systems as additional features instead of foundational design philosophy.

You build the game first. Then you attach clans. Then gifting. Then chat. Then a leaderboard. Then co-op. Then social events.

But humans do not separate social behavior from experiences the way games often do. Social behavior is embedded into how we experience environments themselves.

This is why I believe the future of social game design needs to move far beyond the traditional thinking we currently operate with.

Games should increasingly learn from real world social behavior and from platforms outside the games industry itself.

Games Could Become True Social Platforms

Take something as simple as decoration systems in puzzle games. Right now many decoration focused games already lightly touch social identity by allowing players to customize spaces. But, what if those systems would evolve much further?

Like, as an example, literally, you could have e.g., a Puzzle game with a decoration meta game, on top of which it could have social media feed integrated into the whole experience beyond what we’re seeing now in e.g., decoration games and their metas. This type of approach would be already, at least, one step towards more social compared to what we’ve seen, even when it takes just small inspiration from social media apps.

A quick concept for a Puzzle meets Social App game.

As a part of this experience, think about players being able to follow each other based on aesthetic taste. See in your mind discoverable feeds where players showcase decorated spaces. Think about commenting systems, trends, seasonal social movements, creator identities, and/or community driven design cultures emerging around those environments. Suddenly the decoration layer is no longer just a monetization mechanic or progression sink. It becomes a socially expressive ecosystem. On top of that, you could add a simple or deep puzzle core to it, taking benefits also from segments such as Match-3 or Merge.

And honestly, this should not even sound “radical” anymore.

Social media platforms already proved how powerful e.g., identity, expression, and discoverability are. Games simply have not deeply integrated those learnings into core game structures yet, and, when looked to meta game, same kind of applies in most cases.

What makes this especially interesting is that games already contain infinitely richer interaction possibilities than traditional social platforms. Games contain progression, economies, identity systems, cooperative structures, competition, spatial environments, achievements, emotional experiences, and much more all inside the same ecosystem.

Yet despite all of this potential, even some multiplayer games still feel socially less alive than social media applications (though, as mentioned earlier, some of these social apps definitely try to self-bury them underground).

We’re, as I started with, lazy on this front, or don’t just understand the underlying potential.

The Future Of Social Live Ops

The opportunity here goes far beyond engagement metrics.

Proper social design can fundamentally transform distribution, retention, monetization, live operations, and long term ecosystem resilience.

One of the biggest opportunities sits inside live servicing itself.

Right now many live ops systems are still primarily content scheduling systems. New event. New pass. New shop refresh. New leaderboard. New limited time activity. When it comes to social systems, they are more artificially social than actually social, which of course on some extent works for e.g., F2P mobile games industry, but definitely leaves even cash on the table.

Genuinely social systems create something much more powerful than scheduled engagement. They at their best create self-propagating engagement, which amplifies everything from distribution to engagement, and to monetization as well when done right.

Humans generating experiences for other humans. Humans generating emotional momentum. Humans generating aspiration, identity, culture, and participation loops organically. Or, just simply, humans meeting each other and, just, communicating as a starting point, vs. what we’re seeing on the “artificial social front” currently.

This is where the real scalability of social systems lies.

Traditional content pipelines scale through production resources. Social ecosystems partially scale through community / human behavior itself. One could say, with proper social design, a human starts becoming part of the operating system instead of being just a player using it.

Social Status Design Is Still Primitive

As we’re driving this route further, and when we look into e.g., social status, it can be stated that social status systems remain massively underexplored in games.

Status is one of the strongest motivational forces in human civilization, yet games still often reduce status into rankings, cosmetics, spending visibility, or skill ratings.

But humans socially signal through far more dimensions than this.

People gain social value through taste, influence, leadership, contribution, social connectivity, creativity, reliability, humor, storytelling, mentorship, and countless other forms of social capital.

Games barely explore these layers. Although, some upcoming games aim to explore these fronts, like one from Northern Lights Entertainment startup studio, called Nebulae, which aims to combine political systems with MMO design.

Snapshots from Nebulae, from the game’s website and its Kickstarter page.

On the social front with social status, there are lots of things open to be explored. Like think about ecosystems where community organizers become socially influential. Where tastemakers become discoverable. Where players gain reputation for helping others. Where event organizers become important social figures inside the ecosystem. Where players develop actual social careers inside games.

At these example points, the experience stops feeling like isolated entertainment software. It starts feeling more like a living society.

Web Games and Browser Platforms Are Missing Huge Opportunities

This is also where web gaming feels strangely underdeveloped.

The web as a medium offers enormous flexibility for social UI and UX experimentation, yet many web games and browser portals still behave like isolated game containers from an earlier internet era.

You could easily build e.g., social sidebars, integrated creator feeds, live community windows, discoverability systems, contextual discussions, spectator systems, and/or social overlays directly beside gameplay itself.

Quick mockup about how screens space could be used with modern web games (which we probably will need to wait for years for, given we haven’t seen in past e.g., 20 years anything innovative here in my opinion).

Even more social games such as MMORPGs could benefit enormously from more experimental social interface design. Like, think about social feeds existing alongside the game world itself. See in your mind live player storytelling systems, community driven event discovery, and/or creator ecosystems integrated directly into the environment instead of existing purely outside the game on third party platforms. Maybe also interacting with “social feeds” you could progress the game and/or some of its systems?

The screen space exists. The technology exists. The behavioral demand already exists. What often doesn’t exist yet is enough design ambition around social systems themselves. Let’s see how much we need to wait for something innovative to come here. It might take a while as when I’ve talked about my opinions on this even with some of the web platforms, which resemble what we had already 20 years, or more back, they just raise their eyebrows for the idea and keep doing same things they’ve kept doing. Of course, I get why, because it brings money as old platforms have died, so there’s the opportunity just to push out content instead of innovating at the moment. Hope we’ll get past this at some point towards more creative space.

Games Should Learn From Real Human Social Spaces

One of the biggest “gaps” the industry still makes is “focusing too heavily” on social mechanics while underestimating social environments.

Humans behave differently depending on environments.

A music festival creates different behavior than a business conference. A sports arena creates different social energy than a café. A nightclub creates different emotional dynamics than a classroom.

Lots of games rarely think deeply enough about these environmental emotional dynamics. They absolutely should.

What kind of social behavior does your environment encourage? What kind of emotional tone does your space create? What kinds of spontaneous interactions naturally emerge there? What types of social friction or opportunities exist?

Social systems are not only mechanics. They are emotional architectures.

Modern Systems Often Optimize Away Human Moments

Sometimes modern games accidentally optimize too much of the humanity away.

Many systems today optimize interaction efficiency instead of emotional depth. Faster matchmaking. Faster progression. Faster rewards. Faster transactions. Less friction.

But meaningful social experiences often actually emerge from “imperfection”, downtime, unpredictability, awkwardness, observation, repeated exposure, tension, rituals, and spontaneous interaction. It’s not just positive things that cause them.

Some of the strongest memories players carry from online games were never fully scripted by designers. They emerged socially. Ever heard of emergent design?

That is the part of the industry I believe we still fundamentally underestimate and should explore more.

Friendslop And Co-Op Games Are Early Signals Of Where Things Are Going

As we’re exploring this topic, of course, all isn’t lost as I’m constructively pointing out our laziness. One of the most interesting recent developments is the rise of so called “friendslop” games and lightweight co-op experiences.

A lot of these games are still rough around the edges. Many are mechanically simple, chaotic, intentionally unserious, or built around streamer culture and friend group entertainment.

As we’re seeing more of them floating to market, they are revealing something extremely important in parallel. They are putting social interaction closer to the core experience itself.

The traction many of these games generate is not purely coming from progression systems or mechanical mastery. A huge amount of their appeal comes from shared emotional moments between players. Laughter. Chaos. Embarrassment. Coordination. Failure. Improvisation. Social storytelling. That matters more in these games than some other systems they have there.

For years, the industry has been obsessed with optimizing friction away from multiplayer experiences. Remember when every publisher or investor said co-op games won’t succeed? Yeah, it was a thing. But, as we’ve seen, many of these newer co-op games are proving that social friction itself can actually be part of the entertainment. Even when the mechanics are relatively simple, the human dynamics become the real content layer.

This is why so many of these games spread so naturally on streaming platforms, Discord groups, TikTok clips, YouTube videos, and social media in general. They generate highly shareable human moments. In many ways, these games are exposing how hungry players are for socially driven gameplay again.

At the Same Time, I Think This Entire Category Is Still Extremely Early.

Most friendslop games today are only scratching the surface of what socially native game design could eventually become. The systems are often shallow, the progression is limited, and the long term social structures are still primitive.

But the underlying direction is important. These games are rediscovering something the industry partially “lost”, or just forgot.

That players themselves can become the most important source of entertainment. And because of that, I increasingly believe the entire friendslop and social co-op market is widely open for a defining leap forward.

In many ways, it can be said feeling similar to e.g., the early battle royale era before PUBG transformed the space. There were already games and mods exploring the concept, but nobody had fully crystallized the format into a larger cultural product yet.

The same opportunity exists here. Someone will eventually take the emotional chaos, proximity dynamics, social storytelling, and improvisational interaction of modern co-op and friendslop games and evolve them into something much larger and successful.

This will be something with deeper progression. Something with stronger social ecosystems. Something with long term community structures. Something with more meaningful social identity and persistence. Something where social systems and gameplay systems become inseparable.

And, when that happens, I think the industry may could, at least a bit more, start understanding that social design is not just an extra feature category. It is one of the biggest unexplored gameplay frontiers games still have, even it is in many ways self explanatory for us (which might be also why we think we’re good on social design when we’ve not taken it as far as we could).

Socially Reactive Ecosystems

In connection to social and communities, we often talk about UGC, AI generated content, creator economies, and infinite content generation as the future. But, I increasingly think the bigger evolution is socially reactive ecosystems.

Games that understand humans socially. Games that evolve culturally. Games that allow communities to shape emotional realities together. Games where players themselves become one of the most important layers of content.

Because ultimately, which is a strange thing to say, the most powerful content humans consume has always been other humans.

The Future Of Games Could Look Closer To Societies

When you zoom out far enough, the future opportunity becomes very obvious.

The games industry has become extraordinary at designing mechanics, economies, progression systems, monetization structures, and retention frameworks. But compared to the complexity of actual human social behavior, many of our social systems still feel primitive.

The studios that truly crack this next generation of social design will not simply build better multiplayer games. They will build socially alive worlds. Worlds where identity matters. Where reputation matters. Where social proximity matters. Where culture emerges naturally. Where players emotionally invest in communities instead of only progression. Where systems self-propagate socially. Where live operations become community- / player-driven instead of purely developer-driven.

And, the studios that figure this out first could unlock entirely different levels of engagement, retention, monetization, distribution, and long term ecosystem sustainability. Not because they manipulated players better. But because they finally started designing closer to how humans actually behave socially.

This, in my opinion, is the real frontier ahead for games. Not adding more social features. Building games that are genuinely social by design. It’s that simple.

We have built systems, loops, economies, and live operations that aim to e.g., simulate living games. We add content, tune numbers, design progression, and carefully orchestrate player journeys.

But at the end of the day, most games are still something I call as “static machines”.

Instead of this, what if the game itself was not static anymore? What if the game was actively observing, interpreting, and reshaping itself around the player in real time? In the era of AI raising its head, this is where the idea of an AI Game Master raises its head more than ever.

No. This is not a narrator. Not a helper. Not a content generator. No, no, and no. This is more deeper integration of AI on the systems level, referencing e.g., what I’ve wrote already in the past:

This is a system that sits across every layer of the game and continuously reshapes it through another level of emergency, which can be achieved when imagination becomes limitless, whilst the technological layer enabling such limitlessness becomes realizable.

Note: This isn’t just another “AI slop” outcome article, focused on producing something in low quality. This is an exploration, which hopefully sets in place forces that result in us getting exciting new games, with differentiating experiences.

From Designed Systems to Directed Systems

Traditional game design is about building systems that produce outcomes. When we look into this new suggested direction; an AI Game Master flips this.

It’s not only about systems producing outcomes. It’s about a system that observes outcomes and then reshapes the system itself. This is closer to how “a human dungeon master” operates. They don’t just follow rules. They read the table, feel the tension, and adjust the experience.

Here, the difference between human and AI is scale. An AI Game Master can do this across millions of players, across every session, across every system layer at once. Human-operated systems comes with its limitations (of course, when system design hits its sweet spot, even with limitations, you can create awesome stuff, which I acknowledge still whilst I’m writing this article).

This has implications everywhere:

• Core gameplay

• Meta layers

• Economy

• Monetization

• Live operations

Everything becomes dynamic.

Core Gameplay and Core Loops

At the core loop level, most games operate on fixed patterns, e.g.,:

• Explore → Fight → Loot → Upgrade → Repeat

Even in more advanced systems, the variation is authored or parameter driven.

With an AI Game Master, the loop itself becomes fluid. It can stretch tension, compress pacing, and redirect player intent.

Instead of designing encounters, you design possibility spaces. The AI Game Master decides when to introduce friction, when to create relief, and when to break expectations.

In e.g., an extraction context, this can become extremely powerful. A run is no longer just a sequence of encounters.

It becomes a guided emotional arc:

• The system can detect that the player has had e.g., three safe runs in a row and inject risk.

• It can notice hesitation and push opportunity.

• It can turn a routine run into a story.

The real potential is when regular steps are no longer predictable.

Meta Game Layers Become Alive

Meta systems are usually where games can lose their illusion of life.

They most often are also e.g., spreadsheets with UI:

• Progression trees

• Upgrades

• Collections

• Currencies

An AI Game Master changes this by turning meta into a responsive system:

• Instead of static progression, the system can reshape available paths based on player behavior.

• Instead of fixed rewards, it can create contextual rewards that align with player intent.

And much more. This connects closely to the idea of progression vectors I have written about before:

Different players move through the game with different motivations and directions. The challenge has always been serving these vectors without fragmenting the system.

The AI Game Master doesn’t choose one path. It adapts the system, so multiple vectors can exist at the same time, without breaking coherence. It observes how a player engages and bends the meta around that behavior.

One player might experience a progression that leans into risk and high stakes. Another might see a system that emphasizes collection, completion, and stability. Same game. Different reality. At their best, these systems doesn’t just offer hyper-personalization but also honor multi-archetype systems design, which I’ve also covered in the past:

From Static Economy Design to Situational Systems

This is where things get interesting (and, possibly, also dangerous).

Game economies have traditionally been designed as controlled systems:

• Sources

• Sinks

• Inflation control

• Conversion loops

Monetization sits on top of this as a set of entry points:

• Offers

• Bundles

• Time pressure

With an AI Game Master, the economy is no longer static. It becomes situational.

The system understands context:

• What the player is trying to do

• What they value

• Where they struggle

• Where they succeed

Instead of offering the same bundle to everyone, the system can create opportunities that align with the player’s current state. This is not just about personalization, it’s structural adaptation.

In its best format, it ties back to vector based thinking (mentioned above). Instead of pushing players into predefined funnels, the system supports multiple archetypes at once and allows them to coexist inside the same economy (also referred above).

A risk driven player might see systems that amplify high stakes loops. A builder might see systems that deepen crafting and base growth. A collector might see systems that expand rarity and completion. The economy becomes multi layered but still unified.

The risk? I think it’s obvious. If done poorly, this becomes manipulation. If done well, it becomes “alignment”.

The difference is whether the system is extracting value from the player or creating value for the player. One comes with a proper engagement profile, another comes with a churning point.

Designing for “Intervention”

If you introduce an AI Game Master, you are no longer designing “closed” systems. You’re designing systems that expect “intervention”.

This changes how you build everything:

• Systems need to be interpretable

• Systems need to expose levers

• Systems need to be modular

The AI Game Master needs to understand what is happening and what it can safely change. Let’s think about a layer above that.

A system that can:

• Shift risk reward calculations

• Introduce new objectives mid run

• Change e.g., extraction conditions

• Trigger social conflict

This is not about adding content. It is about creating systems that can be recombined and redirected. Design becomes less about authoring outcomes and more about defining boundaries. Boundaries, and rules; yes, they should exist in your designs.

The End of Static Live Events

Live ops today is scheduled design.

• Events

• Seasonal content

• Limited time modes

Even the most advanced systems still rely heavily on planning and manual tuning.

An AI Game Master turns live ops into a continuous process:

• Events don’t need to be scheduled → they can emerge.

• Difficulty doesn’t need to be globally tuned → it can be locally adapted.

• Content doesn’t need to be pushed → it can be generated or recombined.

The game becomes a live service in the literal sense:

• Always reacting

• Always adjusting

• Always evolving

This also changes how teams operate. For example, by this, designers are no longer only creating content → they are shaping the behavior of the system that creates content.

Extraction RPG Simulation Case Example

Let’s explore this topic through a practical Extraction RPG Simulation concept, which I’ve produced here to showcase what I mean by AI being the Game Master.

In this concept, the core loop is structured around sending squads into dangerous realms; whilst AI Game Master would be observing their behavior, and, eventually, resolving outcomes.

The experience here isn’t just single player / campaign experience, it can be easily stretched to a real multiplayer experience with synchronous multiplayer for matches between players’ squads.

The system includes:

• A hybrid extraction RPG structure with risk and reward loop

• Autonomous characters with needs, traits, and memory

• A base layer with social simulation and multiplayer interaction

This is a “game premise” / “foundation” that fits properly for an AI Game Master.

During a raid, the AI Game Master observes:

• Squad composition

• Health and morale

• Loot value

• Recent player history

…and also runs the whole social and multiplayer “simulation”. Of course, if wanted, player-led controls or intervention controls can be added to the core gameplay.

Instead of fixed encounters, which would be the traditional “design”, the AI Game Master directs the experience completely:

• A squad that is overloaded with loot might want to extract quickly, whilst they could trigger increased enemy attention.

• A high tension run might introduce a rare opportunity that forces a player-made intervention, if such control is designed being part of the core gameplay. Do you risk everything for a potential breakthrough, or secure what you have?

Back at the base, the system continues.

• Raiders remember what happened.

• They form relationships.

• They demand better equipment.

Raiders have needs, personalities, and memory that affect their decisions and behavior.

The AI Game Master connects these layers. It creates continuity between runs. It turns isolated sessions into an ongoing story, with depth on meta layers that the player can interact with.

The result isn’t just a game loop. It’s a living system that produces stories as a byproduct on top of which the player interaction layer stays living and focused on what is wanted to be left for players to explore.

The Opportunity

The biggest mistake would be to treat AI Game Master as an add on. A narrator on top of a static game. A content generator for quests. This misses the point.

The actual opportunity is to let it reshape the entire game:

• Core loop

• Meta

• Economy

• Live ops

Everything becomes part of “a directed” system. The game stops being a product and starts behaving more like “a real simulation”. Not a simulation of e.g., physics or systems; instead, a simulation of experience.

We have spent years building systems that try to feel alive, and have spent lots of cash to achieve this. AI Game Master could be a step toward systems that can be affordable and sustain some form of “healthier” studio economies.

Side Note: No, I don’t want AI to replace people. Instead, I want AI to amplify them and studios to sustain a better future for our industry. This article could be, in this sense, very inspirational for e.g., an upcoming studio, who is bold enough to try out something different, which could theoretically result to a proper outcome, enabling them to scale and grow at all sides, incl. headcount considerations.

As I see it, the challenge is not technical even anymore. It’s more philosophical. Are we willing to leverage AI? Are we willing to give up control? And so on.

The moment we open our mind for a new shift in game-making, we are no longer designing games. Instead, in best scenarios, we are designing worlds that “design” themselves, resulting to new exciting experiences.

From Watching to Participating

For years, and years past those years, spectatorship in games has been passive.

You’ve watched eSports. You’ve watched streamers. You might have chatted. Maybe even donated.

What you might not have done, whilst some may have already, in a format of “baby steps”, influenced someone’s gameplay through a stream, through stream’s “direct” engagement and/or monetization systems.

With the latter in mind, the question raises up: “What happens when spectators are no longer just observers, but actors inside the system?”

We’re already seeing fragments of this future.

Gone deeper, I think the question is not just if spectatorship becomes a core design pillar for some games, but when and who executes it properly to the end as a foundational pillar for their game, incl. all sides of game economies tied to it.

Twitch, Bits, and the First Layer of Spectator Monetization

For spectatorship to exist; platforms like Twitch have already laid the foundation.

Twitch Bits, donations, and subscriptions are not just monetization tools; they are already existing interaction systems:

• Viewers spend to signal support or effect gameplay through emergent events

• Streamers react (shoutouts, gameplay choices, emotional responses)

• Feedback loop, at its best, potentially reinforces some spending

But fundamentally, this is still external to gameplay, or added layer; instead of a layer built to foundational layers of games with first integrations.

Even in cases where Bits trigger effects (alerts, sounds, overlays, etc.), the interaction is:

• Surface-level

• Non-systemic

• Detached from the game’s core economy

So, the leap we haven’t fully made yet is:

• Spectator acting, and also spending, through spectating a stream, in a way that these actions directly impact gameplay, systems, outcomes, and economies as core part of a proper-scale game and its business model.

From Overlay to System: CrowdControl and Beyond

Platforms like CrowdControl.live are early “signals” of where things can be going.

They allow viewers to e.g.,:

• Spawn enemies

• Give items

• Modify difficulty

• Influence moment-to-moment gameplay

This is important, but still largely “tactical” and reactive to its nature.

Despite what we’re seeing already, I see the in-depth opportunity goes beyond the surface level:

• From event-based triggers → to systemic influence

• From chaotic fun → to structured economies

• From stream gimmicks → to core game loops

And… having this all as a core part of a game and its experience, on a proper scale. Crucially, this doesn’t even need to rely on third-party platforms.

Developers can, if seen fit for their business cases, e.g.,:

• Integrate through Twitch’s API directly

• Build web-based control layers

• Create cross-platform participation systems (browser, mobile, second-screen)

Technically, and if wanted to be pushed this far, this opens the door to something much bigger:

• Parallel spectator economies running alongside, or integrated deeply to, with e.g., the player and/or game economy.

Why Hasn’t It Fully Broken Through?

Despite all the developments, as I see it, spectatorship is still underdeveloped as a primary business model (side note: at least based on my research, but there could be some movements already in motion; at least I know couple indie projects who look into it, at least on a paper).

Yes, some games have integrations:

• Voting systems

• Minor Twitch interactions

• Occasional event triggers

However, these are lightweight features, not foundational systems (and interconnections).

We don’t yet have:

• Games designed from the ground up for spectatorship economies

• Monetization loops where spectators are “first-class” participants

• Long-term progression systems for viewers

This is “surprising”, because the demand and early services exists to a certain extent; which could be taken further by some bold takes definitely.

Not to forget this, there are, of course, mentions in blogs, and some direct conversations that I’ve had around the topic, about couple companies that have been trying to crack this space with new multiplayer concepts built around spectatorship and spectatorship monetization.

Whilst these projects have been exciting to be read, and heard about, some of these projects have been paused; not because the idea failed, but because e.g., the market conditions did (e.g., due to tightened funding landscape, or other reasons).

Given these, it’s important to note that spectatorship systems are:

• Complex

• Cross-disciplinary

• Difficult to crack right way economically

…which makes them seen potentially as “a high-risk” in the current macro environment by people who don’t really get the whole funnel and/or economies’ potential behind the model. But this doesn’t reduce the model’s potential; as all advantages still exists, from first actual movers (on a healthy game and longevity basis) to followers on it.

How Spectatorship Fits with Different Business Models?

In F2P

Spectatorship fits naturally into F2P models:

• Viewers can, potentially, even spend without installing the game

• Acquisition funnel expands dramatically

• Social virality compounds monetization

Spectators become:

• Soft-converted users

• Pre-players

• Economic participants without onboarding friction

This can be incredibly powerful model, if executed properly, within F2P.

In Premium Games

More interestingly, spectatorship can unlock new value layers in premium games:

• Extend engagement beyond purchase

• Create post-purchase monetization without breaking the premium promise

• Turn players into performers and spectators into co-creators

When done right, hybrid models emerge, e.g.,:

• Premium entry + spectator-driven live economies

Platforms; Not Just Twitch

This isn’t limited to Twitch.

We’ve already seen early forms of participatory monetization across platforms, e.g.,:

• Live gifting influencing creator or simplistic game behavior

• Interactive streams where audience actions shape outcomes

• Real-time voting systems affecting content direction

This works from Twitch to TikTok to YouTube, and further.

While not always even gameplay-driven, the pattern is clear:

• Audiences (are willing to) pay influence outcomes.

And, yet, gaming is underutilized frontier for this behavior, even despite what we’ve seen already, like simple streamed games based on this model.

What This Can Become

In my own work and explorations, I’ve been thinking about spectatorship not as a feature, but as a core design axis.

The idea is not just interaction, but with “live control” over the game state, by spectators, the model can e.g.,:

• Trigger dynamic events by viewers

• Create environmental shifts influenced by the audience

• Have monetization loops tied directly to these actions

• Form into full-scale progression and economy systems, tied to both ends: the game’s end, and spectating’s end

Games’ can very much blend e.g., AI-driven systems with live audience interaction, introducing player-driven and audience-influenced multiplayer and monetization systems at scale.

This is the direction that I believe matters most. Not gimmicks. Not overlays. A real systemic integration.

Potential Depth of Spectatorship

Spectatorship can exists on a spectrum; from effects to economies. Below is a list of “depth” on high-level, including notes on where we are standing.

Level 1; Cosmetic / Reactive

• Alerts

• Sound triggers

• Visual effects

Level 2; Gameplay Influence

• Events, such as spawning enemies

• Giving buffs/debuffs

• Modifying difficulty

Level 3; Systemic Integration

• Influencing game economies

• Affecting progression systems

• Altering matchmaking dynamics

Level 4; Parallel Meta Systems

• Spectator progression

• Viewer-owned assets

• Cross-session influence

Level 5; Emergent Ecosystems

• Social, e.g., spectators form factions

• Compete or cooperate at scale

• “Influence entire worlds” over time

We are currently hovering between Level 1 and Level 2, whilst the real (monetary / large-scale) opportunity is I’d say within Levels 3–5.

Social Monetization Evolves

This is a much larger topic to discuss, which I’ll go through, maybe, as a topic of its own. So, instead of a too deep dive, let’s just focus on the core message.

Spectatorship is not just a feature, and it might be part of a broader shift toward:

• Social monetization

• Systemic participation

• Emergent economies

Players are no longer the only “users”. Viewers are “no longer passive”. Communities definitely aren’t passive. Players, as well as viewers (and viewer-players), want to be very closely part of the experience and a game more deeper. This got “more validation”, I’d say, through a recent event I attended personally, where both presenters and the audience (audience of game developers) discussed a lot about how players want to be involved more and how e.g., UGC, mods, and multiple other fronts are raising their heads more as part of the experience, on top of having communities being deeply involvement in everything.

Considering these, and many other factors, eventually, the distinction between different business models as well as ways how people get involved with games they play may integrate more deeply together.

Note: Some hints of what I’m discussing shortly about can be found from my previous article about Proximity Design in Game Design:

Why This Can Break Through

Despite where we are, I believe someone will crack this model.

Why and how? Because it has layers that aligns with:

• Human behavior (e.g., influence, participation, social signaling)

• Platform evolution (streaming + interactivity)

• Monetization “expansion” (beyond players) / entrepreneurial monetization exploration

And when it happens, it won’t look like a Twitch plugin, a donation overlay, or a gimmick feature. It will look like a game where the audience is part of the system, and the system is designed around them.

Spectatorship today is where free-to-play was many years ago; understood in fragments, misapplied in execution, and massive in potential.

The question is no longer if spectatorship becomes a core pillar. I’d say the question is:

Who builds the first truly scalable spectator-native game (economy)?

And more importantly, what does it feel like when you’re not just watching… but shaping the game itself?

This is not just a monetization or game experience shift, it also, when done right, shifts engagement as well as distribution and live ops to far into the future.

• Kill → Loot → Upgrade → Repeat.

• Match → Win → Rank → Repeat.

• Build → Expand → Dominate → Repeat.

We’ve optimized it → we’ve monetized it → we’ve scaled it. And yet, engaged players are burning content fast, and developing fatigue over the core.

This happens usually not because loops are bad, but because loops alone are not enough for building longevity. Same could be told for applying for the basic meta systems.

From Loops to Living Systems and Worlds

Players today don’t just play games. They optimize them, break them, and exhaust them. They pretty much go that far that they consume loops like content. And once the loop is “solved”, big parts of most games collapse in players’ eyes.

With this in mind, one part of building longevity is not about better loops or meta systems. It’s more often about what shapes and scales the loop’s experience.

In the eyes of this, most games already have the building blocks they could use for shaping and scaling their loops’ experiences, such as quests, events, social systems (e.g., guilds, factions), contracts / missions, and environment states.

However, most often, even the pieces are the, the real interlink between them and the core loop is broken, as these systems are most often treated as content delivery systems. That gives you results indeed, but that is also most often something that results in having a gap in your longevity.

So, how can we do better? At their full potential, these systems should be used as something I call as “game-shaping systems”. This means they don’t just add gameplay. Instead, they reconfigure the gameplay itself, resulting in deeper dynamics and emergency, which players are looking for.

When a Quest Stops Being a Task

Let’s give this a simple example.

Traditional quest design:

“Go here → kill this → get reward”.

Systemic quest design:

A quest becomes a parameter that modifies the entire session.

Game Scenario Example

We have an Extraction Shooter game with social faction systems, which puts players into active factions core part of the game. As a part of those factions, you activate faction contracts to proceed in the game.

Traditionally, by traditional design, you would have gotten a simple contract to do X to get Y as reward. By systemic design approach, not just your objective changes, but also dynamics change.

This can be designed to affect everything, such as:

• Matchmaking: Higher chance of same-faction players, and increased probability of enemy faction encounters.

• Environment: Specific locations become hotspots, and AI density increases in contract zones.

• AI behavior: More aggressive patrol patterns, and possible boss spawns tied to activity.

• Rewards: Higher-tier loot concentrated in risk zones, and dynamic reward scaling based on participation.

This is not a quest anymore. This is a session modifier. You didn’t pick content, and instead of that you entered a different version of the game. And this is already visible in your system design: contracts increase faction clustering → increased enemy faction encounters → boosted AI presence → extra loot in specific areas.

This isn’t just content anymore, this is systemic orchestration, which in well-executed format adds distribution, engagement, and monetization potential to your game.

What makes this interesting, in this scenario example, is not just the systems and their world-shaping capabilities themselves, but also the fact that player behavior and behavioral dynamics and economies change dynamically from match to match and lobby to lobby. Like tied to an Extraction Shooter experience, players wouldn’t know exactly what dynamics they are matched against, e.g., how many factions, how many non-faction players, how many “boosted” areas, etc. take in shape, which itself makes the whole match very exciting from e.g., core economics perspective.

These types of emergent interconnections would have probably even helped games such as ARC Raiders to sustain its active user counts much longer, if they would have gone for having more dynamism between their systems. Time will tell how they aim to deepen their systems’ approach.

Match-based Ecosystems

Most teams treat matchmaking like plumbing: skill, latency, and queue time. Sounds familiar?

The best matchmaking is actually the most powerful invisible “designer” in your game; because it decides basically who you meet, who you fight, and who/what shapes your experience.

Note: See what I’ve wrote about matchmaking as own separate topic here:

Now, as we understand what matchmakers should be at their best, let’s think about a matchmaking that considers e.g.,:

• Active quests/contracts

• Faction alignment

• Risk level (loot carried into session)

• Player intent (PvP vs farming vs exploration)

• Behavioral patterns (aggressive vs passive players)

With traditional means, matchmakers give “balanced matches” through above parameters.

With systemic approach, instead of “balanced matches”, you can create e.g.,:

• Faction-heavy wars

• Predator vs scavenger ecosystems

• High-risk lobbies full of stacked players

• Mixed-intent chaos sessions

Now each match is not just a match. They actually become ecosystems of their own. Pretty exciting, right?

Events as “Mutations”

Most events use pretty basic formats:

• “+20% XP weekend”

• “Limited-time mission”

• “Holiday skin”

Most often they don’t even change the game. They just “decorate it”.

Of course, above said, I know lots of games do change their content within events and experiment with systems, e.g., Hunt: Showdown, which is currently running their Devil’s Trail event with things as Inferno’s shaping the game world by having big areas under fire, along with many other things there for players to experience.

This is itself very exciting and big investment over building distribution, engagement, and monetization over a live service title. But, even so, they usually over longer time start repeating themselves and/or forget the systems-level interconnectivity potential they could have in their game; regarding specifically what I’m writing here in my article.

Systemic events do something else:

• They add emergency to the world.

Instead of “more rewards”, you can have:

• AI density that spikes dramatically

• Patrol logic that collapses into chaotic aggression

• A roaming boss hunting players dynamically

• Resource value skyrocketing in localized zones

• Extraction becoming contested and volatile

You can also do more than this, e.g., layer these with night-time visibility changes, have faction contracts active along with event systems, and have e.g., a high player density.

By this, you don’t have anymore just a traditional event as “a feature” or experience. You have an emergent system / ecosystem players experience over and over with a big smile on their faces, as these interconnections create experiences that players will remember for ages.

Indirect Participation

Indirect participation can make things more interesting, if wanted to be used. By this design approach, players wouldn’t need to opt into systems to be affected by them.

In a systemic game with indirect participation:

• Some players queue into faction events intentionally

• Others land in those same lobbies randomly

With this, you create new dynamics e.g.,:

• Prepared vs unprepared players

• Opportunistic ambushes

• Avoidance and stealth strategies

• Temporary alliances

Creating Second-order Gameplay

Not anymore about:

• “What is the objective?”

Instead:

“What is happening, and how do I survive it?”

That’s where some further depths of emergence lives.

Social Systems as Behavioral Gravity

Social systems such as factions are still one of the most under-designed systems in modern games.

Usually they add things such as:

• Cosmetics

• Narratives

• Progression tracks

But systemically? They could have more in them.

With the direction I’m pointing through my article, they can become:

• Behavioral gravity wells

Social systems can influence:

• Matchmaking clustering

• Conflict probability

• Map movement patterns

• Resource competition

• Social grouping

When systems such as factions affect who you meet, where you fight, and what enemies and rewards exist; then players are no longer just progressing. They are participating in a “living conflict”.

Interconnectivity as a Key

Individually, these systems are very interesting and can move a needle a lot. However, together, they can become genre-moving designs.

Think about a single session:

• You activate a faction contract

• A global breach event triggers

• Night-time reduces visibility

• Matchmaking clusters high-risk players

That’s not a traditional session anymore over your core loop. That’s a beast of an experience to go through.

Through proper interconnectivity, you get:

• Unpredictable encounters

• Unique session narratives / experiences

• Player-driven outcomes

Key insight:

You don’t scale content
You scale interactions between systems

Why This Changes Everything

This isn’t just design philosophy. It directly impacts to your whole funnel.

1. Distribution

Emergent systems create:

• Shareable stories

• “You won’t believe what happened” moments

• Organic virality through community videos, social media reels, etc.

No marketing beats unpredictable gameplay stories.

2. Engagement

Instead of more content, more levels, and more missions, you create dynamic and emergent variation.

Same loop, but different reality.

3. Monetization

Instead of selling power, skips, and content, you could theoretically sell, as an example:

• Access to high-risk systems

• Influence within factions

• Event participation advantages

• Risk mitigation (insurance, protection, scouting tools)

• And other things tied to your game

You can focus on intrinsic monetization strategies on this side, which don’t feel like monetization, because it’s tied to system participation, not pressure.

Game Genre Examples

Extraction Shooters

The perfect foundation.

• PvPvE

• Risk layers

• Shared spaces

Systemic design turns them into living ecosystems-

Multiplayer Roguelites

Still massively underexplored.

• Runs influenced by player activity

• Events affecting procedural generation

• Shared world states across sessions

Randomness becomes systemically influenced “fun-chaos”.

Note: Interested what I’ve wrote about Extraction Shooters and Roguelites in general? Find more from these articles:

Possibilities with AI

Now, take everything above. And, remove static control.

Add an AI layer that:

• Observes player behavior

• Tracks faction dominance

• Detects stagnation or imbalance

• Understands player intent

And, then, make it actively reshaping your system.

This is not anymore content generation (e.g., infinite quests, procedural noise, narrative spam). This is, again, system orchestration; amplified with AI. Not a slop.

What AI can enable:

1. Adaptive Matchmaking

2. Persistent NPC Memory

3. Dynamic Worlds

4. Social Dynamics

5. Reactive Events

…and much more.

When systems + matchmaking + AI interact, you can bypass endless content, constant updates, and artificial retention loops. Games can become more reactive, adaptive, and unpredictable, in which players don’t return for rewards but rather for possibilities.

Living Systems

Best games are living systems.

The industry has spent decades perfecting core loops, progression systems, and content pipelines. Beyond that, the next generation of games will not be just defined by those. They will be defined by:

How alive they and their systems feel

The real question is no longer: “What I do next?” It’s more about: “What kind of world am I stepping into this time?”

Budgets have inflated. Production cycles have slowed. Content pipelines have become heavier and less predictable. Science-based optimization has been optimized for squeeze that churn users. Players are spreading time among multiple medias more, and many claim “AI is going to kill our jobs”, and such. While this all is cumulating, at the same time, player expectations have shifted toward something entirely different, e.g., living, evolving, and social experiences that persist over time, or just towards wanting, well, better games and experiences.

Growth is no longer driven by acquisition alone. It is driven by retention, depth, and long-tail engagement. Similarly, the industry is no longer rewarded for producing just more content and squeeze over it. It is rewarded for producing better games, and, as I get to discuss this topic here more, better systems around them.

This creates a fundamental shift in how games should be designed, built, and scaled.

The old model:

• Build a game

• Ship content

• Maintain via live ops

• Move to the next project

The better model:

• Build systems, and launch “an experience engine” platform

• Experiment rapidly for optimizing performance in smart way, even when building just the first game

• Through one game (or more games), scale across multiple games, genres, and audiences

• Expand through modular extensions

This is where experience systemization becomes critical for the better model. Not only as an optimization mean, but as the core strategy and mindset model.

When you are as a reader exploring this topic, please note that lots of the examples lie around games and genres I like to blog about, e.g., Shooters. This doesn’t say, though, that Shooters are best benefitting from experience systemization alone. As I see it, there are multitude of genres and experiences these same principles and models can be used for, e.g., even for simulation / tycoon games / idle games, puzzle games, 4X / strategy, MMORPGs, and such.

The key lies in understanding a market, and its near-by markets deeply, and using experience systemization as the main anchoring method for pulling things together the way this article discusses about experience systemization.

Note: This is a topic I’ve developed with a lot of care and passion. It’s something I return to often, because I believe it sits at the core of building a more sustainable future for our industry.

This is also an area where deep, cross-disciplinary experience matters. Systemizing experiences at this level requires a rare combination of systems design, game economy thinking, product leadership, and business understanding. It’s a space I’ve been operating in, and one I feel strongly positioned to help push forward.

Very few people in the industry are currently equipped to operate at this level when it comes to experience systemization. My hope is that through this post and effort of others, more can switch their world perception to right tune for achieving same.

Also, I’m open for opportunities as they come, if someone wants to arm me for building sustainability for their studio(s) through experience systemization.

From Games to Experience Engines

Experience systemization in a nutshell means that you are no longer designing a single game. You are designing an experience engine, which builds sustainability and scalability for your business in smart way.

This engine consists of reusable, interconnected systems, such as:

• progression

• matchmaking

• game mode(s)

• economy / monetization

• social structures / systems

• world / environment simulation

• live ops systems

When it comes to experience systemization, these are not just features. They are primitives / foundations as well as base systems that carry over not just one game but multitude of games, on top of which even for one game they allow adjustments between science bases, modes, genres, and, well, experiences combined.

When designed correctly, they allow you to e.g.,:

• create multiple game modes smarter

• mix and switch between game modes

• experiment with monetization models

• adapt games to player behavior without rebuilding the product

• shift between genres for one or more games

• scale from one foundational game base to new experiences faster

The result is a system that produces experiences and new games instead of building content and games again, and again, and again in an infinite loop. Simultaneously, I would say your genre-mastery accumulates on a much greater scale than previously, as it comes from a foundational layer that allows you to experiment between sciences and experience bases. Instead of just deepening one vector knowledge, you deepen your knowledge in parallel around a multitude of vectors.

Systemizing Experience

Traditional design is often content-first. It focuses on e.g., levels, missions, and handcrafted sequences.

Systemic design is rule-first, and it focuses on:

• mechanics

• interactions

• emergent outcomes

Instead of asking:

“What content do we build next?”

You can ask:

“What system(s) produce(s) the next thousand experiences?”

This is where e.g., mechanics → dynamics → aesthetics become “operational”. You build mechanics that scale and shift dynamically through configurations. In a simple way, you enable dynamics that vary, and you allow aesthetics to emerge.

The outcome:

• higher replayability

• lower content cost

• stronger player agency

Multi-Science Systems

One of the most important principles in experience systemization is this:

• Every system should be built on multiple scientific bases.

Let’s look, for example, into matchmaking. A traditional implementation optimizes for one variable, for skill-based matchmaking.

A systemic implementation optimizes for multiple sciences, e.g.,:

• geo-based matchmaking

• skill-based matchmaking

• engagement-based matchmaking

• symmetric matchmaking

• asymmetric matchmaking

• social cohesion

• core gameplay data

• server data

This transforms matchmaking from a static system into a configurable layer. You can switch between logics, combine models, run experiments, and adapt to player data and feedback.

With this, even something like matchmaking becomes a control system for experience design, and not just a backend utility. And, through this approach, you would have a revolutionary matchmaking system ready for not just one game but multitude of games.

Note: Interested about matchmaking systems? Read what I’ve wrote about them here:

Genre as Configuration

When systems are modular, genre is no longer fixed. It becomes a configuration.

A well-designed experience system allows transitions such as:

• PvPvE → PvE-only → PvP-only

• Extraction → Roguelite → RPG/MMO

• Solo → Co-op → PvP

This is not about making everything flexible. It is about designing systems that support controlled transformation.

Thesis: PvPvE to Co-op PvE in a Shooter Game

If AI systems, rewards, environments, and matchmaking are modular:

• PvP pressure can be reduced or removed

• AI presence, behavior, and difficulty can be scaled

• rewards can be redistributed, and repositioned

The result is a fully different experience built on the same foundation. Of course, the foundation might require some finer tweaks, like for level design, but there are also ways how you could do all this within larger open maps and/or evolving biome-based maps.

Thesis: Extraction to Roguelite in a Shooter Game

Both, Extraction and Roguelite, share core primitives:

• run-based loops

• risk vs reward

• progression layers

The difference lies in e.g., persistence and reset structures. With this in mind, you can build and experience, in a smart systemized way, how you can even go that far that you switch between genres.

If foundations in your systems for both genre directions are supported:

• you can pivot or mix based on data

• you can test player preferences

• you can evolve the product post-launch

This allows you in one systemic shot to not just test and iterate a game to market wisely, but also over time spin new products out from same base, e.g., you could have an Extraction game acting as a spin-off base for your Roguelite game.

Switches between PvP, Co-op, and PvPvE can be also included in this mix, if you build things just the right way.

Note: Interested about what I’ve wrote about Extraction Shooters and Roguelites? Find more from these articles:

Designing the Bet: Constraints That Enable Flexibility

System design for experience systemization is not about unlimited flexibility. It is about choosing the right constraints early.

Meaning, which I acknowledge well here, that there are certain limits for the flexibility and switches between experiences. Like for those Shooter examples, you cannot make them to something extreme like to puzzle games without spending money expensively.

Key decisions for this matter include e.g.,:

• environment / map / level scale and its emergency

• world density and emergency

• session structure

• social depth

• progression systems

Map Example

Large-scale maps:

• long-term tension

• slower pacing

• high-stakes extraction

Biome-based maps:

• faster iteration

• controlled variability

• high replayability

Both support Extraction and Roguelite systems when it comes to Shooters. But they shape the experience differently.

With this in mind, system design for experience systemization is about selecting constraints that maximize future optionality rather than aiming for building a base for unlimited choices.

Systemic Shooter Game Concept Example

This game concept example, I’ve made myself withing couple evenings, can be understood, from experience systemization’s point of view, not as a single game but as a system configuration.

Core layers:

1. Extraction Loop

Deploy → Engage:

Loot:

Extract:

Upgrade / Maintain:

2. Roguelite Character & Trait System

With adding e.g., Class and Roguelite systems, you get e.g.,:

• temporary power growth, lost at character dead

• combinatorial builds and fantasy explorations

• deep economy, which allows also later DLC / microtransactions-based monetization opportunities, if wanted

3. Environment system

Well planned environments bring lots of dept, which suit for Extraction Shooters, Roguelites, and/or their mixes.

For example:

• multiple environments / biomes

• dynamic events (e.g., night, breach)

4. Social structures

Smart design enables:

• All solo, co-op, and group play allowed, AND/OR

• one of these allowed / focused into, as/if wanted

These systems already enable multiple configurations:

• PvPvE extraction

• Co-op PvE roguelite

• PvE-only

• Social raid structures

The important insight:

The game is not the product, the system is.

New Games & Experiences:

From futuristic setting to e.g., modern techy setting, using same “experience” / game (systems) base:

Systems can also enable multi-platform explorations:

Potentially, if your tech. choices allow, multi-platform exploration becomes a possibility to some extent, e.g., same systems but for mobile:

Tech Modularity: The Enabler That Changed

Historically, this level of systemization was extremely difficult. Like when we talk about modularity, I believe it’s something that has been tried to crack properly since 80s. It’s slow, costly, and time-consuming.

Building modular systems has so far required:

• large engineering teams

• long development cycles

• heavy upfront investment

• complex maintenance overhead

As a result, most studios defaulted to building one-off solutions tied to a single game.

This is now very likely changing. AI could be fundamentally shifting the cost structure of modularity under the hood. I’m not talking vibe coding your whole stack but rather than putting AI under the hood of these components, while you would be in control of the architecture. Also, just to put it out here as well, I’m not talking about replacing people by AI on this, as instead you can just amplify them and sustain proper dynamics culturally.

What AI Potentially Enables

As someone pointed for me, the belief is that AI allows you to:

• generate and maintain system variations

• support multiple configurations simultaneously

• reduce engineering overhead for system updates

• automate balancing and tuning processes

Instead of building rigid systems, you can build adaptive ones faster. Instead of maintaining one game, you can maintain a system layer across multiple experiences more efficiently.

The Outcome

Tech modularity becomes:

• faster to build

• cheaper to maintain

• scalable across multiple games

This might be the first time in the industry where true experience systemization is not only possible, but somewhat practical.

Beyond this, AI Can be Considered for e.g.,:

• balancing economies

• tuning matchmaking

• generating events

• adapting difficulty

• supporting live ops experimentation

This allows the system to evolve / be maintained continuously without requiring full manual intervention.

Compounding Systems as The Real Advantage

The biggest impact of experience systemization is economic.

Traditional model:

• each game is a new investment

• each feature is rebuilt

Systemized model:

• each system is reused

• each improvement compounds

• each game becomes cheaper to build

This creates:

• faster production

• lower risk

• scalable portfolios

A studio becomes a system that produces great games, instead of a team that builds them one by one with high risk-profile through traditional optimization means and methods. This way, again, genre-mastery compounds in a way no-one probably haven’t experienced it “the smart way”.

Designing for the Unknown

The most powerful aspect of experience systemization is not efficiency. It is adaptability. You are not designing for a fixed outcome.

You are designing for:

• unknown player behavior

• unknown genre evolution

• unknown monetization shifts

Instead of reacting to change, you are prepared for it.

Experience systemization is the bridge between:

• creativity and scalability

• design and economics

• games and platforms

It is how you:

• reduce cost

• increase speed

• unlock innovation

And most importantly:

It is how you build games that do not just succeed. You evolve along with that.

For many years, my day-to-day work has relied on using market intelligence tools. Over time, I had the chance to try a lot of well-known platforms that promised a high-level view of the mobile games market, e.g., revenue estimates, downloads, KPIs, category leaders, trend identification, and many more.

They were powerful, but also expensive, rigid, and sometimes too abstract for the kind of work I actually needed to do. My core challenge wasn’t access to data. It was a resolution. As a product leader, systems designer, and hobbyist angel investor, I rarely ask simple questions like, “Is this genre growing?” Instead, my questions tend to be more surgical:

• Is this specific subsegment within a genre growing or decaying?

• What monetization structures and strategies are actually working for those competitors on the inside and not just on the surface?

• Are live events being used as a core economic driver, or just as surface-level engagement boosts?

• Does a product’s observed KPI profile support a sustainable business case, or does it break at scale?

With previous tools, answering those questions required a lot of manual triangulation: exporting rough estimates, building parallel sheets over granular parts of the industry, and cross-checking assumptions with anecdotal industry knowledge… And still feeling that some questions were left unanswered.

The challenges in using them peaked at some point, when I realized that many were paying very premium prices for tools that were excellent at telling what was happening—on a certain level—but not on any level why, and definitely not how.

Note for readers: This article has been originally published on AppMagic’s site here.

Finding the Right Tool to Use

I first came across AppMagic through industry circles and peer recommendations. The positioning was interesting: more affordable, but also more focused on practical, granular category analysis, monetization, and live service insights rather than just dashboards after dashboards.

“I didn’t expect it to replace my existing tools at first. I expected it to be complementary. Instead, it quickly became central, as it had some comfying ‘magic’ to it.”

What made AppMagic stand out was how it allowed me to deconstruct markets and products faster and more effectively, rather than forcing me to dive deeper into higher-level perspectives. The level of categorization, down to genres, subgenres, monetization placements, and event structures, matched how I actually wanted to take quick yet insightful looks to support decision-making or time investments across different research topics.

Instead of, say, abstract “puzzle” labels, I could start slicing reality closer to subcategories, how they behave, and how products perform within them, on top of which I was given complementary information about monetization and events.

Monopoly GO! In AppMagic

Getting started with AppMagic was straightforward. There was no heavy onboarding process or mandatory training period. The UI and data structure were intuitive enough that I could jump directly into exploration.

Within days, AppMagic got integrated into multiple workflows:

• Early-stage opportunity evaluation

• Competitor deconstruction

• LiveOps and monetization benchmarking

• Benchmarking for validating new concepts

• KPI benchmarking for monitoring game progress and investments

• Personal investment research

• And much more

There is depth to the platform, and it is the kind you discover naturally as your questions become more detailed. Eventually, it became a multi-purpose lens I now use to analyze both products and markets, and I’m happy to share a nine-step framework that helps turn market research into real results.

Using AppMagic: Example Scenarios

1. Evaluating Opportunities Within a Genre

By drilling into very specific subsegments, I can assess whether an opportunity is genuinely underserved, growing, mature, or declining. Let’s see how this works with the example of one of the genres that showed a tremendous growth in 2025: Screw Puzzles.

I’ve looked at the Screw Puzzle segment before, and back in 2024, it was already clear that pure 2D Screw Puzzle games were declining. The Market Segment dashboard showed that the subgenre leader, Screw Jam, was losing momentum, with no other title poised to take its place. The reasons were fairly typical: copycat games failing to provide fresh takes, overly aggressive monetization pressure, and a general lack of new ideas.

Screw Puzzles on the Market Segment dashboard

Then, the introduction of 3D Screw Puzzle games gave the segment’s growth another push. However, that growth was concentrated only around one title: Screwdom. That’s why the segment still didn’t invite a straightforward business case consideration. Further still, if you dove deeper into Screwdom, you would notice that its downloads had been going down, whilst cumulative RpD had been on the rise.

This is clearly something one needs to monitor in order to understand how their UA strategy may have reprioritized LTV optimization with lower user numbers over sheer traffic volume—to sustain the current business case. But in order to do it right, you need to start with the bigger picture, and that’s what you can do just by looking at the market composition. Starting from here, you can go further into product analysis—as far as you like.

2. Monetization Strategy & Placement Benchmarking

Instead of guessing where monetization pressure sits, I can actually explore all the essential economy aspects of my game of choice:

• What type of monetization strategies and placements it uses

• Which IAP placements drive the most value

• What upcoming monetization methods and psychological tricks are connected to them

• How aggressively the competitors push their monetization and economy

For example, Monopoly GO! is the fastest-grossing game to surpass $6B in revenue, and it serves as a great learning platform for anyone working with monetization. Using AppMagic’s Monetization Intelligence, I can actually take a look at the game’s vast library of offers. Going into a more granular level, tracking their placements and types, I can learn a lot about the game’s success in IAP monetization.

Monopoly GO! offers in Monetization Intelligence

But most importantly, I can see how these offers are interconnected with other aspects of the game, including any ongoing LiveOps events, and with each other.

3. LiveOps Calendar: Types, Cadence, and Strategic Weight

One of the most interesting things for me has been tracking:

• How frequently events run

• What types of events dominate certain segments

• Whether events are used as core economic engines or secondary engagement tools

This feeds directly into designing LiveOps systems that aim for top-percentile performance, not just table stakes, because having a clear view of how others do things also reveals what it actually takes to reach certain percentile targets with your games.

Take, for example, the Merge games segment with its $1.6B IAP revenue and constant year-over-year growth. Despite how promising it might look, it is important to consider what it really takes to get to the top. And such requirements are big ones, especially for live events.

Gossip Harbor in the LiveOps & Updates Calendar

Even a quick glance at the LiveOps & Updates Calendar of Gossip Harbor, an undeniable leader in the genre, is enough to understand the scale of its LiveOps efforts. It’s packed with various simultaneous interconnected events telling a story of the resources you need to put into motion if you hope to sustain the possibility of getting closer to their level.

4. Investment Analysis (as an Angel Investor)

As a hobbyist angel investor in games, AppMagic helps me do the sanity check:

• Whether teams are targeting the right markets

• Whether their ambitions align with observable market realities

• Whether their differentiation claims hold up against existing competitors

In addition to the tools described above, it also helps to see a list of competitors in specific regions. Using the Top Publishers chart, I can review the list of competitors operating in the same country to better understand the company’s background, its professional environment, and the overall state of the games industry in the region.

Top gaming publishers in Türkiye

5. Tracking Emerging Games & New Phenomena

To stay up to date and track major trends earlier than others, I can, as wanted, set up a custom early opportunity/warning system that allows me to:

• Spot emerging games and trends

• Follow them over time to assess sustainability

• Identify genuinely new systems or segment shifts, not just reskins

For that, I rely on several tools: Advanced Search and Notifications. The first helps me track every new release in the niche, even if it hasn’t built a revenue or downloads track record yet, while the second helps set up custom alerts delivered directly to my email. For example, I can track when the game in a certain niche reaches particular revenue or downloads figures; thus, the alert could be set for “Hypercasual Puzzles with daily IAP Revenue of $10K or more” to track new Hybrid Puzzles.

Screw Puzzles in Advanced Search

6. Creative Tracking & Benchmarking

A proper analysis shouldn’t end with the product overview only. Sometimes, it can be even more important to take a look at the UA side of things:

• Spotting the highest-spending creatives by competitors

• Monitoring creative trends

• Network and regional data

Screwdom creatives in Ad Intelligence

If we look at Screwdom as an example, it’s clear that introducing 3D into the Screw Puzzle was not only about gameplay, but a UA decision, too. Its creatives are built around 3D puzzles, highlighting the game’s unique proposition and underscoring the importance of a marketable core gameplay for new Hybridcasual games. This allows the publisher to showcase actual or semi-actual gameplay for UA creatives and to cheaply scale the required volume of creatives.

“The biggest change after adopting AppMagic wasn’t a single “big win”. It was something more valuable: confidence.”

From these Ad Intelligence views, you can also build confidence in what works and what the segment-wide sentiment is. Like, if you’re not seeing fake ads, maybe you can somewhat confidently assume that you should not lean on them fully in your strategy.

Step-by-Step: How AppMagic Fits Into My Rhythm

With AppMagic, I reach conclusions faster, and they are supported by much stronger evidence. It helps me make confident decisions: from killing weak ideas early to doubling down on opportunities backed by real market signals.

That’s why I most often use the tool during the active concept or investment analysis phases. My typical flow would look like this:

1. Identify a question or hypothesis (product, market, monetization, system, etc.)

2. Slice the market down to the right level of granularity

3. AppMagic-deconstruct relevant competitors

   1. KPI ranges, monetization strategies, and live system patterns

4. Granular self-deconstruction, as required, including macro/product layers, and cross-checking against what the tool shows

5. As needed, validate marketability layers:

   1. Channels

   2. Creatives, including possible volume requirements

   3. Trends, risks, and opportunities

6. Feed those insights into validation models, design decisions, or investment theses.

Yes, this might take time and is always about creative thinking with data informing the work and interlinking. But it always translates into meaningful time savings, fewer blind spots at early validation stages, and better alignment between product strategy and actual market reality.

It also changes the quality of internal discussions: conversations become grounded in data rather than opinions, which makes decision-making clearer and more constructive. But most importantly, it helps overcome the biggest friction point in market analysis: the gap between macro-level data and actionable insight.

• We see talks about dynamically segmented events.

• We see talks about tailoring offers to specific cohorts.

• We see talks about AI-driven playstyle detection and behavioral clustering.

• We talk about live-ops engines that mutate the game experience per user.

And yes, in many ways, this direction makes sense. But the means to reach this direction properly? Many times not so much.

For example, mobile F2P, in particular, has reached a maturity point where improving retention and financial performance increasingly requires understanding playstyles at a granular level. AI and data-driven product management are pushing us toward systems that detect intent patterns and serve personalized content accordingly.

In many ways, this is progress. But here’s the uncomfortable truth: Hyper-personalization is often a lazy solution to a deeper design problem.

Hyper-Personalization Alone Is Dangerous

Heavy segmentation can:

• Increase production cost.

• Fragment the player base.

• Reduce cross-archetype exposure.

• Create event fatigue.

• Inflate live-ops complexity.

• Shrink systemic depth.

• Leave engagement and money on the table.

And worst of all:

It can mask weak core system architecture.

If your game requires hyper-personalized event design to keep archetypes engaged, that’s often a signal that your systems aren’t intrinsically elastic enough.

So, instead, before building systems that split players into increasingly narrow silos, you should always ask:

Have we designed systems and/or interconnectivity that naturally serve multiple archetypes at once?

Because if you haven’t, you’re patching over shallow design with algorithmic band-aids. This is something where multi-archetype systems design approach and mindset grows importance over single-purpose design approaches.

The Multi-Archetype Design Mindset

Multi-archetype systems design means:

• One system serving multiple player archetypes through different engagement modes.

• Interconnected systems that progress the overall game even if players don’t deeply engage with all of them.

• Features designed with layered motivations instead of single-purpose funnels.

• Etc.

This is fundamentally different from some takes I’ve seen e.g., being talked on LinkedIn, like:

“Let’s create separate events for each playstyle and segment players by that.”

That path can be beneficial. But, many times with poor systems approach it still can lead to fragmentation, production overhead, event fatigue, and eventually operational complexity that in worst cases eats margin.

Instead, multi-archetype systems create structural elasticity inside the game, which is something many should have in place before going too deep, if not needed even past this point at all.

Multi-archetype systems allow e.g.,:

• Competitive players to compete.

• Social players to cooperate.

• Optimizers to min-max.

• Casual collectors to accumulate.

• Explorers to discover.

• And much more.

The best part, this all can be achieved within the same “macro-system”.

When done correctly, hyper-personalization could even become:

1. A minor optimization layer.

2. Or completely unnecessary.

Because… the system already adapts through player agency!

Light Examples

Monopoly GO’s Archetype Biasing

You can see early, lighter versions of this thinking in Monopoly GO!.

Take a team-based event, as an example. Despite fully leaning to team-based activities, players can technically also choose to play solo, even the solo option is visually secondary (placed below the team-building flow).

This placement order most likely matters for Monopoly GO!, as the default nudges players toward social participation, which is very likely seen through experiments improving engagement and monetization in solid manner. But, beyond that, solo exists, even in de-emphasized format, as there’s also meaningful results probably gained from that as well.

The system serves multiple archetypes / playstyles, and it does so without fully splitting the feature into isolated archetype-targeted variants. One reason Monopoly GO reached such massive scale is precisely because its overall design serves multiple archetypes simultaneously.

It’s not just a board game. It’s e.g.,:

• A collection meta.

• A competitive race.

• A cooperative event engine.

• A long-term progression economy.

There’s still, of course, room for deeper multi-archetype layering, but the structural direction is slightly better than many others directions are pushing developers and publishers to go.

ARC Raiders: Archetype Layering as a Pillar

On the PC/console side, I discussed in The Future of Extraction Shooters article how ARC Raiders builds one of its core success pillars around serving multiple archetypes.

Unlike many extraction shooters that heavily lean into hardcore PvP tension, ARC Raiders layers:

• PvE cooperation.

• Environmental scavenging.

• Long-term progression.

• Competitive PvP risk.

• Social squad play.

• Narrative / quests.

• Etc.

The result is a broader archetype surface area. Instead of segmenting these audiences into different single-purpose modes or events, the core loop itself supports them.

They show on some level quite well the difference between multi-archetype system architecture instead of leaning to reactive personalization. Beyond this and their success on this approach, I do think they could do a bit more still on this front, which will be seen through future updates if they go more on this direction or do something else based on strategies of their choosing (as they pretty much can choose and experiment past their success).

Multi-Archetype Design Across Genres

Past given examples, let’s go deeper on this through some (hypothetical) examples.

Modern Puzzle Games

Instead of:

• One competitive leaderboard event.

• One collection album event.

• One narrative mini-campaign event.

Let’s think about a new single meta-layer where:

• Competitive players push time-based leaderboards, whilst benefits flow to below points.

• Collectors climb same boards for cosmetics and seasonal artifacts, whilst benefits flow to other presented points.

• Social players contribute to guild / team-based puzzle-solving goals, which on same system may advance different reward routes / boards on top of their single contributions advancing above points.

• “Optimizers” theorycraft resource economies to maximize event multipliers, and take part as they want beyond that in single or social activities.

The same core play fuels multiple motivations and still progresses things further through interconnectivity.

Interconnectivity here ensures e.g.,:

• Playing casually still contributes to guild progression, if you’re part of one.

• Competitive engagement boosts other milestones and progression / reward paths.

• Collection unlocks modify gameplay expression in casual and social play.

No segmentation needed. Just multi-archetype targeting for system design. Same thinking can be applied to actual core and meta, and/or for events / live events as takes go.

Action-RPGs / MMORPGs

Let’s think about a dynamic world boss system approach.

Instead of:

• Separate PvP tournaments.

• Separate co-op raid events.

• Separate solo challenge ladders.

One integrated system could allow:

• Solo players to weaken world bosses over time.

• Guilds to coordinate final kills.

• PvP factions to fight over spawn control.

• Crafters to profit from drop-based resource cycles.

• Explorers to discover spawn patterns.

Interconnectivity in this rough example ensures that e.g.,:

• Even non-combat players influence outcomes / economy.

• Social and competitive layers collide organically.

• The system progresses globally without mandatory participation.

Extraction Shooters

Beyond ARC Raiders’ styled take, think about a seasonal “frontline” meta-layer where:

• PvP-focused players push territory control.

• PvE scavengers collect rare components.

• Social players coordinate and collaborate over PvP / PvE / PvPvE.

• Risk-averse players contribute via e.g., “logistics” and crafting.

• Hardcore players escalate on high-risk zones.

Everyone contributes to the same “macro”. But, no-one is intentionally “forcedF into every sub-loop, even though the typical risk-reward layer for extraction might stay same.

Strategy / 4X

One alliance war system can serve:

• Diplomats (negotiation mechanics).

• Economists (resource optimization).

• Military tacticians (battle planning).

• Saboteurs (covert mechanics).

• Social leaders (community coordination).

Interconnectivity > Isolation

Multi-archetype design rests on high-level on two pillars.

1) One System Serving Many Archetypes

Including e.g.,:

• Multiple interaction modes.

• Different reward surfaces.

• “Choice” architecture.

2. Interconnectivity Without Mandatory Participation

Players:

• Progress the macro layer even if they ignore or de-emphasize certain systems.

• Are exposed to adjacent loops passively.

• Drift between archetypes over time.

Full Ignorance Eats Engagement

If your strategy is heavy data- or AI-driven segmentation with archetype-targeted events, something dangerous can happen:

Players stop seeing adjacent motivations.

This means that by your strategy you reduce cross-pollination, and most likely extra engagement and monetization opportunities.

You train achievers to only play achiever events. Collectors to only show up for album events. Competitors to only care about ranked ladders.

Exposure disappears… and with it, business potential.

The Live Ops Implication

Live ops becomes dramatically more efficient under multi-archetype design.

Instead of:

• Producing multiple segmented event tracks.

• Designing bespoke mechanics per cluster.

• Managing complex targeting logic.

You simply can:

• Build few deeply layered seasonal systems.

• Tune reward routes, interconnectivity and weighting per vector.

• Plan economy multipliers and modifiers per route.

• Etc.

If the core design is strong, personalization becomes refinement and not repair.

The UA & Marketing Layer

There’s another overlooked benefit for user acquisition.

In Unlocking the Power of Intrinsic Motivation article, I discussed how intrinsic loops should shape our marketing narratives.

With multi-archetype systems, you can create truthful creatives for different archetypes, without building separate experiences.

From the same system:

• A competitive-focused creative shows leaderboard tension.

• A social creative highlights guild collaboration.

• A collector-focused creative showcases e.g., cosmetic progression.

• An optimizer creative emphasizes economy mastery.

You “hypertarget” through systems-born messaging. This aligns product and marketing, in which your unique selling points become archetype-specific value propositions drawn from the same core. No need to lean (at least that fast) to “fabricated” hooks for CPI optimization.

The Strategic Decision

What I’m writing and discussing here doesn’t mean hyper-personalization is wrong.

AI-driven playstyle detection.
Behavioral clustering.
Offer / event optimization.

These can be powerful.

But, honestly, they should come after:

1. Strong multi-archetype system architecture.

2. Deep interconnectivity.

3. Intrinsic motivational layering.

And I get it. For some games, especially smaller teams or tightly scoped designs, full multi-archetype layering may be too heavy. In those cases, segmentation experiments may be the right short-term lever. In some cases, maybe it’s too late to change the direction of a live product, if you have inherited one that isn’t designed or easy to adapt to that way. Sometimes there’s just lots of debt over tech., etc.

But strategically:

Multi-archetype systems create compounding structural advantage.

They:

• Scale better.

• Reduce content overhead.

• Improve organic retention.

• Support truthful UA.

• Enable light-touch personalization.

• Protect against archetype stagnation.

And… even if resources would be tight, I’d always argue that good systems are better investment for your money from scratch instead of realizing this past your first lever or failure.

So, all in all, the future of games is not just hyper-personalized. It is architecturally more multi-dimensional.

When you design systems that:

• Serve multiple archetypes.

• Interconnect without coercion.

• And expose players to adjacent motivations.

You don’t need to chase personalization with poor means. You’ve already built everything into the fabric of the game. And that is far more powerful than any algorithm.

What began as e.g., tightly scripted, replayable team experiences is steadily evolving into something more systemic, more persistent, and more unpredictable as we’re seeing and predicting fresh takes on the genre.

One soon realizing future sits at the intersection of two forces:

• Roguelike / roguelite systemic design.

• Co-op-first social play.

However, I believe this is just the beginning.

If things continue with this approach, I think we’re actually seeing at some point future games based on the intersection of three forces:

• Roguelike / roguelite systemic design.

• Co-op-first social play.

• Extraction-inspired DNA / PvPvE structures.

Individually, each of these has proven successful. Combined, they point toward new genre phases, one likely to define the next 3 to 5 years of multiplayer shooters, followed by a deeper evolution that could shape the direction of the genre for at least the next decade.

Let’s dive deeper.

AA / AAA Momentum: Roguelite Systems Enter the Shooter Core

One of the clearest signals of these directions comes from the AA / AAA space, where systemic replayability is no longer a niche experiment but a central design pillar for some studios.

A strong example is Housemarque, the Finland-based studio now owned by Sony. Their work has helped “normalize” roguelite mechanics in high-fidelity shooter experiences, starting from Returnal.

Returnal proved that:

• Roguelite loops can coexist with premium production values.

• Procedural and systemic progression can carry emotional narrative arcs.

• Failure can be reframed as forward momentum rather than punishment.

Returnal features trailer. (Source: https://www.youtube.com/watch?v=OKZV00Esu54)

Returnal’s Formula

Core Roguelite Loop

• Death resets most items, weapons, and run-specific currencies, but key upgrades and narrative progress persist.

• Procedural structure reshapes each run through shifting rooms / biomes, item placement, and encounters.

• Fast third-person combat built around mobility and bullet-hell experience with encounters and avoidance.

Systemic Build Variety

• Weapons with randomized stats, traits, alternate fire modes.

• Weapon Proficiency enabling stronger drops deeper into a run.

• Strategic decision layers:

  • Malignant items that offer power with risk.

  • Parasites that introduce trade-offs.

  • Adrenaline stacks rewarding skillful, damage-free play.

“Dual-layer” Economy

• Run currency for immediate decisions.

• Persistent resources that carry meta-progression across deaths.

Narrative through Repetition

• Story fragments, environmental storytelling, and progression unlocked over multiple cycles.

The Blend

This blend, permanent growth, temporary power, and systemic risk / reward, became the studio’s defining design identity.

Now, they’re escalating that identity.

Saros: Formula Escalation

Housemarque’s upcoming project, Saros, appears to deepen and intensify the same philosophy and formula they’ve invested once already in.

While the game isn’t released yet, the direction communicated so far suggests a stronger and deeper emphasis over the existing formula:

• Newly thought Roguelite comeback (“Death → return stronger” loops) mechanics.

• Shapeshifting biomes and level states., with a world-state escalation system (“eclipse”) that:

  • Corrupts the environment, escalates enemy systems, and raises audiovisual intensity and difficulty.

  • Improves rewards in exchange for higher risk.

  • Interacts differently with armor and weapon builds, in connection with the enemy system escalation.

• Permanent progression via armor, perks, and talent-like systems, with skill / talent tree styled approach.

• Modifier systems balancing protection vs. offensive power as well as world / enemy conditions.

  • Note: Manipulators are something as systems that I’ve predicted gaining popularity in one of my previous articles here (https://gamesalchemy.substack.com/p/41-manipulator-mechanics-new-frontiers):

• Continuation mechanics.

• And much more.

Compared to Returnal, these systems appear more depthful, layered and tension-driven, and less about a single run loop and more about shaping the world itself across repeated engagements. And, I think this is a great direction, and I hope they’ll do well with this game release, as from that they can get where I’m expecting roguelites and co-op direction going.

Saros Gameplay Overview Trailer going through its base systems. (Source: https://www.youtube.com/watch?v=OcLGdMG0L8Q)

As Returnal established the formula, Saros looks a step to evolve it into a bit more persistent and reactive ecosystem, focusing in building excitement and engagement through clearer power progression.

Note: As we’re covering Extraction DNA in the article a bit as well, power progression and systems depth is something I’m predicting coming for future Extraction Shooters as well. See article about this topic here (https://gamesalchemy.substack.com/p/57-the-future-of-extraction-shooters):

What Housemarque should / could build next? Well, if they do well, and my article ages properly, I’d say they should end up building a proper co-op and/or PvPvE game in this space, to continue multiplying their success.

Co-op Momentum

As AA / AAA side is building momentum over the roguelite side, at the same time, the market has shown a powerful trend: co-op and “friends-first” / friendslop games are surging more than the industry predicted many years back.

Remember when as a developer it was almost impossible to argue for co-op games’ success? Well, that has changed with there being lots of momentum over games like Peak, Repo, Phasmophobia, Schedule I, and such.

It seems we’ve inevitable ended up players increasingly wanting e.g.,:

• Shared fun.

• Shared tension.

• Shared risk.

• Shared reward.

• Shared win / recovery conditions.

• Social storytelling emerging from emergent and/or systemic play.

• …and much more.

Even ARC Raiders and many games have proven co-op really stands out in a shooter setting, even it includes PvPvE in its core. And, not to forget, Helldivers 2 is of course standing there leaning on co-op as well as if you look more into extraction space, Hunt: Showdown has also duo and trip setups.

Note: Interested to read more about the phenomena behind ARC Raiders, Helldivers 2 and Hunt: Showdown? Check my article here (https://gamesalchemy.substack.com/p/57-the-future-of-extraction-shooters):

How we ended here? There are lots of e.g., macro and micro economics as well as economics behavior conditions behind this all. On top of that, there are even, which you might not think much, lots of psychology and physiology behind these phenomena as well, on both on macro and micro levels. These are totally different article and discussion point themselves. For now, let’s just say that seeing overall where some part of the industry has puts its money, this side has “naturally” being craved by the other side, incl. players’ side, and from that overall I think we’ve ended seeing these games popping up and building success. Naturally we’ve also seen more curiosity and encouragement for going here and being bold about bringing our co-op visions to life.

Momentum Combination

The combination of currently growing co-op and roguelite momentum looks like a no-brainer, if you look both sides’ ends with simplistic lenses on; and, therefore, this makes it one predictable direction where co-op shooters can go.

When we look into some similarities, roguelite shooters already generate e.g., emotional spikes from e.g., failure, survival, unexpected builds, near-death moments. When those experiences become shared, they supposedly multiply in intensity and memorability.

This is why the next logical step is not just co-op or roguelite shooters alone, but co-op roguelite shooters. And, actually, momentum is building already to this direction.

The return of creators behind co-op shooter classics like Left 4 Dead, signals renewed interest in pushing cooperative shooter design forward again: https://www.playstation.com/en-us/games/4-loop/.

4:LOOP trailer. (Source: https://www.youtube.com/watch?v=6-5ieEtmgTc)

From PlayStation Official Site:

“Created by Mike Booth (Left 4 Dead) and the interactive storytellers at Bad Robot Games, 4:LOOP is a tactical, four-player co-op shooter crafted for endless replayability and infinite ways to build the ultimate team. Together, if you can learn from your mistakes, you might just fail to save the world.

Experiment. Improvise. See if you can beat the odds.”

4:LOOP in-game captured image. (Source: https://www.playstation.com/en-us/games/4-loop/)

In terms of us seeing really soon what’s coming on this side, I think the momentum will just continue building up.

Co-op Roguelite Shooter DNA

In one format, over how a co-op roguelite shooter could look, you can look into a multiplayer-first design built on systemic progression instead of scripted missions. Let’s dive deeper on this.

World Progression

• Teams unlock new regions and biomes over time.

• Global progression shifts the structure of future runs.

• Narrative emerges through world changes rather than linear storytelling.

Loop Tightening

• Each cycle increases stakes, difficulty and strategic demands.

• Systems react to player success / failure patterns.

Layered Progression

• Temporary run-based builds.

• Permanent meta upgrades.

• Potentially even team-level progression (shared unlocks, structures, tech.); permanent and temporary.

Risk vs. Reward

• ”Corrupted” zones offering higher payouts.

• Trade-off decisions impacting entire squad survival.

• Build synergy across teammates.

Adaptive world conditions

• Weather, “corruption”, faction activity, and AI evolution.

• Difficulty scaling tied to player performance.

• Combined manipulators.

Note: Read more about manipulators here (https://gamesalchemy.substack.com/p/41-manipulator-mechanics-new-frontiers):

Emergent gameplay

• Unexpected team roles.

• Improvised strategies.

• Player-driven “stories” instead of authored missions.

This is where co-op becomes more than a mode. It becomes the core operating system of the experience.

The Matchmaking Challenge: Roguelite Meets Multiplayer

A multiplayer roguelite introduces a critical design challenge: matchmaking.

Traditional lobbies assume many times parity, incl. similar skill, similar power, and/or similar progression. Roguelite systems, considering the systemic direction they’re going on AA / AAA side, will break this.

A successful system would need to consider e.g.,:

• Meta progressions and levels as well as build types.

• Run history and playstyle / progression compatibility.

• Social preference (friends vs. solo fill).

• World conditions’ adaptability.

• AI conditions’ adaptability.

• And much more, even considerations not around symmetric directions but also asymmetric directions.

The complexity raises up by this, incl. the importance of designing the matchmaker properly. Matchmakers can make or break your social game, see more about how you should approach them here (https://gamesalchemy.substack.com/p/42-matchmaking-the-hidden-engine):

However, despite the complexity on matchmakers, I believe early in a game’s lifecycle, concessions must be considered:

• Wider matchmaking tolerances.

• Assisted onboarding runs.

• Scaled enemy difficulty based on team composition.

…because overall if you’re wanting to onboard players and build proper DAUs / MAUs for the game, you’ll need to consider how you can sustain that past the whole journey. Having a successful game helps of course, but it’s something you cannot lean as even those games needs to be grown over time properly. And, good systems will help you on that.

Over time, matchmaking would evolve into a core design system:

• Pairing complementary builds.

• Balancing risk profiles.

• Creating intentional friction and synergy.

This becomes more about creating engaging tension to sustain a proper design, on top of fairness.

PvPvE: Where Extraction Design Enters the Picture as 3rd Pillar

Once roguelite and co-op systems stabilize over the co-op and current state roguelite pillars, PvPvE becomes the next frontier, and for that I believe we’re needing a 3rd, Extraction DNA, pillar.

Extraction shooters already introduced:

• Enter → raid → survive → extract loops.

• Persistent economies.

• High-stakes risk.

Combining that with roguelite progression and co-op / PvPvE unlocks powerful possibilities. This can formulate multiple scenarios, over which I’ll give two examples below.

Scenario 1: Jump-In World Spaces

• Multiple squads enter a shifting map.

• Areas open dynamically as well as by based on players’ in-game activities.

• Teams race to raid corrupted zones.

• High-tier resources require confronting elite enemies.

• Extraction becomes the climax.

Scenario 2: MOBA-like Persistent Worlds

• AAA-scale environments.

• Long-term territory control.

• PvE threats shaping PvP opportunities.

• Extraction loops feeding macro-progression.

This hybrid model keeps PvP from dominating the experience while ensuring constant unpredictability. The PvE world becomes the “third player.”

Single-Player Can Still Matter

Despite the multiplayer focus, these systems can on some games benefit from solo compatibility.

Different design pillars could coexist:

• Solo roguelite runs for mastery and experimentation.

• Co-op for shared and separated / combined progression.

• PvPvE for high-tension stakes.

Note: I’ve discussed about blending single / campaign vectors in the past with multiplayer vectors, which heavily lean on what I’m writing here. See more from my article here (https://gamesalchemy.substack.com/p/45-blending-vectors-designing-games):

Players could fluidly shift between “modes”, with shared progression tying the ecosystem together. This avoids fragmenting the audience and reinforces the idea of a single living world rather than separate modes.

The Real Opportunity: Systems, Not Modes

Whilst this article and discussion focuses heavily on specific directions, I believe beyond that the future of co-op shooters isn’t all about adding roguelite elements or PvPvE modes.

It’s about building:

• “Persistent” and/or “adaptive” worlds in combination.

• Systemic progression.

• Shared environments and conditions.

• Emergent game and team dynamics.

• Risk economies that feel meaningful.

Note: I cover some things like emergent and systemic mechanics in my past articles, which relate heavily to where I think games are going. Whilst the article what I’ve written focuses on F2P games, these games can be also premium or premium + microtransactions based. Read more here (https://gamesalchemy.substack.com/p/28-systematic-and-emergent-gameplay):

Studios like Housemarque are already showing how high-production shooters can adopt roguelite DNA without losing emotional or cinematic impact. The next leap is socializing those systems (which and Bad Robot Games is looking to showcase) making progression shared, tension communal, and outcomes unpredictable because other players exist inside the same systemic web.

That’s where co-op shooters stop being content-driven experiences and become living ecosystems.

Not just mechanical power (e.g., DPS, levels, gear, rank), but social power. Who gets to shine within your social systems. Who gets listened to. Who sets the tone. Who influences the economy. Who defines what “meta” even means. Who overall has power and equity on social side.

As more and more games can evolve (if designed right) into persistent ecosystems rather than isolated products, social equity has quietly become one of the most important (/and sometimes least intentionally designed) progression layers in modern game development.

It exists in its simplest form around three overlapping spaces:

1. Inside the game

2. Around the game (systems & meta layers)

3. Outside the game (community, creators, and culture)

And, within each of these, there are both tangible and intangible forms of power.

With great social power and equity comes great responsibility.

Understanding this is no longer optional for developers. It is a core part of how games grow, stabilize, fracture, or even in some circumstances collapse.

What is Social Equity?

Social equity is a player’s accumulated power through systems as well as influence, trust, recognition, and authority within a game ecosystem.

It is by some form of definition a combination of:

• Systemic power

• Reputation

• Authority

• Credibility

• Access

• Network position

• Cultural relevance

It compounds over time, much like wealth or skill. And like any economy, it has visible (tangible) and invisible (intangible) forms.

Social Equity Inside the Game

This is where design can intentionally shape power.

Tangible Social Equity in the Game

These are system-recognized markers of influence, such as:

• Guild leadership roles

• Raid leaders and strategists

• High-ranked PvP players

• Economy controllers (traders, crafters, auction manipulators)

• Territory owners

• Clan founders

• World-first achievers

Some genres where this thrives:

• MMOs / MMORPGs

• Extraction shooters

• Sandbox RPGs

• Strategy and survival games

System-driven Examples

Guild ecosystems:

• Guild owner controls access, direction, and social hierarchy.

• “Officers” gain trust-based power.

• Recruitment decisions shape player pipelines.

Raid leadership:

• Knowledge = power.

• Strategy creators become “institutional memory”.

• Social equity accumulates through success repetition.

Economy dominance:

• Players controlling crafting chains become indispensable.

• Auction house experts dictate supply flows.

• Resource “cartel” behavior emerges.

Extraction shooters:

• Shot-callers determine team survival.

• Route planners hold tactical authority.

• Trust networks determine squad inclusion.

Designers can actively enable this:

• Visible leadership ladders

• Reputation scoring

• Guild (legacy) systems

• Economy influence tools

• Social progression tracks

These mechanics transform players from consumers into actors in a social power structure.

Intangible Social Equity in the Game

This is harder to measure, but often very powerful.

• “That player who always helps newbies”

• “A friend with whom I always like to play”

• The strategist everyone trusts

• The calm voice during raids

• The person who never tilts

• The lore / theorycraft expert

• The culture-setter

These players in some games:

• Hold no formal rank

• Own no territory

• Have no mechanical dominance