DEV Community: Anthony KOZAK

How to Build a Production-Ready Save System in Unity

Anthony KOZAK — Mon, 12 Oct 2026 08:03:56 +0000

A save system looks like a small technical feature until real players depend on it. Then it becomes part database, part platform integration, and part promise. After 16 years in game development, including shipping Eagle Flight Arcade as a Gameplay Programmer at Ubisoft Montreal in 2016, publishing Touch Camera PRO, and freelancing across Unity projects, I treat persistence as production infrastructure. The goal is not merely to serialize an object. The goal is to preserve player intent through updates, crashes, platform interruptions, and design changes.

Key Takeaways

Save durable player intent and stable identifiers, not an uncontrolled snapshot of the Unity scene.
Use versioned data transfer objects that remain separate from MonoBehaviours and runtime systems.
Write transactionally through temporary files, validation, replacement, and recoverable backups.
Build explicit migrations and test them against real fixtures from every supported schema.
Treat platform lifecycle handling, cloud conflicts, user feedback, and failure recovery as core features.

Why Is a Save System More Than Serialization?

Serialization answers one narrow question: how can an in-memory value become bytes or text? A production save system must answer a much larger set of questions. What happens if the application closes halfway through a write? What if a field disappears in the next update? What if the file is syntactically valid but refers to content that no longer exists? What if a returning player loads data created several releases ago?

Players rarely praise persistence when it works. They notice it immediately when it fails. Lost progress can invalidate hours of play, while a corrupted settings file can prevent the game from reaching its main menu. That makes the save pipeline part of the user experience, even though most of its code runs invisibly. I therefore design it with the same seriousness I would apply to input, scene loading, or platform submission requirements.

The first useful mental model is to treat a save operation as a transaction. It either produces a complete, validated new state, or the previous valid state remains available. Overwriting the only copy directly violates that rule. If the process loses power or storage access during the write, the player may be left with neither the old state nor a complete new one.

The second model is to treat every shipped save format as a public contract. Once players possess version 1 data, that schema exists in the world whether the team still likes it or not. Renaming a field, changing an item identifier, or reorganizing quests may become a data migration problem. This is why I push save design earlier than many teams expect. You do not need the final implementation during prototyping, but you do need to identify what progress means before content and code silently create incompatible assumptions.

What Game Data Should Actually Be Saved?

I start by separating durable player intent from reconstructable runtime state. Durable intent includes facts such as unlocked content, completed objectives, selected options, inventory quantities, or authored customization choices. Reconstructable state includes cached references, navigation paths, temporary animation values, pooled object status, and other information that systems can regenerate after loading. Saving less data usually creates a more resilient system.

Runtime objects are especially dangerous persistence targets. A MonoBehaviour may contain references to scenes, components, services, coroutines, and cached data that only make sense during one execution. Instead of storing the component, store a compact record that describes the durable outcome. A door might need a stable door identifier and an open state. It does not need its Transform, Animator, collider, or current animation time unless the game design specifically requires exact mid-animation restoration.

I also divide data by responsibility. Profile data can contain global unlocks or accessibility preferences. Campaign data can represent progress within one playthrough. Settings can have a separate lifecycle because they may need to load before gameplay. Temporary checkpoint data may be replaceable and more frequent than manual slots. These categories do not always require separate files, but naming them exposes conflicting requirements before they become code.

Authored identifiers are the bridge between saved records and current content. I prefer explicit, stable IDs over array positions, scene hierarchy paths, or display names. A designer should be able to reorder an item list or rename a visible label without invalidating old progress. IDs also need governance. Accidentally reusing a deleted ID can be worse than failing to find it because an old record may silently resolve to the wrong content. The save should express what happened, while current game systems decide how to reconstruct the playable state from that durable information.

How Should a Unity Save Schema Be Structured?

I keep persistence models separate from gameplay models. A save data transfer object should be boring: serializable fields, stable identifiers, simple collections, and minimal behavior. Gameplay systems can remain rich and interconnected, but the boundary between runtime state and persisted state should be explicit. This separation prevents an innocent refactor of a MonoBehaviour from automatically becoming a breaking file format change.

At the top level, I use an envelope containing a schema version, payload, integrity information, and useful diagnostic metadata. The schema version belongs to the data format, not the public game version. A game can ship several patches without changing its schema, or change the schema multiple times during one release cycle. Build information can still help diagnose reports, but it should not control migrations by itself.

Defaults must also be intentional. Missing data is normal when loading an older format. If a new accessibility option appears, an old save cannot contain it. The loader needs a documented default rather than whatever value a field happens to receive after deserialization. I prefer constructing a valid default model first and then applying loaded values or migration results. That approach makes absent optional information predictable.

Unity's JsonUtility is useful for straightforward serializable classes, but its limitations should shape the schema. Dictionaries, polymorphic graphs, and interface-heavy models require another representation or serializer. That is not necessarily a problem. Save formats benefit from simple structures. I avoid serializing UnityEngine.Object references and represent relationships with IDs instead. If a project needs human-readable files, JSON is convenient for debugging. If size or speed later becomes material, the storage encoding can change behind the same persistence interface. The domain schema matters more than whether the bytes are JSON, a binary format, or a platform-specific container.

How Can Save Writes Survive Crashes and Corruption?

My baseline file workflow is write, flush, validate, replace, and retain recovery data. The game first serializes a complete envelope into a temporary file located on the same storage volume as the final file. It flushes that file, then replaces the previous save. When the platform supports replacement with a backup, the old valid file becomes a recovery candidate rather than disappearing immediately.

A checksum helps detect truncation or accidental modification, but it is not an anti-cheat system. Anyone who controls the client can potentially reproduce a checksum. If competitive inventory, purchases, or entitlements require authority, those values belong on a trusted service. Local validation protects reliability, not business rules.

using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;
using UnityEngine;

[Serializable]
public sealed class SaveEnvelope
{
    public int schemaVersion = 3;
    public string buildId;
    public string payloadJson;
    public string checksum;
}

public static class SaveFileWriter
{
    public static void Save<T>(string slotName, T data)
    {
        string payload = JsonUtility.ToJson(data);
        var envelope = new SaveEnvelope
        {
            buildId = Application.version,
            payloadJson = payload,
            checksum = ComputeSha256(payload)
        };

        string directory = Path.Combine(
            Application.persistentDataPath, "saves");
        string finalPath = Path.Combine(directory, slotName + ".json");
        string tempPath = finalPath + ".tmp";
        string backupPath = finalPath + ".bak";

        Directory.CreateDirectory(directory);
        byte[] bytes = Encoding.UTF8.GetBytes(
            JsonUtility.ToJson(envelope));

        using (var stream = new FileStream(
            tempPath, FileMode.Create, FileAccess.Write, FileShare.None))
        {
            stream.Write(bytes, 0, bytes.Length);
            stream.Flush(true);
        }

        if (File.Exists(finalPath))
        {
            if (File.Exists(backupPath)) File.Delete(backupPath);
            File.Replace(tempPath, finalPath, backupPath);
        }
        else
        {
            File.Move(tempPath, finalPath);
        }
    }

    private static string ComputeSha256(string value)
    {
        using (var sha = SHA256.Create())
        {
            byte[] hash = sha.ComputeHash(Encoding.UTF8.GetBytes(value));
            return BitConverter.ToString(hash).Replace("-", string.Empty);
        }
    }
}

This is an illustrative desktop-style implementation, not universal platform code. File replacement, synchronous flushing, storage permissions, and available cryptography APIs can differ by Unity target and scripting backend. I put these operations behind an interface so console storage, WebGL persistence, mobile files, and editor tests can use appropriate adapters.

Loading should follow the reverse discipline. Read the primary file without mutating it, parse the envelope, validate the checksum, migrate the payload, and validate domain invariants. If that fails, try the backup and report the recovery. Never interpret a deserialized object as valid merely because parsing succeeded. A negative currency value, duplicate unique item, or reference to removed content may be structurally valid JSON while still being unusable game state.

How Should Save Data Migrations Work Across Updates?

In 2025 and 2026, games commonly remain installed through many updates, and players may return after long breaks. A save system therefore needs to handle skipped versions. I use sequential migrations: version 1 becomes version 2, version 2 becomes version 3, and so on until the current schema is reached. Each step is small, testable, and responsible for one historical change.

This is safer than a single function full of conditions for every previous release. A direct old-to-current conversion tends to accumulate branches that are difficult to reason about. Sequential migration preserves the meaning of each transition. For example, one step can replace a renamed item ID, while another initializes a newly introduced progression field. Tests can identify exactly which historical transition failed.

Migrations should operate on a copy and produce a validated result before replacing any file. Keep the original backup until the new save has loaded successfully. I also avoid destructive cleanup during the first migration pass. If content was removed, an archived or explicitly unknown record may be safer than silently deleting something that could become meaningful after a correction. The right policy depends on the game, but accidental data loss should never be the default.

Every migration needs fixtures representing actual old schemas. I check those files into version control with a short explanation of what they cover. That creates a permanent compatibility suite even after the original code has changed. It also forces the team to distinguish between schema history and current runtime classes. When support for a very old format must eventually end, make that a deliberate product decision with clear player communication and recovery options. Do not let compatibility disappear accidentally because a developer removed a class that appeared unused. Shipped data is an external dependency, even when the only external system is a file sitting on a player's device.

How Do Platform Lifecycles Change Save System Design?

A file path is only one part of platform persistence. Desktop, mobile, console, and WebGL targets have different lifecycle events, storage behavior, user identity models, and interruption risks. Unity's Application.persistentDataPath provides a useful location abstraction, but it does not make every platform behave identically. The storage adapter still needs testing on actual targets.

On mobile, the application can lose focus, pause, or be terminated without a long shutdown window. I do not rely exclusively on OnApplicationQuit. Instead, gameplay emits meaningful save requests during safe transitions, and pause handling attempts a final lightweight commit. Rapid events should be debounced so entering a menu does not trigger several redundant writes. A snapshot of Unity-owned state should be captured on the main thread before any background serialization or I/O, because most Unity APIs are not thread-safe.

Console projects may require platform user selection, reserved storage, quota handling, or platform-specific APIs. WebGL persistence may involve browser-managed storage and synchronization behavior rather than normal desktop files. Cloud saves add another layer, but cloud storage is replication, not a substitute for local transactional safety. Uploading corrupted state simply creates a remote copy of the problem.

Conflict resolution needs product rules. A revision number, device identifier, playtime summary, progression summary, and modification time can help, but the newest timestamp should not automatically win because clocks can be wrong. Some games can merge independent categories such as settings and unlocked cosmetics. Others must ask the player to choose between recognizable snapshots. Save size and frequency also affect cloud cost, synchronization time, and platform limits. I define these constraints before designing a massive world snapshot. Platform persistence is architecture plus user experience, so error messages, retry behavior, offline access, and account switching need the same attention as the serializer.

How Can a Team Test Save Failures Before Players Find Them?

I build a failure matrix rather than testing only a successful round trip. A useful suite covers a missing file, empty file, truncated JSON, invalid checksum, unsupported future version, every supported historical version, missing optional fields, removed content IDs, duplicate records, permission errors, and an interrupted temporary write. It should also verify recovery from the backup and confirm that repeated load-save cycles do not gradually change values.

The easiest way to test this is dependency injection. Gameplay code should talk to a save service, while that service talks to a storage interface. Editor tests can use memory storage that simulates partial writes, unavailable space, or exceptions at specific transaction stages. Integration tests can exercise real files in a temporary directory. Platform builds then verify the final adapter and lifecycle behavior.

Golden fixtures are particularly valuable. I keep representative files for each schema version and assert that they migrate into valid current models. I also test locale-sensitive values. Numbers and dates should use invariant, explicit representations rather than depending on the device's formatting rules. Randomized data can expose boundary mistakes, but carefully designed fixtures remain necessary for known historical cases.

Manual destructive testing still matters. Save during a meaningful transition, terminate the development build, relaunch, and inspect which state survives. Repeat the experiment at different moments around the transaction. On supported hardware, test low storage, user switching, suspended applications, and disconnected cloud access. Logging should identify the slot, schema version, transaction stage, and recovery path without exposing personal information or the full contents of a player's save. Finally, make failure visible to QA. If the game silently resets to defaults after a load error, a tester may report unrelated progression bugs instead of the real persistence failure. A clear diagnostic mode shortens that investigation dramatically.

What Production Workflow Keeps Persistence Maintainable?

A maintainable save system needs ownership and a written contract. I document the top-level data categories, current schema version, stable ID rules, save triggers, backup policy, migration policy, and platform adapters. Designers need to know which authored identifiers cannot be casually changed. Programmers need to know how new fields receive defaults. QA needs fixtures and a visible way to create, export, import, and damage test saves.

I also schedule persistence work alongside features rather than at the end. When a quest, inventory, customization system, or world interaction becomes durable, its save representation is part of its definition of done. That does not mean saving every internal field. It means proving that the player's meaningful outcome survives a restart and an upgrade from the previous schema.

Scope should match the game. A reliable autosave with one recoverable slot is better than an elaborate multi-slot interface built on unsafe writes. Add manual slots, thumbnails, cloud synchronization, cross-device merging, and import tools only when the product requires them. Each feature multiplies states that need testing. Even a thumbnail introduces questions about atomicity and whether the image matches the committed data.

My perspective here comes from both shipped game work and long-lived Unity products. Eagle Flight Arcade shipped in 2016, while assets such as Touch Camera PRO exist in an ecosystem where Unity versions and customer projects continue changing. The common lesson is that compatibility is ongoing work, not a launch checkbox. For teams that need broader architecture and delivery support, my full-cycle Unity game development service covers production planning, implementation, platform preparation, and systems such as persistence. Whatever the project size, the standard remains the same: preserve the last known good state, make schema changes explicit, and rehearse failure while the team can still fix it.

References & Further Reading

AI-Assisted Unity Testing: How to Verify Generated Code

Anthony KOZAK — Mon, 05 Oct 2026 08:02:02 +0000

AI can generate a Unity test fixture in seconds, but speed is not the same as evidence. After 16 years in game development, I have learned that the dangerous bugs are rarely the ones that fail to compile. They are the ones that compile, pass a reassuring test suite, and still violate the player's expectations on a real device. In 2026, coding agents make that false confidence easier to manufacture at scale. My rule is simple: let AI expand the search space, but never let it define correctness. This article explains how I use that rule to turn AI into a practical test engineering assistant rather than an automated producer of green checkmarks.

Key Takeaways

Define behavioral contracts before asking AI to generate tests.
Keep the test oracle independent from the production implementation.
Separate Edit Mode, Play Mode, and device validation by risk.
Prove important tests by making them fail intentionally.
Use deterministic fuzzing and mutation to expose weak assertions.

Why can AI-generated Unity tests be dangerously convincing?

When a model returns a clean NUnit fixture with descriptive method names, setup code, and a row of passing assertions, the result looks finished. That presentation is part of the risk. Large language models are excellent at reproducing the shape of a test. They are less reliable at deciding whether the test proves the behavior that matters. A syntactically perfect test can assert the wrong output, exercise an impossible state, or duplicate the same faulty assumption used by the implementation.

Unity adds several ways for this illusion to survive. A test might bypass the MonoBehaviour lifecycle that triggers the real defect. It might call a method directly even though production invokes it after input processing, animation, or scene activation. Physics timing, serialization, script execution order, platform APIs, and object destruction all create differences between a neat unit test and the running game. An AI assistant cannot infer every one of those boundaries from a single source file.

I learned the importance of platform boundaries as a gameplay programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016. The game targeted PSVR, Oculus Rift, and HTC Vive. Even when gameplay intent is shared, the path through hardware, input, runtime behavior, and presentation is not automatically identical. Publishing Touch Camera PRO has reinforced the same general lesson in another context: interaction code lives inside projects with different UI layouts, settings, devices, and integration choices.

The most dangerous generated test is a mirror. If production computes a value with a particular formula and the test calculates its expected result with that same formula, both can agree while both are wrong. Mocks can create a similar trap by confirming that mocked collaborators return exactly what the test configured them to return.

I therefore classify AI output as a hypothesis, not proof. Compilation proves syntax. A passing assertion proves agreement with an oracle. Only a well-chosen, independent oracle gives that agreement any value.

What should you define before asking AI to write tests?

Start with a risk map, not a prompt asking for comprehensive coverage. Comprehensive is an attractive word with no operational meaning. I first write down what can hurt the product: corrupted state, blocked progression, incorrect input, unstable frame behavior, broken saves, platform-specific failures, and interaction states that leave the player without a recovery path. The exact list changes by project, but it must come from product knowledge rather than model confidence.

For each risk, define an observable consequence. If a camera zoom policy receives a value beyond its supported range, the output must remain inside the configured limits. If a UI panel owns a touch, gameplay should not react to that same touch. If loading fails, the application needs a defined recovery state. These statements are more useful than implementation instructions because they describe what a player or another system can observe.

Next, list boundaries and state transitions. AI tends to produce happy-path examples unless prompted otherwise. I explicitly include minimum and maximum values, values just inside and outside each boundary, empty collections, duplicate events, disabled objects, scene changes, interrupted operations, repeated initialization, and invalid serialized data. Time-based code also needs zero delta, unusually large delta, pauses, and operations that span multiple frames.

Then decide which dependencies are real in the test. Replacing everything with mocks makes tests fast, but it can remove the exact integration behavior that needs validation. A pure calculation may need no Unity objects. A component that depends on activation order probably needs a GameObject and a Play Mode test. Input or XR behavior may require a simulator for broad checks and target hardware for final evidence.

Only after that preparation do I ask AI for a candidate test matrix. I provide the public behavior, known risks, legal inputs, forbidden outcomes, and available test environments. The model can then identify missing combinations or tedious cases. I still choose which cases matter, because prioritization is an engineering decision tied to the product, not a text generation task.

How do you turn design intent into testable contracts?

A useful contract states preconditions, an operation, and observable postconditions. Consider a generic camera zoom policy. Its preconditions might require finite minimum and maximum values with the minimum no greater than the maximum. The operation accepts a requested zoom. Its postconditions say that the result is finite, remains within the configured interval, and equals the request when that request is already legal. Those claims can be tested without knowing whether production uses Mathf.Clamp, branches, or another implementation.

Contracts also need state rules. Initialization might be safe to call once but reject a second call, or it might be intentionally idempotent. Disabling a component might preserve configuration while clearing transient input. An interrupted transition might roll back, finish immediately, or enter a recoverable error state. Any of those policies can work. The costly situation is leaving the policy undefined and allowing AI to invent one while generating tests.

I separate objective rules from subjective qualities. Camera bounds, event ownership, and save compatibility can have crisp assertions. Camera feel, animation appeal, and comfort need human evaluation plus measurable proxies. A test can detect a sudden discontinuity or an excessive angular speed, but it cannot certify that movement feels good. Calling a subjective judgment automated does not make it objective.

This contract work often exposes architecture problems before it exposes bugs. If a rule can only be tested by loading a large scene and waiting through several frames, important policy may be tangled with Unity lifecycle code. Extracting a small deterministic policy from a MonoBehaviour can improve both testability and maintenance. It also gives AI a smaller surface where generated cases are easier to audit.

For difficult systems, an external perspective can help distinguish missing contracts from implementation noise. That is one reason I offer Unity code reviews and architecture audits. Whether the reviewer is a person or an AI assistant, the key question is the same: can we describe correct behavior independently enough to recognize an incorrect implementation?

Which Unity tests belong in Edit Mode, Play Mode, or device builds?

Edit Mode tests are my first choice for deterministic C# rules. Parsers, coordinate conversions, validation, inventory policies, selection rules, and mathematical utilities usually belong here if they can run without a scene lifecycle. These tests are fast, easy to isolate, and cheap to execute after every change. AI is particularly productive at filling out boundary tables for this layer because the inputs and outputs can be made explicit.

