DEV Community: Lewis Liu

Best AI Model for Unreal Engine in 2026? Kimi K3 vs Claude Opus 5 vs Qwen3.8

Lewis Liu — Sat, 25 Jul 2026 12:26:14 +0000

Evidence checked on July 25, 2026. This comparison separates vendor claims, general coding evidence, and native Unreal Engine delivery. Those are not the same thing.

Kimi K3, Claude Opus 5, and Qwen3.8-Max-Preview all arrived with unusually strong claims around coding, visual iteration, long-running agents, or 3D creation. That makes one question inevitable for game developers:

Which AI model is actually best for building an Unreal Engine 5 game?

The short answer is Claude Opus 5 currently has the strongest public evidence for reliable agentic engineering and 3D reconstruction; Kimi K3 has the clearest first-party claim around playable 3D games and vision-in-the-loop iteration; Qwen3.8-Max-Preview is promising for large, multimodal engineering tasks but remains a preview with no official Unreal delivery proof.

The more important answer is that none of these model announcements, by itself, proves that the model can deliver a valid native Unreal project, compile Blueprint or C++, cook assets, package a build, and reproduce the result. For Unreal work, the execution environment often matters more than a small difference in model intelligence.

TL;DR: the Unreal-specific verdict

Model	Strongest relevant evidence	Unreal-specific gap	Best current role
Claude Opus 5	Strong agentic coding, verification, computer use, a successful 3D FreeCAD reconstruction case, and early-user reports of better games and 3D output	No official native Unreal project or packaging benchmark	Lead engineering agent for difficult implementation, debugging, and review
Kimi K3	First-party claim for playable multiplayer and 3D games, native vision, 1M context, long-horizon tool use, and screenshot-driven iteration	Showcases do not establish `.uproject`, Blueprint, C++, cook, or package success	Long-context, visually iterative game prototyping and tool-driven workflows
Qwen3.8-Max-Preview	2.4T multimodal preview positioned for repository-scale coding, long tasks, image/video/document understanding, and agent workflows	Preview status; no official Unreal or native 3D game-delivery evidence	Cost-aware experimentation, repository analysis, and implementation planning
Other frontier coding models	Strong general software-engineering and terminal-agent baselines	General coding scores still do not prove Unreal asset or build validity	Secondary implementer, reviewer, or fallback inside a controlled harness

My practical ranking is therefore task-dependent:

For difficult code, debugging, and self-verification: Claude Opus 5.
For visual iteration and open-ecosystem experimentation: Kimi K3.
For large-context, multimodal, cost-sensitive evaluation: Qwen3.8-Max-Preview.
For a playable native Unreal result: choose the workflow that can actually open Unreal, inspect screenshots and logs, modify the project, and package the build. Do not choose from model marketing alone.

First, define what “building a 3D game” means

Many impressive AI game demos are browser projects using Three.js, Babylon.js, WebGL, or a custom JavaScript runtime. Those can be excellent results, but they are not Unreal Engine projects.

A credible Unreal evaluation should require all of the following:

A valid native project with a .uproject file.
Correct Config, Content, Source, and plugin structure for the chosen scope.
A map that opens without missing dependencies.
Working input, camera, collision, and a small gameplay loop.
Blueprint and C++ that compile where those systems are used.
Assets that cook correctly for a named target platform.
A packaged build that launches outside the editor.
Logs, screenshots, and a reproducible handoff rather than a one-shot video.

Epic's packaging documentation describes Build, Cook, Stage, Package, Deploy, and Run as distinct operations. An attractive screenshot only covers a fraction of that pipeline.

This distinction is the most important part of the comparison. A frontier model can write excellent C++ and still fail because it cannot see the Unreal editor, resolve an asset reference, regenerate project files, inspect a cook error, or rerun the packaged executable.

Release status: what is actually available?

Kimi K3

Moonshot AI introduced Kimi K3 on July 17, 2026 as a 2.8-trillion-parameter model with native vision and a 1-million-token context window. K3 is available through Kimi, Kimi Work, Kimi Code, and the Kimi API. Its technical blog says the full model weights are scheduled for release by July 27, 2026.

That date matters. On July 25, the hosted product and API are available, but “open model” should not be interpreted as “the full weights are already downloadable everywhere.”

