traceyang

AI Native Game Dev in Practice — TPS Camera Overhaul

May 14, 2026 by trace yang

I. Why This Article

In our previous article, we discussed the methodology of AI Native game development, with the core thesis being “experience validation first” — games can be fully played and validated before production assets are finished.

Methodology sounds great on paper, but what does it actually look like in a real project?

This article answers that with a real case: we had an FPS engine and wanted to transform it into a TPS. Not building a TPS from scratch, but making an existing FPS system “feel like a TPS.”

This isn’t a TPS camera technical article. It’s a record of how AI participated in a real development process — from understanding an unfamiliar system to producing a complete refactoring plan.

II. Starting Point: An FPS Engine Wants to Become TPS

The engine we faced had been in operation for some time — built on UE, substantial codebase, multiple teams had worked on it over the years. It did have a TPP mode — there was a CameraMode component supporting FPP/TPP switching, and the camera did move behind the character when you switched.

But the moment you switched to TPP, you could immediately feel “this isn’t TPS.” Camera distance fixed at 216cm, shoulder offset only 24cm, no follow lag whatsoever — felt like a camera rigidly welded to the character’s back. Aiming switched straight back to FPP, so you couldn’t properly ADS in TPS view. Shooting had almost no camera feedback — recoil and fire shake systems existed but only worked in FPP. Hugging walls caused the camera to clip straight through. Overall it felt more like “watching an FPS from behind” rather than a genuine third-person shooter experience.

The traditional approach is familiar to everyone: designers write a camera requirements doc based on experience, list a bunch of “features to add,” engineering schedules the work, builds it, discovers it’s wrong during integration, revises, re-integrates, revises again. Months later, still tuning basic feel. And because nobody has a full picture of the existing system, there’s a good chance of reinventing wheels — some feature already exists but nobody knows.

That’s how we initially planned to approach it too.

Then we changed our thinking: instead of guessing “what needs to be built” based on experience, let AI read through the entire camera system first and figure out “what already exists.”

III. AI Isn’t “Generating Features” — It’s “Understanding the System”

This was the most surprising part of the entire process.

After AI read through the complete camera system source code, we discovered an unexpected truth: this engine’s camera framework was actually very capable.

The SpringArm component supported 15+ movement states — standing, crouching, prone, vaulting, parachuting, swimming, being carried, NPC dialogue… each with independent camera distance, offset, and height configurations, driven through a TMap called BasicLayerConfig configured in Blueprints — completely data-driven. The CameraModifier system lined up impressively: weapon recoil modifier, gun sway modifier, hit camera modifier, fire shake modifier, prone impact modifier, vehicle camera modifier… over a dozen modifiers each handling their own responsibility. The scope system had a complete CSV config table with 50+ scopes, each with its own zoom ratio, FOV, and depth-of-field parameters. FPP/TPP switching had a complete priority mechanism supporting multiple systems requesting camera mode changes simultaneously with priority arbitration.

Framework capabilities far exceeded our expectations.

But AI also uncovered another side. Having AI dig through a years-old production codebase is a lot like archaeology — you keep excavating things, some still in use, some buried, some half-finished and abandoned.

Sprint camera layer — complete acceleration/stabilization/deceleration camera change logic, roughly 60 lines of code, but entirely wrapped in #if 0. This wasn’t “never built.” It was built, then abandoned.

Recoil system — highly refined, supporting per-stance recoil patterns with spring-damper recovery. But detecting non-FPP mode triggers an immediate return. Whether an engine “feels like TPS” sometimes comes down to a single line of code.

ADS aiming — triggers forced FPP switch with no configuration toggle. TPS experience breaks apart not because systems are missing, but because systems aren’t truly cooperating.

The code also contained large blocks annotated “deprecated logic” — left/right shoulder shooting camera layers, jetpack camera layers, all with configuration property declarations but commented out. A previous team had planned a complete TPS shoulder-shooting camera system, but it was shelved at some point. These ruins mixed in with active code — a production engine that’s been running for years often doesn’t look like “one system.” It looks more like ruins from multiple eras stacked on top of each other. Without AI flagging them, it’s very hard to distinguish what’s alive from what’s dead.

AI traced the call chains further down and dug up some even more unexpected things.

FPP/TPP transition timing was asymmetric — switching into FPP took 0.1 seconds (instant snap), switching back to TPP took 0.6 seconds (smooth transition), with independent easing curves for each direction. These weren’t arbitrary numbers: fast zoom-out looks jarring, so entering FPP needs to be fast while returning to TPP needs to be slow. An experience design decision embedded in code, with no documentation recording why. When AI found these numbers, we realized previous developers had put very careful thought into this.