Play Mode tests answer a different class of question. They are appropriate when behavior depends on GameObject activation, MonoBehaviour callbacks, coroutines, scene loading, physics steps, instantiated prefabs, or operations spread across frames. A component can pass every direct method test and still fail because OnEnable runs before a dependency is ready. Moving that test into Play Mode is not an admission that unit testing failed. It is recognition that lifecycle behavior is part of the contract.

Device tests cover evidence that the Editor cannot provide. Graphics APIs, memory pressure, permissions, touch behavior, sensors, native plugins, IL2CPP, XR runtimes, and headset input can differ from an Editor simulation. Eagle Flight Arcade shipped across PSVR, Oculus Rift, and HTC Vive in 2016, and that multi-platform experience made one principle permanent for me: shared source code does not eliminate platform-specific validation.

I use a layered portfolio rather than forcing everything into a pyramid. Run numerous focused Edit Mode tests frequently. Run relevant Play Mode tests on changes and in continuous integration. Reserve slower builds and hardware checks for the risks only those environments can reveal. A project involving device interaction may need proportionally more hardware evidence than a tool built entirely around Editor workflows.

AI assistants often select the easiest layer because they optimize for producing runnable code from visible context. Correct that bias in the request. Tell the model which Unity lifecycle, platform, and integration boundaries matter, then ask it to classify candidate tests by layer. Review that classification before generating fixtures. Choosing the wrong environment can make a technically valid test irrelevant to the actual failure mode.

How can AI generate test cases without owning the oracle?

I get the best results when I give AI a human-authored contract and ask it to vary inputs, not expected behavior. The model can expand a boundary table, translate cases into NUnit attributes, improve failure messages, and identify values I omitted. The expected outcomes still come from the contract. This division of labor uses AI for repetition and search while keeping product judgment under human control.

Here is a deliberately small example. The constants are illustrative, not values from Touch Camera PRO. The examples assert exact boundary behavior, while the seeded loop checks a broader invariant. Production could later change its internal algorithm without forcing the tests to copy that implementation.

using NUnit.Framework;
using UnityEngine;

public static class CameraZoomPolicy
{
    public static float ClampZoom(float requested, float min, float max)
    {
        if (float.IsNaN(requested) || float.IsInfinity(requested))
            throw new System.ArgumentException("Zoom must be finite.");

        return Mathf.Clamp(requested, min, max);
    }
}

public class CameraZoomPolicyTests
{
    [TestCase(-100f, 1f)]
    [TestCase(1f, 1f)]
    [TestCase(6f, 6f)]
    [TestCase(12f, 12f)]
    [TestCase(100f, 12f)]
    public void ClampZoom_RespectsDocumentedBounds(
        float requested,
        float expected)
    {
        float result = CameraZoomPolicy.ClampZoom(requested, 1f, 12f);
        Assert.That(result, Is.EqualTo(expected));
    }

    [Test]
    public void ClampZoom_AlwaysReturnsValueInsideBounds()
    {
        var random = new System.Random(2026);

        for (int i = 0; i < 500; i++)
        {
            float requested = (float)(random.NextDouble() * 400.0 - 200.0);
            float result = CameraZoomPolicy.ClampZoom(requested, 1f, 12f);
            Assert.That(result, Is.InRange(1f, 12f));
        }
    }
}

I would separately add tests for NaN, positive infinity, negative infinity, and invalid bounds after deciding the desired policy for each. The model should not silently decide whether those inputs clamp, throw, log, or return a fallback. That is exactly the kind of product decision that becomes accidental when developers accept a generated fixture without reviewing its assumptions.

Seeded generation matters because failures must be reproducible. If a random test fails only once and cannot report its seed or input sequence, diagnosis becomes unnecessarily expensive. I also ask AI to name each case in behavioral language and explain which contract clause it protects. If it cannot explain the connection, the test may be decorative rather than useful.

Finally, I keep test generation and implementation review as separate passes. Asking the same conversation to invent a function and immediately certify it encourages shared assumptions. A fresh pass that receives the contract and public interface, but not the implementation rationale, has a better chance of challenging the code.

How do you detect false confidence in AI-generated tests?

The fastest check is to make the production code wrong on purpose. Change a comparison, remove a clamp, return a constant, skip an event, or invert a condition. The relevant test should fail, and its message should point toward the violated behavior. Then restore the code and confirm that the test passes. This red-green exercise is basic, but it catches an alarming number of generated tests that execute code without meaningfully constraining it.

I inspect every assertion for strength. Assert.NotNull can be appropriate, but it says little about content. Verifying that a method was called does not prove that the resulting state is correct. A tolerance wide enough to absorb every plausible error is not a safety net. Neither is a test that catches all exceptions, logs them, and continues. Generated tests sometimes contain these patterns because they make unstable code appear cooperative.

Conditional assertions deserve special suspicion. If a test says, in effect, assert the result only when the result exists, the most important failure may skip the assertion. Setup code can produce the same issue by returning early when an asset, object, or platform capability is missing. A skipped test should be reported explicitly, not converted into a pass.

I also check whether mocks have replaced the behavior under examination. Mocking a storage service is useful when testing a UI reaction to failure. It is useless when the actual question is whether serialization survives a version change. The dependency boundary should follow the risk. AI cannot choose that boundary reliably unless the prompt explains what evidence is required.

Coverage belongs at the end of this review, not the beginning. Line and branch coverage can reveal untouched areas, but high coverage does not prove strong oracles. I would rather have a smaller suite that kills deliberate defects than a large generated suite that merely visits methods. Passing tests earn trust through demonstrated sensitivity, readable intent, and stable reproduction, not through volume or polished naming.

Where do property testing, fuzzing, and mutation fit into an AI workflow?

Example-based tests are easy to understand, but they cover only selected points. Property testing describes rules that should hold across a larger input space. A clamped value remains within bounds. Applying a normalization operation twice produces the same result as applying it once. Serializing and then deserializing supported data preserves defined fields. AI is useful for proposing properties because it can restate the contract in several forms, but a developer must reject properties that are mathematically tidy and productually irrelevant.

Fuzzing extends the search with generated values and event sequences. In Unity, useful candidates include NaN, infinities, zero-length vectors, missing references, duplicated touch identifiers, rapid enable and disable cycles, interrupted scene operations, and unusual frame timing. The generator needs fixed seeds, bounded execution, and a clear failure report. Uncontrolled randomness inside CI creates intermittent noise, which trains teams to ignore exactly the failures automation should expose.

Stateful systems benefit from generated sequences rather than isolated values. An input component might receive press, disable, enable, move, cancel, and release events in unexpected orders. AI can propose a compact state model and candidate transitions. I still compare that model with Unity's actual lifecycle and the product's intended recovery behavior. Otherwise, the generated sequence tests an imaginary system very thoroughly.

Mutation testing turns the question around. Instead of asking how much production code a suite executes, it introduces small defects and measures whether tests notice. Full mutation tooling is not always practical in a Unity pipeline, but manual mutations on critical rules provide immediate value. Replace less-than with less-than-or-equal, remove a state reset, or bypass a validation branch. Surviving mutations reveal weak assertions or missing cases.

AI can help classify surviving mutations and suggest the smallest test that should kill each one. It should not automatically add dozens of overlapping tests without review. The goal is improved fault detection, not a larger test directory. Property testing, fuzzing, and mutation are strongest when they remain deterministic, traceable to a contract, and focused on failures that matter to the shipped experience.

What does a practical AI testing workflow look like in 2026?

My preferred workflow begins with a short human-written test charter. It names the feature, important behaviors, major failure costs, supported environments, and explicit unknowns. I ask AI to challenge that charter by proposing omitted boundaries and state transitions. I accept, edit, or reject those suggestions before any fixture is generated. This prevents the first plausible model response from quietly becoming the specification.

Next, I choose the test layer and create the smallest seam that can expose the behavior. The AI may draft Edit Mode cases, Play Mode scaffolding, test data builders, or deterministic generators. Every generated file goes through the same review as production code. It must compile without hidden dependencies, clean up created objects, avoid arbitrary waits, produce useful failure messages, and map each assertion to a documented rule.

Before merging, I run the relevant tests against an intentional defect. In continuous integration, fast deterministic checks run first so failures arrive quickly. Play Mode suites follow where lifecycle behavior matters. Builds and device checks cover platform risks on an appropriate schedule. Logs, screenshots, seeds, and other failure artifacts must be retained. An AI agent saying that tests passed is not evidence unless the pipeline records what ran and where.

The 2025 to 2026 generation of coding agents can edit multiple files, invoke tools, and react to errors. That makes permission boundaries important. I am comfortable letting an agent draft tests and run local commands in a controlled workspace. I am less comfortable letting it rewrite contracts, weaken assertions, update snapshots, and approve its own changes in one autonomous loop. Those actions can optimize the metric while erasing the behavior the metric was meant to protect.

The final ownership stays human. A developer should be able to explain what each critical test proves, which environment it covers, and what remains untested. AI can lower the cost of constructing cases and maintaining repetitive fixtures. It cannot remove the need for judgment. Used this way, AI does not replace test engineering. It gives disciplined test engineering more reach, while the team keeps control of correctness.

References & Further Reading

How to Evaluate Game Development Opportunities Before Saying Yes

Anthony KOZAK — Mon, 28 Sep 2026 08:02:08 +0000

A game development opportunity can look excellent on paper and still move your career in the wrong direction. A recognizable company, an impressive title, or a fashionable technology does not automatically produce useful experience. After 16 years across studio development, Unity products, and client work, I have learned to evaluate opportunities as bundles of tradeoffs. The right question is not simply, "Is this a good project?" It is, "What will this project leave me with when it ends?"

Key Takeaways

Evaluate opportunities by what they add to your skills, evidence, relationships, income, and sustainability.
A prestigious name is useful only when the underlying responsibilities help you grow.
Unknown scope, ownership, or decision authority should lower an opportunity's score.
Build a clear specialty, but keep adjacent skills that preserve your options.
Review your career portfolio every six months instead of waiting for a crisis.

What Are You Actually Buying With the Next Project?

When people compare jobs or contracts, they usually begin with salary, rate, title, and company name. Those factors matter, but they are only the visible part of the transaction. Every opportunity also purchases some combination of technical skill, production judgment, professional relationships, public evidence, creative energy, and future options. It consumes time in return. If you do not identify that exchange clearly, you can spend a year becoming more experienced without becoming more valuable.

I think of an opportunity as a package with five accounts: craft, evidence, relationships, compensation, and sustainability. Craft is what you will learn to do better. Evidence is what you can later demonstrate or explain, subject to confidentiality. Relationships are the people who may trust your work again. Compensation is the complete economic return, not just the headline number. Sustainability covers schedule, health, attention, and whether the work leaves room for a life outside production.

In 2016, I worked as a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal. It shipped as a VR flight game on PSVR, Oculus Rift, and HTC Vive. That credit had a recognizable studio name, but the durable career value was more specific: I had participated in shipping gameplay across multiple VR platforms. The title alone would have been a weak summary. The platform constraints, production decisions, and finished result were the assets that remained useful.

This distinction matters even more in 2025 and 2026. Tools, AI-assisted workflows, and platform priorities are changing quickly. A role built around operating one narrow process can lose value when that process changes. Before accepting work, write down what you expect to retain after the project ends. If the honest answer is only a line on your resume, investigate further.

How Should You Score an Opportunity Before Saying Yes?

I use a lightweight scorecard to force vague enthusiasm into explicit assumptions. Score craft, evidence, relationships, compensation, and sustainability from 0 to 5. Then write one sentence justifying every score. The explanation matters more than the number. "This seems exciting" is not evidence. "I will own a complete input feature, receive code review, and participate in platform testing" is concrete enough to investigate.

The weights should reflect your current situation. Someone entering the industry may prioritize learning and credible collaborators. A developer with dependents may assign more weight to predictable compensation and schedule. An experienced specialist may accept lower novelty when the project deepens a valuable niche. Here is a small Unity ScriptableObject version of the worksheet. A spreadsheet or notebook works just as well.

using UnityEngine;

[CreateAssetMenu(menuName = "Career/Opportunity Score")]
public sealed class OpportunityScore : ScriptableObject
{
    [Range(0, 5)] public int craft;
    [Range(0, 5)] public int evidence;
    [Range(0, 5)] public int relationships;
    [Range(0, 5)] public int compensation;
    [Range(0, 5)] public int sustainability;

    public float WeightedTotal()
    {
        return craft * 0.30f
             + evidence * 0.20f
             + relationships * 0.15f
             + compensation * 0.20f
             + sustainability * 0.15f;
    }
}

Do not let the total make the decision for you. Its purpose is to expose imbalance. A financially attractive contract with a sustainability score of 1 may still be correct for a short, controlled period. A fascinating prototype with unclear ownership and no budget may not be. The score lets you name the sacrifice instead of discovering it halfway through production.

I also treat unknowns as risks, not neutral values. If nobody can explain who approves the feature, what "done" means, or whether you can discuss the work later, lower the relevant score until you get an answer. Optimism should not fill gaps in scope. Good opportunities usually become clearer under specific questions. Weak ones often rely on excitement to prevent those questions.

When Is a Prestigious Name Less Valuable Than the Work?

A respected studio or client can create useful context, but prestige is a multiplier, not a substitute for responsibility. Ask what you will actually own, which decisions you will make, who will review your work, and whether the project is likely to ship. A famous logo attached to repetitive implementation may produce less career growth than a smaller project where you solve a complete problem and can explain the result.

Eagle Flight Arcade is my only AAA studio credit. I value it, but I do not build my professional identity around pretending it represents a long catalog of major studio titles. Its value comes from a specific shipped game, a specific gameplay role, a specific year, and three named VR platforms. Precision is more credible than trying to inflate a recognizable credit into a larger story.

The same principle applies outside studios. Touch Camera PRO and Touch Camera LITE communicate something different from a company name. They are concrete Unity Asset Store products built around camera control. Assets Manager, Tutorial Engine, Responsive UI Pro, and Level Designer point toward other kinds of ownership. A product requires you to define a problem, package a solution, communicate its use, and live with technical decisions after release. That experience can be highly legible even without a famous employer.

When evaluating prestige, separate access from substance. A name may introduce you to stronger peers, mature processes, difficult platforms, or future interviews. Those are real benefits. However, ask whether you will be close enough to the meaningful work to gain them. If the role hides ownership, offers no feedback, or keeps you far from decisions, the brand may decorate your resume without materially changing your capabilities. Choose the responsibilities first and use the name as supporting context.

How Can You Tell Whether a Role Will Expand Your Range?

Useful range does not mean touching every tool once. It means adding adjacent capabilities that let you own a larger outcome. For a Unity gameplay programmer, productive adjacency might include input systems, profiling, UI integration, build pipelines, editor tooling, or platform constraints. Random tasks create busyness. Adjacent tasks strengthen the same professional story while reducing your dependence on someone else for every boundary decision.

Before joining a project, draw three circles. The first contains work you can already perform reliably. The second contains tasks that stretch you with available support. The third contains responsibilities so unfamiliar that delivery would become guesswork. A strong opportunity spends most of its time in the first two circles. If everything is familiar, growth may stall. If everything is in the third circle, the project may be transferring unmanaged risk to you.

My freelance and client work has included Meta Spirit Sling, Loreal Viva Tech 2024, Mindsight Journey, Rabbids Coding, RE-PAIR, and other projects from the approved list of work I can name. Variety by itself is not the lesson. Different contexts are valuable when they sharpen transferable judgment: clarifying requirements, choosing an appropriate implementation, communicating constraints, and finishing work another person can use. Those capabilities survive changes in genre and platform.

Ask who will help when you reach the edge of your experience. Is there a senior developer reviewing architecture? Can you speak directly with design, art, QA, or stakeholders? Will you see production feedback, or only receive isolated tickets? Growth requires a feedback loop. A role can involve advanced technology and still teach very little if you never learn whether your decisions worked. Look for access to consequences, not just access to tools.

Which Career Red Flags Should Make You Walk Away?

The first red flag is strategic ambiguity disguised as flexibility. Early prototypes naturally contain uncertainty, but the project should still have a reason to exist, a person who can make decisions, and a near-term definition of success. If every stakeholder can redirect the work and nobody can accept it, you are not being offered creative freedom. You are being asked to absorb organizational confusion.

The second red flag is unlimited scope attached to fixed expectations. Listen for phrases such as "production ready" without target platforms, "multiplayer" without a networking model, or "AI powered" without a plan for evaluation and failure. In 2026, AI language deserves particular scrutiny. Generated code and content can accelerate exploration, but they do not remove integration, testing, security, licensing, or maintenance responsibilities. Ask who owns verification when generated output is wrong.

The third red flag is blocked evidence. Confidentiality is normal, especially in client work, but you should understand the rules before starting. Can you name the project after release? Can you describe your responsibilities without exposing protected information? Will you receive a formal credit? A project may still be worthwhile when every answer is no, but its compensation and learning value need to justify the invisible work.

Finally, watch how the people involved respond to reasonable questions. Clear leaders may not know every answer, but they can distinguish decisions from assumptions. Weak opportunities often rely on urgency, flattery, or fear of missing out. I have learned not to confuse a fast request with a well-defined need. Walking away is appropriate when payment terms are evasive, ownership is disputed, access is withheld, or the schedule assumes permanent emergency. A career is not protected by accepting every invitation. It is protected by refusing arrangements whose failure pattern is already visible.

How Do You Balance Specialization With Career Optionality?

Specialization makes it easier for people to remember why they should call you. Optionality keeps that specialty from becoming a cage. My flagship Unity Asset Store product is Touch Camera PRO, so camera control is an obvious part of my public technical identity. That anchor is useful. It does not require me to describe every other capability as unrelated or to accept only one category of work forever.

I prefer a hub-and-spoke model. The hub is a problem you can solve deeply and repeatedly. The spokes are adjacent skills that make the hub more useful. A camera controller touches input, interaction, UI, platform behavior, serialization, documentation, and user expectations. Products such as Easy Tooltips And Overlays, Home Designer, Layered Scene Screenshot, and Floor Plan Designer sit in different categories, but they still exercise the broader ability to turn Unity workflows into usable systems.

Optionality should be deliberate. Choose one adjacent area each year that improves your ability to deliver your core work. A gameplay programmer might deepen profiling. A technical designer might learn editor scripting. A VR developer might strengthen OpenXR debugging or accessibility knowledge. Avoid collecting technologies only because job posts mention them. A shallow list of frameworks is less defensible than a connected set of capabilities that helps you solve a complete class of problems.

The test is simple: can you explain your specialty in one sentence, then describe three nearby problems you can also own? If you cannot name the specialty, your positioning may be too broad. If you cannot name adjacent problems, it may be too brittle. Career resilience comes from being recognizable without being trapped. I want clients and collaborators to understand my strongest value quickly, while still seeing enough range to trust me with the boundaries around that value.

What Should You Negotiate Besides Money?

Compensation deserves direct discussion, but the shape of the work can affect your career as much as the amount. Negotiate scope, ownership, communication access, acceptance criteria, credit, portfolio permissions, schedule, and the conditions for ending the engagement. Employees may express these topics through role expectations and management conversations. Freelancers may put them into a statement of work. The vocabulary changes, but the underlying risks do not.

Start with decision authority. If you are accountable for a system, clarify which technical decisions you control and who can override them. Then define acceptance. A feature is not complete because someone says it should "feel polished." Identify target devices, supported scenarios, review steps, and known exclusions. This protects delivery and reveals whether the organization has thought through the request.

Next, discuss feedback and access. Will you speak with the people using or testing the result? Will code review happen regularly? Can you see crash reports, performance data, or QA findings relevant to your work? Feedback access turns execution into learning. Without it, you may repeat the same assumptions while believing that time alone is producing expertise.

