By Oleg Sidorkin, CTO of Cinevva

Bungie just ended active development on Destiny 2 after nine years, with layoffs to follow, and moved its people to Marathon, a game that lost more than half its concurrent players in its first month. A few weeks earlier, OpenAI shut down Sora after burning roughly a million dollars a day against about two million in lifetime revenue. Through the spring, studio after studio cut staff. It's easy to file these under different headers, live service fatigue, AI hype, a soft economy. They're the same failure wearing three costumes.

Three collapses, one shape

Each story has the same skeleton. A very expensive thing carries very high fixed costs. The audience shifts. The cost structure can't shift with it. Destiny 2 needed hundreds of people shipping content forever just to stand still. Sora's costs scaled with every video generated, so popularity made the bleeding worse, not better. A 300-person studio with one flagship in production runs a payroll that doesn't care whether the flagship is going well. When revenue moves and costs can't follow, the only lever left is to cut the people. That's why every one of these ends in layoffs.

The problem was never the product

Bungie's mistake wasn't that Destiny 2 failed. It ran for nine years and earned a devoted audience. The mistake was that the only follow-up was another nine-figure live service game, so when Marathon wobbled there was nothing smaller to fall back on. Sora wasn't a bad demo. It was a genuinely impressive model strapped to an economic engine that punished its own success. In both cases the thing they shipped worked. What didn't work was the size of the bet behind it. A studio that puts everything into one giant title has no shock absorbers. The first bad quarter is also the last one.

The only real defense is a cheap miss

Here's the part the headlines skip. The studios and tools that survive downturns aren't the ones that pick winners more often. Nobody picks winners reliably. They're the ones where a miss doesn't end the company. If a game costs a small team a few weeks instead of a few hundred people a few years, a flop is a Tuesday, not a funeral. The math that just ended Destiny 2's development assumes each bet is enormous and therefore each loss is fatal. Drop the cost of a single attempt low enough and the logic inverts. You get to be wrong most of the time, which is the only honest way to be right occasionally.

This is why the fixed-cost trap is structural, not a Bungie problem or an OpenAI problem. Any model that needs hundreds of people, or compute that grows with usage faster than revenue does, is fragile by design. It looks strong right up until the audience moves, and the audience always moves.

What this means if you're building

The future isn't fewer, bigger games carried by thousand-person teams. It's many more games made by small teams and individuals, where trying something costs almost nothing. That's not optimism, it's where the economics point. The audience that left Destiny didn't disappear. It fragmented across dozens of games, and the next wave that captures it will be cheaper to make, faster to ship, and easier to iterate on than any decade-long monolith.

That's the bet we're building at Cinevva. Games made and played in the browser, where the cost of an attempt is low enough that one miss doesn't take the studio with it. The economics that just ended Destiny 2's development are exactly the economics we built the platform to route around. The giants are learning the hard way that scale without a shock absorber is just exposure. The people who internalize that first get to build through the downturn instead of being cut by it.

Related:

• Bungie ends Destiny 2 development — the sunset, the layoffs, and the Marathon bet
• Sora is gone — a million dollars a day against two million in lifetime revenue
• Game industry layoffs continue through March 2026 — the wider contraction
• The rubble of the giants — the indie opportunity on the other side of the collapse
• For game creators — publish playable games, subscription pool, playtime-based payouts

By Mariana Muntean, CEO of Cinevva

Every story about a studio sunsetting a game gets written as a tragedy, and for the people losing their jobs it is one. But there's a second story underneath, the one with no press release. When Bungie ends active development on Destiny 2, it isn't only cutting a team. It's releasing an audience. Millions of players who organized their evenings around one game are, slowly, looking for the next one. That's not a loss for games. It's a redistribution, and small teams can catch more of it than they think.

A sunset is a migration

When a live-service game winds down, its players don't quit games. They quit that game. Destiny's community didn't lose interest in playing with friends. They lost the reason to keep doing it in one specific place. The same thing followed every big sunset before this one. The audience scatters, and it scatters toward whatever feels fresh, social, and alive. The giants spent a decade pulling those players into one room. Now the doors are opening and the players are back on the open market.

Displaced players are the cheapest audience you'll ever reach

The hardest thing in games isn't making one. It's getting anyone to try it. The most expensive line item for most small studios is attention. A player coming off a sunsetting live-service game is, for a short window, actively shopping. They have time they used to spend, a friend group looking for a new home together, and no current loyalty. That's the rarest combination in the business, motivated and unattached and arriving in groups. You don't have to pry them away from anything. The giant already let go.

What the giants can't do anymore

Here's the asymmetry. A thousand-person studio can't chase a fragmented audience. Its cost structure, the fixed-cost trap we wrote about, only works if it lands one massive hit. Twelve weird games for twelve niches doesn't cover a payroll that size. So the exact moment the audience fragments is the moment the giants are least able to serve it. That gap is the indie opening. Small teams can make the strange, specific, social games a fragment of a fragment actually wants, at a cost where a niche audience is more than enough.

How to be there when they land

Being in the rubble at the right time isn't luck, it's positioning. It means shipping often instead of betting everything on one launch. It means making games cheap enough that you can have one ready when the migration starts, not eighteen months after it ends. It means meeting displaced players where they already are, in a browser tab, with something they can play in one click and bring their friends to.

That's what we're building at Cinevva. A place where small teams ship playable games fast, get found through reels instead of an ad budget, and earn from playtime instead of a launch spike. The giants are teaching the whole industry that scale is fragile. The flip side of that lesson is that their audience is up for grabs, and the people ready to catch it are the ones who never needed the audience to be huge in the first place.