The camera mode system had 7 priority levels. Interestingly, player manual FPP/TPP switching ranked 5th — above vehicles. Code comments explicitly stated: “Player manual switch has very high priority. If gameplay logic needs to override it, it must first call the cleanup interface.” A UX philosophy embedded in code: player choice trumps most system behaviors.

The most unexpected discovery: AI traced the retarget logic and found that even when the player was in TPP mode, if the weapon was zoomed in, animations would silently switch to FPP mode. When aiming down sights in TPP, the character’s arm animations were actually using FPP ones. Without reading the complete chain, you’d never find this.

An engine that doesn’t “feel like TPS” isn’t because it lacks TPS capabilities — it’s because those capabilities are scattered everywhere, some disabled, some FPP-only, some with logic written but no parameters configured, some half-built and shelved, some hidden in conditional branches you’d never notice.

We initially thought “we need to build many new features.” We later discovered “most features already exist — they just weren’t being used properly.”

This discovery changed the entire project trajectory. Under traditional thinking, we would have planned a “develop new TPS camera system” project taking months. What actually needed to happen was “enable existing features + tune parameters + fix a few hardcoded blocks” — an order of magnitude less work.

Even more interesting, AI mapped out a complete configuration hierarchy: the base layer is BasicLayerConfig controlling per-stance camera parameters, the middle layer is IndoorLayerConfig automatically applying additive offsets indoors (doing an upward ray trace every 0.5 seconds to detect ceilings), and the top layer is the scope table controlling ADS FOV and depth of field. Many “camera feels wrong” problems might not need code changes at all — just table tuning. But before AI’s analysis, nobody knew the full picture of this three-layer configuration system, let alone the data flow between them.

This made us rethink a question: in traditional projects, the time teams spend “developing new features” may not be as much as imagined. A huge amount of time is actually spent “figuring out what state the existing system is actually in.” In a medium-to-large codebase, who wrote some feature, who disabled it, why it was disabled, whether it can still be used, which table the parameters are in — these questions can take days to weeks through manual code review. AI compressed this process to a few hours.

And AI’s “understanding” isn’t simple code search. It can string together logic scattered across a dozen files into a complete chain: player presses aim → FSM Action triggers → CameraMode component arbitrates by priority → SpringArm state switches → BasicLayerConfig looks up corresponding parameters → interpolates to target position → CameraModifiers stack recoil/sway/hit effects one by one → final camera transform output. This chain spans Gameplay Framework, Camera, Weapon, and Animation — four modules. No human can trace this end-to-end in their head at once. AI can.

IV. From Feature List to Design Principles — Every Principle Comes From a Real Pitfall

After understanding the system’s current state, the first draft naturally became a Feature List: ADS should stay TPP, add Sprint camera, enable peek, complete TPP shooting feedback, optimize collision…

A long list.

Then we hit a problem: with so many features listed, we didn’t know what to prioritize, what to restrain versus amplify, or whose rules win when two features conflict.

What the Feature List lacked wasn’t “what to do” but “why to do it” and “what not to do.”

So we started building design principles. Not by sitting down to write a complete Camera Philosophy from scratch — nobody reads those. Instead, every time we hit a pitfall, we distilled the lesson into a principle. Five principles, each from a real problem.

Camera Philosophy: Readability > Feel > Cinematic > Flashy

We initially tried adding dynamic camera movements for a “premium feel.” Heavy follow inertia, aggressive Sprint FOV push, strong hit screen offset. It definitely looked more “dynamic.”

Then we discovered players couldn’t hit anything.

Comfort & Stability: No Fatigue Over Long Sessions, ADS Must Be Stable

We tried stronger Camera Lag and Sprint Shake. The first problem wasn’t “not exciting enough” — players started getting dizzy.

Short-term reaction: “Wow, this camera has such a cinematic feel.” After 30 minutes: “I need a break.” TPS is a genre for long play sessions. Camera comfort matters far more than short-term excitement.

Transition & Rhythm: State Transitions Need Tempo

Every camera feature worked fine in isolation. But running simultaneously, Sprint pull-back hadn’t recovered before ADS kicked in, ADS was still transitioning when recoil fired, recoil hadn’t settled when an explosion hit.

The problem wasn’t that any single feature was wrong — the camera had lost its rhythm.

Consistency: Same Action, Same Feedback, Every Time

ADS shooting feedback didn’t match hip-fire feedback. Sprint pull-back distance varied. ADS transition speed was inconsistent.

Result: players could never build stable muscle memory.

Safety Rules: Camera Must Never Break

Narrow spaces causing camera to shake wildly. ADS getting forcibly pulled open by explosion effects. Wall-hugging causing camera to clip through the character. These aren’t “bad experience” problems — they’re “experience completely collapses” problems.

V. Separating Function from Feel — AI Exhausts Possibilities, Humans Decide What’s Right