Kimi's most relevant claim is unusually direct: K3 combines 3D reasoning, coding, and vision to create playable interactive experiences, with a vision-in-the-loop workflow that alternates between code and live screenshots. The homepage also explicitly promotes playable multiplayer and 3D game creation.

This is highly relevant to game development. It is not yet Unreal-specific proof.

Claude Opus 5

Anthropic released Claude Opus 5 on July 24, 2026. It is available through Claude products and the API as claude-opus-5, at the same base API price Anthropic listed for Opus 4.8.

The release emphasizes long-running software agents, verification, computer use, professional work, and improved visual output. Two pieces of evidence are particularly relevant to 3D work:

In an Anthropic evaluation, Opus 5 reconstructed a machine part as a 3D FreeCAD model after building its own computer-vision pipeline to extract geometry from raw pixels.
An early-access partner reported the best animations, games, and 3D work they had seen from an Opus model.

Opus 5 also places unusual emphasis on checking its own work before reporting success. That behavior is valuable in Unreal, where a model must distinguish “the code looks plausible” from “the editor compiled it and the packaged build launched.”

Again, neither example is a published native Unreal packaging benchmark.

Qwen3.8-Max-Preview

The currently accessible model is Qwen3.8-Max-Preview, not a final open-weight Qwen3.8 release. Alibaba Cloud's developer-community overview describes a 2.4-trillion-parameter multimodal preview for engineering, long-running agents, large repositories, and image, video, and document understanding. It is available through selected Alibaba/Qwen coding and API surfaces, while the final weights remain future-facing.

Qwen's current public positioning is strongest around general engineering and WebDev. That can transfer to Unreal tasks such as reading a C++ module, proposing a subsystem architecture, refactoring build scripts, or interpreting screenshots. But I could not find an official claim that Qwen3.8 generates native .uproject files, compiles Blueprint graphs, cooks assets, or packages a production Unreal build.

Treat it as a promising preview, not a proven Unreal generator.

The readiness matrix: claims versus Unreal delivery

The labels below are evidence grades, not synthetic benchmark scores:

Strong: directly supported by a current first-party release or concrete case.
Moderate: supported indirectly by adjacent capabilities.
Unproven: no current public evidence specific to the requirement.

Requirement	Claude Opus 5	Kimi K3	Qwen3.8-Max-Preview
Long-horizon coding	Strong	Strong	Moderate–Strong
Visual/screenshot iteration	Strong	Strong	Moderate
3D creation evidence	Strong, via FreeCAD case and partner reports	Strong, via first-party 3D/game claims	Moderate, via multimodal/WebDev transfer
Large repository reasoning	Strong	Strong, 1M context	Strong in current positioning
Tool/terminal orchestration	Strong	Strong	Moderate–Strong
Native `.uproject` generation	Unproven	Unproven	Unproven
Blueprint asset compilation	Unproven	Unproven	Unproven
Unreal C++ build success	Unproven	Unproven	Unproven
Cook/package/launch proof	Unproven	Unproven	Unproven

This table is intentionally conservative. General coding benchmarks can help predict performance, but they do not test binary assets, editor-only APIs, plugin compatibility, shader compilation, cook rules, target SDKs, or packaged runtime behavior.

How each model is likely to behave in an Unreal workflow

Claude Opus 5: the strongest engineering lead

Opus 5 looks best suited to tasks where judgment matters more than raw generation volume:

tracing a multi-module Unreal C++ bug;
questioning an unsafe architecture before editing;
planning a Gameplay Ability System implementation;
interpreting build, cook, and runtime logs;
checking whether a fix addresses the root cause;
iterating with screenshots and tool output;
reviewing a handoff before claiming completion.

Its biggest advantage is not that it can draw the prettiest 3D scene. It is the combination of coding, computer use, iteration, and verification.

The risk is assuming this automatically gives it Unreal asset access. A language model cannot reliably create or repair binary .uasset files without an engine-aware tool path. Give it Unreal, source control, logs, screenshots, and explicit pass/fail checks.

Kimi K3: the strongest 3D-native claim

K3 has the clearest vendor claim around playable 3D creation. Its native vision, long context, terminal orchestration, and screenshot loop are a good match for:

creating a playable prototype over a long session;
iterating on composition, navigation, and visual defects;
retaining a large design brief plus repository context;
coordinating code, research, asset preparation, and testing;
working through a game-development task with minimal supervision.

K3's published limitations are also relevant. Moonshot warns that quality may become unstable if a harness does not preserve the expected thinking history, and that the model can be excessively proactive when instructions are ambiguous. In an Unreal workspace, that means permissions, file boundaries, plugin policy, allowed commands, and packaging targets should be explicit.

K3 may be an excellent engine inside a game-building agent. The current evidence still does not show that the base model alone is an Unreal pipeline.

Qwen3.8-Max-Preview: promising, but evaluate the preview as a preview

Qwen3.8-Max-Preview is attractive when the task contains a very large repository, mixed documents and visuals, or many repeated engineering operations. Possible Unreal uses include:

reading project source, configuration, build files, and technical design documents together;
generating C++ or automation scripts under a review loop;
analyzing screenshots, logs, and specifications;
planning migrations or repository-wide changes;
running cheaper exploratory passes before a stronger verifier reviews the result.

The problem is evidence maturity. The public material I found emphasizes preview access, general engineering, long agents, and WebDev—not a repeatable Unreal result. Until the final release, model card, and native engine tests are available, Qwen3.8 should be evaluated with stricter checkpoints rather than broader claims.

A reproducible Unreal benchmark that would actually matter

If you want to compare models fairly, give each one the same environment, prompt, time budget, tool permissions, and clean Unreal project.

Here is a compact benchmark:

Build a small third-person Unreal 5 game in which the player explores a mountain-and-water environment, reaches three checkpoints, and sees a completion screen. Use only redistributable or generated assets. Add a restart action, package for Windows, launch the packaged build, and provide the project, build logs, runtime logs, and five screenshots.

Score it with observable gates:

Gate	Pass condition
Project validity	`.uproject` opens in the specified Unreal version
Dependency integrity	No missing plugin, module, map, or asset references
Gameplay	Movement, camera, checkpoints, completion, and restart work
Code health	Blueprint and C++ compile without blocking errors
Visual review	Screenshots show the intended scene and readable UI
Packaging	Build, cook, stage, and package complete
Runtime	Packaged executable launches and completes the loop
Reproducibility	A second run from clean state produces the same result
Handoff	Source project, logs, build, assets, and rights notes are present

Record the number of human interventions, tool calls, elapsed time, retries, and unresolved warnings. That will tell you more than a model's generic coding rank.

So which model should an Unreal developer choose?

Choose Claude Opus 5 when you already have a capable tool environment and need the strongest current engineering judgment, difficult debugging, or careful verification.

Choose Kimi K3 when visual iteration, long context, and 3D/game experimentation are central—and when your harness can preserve its expected history and constrain its autonomy.

Choose Qwen3.8-Max-Preview when you want to evaluate a large multimodal model for repository analysis, automation, or cost-sensitive exploration, while accepting preview risk and the lack of native Unreal proof.

For serious work, a multi-model pipeline may be better: one model drafts and implements, another reviews the change, while Unreal itself remains the source of truth through compile, cook, package, and runtime tests.

The deeper conclusion: the harness beats the headline

The 2026 model race is making 3D demos faster and more impressive. But Unreal game development is not one generation step. It is a feedback loop across source code, Blueprints, assets, editor state, logs, rendering, performance, packaging, and runtime behavior.

The best Unreal AI system is therefore not automatically the model with the largest parameter count or the most attractive demo. It is the system that can:

create a native project;
observe the real editor and runtime;
repair failures using logs and screenshots;
package and launch the result;
return editable artifacts with honest limitations.

If you want to evaluate that complete workflow rather than another isolated model claim, SEELE AI provides a native Unreal 5 project workflow with browser preview, packaging, and local download. It is an independent product and is not affiliated with or endorsed by Epic Games. Generated projects, third-party assets, plugins, platform requirements, and release readiness still require review.

That link is included as a practical test option, not as evidence that one underlying model “wins” this comparison.

Sources and methodology

I prioritized current first-party sources, dated every time-sensitive claim, and marked capabilities as unproven when I could not find public Unreal-specific evidence. Vendor benchmarks and customer quotes are useful signals, but they are not a substitute for an identical, independently run Unreal benchmark.