Related:

• The fixed-cost trap — why the giants are fragile in the first place
• Bungie ends Destiny 2 development — nine years of audience, back on the market
• Game industry layoffs continue through March 2026 — the scale of the contraction
• For game creators — reels discovery, subscription pool, playtime payouts

By Oleg Sidorkin, CTO of Cinevva

Two months ago we wrote that browser rendering had its best month ever, and we assumed it was a spike. It wasn't. It was the start of a trend, and the trend has a direction. The browser is becoming a place where you ship a real game, not a place where you port a small one.

What landed since March

Run the list. Babylon.js 9 shipped clustered lighting for thousands of dynamic lights, volumetric lighting, and a full Gaussian splatting overhaul. Three.js r184 added HTMLTexture, which renders live, interactive DOM as a texture on a 3D surface. PlayCanvas v2.17 brought GPU-driven Gaussian splatting on WebGPU, with f16 spherical harmonics and GPU sorting and frustum culling. Godot 4.7 beta added WebGPU web export behind a flag alongside real HDR output and area lights. Chrome 146 shipped a WebGPU compatibility mode that runs on OpenGL ES 3.1 and Direct3D 11, and WebGPU itself reached W3C Candidate Recommendation. Any one of those would make a notable quarter. They all landed in about eight weeks.

"Good enough for a demo" became "good enough to ship"

The features that arrived aren't toys. Clustered lighting is how you light a scene with thousands of dynamic lights without the frame rate collapsing. Gaussian splatting is how you put photoreal captured environments into a game at interactive frame rates. GPU-driven sorting and culling is the difference between a tech demo that stutters and a game that holds 60. These are the techniques native engines use to ship AAA, and they now run in a tab. The compatibility-mode work matters just as much in the other direction. It means WebGPU reaches the cheap and older hardware most players actually own, not just developer machines with a high-end GPU.

We've been building on this, by hand

We're not reading this off a press release. We've spent the last stretch building an open world that runs in the browser, across more than sixty spike experiments, from ugly terrain baselines to GPU marching cubes and streaming LOD. We wrote the trail up as a full series and a longer piece on the methodology. Almost every feature above maps to a problem we hit the hard way. When clustered lighting lands in a mainstream web engine, that's a stretch of our own code we get to delete.

The objection is dead, the habit isn't

"You can't make a real game in a browser" was true for a long time, and it stopped being true while most of the industry was looking the other way at AI. The technical ceiling that justified shipping a native client first and a web build maybe-never has lifted. What's left is habit. Engines, studios, and toolchains are still built around the assumption that the browser is the lesser target.

That assumption is the opportunity. We built Cinevva on the bet that the browser would become the default place to ship and discover games, not the fallback. The rendering stack just spent two months proving the bet out. The studios that update their mental model first get a distribution surface with no install friction and an audience one click away. The ones that wait will port to it eventually, after everyone else already lives there.

Related:

• Browser rendering just had its best month ever — the spike we thought was a one-off
• Babylon.js 9 released — clustered lighting and Gaussian splatting
• Three.js r184 lands HTMLTexture — live DOM as a 3D surface
• PlayCanvas v2.17 adds GPU-driven Gaussian splatting — splatting on WebGPU at scale
• Godot 4.7 beta — HDR output, area lights, WebGPU web export
• Chrome 146 adds WebGPU compatibility mode — WebGPU for older GPUs
• What it takes to build an open world in a browser — our own trail

By Mariana Muntean, CEO of Cinevva

GDC's State of the Game Industry survey for 2026 put two matching numbers in the headlines. 52% of game companies report using generative AI in production and at the same time 52% of developers say generative AI is having a negative impact on the industry. Same percentage, opposite read on the future.

Beneath that symmetry is another split that gets less airtime. Only 36% of respondents said they personally use generative AI, while company-level adoption sits higher. Management is buying tools that a lot of individual developers never touch. The gap is a clue about where the real argument lives. It is not only ethics. It is who controls the pipeline and whether the person at the keyboard thinks AI can actually do their job.

The comfort of staying manual

Plenty of developers who avoid AI are not naive. They are running a mental model that sounds like this: my work is a chain of hard problems that do not reduce to a chat prompt. A unique concept has to survive contact with modeling. A model has to survive rigging. Rigging has to survive animation. Animation has to survive gameplay feel and systems design. At each handoff, taste and constraints matter. An LLM that writes a decent paragraph about a character is not the same thing as a mesh that deforms correctly, a rig that an animator will not fight, or mechanics that read as intentional rather than mushy.

That story is not wrong for how most tools work today. General models are strongest at isolated tasks. They are weak at holding a single creative thread across disciplines without you stitching the pieces together. So the feeling of being "safe" by not relying on AI is partly technical. If your job is the glue between concept art, topology, skin weights, state machines, and camera language, it is easy to believe automation will stay on the shallow end for years.

Steam and other players still draw lines

The same instinct shows up on the distribution side. Steam does not block games for using generative AI across the board. Valve does require clear disclosure when AI-created content ships to players, with extra scrutiny if the game generates content live at runtime. Listings also have to stay on the right side of rights and safety rules. That is not the same as a mesh topology problem, but it is another reason teams treat AI as risky. A big PC storefront turned the question from "can we make this?" into "can we ship this here without a label fight or a review surprise?"