Halfway through the plan, we discovered a more fundamental issue: much of camera experience quality depends not on “whether a feature exists” but on “whether parameters are right.”

The same Sprint Camera feature — pushing FOV 2 degrees more or less, pulling the camera back 30cm versus 50cm — feels completely different. Getting the feature right is just the starting point; getting the parameters right is the finish line.

But feature development and parameter tuning require completely different skills. Feature development needs code architecture understanding, logic changes, edge case handling; parameter tuning needs repeatedly playing the game, judging by feel, making tradeoffs. AI does the former quickly and reliably; only humans can do the latter.

So we split the workflow into two tracks:

AI handles making features work — analyzing code, enabling disabled features, filling missing logic paths, generating parameter table templates with suggested defaults.

Designers handle making the experience feel right — taking AI-generated parameter tables, repeatedly playing and testing, adjusting item by item until the feel is correct.

More precisely: AI is better at “exhausting possibilities,” humans are better at “deciding what’s right.” AI can tell you “this engine has 15 camera states, 8 types of Camera Modifiers, 50+ scope configurations,” but only a human can judge “how far the camera should be from the character when standing to feel most comfortable.”

This isn’t AI’s limitation — it’s the right division of labor.

For a concrete example: after analyzing the shooting feedback system, AI told us “among the dozen-plus CameraModifiers, recoil, fire shake, and FPP bone animation only work in FPP; gun sway and joggle camera work in both FPP and TPP; hit camera works in TPP but is weak due to bone animation dependency.” Based on this analysis, AI generated a TPP recoil parameter table template categorized by weapon type. But “does scaling rifle recoil to 0.5 of FPP feel right” and “will SMG’s high-frequency shake annoy players” — these judgments only come from someone playing a few rounds with a controller.

AI continuously outputs “what the system can do” and “how parameters can be tuned”; designers continuously answer “does this feel right” in-game. Two tracks running in parallel, much faster than traditional sequential feedback loops.

VI. Development Plan: First “Does It Look Like TPS,” Then “Can You Aim,” Finally “Does Shooting Feel Good”

With plan and principles in hand, the next question was: what to do first?

The biggest problem with TPS cameras usually isn’t “missing features” but “foundation rhythm isn’t established.” If the basic viewing angle is wrong, adding more advanced features is building on a crooked foundation.

We broke P0 into 7 steps in strict sequence:

Step one was basic TPP view and shoulder position. This step only answers one question: “Does it look like a TPS?” If shoulder offset is wrong or camera distance feels awkward, everything downstream will be off.

Step two was ADS. Establishing stable aiming experience. This was the highest-risk step — affecting input, FOV, recoil, aim stability — everything interconnected. Placed at step two to surface problems early.

Step three was collision handling. Steps four through seven: shooting feedback, Sprint camera, shoulder switch, hit feedback.

Each step validated immediately before proceeding to the next.

Why does this order matter? Because TPS camera dependencies are directional. Wrong base view means ADS pull-in targets the wrong position; unstable ADS means shooting feedback can’t be tuned; unresolved collision means all indoor features break. Each subsequent step depends on previous steps being correct.

We also risk-rated each step. ADS overhaul was high risk — it touches input, FOV, recoil, aim stability; changing one thing might affect five others. Sprint Camera and peek were low risk — existing logic just needs uncommenting.

One core principle throughout: unless it affects core experience, prioritize reusing existing capabilities over large-scale refactoring.

After P0 completion, lock the foundation. P1 (advanced feel) and P2 (advanced combat presentation) must not break P0’s established baseline.

VII. AI’s Real Value — Compressing the Cost of “Understanding Current State”

Looking back at the entire process, AI didn’t automatically produce a TPS camera.

What AI did was compress “understanding current state → identifying problems → producing plans → breaking down tasks” from weeks to days.

In this project, AI began to resemble a senior engineer on the team for the first time — not because it writes code, but because it can rapidly understand the entire system.

AI read the complete camera system source code in hours, telling us: what exists here, what’s missing there, what got disabled by whom, what the config tables look like, how the data flows. Then based on these facts (not guesses), produced plans and schedules.

Traditional flow is “guess first, verify later” — guess what needs building based on experience, verify after development whether the guess was right. AI Native flow is “look first, build later” — let AI read through the system first, produce plans based on facts, then develop with targeted precision.

This connects back to the previous article’s core thesis, but at a different dimension. The previous article’s “experience validation first” mainly meant validating gameplay direction with placeholder assets. This practice made us realize: validation first isn’t just validating gameplay — it includes validating “what the existing system can actually do.” Understanding what cards you hold before making moves is itself a form of validation first.