Disclosure: AI tools assisted with source collection and article drafting. The capability boundaries, model status, and linked sources were reviewed against the pages listed above on July 25, 2026.

We Open-Sourced a Seeded UE5 Village Generator — Here’s the C++ Pipeline

Lewis Liu — Sat, 18 Jul 2026 04:05:51 +0000

Randomly scattering meshes is easy. Generating a village that follows the terrain, avoids obvious overlaps, stays art-directable, and can be reproduced from a seed is the harder problem.

We open-sourced the solution as Seele Scatter Regions, an MIT-licensed Unreal Engine 5.5 editor plugin developed by SEELE AI. It generates villages, farms, and cemeteries from project-owned Static Mesh recipes without depending on Unreal Engine's PCG framework.

The repository includes the public C++ source, Blueprint-callable editor tooling, a JSON automation path, packaging validation, and a UE5.5 release. This article walks through how those pieces fit together.

This post walks through the current C++ implementation: how recipe assets become topology, how candidate points are filtered into believable layouts, how instances are projected onto Landscape, and how the generator exposes enough telemetry to be automated safely.

Current scope: beta 0.1.0, Unreal Engine 5.5, editor-side generation, and C++ projects.

The actual problem: controlled randomness

A useful procedural tool needs more than a random position and yaw. We wanted five properties:

Repeatability — the same seed should reproduce the layout when the recipe and scene are unchanged.
Art direction — artists should provide meshes, weights, density, and scale without recompiling C++.
Spatial logic — roads, buildings, fields, tombs, gates, and props need different placement rules.
Terrain awareness — generated content must land on Landscape instead of floating at the input Z.
Automation-friendly results — callers need structured counts, warnings, bounds, and errors, not just a log line.

The implementation became a pipeline:

JSON / C++ input
        ↓
Recipe Data Asset
        ↓
Seeded boundary + road topology
        ↓
Candidate point generation
        ↓
Density, distance, slope, and collision filters
        ↓
Landscape projection
        ↓
Instanced Static Mesh components
        ↓
Structured generation result

The important design decision is that randomness is only one stage. Most of the believable result comes from constraints applied after candidate generation.

1. Put art direction in recipe assets

The public recipe starts with a small piece of shared mesh data:

USTRUCT(BlueprintType)
struct FScatterRegionMeshRecipeData
{
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    TSoftObjectPtr<UStaticMesh> Mesh;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    FVector ScaleMin = FVector::OneVector;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    FVector ScaleMax = FVector::OneVector;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    bool bUniformScale = false;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, meta = (ClampMin = "0.0"))
    float Weight = 1.0f;
};

A UScatterRegionRecipeDataAsset then exposes type-specific slots:

Village: weighted building slots, local props, fence, gate, road, roadside props, and scatter props
Farm: road, dirt tiles, crops, and scarecrows
Cemetery: road, tombs, and a memorial/panteon slot

The asset normalizes its slot layout in the constructor, PostLoad, and PostEditChangeProperty. When the region type changes, irrelevant slots disappear and the expected slots are restored.

This gives us a stable contract without hard-coding production art. The open-source repository includes lightweight recipes using Unreal's Basic Shapes, while real projects can duplicate a recipe and assign their own assets.

Soft object references matter here: recipes can describe content without eagerly loading every mesh. At generation time, the compiler resolves the selected recipe, validates its slots, loads meshes synchronously, and converts the author-facing data into a compact internal representation.

2. A seed should control topology, not only decoration

Every random choice flows through one FRandomStream:

FRandomStream Stream(Spec.Seed);

if (Spec.RegionType == TEXT("farm"))
{
    GenerateFarm(Context, Spec, Recipe, Stream);
}
else if (Spec.RegionType == TEXT("cemetery"))
{
    GenerateCemetery(Context, Spec, Recipe, Stream);
}
else
{
    GenerateVillage(Context, Spec, Recipe, Stream);
}

The seed influences boundary irregularity, road bends, branch placement, building selection, density filtering, mesh weights, position jitter, yaw, and scale. This is more useful than applying a seed only to the final prop scatter: the large-scale composition is reproducible too.