Other gatekeepers went harder. Games Workshop banned AI-generated work across Warhammer properties. The Indie Game Awards pulled a major nomination over AI use in development even when fans argued the shipped game was clean. Community moderators have walked out over AI-looking trailer work. Epic's Tim Sweeney and Valve have argued in public about whether Steam-style labels help or hurt. The point is not which executive is right. The point is that distribution and IP owners are fragmenting. A developer who stays fully manual simplifies one whole layer of that fight. No generative assets in the player build means less to disclose and less to defend when a forum decides your key art looks synthetic.

We wrote more about the trust and labeling stack in AI controversy, trust, and the post-AI economy and spell out how we handle labels on Cinevva in AI-generated content policy.

Why that safety is shaky

The same survey shows sentiment moving fast. Net positive views of AI's industry impact fell. Negative views rose. Layoff numbers and union support tell you people are not calm. So the psychological picture splits again. Some developers feel protected because the full stack is still hard. Others feel exposed because studios are buying efficiency anyway, with or without their consent.

Those two groups are not always talking about the same layer of the stack. Executives often mean "can we ship more with less on this milestone?" Artists and designers often mean "will my specialty still exist?" Both questions are real. The first rewards partial automation. The second punishes anyone who assumed their corner of the pipeline was too bespoke to touch.

What would actually change the calculus

If the industry moves from one-off generators to connected workflows, where a concept, a rig, and a playable loop share one context, the "I am safe because this is too custom" argument gets narrower. Not because taste goes away. Because the boring seams between steps stop eating half your calendar. The threat to pure manual workflows is not a single model that does everything. It is fewer seams.

That is the bet we are building toward at Cinevva. AI-assisted creation in the browser, tools that feed each other, and a path from work-in-progress to something players can actually run and discover. Not so executives can replace teams on a spreadsheet. So a small group or a solo dev can own the full line from idea to shipped game without pretending one prompt replaces a lead artist.

The 52% who use AI and the 52% who fear what it is doing to the industry are both responding to real signals. The developers who feel secure skipping AI today have a serious case about complexity. The open question is how long that case stays true if the toolchain stops breaking at every discipline boundary.

Related:

• GDC 2026 by the numbers — attendance, engine market share, and the AI divide
• Everyone wants to be the AI game engine now — the platform race behind adoption
• Open source has an AI pollution problem — the cost side of cheap AI generation
• AI controversy, trust, and the post-AI economy — Steam numbers, studio reactions, and trust
• AI-generated content policy — how Cinevva handles disclosure and filters
• Vibe coding is the new game jam — when experimentation gets cheap
• For game creators — publish playable games, subscription pool, playtime-based payouts

By Oleg Sidorkin, CTO of Cinevva

While the game industry spent March arguing about AI at GDC, the browser rendering stack shipped five years of progress in four weeks. Nobody held a press conference. Nobody posted a hot take. Five separate things happened that collectively changed what "browser game" means.

Babylon.js has been pushing browser rendering forward for years. Version 9.0 took the biggest leap yet.

What shipped in March 2026

Babylon.js 9.0 launched with clustered lighting, a rendering technique that handles hundreds of dynamic lights in a scene without killing performance. Until now, this was an AAA engine feature. The release also includes volumetric lighting with realistic light scattering, textured area lights for effects like stained glass and LED displays, and a node-based particle editor. All of it runs on both WebGPU and WebGL 2.

PlayCanvas v2.17 shipped GPU-driven Gaussian Splatting sorting on WebGPU. Gaussian splatting, the technique that turns photogrammetry captures into real-time 3D scenes, was a research paper two years ago. Now it's running in a browser engine with GPU acceleration for the sort pass.

Three.js r183 renamed its PostProcessing module to RenderPipeline. That sounds like a minor API change, but the naming matters. "Post processing" is something you tack onto a hobby project. "Render pipeline" is production infrastructure. The Three.js team is signaling that the library is ready for serious, structured rendering architectures.

Chrome 146 added WebGPU Compatibility Mode, which means older GPUs that don't support the full WebGPU feature set can now use WebGPU through a reduced-capability path. The install base for WebGPU just expanded dramatically.

The W3C published WebGPU as a Candidate Recommendation Draft. This is the formal step toward it becoming an official web standard. WebGPU is no longer experimental. It's on the standards track.

Why this month is different

Any one of these releases would be noteworthy. All five happening in the same month creates a compounding effect.

Five years ago, "browser game" meant a 2D casual game, maybe with some Canvas effects if you were ambitious. Three years ago, you could do basic 3D with careful optimization. A year ago, WebGPU started landing in production browsers and the ceiling began to rise.

But March 2026 is when the gap between native and browser rendering moved from "significant" to "narrowing fast." Clustered lighting was something you needed Unreal or Unity for. Gaussian splatting was something you needed a research lab for. Production-quality post-processing pipelines were something you needed a custom engine for. All three are now shipping in open-source browser engines that anyone can npm install.

Three.js Water Pro running on WebGPU. This is a browser.

What I think happens next

We've been betting on browser-first game delivery at Cinevva since the beginning. The thesis was always that the rendering gap would close because the web platform iterates faster than native engines. WebGPU took longer than I expected, but the convergence is now happening on schedule.

The practical effect is distribution. A game that runs in a browser doesn't need a download, an install, or a platform approval process. It loads from a URL. That's always been the browser's advantage, but it only matters when the rendering quality is good enough that developers actually choose it.

We're past that threshold now. Not for every game. Not for open-world AAA with ray tracing. But for an increasingly large class of games that include real-time 3D, dynamic lighting, particle systems, and photogrammetric assets, the browser is a viable target. And unlike native platforms, there's no 30% platform tax on the other end.