Finally, negotiate the exit. Determine what happens when priorities change, milestones slip, or the project pauses. Clarify payment for completed work, handoff expectations, source access, and ongoing support. For products and plugins, support obligations can outlive initial development, so maintenance boundaries matter too. These conversations are not pessimistic. They are production planning. A healthy opportunity can survive being described precisely. If asking for precision damages the relationship before work begins, that is useful information you received early.

How Should You Review Your Career Portfolio Every Six Months?

I recommend a six-month review because annual planning is too slow for a volatile industry, while weekly career analysis creates noise. List every meaningful project, product, learning investment, and professional relationship from the period. For each one, record what improved, what became demonstrable, what it cost, and whether you would choose it again with the information you now have.

Then look for concentration risk. Is all your recent work tied to one platform, one client, one tool, or one type of task? Concentration can be intentional when it builds a valuable specialty. It becomes dangerous when it happens accidentally and leaves no transferable explanation. Also check for fragmentation. If every project points in a different direction, decide which thread deserves to become your hub.

Your review should end with decisions, not observations. Continue one activity that is compounding. Stop one activity that consumes attention without improving income, skill, relationships, or evidence. Start one bounded experiment that tests a career assumption. The experiment might be a small tool, a focused technical study, a talk, a prototype, or guided learning. If you need external structure, one-on-one Unity mentoring and practical team training can help turn a vague gap into a concrete plan.

Keep the review honest by separating status from progress. A new title can feel like progress while narrowing your responsibilities. A modest project can look unimportant while teaching you to own an entire production problem. In 2025 and 2026, tools and workflows are moving too quickly to outsource this judgment to job titles. Your career is a portfolio of capabilities, trust, and completed decisions. Review that portfolio before the market forces you to.

References & Further Reading

How to Architect Hardware-Resilient VR/XR Interaction in Unity

Anthony KOZAK — Mon, 14 Sep 2026 08:02:43 +0000

VR/XR hardware changes faster than most production schedules. A Unity project can begin with controllers, add hand tracking, move to a different runtime, and encounter new display or tracking constraints before launch. My answer is not another layer of device checks. It is an architecture that separates user intention, interaction rules, hardware capabilities, and platform delivery. After 16 years in game development, including shipping Eagle Flight Arcade at Ubisoft Montreal in 2016 and working on modern XR client projects, I consider that separation one of the best investments an XR team can make.

Key Takeaways

Design around capabilities and user intentions, not headset model names.
Keep OpenXR and toolkit APIs at the platform boundary.
Give controllers, hands, and gaze appropriate interaction affordances.
Treat frame timing, hardware testing, and telemetry as architectural concerns.
Define fallbacks before optional XR features enter production.

Why does device-first XR architecture become expensive?

VR projects often begin with a deceptively reasonable question: which headset are we targeting? The dangerous next step is allowing that answer to shape every gameplay script. Code starts asking whether a particular controller exists, whether a specific runtime is active, or whether the current headset supports a named vendor feature. Those checks spread through tools, tutorials, UI, and game logic. When hardware requirements change, the project does not have one platform migration. It has dozens of small migrations hidden across scenes and prefabs.

I saw the importance of stable runtime behavior while working as a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016. That VR flight game shipped on PSVR, Oculus Rift, and HTC Vive. The devices were different, but the player-facing rules still needed to feel like one coherent game. The lesson I carried forward was not that every platform should behave identically. It was that hardware differences should enter the project through deliberate boundaries rather than leak into every feature.

OpenXR helps, but it is not a universal compatibility button. It standardizes communication with XR runtimes and defines interaction profiles, while hardware vendors can still expose optional extensions and different physical capabilities. One device may provide controllers and tracked hands. Another may add eye tracking. Tracking quality, refresh rates, permissions, boundary behavior, and system gestures can also differ.

I prefer capability-first design. Gameplay asks whether precise pointing, direct manipulation, haptics, or a confirmation action is available. A platform adapter decides how the active hardware provides it. This converts hardware changes from broad rewrites into contained adapter and presentation work. It also forces the team to decide what is essential, what is enhanced, and what requires a fallback before content depends on it.

Where should OpenXR end and game-specific code begin?

I treat OpenXR as infrastructure, not as the language of the game. The same applies to Unity's XR Interaction Toolkit. Both can provide valuable implementations, but a puzzle, tool, menu, or training workflow should not need to know which OpenXR interaction profile produced an action. If game code directly queries runtime paths or toolkit components, package decisions become gameplay dependencies.

A practical Unity project can use three layers. The platform layer owns OpenXR configuration, action bindings, tracking origins, runtime lifecycle events, and optional extensions. The interaction layer translates poses and actions into project concepts such as hover, select, grab, use, confirm, or cancel. The domain layer decides what those concepts mean. For example, the domain decides whether a component can be picked up while locked. It should not decide whether the request came from a trigger, pinch, gaze dwell, or test script.

This boundary also gives prefabs clearer responsibilities. A tracked controller prefab can contain pose drivers, render models, rays, haptics, and toolkit interactors. An interactable object can expose its states and rules without searching for a named controller in the scene. Scene code can then replace the controller presentation without rewriting the object. That matters when a prototype grows into a product with tutorials, accessibility settings, and multiple hardware configurations.

The boundary does not require wrapping every Unity API. Over-abstraction is another failure mode. I wrap the concepts likely to vary across hardware or tooling, while leaving stable engine concepts alone. Transform, collider, and animation code rarely need a custom facade. Input semantics, tracked-pose availability, haptic requests, and runtime capabilities usually do.

For teams that need help establishing this boundary, my Unity VR and MR development and performance optimization work focuses on production architecture as well as headset implementation. The goal is not abstraction for its own sake. It is keeping platform volatility away from the rules that make the experience valuable.

How can XR input represent intention instead of buttons?

The most durable input abstraction is an intention with temporal state. A button name is hardware vocabulary. An intention such as grab, use, confirm, or cancel is application vocabulary. The state must still preserve information such as whether the intention began this frame, remains active, or ended. Without that timing, gameplay scripts eventually return to polling raw controls.

It is important not to make the intentions too broad. A single generic select action can become ambiguous when the same hand can point at UI, grab an object, and operate a tool. I define a small vocabulary based on the experience's actual interaction model. I also keep context resolution outside the hardware adapter. The adapter reports intention, while interaction logic decides which eligible target receives it.

A minimal boundary can be expressed without referencing a controller type:

using UnityEngine;

public enum XRIntent

{

    Grab,

    Use,

    Confirm,

    Cancel

}

public readonly struct XRIntentState

{

    public readonly bool IsHeld;

    public readonly bool PressedThisFrame;

    public readonly bool ReleasedThisFrame;

public XRIntentState(bool isHeld, bool pressed, bool released)
{
    IsHeld = isHeld;
    PressedThisFrame = pressed;
    ReleasedThisFrame = released;
}


}

public interface IXRIntentSource

{

    XRIntentState Read(XRIntent intent);

}

public sealed class XRToolDriver : MonoBehaviour

{

    private IXRIntentSource input;

public void Initialize(IXRIntentSource inputSource)
{
    input = inputSource;
}

private void Update()
{
    XRIntentState use = input.Read(XRIntent.Use);

    if (use.PressedThisFrame)
        BeginUsingTool();
    else if (use.ReleasedThisFrame)
        StopUsingTool();
}

private void BeginUsingTool() { }
private void StopUsingTool() { }


}

The production implementation can read Unity Input System actions, hand gestures, simulated input, or recorded test data. The consumer does not change. Notice that the interface does not promise haptics or even a tracked hand. Those are separate capabilities. Mixing output features into input state makes fallback logic harder and encourages assumptions that every source has a physical controller.

When hand tracking or a new controller arrives, I add or update an intention source and then validate the interaction presentation. I do not rewrite every tool. This approach also makes input recording practical because a test can replay meaningful actions instead of reproducing vendor-specific button paths.

How should controllers, hands, and gaze share an interaction model?

Controllers, hands, and gaze can share semantics, but they should not be forced to share identical mechanics. A controller offers discrete buttons, predictable grip poses, and often haptic feedback. Hand tracking infers gestures from changing joint data and can lose confidence during occlusion. Gaze can indicate attention efficiently, but looking at something is not always consent to activate it. Treating these sources as interchangeable pointers produces fragile and sometimes exhausting interactions.

I begin by separating targeting, commitment, manipulation, and feedback. Targeting answers what the user may be addressing. Commitment confirms an intentional action. Manipulation describes continuous movement or adjustment. Feedback tells the user what the system understood. A controller ray might target an object, a trigger might commit, controller motion might manipulate it, and vibration might confirm contact. With hands, a pinch may commit while visual and audio feedback replace unavailable haptics. With gaze, I usually require a second signal or a carefully designed dwell rather than activating everything the user observes.

The shared layer should describe the result: an object became targeted, selected, grabbed, adjusted, or released. The source-specific layer should own gesture thresholds, pose stabilization, ray origin, dwell timing, and feedback options. This keeps application rules consistent without pretending that all modalities have the same reliability or ergonomics.

Capabilities can also change during a session. Controllers may sleep, hands may leave the tracked area, or permission for an optional feature may be denied. A robust interaction manager announces source availability and performs explicit transitions. It should clear stale hover states, release or safely preserve manipulated objects, and update tutorials or prompts. Silent switching is risky because the user may not know why an interaction stopped responding.

I also avoid collecting raw gaze or hand data by default. If a feature only needs a confirmed selection, store that event rather than a detailed biometric stream. Capability-first architecture makes this easier because domain analytics receive meaningful actions, not unrestricted sensor data.

Why must frame timing be part of XR architecture?

Performance is not a final optimization pass in VR. It affects which rendering features, physics rules, interaction techniques, and content densities are safe to build. At 72 Hz, a frame has about 13.9 milliseconds. At 90 Hz, it has about 11.1 milliseconds. At 120 Hz, it has about 8.3 milliseconds. That total includes CPU and GPU work, while the runtime also has presentation and tracking responsibilities. A feature that appears inexpensive in the Editor can still break frame pacing on a standalone headset.

I therefore make performance targets part of system interfaces. An interaction system should avoid uncontrolled physics queries per object, repeated scene-wide searches, and allocations during continuous hand or ray updates. Visual feedback should use pooled or persistent objects instead of creating effects every time hover changes. UI, outlines, transparent materials, shadows, and live previews all need costs that remain predictable when several interactors and targets are active.

The correct target is not merely a good average frame rate. Spikes matter because interaction events often trigger animation, audio, haptics, physics, and UI at the same moment. I profile frame-time distributions and investigate repeatable spikes around grabbing, releasing, opening menus, loading assets, and changing tracking modes. CPU and GPU timings must be considered separately because reducing scripts will not fix an expensive fragment shader.

Device testing should use release-like builds, the intended render path, and representative content. Thermal behavior also matters during longer standalone sessions. Dynamic resolution, foveation where supported, simplified effects, and quality tiers are useful controls, but they should protect an already disciplined frame budget rather than excuse an unbounded scene.

In 2025 and 2026, XR hardware continues to span standalone and PC-connected systems with different performance envelopes. A shared architecture should expose quality capabilities and chosen refresh targets without allowing every feature to invent its own device list.

How can teams test XR interactions without making the headset a bottleneck?

A headset is mandatory for validating an XR experience, but it should not be mandatory for every code change. If interaction rules consume intentions and poses through stable boundaries, much of the behavior can run in Edit Mode tests, Play Mode tests, or a desktop simulation. This shortens iteration and makes failures easier to reproduce than a verbal report about what happened inside a headset.

I divide testing into four layers. Domain tests verify rules such as whether an object is selectable, whether a two-step operation can be cancelled, and whether state survives an interruption. Interaction tests feed synthetic hover, selection, grab, and release sequences into components. Integration tests verify Unity Input System, XR toolkit, and OpenXR adapter configuration. Finally, device tests validate tracking, ergonomics, rendering, frame pacing, boundaries, permissions, and runtime lifecycle behavior.

Recorded intention sequences are particularly useful. A tester can capture a meaningful series of interactions, and the team can replay the sequence against later builds. This does not reproduce every tracking nuance, but it can catch state regressions such as an object remaining locked after input disappears. Synthetic tests should also cover ugly transitions: a source disconnecting while grabbing, tracking becoming unavailable during a confirmation, application focus changing, and the active modality switching.

The hardware matrix still needs discipline. I list supported runtime, device class, input modality, refresh configuration, and required optional features. I then identify which combinations receive full release coverage and which are unsupported. OpenXR does not remove this matrix. It makes the platform boundary more consistent, which should make the matrix easier to execute.

Real headset sessions should focus on qualities simulation cannot answer. Is a target readable at the expected distance? Can users discover the affordance? Does the interaction remain comfortable at different heights and orientations? Does tracking degrade around the intended physical motion? Automation protects logic, while human testing protects the embodied experience. A mature XR workflow needs both.

What should XR telemetry reveal after deployment?

XR bugs are often described through symptoms: an object would not grab, a hand disappeared, the view stuttered, or a menu stopped responding. Useful telemetry must provide context without collecting excessive sensor data. I want to know the application version, active XR runtime, broad device class, selected refresh rate, enabled capabilities, active interaction source, scene, and the semantic event that failed. Those fields are usually more actionable than a raw stream of poses.

Interaction state machines should emit structured events for transitions and rejected actions. If a grab request fails because the object is locked, report the reason. If a source becomes unavailable, record the transition and whether an active manipulation required recovery. If an adapter cannot bind a required intention, surface that during startup instead of waiting for a user to discover an inert control.

Performance telemetry should emphasize frame-time distributions and spikes rather than only average frames per second. Track CPU-bound and GPU-bound intervals where the platform exposes reliable measurements. Associate severe spikes with scene changes, quality changes, and high-level interactions. Avoid logging every frame to a remote service. Aggregate locally, sample responsibly, and send only what is needed to diagnose production behavior.

Privacy must be designed with the schema. Hand joints, room geometry, camera imagery, microphone input, and gaze can be sensitive. If a product needs to know that a user selected a button with gaze, the semantic selection event may be enough. Data collection should have a defined purpose, suitable consent, limited retention, and secure handling. The architecture should make the minimal path the easiest path.

Across freelance and client work, including Meta Spirit Sling and Loreal Viva Tech 2024, I have found that deployment context can differ as much as hardware. A public installation, standalone product, and guided demonstration may need different diagnostics. A stable event vocabulary lets telemetry adapt without embedding analytics calls throughout interaction code.

What should an XR team lock down before content production scales?

Before artists and designers produce large amounts of interactive content, I want a written platform contract. It does not need to predict every future headset. It needs to define the project's current promises and what happens when a capability is missing. Otherwise, each feature author makes a local assumption, and those assumptions become expensive dependencies.

List supported runtimes, device classes, and interaction modalities.
Define required capabilities and optional enhancements.
Document fallback, interruption, and source-switching behavior.
Set refresh targets and CPU and GPU frame budgets.
Specify the device matrix required for release approval.

I also build one representative interaction slice before scaling content. It should include targeting, commitment, manipulation, feedback, interruption recovery, tutorial prompts, performance profiling, and structured diagnostics. This is not a visual showcase. It is evidence that the architecture survives a realistic workflow. Content templates and prefabs should come from that tested slice rather than from isolated prototypes.

Ownership matters. Someone must control OpenXR settings and platform adapters. Someone must define interaction semantics. Someone must maintain performance capture and hardware coverage. On a small team, one person may hold several roles, but the responsibilities should still be explicit. Package upgrades and runtime changes should pass through a branch with device validation instead of entering production as casual dependency updates.

My strongest recommendation is to decide what remains stable. Hardware adapters will change. Bindings and extensions will change. Rendering options will change. The domain meaning of selecting, using, confirming, and cancelling should change far less often. Put effort into that stable center, then keep platform volatility at the edges.

That is how I would build an XR project in 2026. OpenXR provides a valuable foundation, but durable production comes from capability boundaries, semantic interactions, measured frame timing, deliberate fallbacks, and repeatable testing. Those practices let a Unity project adopt new hardware without turning every new device into a rewrite.

References & Further Reading

Web Performance Budgets: Lessons From 16 Years in Games

Anthony KOZAK — Mon, 07 Sep 2026 08:02:13 +0000

After 16 years in game development, I see web performance differently from many web teams. Working as a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016 taught me to think in budgets, feedback loops, and worst-case behavior. Those ideas apply just as strongly to a product page, account portal, or browser-based application. A website does not need a frame counter to feel slow.

Key Takeaways

Treat loading time, interaction latency, JavaScript, and media as limited budgets.
Measure real user journeys instead of optimizing a single benchmark score.
Give every asynchronous interaction explicit loading, success, empty, failure, and cancellation states.
Design useful progress and graceful degradation before adding visual polish.
Automate performance checks, but validate important flows on physical devices.

Why Should Web Teams Think in Frame Budgets?

Games taught me that performance is not an abstract quality. It is a recurring deadline. At 60 frames per second, the application has roughly 16.7 milliseconds to process input, update its world, prepare rendering, and present the result. At 90 Hz, a common target in VR, that window drops to about 11.1 milliseconds. Miss the deadline repeatedly and the player feels it immediately.

Web applications have less obvious deadlines, but users still perceive them. A button should acknowledge input quickly. A route should reveal meaningful content before attention disappears. Scrolling should remain stable while images and advertisements arrive. Search results should not freeze the interface while filtering. The browser may not display a dropped-frame warning, yet hesitation and visual instability communicate the same message: the software is not keeping up.

I therefore prefer explicit budgets to requests such as make it fast. A project can define limits for initial JavaScript, image weight, font files, third-party scripts, server response time, and interaction latency. The exact limits depend on the audience and product. A public marketing page, an internal planning tool, and a rich browser editor should not inherit the same numbers without discussion.

The important part is forcing tradeoffs into the open. If a new analytics package consumes a meaningful part of the script budget, the team should decide whether its value justifies that cost. If an autoplaying video dominates the loading budget, that decision belongs in product review rather than being discovered during final optimization.

This mindset also changes sequencing. I do not build an unlimited experience and hope to optimize it later. I reserve capacity for features, identify the weakest realistic device, and test as the product grows. Performance becomes a design constraint like screen size, accessibility, or localization. That approach is less glamorous than a last-minute optimization sprint, but it is far more reliable.

What Should You Measure Before Optimizing a Web App?

The first performance mistake is measuring whatever a tool makes easiest rather than what matters to the user. A perfect score on an isolated page does not prove that account creation, checkout, file upload, or search feels good. Before changing code, I write down the important journeys and the moments where users need feedback. Those moments become the foundation of the measurement plan.

Core Web Vitals provide a useful shared vocabulary in 2025 and 2026. Largest Contentful Paint measures when the main visible content appears. Interaction to Next Paint measures responsiveness after user input. Cumulative Layout Shift measures unexpected movement. Google's good thresholds are an LCP within 2.5 seconds, an INP within 200 milliseconds, and a CLS of 0.1 or less, assessed at the 75th percentile.

Those metrics are a starting point, not a complete diagnosis. I also want server response time, transferred bytes, JavaScript execution time, long tasks, API error rates, and timing for product-specific actions. For an editor, opening and saving a document may matter more than the landing page. For an account system, authentication and form submission deserve dedicated instrumentation.

Laboratory and field measurements answer different questions. Lighthouse gives repeatable evidence during development, although scores can vary with configuration and environment. Real user monitoring reveals the devices, networks, routes, and regressions affecting actual visitors. Synthetic testing is controlled. Field data is representative. Mature teams need both rather than arguing that one invalidates the other.