For villages, the generator builds a smoothed closed boundary, chooses a gate along the boundary, and grows the road graph inward from that gate. The primary road is made from short quadratic Bézier segments; secondary branches search for valid endpoints inside the polygon.

In simplified form:

const FVector2D Control =
    (Start + End) * 0.5f +
    Normal * Stream.FRandRange(-BendStrengthCm, BendStrengthCm);

for (int32 Index = 1; Index <= SegmentCount; ++Index)
{
    const float T = static_cast<float>(Index) / SegmentCount;
    const FVector2D A = FMath::Lerp(Start, Control, T);
    const FVector2D B = FMath::Lerp(Control, End, T);
    const FVector2D Current = FMath::Lerp(A, B, T);
    Segments.Add(MakeRoadSegment(Previous, Current, bPrimary));
    Previous = Current;
}

The result is deterministic but not rigidly grid-shaped.

There is one important caveat: deterministic generation means same seed + same recipe + same scene state. If the Landscape or mesh bounds change, projection and collision decisions can change as well. The seed makes a build reproducible; it does not freeze the world around it.

3. Treat placement as a point-processing pipeline

The reusable core is a lightweight graph-point structure containing location, yaw, density, bounds radius, Z offset, and a scale multiplier.

Instead of placing a mesh immediately, each region strategy creates candidate points and runs them through small transforms. The village roadside-prop path is a good example:

SidePropPoints = ScatterRegionDensityFilter(
    SidePropPoints, Stream, 1.0f);

SidePropPoints = ScatterRegionDifferenceAgainstRoads(
    SidePropPoints,
    RoadSegments,
    MinRoadDistance,
    MaxRoadDistance);

SidePropPoints = ScatterRegionDifferenceAgainstPlacements(
    SidePropPoints,
    BuildingPlacements,
    BuildingClearance);

SidePropPoints = ScatterRegionSelfPruning(
    SidePropPoints,
    Stream,
    MinimumSpacing,
    true);

ScatterRegionLookAtRoad(SidePropPoints, RoadSegments);

ScatterRegionTransformPoints(
    SidePropPoints,
    Stream,
    80.0f,          // position jitter in cm
    12.0f,          // yaw jitter in degrees
    FVector(0.85f),
    FVector(1.15f),
    true);

Each operation has one job:

Density filter accepts points probabilistically from recipe density.
Difference against roads enforces a minimum and optional maximum road distance.
Difference against placements keeps props away from buildings or reserved landmarks.
Self-pruning rejects candidates that are too close to already accepted points.
Look-at-road rotates a point toward its nearest road segment.
Transform adds controlled position, yaw, and scale variation.

Collision reservation uses mesh bounds when available, so a large building and a small prop do not consume the same amount of space.

This pipeline is the heart of the system. Region generators can create very different candidate sets while reusing the same constraints.

4. Project every accepted instance onto Landscape

Candidate generation happens in local XY space around a root actor. Before an instance is committed, the plugin traces vertically through the editor world:

const FVector Start(
    WorldXY.X,
    WorldXY.Y,
    Context.Center.Z + LocalLocation.Z + 200000.0f);

const FVector End(
    WorldXY.X,
    WorldXY.Y,
    Context.Center.Z + LocalLocation.Z - 200000.0f);

TArray<FHitResult> Hits;
Context.World->LineTraceMultiByChannel(
    Hits,
    Start,
    End,
    ECC_Visibility,
    QueryParams);

for (const FHitResult& Hit : Hits)
{
    if (IsLandscapeTraceHit(Hit))
    {
        OutLocalLocation.Z =
            Hit.ImpactPoint.Z - Context.Center.Z;
        Context.ProjectionHits++;
        return true;
    }
}

The trace ignores the root actor and actors tagged as previously generated regions. Without that, later generations could project onto earlier generated meshes instead of the Landscape.

After projection, the mesh is grounded using its bounds:

Location.Z += GroundedZ(RecipeMesh, Scale);
Location.Z += VerticalOffsetCm;

The generator tracks projection attempts, hits, and misses. A complete miss becomes a warning rather than silently producing a misleading "success."

Slope checks reuse Landscape samples around building or memorial candidates. That lets large semantic objects be rejected on steep terrain before they are committed.