The question was never "will browsers catch up." It was "when." March 2026 answered it.

Related:

• Babylon.js 9.0: clustered lighting and gaussian splatting — the full technical breakdown
• Chrome 146 ships WebGPU Compatibility Mode — expanding the WebGPU install base
• Web game development enters the WebGPU era — how we got here
• Web Game Engines Comparison — Babylon.js, Three.js, PlayCanvas, and the rest
• WebGPU getting started for game developers — hands-on with the new API
• Browser 3D Open World Tech — the rendering architecture behind browser worlds

By Oleg Sidorkin, CTO of Cinevva

Three game engines showed up in March that are architecturally different from anything in the Unity/Unreal/Godot lineage. They don't have visual editors. They don't optimize for a human clicking through menus. They're built from the ground up for AI agents to read, write, and control game state.

This isn't "Unity with an AI tab." This is a different species of engine.

AI is already changing 3D game development workflows. The engine layer is next.

The three engines

nAIVE Engine is open-source, written in Rust with WebGPU rendering. Sub-second hot-reload: shaders in under 200ms, scenes under 100ms, scripts under 50ms. Scenes, pipelines, and materials are defined in YAML, which means LLMs can read and generate them without parsing binary formats. It exposes an MCP command interface that lets AI agents control engine functions through JSON-RPC. It ships with first-class Gaussian splatting and headless rendering for automated testing. The entire architecture assumes your primary user might be an AI agent, not a person with a mouse.

Arcane Engine is a code-first 2D engine. Rust core, TypeScript scripting. No visual editor at all. Its philosophy: "code is the scene." Game state is a queryable database rather than a scene tree. It includes a built-in protocol for AI agent interaction. Apache 2.0 licensed.

Mirror Engine is in alpha, and it's multiplayer-first with an entity component system. The interesting part: it includes AI text-to-3D generation that produces Gaussian splats from text prompts in about 60 seconds. TypeScript scripting, browser-based "Mirror Lite" client.

These three engines don't share a codebase or a team, but they share a design thesis: the primary interface to a game engine should be structured text, not a GUI.

Why this architecture matters

Traditional game engines evolved to serve a human sitting at a desk. You have a viewport. A hierarchy panel. An inspector. A timeline. Everything is designed around clicking, dragging, and visually placing objects. That workflow is powerful. It's also impossible for an AI agent to use.

When your primary "user" is an LLM, you need different primitives. YAML over binary scene formats. Queryable state over nested scene trees. Protocol-based commands over mouse clicks. Headless operation over window rendering.

This is the same shift that happened in infrastructure when DevOps moved from GUI control panels to infrastructure-as-code. The same thing is happening in game engines, just twenty years later.

nAIVE's MCP interface is the clearest example. MCP (Model Context Protocol) is becoming the standard way AI agents communicate with tools. When an engine speaks MCP natively, any AI agent that supports the protocol can manipulate scenes, adjust parameters, run tests, and iterate on gameplay without a human in the loop. That's not a feature bolted onto a traditional engine. That's a fundamentally different relationship between the engine and its user.

Gaussian splatting in game development. Both nAIVE and Mirror treat it as a first-class rendering primitive.

The bigger picture

These three engines aren't the only signal. Meshy's Black Box demonstrated AI-generated game mechanics at runtime. OpenAI showed a tactical RPG built with Phaser at GDC. The tooling layer between "AI generates something" and "that something runs as a playable game" is getting thinner every month.

At Cinevva, we've been building this bridge from the other direction. Our engine handles rendering, physics, and real-time interaction while AI handles asset generation. The approach is different from nAIVE or Arcane, but the underlying bet is the same: the future game engine needs to speak AI as a first language, not just add it as a plugin.

The traditional engine makers know this too. Unity previewed AI game creation tools at GDC. Roblox launched AI-powered 4D model creation. But there's a meaningful difference between adding AI features to an engine designed for humans and designing an engine where AI is the primary interface.

What I think happens next

Most of these engines won't survive. That's normal for a new category. But the design patterns will. YAML-based scene definitions, MCP protocols for agent control, queryable game state, headless operation. These ideas will get absorbed into mainstream engines within two years.

The engine that wins this era probably doesn't exist yet. But the architectural DNA is being written right now, in these three projects and a handful of others. The question isn't whether game engines will become AI-native. It's whether the transformation comes from inside the incumbents or from new entrants that designed for agents from day one.

Related:

• Everyone wants to be the AI game engine now — the platform race that set the stage
• Frontier Open-Source Gen AI Models — the models these engines are integrating
• Web Game Engines Comparison — where the new engines fit in the broader ecosystem
• Open source has an AI pollution problem — the cost side of AI-generated contributions

By Oleg Sidorkin, CTO of Cinevva

Two weeks ago, I wrote that vibe coding is the new game jam. The thesis was that AI tools had collapsed the barrier between idea and prototype. Since then, the evidence moved from "people are prototyping" to "people are selling."

This isn't a jam anymore. It's a production methodology.

Building full video games with AI agents. The multi-agent workflow is the pattern that scales.

What shipped in March

Void Balls was built by BigDevSoon in 10 days. Not 10 days of hacking together a demo. 10 days of building a game with 29,000 lines of C# across 173 scripts, 88 test files, five enemy types, 15 power-up cards, and boss fights. The workflow: 8 parallel Claude Code agents, each handling a different domain. Architecture, implementation, game balance, testing. All running simultaneously. Art came from Replicate, audio from ElevenLabs.