I also segment results instead of averaging everything together. A fast desktop can hide a poor mobile experience, and a cached repeat visit can hide an expensive first load. Compare mobile with desktop, new visits with returning visits, and key routes with the site-wide summary. Optimization begins when the team can name the affected users, the delayed action, and the work responsible for that delay.

How Can Loading Screens Communicate Real Progress?

Game developers spend a great deal of time hiding or reorganizing loading. The same problem appears on the web whenever an application fetches records, initializes an editor, processes a payment, uploads a file, or waits for generated content. The worst response is often an unexplained spinner. It proves that animation still works, but it says nothing about whether the operation is progressing or stuck.

I prefer the earliest possible useful result. Render the page shell, heading, navigation, and cached information before optional content. Prioritize the image or data that establishes context. Defer analytics, recommendations, secondary panels, and decorative motion. This is similar to loading the playable or visible part of a game scene before preparing content the player cannot reach yet.

Progress indicators should reflect what the system knows. Use determinate progress for an upload when the client knows total bytes. Use named stages when the process has clear steps, such as uploading, validating, and processing. Use an indeterminate indicator only when progress cannot be estimated honestly. A fabricated percentage that stalls at 99 percent can damage trust more than a clear status message.

Skeleton layouts are useful when they preserve the final geometry, but they are not free performance. Complex shimmer effects can consume rendering time, and misleading placeholders create a second layout when the actual content differs. Reserve dimensions for media, keep placeholders simple, and replace each region independently. Partial success is usually better than holding the whole page behind one global loading state.

Finally, give slow operations an escape route. Users should be able to cancel an upload, navigate away safely, retry a failed request, or continue with another task when the workflow allows it. Loading design is not merely cosmetic. It defines how the product behaves under latency, which is why I treat it as part of application architecture rather than a final animation pass.

Why Does Every Async Interaction Need Explicit States?

Many web bugs come from pretending an asynchronous action has only two states: not started and done. Real operations can be idle, waiting, successful, empty, failed, cancelled, stale, or retrying. When those possibilities remain implicit, interfaces develop duplicate submissions, buttons that never re-enable, stale data that overwrites fresh data, and error messages that vanish before anyone can read them.

I learned to value explicit state machines through gameplay programming and through maintaining configurable Unity products such as Touch Camera PRO. A camera controller, input interaction, or network-backed interface becomes easier to reason about when transitions are named. The same model applies to React components, server-rendered forms, browser editors, and background jobs. Framework syntax changes, but state does not disappear.

public enum AsyncState
{
    Idle,
    Working,
    Succeeded,
    Empty,
    Failed
}

public sealed class AsyncOperationModel<T>
{
    public AsyncState State { get; private set; } = AsyncState.Idle;
    public T? Data { get; private set; }
    public string? Error { get; private set; }

    public async Task RunAsync(
        Func<CancellationToken, Task<T>> operation,
        CancellationToken token)
    {
        State = AsyncState.Working;
        Data = default;
        Error = null;

        try
        {
            Data = await operation(token);
            State = Data is null
                ? AsyncState.Empty
                : AsyncState.Succeeded;
        }
        catch (OperationCanceledException)
        {
            State = AsyncState.Idle;
        }
        catch (Exception ex)
        {
            Error = ex.Message;
            State = AsyncState.Failed;
        }
    }
}

This C# example is deliberately small. In production, I would separate a safe user-facing message from diagnostic details, record request identifiers, and define whether existing data remains visible during refresh. I would also prevent an older request from replacing a newer result. The important lesson is that rendering should follow a known state rather than infer one from a scattered combination of nullable values and Boolean flags.

Explicit states also improve product conversations. Designers can specify the empty view. Writers can prepare failure messages. QA can test cancellation and retry. Developers can decide whether an action is idempotent before enabling automatic recovery. A feature is not complete because its successful request works on a fast connection. It is complete when every meaningful transition has an intentional outcome.

How Can Asset Budgets Stop a Fast Site From Becoming Slow?

Most slow websites are not ruined by one spectacularly bad decision. They accumulate weight through ordinary additions: another font, a larger hero image, a chat widget, an experiment script, a component library, and duplicate utilities from separate packages. Each change appears acceptable in isolation. Together they consume the loading and execution budget that nobody documented.

I like budgets that assign ownership. Images need dimensions, appropriate formats, responsive variants, and a reason to load eagerly. Fonts need a subset strategy and sensible fallback. JavaScript needs route-level inspection, not just a total repository size. Third-party scripts need named owners because external code still uses the visitor's processor, network, memory, and privacy allowance even when it is not in your source repository.

A team might begin with a compressed JavaScript target for each public route, a maximum hero-image weight, and a limit on critical font files. Those numbers are not universal standards. They are conversation starters that should be validated against the supported device and network profile. A browser-based design tool may justify more code than a contact page, but it still benefits from lazy loading and deliberate feature boundaries.

The parallel with Unity asset development is strong. Touch Camera PRO has to provide flexibility without forcing every project to pay for every possible behavior at once. Web components should follow the same principle. Load advanced editors only where they are used. Avoid shipping an entire icon set for a handful of symbols. Do not initialize video, maps, or real-time connections before the user needs them.

Review dependencies as product decisions, not free implementation details. Check their parsed size, runtime behavior, update history, accessibility, and overlap with existing code. Native browser capabilities are often sufficient. When a dependency is justified, isolate it so replacement remains possible. The goal is not zero JavaScript or zero third-party services. The goal is knowing what each asset costs and why that cost belongs in the experience.

What Does Graceful Degradation Look Like in a Real Product?

Performance and resilience meet when something goes wrong. Networks become intermittent, APIs time out, authentication expires, browser storage fills, and third-party services fail. A fast happy path is valuable, but a product earns trust through its unhappy paths. Users should understand what happened, whether their work is safe, and what action they can take next.

Across freelance work that has included Meta Spirit Sling, Loreal Viva Tech 2024, Ticketly, and indie projects, the product contexts have varied considerably. The reusable lesson is not a particular framework. It is to identify critical capabilities and reduce the number of systems required to preserve them. Optional analytics should never block a primary action. A failed recommendation panel should not make account settings unavailable.

Forms deserve special care. Preserve entered data when submission fails. Disable duplicate submission while a request is active, but restore the control after failure. Use idempotency protection for operations that must not run twice. Validate near the input for fast feedback, then validate again on the server because the browser cannot be trusted as the final authority. If a session expires, explain whether the draft can be recovered before redirecting.

Retries should be selective. Retrying a transient read with exponential backoff can be reasonable. Blindly retrying a payment, deletion, or other side-effecting operation can create a worse failure. Respect server guidance, cap attempts, add jitter where many clients could retry together, and always provide a final state. An infinite spinner is not a recovery strategy.

Graceful degradation also includes accessibility and reduced capability. Core content should remain understandable without motion, with keyboard navigation, and at high zoom. Where practical, cache read-only information or drafts for intermittent connectivity. Not every application needs full offline operation, but every application should define what happens when connectivity disappears. Resilience becomes much easier when it is designed alongside the successful flow rather than attached after launch.

How Do You Make Performance Part of the Delivery Workflow?

Performance work fails when it depends on one enthusiastic developer remembering to run a test before release. The solution is not a larger optimization document. It is a delivery loop that makes regressions visible while they are still cheap to fix. I want performance discussed during planning, checked during implementation, reviewed in pull requests, and observed after deployment.

Start with a small set of representative routes and actions. Capture transferred bytes, script size, LCP, CLS, long tasks, and important product timings under a documented test profile. Add automated checks for clear violations, such as an unexpected bundle increase or an oversized image. Keep thresholds realistic enough to be enforced. A warning that everyone learns to ignore is not a budget.

Lighthouse CI and browser automation can catch valuable regressions, but synthetic scores have natural variance. Compare trends, run multiple samples, and investigate the underlying trace rather than treating one score as a verdict. For major releases, test on physical mobile hardware and a constrained network. Developer laptops often conceal main-thread, memory, thermal, and bandwidth problems that real users face.

After release, monitor field data by route, device class, geography where appropriate, and application version. Connect technical metrics to outcomes such as task completion and error recovery without collecting more personal data than the product needs. An improvement matters when it makes the intended journey more reliable, not merely when a dashboard turns green.

This workflow is part of how I approach web application and backend development. Architecture, interface behavior, testing, and deployment have to support the same performance targets. I also assign follow-up ownership. If a threshold fails, the team should know who investigates, which exceptions are allowed, and when temporary debt expires. Performance stays healthy when it becomes an ordinary acceptance criterion rather than a heroic cleanup phase.

What Should Web Teams Prioritize in 2026?

In 2026, web teams have more rendering strategies, hosting platforms, component libraries, AI coding tools, and observability products than they can reasonably evaluate. More options do not automatically produce faster software. In fact, the easiest way to lose performance is to stack abstractions before understanding the user journey they are supposed to support.

My priority order is simple. First, remove work that does not create user value. Second, delay work until it is needed. Third, move suitable work away from the main thread or critical request path. Fourth, cache results with an explicit freshness policy. Fifth, communicate the remaining wait honestly. This sequence usually produces better decisions than selecting a fashionable rendering mode and assuming architecture alone will solve latency.

AI-generated code makes discipline more important. A generated component can introduce a large dependency, duplicate an existing utility, trigger unnecessary requests, or mishandle cancellation while still looking convincing in review. I use automation to accelerate implementation, but generated output must obey the same budgets, security boundaries, accessibility requirements, and state model as handwritten code. Faster code production can otherwise mean faster performance regression.

I would also resist universal rules. Server rendering can improve the arrival of useful content, but it does not excuse excessive client hydration. Client rendering can support rich interaction, but it should not delay basic navigation unnecessarily. Edge execution can reduce distance for some workloads, but data location, consistency, cost, and operational complexity still matter. Measure the complete request rather than optimizing labels.

The biggest lesson I carry from games to the web is that responsiveness is part of design. Eagle Flight Arcade needed disciplined real-time behavior because VR makes delay difficult to hide. A web product may have a different tolerance, but users still notice when software ignores them. Define the budget, expose every meaningful state, test weak conditions, and keep measuring after release. Fast experiences are not created by one optimization. They are protected by hundreds of explicit decisions.

References & Further Reading

How to Build a Unity Vertical Slice That Actually De-Risks Production

Anthony KOZAK — Mon, 31 Aug 2026 08:02:04 +0000

Most game projects do not fail because nobody had a good idea. They fail because the team scaled production before proving that the idea could survive contact with players, hardware, schedules, and content pipelines. Across 16 years in game development, I have learned to treat the vertical slice as a decision-making tool, not a miniature trailer. A useful slice exposes risk while change is still affordable. A bad one hides risk under polished art. Whether I am evaluating a Unity client project, maintaining Touch Camera PRO, or thinking back to Eagle Flight Arcade at Ubisoft Montreal in 2016, the same principle applies: prove the difficult parts before multiplying them.

Key Takeaways

A vertical slice should test production assumptions, not merely demonstrate a game concept.
Start with the risks most likely to invalidate the project, including feel, performance, content cost, and platform constraints.
Use enough architecture to test repeatability, but avoid building a speculative framework.
Set measurable acceptance gates before polishing the slice.
Greenlight, pause, or cancel based on evidence rather than enthusiasm or sunk cost.

What Should a Vertical Slice Actually Prove?

A vertical slice is a small, representative piece of the intended game at something close to the target quality bar. That definition sounds simple, but teams often confuse it with a prototype, demo, or pitch video. A prototype asks whether an idea might work. A demo communicates an idea to an audience. A vertical slice asks whether the team can repeatedly produce the real game.

I expect a slice to answer five questions. Is the core interaction enjoyable after the novelty wears off? Can the technology support the intended experience? Is the visual and audio target achievable on the target hardware? Can the team build more content through a repeatable pipeline? Finally, does the result communicate a coherent product to someone who did not help create it? A beautiful room that took heroic effort to assemble does not answer those questions.

The common mistake is selecting the easiest content. Teams choose a safe level, scripted encounter, or controlled camera angle because it produces attractive footage. That approach removes exactly the uncertainty the slice should expose. If enemy density, touch input, save data, network latency, or procedural layout is central to the product, the slice must include a representative version of that problem.

As a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016, I worked on a VR flight game targeting PSVR, Oculus Rift, and HTC Vive. That kind of development makes hidden assumptions expensive. Controls, frame timing, readability, and player comfort are part of the product, not finishing touches. The lesson applies outside VR too. Your slice should contain enough real pressure to reveal whether the design survives its delivery conditions.

The final test is repeatability. If the slice works only because one developer remembers a fragile sequence of editor steps, production has not been proven. A strong slice leaves behind documented settings, reusable prefabs, clear ownership, and a credible path to the next piece of content.

How Do I Choose the Riskiest Part of the Game?

I begin with a risk register before I build a scene. For each major assumption, I record what must be true, what evidence currently supports it, and what happens if it is false. I then rate uncertainty and consequence on a simple scale from 1 to 5. Multiplying those ratings is not scientific, but it forces useful comparisons. A feature with high uncertainty and project-ending consequences belongs near the front of the slice.

Design risk is only one category. Technical risk covers performance, platform services, simulation, networking, input, and persistence. Production risk covers asset throughput, level assembly, localization, testing, and build creation. Product risk covers whether players understand the premise and want another session. Team risk covers missing expertise, unclear ownership, or a tool that only one person can operate. A real slice usually combines one or two risks from several categories.

Maintaining Touch Camera PRO has made me particularly suspicious of the phrase “input is easy.” Input is easy in an isolated happy path. It becomes difficult when gestures overlap, devices report differently, UI competes with world interaction, and a project needs custom behavior without modifying package code. If touch control is central to a game, I would rather test gesture conflicts and customization in the slice than demonstrate one perfect swipe.

Do not automatically select the largest feature. Select the uncertainty that could force the largest redesign. A procedural world might sound technically impressive, but the bigger risk could be whether players can read the combat at the chosen camera distance. A multiplayer architecture may deserve investigation, but perhaps the immediate product risk is whether the cooperative action is enjoyable in the same room.

I also write a failure statement before implementation. For example: “If new players cannot identify the next valid action without verbal guidance, this interaction model needs revision.” That is far more useful than “make the tutorial feel good.” A clear failure statement tells the team what to observe and makes it harder to redefine success after seeing disappointing results.

Which Unity Architecture Belongs in a Vertical Slice?

A throwaway prototype can tolerate shortcuts. A vertical slice cannot depend entirely on them because it must test whether production is repeatable. However, this does not justify building a universal framework. I want narrow seams around the systems most likely to change: input, game rules, presentation, content configuration, persistence, and platform services.

In Unity, I usually separate authored data from runtime state. ScriptableObjects can hold tuning values and content definitions, while scene objects own temporary state. I keep input behind a small interface so keyboard, controller, touch, or XR implementations can change without rewriting the gameplay rule. The same principle applies to audio, achievements, analytics, and save systems. The interface should represent what gameplay needs, not every capability the provider offers.

using UnityEngine;

public interface IAbilityInput

{

    bool PressedThisFrame { get; }

}

public interface IPlayerAbility

{

    bool TryActivate();

}

public sealed class PlayerAbilityController : MonoBehaviour

{

    [SerializeField] private MonoBehaviour inputSource;

    [SerializeField] private MonoBehaviour abilitySource;

private IAbilityInput input;
private IPlayerAbility ability;

private void Awake()
{
    input = inputSource as IAbilityInput;
    ability = abilitySource as IPlayerAbility;

    if (input == null || ability == null)
    {
        throw new System.InvalidOperationException(
            name + ": Sources must implement the slice interfaces.");
    }
}

private void Update()
{
    if (!input.PressedThisFrame)
    {
        return;
    }

    ability.TryActivate();
}


}

This example is intentionally small. The controller understands an intention and an ability, but it does not know whether the intention came from a touchscreen or gamepad. It also does not contain cooldown visuals, sound effects, or platform code. Those boundaries let a team test alternative implementations without dismantling the core loop.

I apply two tests to every abstraction. First, does the slice already have at least two plausible implementations or a known platform variation? Second, will this boundary make a production risk observable? If both answers are no, I probably do not need the abstraction yet.

The architecture has succeeded when another developer can create a second representative encounter without copying a scene and repairing references by hand. Prefab variants, validation tools, automated tests for stable rules, and concise setup notes are more valuable than an impressive inheritance hierarchy. The goal is controlled repetition, not theoretical purity.

How Much Polish Should the Slice Receive?

A vertical slice needs enough polish to test the intended experience, but polish must be attached to a question. If hit effects are necessary for players to understand combat timing, they belong in the slice. If a cinematic transition exists only to make a presentation feel expensive, it may be hiding the unfinished production problem underneath.

I divide polish into readability, responsiveness, coherence, and spectacle. Readability tells the player what is happening. Responsiveness connects input to visible and audible feedback. Coherence ensures the art, animation, UI, and sound appear to belong to the same product. Spectacle creates memorable peaks. I fund those categories in that order. Spectacle cannot rescue an interaction that players cannot parse.

Performance is also part of polish because unstable delivery changes how controls and animation feel. Choose an explicit hardware target and frame-rate target before profiling. A 60 Hz game has roughly 16.7 milliseconds for a frame, while a 90 Hz target has roughly 11.1 milliseconds. Those are total budgets, not CPU allowances. The slice should measure representative scenes on representative hardware instead of assuming the editor reflects the final build.

I recommend setting content budgets early, even when the first values are provisional. Track texture memory, material complexity, visible characters, physics activity, audio voices, loading behavior, and garbage collection. In 2025 and 2026, Unity teams commonly target several hardware tiers and storefront environments. A slice running on a powerful development machine proves very little about the weakest supported device.

Do not polish every surface equally. Pick the player path that represents normal play, bring it to the intended bar, and leave secondary areas visibly temporary. Label placeholders so stakeholders do not mistake them for final decisions. This creates an honest contrast between proven quality and unresolved work.

I stop adding polish when the team can answer the slice questions without apologizing for missing feedback, but before improvements become indistinguishable from content production. The slice is an experiment with production-quality ingredients. It is not permission to build the first ten minutes of the game while the remaining pipeline stays hypothetical.

How Should Players Test a Vertical Slice?

Developers are poor substitutes for first-time players because we know what every object means and what every broken interaction was supposed to do. I want external observation early, including when placeholder visuals are uncomfortable to show. Waiting for presentation quality usually means preserving design mistakes for too long.

I use three waves of testing. The first is guided and diagnostic. I can interrupt, ask what the player expected, and inspect obvious failures. The second is silent. The player receives only the instructions that the final product would provide, while the team watches without rescuing them. The third approximates the target context, including the intended device, input method, session conditions, and build installation process.

Questions should test comprehension and intention rather than request design solutions. I ask, “What were you trying to do?” and “What did you expect to happen next?” I avoid “Did you like the controls?” because politeness makes that answer unreliable. Behavior is stronger evidence. Repeated hesitation, missed feedback, accidental actions, and ignored options show where the design model differs from the player’s model.

Basic instrumentation helps, even without a production analytics service. Record important state transitions, failed interactions, restarts, completion paths, and settings changes. Use anonymous local logs when that is sufficient, and review privacy requirements before collecting anything remotely. A timeline often reveals that a supposed difficulty problem is actually a comprehension problem three steps earlier.

Test the second attempt as well as the first. The first attempt reveals onboarding and readability. A repeated attempt reveals whether the mechanic gains depth or merely becomes routine. A vertical slice should not only produce one successful session. It should offer evidence that the central loop can sustain repetition.

Most importantly, define in advance what result triggers a change. If three testers struggle, a team can always call them outliers. If the acceptance condition says that unassisted players must identify the primary objective and perform the core action, failure is harder to rationalize. The exact threshold depends on the project, but the threshold must exist before the room becomes emotionally invested in the result.

What Do Real Hardware and Delivery Constraints Reveal?