5. Batch output with Instanced Static Mesh components

Spawning one Actor per crop, tomb, or fence segment would create unnecessary editor and rendering overhead. The plugin groups instances by slot + mesh path:

const FString ComponentKey = Slot + TEXT("|") + RecipeMesh.Path;

if (UInstancedStaticMeshComponent** Existing =
        Context.Components.Find(ComponentKey))
{
    return *Existing;
}

UInstancedStaticMeshComponent* Component =
    NewObject<UInstancedStaticMeshComponent>(
        Context.RootActor,
        ComponentName);

Component->SetStaticMesh(RecipeMesh.Mesh);
Component->AttachToComponent(
    Context.RootActor->GetRootComponent(),
    FAttachmentTransformRules::KeepRelativeTransform);

Every accepted transform is added to the matching UInstancedStaticMeshComponent. The generated region remains one tagged root actor with a manageable component set, while slot counts and world bounds are updated as instances are added.

We have deliberately not attached a benchmark number to this design: performance depends on meshes, materials, instance counts, and the target machine. The architectural benefit is still concrete—thousands of repeated objects do not become thousands of Actors.

6. Three content grammars, one infrastructure

The generators share recipes, random streams, point filters, projection, collision reservation, output components, and telemetry. What differs is the content grammar.

Region	Topology	Main placement rules
Village	Irregular boundary, gate-rooted main road, bent branches	Road-facing building clusters, local props, perimeter fence/gate, roadside and free scatter
Farm	Closed boundary, two-lane access roads, tiled fields	Dirt tiles avoid road footprints; crops sit above dirt; scarecrows are density-filtered and spaced
Cemetery	Closed boundary and access paths	Memorials reserve exclusion zones; tomb grids avoid roads and memorials, then self-prune

This separation is valuable. A "universal" random scatter function would bury these differences in flags. Three small domain strategies over shared primitives are easier to reason about and extend.

7. Make the generator safe to automate

The same generator can be called from C++, a Blueprint-callable Editor Subsystem, or a JSON adapter.

A request looks like this:

{
  "region_type": "village",
  "center": [75000, 37000, 0],
  "size_m": 150,
  "seed": 76101,
  "recipe_asset": "/Game/MyRecipes/DA_Village.DA_Village"
}

The public command is generate_scatter_region. Inputs are validated before the world is touched:

region type must be village, farm, or cemetery
size is clamped to 20–1000 meters
a recipe asset path is required
generation is rejected when PIE is active
the editor world must be initialized and available

The result reports:

success
generated actor name
instance and component counts
per-slot counts
projection attempts, hits, and misses
generated bounds
warnings and structured errors

That observability is not just polish. It lets an automation client distinguish "the command returned" from "a useful region was actually generated."

A practical success check is:

success == true
region_actor is not empty
instance_count > 0
projection_hits > 0 when Landscape projection is expected
errors is empty

What we learned

A few design lessons survived every iteration:

Randomness is an input, not the architecture. The spatial constraints do most of the work.

Determinism must include topology. Reproducing only prop jitter is not enough when roads and clusters define the composition.

Authored data and generation logic should evolve separately. Recipe assets let artists replace meshes and tune density without turning the generator into project-specific code.

Telemetry belongs in the public API. Counts, bounds, warnings, and projection statistics make editor automation debuggable.

Scope should be explicit. Version 0.1.0 generates in the editor, not at packaged-game runtime. The generated actor and instanced components can be saved with the edited level.

Try it or read the source

Seele Scatter Regions is MIT-licensed and open source:

If you are building procedural tools in Unreal Engine, I would be interested to hear how you balance deterministic generation, designer control, and terrain constraints—especially if you have taken a PCG-based or runtime-first approach.

A website that counts open source model tokens online is recommended

Lewis Liu — Sat, 17 Aug 2024 10:18:42 +0000

Still wondering how to count tokens for the open source model?

Today, I recommend a web tool whose main function is to count tokens for open source models that currently support both Mistral and Llama2 models.

web links：toolai.fun

Using this web tool is very simple. Just select the corresponding model, enter the characters, the system will automatically calculate the number of tokens, and provide intuitive results display. This not only saves the user's manual calculation time, but also improves the work efficiency.

If you need it, save it and use it toolai.fun