Grumbulus was built by two developers in two evenings. 15,000 lines of vanilla JavaScript with procedural audio and parallax rendering, all generated through Claude Code. No framework. No engine. Just AI writing plain JS.

CODEX MORTIS launched on Steam Early Access as the self-described "world's first 100% AI-developed game." A necromantic survival bullet hell built in three months with Claude Code for animations and shaders, ChatGPT for artwork. Pure TypeScript with PIXI.js and bitECS, wrapped in Electron. The demo pulled 10,500 players with a 71-minute average session length.

Catvivors hit Steam Early Access as a Vampire Survivors-style roguelite about cats. Solo developer, AI researcher, built the whole thing with Claude Code.

The pattern that matters

The individual games are interesting. The replicable pattern is more interesting.

The Void Balls workflow deserves attention because it isn't one person typing prompts. It's eight parallel AI agents, each with a specific role, operating on the same codebase simultaneously. That's not vibe coding. That's orchestrated AI labor. Architecture agent defines the structure. Implementation agents build features. Balance agent adjusts difficulty curves. Test agent writes and runs test suites. One human directing eight workers.

This is the workflow that scales. Not "tell Claude to make a game" but "manage a team of Claude agents the way you'd manage a team of developers." The parallel agent pattern is how you go from prototype to shippable product in days instead of months.

The full stack is now proven: code generation + art generation + audio generation + game engine = shippable product. Each layer has a capable tool. Claude Code for the codebase. Replicate or Midjourney for art. ElevenLabs for audio. Pick your engine. The integration between these tools is still rough, but it works.

Vibe coding a 3D FPS from scratch in one hour. No Unity, no Unreal, no engine.

The honest limits

I'm going to be direct about the ceiling because I think the hype is outrunning the reality.

The 71-minute average session for CODEX MORTIS is impressive for a demo. It doesn't tell you about day-7 retention or whether people will pay for the full game. The shipped games so far are mostly roguelikes, bullet hells, and auto-battlers. These are genres with procedural variation and mechanical depth that come from systems interacting, not from handcrafted content.

What hasn't shown up yet: complex narrative games, deep strategy games, anything where level design requires human intuition about pacing and emotional arc. The genres AI handles well are the ones that are most systematizable. That's not a coincidence.

"Shippable" and "worth buying" are different things. The quality bar for a free browser game and a $15 Steam game aren't in the same league. We haven't seen the retention data or the revenue data that would tell you whether AI-built games can sustain a business, not just a launch.

What I think happens next

More games like these will ship. The quality will improve as the AI models improve and the multi-agent workflows mature. The first genuine hit, a game built primarily with AI tools that sustains a player base and generates real revenue, will probably arrive before the end of 2026.

But the thing that changes the industry isn't any single game. It's the fact that the production methodology now exists. We built A Breaker Belt in three days with two people. BigDevSoon built Void Balls in 10 days with one person and eight agents. The timeline for going from idea to shippable game has compressed from years to weeks for a growing category of games.

The studios that should be paying attention aren't the AAA houses. They're the mid-tier publishers who charge $20 for games that a solo developer can now build in a month.

Related:

• Vibe coding is the new game jam — the signal this one builds on
• A Breaker Belt: Snake meets Arkanoid, vibe coded in three days — our own experience with the AI workflow
• Agentic AI code tools — Claude Code, Cursor, and multi-agent development
• Game Jams & Hackathons — the format that vibe coding is evolving from

By Oleg Sidorkin, CTO of Cinevva

NVIDIA launched DLSS 5 at GDC with a promise: generative AI that reconstructs lighting, materials, and shadows in real-time, making games look photorealistic without the performance hit. Then people saw what it actually did to character faces.

The internet called it "yassifying." Grace Ashcroft from Resident Evil Requiem went from a haggard, battle-worn survivor to a smoothed-out, homogenized face that looked like a different character. Leon got the same treatment. The AI decided the original art direction wasn't good enough and "fixed" it.

NVIDIA's DLSS 5 reveal with Resident Evil Requiem. The visual changes sparked immediate backlash.

What NVIDIA shipped and what it actually does

DLSS versions 1 through 4 were upscaling technologies. They rendered at a lower resolution and used AI to fill in the missing pixels. Artists appreciated them because they respected the source image. Your art direction stayed intact. The AI just made it sharper.

DLSS 5 is fundamentally different. It's a video-to-video generative AI system that operates without access to the original game assets, geometry, or scene data. It takes the rendered 2D frame and motion vectors, then generates a new frame with "improved" lighting, materials, and detail.

The key word is "improved." Improved according to whose judgment? The AI's. Not the artist's.

NVIDIA initially described it as having "3D scene understanding." They later clarified it works from 2D frame data only. That distinction matters. The system isn't enhancing what the artists built. It's interpreting a flat image and generating what it thinks should be there. When it encounters a face with deliberate imperfections, scars, grime, stress lines, asymmetry, it tends to smooth them away because its training data associates these with "lower quality."

This is the creative control problem

The 52% of developers who told GDC they think AI is harming the industry aren't all worried about losing their jobs. Many of them are worried about losing control over what their work looks like when it reaches the player.

DLSS 5 makes that fear concrete. There's now an AI sitting in the rendering pipeline between your finished art and the player's screen, and it's actively rewriting your creative decisions. The haggard face you spent weeks perfecting gets smoothed out. The moody lighting you carefully balanced gets "corrected" to be more photorealistic. The specific look you chose gets generalized into whatever the model thinks "good" looks like.