There was an unexpected bonus. AI produced not just a plan, but a “system map” the entire team could understand. Previously only the original code authors knew what the camera system looked like. Now AI organized the complete architecture, data flows, config tables, active features, and disabled features into documentation. New engineers and designers joining could get up to speed by reading this document instead of spending two weeks reviewing code themselves.

This may be an undervalued contribution of AI in large-scale engineering: not just helping you do things, but helping you turn tacit knowledge into explicit knowledge. In many codebases, the greatest asset isn’t the code itself but the contextual information of “why it was written this way” and “what it can do.” This information previously existed only in a few people’s heads. AI makes it documentation everyone can reference.

VIII. This Is Just the Beginning

Camera is only the first step of TPS transformation.

We’ll continue dismantling movement systems, TPS aiming, animation layering, and weapon mounting module by module. Not just presenting “final solutions,” but genuinely recording how AI participates in the continuous refactoring of a large game engine.

Many problems are honestly still far from solved. AI can help teams understand systems faster, validate directions faster, and prototype faster. But “what makes a good experience” still requires humans to repeatedly test and stumble. Camera feel, shooting rhythm, movement weight — no AI can judge these for you. Only someone holding a controller and playing for dozens of hours can gradually approach the answers.

To date, AI’s greatest value remains not “automatically generating games,” but enabling teams to understand systems faster, validate directions faster, and discover what isn’t fun faster.

AI exhausts possibilities; humans decide what’s right. AI understands systems; humans understand experience.

This is an ongoing AI Native development record, not an isolated case study. If you also have an engine that “clearly has capabilities but doesn’t feel right when running,” try letting AI read through it first. You might discover, as we did: the answers may already be in the code — it’s just that nobody had ever looked at the complete picture.

AI Native Game Development — From Pipeline Restructuring to Dynamic Experience

May 12, 2026 by trace yang

What AI Native games truly change isn’t AI-generated assets. It’s that the game industry is shifting for the first time from “competing on asset production capacity” to “competing on experience validation speed.”

I. Industry Thesis: What’s Actually Expensive in Game Development

For the past twenty years, the core bottleneck of the game industry has been content production.

Traditional AAA development relies on massive art teams, long asset production cycles, and heavy-asset iteration pipelines. A AAA project routinely involves hundreds of artists, two to three years of asset creation, and budgets measured in hundreds of millions. On the surface, these costs go toward “making content.” But if you break it down carefully, what’s truly expensive isn’t “writing code” or “building models” — what’s truly expensive is “validating a gameplay direction.”

A level designer has an idea but needs to wait for environment art to be built before validating player flow. A combat designer wants to adjust shooting feel but needs weapon models and VFX in place before sensing feedback. A systems designer wants to test new spawn pacing but needs enemy models and animations ready before running a playtest. Every validation is blocked by art asset progress. The later you discover a wrong direction, the more art capacity you’ve wasted.

We’ve all seen the classic disasters: weapon VFX carefully crafted over three weeks, only to discover TTK is fundamentally wrong once implemented. Boss animations produced over two months, only to find the mechanic isn’t fun when you actually play it. Scene art built over three months, only to discover the map scale is off and combat spaces are too open during playtesting.

What’s truly expensive was never “making assets” — it’s “making the wrong assets.”

Every team has experienced it: a group of people spend months building resources, only to finally realize “this thing just isn’t fun.” That silence in the meeting room — everyone who’s shipped a game understands it.

This is the biggest structural waste in traditional game development: design validation and asset production are tightly coupled.

The real change AI brings is not “automatically generating games” — we’re far from that today. The real change is:

For the first time, game teams can complete gameplay validation before production assets are finished.

This means three things:

Design validation moves earlier — full experience loops can be run on placeholder assets to confirm design direction
Art shifts from “production-driven” to “experience-convergent” — instead of designers validating whatever art finishes first, art converges toward whatever design has already validated
Engineering returns to the center of development pacing — AI dramatically accelerates engineering output, moving “time to a validatable build” from months to days

This is the fundamental difference between AI Native games and traditional game development. It’s not “who AI replaced” — it’s that the rhythm control of the entire development pipeline has changed.

Many teams in the industry are still discussing “when will AI replace artists.” But the question itself is wrong. If a team is still waiting for “AI to generate production-grade 3A assets,” it has likely already missed the real window for AI Native game development. The window isn’t in asset generation — it’s in pipeline restructuring.

II. Why Extraction Shooters, Why Now

Over the past two years, AI discussions in the game industry have clustered around two extremes: “AI-generated 3D assets will soon disrupt art production capacity” on one side, and “AI can only chat and offers no real help for game development” on the other. Both are wrong — the former overestimates 3D generation maturity, the latter underestimates AI’s already-scalable capabilities in engineering and design.

The actually valuable question isn’t “when will AI replace artists” but: Given that 3D generation isn’t mature today, if we adopt a different asset strategy, how far can AI actually push the development of a game?