My only AAA studio credit is Eagle Flight Arcade, where I worked as a Gameplay Programmer at Ubisoft Montreal in 2016. It shipped across PSVR, Oculus Rift, and HTC Vive. The enduring lesson was not simply that VR needs performance. It was that hardware assumptions shape design, controls, testing, and content from the beginning. You cannot validate the experience on one convenient setup and treat the rest as a packaging task.

The same principle applies to mobile devices, desktop configurations, event builds, handheld hardware, and browser delivery. Different aspect ratios can invalidate UI composition. Thermal limits can turn a stable opening into an unstable longer session. Storage and loading behavior can break pacing. Controller disconnection, focus loss, permission prompts, and suspended applications can expose missing state transitions.

Client-facing work, including Loreal Viva Tech 2024, has reinforced another point for me: a build is experienced inside a delivery context. The person launching it may not be a Unity developer. The network may be restricted. The display may be different from the one used during development. Recovery after an interruption can matter as much as the ideal path. A slice should therefore test startup, restart, failure recovery, and shutdown, not only the playable middle.

I create a small platform matrix before greenlighting production. It lists target device classes, input methods, performance targets, display assumptions, platform services, and known failure modes. I then identify which combinations are mandatory for the slice. This prevents “supports controller” from meaning that one developer connected one controller once.

Build automation should enter the process here. The team does not need an elaborate release pipeline, but it should be possible to produce a clean version from source control without relying on undocumented local files. Test that version outside the development environment. Confirm scenes, configuration, shaders, addressable content, permissions, and persistent data behavior.

A delivery constraint discovered during the slice is good news. It may be frustrating, but it is cheaper than discovering the same constraint after dozens of levels, characters, or client milestones depend on the wrong assumption.

Which Production Gates Prevent Scope Creep?

Scope creep thrives when a slice has no exit criteria. Every new idea can be described as necessary for “proper evaluation,” and the experiment quietly becomes full production. I prevent that by defining gates before the implementation backlog expands.

Gate zero is a written hypothesis. It states the target player, core loop, riskiest assumptions, target platforms, and the evidence required for a decision. Gate one is functional proof. The complete loop works with temporary presentation and can be played from start to finish. Gate two is representative quality. The chosen path reaches the intended standard for feel, readability, art, audio, and performance. Gate three is repeatability. Another piece of content can be assembled through the documented pipeline without exceptional intervention.

Each gate receives a green, yellow, or red result. Green means the evidence supports the assumption. Yellow means the result is promising but a bounded follow-up is required. Red means the current approach failed. A yellow item must include a specific question, owner, and time limit. Otherwise, yellow becomes a polite word for permanent uncertainty.

I also freeze a “not in slice” list. It might contain secondary game modes, broad progression, cosmetic variety, advanced settings, optional narrative content, or final storefront integration. The exact list changes by project, but writing it down protects the slice from attractive distractions. New requests must either replace existing work or wait for the production decision.

In the 2025 and 2026 market, teams face intense discoverability pressure and may feel compelled to prepare trailers, festivals, store pages, and community beats as early as possible. Those activities can be valuable, but marketing readiness and production readiness are different gates. A clip can generate attention while the content pipeline remains unsustainable. Do not let public enthusiasm erase technical evidence.

A weekly review should focus on resolved assumptions rather than completed tasks. “Implemented inventory UI” reports activity. “Players can equip, compare, and discard items without guidance, and the workflow runs within the performance budget” reports evidence. That distinction keeps the vertical slice aimed at decisions instead of velocity theater.

The best gate is one the team is genuinely willing to fail. If every possible outcome leads automatically to full production, the slice was never an experiment. It was only a delayed announcement.

When Should a Prototype Be Greenlit, Paused, or Cancelled?

I evaluate the completed slice across four dimensions: player value, technical viability, production repeatability, and product clarity. A greenlight requires credible evidence in all four. Strong game feel cannot compensate for a content pipeline that takes heroic effort. Reliable technology cannot compensate for players misunderstanding the central activity. A clear pitch cannot compensate for a loop that becomes dull after the first attempt.

Pausing is appropriate when the concept remains promising but a specific external dependency or missing capability blocks an honest decision. The pause should have a written restart condition. “Wait until we have better art” is vague. “Resume after validating whether the target device can sustain the representative scene within the chosen frame budget” is actionable. Without a restart condition, paused projects become invisible commitments that continue consuming attention.

Cancellation is the correct result when a core assumption fails and the affordable alternatives no longer support the original product. That does not make the slice wasted work. It purchased information before the team multiplied the mistake. Useful tools, shaders, interaction experiments, and pipeline knowledge can survive, but they should be extracted deliberately rather than used to justify continuing the wrong game.

Publishing Unity products such as Touch Camera PRO, Assets Manager, City Builder, and Level Designer has reinforced the difference between a one-off solution and a repeatable system. Reuse requires clean boundaries, documentation, predictable setup, and testing outside the original scene. A game vertical slice does not need Asset Store-level packaging, but it should show that the team can reproduce its success without relying on the exact people and conditions that created the first version.

If the project is greenlit, I do not immediately expand every dimension. I turn the slice into a production template, identify remaining yellow risks, estimate content from observed throughput, and schedule another review after the first repeated content set. The slice provides evidence, not immunity from future mistakes.

My strongest advice is to make the decision explicit. Write a short greenlight, pause, or cancellation memo that cites the evidence and unresolved risks. Months later, that document will be more valuable than anyone’s memory of how exciting the demo felt. Good game development is creative, but it is also the discipline of paying for uncertainty in the smallest responsible increments.

References & Further Reading

Context Engineering for Unity: How to Make AI Useful on Real Projects

Anthony KOZAK — Mon, 24 Aug 2026 08:02:25 +0000

AI coding tools are impressive in a clean demo and much less impressive inside a Unity project that has been shipping for years. The difference is usually not the prompt. It is the context surrounding the prompt. After 16 years in game development, I have learned that production work depends on assumptions scattered across scenes, prefabs, packages, build settings, naming conventions, and platform requirements. An AI assistant cannot respect information it cannot see. This article is not about adding a chatbot to an NPC or sending player text to a model. It is about context engineering: organizing a real Unity project so an AI assistant can make useful, reviewable changes without turning your repository into an experiment.

Key Takeaways

AI output is only as reliable as the project context supplied with the task.
Small tasks with explicit acceptance checks outperform broad feature requests.
Unity versions, package versions, scene ownership, and serialization rules must never be left to guesswork.
Automated tests convert plausible AI suggestions into evidence.
Measure accepted changes and review cost, not generated lines of code.

Why Does AI Struggle With Real Unity Projects?

Most AI coding failures I see are not failures of syntax. The generated C# compiles, the class names look sensible, and the explanation sounds confident. The failure appears one level deeper. The code assumes the wrong input system, modifies a prefab that should be treated as a template, calls an API unavailable in the installed package version, or creates a second architecture beside the one already in production. These are context failures disguised as implementation failures.

Unity makes this problem especially visible because the project is larger than its scripts. Important behavior can live in scenes, prefabs, ScriptableObjects, animation controllers, physics layers, tags, package manifests, quality settings, and platform-specific configuration. A model shown three C# files may produce a reasonable answer for those files while remaining completely unaware that a serialized event in a prefab depends on the method it wants to rename.

I learned to respect hidden dependencies long before modern coding assistants appeared. Eagle Flight Arcade, which I shipped as a Gameplay Programmer at Ubisoft Montreal in 2016, targeted PSVR, Oculus Rift, and HTC Vive. Even without discussing its internal architecture, that platform matrix illustrates the point. A change that appears local can interact with input, performance, comfort, hardware behavior, and build configuration. Production knowledge rarely fits inside one source file.

My first question for an AI task is therefore not whether the model can write the code. I ask whether it has enough evidence to understand the job. If the answer is no, I improve the evidence before refining the prompt. I provide relevant file paths, Unity and package versions, architectural boundaries, expected behavior, and known risks. A shorter request with the right project map is more valuable than a clever paragraph full of motivational instructions. Context engineering begins by making the invisible parts of the project visible.

What Should an AI-Readable Unity Project Brief Contain?

A useful project brief should explain the repository the way I would explain it to a developer joining for a focused task. It does not need to document every class. It needs to identify the decisions that must not be reinvented. I usually begin with the Unity editor version, render pipeline, supported platforms, input solution, major packages, assembly layout, testing approach, and the directory boundaries between runtime code, editor code, samples, and third-party dependencies.

The next layer describes architecture in plain language. Which system owns game state? How do scenes transition? Are services found through dependency injection, explicit references, static access, or another established pattern? Which ScriptableObjects are configuration assets, and which hold runtime state? Are asynchronous operations based on coroutines, tasks, or a project-specific abstraction? This is not an invitation for the AI to redesign those choices. It is a contract telling the assistant which choices already exist.

I also document prohibited changes. An asset package, for example, should not silently add a new dependency, modify global project settings, or require customers to restructure their scenes. That matters to products such as Touch Camera PRO and Touch Camera LITE because reusable Asset Store code lives in projects I do not control. The safest implementation is usually the one with the smallest integration footprint. The project brief should state that requirement directly instead of expecting a model to infer it.

Finally, I include a definition of done that can be observed. The code must compile without new warnings. Existing public APIs must remain compatible unless the task explicitly authorizes a breaking change. Edit Mode and Play Mode tests must pass. Any new serialized field needs a safe default and a migration plan if existing assets are affected. Files outside the approved scope should remain untouched. I keep this brief in the repository, review it like code, and update it when architecture changes. That gives humans and AI assistants the same baseline instead of allowing each conversation to invent a different version of the project.

How Should You Break Work Into AI-Sized Tasks?

Broad requests encourage broad guesses. Asking an assistant to improve the camera system gives it permission to reinterpret input, smoothing, collision, framing, serialization, and public APIs at the same time. Asking it to add an optional maximum zoom constraint to one component, preserve existing defaults, update one test file, and avoid allocation in the per-frame path creates a task that can be reviewed. The second request is smaller, but it contains more useful engineering information.

I divide work according to verification boundaries. A good task has one behavioral objective, a limited file set, known constraints, and a result I can test without finishing three other features first. Investigation is a separate task from implementation. I may first ask the assistant to trace where a value originates, list every serialized reference to a method, or compare two possible extension points. Only after validating that map do I request a patch. This prevents an uncertain analysis from being buried inside a large code change.

I also ask for a plan before code when a task crosses systems. The plan should name the files to modify, explain why each file is involved, identify compatibility risks, and propose tests. I reject plans that introduce unnecessary managers, wrappers, service locators, or generic frameworks. AI assistants often solve ambiguity by creating abstractions. Mature projects frequently need the opposite: a narrow change that respects the abstractions already present.

The final request should include stop conditions. If a required class is missing, a package API is uncertain, or a scene reference cannot be inspected, the assistant should report the uncertainty rather than fabricate an answer. This matters in 2026 because models are increasingly capable of completing a task-shaped conversation even when the repository evidence is incomplete. Fluency can hide uncertainty. Small task slices expose it. They also make commits easier to review, revert, benchmark, and assign. My preferred AI unit of work is not a feature. It is the smallest coherent change that can prove its own correctness.

Which Unity Details Must the Model Never Guess?

The Unity version is the first detail I make explicit. APIs, package compatibility, serialization behavior, and build tooling change over time. A model trained on years of Unity examples may combine an older tutorial, a newer package API, and a deprecated workflow into code that looks entirely plausible. I provide the exact editor version and relevant package versions, then require the assistant to flag any API it cannot verify against that environment.

Scene and prefab ownership must also be clear. I do not let an assistant assume that editing a prefab instance is equivalent to editing its source, or that a scene object is always present at runtime. The task should state how references are assigned, whether objects are loaded additively, what survives scene transitions, and whether a prefab belongs to the project or an imported package. If the assistant cannot inspect serialized YAML safely, I provide a human-readable summary instead of pretending the script files tell the whole story.

Execution order is another dangerous guessing area. Unity lifecycle methods, script execution settings, domain reload options, Enter Play Mode configuration, and asynchronous loading can all change when initialization occurs. An assistant may fix a null reference by adding a convenient lookup in Update, but that can replace a visible lifecycle bug with a permanent performance cost. I want the initialization contract explained and tested, not patched through repeated searching.

Platform behavior belongs on the same list. Touch, mouse, controller, VR input, safe areas, file permissions, and graphics capabilities are not interchangeable. My experience with Eagle Flight Arcade reinforced how seriously platform constraints must be treated, while maintaining camera assets reinforces the variety of customer configurations a reusable package can encounter. I tell the model which platforms matter and which ones are outside scope. I also identify code that runs per frame, in physics steps, in editor callbacks, or during builds. These details determine whether an allocation, reflection call, asset lookup, or conditional compilation symbol is acceptable. When context is unavailable, the correct AI response is a question, not a confident guess.

How Can Tests Turn AI Suggestions Into Evidence?

Generated code should enter the repository through the same evidence pipeline as human code. Compilation is only the first gate. I want tests that describe the intended behavior before I accept an implementation, especially when the assistant proposes a refactor. If a method is supposed to clamp zoom, preserve an old default, or reject invalid configuration, those expectations should be executable. Otherwise, the review becomes a debate about whether the code looks reasonable.

Tests are also a compact form of context. A well-named test tells the assistant what the system promises, which edge cases matter, and what compatibility means. For Unity work, I separate pure C# logic from engine-dependent behavior when practical. Pure calculations can often be covered quickly with Edit Mode tests. Frame timing, coroutines, scene loading, and component lifecycle behavior may require Play Mode tests. I do not force everything into an engine-free layer, but I avoid making simple rules impossible to test.

I sometimes version a small task brief as a ScriptableObject so constraints and acceptance checks remain inspectable by the team. The following is intentionally simple. It creates a consistent summary that can be copied into an approved AI tool or exported by an editor utility:

using System;

using System.Text;

using UnityEngine;

[CreateAssetMenu(menuName = "AI/Task Context")]

public sealed class AiTaskContext : ScriptableObject

{

    [SerializeField] private string objective;

    [TextArea(3, 8)]

    [SerializeField] private string constraints;

    [SerializeField] private string unityVersion;

    [SerializeField] private string[] packageVersions = Array.Empty<string>();

    [SerializeField] private string[] acceptanceChecks = Array.Empty<string>();

public string BuildBrief()
{
    var builder = new StringBuilder();
    builder.AppendLine($&quot;Objective: {objective}&quot;);
    builder.AppendLine($&quot;Unity: {unityVersion}&quot;);
    builder.AppendLine($&quot;Packages: {string.Join(&quot;, &quot;, packageVersions)}&quot;);
    builder.AppendLine(&quot;Constraints:&quot;);
    builder.AppendLine(constraints);
    builder.AppendLine(&quot;Acceptance checks:&quot;);

    foreach (string check in acceptanceChecks)
        builder.AppendLine($&quot;- {check}&quot;);

    return builder.ToString();
}


}

This object is not a security boundary and it does not replace repository documentation. Its value is consistency. The objective, environment, and checks can be reviewed alongside the work rather than disappearing in a private chat history.

For every AI-assisted change, I run the tests outside the conversation. I inspect the actual diff, open affected scenes or prefabs, and test the relevant platform path. If the model writes the test and implementation together, I deliberately add or modify an edge case myself. A model can produce a test that merely confirms its own assumptions. Independent checks are what convert a plausible patch into evidence I can trust.

What Review Process Keeps AI Code Maintainable?

I review AI-generated code more skeptically than familiar human code, not because it is automatically worse, but because authorship signals are different. A human teammate can explain which assumptions came from project history. A model may provide a polished explanation assembled from incomplete evidence. I review the diff from the outside inward: scope first, behavior second, architecture third, and style last. If the patch touches files unrelated to the objective, I stop before debating naming.

My first pass checks additions that expand the maintenance surface. Did the change introduce a package, static singleton, reflection helper, editor preference, scripting define, or new public API? Did it copy logic that already exists? Did it create a generic abstraction for a single use case? These patterns can look professional while making the project harder to understand. I ask for deletion and simplification before accepting extra machinery.

The second pass follows Unity-specific failure paths. I inspect serialized field renames, default values, missing-reference behavior, event subscriptions, scene unloads, destroyed objects, domain reloads, and editor-only APIs. I check whether lifecycle methods accidentally hide a base implementation and whether repeated calls create allocations or duplicate listeners. For reusable code such as Touch Camera PRO, I also think about namespace collisions, optional integrations, sample isolation, and whether a customer can upgrade without repairing existing scenes.

The final pass treats the assistant's explanation as a claim to verify, not as proof. I compare it with the diff, run tests, and exercise the feature in the editor. I prefer one conceptual change per commit, even if the assistant could generate a larger patch in seconds. Small commits preserve accountability and make regressions easier to isolate. I also record material AI involvement according to the client's policy, especially when repository access, confidentiality, or licensing is involved. Review cannot be delegated back to the same model that produced the patch. The shipping developer remains responsible for understanding every accepted line and for removing code that the team cannot confidently maintain.

How Do You Introduce AI Into a Mature Product?

I would not begin by asking AI to refactor the heart of a mature product. I start at the edges, where outcomes are easy to compare and rollback is cheap. Good early tasks include drafting tests around existing behavior, summarizing an unfamiliar subsystem, identifying duplicate validation, improving editor diagnostics, or preparing a narrow documentation update. These jobs reveal whether the supplied context is accurate without risking a large migration.

This approach matters for long-lived Unity assets. Products such as Touch Camera PRO, Assets Manager, Tutorial Engine, Responsive UI Pro, and Level Designer have different responsibilities, but they share a publisher's constraint: existing users may depend on behavior that is not obvious from the latest code. A cleaner implementation can still be the wrong implementation if it changes defaults, serialization, namespaces, or setup steps. Before using AI on a mature package, I identify compatibility promises and capture representative project setups as tests or sample scenes.

Client work requires another layer of discipline. My freelance experience spans projects and engagements such as Meta Spirit Sling, Mindsight Journey, Loreal Viva Tech 2024, Rabbids Coding, and A Long Journey to an Uncertain End. Those names do not imply that the same AI policy, repository access rule, or tooling choice applies to each engagement. Before sending any material to an external service, I confirm the client's policy, data boundaries, contractual requirements, and approved tools. If approval is unclear, source code and project data stay out of the model.

I then run a limited trial with a reversible task and compare the full workflow against the normal approach. That includes context preparation, generation, correction, review, testing, and documentation. If the assistant saves ten minutes of typing but creates an hour of review uncertainty, it has not improved the process. If it helps expose an undocumented dependency or produces useful test cases that survive review, I keep that pattern. Adoption should expand through demonstrated value, not enthusiasm. Mature projects accumulate knowledge slowly, so AI access should expand slowly too.

What Should a Team Measure About AI Work in 2026?

Lines of generated code are a terrible success metric. More code often means more review, more surface area for defects, and more future maintenance. Prompt counts and model usage are not much better. They measure activity rather than outcomes. In 2026, when coding assistants can produce substantial patches quickly, generation speed is rarely the limiting factor. The bottleneck is deciding whether the patch belongs in the product.

I prefer to measure accepted task cycle time. Start when the developer has enough information to begin, and finish when the change is reviewed, tested, documented, and ready to merge. I compare that with similar non-AI tasks when possible. I also track correction rounds, review time, escaped defects, reverted changes, and the percentage of generated code that survives meaningful human review. These do not need to become surveillance metrics. Their purpose is to expose where the workflow creates or removes friction.

Documentation quality is another useful signal. If an assistant repeatedly asks about initialization order, supported platforms, or package versions, the repository may be missing important context. Improving that context benefits human developers too. In this sense, AI can act as a diagnostic tool for project clarity. A codebase that is difficult to explain to a model is often also difficult to hand to a freelancer, onboard to a new teammate, or revisit after several months.