Digital Foundry published an initially positive preview, then released a follow-up titled "Why We Should Have Waited With Our Coverage." Even the tech press that tends to celebrate NVIDIA recognized that something was different about this release.

Larian Studios, makers of Baldur's Gate 3, reportedly dropped some of the generative rendering tools for their next project after fan backlash. When a studio that just won Game of the Year walks away from free rendering technology, the creative control argument isn't theoretical.

Digital Foundry's follow-up on the DLSS 5 debate: "We should have taken more time."

The pattern is the same

I wrote about AI pollution in open source earlier this month. The pattern is identical. Making something is cheap. Making something good still costs the same. Evaluating whether something is good still costs the same.

In open source, it's AI-generated pull requests that look plausible but introduce subtle bugs. In rendering, it's AI-generated frames that look "better" but aren't what the artist intended. Both cases involve AI overriding human judgment with statistically averaged output. Both cases cost someone else time and creative control.

The difference is that a maintainer can reject a bad PR. An artist can't reject DLSS 5 if NVIDIA and the publisher have agreed to enable it. The player's GPU is rewriting their work in real time, and they have no say.

What I think happens next

NVIDIA will ship DLSS 5 in fall 2026. Major publishers including Capcom, Bethesda, Ubisoft, and Warner Bros. have already signed on. The technology will improve and the "yassifying" will become less obvious. The backlash will quiet down because people get used to things.

But the underlying question won't go away: when you add generative AI to the rendering pipeline, who has final say over what the player sees? Right now, the answer is NVIDIA's training data. That should bother anyone who cares about games as an art form.

The distinction matters for how we think about AI tools across the industry. AI that serves the creator's intent is a tool. AI that overrides the creator's intent is something else entirely. DLSS 1 through 4 were tools. DLSS 5 is the first mainstream example of AI inserting its own aesthetic judgment into someone else's art, at the hardware level, without asking.

Related:

• Open source has an AI pollution problem — the same pattern in a different context
• GDC 2026 by the numbers — the survey data on developer opposition to AI
• AI controversy, trust, and the post-AI economy — the broader trust question
• Frontier Open-Source Gen AI Models — the models powering generative rendering

By Oleg Sidorkin, CTO of Cinevva

Andrej Karpathy coined the term "vibe coding" in February 2025 to describe building software by describing what you want and letting AI handle the implementation. A year later, Collins Dictionary made it their Word of the Year. Searches for the term jumped 6,700% that spring.

For most software, vibe coding means faster prototyping. For game development, it means something more specific. The barrier between "weird idea" and "playable prototype" collapsed.

A Breaker Belt: Snake meets Arkanoid, vibe coded in three days on the Cinevva Engine

What actually changed

Game jams exist because game development takes too long for most experiments. You get 48 hours, a theme, and whatever energy you can sustain on caffeine and adrenaline. The constraint forces creativity. You can't build anything ambitious, so you build something weird. Some of the best games in history started as jam projects.

Vibe coding does something similar but removes the artificial time pressure. When describing a mechanic, a mood, or a behavior gets you a working prototype in minutes instead of days, you can try ideas that nobody would greenlight. The economics of experimentation changed.

We built A Breaker Belt in three days. Two people, on and off, not crunching. Snake meets Arkanoid. 50 waves. 23 brick types. Reactive music. AI narration. Real-time synthesized sound effects. Shipped to web, mobile, and PC. That scope would normally take a team of eight or nine people several months. The weird mashup that would die in a brainstorm doc instead got built over a long weekend.

That's what vibe coding actually does for games. It doesn't make great games automatic. It makes experiments cheap.

The numbers behind the trend

The investment tells you how seriously the industry is taking this. Cursor raised $2.3 billion in Series D. Lovable raised $330 million at a $6.6 billion valuation. An estimated 25% of Y Combinator's Winter 2025 startups ran on codebases that are 95% AI-generated.

In game development specifically, Three.js is now the primary library for vibe-coded web games, with 2.7 million weekly npm downloads. Platforms like Cinevva, Phaser, and a growing list of AI tools are building development environments where describing intent is the primary input.

Karpathy himself has already moved on to the next concept. He's calling it "agentic engineering," where AI agents write code themselves rather than responding to human prompts. "There is an art and science and expertise to it," he wrote. The field is moving faster than the vocabulary.

What doesn't change

The limits are real and worth being honest about. As projects grow, context management becomes the bottleneck. AI model performance degrades when your project gets complex enough that the full context doesn't fit in a single window. The code you get is often good enough to run but not good enough to maintain. When something breaks, debugging AI-generated complexity that nobody fully understands is its own special challenge.

There's also the taste problem. AI can generate a mechanically functional game very quickly. It can't tell you whether the game is fun. Whether the difficulty curve feels right. Whether the music matches the mood. Whether the pacing keeps you engaged or slowly bores you. That layer of judgment, the thing that separates a prototype from a game worth playing, still requires a human who cares about the result.

Game jams work because the time pressure forces you to make hard choices about what matters. Vibe coding removes the time pressure but not the need for choices. The best vibe-coded games will come from people who know what they want, not from people who accept whatever comes back.

What I think happens next

More games that shouldn't exist will exist. Some of them will be terrible. Some of them will be brilliant. The ratio might not change, but the volume will. And in that volume, you'll find games that could never have been made before. Genres that don't have names yet. Mashups nobody would have funded. Personal projects that one person built because the tools finally got out of the way.