We chose ARC Raiders-style PvEvP cooperative extraction shooters as our analysis target, not because this genre is the hottest, but because it’s naturally suited for AI intervention on two levels.

On a technical level, this genre’s structural characteristics maximize AI’s intervention space:

Single-match format means no cross-session memory or long-term narrative consistency needed — neatly avoiding LLM’s weakest area
PvE core means no PvP fairness constraints — AI can freely orchestrate content without breaking competitive balance
Search-fight-extract three-act structure is inherently modular — each phase’s design/engineering/art work can be independently evaluated
Small squad size means minimal data volume — even with runtime AI scheduling, compute costs remain manageable

On an experience structure level, the core fun of extraction shooters inherently comes from uncertainty — dynamic encounters, risk variation, resource pressure, on-the-spot decision making. Players don’t expect the same fixed flow every match; they expect to never know what they’ll encounter each time they drop in. This is precisely what AI Directors excel at: dynamically recomposing experiences. From Left 4 Dead’s AI Director to Roguelike procedural generation, this kind of “every match is different” game structure is naturally suited for AI. Extraction shooters are simply the genre that best matches current technology maturity on this axis.

This isn’t a speculative article about “what AI games will look like in the future.” This is about an engineering approach that can be deployed today, and an honest assessment of what doesn’t work yet.

We decompose game development into 8 pipelines across two layers:

Core Gameplay Layer: Combat, Enemies, Missions/Levels, Characters/Loadout
Scene & Presentation Layer: Environment, Game Feel, Audio, UI

The art side doesn’t pursue AI-generated production-grade 3D assets, but instead follows an “AI placeholder validation + marketplace/project asset reuse + AI batch refinement” approach — not a compromise, but a deliberate choice based on the industry thesis above: decoupling experience validation from asset production.

III. Core Gameplay Layer: Engineering and Design Are Already Fully AI-Ready

1. Combat Pipeline — Parameter-Driven Work, AI’s Natural Fit

The combat pipeline is one of the best demonstrations of AI’s deployment value, but not because “AI can write perfect combat code.” It’s because combat system work is fundamentally parameter-driven.

Weapon DPS, TTK, skill cooldowns, buff stacking rules — these aren’t creative work, they’re math. Traditionally, designers spend enormous time manually filling Excel sheets, iteratively fine-tuning values, running simulations to verify balance. This is exactly what AI excels at: given constraints, exhaustively explore parameter space, output proposals that match design intent. An experienced designer working with AI can complete in one day what previously took a week of numerical iteration.

Engineering is even more direct. Weapon state machines, damage calculation modules, skill frameworks, buff systems — these are highly pattern-determined engineering tasks. AI code generation quality in these scenarios is already quite stable — not “usable” level, but “goes straight into production” level. Batch config table generation and validation is AI’s particular strength, essentially eliminating manual data entry error risk.

The combat pipeline’s bottleneck was never art resources — a gun model doesn’t affect shooting feel tuning. The bottleneck is numerical iteration speed. AI opens exactly this bottleneck. A placeholder proxy mounted with AI-generated parameter tables and code lets designers tune TTK today.

2. Enemy Pipeline — Structured Design + Behavior Systems, AI’s Strength

The enemy pipeline has an underappreciated characteristic: its design work is highly structured.

An extraction shooter’s enemy taxonomy is fundamentally a classification problem — build a matrix by body type (light/medium/heavy), behavior pattern (patrol/ambush/chase/AOE), difficulty tier (normal/elite/boss), then fill in attribute parameters and counter-relationships. This “define framework first, fill parameters second” workflow is where AI is both fast and stable. Budget bucket parameters, patrol route plans, wave config tables, difficulty curves — where designers previously needed repeated playtesting to tune, AI can batch-generate first versions based on design intent, with designers doing precision adjustments on top. Efficiency gains aren’t percentage-point improvements — they’re order-of-magnitude.

Engineering-side, behavior tree/state machine code, perception systems, SpawnManager — equally pattern-determined work with stable AI generation quality.

What does validating spawn pacing actually require? A working SpawnManager plus a few capsule proxies, not meticulously crafted monster models. Getting “a testable enemy system” goes from weeks to days. What AI eliminates isn’t workload — it’s waiting.

3. Mission/Level Pipeline — The Modular Advantage

Extraction shooter mission design has a natural advantage: the three-act structure is inherently modular.

Search phase POI configuration, combat phase encounter design, extraction phase pressure curves — each phase can independently define parameters and rules. AI can generate mission type libraries (destroy, escort, collect, defend, recon) and POI function assignments based on map topology. The designer’s core value here isn’t “coming up with these mission types” (AI can cover that), but “judging which combinations feel good experientially” — this is a game-feel judgment call that AI cannot yet replace.