My strongest metric is boring: did the change make shipping safer or easier? Useful AI work might reduce a risky manual step, add regression coverage, clarify an undocumented boundary, or help a developer compare implementation options. It does not need to generate a complete feature. I judge tools by accepted outcomes, not demonstrations. Models, context limits, integrations, and pricing will continue to change, so I avoid building a workflow around one vendor's personality. The durable investment is a repository with explicit architecture, narrow tasks, automated checks, and disciplined review. That foundation makes current AI tools more useful, and it will remain valuable when the next generation arrives.

References & Further Reading

How to Build a Resilient Unity Career Through Proof of Work

Anthony KOZAK — Mon, 17 Aug 2026 08:02:13 +0000

Game development careers rarely follow a clean ladder. Mine has moved through gameplay programming, VR, Unity tools, Asset Store products, and client work. After 16 years in the industry, I no longer think resilience comes from finding one perfect role. It comes from building visible proof, maintaining useful specialties, and creating enough professional options that one cancelled project or market shift cannot define your future. In 2026, when studios remain cautious and production expectations keep changing, that approach matters more than any single job title.

Key Takeaways

Career resilience comes from maintaining several credible ways to create value.
Shipped work is stronger evidence than disconnected portfolio prototypes.
A strong portfolio explains constraints, decisions, tradeoffs, and results.
Specialization should create recognition without trapping you in one market.
Confidential work can still produce useful, sanitized career evidence.

What Does a Resilient Unity Career Look Like in 2026?

In 2026, career resilience does not mean predicting which platform, genre, or technology will win. Nobody can do that consistently. It means developing enough valuable capabilities that you can respond when circumstances change. A resilient Unity developer might be able to implement gameplay, diagnose performance, create editor tooling, communicate with nontechnical stakeholders, and deliver a build that another person can actually maintain.

My own career illustrates why this matters. My only AAA studio credit is Eagle Flight Arcade at Ubisoft Montreal in 2016, where I worked as a Gameplay Programmer on a VR flight game for PSVR, Oculus Rift, and HTC Vive. That experience remains important, but it is not the complete foundation of my career. Touch Camera PRO, Touch Camera LITE, Assets Manager, Tutorial Engine, and my other Unity Asset Store products demonstrate a different type of value. Client work such as Meta Spirit Sling, Mindsight Journey, and Loreal Viva Tech 2024 represents another environment again.

Those categories require overlapping skills, but they reward different behaviors. A studio role values collaboration inside an established production structure. A product requires documentation, compatibility decisions, support, and long-term ownership. Client work requires rapid context gathering, expectation management, and the ability to separate the real business problem from the initially requested feature.

I define resilience as having credible options before an emergency occurs. A developer who begins building a portfolio only after losing a contract is already under pressure. A developer who has shipped examples, current technical knowledge, professional relationships, and a clear specialty can make a deliberate choice. The goal is not to perform every job. The goal is to avoid having only one story about why somebody should hire you.

Which Proof of Work Actually Changes a Hiring Decision?

Most portfolios contain evidence, but not all evidence has equal weight. A screenshot proves that something existed. A video proves that it behaved in a certain way. A playable build proves more. A shipped product with documentation and a clear explanation of your contribution is stronger because it demonstrates execution under real constraints. Hiring managers and clients are not only asking, "Can this person write code?" They are asking whether that person can reduce uncertainty.

I think useful proof has four layers. First, establish the problem and production context. Second, show the result through a build, video, store page, or concise case study. Third, explain the decisions you personally owned. Fourth, provide a focused technical artifact, such as a code sample, architecture diagram, profiler capture, or testing strategy. A repository without context forces the reviewer to reverse engineer your value, and many reviewers will not have time to do that.

Eagle Flight Arcade is meaningful proof because it identifies a role, a year, a studio, a shipped game, and three VR platforms. Touch Camera PRO provides a different signal. It shows sustained ownership of a Unity camera controller distributed through the Asset Store. Neither item needs exaggerated claims. The verifiable context already makes the evidence useful.

Personal prototypes still have a place, especially when you are learning or moving into a new specialty. However, they should be scoped around a decision you want to demonstrate. Instead of producing another generic scene, show how you handled camera collision, input abstraction, save migration, accessibility, or frame-time diagnosis. Explain what you excluded and why. Professional work is full of exclusions, tradeoffs, and incomplete information. A portfolio that acknowledges those realities feels much closer to production than a polished scene that explains nothing.

How Can One Project Become More Than One Career Asset?

A common mistake is treating a finished project as a single portfolio entry. In reality, one legitimate piece of work can support several career assets without misrepresenting what happened. The key is to separate the original deliverable from the reusable knowledge around it. A project might lead to a short case study, a technical article, a demonstration video, a sanitized code excerpt, an interview story, and a checklist that improves your next production.

Touch Camera PRO is more than a store listing in this sense. It can demonstrate camera design, touch input handling, configuration decisions, documentation, packaging, and maintenance. Those subjects speak to different audiences. A technical lead may care about architecture. A designer may care about tuning and feel. A producer may care about integration risk. The underlying work stays the same, but the explanation changes based on the question being answered.

This does not mean publishing every internal detail. Before reusing anything from client or studio work, confirm ownership, confidentiality, and permission. If source code cannot be shown, recreate the general engineering lesson in a clean sample that contains no client assets, data, or proprietary logic. Clearly label it as an illustrative reconstruction. Accuracy is more valuable than making the sample appear closer to the original project.

I use a simple test when deciding whether an artifact is worth creating: will this help another person evaluate a skill that would otherwise remain invisible? If the answer is yes, the artifact has career value. A two-minute walkthrough of a debugging process may reveal more than a long montage. A compact architecture diagram may make years of judgment legible. Shipping creates experience, but documentation converts that experience into portable proof. Without that conversion, valuable lessons remain locked inside a project that future collaborators may never see.

What Should a Unity Portfolio Reveal About Engineering Judgment?

A Unity portfolio should reveal more than whether you know the API. Documentation and AI tools can help almost anyone discover a method name. Engineering judgment appears in how you define boundaries, anticipate failure, choose an appropriate level of abstraction, and communicate consequences. I want to know why a developer selected a particular approach and what would cause that approach to stop being appropriate.

For each substantial sample, describe the target platform, input assumptions, performance constraints, ownership boundaries, and validation method. If the code is intentionally simplified, say so. If an allocation is acceptable because an operation occurs only during loading, explain that context. If you rejected a flexible system because the feature needed to ship quickly and had a narrow use case, that can be a sound decision. Complexity is not evidence of seniority.

I also recommend storing a short project record beside the sample itself. It keeps the narrative connected to the implementation rather than relying on memory months later. A small ScriptableObject can make that information visible inside a Unity demonstration project:

using UnityEngine;

[CreateAssetMenu(menuName = "Portfolio/Demo Record")]

public sealed class DemoRecord : ScriptableObject

{

    [TextArea(2, 5)] public string problem;

    [TextArea(2, 5)] public string constraints;

    [TextArea(2, 5)] public string decisions;

    [TextArea(2, 5)] public string validation;

    [TextArea(2, 5)] public string nextSteps;

public bool IsReadyForReview()
{
    return !string.IsNullOrWhiteSpace(problem)
        &amp;&amp; !string.IsNullOrWhiteSpace(constraints)
        &amp;&amp; !string.IsNullOrWhiteSpace(decisions)
        &amp;&amp; !string.IsNullOrWhiteSpace(validation);
}


}

This is not a production architecture pattern. It is a communication device. The important part is the discipline of recording what problem existed, which constraints mattered, what you decided, and how you checked the result.

Finally, include limitations. Perhaps the sample does not address multiplayer authority, localization, console certification, or extremely large scenes. Naming those boundaries shows awareness. A reviewer can distinguish an intentional scope limit from an overlooked requirement. That distinction is one of the clearest signals of mature engineering judgment.

Why Does Shipping Teach What Prototypes Cannot?

Prototypes are excellent for answering focused questions. Can a mechanic feel good? Can an interaction be understood? Can a technical risk be reduced before production? What prototypes usually do not reveal is the cost of ownership after the first successful demonstration. Shipping introduces packaging, documentation, compatibility, edge cases, user expectations, versioning, and the uncomfortable discovery that other people will use a feature differently than you intended.

I experienced one form of shipping on Eagle Flight Arcade in 2016. A studio production requires individual work to coexist with a wider game, platform requirements, schedules, and the decisions of other disciplines. Asset Store products create another form of pressure. Users integrate tools such as Touch Camera PRO, Responsive UI Pro, Easy Tooltips And Overlays, or Level Designer into projects you do not control. Their scene structures and assumptions will not necessarily match yours.

Client work creates a third kind of shipping discipline. Work such as Crazy Coaster, Hop Hop Delivery, RE-PAIR, Hamsterstellar, and Croquette League came with its own context and goals. The transferable lesson is not that all projects should use the same process. It is that delivery requires understanding which risks matter for this particular product and this particular stakeholder.

When presenting shipped work, avoid turning the portfolio into a list of logos or titles. Explain what shipping changed about your thinking. Did it make you more conservative about dependencies? Did it teach you to create migration paths? Did you improve error messages because users could not inspect the source of a failure? Did you separate configuration from runtime state because integration became difficult?

A finished product is valuable career evidence because somebody had to accept its constraints. It does not prove perfection, and no honest developer should claim that. It proves that decisions survived contact with production. That is why one modest, clearly explained release can be more persuasive than several ambitious prototypes that were abandoned as soon as the interesting technical problem was solved.

How Should You Balance Specialization With Career Optionality?

Specialization makes you memorable. Optionality keeps you employable when demand moves. The challenge is to develop both without becoming so broad that nobody understands your strongest value. My preference is to build a visible anchor skill and surround it with adjacent capabilities that make the anchor more useful.

Camera systems are an obvious anchor in my portfolio because of Touch Camera PRO and Touch Camera LITE. However, a production-ready camera touches input, collision, animation, user experience, mobile constraints, and game feel. Unity tooling adds another adjacent capability. Products such as Assets Manager, Tutorial Engine, Responsive UI Pro, and Layered Scene Screenshot reflect problems outside a single gameplay niche. The portfolio becomes broader, but it still has a coherent center: practical Unity systems that other people can integrate and use.

For developers planning their own growth, I like a 70, 20, 10 model for quarterly learning time. Spend roughly 70 percent deepening the skill for which you want to be hired. Spend 20 percent on an adjacent capability that increases its usefulness. Spend 10 percent exploring a riskier area with uncertain value. These are planning targets, not universal rules, but they prevent curiosity from consuming all available time.

The adjacent skill should solve a real collaboration problem. A gameplay programmer might learn enough profiling to identify CPU and allocation issues, enough animation to communicate about state transitions, or enough backend integration to consume an API safely. The goal is not to claim expertise in every discipline. It is to reduce friction at the boundaries.

Reevaluate the anchor periodically. A specialty can remain valuable while its tools change. VR knowledge from 2016 still informs interaction and comfort decisions, but hardware, runtimes, and user expectations have evolved. Preserve the underlying principles while updating the implementation. Career optionality comes from understanding which parts of your expertise are durable and which parts are tied to a specific version, platform, or market cycle.

How Can You Show Valuable Work When Client Details Are Private?

Confidentiality is a normal constraint, not an excuse for an empty portfolio. Some of the most interesting professional problems cannot be shown through source code, internal screenshots, financial results, or unreleased designs. Even when a project name is public, the implementation details may remain private. The solution is to build a sanitized case study that communicates your reasoning without exposing protected information.

I structure that case study around five fields: context, responsibility, constraint, decision, and lesson. Context describes the type of product without revealing unnecessary details. Responsibility states exactly what I owned. Constraint identifies the pressure that shaped the work, such as a platform limitation, delivery requirement, or integration boundary. Decision explains the approach at a useful level. Lesson captures what I would repeat or change.

For named work such as Meta Spirit Sling or Loreal Viva Tech 2024, I still would not assume that every production detail is available for publication. Public association with a project is not blanket permission to reveal repositories, conversations, assets, roadmaps, or measurements. When in doubt, ask the rights holder for written approval or keep the description general.

A generic explanation can still be specific about engineering. You might say that you separated device input from gameplay commands so a VR interaction could be tested without hardware. You can explain that a tool used validation before export, without sharing the client's data format. You can discuss why a feature was divided into reversible milestones, without publishing the schedule.

Never compensate for missing details by inflating your role. Use "I" for work you personally performed and "we" for team outcomes. If you contributed to one system, do not imply ownership of the whole product. Precision builds trust. A restrained case study with clear boundaries tells an experienced reviewer that you understand both professional confidentiality and collaborative credit.

What Career System Should You Run Every Quarter?

A resilient career needs maintenance. I recommend a quarterly review because it is frequent enough to catch drift but long enough to finish meaningful work. This is not a performance ritual for a manager. It is a private operating system for deciding what evidence, skills, and relationships need attention next.

Start with an inventory. Record what you shipped, improved, documented, or learned during the previous quarter. Include unglamorous work such as removing a recurring failure, clarifying setup instructions, or creating a repeatable test. These are often stronger professional signals than another feature screenshot. Attach evidence while it is still available and the reasoning is still fresh.

Next, perform a gap review. Look at the roles or clients you want and compare their recurring needs with your current proof. Do not respond to every job description by starting a new course. Find the smallest credible project that closes a meaningful evidence gap. If you claim performance expertise, produce a before-and-after profiler analysis. If you claim tool development, create a usable editor workflow with validation and documentation.

Then choose one shipping commitment. It might be a focused update, a small public sample, a technical case study, or a reusable internal tool. Give it a definition of done. "Learn networking" is not shippable. "Build and document a small authoritative interaction sample" is much easier to evaluate.

Finally, refresh distribution. Update the places where people actually discover your work, contact former collaborators without immediately asking for something, and make sure your strongest proof is easy to find. Career opportunities often arrive through accumulated trust rather than a single application.

After 16 years, my opinion is simple: do not wait for the industry to provide a stable identity. Build one from repeated, verifiable work. Titles will change, Unity versions will change, and markets will change. A habit of shipping, documenting decisions, and deliberately extending your capabilities remains useful through all of them.

References & Further Reading

Web Development for Unity Teams: APIs, Dashboards, and Production Lessons

Anthony KOZAK — Mon, 03 Aug 2026 08:02:12 +0000

Web development can look like a separate discipline from game development, but modern Unity projects rarely live inside the executable alone. Accounts, cloud saves, events, support tools, content configuration, and internal dashboards all need a web layer. Across 16 years in the industry, from working as a Gameplay Programmer on Eagle Flight Arcade at Ubisoft Montreal in 2016 to freelance work involving Meta Spirit Sling, Mindsight Journey, Loreal Viva Tech 2024, and Ticketly, I have learned that this layer deserves the same engineering discipline as the game. In 2025 and 2026, a browser dashboard and a reliable API are often part of the product, even when players never see them directly.

Key Takeaways

Treat the API contract as a product shared by Unity, web, and backend developers.
Never embed trusted server secrets inside a Unity build.
Build internal dashboards around safe tasks, not direct database access.
Keep network calls outside frame-critical gameplay systems.
Prefer boring, observable technology over fashionable complexity.

Why do Unity projects need serious web development?

For many teams, the first web requirement sounds harmless: save a profile, display a leaderboard, or let a producer edit a configuration value. That small feature quickly becomes a system with authentication, permissions, validation, deployment, monitoring, and customer support implications. If those pieces are improvised late in production, the web layer becomes a collection of risky scripts rather than dependable infrastructure.

I think Unity developers have an advantage here. We already understand state, serialization, versioning, tools, and hostile input. A player can close an application halfway through an operation. A mobile connection can disappear. An old client can send data that the newest server no longer expects. Those are web problems, but they are also familiar game development problems. The important shift is recognizing that the server is authoritative and that every client request must be treated as untrusted.

My Unity Asset Store work has reinforced the value of designing for users who do not share my assumptions. Touch Camera PRO needs to behave predictably across projects I cannot inspect. Products such as Tutorial Engine, Assets Manager, Level Designer, and Responsive UI Pro also have to expose understandable workflows instead of relying on hidden knowledge. A web API has the same obligation. Its inputs, outputs, errors, and compatibility rules must be explicit.

A practical web layer also reduces pressure on game releases. If a support team can safely inspect an account, or a designer can schedule validated content through a dashboard, every routine operation does not require a programmer to build and ship a new client. That does not mean moving the entire game to the server. It means giving operational data an appropriate home and giving the team controlled tools for managing it.

What should a production API contract look like?

I start with the contract, not the framework. Before choosing a server language or creating database tables, I write down what the Unity client is allowed to ask for, what it receives, and how failure is represented. A useful contract is boring enough that a developer can inspect a request in an HTTP tool and understand it without reading the backend source.

Resource-oriented URLs are usually clearer than endpoints named after interface buttons. For example, GET /v1/profiles/me communicates intent better than POST /loadProfileScreen. The first describes a resource. The second couples the server to one client interface. Versioning the route does not solve every compatibility problem, but it establishes that contracts change deliberately. I also include a schema version in long-lived documents such as saves or user-generated layouts.

Responses need stable identifiers, server-generated timestamps, and documented nullability. Lists should be paginated before they grow large, not after a dashboard begins timing out. Write operations should consider idempotency. If a client retries a purchase confirmation or content submission after losing its connection, the server must not blindly perform the action twice. An idempotency key or operation identifier can let the backend recognize a repeated request.

Errors are part of the contract. An HTTP status such as 400, 401, 403, 404, 409, or 429 provides a broad category, while a compact application error code tells the client what it can do next. Human-readable text is useful for logs, but gameplay logic should not depend on matching an English sentence. I want the Unity client to know whether it should refresh authentication, ask the player to edit input, wait before retrying, or stop.

Finally, document the contract in a machine-readable format such as OpenAPI. Generated documentation is helpful, but the bigger benefit is alignment. Web developers, Unity developers, testers, and external partners can discuss one shared definition instead of maintaining conflicting assumptions in chat messages and spreadsheets.

How should authentication work between Unity and a backend?

The first rule is simple: a Unity build cannot safely contain a trusted secret. Anything shipped to a player should eventually be considered readable. Obfuscation can increase the effort required to inspect a build, but it does not transform a client secret into a server secret. Permanent service credentials belong on infrastructure controlled by the team.

A player-facing client should authenticate as a public client. Depending on the product, that might begin with an email flow, platform identity, device flow, or a session created by another trusted identity provider. After authentication, the client can receive a short-lived access token. A refresh mechanism may keep the session usable, but it needs rotation, revocation, expiration, and careful storage. The exact implementation depends on the platforms being supported, particularly when Unity WebGL runs inside a browser sandbox.

Authentication answers who is making a request. Authorization answers what that identity may do. The backend must enforce both. Hiding an administrator button in the Unity interface or web dashboard is not authorization. If an ordinary account can manually call the underlying endpoint, the system is still vulnerable. Internal dashboards should use roles or explicit permissions, and sensitive actions should produce an audit record.

CORS is another common source of confusion. It is a browser policy controlling which origins can read responses. It is not a substitute for authentication, and it does not protect an API from non-browser clients. For WebGL, configure allowed origins narrowly and test preflight requests early. Cookies can be appropriate for browser applications, but their Secure, HttpOnly, and SameSite behavior must be understood rather than copied from an old tutorial.

I also avoid putting tokens, email addresses, or complete request bodies into routine logs. Logging is essential, but logs become another sensitive data store when everything is recorded indiscriminately. Record request identifiers, safe account identifiers, endpoint names, timing, and error categories. Redact credentials at the logging boundary so a debugging statement cannot accidentally expose them later.

What makes an internal web dashboard genuinely useful?