That's always been the promise of better tools. Not that everything gets better, but that more things get to exist. The game jam energy, the "let's just try this and see," is no longer confined to a 48-hour window. It's Tuesday afternoon and you have an idea. By Thursday, it's playable.

Cinevva's engine is free to use. Your weird game idea might be three days away from existing.

Related:

• A Breaker Belt: Snake meets Arkanoid, vibe coded in three days
• We didn't expect to build a radio station
• Agentic AI code tools — Claude Code, Cursor, and GitHub Copilot for game development
• Game Jams & Hackathons — the original 48-hour game creation format
• Web Game Engines Comparison — engines that pair well with AI-assisted workflows

By Oleg Sidorkin, CTO of Cinevva

Steam Next Fest isn't just an event. It's a dataset. Over 2,200 games showed up in February 2026 with demos, trailers, and hopes for wishlists. The results are in, and they confirm something indie developers feel but don't always say out loud.

Next Fest rewards games that already have an audience. If you're starting from zero, the festival alone won't change that.

Standout indie games from Steam Next Fest February 2026

The numbers

presskit.gg analyzed the data and the tiers are pretty stark:

The median game earned 460 wishlists. That's with a demo available, a store page live, and Steam actively promoting the event. Four hundred and sixty wishlists for a week of dedicated visibility on the largest PC gaming platform on Earth.

Momentum compounds. Obscurity compounds too.

The Diamond tier games almost all entered with 10,000+ existing wishlists. They had content creator coverage before the festival started. Their capsule art communicated instantly at thumbnail sizes. They'd done the marketing work before showing up.

The games entering with fewer than 1,000 wishlists? They mostly gained a few hundred more. The festival amplified what was already there. It didn't manufacture something from nothing.

This pattern isn't unique to Next Fest. It shows up everywhere in discovery. YouTube recommends videos that are already performing well. Spotify surfaces songs with existing listens. Store algorithms everywhere reward engagement with more engagement.

If you have momentum, Next Fest is a multiplier. If you don't, it's a participation certificate.

Genre matters more than you'd think

Co-op games overperformed across the board. Content creators want to play with friends on stream. That social dynamic generates clips, which generates views, which generates wishlists. The social play loop feeds the social media loop.

Survival and crafting games stayed strong despite how crowded the genre feels from the developer side. Players still want these games. The supply hasn't exceeded the demand.

Narrative games and visual novels struggled. The format of Next Fest works against them. Demo browsing rewards fast visual clarity. You need to understand what a game is within seconds of seeing its capsule art and maybe watching ten seconds of gameplay. Story-driven games need context that thumbnails can't provide.

Roguelikes could still break through, but only with strong differentiation. "It's a roguelike with a twist" needs the twist to be visible at a glance.

Why we're watching this closely

This data matters to us because Cinevva was built specifically for the problem it reveals. Our reels-first discovery shows real gameplay, not curated screenshots. You scroll through clips, see something that looks fun, and you're playing it instantly in your browser.

We're not trying to replace Steam or compete with Next Fest. The data tells us these platforms work great for games that already have visibility. The question we care about is: what happens to the other 2,000 games? The ones that are genuinely good but didn't enter with an existing audience?

Those games need a discovery path that doesn't depend on pre-existing momentum. Somewhere a player can stumble onto a game they'd never find in a store, because they saw five seconds of it and it looked interesting. That's the gap we're building into.

The Steam Next Fest strategy guide we published earlier this year covers the tactical side. This piece is about the structural takeaway. Discovery on the biggest platform in PC gaming is increasingly a rich-get-richer system. If that's the only system, a lot of great games will stay invisible.

Related:

• Steam Next Fest February 2026 data
• Steam Next Fest strategy guide — tactics for making Next Fest work for you
• Co-op Game Design — co-op games consistently overperform at festivals
• How to Launch Your Game on itch.io — an alternative discovery path for smaller games

By Oleg Sidorkin, CTO of Cinevva

Rémi Verschelde is one of the people who keeps Godot running. Not as a side project or a hobby. As a life's work. He's been maintaining the engine since before most people had heard of it, reviewing contributions, merging patches, making sure the thing millions of developers depend on actually works.

Last month, he described what's happening to Godot's contribution pipeline as "draining and demoralizing."

The cause: AI-generated pull requests. Lots of them.

Godot has 4,681 open pull requests on GitHub right now. A growing percentage of new submissions are generated by people who typed a prompt, got some code, and submitted it without understanding what it does. The code often looks plausible at first glance. It compiles. The variable names make sense. Then a maintainer spends twenty minutes figuring out that it introduces a subtle bug, breaks an edge case, or solves a problem that doesn't exist.

The time spent rejecting bad PRs is time not spent reviewing good ones.

The irony writes itself

AI tools are supposed to make developers more productive. That's the pitch. That's why companies are raising billions to build them. And at the individual level, they do. I use AI tools every day. Our entire platform uses AI for game creation, music generation, 3D models, and more. I'm not anti-AI.

But there's a system-level effect that nobody talks about in the investor decks. When AI makes it trivially easy to generate a contribution, and the cost of submitting drops to zero, but the cost of reviewing stays exactly where it was, you get a pollution problem.

The people submitting these PRs aren't malicious. Most of them genuinely want to contribute. They've been told that AI tools let them contribute to open source without deep expertise. And the tools do let them generate something that looks like a contribution. It just isn't one.