Engineering-side, mission state machines, trigger systems, event dispatchers are all standard AI deployment scenarios. Dynamic event system frameworks are mature generation targets.

This pipeline has high engineering volume and clear patterns — AI’s ROI is very high. Traditionally, validating a level’s extraction pacing required waiting for scene art to be completed — months. With AI whitebox + mission system code, the cost of discovering a wrong direction drops from three months to two days.

4. Character/Loadout Pipeline — Config-Table-Intensive, AI’s Efficiency Dominance

Equipment system design and economy model simulation are typical design-side AI scenarios. But where AI delivers the most value on this pipeline is actually config table generation.

A mid-scale extraction shooter might have dozens of weapons, multiple armor sets, and numerous stratagems. Each requires complete DataTable configuration: base attributes, quality bonuses, upgrade curves, compatibility rules. Traditionally this is pure manual labor — time-consuming and extremely error-prone. AI batch generation + auto-validation speeds this up 5-10x while virtually eliminating data consistency issues.

The underestimated cost in game development isn’t “thinking of a good design” — it’s “turning a design into hundreds of error-free config rows.” What AI changes first isn’t asset production — it’s config production.

Worth adding: AI is particularly well-suited for parameter space exploration, numerical balancing, build combination analysis, wave design, encounter matrices, drop configuration, config validation — and these happen to be exactly what mid-level designers spend most of their time on daily. AI won’t replace “people who can design,” but it will rapidly eliminate “people who can only fill spreadsheets.” The core value of design is shifting from “executing configuration” back to “making experience judgments.”

IV. Scene & Presentation Layer: Engineering Still Strong, But Feel Tuning Needs Humans

5. Environment Pipeline — AI Does Infrastructure, Humans Do Spatial Feel

The environment pipeline best illustrates AI’s capability boundary.

What AI can do is concrete: map functional zoning, POI density suggestions, procedural vegetation/prop placement rules, terrain generation and navmesh code. These are all rule-driven, data-driven work with clear inputs and outputs.

What AI can’t do is equally clear: spatial feel. A good extraction shooter map derives its tension from sightline management, from the spatial narrative of “turning a corner into an enemy,” from the tactical depth created by elevation differences and cover distribution. This requires level designers’ intuition and extensive playtesting — AI cannot currently replace this.

The most pragmatic approach: AI handles “infrastructure” (terrain generation, streaming, interaction code), humans handle “experience” (spatial layout, atmosphere, tactical path design). Collaboration, not replacement.

But even in the environment pipeline, the validation checkpoint still moves earlier. AI-generated whitebox terrain, though rough, is sufficient for level designers to validate spatial scale, sightline relationships, and tactical paths. Confirm “is it fun” first, then invest resources to make it “look good.” What this sequence saves isn’t just time — it eliminates the classic disaster of “spending three months building a scene only to discover the scale is wrong.”

6-8. Game Feel / Audio / UI

Game Feel: Engineering-side (screen shake, hit stop, camera shake, destruction system code) AI can generate directly, but final hit feedback tuning is subjective judgment work requiring human iteration. VFX assets follow marketplace reuse + AI parameter fine-tuning.

Audio: AI-generated temporary SFX and music serve the prototype phase — far better than “no audio,” because you simply cannot evaluate hit feedback without sound. Final quality audio still requires professional production.

UI: The pipeline with highest art-side AI maturity. 2D UI element AI generation quality is already production-ready, combined with marketplace UI Kits for essentially full AI coverage. This isn’t future speculation — it’s happening today.

V. Development Rhythm Shift: Who Defines the Production Timeline

For the past decade, game development’s rhythm control has effectively been held by the art production pipeline.

Because gameplay validation depends on assets, scene validation depends on environments, combat validation depends on VFX, flow validation depends on level art. Engineering determines “can the system run,” but what truly determines “when can we validate the experience” is asset production speed. Designers wait for artists, artists wait for outsourcing, outsourcing waits for feedback — the entire chain’s rhythm is dictated by its slowest link.

AI changes this. When AI can batch-generate code, auto-generate configs, rapidly build whiteboxes, and generate playable placeholder assets — game development returns to “engineering + design driven” for the first time.

This change matters far more than “X% efficiency improvement.” It means:

Iteration cycles compress — from monthly (wait for assets → test → feedback → revise) to daily (AI generates → test → feedback → regenerate)
Experimentation costs plummet — want to try three different level layouts? Previously that meant triple the scene production time. Now it means three AI whiteboxes, all validated within a week
Small teams gain large-team iteration velocity — not because fewer people is better, but because AI eliminates “waiting,” the biggest time black hole