A dashboard should be designed around tasks, not around database tables. Exposing every field from a record might be quick for the developer, but it forces producers, support staff, and clients to understand implementation details. Instead, I identify the decisions a user needs to make: publish a configuration, review a submission, restore a known value, or inspect why an operation failed.

This is closely related to game tool development. While building products such as Home Designer, Floor Plan Designer, Easy Tooltips And Overlays, and Level Designer, I have had to think about discoverability, defaults, validation, and feedback. A powerful feature is not useful if users are afraid to touch it. The same principle applies to an internal web interface used during a live operation or a client presentation.

High-impact actions need friction in the right places. A destructive button should explain its scope, require confirmation, and preferably offer an undo path. Configuration publishing should show a preview or diff before activation. If a value must stay within a valid range, the interface should communicate that rule and the backend should enforce it again. Client-side validation improves the experience, but server-side validation protects the system.

I also recommend separating drafts from published data. A designer should be able to prepare changes without immediately affecting players. Publishing can create an immutable revision, recording who approved it and when. The game then requests a specific active revision rather than reading a half-edited working document. This model is more predictable and makes rollback much easier.

Finally, build accessibility and responsive behavior into the component system. Internal does not mean disposable. The person handling an urgent issue may be using a laptop, tablet, keyboard, or assistive technology. Clear labels, focus states, semantic controls, useful empty states, and visible loading feedback cost less when they are established early. They also make automated browser tests more reliable because controls have stable meaning.

Where should the boundary between Unity and the backend be drawn?

I draw the boundary by asking three questions. Who must be authoritative? How often does the data change? What happens if the network is unavailable? Security-sensitive decisions, shared persistent state, account ownership, and transactions belong on the backend. Frame-by-frame movement, camera response, animation, and moment-to-moment input belong in Unity. Configuration and progression often span both sides, so their ownership needs to be documented.

A backend should not sit inside the main gameplay loop. At 60 frames per second, a frame lasts about 16.7 milliseconds. Even a healthy internet request can take far longer, and mobile latency can vary dramatically. Calling an API from Update is therefore an architectural mistake, not a networking optimization problem. Fetch data at defined synchronization points, cache what is safe to cache, and let gameplay consume local representations.

I like shipping sensible local defaults with the client. Remote configuration can override those defaults after validation, but the game should know what to do before the first response arrives. Each payload should carry a schema version, and the client should reject versions it cannot interpret safely. Silently accepting unknown structures can create failures that are much harder to diagnose than a clear compatibility error.

Server authority does not require sending every calculation across the network. The server can validate important outcomes while the client performs presentation and prediction. The exact model depends on the genre and threat level. A single-player creative tool with cloud synchronization has different requirements from a competitive game, but both need conflict rules. If the same document changes on two devices, decide whether the server wins, the latest revision wins, fields merge, or the user resolves the conflict.

Keep personally identifiable information out of game payloads unless it is genuinely needed. The Unity client often needs a display name and an opaque account identifier, not a full customer record. Smaller, purpose-specific responses improve performance and reduce the impact of accidental logging or exposure.

How should Unity handle unreliable API requests?

Network failure is a normal state. A request can time out after the server completed it, a token can expire between screens, or a device can reconnect through a different network. I model API calls as operations with explicit loading, success, retryable failure, and permanent failure states. The interface should never spin forever because one callback was missed.

The following simplified coroutine demonstrates the boundaries I want in a Unity client. It applies a timeout, sends an access token, handles authentication separately, and deserializes only after a successful response. Production code should also inject the base URL, centralize token refresh, validate the payload, and route diagnostics through a logging service rather than scattering requests throughout gameplay scripts.

using System;
using System.Collections;
using UnityEngine;
using UnityEngine.Networking;

[Serializable]
public sealed class PlayerProfile
{
    public string id;
    public int schemaVersion;
    public string displayName;
}

public sealed class ProfileApi : MonoBehaviour
{
    [SerializeField] private string baseUrl;

    public IEnumerator GetProfile(
        string accessToken,
        Action<PlayerProfile> onSuccess,
        Action<long> onFailure)
    {
        using var request = UnityWebRequest.Get(baseUrl + "/v1/profiles/me");
        request.timeout = 10;
        request.SetRequestHeader("Authorization", "Bearer " + accessToken);
        request.SetRequestHeader("Accept", "application/json");

        yield return request.SendWebRequest();

        if (request.responseCode == 401)
        {
            onFailure?.Invoke(401);
            yield break;
        }

        if (request.result != UnityWebRequest.Result.Success)
        {
            Debug.LogWarning(
                $"Profile request failed with status {request.responseCode}");
            onFailure?.Invoke(request.responseCode);
            yield break;
        }

        var profile = JsonUtility.FromJson<PlayerProfile>(
            request.downloadHandler.text);
        onSuccess?.Invoke(profile);
    }
}

Retries require judgment. Retrying a timed-out read with exponential backoff and jitter is usually reasonable. Repeating a write can be dangerous unless the operation is idempotent. I cap retries and respect a server's rate-limit response rather than allowing every client to reconnect at once. A manual retry button can be better than an endless automatic loop.

Offline queues also need product rules. Queueing a cosmetic preference is different from queueing a purchase or competitive result. Store the minimum necessary data, protect it appropriately, include operation identifiers, and expire actions that no longer make sense. Most importantly, tell the player what happened. A clear message such as “saved locally, waiting to sync” is more trustworthy than pretending the server accepted something it never received.

How can teams test and deploy the web layer safely?

The web layer should have its own release pipeline, but it cannot be tested in isolation. I want unit tests for validation and permissions, integration tests against the database, contract tests for API responses, and a small set of browser tests covering critical dashboard tasks. Unity also needs tests against a real staging service because serialization, headers, CORS, and platform behavior can differ from mocks.

Staging should resemble production in configuration without copying sensitive production data into a casual test environment. Seed it with deliberate scenarios: a new account, an expired session, an unsupported schema version, an empty list, a rate-limited request, and a partially completed workflow. Happy-path test data produces dashboards that look polished until the first real support incident.

Database migrations deserve special care because application code can be rolled back more easily than transformed data. I prefer an expand, migrate, and contract sequence. First add a compatible field or table. Next deploy code that can work with old and new representations while data is migrated. Remove the old structure only after every active application version has stopped depending on it. This is slower than a destructive rename, but much safer.

Deploy frontend, backend, and Unity changes so adjacent versions remain compatible. A website can update in minutes, while a game build may wait for platform review or remain installed for months. Feature flags can separate deployment from activation, but each flag needs an owner and a removal plan. Otherwise, the codebase accumulates permanent branches that nobody understands.

Observability completes the pipeline. Track request rates, latency, error categories, authentication failures, and background job health. Give each request a correlation identifier that can travel from the Unity client through the API and its dependencies. Alerts should represent user impact rather than every harmless exception. When something goes wrong, the team needs to answer which operation failed, which version sent it, and whether retrying is safe. A rollback plan should be written before the release, not invented while customers are waiting.

What web technology should a Unity developer learn in 2026?

My opinion in 2026 is that fundamentals are a better investment than chasing a framework leaderboard. Learn HTTP, browser security, semantic HTML, CSS layout, JavaScript or TypeScript, SQL, authentication, and deployment. Frameworks package these concepts, but they do not remove them. When a cookie is rejected or a request is cached incorrectly, understanding the platform is more useful than memorizing a component API.

For the backend, choose a mature ecosystem the team can operate. A Unity-heavy C# team may be productive with ASP.NET Core because language skills and data models transfer naturally. Teams can also succeed with Laravel, Node.js frameworks, or other established platforms. The important questions are less glamorous: Can the team patch it? Can new developers understand it? Does it support migrations, background jobs, structured logging, testing, and the authentication model you need?

Use a relational database by default when the data has relationships, constraints, and transactional rules. Add caches, search engines, document stores, or queues when a measured requirement justifies them. Starting with five infrastructure products does not make an application scalable. It creates five operational responsibilities before the team has users or evidence.

On the frontend, component-based development is valuable, but the dashboard does not automatically need a large single-page application. A server-rendered interface can be faster to build, simpler to secure, and easier to maintain. Choose a richer client when the workflow genuinely needs complex local state, real-time interaction, or reusable interactive components. Progressive enhancement is still a strong strategy for forms and administrative tools.

My broader career, including Eagle Flight Arcade in 2016, Touch Camera PRO, and freelance work across games, interactive experiences, and business clients, has made me skeptical of technology chosen for prestige. The best stack is the one that lets a team ship, inspect, repair, and eventually hand over the system. In 2025 and 2026, AI-assisted coding can accelerate implementation, but it does not own the consequences of an insecure endpoint or destructive migration. Keep architecture understandable, review generated code, and make production behavior visible.

References & Further Reading

Shipping Runtime AI in Unity: Build Guardrails Before Prompts

Anthony KOZAK — Mon, 27 Jul 2026 08:02:50 +0000

AI prototypes are easy to celebrate and surprisingly hard to ship. In 2026, a Unity developer can connect a model to a dialogue box in an afternoon, but that says nothing about latency, safety, platform support, testing, or maintenance. After 16 years in game development, I care less about whether a model can produce an impressive answer and more about whether the feature survives a bad connection, a provider update, and an inventive player. My work has ranged from Eagle Flight Arcade at Ubisoft Montreal in 2016 to Touch Camera PRO and client projects such as Meta Spirit Sling and Loreal Viva Tech 2024. Those projects do not prove that every game needs AI. They explain why I approach runtime AI as production infrastructure rather than magic.

Key Takeaways

Give AI narrow responsibilities and keep authoritative game state deterministic.
Put provider credentials and validation behind a backend you control.
Treat every model response as untrusted external input.
Test requirements and failure modes instead of expecting identical sentences.
Design explicit fallbacks for latency, outages, cost limits, and offline play.

What Should an AI Feature Be Allowed to Control?

The first production question is not which model to use. It is what the model is allowed to control. I divide possible responsibilities into three categories: presentation, recommendation, and authority. Presentation includes rewriting a hint or adapting the tone of a tutorial. Recommendation includes selecting a likely response, suggesting an item, or ranking authored options. Authority includes changing inventory, awarding currency, resolving combat, saving progression, or making a purchase. I am comfortable experimenting with the first two. I strongly resist giving a generative model the third.

That line comes from conventional game development. Eagle Flight Arcade was a VR flight game shipped in 2016 on PSVR, Oculus Rift, and HTC Vive. Its feel depended on controlled movement, predictable rules, and platform-aware behavior. Touch Camera PRO has the same basic obligation in a different context. A camera controller must respond consistently when a player pinches, pans, follows a target, or hits a boundary. A clever but unpredictable answer is not a substitute for reliable interaction. Runtime AI should usually sit beside the simulation, not become the simulation.

I therefore define an output contract before writing a prompt. A hint system might let a model choose one hint identifier from an allowlist. A conversational character might select an authored intent plus optional display text. A level assistant might propose parameters, but deterministic code validates and applies them. For every output, I ask what happens if it is empty, malformed, hostile, irrelevant, or ten seconds late. If the answer is that progression breaks, the model owns too much. A useful feature can be summarized as: AI proposes, code verifies, and the game decides. That sentence is far more valuable than a giant system prompt.

Should the Model Run on the Device or Behind a Server?

On-device inference, server inference, and hybrid architecture solve different problems. Local execution can improve privacy, remove per-request network latency, and support offline play. It also adds model files to the build, consumes memory, competes for CPU or GPU time, and behaves differently across hardware. That last issue matters in Unity because one project may target desktop, mobile, consoles, WebGL, or standalone VR. A model that feels acceptable on a development PC may be inappropriate on the lowest supported phone or headset.

Server inference makes model upgrades easier and gives the team tighter control over credentials, rate limits, logging, and provider selection. The tradeoffs are network dependency, operating cost, regional availability, and additional privacy work. A provider key must never be embedded in a Unity client. Players can inspect builds and network traffic, so a secret stored in the application should be treated as already exposed. My preferred server design sends compact game context to an endpoint I control. That backend authenticates the player, removes unnecessary data, calls the model provider, validates the response, and returns a small application-specific result.

For many games, the practical answer in 2026 is hybrid. Deterministic local logic remains the foundation. A server model adds optional language or recommendation features, while authored content handles offline and failure states. Smaller local models can support narrow classification tasks when the target hardware justifies the download and performance cost. I make this decision from a platform matrix, not a model leaderboard. List every supported device, expected connection state, memory constraint, privacy requirement, and acceptable wait. Then profile the actual build on the weakest hardware. Shipping Eagle Flight Arcade across three VR platforms reinforced a lesson that still applies: platform differences are product requirements, not cleanup tasks for the final week.

How Can Nondeterministic Output Be Made Safe?

A low temperature does not turn a generative model into deterministic game code. Providers update infrastructure, model versions change, and tiny context differences can alter an answer. I treat model output exactly like data received from an unknown external service. It crosses a trust boundary and must pass validation before any gameplay system, save file, UI renderer, or analytics event uses it. Prompting is useful guidance, but a prompt is not a security boundary and it is not a schema validator.

I use three validation layers. The syntactic layer checks whether the response matches the expected JSON shape, types, required fields, and size limits. The semantic layer checks allowlists, text length, supported locales, prohibited markup, and numeric ranges. The game-state layer asks whether the requested action is legal right now. A generated command to unlock a door is rejected if the player has not met the deterministic unlock conditions. A generated hint identifier is rejected if it does not belong to the current objective. Free text should be escaped before rendering, and arbitrary URLs, rich-text tags, asset paths, or executable command names should not be accepted.

Every request also needs a boring fallback. I usually prefer an authored default over repeated model calls. One controlled retry may be reasonable for a transient transport failure, but repeatedly asking a model to repair its own invalid output increases latency and cost without guaranteeing success. Prompts, schemas, model identifiers, and validation rules should be versioned together so a regression can be traced. Logs can record timing, failure category, token usage, and version identifiers, but they should avoid raw personal or sensitive content. Most importantly, players must not be able to inject instructions through names, chat, imported files, or community content that the application blindly places inside a privileged prompt. Data is data, even when it contains convincing instructions.

What Does a Maintainable Unity Integration Look Like?

I do not let gameplay scripts know which AI provider is being used. The Unity side should depend on a small interface expressed in the language of the game, such as requesting a hint, classifying an intent, or summarizing an authored journal entry. A provider adapter can live behind that boundary, preferably on a backend for cloud models. This keeps networking details, authentication, provider response formats, and model migrations out of scenes and MonoBehaviours. It also makes the feature testable with a fake implementation.

using System;

using System.Threading;

using System.Threading.Tasks;

using UnityEngine;

public interface IAiHintService

{

    Task<AiHintResult> GetHintAsync(

        AiHintRequest request,

        CancellationToken cancellationToken);

}

[Serializable]

public sealed class AiHintRequest

{

    public string objectiveId;

    public string locale;

    public string[] allowedHintIds;

}

public readonly struct AiHintResult

{

    public bool Success { get; }

    public string HintId { get; }

public AiHintResult(bool success, string hintId)
{
    Success = success;
    HintId = hintId;
}


}

public sealed class HintController : MonoBehaviour

{

    private IAiHintService _service;

    private CancellationTokenSource _request;

    private int _requestVersion;

public void Install(IAiHintService service)
{
    _service = service;
}

public async void RequestHint(
    string objectiveId,
    string[] allowedHintIds)
{
    if (_service == null)
    {
        ShowFallback();
        return;
    }

    _request?.Cancel();
    _request?.Dispose();
    _request = new CancellationTokenSource();
    int version = ++_requestVersion;

    var input = new AiHintRequest
    {
        objectiveId = objectiveId,
        locale = Application.systemLanguage.ToString(),
        allowedHintIds = allowedHintIds
    };

    try
    {
        AiHintResult result = await _service.GetHintAsync(
            input, _request.Token);

        if (version != _requestVersion)
            return;

        if (result.Success &amp;&amp;
            Array.IndexOf(allowedHintIds, result.HintId) &gt;= 0)
        {
            ShowAuthoredHint(result.HintId);
        }
        else
        {
            ShowFallback();
        }
    }
    catch (OperationCanceledException)
    {
        if (version == _requestVersion)
            ShowFallback();
    }
    catch (Exception exception)
    {
        Debug.LogException(exception);
        ShowFallback();
    }
}

private void OnDestroy()
{
    _request?.Cancel();
    _request?.Dispose();
}

private void ShowAuthoredHint(string hintId) =&gt;
    Debug.Log($&quot;Show hint: {hintId}&quot;);

private void ShowFallback() =&gt;
    Debug.Log(&quot;Show the authored fallback hint.&quot;);


}

The important detail is that the model returns an identifier from an allowlist, not an instruction that directly manipulates the scene. Local code still verifies the identifier and maps it to authored content. For a feature that genuinely needs generated prose, I would expand the result object with explicit validation status, moderation status, model version, and a safe display string. I would not return an unstructured provider response to the UI.

Cancellation and request ownership also matter. Players close menus, change objectives, reload scenes, and make a second request before the first finishes. Old responses must not overwrite current state. Timeouts belong in the service layer, while visible fallbacks belong in the feature layer. Finally, all Unity object access should remain on the Unity main thread. Parsing, transport, and validation can be separated, but a background callback should not casually modify a GameObject. Clean boundaries make these rules much easier to enforce.

How Do You Test a Feature Whose Answers Keep Changing?

Traditional unit tests compare a known input with an exact output. That is still appropriate for validators, allowlists, parsers, fallbacks, and state transitions, but it is usually the wrong test for generated language. I test properties instead. Did the response use the requested language? Is it below the display limit? Does it avoid revealing hidden information? Did it select an allowed intent? Does the feature reach a valid fallback when the response is malformed? These requirements are stable even when the wording changes.

I recommend building an evaluation set before launch. Start with representative normal cases, then add empty context, contradictory context, very long input, unsupported languages, prompt injection attempts, offensive player names, network timeouts, and requests made during scene changes. Fifty carefully chosen cases can reveal more than hundreds of casual prompts, although the right size depends on the feature. Each case should have machine-checkable rules plus a small human review rubric for relevance, tone, factual consistency, and usefulness. Do not collapse everything into one vague quality score. A response can sound excellent while violating a progression rule.

My preferred pipeline has three layers. Fast continuous integration tests exercise deterministic code with fake and recorded responses. A scheduled evaluation calls the current model and compares pass rates by prompt, schema, and model version. Human reviewers inspect sampled failures and sensitive categories before a release. This avoids paying for live model calls on every code commit while still detecting provider drift. It also creates evidence for model changes instead of relying on someone saying the new output feels better.

Localization deserves its own evaluation set. Text expansion, gender, formality, cultural context, unsupported characters, and right-to-left layouts can expose both model and UI failures. Test on the actual Unity screens, not only in a provider playground. A sentence that is acceptable in isolation may cover a button, break subtitles, or conflict with an authored voice line. The final product is the game experience, not the raw response.

How Should Latency, Cost, and Offline Play Shape the UX?

Runtime AI introduces a new timing category. A normal button press should feel immediate, but a network model may take seconds or fail entirely. My UX rule is to acknowledge input within roughly 100 milliseconds, show honest progress if work continues, and provide a cancel or fallback path when a wait becomes noticeable. Those are design targets, not promises that every provider will meet them. The feature should never freeze the main thread, block scene loading indefinitely, or leave a player staring at an animation that implies success is guaranteed.

Streaming text can reduce perceived latency, but it creates additional problems. Partial output may contain markup, unfinished sentences, or content that has not passed final validation. For many game features, I prefer waiting for a complete, validated response and showing an authored transitional state. If streaming is central to the experience, validate chunks conservatively and reserve the right to replace the output with a safe fallback. In VR, unstable frame timing is far more damaging than a slow text response. My experience with Eagle Flight Arcade made me strict about keeping optional services away from frame-critical movement, rendering, and input paths.