Verschelde acknowledged that using AI to detect AI-generated PRs would be "horribly ironic." He's right. Fighting AI output with AI detection is an arms race nobody wins.

What this really tells us

Making something is now cheap. Making something good still costs the same.

That's the lesson showing up everywhere, not just in open-source code review. It shows up in game development, in music production, in content creation. AI dropped the floor. The minimum viable contribution, the minimum viable game, the minimum viable blog post can now be generated in seconds. But the ceiling didn't move.

The people who were already good at their craft are now faster. The gap between "made a thing" and "made a thing worth someone's time" is actually wider than it used to be, because the volume of mediocre output has exploded while the number of people who can evaluate quality hasn't changed.

Godot's contribution guidelines require disclosure of AI assistance. People ignore them. You could make the rules stricter, but enforcement requires the same human review time you're trying to save.

The real solution is boring

Verschelde's primary ask is funding. Hire more maintainers. More humans reviewing the work. That's not a technical solution. It's an organizational one. And it's probably the only one that works.

Open-source projects are getting the same lesson the rest of us are learning: AI doesn't eliminate the need for human judgment. It increases it. The more AI-generated content flows into any system, the more you need people who can tell the difference between something that looks right and something that is right.

We think about this constantly when building Cinevva's tools. The goal was never to remove human judgment from game creation. It's to let creative people focus their judgment on what matters: does this feel right, does this work, would someone enjoy this? The grunt work gets handled. The taste doesn't get automated.

Godot will figure this out. The engine is too important and the community too strong for it not to. But the pattern they're dealing with isn't going away. Every open-source project, every creative platform, every system that accepts contributions from the public is going to face this same question: how do you handle a world where producing something is nearly free but evaluating it isn't?

Related:

• Agentic AI code tools — responsible use of AI coding tools
• Frontier Open-Source Gen AI Models — the open-source models driving this shift
• AI controversy, trust, and the post-AI economy — the broader trust question around AI in creative work
• Web Game Engines Comparison — Godot and other engines affected by this trend

By Oleg Sidorkin, CTO of Cinevva

In February 2026, the following things happened within about three weeks of each other.

Unity's CEO went on record saying they'll demo prompt-to-game at GDC. Roblox shipped a 4D creation tool that generates interactive objects from text. Moonlake AI opened a beta for their Generative Game Engine backed by $30 million from Nvidia, Jeff Dean, and YouTube's co-founder. Phaser Editor v5 launched with AI built directly into the scene editor through MCP. And at least half a dozen startups I'd never heard of popped up on Product Hunt with some variation of "describe a game, we'll build it."

Roblox's VP of AI on their Cube foundation model and 4D creation

This isn't a complaint. It's an observation about timing.

Two years ago, when we were pitching what Cinevva does, VCs from Sequoia, Pear, Draper, and dozens of other firms told us the market wasn't there. B2C game creation? Indies don't pay for tools. You can't simplify game development without gutting capability. The standard deck of objections dressed up as market analysis.

Now the biggest names in gaming are spending hundreds of millions racing to build variations of the same thing they said couldn't work.

These tools are not the same thing

Here's what matters and what most coverage misses. "AI game creation" is an umbrella that hides fundamentally different products.

Text-to-demo tools generate something that looks impressive in a tweet. You type a prompt, get a playable thing, share the GIF. The output is real, but it's a demo. Getting from that demo to a game someone would play for an hour is a different problem entirely. Moonlake and some of the newer startups live here. They're solving the initial spark.

AI copilot tools sit inside an existing engine and help you work faster. Phaser Editor v5 with MCP does this. Ziva does this for Godot. They don't replace the development process, they accelerate it. You still need to understand what you're building. The AI handles the grunt work.

Platform-native AI creation is what Roblox is doing with 4D. The AI is embedded in the runtime. Objects don't just look right, they behave right because the generation model understands the platform's physics and interaction systems. The tradeoff: you're locked to that platform.

Full-stack AI game engines are trying to handle everything from concept to shipping. That's what Unity is promising for GDC. That's what we've been building at Cinevva for years. Describe what you want, iterate on what comes back, ship to web, mobile, desktop, Steam. The game you prompt is the game you publish.

Phaser Editor v5 integrates AI through MCP for scene-level assistance

The gap between demo and ship

Every tool in this space can generate a thing that runs. That part got easy fast. The hard part is everything after. Does the game feel good on a phone? Does it handle edge cases? Can you iterate on the music, the difficulty curve, the pacing? Can you ship it to five platforms from the same project? Does the AI understand what makes a game actually fun versus what makes a screenshot look cool?

Some of these announcements will turn into real products. Some will get a round of funding, generate nice demos, and quietly disappear when the "ship a real game" part proves harder than the "generate a prototype" part.

What I think is actually happening

The market validation we couldn't get in a Sand Hill Road meeting is now coming from the industry itself. When Unity and Roblox bet their roadmaps on AI creation, they're confirming what we've been building toward: the tools should adapt to how creative people think.

The race isn't about who announces first. It's about who ships something people actually use to make games they're proud of. We have thousands of people doing that on Cinevva today. A Breaker Belt was two people and three days. Cinevva Radio has 362 community-created tracks. That's the difference between promising to build the future and already living in it.

The competition is good. It means the market exists. We've known that for a while.

Related:

• Web Game Engines Comparison — how traditional engines compare on web output
• Frontier Open-Source Gen AI Models — the AI models powering game generation
• Agentic AI code tools — the AI copilot layer that accelerates development
• A Breaker Belt — a game built in three days with AI tools