This also changes role relationships within teams. In traditional pipelines, designers submit documents then enter a long wait — waiting for art assets, waiting for engineering to build systems, waiting for integration to become playable. Now, the same day a designer submits a document, AI can generate a playable version. Designers shift from “submit requirements then wait” to “submit requirements then immediately validate.” Art’s role changes too: no longer “build first so designers can validate,” but “designers validate first, then tell art which direction to build.”

Key judgment: The most competitive teams in the AI Native era won’t necessarily be those with the most art assets, but those who can fastest validate “what’s fun.” Engineering + AI-driven iteration speed is becoming the new core competitive advantage.

VI. Pipeline-by-Pipeline Validation: Running the Game Before Assets Arrive

Chapter V covered the macro rhythm shift. This chapter covers the specifics: how designers and artists complete validation during the placeholder phase, pipeline by pipeline.

Combat: After AI generates values + code, mount placeholder weapons and temporary VFX, and designers can immediately validate shooting feel and TTK in-game. No need to wait for weapon models. Artists observe VFX timing and rhythm on this validated build, confirming direction before marketplace selection — rather than buying assets first and discovering they don’t fit.

Enemies: Capsule proxies color-coded by unit class are sufficient for designers to test spawn pacing and difficulty curves. Artists confirm “how much body size differentiation is needed” and “what silhouette features ensure readability,” then approach marketplace asset matching with clear requirements.

Missions/Levels: AI whitebox levels let designers run the full search-fight-extract flow — is pathing smooth, is POI density right, is extraction tension sufficient? Run the experience through on whitebox; production scenes coming in is just reskinning, not direction gambling.

Environment: Confirm spatial scale and sightline relationships on whitebox. Artists plan production scene layout direction accordingly, avoiding the “three months building a scene, then discovering the map is too big/small/has flow problems” disaster.

Audio: AI generates temporary gunfire/explosion/ambient SFX, letting designers experience the complete audio feedback chain. Validate audio layering and priority relationships with placeholders before commissioning production audio.

UI: AI generates debug HUD so designers see real-time health/ammo/status data in-game, validating information clarity and interaction flow.

Every pipeline follows the same pattern (see Experience Validation Loop diagram).

Traditional pipeline: “Art leads, design follows assets”
New pipeline: “Design leads, assets follow experience”
The most expensive thing in traditional game development isn’t production — it’s direction gambling. The new pipeline reduces direction gambling costs by an order of magnitude.

VII. Art Asset Strategy: Not Waiting for AI to Generate 3D — You Don’t Need It To

There’s an industry mental habit: when discussing AI’s value in game development, the conversation always gets stuck on “when will 3D asset generation mature.” As if AI has nothing to offer game development until 3D generation is ready.

This thinking is wrong.

3D asset generation is indeed immature, with no visible path to production-grade quality in the near term. But that doesn’t mean the art side can only wait. Our strategy is a four-phase workflow that completely bypasses the “AI generates 3D” bottleneck.

Phase 1: Validation — Testable in 24 Hours

After designers produce design documents, AI immediately generates whitebox levels, proxy models, temporary VFX, test audio, and batch test configs. The key isn’t these placeholders’ quality (they’re rough), but that they unblock gameplay validation from art pipeline progress. Any gameplay idea can reach a testable state within 24 hours.

Phase 2: Procurement — Don’t Reinvent Wheels

Once gameplay direction is confirmed, source from UE Marketplace / Fab, while reusing existing project assets. Small teams shouldn’t spend resources on problems the marketplace has already solved. The problem isn’t “can’t find assets” — it’s “assets from different sources look like a mashup when placed together.”

Phase 3: Refinement — Turning Mashup Into Cohesion

The most critical phase. AI refinement pipelines turn “manual one-by-one adjustment” into batch processing:

High maturity, directly batch-deployable:

Texture resolution alignment — AI super-res upscaling with linked normal/AO/roughness detail fill
Livery/variant batch generation — color tone, wear level, camo variants in one batch
Naming/directory standardization — AI scripts for batch renaming and auto-categorization

Moderate maturity, human-assisted:

Style unification — AI batch texture repaint for unified color temperature/wear/grime
Material standardization — AI PBR parameter calibration to unified standards
LOD auto-generation, animation retargeting, scale calibration, collision body adaptation

Phase 4: Replacement

Production assets replace placeholders, artists do final polish, ship.

Why This Strategy Beats “Waiting for 3D Generation to Mature”

First, it works today. No technology breakthroughs needed.

Second, it changes development rhythm. The entire pipeline shifts from “wait for assets → make game” to “make game → swap assets.”

Third, it reduces direction gambling costs. Wrong design directions are caught in the placeholder phase — no more spending three months of art capacity to “bet on a direction.”

The four-phase workflow isn’t an “art asset management plan” — it removes “waiting for assets” from the critical path entirely.