Cost should be designed like memory or bandwidth, not discovered after launch. Estimate requests per active session, input size, output limits, retries, moderation calls, and the cost of abuse. Then enforce server-side quotas and rate limits. Compact structured context is usually better than sending an entire conversation or save file. Cache only when the request is nonpersonal, the result is safe to reuse, and invalidation is understood. Deduplicate repeated button presses and set hard output limits. A cheaper model can handle classification while a more capable model is reserved for rare, genuinely complex requests.

Offline behavior must be visible in the feature specification. A game may use an authored hint, disable optional generation, queue a nonurgent request, or use a small local classifier. What it should not do is silently break. If the core loop cannot function without an external model, the team is operating a live service whether it planned to or not.

What Privacy and Security Work Is Required Before Launch?

Before integrating a model, I create a data map. What leaves the device? Does it include chat, account identifiers, location, voice transcripts, screenshots, save data, or user-generated content? Where is it processed, how long is it retained, who can access it, and how can it be deleted? The safest input is information the feature never collects. Data minimization also reduces token cost and makes prompts easier to reason about, so privacy and engineering quality often point in the same direction.

The Unity client should communicate with an authenticated backend over secure transport. That backend should enforce request size limits, per-user and per-device rate limits, model allowlists, timeouts, and spending controls. Provider credentials stay on the server and should be rotatable. Logs need access controls and retention rules. If debugging requires examples, use redacted or synthetic cases whenever possible. Projects aimed at children, workplaces, health-related contexts, or public installations may need additional legal and policy review. A developer should not guess at those obligations from a model provider's marketing page.

Prompt injection is only one part of the threat model. A player might submit huge inputs to increase cost, automate requests, place hostile instructions in imported content, attempt to expose hidden prompts, or persuade the model to emit unsupported commands. Output can also become an injection channel if the game interprets rich text, URLs, filenames, or tool names. The defense is architectural: separate instructions from untrusted data, expose narrowly scoped tools, validate every argument, authorize actions in conventional code, and encode text for its destination.

I also think teams need honest player communication. Explain when content is generated, when data is sent to a service, and what happens if the service is unavailable. Provide reporting tools when players can encounter generated public content. On freelance work, whether the client is an indie team or a much larger organization, I ask these questions before polishing the prompt. Security added after a successful prototype is usually expensive because the prototype already gave the model too much data and authority.

When Is Conventional Game Logic Better Than Generative AI?

Generative AI is the wrong tool when a feature has a small state space, strict timing, exact balancing, or a clear algorithmic solution. State machines, behavior trees, utility systems, procedural algorithms, search, authored dialogue, and ordinary databases remain excellent technology. They are fast, inspectable, testable, and available offline. A camera controller such as Touch Camera PRO should not ask a model how far to pan. A level rule should not become probabilistic merely because a prompt looks shorter than the equivalent code.

I use a simple filter. Does the task require open-ended language or fuzzy interpretation? Can the result be verified before use? Can the player recover from a bad answer? Is a fallback available? Is the value worth the latency, cost, privacy work, and vendor dependency? If several answers are no, I reject runtime generation. Sometimes AI can still help during development, but that is a separate decision from putting a model call in the shipped product. Tools such as Tutorial Engine, Level Designer, and Touch Camera PRO serve developers by making repeatable behavior easier to author. Predictability is often the feature.

The same skepticism applies to fashionable autonomous agents. Giving a model more tools and more context can make a demonstration look capable, but it also expands the number of actions, failure states, and security checks. I prefer the smallest useful capability. One validated request that selects an authored hint may create more player value than an elaborate agent that reads the entire save and attempts to manage the experience. Scope is not a failure of ambition. It is how a team creates something supportable.

AI in 2026 is useful enough that developers should understand it, but unstable enough that architecture matters more than hype. My shipping checklist is straightforward: define authority, choose the execution location, validate input and output, provide a deterministic fallback, measure latency and cost, build evaluations, review privacy, and plan provider replacement. If a feature still makes sense after that work is visible, build it. If it only looked attractive when failure was ignored, conventional code has already given you the answer.

References & Further Reading

Unity 7: A Game Developer's Revolution on the Horizon

Anthony KOZAK — Fri, 24 Jul 2026 10:01:54 +0000

Unity 7: A Game Developer's Revolution on the Horizon

As we've entered an era where game development platforms are expected to be not just powerful but also intuitive, Unity Technologies recently announced what seems to be a revolutionary update: Unity 7. Unveiled at the Unite Seoul conference on July 21, 2026, this new iteration is touted as a next-gen production platform designed to streamline development and offer unprecedented collaboration capabilities for teams across the globe. Unlike a typical point release, Unity 7 is being pitched less as "a new version of the engine" and more as a rethink of how the entire production pipeline — code, art, lighting, and now AI collaborators — fits together. Let's dive into what Unity 7 has to offer, feature by feature, and what this means for developers everywhere.

Key Takeaways

Unity 7 introduces a 'Zero Rebuild' feature, promising seamless transitions from Unity 6 with no disruptive rebuilds.
The new CoreCLR scripting runtime enhances the speed and efficiency of developing within Unity.
Shader compilation in Unity 7 is up to 90% faster, reflecting immense improvements in code execution efficiency.
Play Mode launch is described as near-instant, targeting one of Unity's most notorious iteration bottlenecks.
Unity 7 is designed as an open collaboration platform with enhanced integration into AI coding tools.
Surface Cache, a new global-illumination rendering system, is set to transform visual rendering in gaming.

What Is Unity 7, and Why Is Unity Technologies Calling It a "Platform" Instead of Just an Engine?

Unity 7 represents a significant leap forward in Unity's evolution, both technologically and strategically. Rather than framing it purely as a rendering-and-scripting engine, Unity Technologies is positioning Unity 7 as a production platform — a shared space where developers, artists, producers, and AI coding agents can work side by side across the entire lifecycle of a game, from prototyping through live-service updates. That framing matters because it signals where Unity thinks the next competitive battleground actually is: not raw graphical horsepower, which has become table stakes across modern engines, but how fast a mixed team of humans and tools can move from idea to shipped build without stepping on each other.

This is particularly crucial as the demand for more sophisticated and expansive games continues to rise, often built by teams that are smaller, more distributed, and more reliant on external contractors and freelancers than ever before. A platform-first approach means the tooling around the engine — collaboration surfaces, permissions, AI-assisted workflows — is being treated as a first-class part of the product, not an afterthought bolted on after the rendering and scripting fundamentals are locked in.

What Exactly Does Unity's "Zero Rebuild" Promise Mean for Existing Projects?

Major engine upgrades have historically been a source of dread for studios running live games. New rendering pipelines, breaking API changes, and asset reimport requirements have, in past Unity version jumps, forced teams to choose between staying on an aging version indefinitely or burning weeks of engineering time just to get back to parity after an upgrade. Unity 7's headline promise is meant to directly address that pain: every foundational piece of the new platform, including the CoreCLR scripting runtime and the Surface Cache rendering system discussed below, is being shipped and production-verified inside Unity 6 first, before it ever appears as part of Unity 7 proper.

Practically, that means a studio already running a Unity 6 project has effectively already been running on Unity 7's core technology for some time by the point the full release lands — just without the version number changing underneath them. The goal is that moving from Unity 6 to Unity 7 becomes closer to flipping a switch than performing a migration, since the risky, breaking parts of the upgrade were absorbed earlier, in smaller, well-tested increments. For teams maintaining a live game with a real player base, that is arguably a bigger deal than any single new rendering feature — it changes the calculus of whether upgrading is worth the risk at all.

How Does the New CoreCLR Scripting Runtime Change C# Development in Unity?

CoreCLR is the same runtime family that already underpins the broader modern .NET ecosystem — the same technology stack powering ASP.NET Core services and current-generation .NET desktop applications outside of games entirely. Across that wider ecosystem, CoreCLR is known for things like tiered JIT compilation (starting code execution quickly, then optimizing hot paths as they're identified), stronger garbage collection tuning options, and closer alignment with the mainstream .NET tooling and library ecosystem than older, embedded runtimes typically offer.

For Unity developers, who have long worked with a Mono-based scripting runtime under the hood, a move toward a CoreCLR foundation is significant less because of any single benchmark number — Unity has not published detailed head-to-head performance figures as of this writing — and more because of what it represents: closer parity with how C# performs and is tooled everywhere else in the industry. That can mean fewer workarounds for library compatibility, easier hiring and onboarding for engineers coming from non-game .NET backgrounds, and a scripting layer that benefits from improvements Microsoft ships to the wider .NET runtime going forward, rather than waiting on a game-specific fork to catch up.

Just How Much Faster Is Shader Compilation, and Why Should Developers Care?

Shader compilation has been one of the most persistent, unglamorous sources of friction in real-time 3D development. Tweak a material property, add a new shader variant for a platform-specific feature, or bring in a new lighting model, and the editor can grind through a compilation pass that pulls a developer or technical artist out of flow for anywhere from several seconds to several minutes, especially on larger projects with sprawling shader variant matrices. Multiply that across a full day of iteration, by every artist and engineer touching materials, and it becomes a meaningful tax on total studio output.

Unity 7's headline claim here is shader compilation up to 90% faster than in prior versions. Even taken as a best-case figure rather than a universal guarantee, a reduction anywhere near that scale would meaningfully shrink the "wait and stare at a progress bar" portion of a technical artist's day, and make late-stage lighting and material iteration far less punishing. Consider a simplified shader like the one below — the kind of everyday, unglamorous code that developers recompile constantly during iteration, and exactly the workload this improvement targets:

// Sample Shader - Simpler and Faster
Shader "Custom/FastShader" {
   Properties {
      _Color ("Main Color", Color) = (1,1,1,1)
   }
   SubShader {
      Pass {
         CGPROGRAM
         #pragma vertex vert
         #pragma fragment frag
         struct appdata {
            float4 vertex : POSITION;
         };
         struct v2f {
            float4 pos : SV_POSITION;
         };
         float4 _Color;
         v2f vert (appdata v) {
            v2f o;
            o.pos = UnityObjectToClipPos(v.vertex);
            return o;
         }
         fixed4 frag (v2f i) : SV_Target {
            return _Color;
         }
         ENDCG
      }
   }
   FallBack "Diffuse"
}

What Does Near-Instant Play Mode Launch Actually Save Developers?

Alongside shader compilation, Unity 7 is being positioned as delivering nearly instant Play Mode launches. Anyone who has worked in Unity at scale knows the ritual: hit the Play button, then wait through domain reloads, script recompilation, and scene reinitialization before actually being able to test a change. On a small prototype that wait might be negligible; on a large production project with thousands of scripts and assets, it can stretch into a genuinely disruptive pause, repeated dozens of times a day per developer.

Iteration speed compounds. A developer who can test a tweak in one second instead of ten will simply try more things — more variations on a game-feel parameter, more experiments with an enemy's behavior tree, more quick sanity checks before committing to a design direction. Faster Play Mode entry is exactly the kind of unglamorous, quality-of-life improvement that doesn't show up on a feature list slide but adds up to real, measurable gains in how much a team can explore and polish within the same production schedule.

What Does Unity 7's Open Collaboration Platform Look Like in Practice?

Unity 7 advances its capabilities as a collaborative platform, supporting seamless integration of AI coding tools alongside the traditional mix of engineers, artists, and producers. This facet is particularly important as development teams become more distributed and multi-disciplinary, frequently spanning multiple studios, time zones, and freelance contributors on a single project. The broader industry has been moving toward AI-assisted coding and content workflows for several years now; Unity 7's pitch is to make that integration a native part of the platform rather than something bolted on through third-party plugins, so that an AI coding agent can participate in a project's workflow — reviewing changes, assisting with implementation, flagging issues — alongside human collaborators rather than as a separate, disconnected tool.

For studios that already lean on a patchwork of external tools to keep distributed teams in sync, a first-party collaboration layer that treats AI agents as legitimate participants in the pipeline — rather than an afterthought — could meaningfully reduce the tooling overhead that currently sits between "have an idea" and "see it running in the game."

What Is Surface Cache, and How Could It Change Lighting Workflows?

The "Surface Cache" feature marks a notable advancement in global illumination rendering. Real-time GI has always forced a trade-off: fully dynamic lighting solutions tend to be expensive and can introduce artifacts like light leaking, while baked lighting solutions look great but lock scenes into long precompute times and make dynamic time-of-day or destructible environments painful to support. A cache-based approach to surface lighting information suggests Unity is aiming squarely at that middle ground — retaining enough precomputed or reusable lighting data to keep performance costs down, while still allowing scenes to update dynamically without the punishing bake times traditionally associated with high-quality GI.

If it delivers on that promise, Surface Cache could be one of the more visible wins for smaller teams in particular. High-end global illumination has often been the domain of AAA studios with dedicated rendering engineers; a system that gets teams closer to that visual bar without demanding the same specialized expertise would be a genuine democratization of a previously expensive-to-achieve look.

How Does Unity 7's Timeline Position It Against Unreal Engine?

The official beta for Unity 7 is expected to open in December 2026, with a general release targeted for Q1 2027. Industry coverage of the announcement has framed this timeline as putting Unity roughly a year ahead of Unreal Engine's next comparable major release — a notable shift in a rivalry where Unreal has often been perceived as setting the pace on rendering technology in recent years.

Release timing matters more than it might first appear for engine selection decisions. Studios evaluating which engine to commit a multi-year project to are, in effect, betting on a roadmap as much as a feature set at any single point in time. Being first to market with a platform-level upgrade — rather than following a competitor's release — gives Unity a window to capture studios that might otherwise wait and see what Unreal ships next before committing.

What Should Studios and Solo Developers Do Between Now and the Beta?

With several months before the December 2026 beta opens, the most productive stance for most teams is preparation rather than premature migration. That means auditing which parts of a current Unity 6 project already depend on the pieces Unity has said are being shipped early — the CoreCLR runtime and Surface Cache rendering — so that when Unity 7 lands, the delta to test is as small as possible. It also means resisting the urge to overhaul a production pipeline around headline numbers like "90% faster shader compilation" before independently verifying them on real project content once the beta is available, since marketing figures and in-production results don't always match exactly.

For solo developers and small teams in particular, the safest approach is to keep an eye on the beta program once it opens, read early hands-on impressions from studios that do jump in immediately, and plan any engine-version upgrade for a natural break point in a project's schedule rather than mid-sprint. A platform-level shift like this is worth adopting deliberately, not reactively.

It's also worth remembering that a beta period exists precisely to surface the gap between announced capability and shipped reality. Shader compilation and Play Mode speedups in particular are the kind of claims that can vary considerably depending on project size, target platform, and existing shader complexity, so teams with performance-sensitive production pipelines should budget time during the beta to benchmark against their own actual content rather than taking headline percentages at face value.

References & Further Reading

Exploring the Evolution of VR/XR in Game Development

Anthony KOZAK — Thu, 23 Jul 2026 22:08:41 +0000

Exploring the Evolution of VR/XR in Game Development

The landscape of game development is undergoing a momentous transformation, largely driven by the rapid advancements in Virtual Reality (VR) and Extended Reality (XR) technologies. Over the past decade, these technologies have matured, pushing the boundaries of immersive experience and altering the way we conceptualize interactive entertainment. From my own journey with Eagle Flight VR at Ubisoft to my freelance projects with diverse clients, I've witnessed the compelling evolution of VR and XR firsthand. Here’s an exploration into how VR/XR is shaping the future of game development.

Key Takeaways

VR/XR technologies are dramatically enhancing the immersion factor in gaming experiences.
The hardware landscape for VR/XR is rapidly evolving, offering developers more powerful tools.
Understanding player comfort and reducing motion sickness remain critical for VR/XR game success.
Integration with AI technologies is opening new frontiers for dynamic and responsive XR environments.
Cross-platform compatibility is becoming increasingly important in VR/XR development.

Why is VR/XR Immersion Revolutionizing Game Design?

The cornerstone of VR and XR revolutions in gaming lies in their ability to deliver unparalleled levels of immersion. This has been a game-changer as developers strive to make games less about pixels on a screen and more about experiences in a 3D space. With VR/XR, game worlds feel more tactile and emotional because they engage multiple senses simultaneously. While working on Eagle Flight, I was focused on flight mechanics that leveraged head tracking to create a sense of genuine flight, an experience standard gaming couldn’t match.

Moreover, both VR and XR have expanded possibilities for game mechanics and storytelling. In XR, for instance, players can interact with digital and physical spaces concurrently, providing an unprecedented narrative possibility where the player becomes an actual part of the story world. But mastering this requires more than just tech—it demands a new language of game design that we are only beginning to fully articulate.

What Role Does Hardware Play in VR/XR Evolution?

Hardware advancements are critical to the evolution of VR/XR game development. Devices like Meta Quest 3 and the latest iterations of HTC Vive and Valve Index have pushed the envelope, allowing for more complex, high-performance VR experiences. These platforms come with reduced latency, improved display resolutions, and expansive tracking capabilities. This progress means developers are no longer constrained by the hardware limitations that early VR pioneers faced, opening up new creative possibilities.

While working on various projects including Magic Massages and Crazy Coaster, I've seen firsthand how hardware capabilities can determine the scope and ambition of the VR/XR experiences we build. Today, leveraging the latest headset tech is not just an advantage but a necessity for developers who aim to create cutting-edge VR content.

How Can Developers Overcome Motion Sickness in VR Experiences?

Despite the remarkable progress, VR adoption still grapples with the issue of motion sickness—a challenge that persists uniquely with this medium. Motion sickness is often caused by the lag between visual motion and physical sensation. While designing Eagle Flight, we approached this by meticulously optimizing frame rates and innovating player-oriented motion techniques to mitigate disorientation.

Best practices now include avoiding movements or environmental rotations that could confuse the player’s inner ear. Implementing gradual acceleration and deceleration, offering comfort modes, and allowing players to control their distance and positioning through gaze and gesture are critical strategies for alleviating discomfort.

How Does AI Enhance VR/XR Environments?

AI's role in VR/XR is undeniably crucial. It's transforming these immersive environments into adaptive, intelligent entities. AI can dynamically alter scenarios based on player interactions, making virtual worlds feel more responsive and alive. For instance, in Mindsight Journey, we employed AI to adjust challenge levels on-the-fly based on player performance, fostering a personalized gaming experience. In parallel, AI algorithms contribute to reducing VR's data load by effectively predicting and rendering what the player might need to see next.

// Example of using AI for dynamic scene adjustment in Unity C#
void AdjustDifficulty(Player player, Scene scene) {
    if (player.performanceMetrics.reactionTime < threshold) {
        scene.Difficulty += difficultyIncrement;
    } else {
        scene.Difficulty -= difficultyDecrement;
    }
}

Why is Cross-Platform Compatibility Important in VR/XR Development?

As VR/XR games diversify, ensuring compatibility across multiple devices is increasingly vital. Developers must ensure their titles operate seamlessly on various hardware without sacrificing quality. During my tenure with Ubisoft and subsequent freelance ventures, I’ve dealt extensively with the intricacies of cross-platform development. Consistency in performance and visual fidelity across different platforms like Oculus, SteamVR, and proprietary devices are not just technical challenges—they also influence marketability.

Experienced developers now adopt engines like Unity and Unreal, equipped with robust cross-platform compatibility features. These tools enable efficient deployment across various systems, ensuring that developers can extend their reach to broader audiences without being hampered by technical complexity.

Closing Thoughts

The continued evolution of VR/XR heralds an exciting era for game creators and consumers alike. As these technologies advance, they will redefine how we perceive and interact with digital spaces, turning the impossible into a reality within our reach. For developers, now is an opportune time to embrace these tools, learn their quirks, and explore the immense potential they offer.