VIII. Runtime Experience: AI Director Possibilities and Boundaries

Beyond AI-ifying the development pipeline, extraction shooters also have potential for runtime AI intervention. But to be clear: this part is still in early exploration, unlike the already-deployable capabilities discussed above — this is more directional thinking.

Why Extraction Shooters Are Ideal for AI Director Experimentation

PvE extraction shooter characteristics make them an ideal testbed: no PvP fairness constraints, minimal squad data volume, single-match format requiring no cross-session memory, and the three-act structure naturally suited for phased orchestration.

Why You Can’t Let LLM Directly Control Enemies

This is the key question for understanding AI director architecture.

Runtime scenarios LLM is fundamentally unsuited for:

Combat Tick — damage calculation, collision detection, state updates execute every frame; LLM inference latency (hundreds of milliseconds to seconds) is completely unacceptable
NavMesh real-time control — pathfinding, obstacle avoidance, formation maintenance require millisecond-level response
High-frequency decisions — “should this enemy fire or reload this frame” is far too high-frequency for LLM
Determinism requirements — same input to a behavior tree always produces the same output; LLM doesn’t guarantee this, which is fatal in multiplayer synchronization

Four hard constraints dictate that LLM must operate above frame-level logic: latency, token cost, determinism, debuggability.

Runtime scenarios where LLM truly excels:

Wave Orchestration — “what spawns in the next 30 seconds, from which direction”
Encounter Pacing — “should we increase pressure or give breathing room”
Director Orchestration — “trigger an ambush” or “deploy a friendly distress signal”
Content Mutation — generate different mission/POI/enemy configs each match
Event Injection — trigger dynamic events at the right moments

Key judgment: LLM is unsuited for Combat Tick but excellent for Encounter Orchestration. LLM decides “what to do,” behavior trees decide “how to do it.”

AI Director Architecture

Honestly, What’s Not Solved Yet

Output stability: LLM may generate unreasonable config combinations; extensive constraint rules and output validation needed
Experience quality control: “numerically balanced” and “fun” are two different things
Debugging difficulty: Bad AI director decisions are harder to trace and fix than rule system issues
Cost: Per-match LLM inference server costs need serious accounting

The more realistic current approach: let LLM handle pre-match config generation first (one-time inference, controllable cost), keep mid-match scheduling on traditional rules + weighted randomization. After validating quality and stability, gradually expand LLM’s decision scope. Don’t bet on full AI director from day one.

IX. Summary: What AI Changed, What It Didn’t

What AI Changed

Engineering is fully AI-ready across all pipelines. All 8 pipelines’ engineering side can be deployed at scale. 60-70% reduction in baseline code workload — not replacing engineers, but freeing them from repetitive work to focus on architecture and core systems.

Design shifts from “filling spreadsheets” to “making judgments.” 5-10x efficiency gains. AI eliminates the manual labor in config production, freeing designers’ creative bandwidth.

Development rhythm control has changed. Through the “AI placeholder → marketplace reuse → AI refinement” strategy, validation no longer waits for assets. Want to try three different level layouts? No longer means triple the scene production time — it means three AI whiteboxes, all validated within a week.

What AI Didn’t Change

3D art assets still depend on humans. This won’t change short-term. But as analyzed above, this doesn’t prevent AI from delivering enormous value — the key is choosing the right strategy.

Work requiring “feel” and “judgment” remains human. Level spatial feel, hit feedback tuning, audio layering, art style direction — AI can assist but cannot replace these.

Game design creativity itself hasn’t changed. AI excels at “filling in content given a framework,” not “inventing an addictive core loop.” Whether an extraction shooter is fun depends not on how fast config tables generate, but on core loop design quality.

Greatest Efficiency Levers

Full AI adoption on engineering → The biggest, most certain, immediately deployable lever
Design numerical/config automation → Freeing designers’ creative bandwidth
Art asset reuse + AI refinement → Bypassing 3D generation bottleneck, changing development rhythm
MCP toolification → Establishing technical foundation for runtime AI directors

For the past twenty years, the game industry has increasingly resembled a “content manufacturing industry.” Teams grew larger, pipelines grew heavier, validation grew slower. A gameplay idea could wait months of asset production before being validated.

AI Native game development may be the first time game development returns to an era of “small teams, rapid experimentation.”

The game industry is shifting from “competing on asset production capacity” to “competing on experience validation speed.” The most competitive teams of the future won’t necessarily be those with the most assets, but those who can fastest validate “what’s fun.”

The greatest significance of AI Native development may not be making games “auto-generate,” but enabling teams to discover “what isn’t fun” as early as possible.

AI hasn’t made making games “easy,” but it has made it possible for a small team to build what previously required a large team. That is the true meaning of AI Native game development.