How Do You Structure a Unity Project That Can Survive Years of Change?
---
title: "How Do You Structure a Unity Project That Can Survive Years of Change?"
published: true
canonical_url: exoa.dev
description: "Learn how to structure Unity projects for safer features, platform changes, team growth, and long-term maintenance."
---
<p>A Unity project rarely becomes difficult because one programmer wrote one bad class. It becomes difficult because hundreds of reasonable local decisions slowly remove the project's boundaries. After 16 years in game development, including shipping Eagle Flight Arcade as a Gameplay Programmer at Ubisoft Montreal in 2016 and maintaining products such as Touch Camera PRO, I have learned to treat changeability as a production feature. A project that works today but resists tomorrow's platform SDK, control scheme, or content request is already accumulating risk.</p>
<div class="key-takeaways"><strong>Key Takeaways</strong><ul><li>Organize Unity projects around features and ownership, not only file types.</li><li>Use assembly definitions to enforce a small number of meaningful boundaries.</li><li>Keep platform APIs, global state, and scene references behind explicit seams.</li><li>Automate architectural checks before conventions become optional.</li><li>Refactor incrementally while delivering features instead of waiting for a rewrite.</li></ul></div>
<h2>What Actually Makes a Unity Project Hard to Change?</h2>
<p>The real enemy is not the number of scripts. It is the distance between a requested change and its unexpected consequences. A menu adjustment should not require knowledge of the save format, platform achievements, character movement, and analytics. When it does, the project has lost separation between responsibilities. Unity makes this easy to miss because almost anything can reference a MonoBehaviour, find an object in a scene, or reach a static singleton.</p>
<p>I saw the importance of explicit responsibilities while working on Eagle Flight Arcade at Ubisoft Montreal in 2016. A VR game shipping across PSVR, Oculus Rift, and HTC Vive could not treat hardware assumptions as harmless details. The broader lesson applies to every Unity project. Platform code changes faster than core game rules, presentation changes faster than persistent data, and prototypes change faster than production infrastructure. If those rates of change are mixed together, every update becomes a project-wide negotiation.</p>
<p>I evaluate architecture by asking three questions. Which code owns this decision? What is allowed to depend on it? How would I replace it without editing unrelated features? If the answers are unclear, the system probably relies on accidental coupling. A public field in the Inspector may look convenient, but it still creates a dependency. The same is true for a static event, a Resources load, or a scene object discovered by name.</p>
<p>This does not mean every game needs enterprise-style abstraction. Small prototypes should remain small. The important distinction is whether a shortcut is contained. I am comfortable taking on debt when I can name it, locate it, and remove it. Unnamed debt spread across scenes, prefabs, and global services is what turns an ordinary feature request into a dangerous change.</p>
<h2>Where Should You Draw Boundaries Inside a Unity Project?</h2>
<p>I start with rates of change, not a favorite diagram. Code that changes for the same reason should usually live together. Code that changes for different reasons should communicate through a narrow contract. In a typical Unity project, I separate core rules, feature implementation, presentation, persistence, platform integration, and editor tooling. Those categories can become assemblies, but the conceptual boundary matters before the file structure does.</p>
<p>Features should own as much of their vertical path as practical. An inventory feature might contain its rules, data types, runtime controller, UI presenter, tests, and authoring tools. That is often easier to maintain than placing every view in one global UI folder, every data class in another, and every manager in a third. A developer investigating inventory behavior can then inspect one coherent area rather than tracing references across the whole repository.</p>
<p>Platform integrations belong at the outside edge. Steam, console services, mobile notifications, VR runtimes, and vendor-specific input should adapt external APIs into contracts understood by the game. Core rules should not know which SDK provided an identity, controller pose, purchase result, or storage location. This makes editor simulation easier and reduces the blast radius when a package changes during 2025 or 2026.</p>
<p>I also separate runtime code from authoring code. Custom inspectors, import processors, validation windows, and content generators are valuable, but a player build should never depend on an editor assembly. My Unity Asset Store work, especially Touch Camera PRO and tools such as Tutorial Engine and Level Designer, reinforced this discipline. A reusable package cannot assume that it owns the host project's scenes, initialization order, input setup, or folder conventions.</p>
<p>A useful boundary has a clear owner and a small public surface. If two modules constantly reach into each other's internal state, they are either one module pretending to be two or they need a better contract. Architecture is not the number of boxes in a diagram. It is the set of changes that each box can absorb independently.</p>
<h2>How Should Scenes, Prefabs, and Assets Be Organized?</h2>
<p>Unity architecture is not only C# architecture. Scenes, prefabs, ScriptableObjects, materials, and import settings carry dependencies that are invisible to a normal code review. I organize assets so that ownership is obvious. Shared assets should be intentionally shared, while feature-specific assets should stay with their feature. A folder called Common often becomes a landfill unless the team defines what qualifies for it.</p>
<p>I prefer small scenes with explicit purposes over one scene that silently owns the entire application. A bootstrap scene can establish long-lived services. Content scenes can provide environments or levels. UI can live in a dedicated scene when independent loading is useful. This is not a rule that every project must use additive loading. It is a way to make lifetime visible. The team should know which objects persist, who creates them, and who destroys them.</p>
<p>Prefab variants deserve similar restraint. They are excellent when a variant expresses a real product relationship, such as several enemies sharing a stable base. They become painful when inheritance is used merely to avoid duplicating a few values. Deep prefab chains obscure overrides and make edits hard to predict. I would rather duplicate a small presentation prefab than create an inheritance structure nobody feels safe modifying.</p>
<p>ScriptableObjects are useful for authored configuration and shared immutable data, but I avoid treating them as magical global variables. Runtime mutation can persist in the Editor in surprising ways, and shared references make tests order-dependent. If a ScriptableObject represents configuration, I keep runtime state elsewhere or create a runtime copy deliberately. The lifetime must be a design choice rather than an accident of Unity serialization.</p>
<p>Finally, naming should describe role, not implementation history. Names such as GameplayBootstrap, InventoryCatalog, and QuestView communicate intent. Names such as NewManager2 advertise archaeology. Good asset organization shortens investigation time, improves merge safety, and helps new contributors predict where a change belongs before they open the first file.</p>
<h2>When Should You Use Assembly Definitions and Interfaces?</h2>
<p>Assembly definition files are most valuable as dependency rules. Faster compilation can be a welcome result, but I do not create an assembly merely to reduce compile time. I create one when a module should have an enforceable public boundary. A gameplay assembly may reference shared contracts, while a UI assembly references gameplay contracts. Core gameplay should not reference UI simply because one screen needs a new label.</p>
<p>Start with a small graph. A project might have assemblies for core contracts, gameplay, presentation, platform adapters, editor tools, and tests. Feature-specific assemblies can be introduced when features are sufficiently independent or reusable. Creating an assembly for every folder produces administrative work without necessarily improving design. Circular references are usually a sign that responsibilities need to move, not that the compiler is being difficult.</p>
<p>Interfaces belong at volatile seams. I use them when multiple implementations are expected, when an external SDK needs isolation, or when testing requires a controllable substitute. I do not create an interface for every class. An interface with one implementation and no plausible replacement can add ceremony while hiding a simple relationship.</p>
<pre><code class="language-csharp">using System.Linq;
using NUnit.Framework;
public sealed class AssemblyBoundaryTests
{
[Test]
public void GameplayAssembly_DoesNotReferencePresentation()
{
var references = typeof(MatchController)
.Assembly
.GetReferencedAssemblies()
.Select(assemblyName => assemblyName.Name);
Assert.That(references, Does.Not.Contain("Project.Presentation"));
}
}</code></pre>
<p>This small architecture test turns an intention into an executable rule. The exact assembly and type names will differ by project, but the principle is stable. If gameplay accidentally takes a dependency on presentation, the test fails during development instead of allowing the dependency to spread.</p>
<p>Boundaries also need escape hatches for debugging and iteration. Public contracts should expose what another module genuinely needs without revealing every internal object. If developers repeatedly bypass an interface, I inspect the contract before blaming the developers. A boundary that makes routine work unnecessarily painful will eventually be ignored. Good architecture guides the common path and makes the dangerous path visibly unusual.</p>
<h2>How Can You Prevent Global State and Event Chaos?</h2>
<p>Global state feels efficient because it eliminates wiring. A singleton exposes audio, configuration, inventory, scenes, analytics, and saves from anywhere. The first calls are convenient. The cost appears later when initialization order becomes implicit, tests affect one another, and every system can modify state without showing that dependency in its constructor, serialized fields, or setup method.</p>
<p>I do not ban singletons categorically. Some application-wide services genuinely have one active instance. I do insist that access and lifetime remain controlled. A composition root can construct services, connect features, and pass narrow interfaces to consumers. That gives the project one place where high-level dependencies are visible. It also allows a test, editor tool, or alternate platform implementation to provide a substitute.</p>
<p>Events need the same discipline. An event is useful when the publisher should not know which systems respond. It is dangerous when it becomes a hidden command bus with unclear ordering. I name events as completed facts, such as LevelLoaded or PurchaseConfirmed, rather than vague instructions. I unsubscribe symmetrically, document whether delivery is immediate, and avoid relying on event order unless a coordinator explicitly owns that sequence.</p>
<p>Static events are especially easy to leak across play sessions when domain reload settings change. Unity's configurable Enter Play Mode behavior can expose assumptions about static initialization and cleanup. Every static cache or event should have a deliberate reset strategy. Otherwise, a project may behave differently after the second Play press than it does after an Editor restart or in a player build.</p>
<p>The best diagnostic question is simple: can I understand this component's inputs by looking at it? Serialized references, constructor parameters in plain C# classes, and explicit initialization methods make dependencies visible. Calls to global locators and unnamed event channels hide them. Visibility does not automatically produce good design, but hidden dependencies almost always make maintenance harder.</p>
<h2>What Automation Keeps Unity Architecture Honest?</h2>
<p>Documentation explains intent, but automation protects it. A folder convention in a wiki will drift if nothing checks it. An assembly rule described during onboarding will be forgotten under deadline pressure. I automate the decisions that would be expensive to rediscover during a release, package update, or platform migration.</p>
<p>Architecture tests can verify assembly references, forbidden namespaces, or unwanted dependencies on vendor SDKs. Editor validation can locate missing prefab references, duplicate identifiers, mutable configuration assets, and scenes that contain prohibited components. Build scripts can confirm that required scenes, scripting defines, and platform settings are present. These checks are not glamorous, but they transform tribal knowledge into repeatable feedback.</p>
<p>I keep validators focused and actionable. A warning that says an asset is invalid is much less useful than one that identifies the asset, explains the violated rule, and suggests a repair. Slow validation also gets skipped, so I divide checks into fast feedback for normal development and comprehensive checks for continuous integration or release preparation.</p>
<p>Tests should target boundaries rather than attempt to simulate the whole game through one enormous scenario. Pure rules can use Edit Mode tests. Component behavior can use focused Play Mode tests. Platform adapters can be tested against fake implementations of their contracts. A small number of representative scene-loading and build tests can then verify that composition still works.</p>
<p>Version control is part of this system. Text serialization, visible meta files, stable asset naming, and small pull requests make Unity changes reviewable. Large scene and prefab edits deserve the same scrutiny as C# changes because they can alter dependencies just as easily. If a project has already become difficult to reason about, a focused <a href="exoa.dev">Unity architecture and performance review</a> can identify the highest-risk seams before a team commits to a broad rewrite.</p>
<p>The goal is not to reject every imperfect change. It is to provide fast, objective feedback while the context is still fresh. Architecture survives when the cheapest path for a developer is also the intended path.</p>
<h2>How Should You Refactor Without Stopping Feature Work?</h2>
<p>I am skeptical of complete rewrites. They remove visible technical debt while introducing untested assumptions, delayed features, and a long period in which the old and new systems both demand attention. A safer approach is to improve the seam required by the next real change. Production work then pays for architectural progress instead of competing with it.</p>
<p>Suppose a feature talks directly to a platform SDK. Before adding another platform, define the smallest contract the feature needs and place the existing integration behind an adapter. Keep behavior unchanged. Add tests around the contract. Then implement the second adapter. This sequence creates immediate value, proves the abstraction against real implementations, and avoids designing a universal platform layer in isolation.</p>
<p>I use the same approach with large managers. First identify one responsibility, such as session state, content loading, or reward calculation. Add a clear boundary around it, move behavior with tests, and leave a compatibility path for existing callers. New code uses the extracted service. Old code migrates when touched. The original manager gradually becomes smaller instead of being replaced in one risky merge.</p>
<p>Folder moves should be separated from behavior changes whenever possible. Unity meta files make asset identity stable when moved correctly, but huge reorganizations still create merge conflicts and noisy reviews. A clean hierarchy is not worth losing the ability to inspect what actually changed. I prefer a sequence of understandable commits over one perfect-looking final tree.</p>
<p>Refactoring also needs a stopping rule. The target is not theoretical purity. It is reducing the cost and risk of expected changes. Once a seam is clear, covered, and easy to use, I move back to product work. Touch Camera PRO has remained valuable to me as a lesson in this balance. A reusable Unity product must evolve, but unnecessary internal churn can be just as disruptive as neglected code.</p>
<p>When teams reserve refactoring for a future cleanup phase, that phase rarely arrives in the form they imagine. Sustainable projects make cleanup part of ordinary delivery, one dependency and one validated boundary at a time.</p>
<h2>What Does a Maintainable Unity Project Look Like in 2026?</h2>
<p>By 2026, a Unity project may need to absorb engine updates, package changes, new input devices, storefront requirements, rendering decisions, and platform SDK revisions during the same product lifetime. Maintainability does not mean predicting every change. It means arranging the project so that the unpredictable parts are contained at replaceable edges.</p>
<p>A maintainable project is usually boring to navigate. Features have obvious homes. Runtime and editor code are separate. Third-party packages do not leak types through every gameplay class. Scenes have documented ownership and lifetime. Core rules can run without loading a presentation scene. Build configuration is repeatable. A developer can remove or replace a platform adapter without opening unrelated systems.</p>
<p>It should also be easy to delete code. Deletion is an underrated architecture test. If removing an abandoned feature requires editing dozens of unrelated prefabs and managers, the feature never had a boundary. If its assembly, assets, registrations, and tests can be removed as a coherent unit, the structure is doing useful work.</p>
<p>I would not apply all of these practices on the first day of a weekend prototype. I would apply them as uncertainty decreases and commitment increases. The moment a project gains multiple platforms, external SDKs, several contributors, reusable content pipelines, or a planned life beyond its first release, explicit boundaries begin paying for themselves. My work across shipped VR, freelance Unity development, and Asset Store products has made that transition very visible.</p>
<p>The practical test is whether the team can answer a future request with a bounded plan. Which module changes? Which contract protects the rest? Which automated checks prove that the change is safe? If every answer is the entire project, architecture needs attention. If the answer is a small set of owned systems with clear integration points, the project is positioned to survive change.</p>
<p>Unity will keep evolving, and production requirements will evolve with it. The durable advantage is not a particular folder template or framework. It is a codebase that makes dependencies visible, isolates volatile technology, and allows developers to improve one part without destabilizing everything else.</p>
<h2>References & Further Reading</h2>
<ul><li><a href="docs.unity3d.com">Unity Documentation</a></li><li><a href="learn.unity.com">Unity Learn</a></li><li><a href="Unity-Technologies/UnityCsReference">Unity C# Reference Source</a></li><li><a href="gameprogrammingpatterns.com">Game Programming Patterns</a></li></ul>
Cursor vs Claude Code for Game Development
Verdict: Cursor is the cheaper, friendlier start because it's a code editor with a free plan. Claude Code is a coding agent with no free plan, better for people comfortable on the command line who want to hand off bigger chunks of work. Both can build a real game in Godot, Unity, Unreal or a web framework, and both leave you with code you own and can ship anywhere.
Prices and plan details come from each vendor's pricing and terms pages, checked Oct 18–19, 2026. For every engine-focused coding tool in one list, see AI coding tools for game engines.
At a glance
Cursor (+ Godot)
- Type: AI code editor and coding agent
- Where it runs: desktop editor; also a CLI and in Slack
- Free plan: yes (Cursor Free $0; Godot is free)
- Paid plans: Plus $8 · Premium $30 · Super $100 · Ultra $200 /mo
- AI models: choice of models from several AI labs
- Who owns the code: terms assign Suggestions to you
- Best for: learning, seeing every change, tight budgets
Claude Code
- Type: agentic coding tool
- Where it runs: terminal, IDEs, desktop app and web
- Free plan: no (not on Claude's Free plan)
- Paid plans: Pro $20/mo ($17 annual) · Max from $100/mo
- AI models: Anthropic's Claude models
- Who owns the code: terms assign you Anthropic's rights, if any, in Outputs
- Best for: handing off features, bug fixes and tests
How they differ in practice
Cursor: an editor first
Cursor looks and works like a regular code editor, with AI built in. You open your project folder, and its agent can plan and write code across the whole project: your GDScript or C# for Godot, C# for Unity, or JavaScript for a browser game. You see each change in the editor before you accept it, which makes it a good way to learn how your game actually works. Cursor lets you pick models from several AI labs, so you can switch when one model struggles with a task. It also runs as a CLI and in Slack.
The free plan means you can try it on a real project before paying, and Plus is $8 a month. Higher plans (Premium $30, Super $100, Ultra $200) are for heavier daily use. Paired with Godot, which is free and open source, your total cost can start at $0.
Claude Code: an agent first
Claude Code is Anthropic's agentic coding tool. It reads your codebase, edits files and runs commands, and it works across multiple files at once. You can use it from the terminal, inside IDEs, in a desktop app or on the web. The difference from an editor is the working style: instead of asking for a function and reviewing it line by line, you describe a task ("add a double jump with coyote time and write a test for it") and Claude Code plans it, makes the edits, runs commands and tests, and reports back.
That suits coders who already know their project and want to move faster. It's less suited to someone who's never seen the code, because you'll still need to judge what it did. Claude Code isn't on Claude's Free plan; it's included from Pro at $20 a month ($17 billed annually), and Max starts at $100 a month for heavier use.
Engine support
Neither tool is tied to an engine. They work on text files, so they handle anything an engine stores as code. A few things make each engine smoother:
- Godot: GDScript is short and readable, which makes it a good fit for AI-written code. Tell the AI you're on Godot 4 every time; models often mix in old Godot 3 APIs. GodotPrompter loads Godot 4.3+ guidance in both tools, and Ziva is a Godot-native agent that can use your Claude Code plan. Full guide: best AI for Godot.
- Unity: both edit C# well. Unity's AI tools include a free CLI with MCP mode and an official plugin so outside coding agents can control the Editor, and Unity's official Unity Skills work in Claude Code and Cursor. Community bridges like Unity MCP and UnitySkills add scene and prefab editing.
- Unreal: Epic Games publishes official Unreal Engine Skills for Claude Code, which drive the Unreal Editor over MCP, including Blueprints, materials, Niagara and automation tests. It's built for Claude Code only. For Cursor, Unreal Engine Skills for AI Agents covers UE 5.8 C++ in both tools.
- Browser games: the official Phaser Agent Skills and Three.js Skills keep either agent on current APIs.
- Roblox and Minecraft: both can write Luau or Java mod code. Roblox Studio has its own Roblox Assistant, and MCreator's early-access local MCP server lets either agent drive it for Minecraft mods.
Agent skills: where Claude Code has an edge
Agent skills are packaged instructions and scripts that teach a coding agent a specific job. Many game dev skills now load in both tools, but a few big ones don't list Cursor. Claude Code Game Studios turns a session into a game studio with 49 specialist agents and 74 slash-command skills for Godot 4, Unity or Unreal 5; its README recommends staying on the minimal process level unless you need more. godogen builds whole games from a description with Claude Code or Codex. Epic's Unreal plugin is built for Claude Code only.
Cursor is well covered by cross-agent packs: awesome-gamedev-agent-skills (74 skills with a router for Godot, Unity, Unreal, Phaser, three.js, Bevy and more), the wshobson game-development plugin and Game Dev Agentic Skills all list both. Browse every pack at agent skills for game dev, or read our agent skills guide.
A sample workflow with each
Say you're adding a dash move to a 2D platformer in Godot. Here's how the same task usually goes in each tool.
In Cursor: open the player script, select the movement function and ask the agent to "add a dash on Shift that moves the player 200 pixels over 0.15 seconds, with a 1-second cooldown, Godot 4". Cursor proposes edits in the file, often touching the input map and the player scene too, and you accept or reject each change. You run the game in Godot, notice the dash goes through walls, paste that back in, and iterate. You see every line as it changes, which is slower but teaches you where things live.
In Claude Code: from the project folder, describe the feature and the acceptance criteria in one message, including "don't pass through walls" and "add a test if the project has tests". Claude Code reads the relevant files, plans, edits the script and input settings, and can run commands such as your test runner. You review the diff at the end, run the game and give feedback. You spend less time per change but more time reviewing a bigger diff.
Both approaches work. The real question is whether you'd rather steer each step or hand off the task and review the result. Beginners usually learn more from the first; experienced coders usually move faster with the second.
Cost for a typical solo project
If you code a few evenings a week, Cursor Free may be enough to start, and Plus at $8 a month is the cheapest paid option here. Claude Code starts at $20 a month (Pro), or $17 billed annually. If you hit limits often, both have bigger plans: Cursor Premium at $30 or Claude Max from $100. Your engine adds nothing if it's Godot, and asset tools are separate; see the free AI game dev stack for free art and audio picks.
Other options
GitHub Copilot has a free tier with limited AI credits, is free for verified students, and Pro is $10/mo; it suggests code as you type and can turn an issue into a pull request. Devin Desktop (formerly Windsurf) is Cognition's AI IDE with a free plan, Pro at $20/mo, and an Agent Command Center for running several agents. If you'd rather not code at all, see Lovable vs Bolt for making games or Rosebud vs GDevelop.
Tips for either tool
1. Use version control. Commit before each big AI change so you can roll back. Epic even advises saving and committing before long sessions with its Unreal plugin.
2. Name your engine version. "Godot 4.4" or "Unity 6" in the prompt saves a lot of broken code.
3. Ask for one feature at a time. Run the game after each change and paste errors back in.
4. Read what it wrote. You'll learn the codebase and catch mistakes before they pile up.
5. Keep a project notes file. A short file describing your game, folders and conventions helps either agent make better changes.
Which to pick
Pick Cursor if you're learning, want a free start, and like to see and approve each change in a familiar editor. Pick Claude Code if you live in the terminal, already have a Claude plan, and want an agent to do larger chunks of work, or if you want Claude Code-only skills like Claude Code Game Studios or Epic's Unreal plugin. Not sure? The QuickMatch matcher suggests a stack from your engine, budget and skill level.
New to all this? Start with how to make a game with AI or your first AI game. Writing a Minecraft mod? Compare the best AI Minecraft mod makers, or see AI tools for game modding and the modding hub for other games.
Try Cursor · Try Claude Code
Questions people ask
Can I use Cursor or Claude Code with Godot?
Yes. Both work on your project files, so you can pair either with the free Godot engine. Godot-specific agent skills such as GodotPrompter work with both. See our Godot setup guide.
Which is cheaper?
Cursor has a free plan and Plus at $8/mo. Claude Code needs at least Anthropic's Pro plan, $20/mo ($17/mo billed annually); Max starts at $100/mo.
Is Claude Code better than Cursor for making games?
Neither is better for everyone. Cursor suits people who want to see and edit code in an editor with a free plan. Claude Code suits people comfortable in a terminal who want to hand off larger tasks like a whole feature or a round of bug fixes. Many devs use both.
Can I use Claude Code inside Cursor?
Claude Code runs in the terminal, IDEs, a desktop app and on the web, so you can run it in the terminal of any editor, including Cursor. You'd pay for both tools.
Do I own the code Cursor or Claude Code writes?
Cursor's terms assign Suggestions to you. Anthropic's consumer terms assign you its rights, if any, in Outputs. Third-party code and your engine's own license still apply.
Do they work with Unity and Unreal too?
Yes. Both edit C# and C++ files like any other code. Unity's official CLI has an MCP mode and plugin for outside agents, and Epic Games publishes an official Unreal Engine plugin for Claude Code that drives the editor over MCP.
Do I need to know how to code?
It helps a lot. Both tools write real code you'll need to run, read and debug. If you want no code at all, try a game maker like Rosebud AI or GDevelop, or a chat builder like Bolt.new.
Sources
- cursor.com
- cursor.com
- claude.com
- claude.com
- anthropic.com
- EpicGames/unreal-engine-skills-for-claude-code-plugin
- Unity-Technologies/skills
---
Originally published on QuickMatch. Some links on QuickMatch are affiliate links.
Mentions
【Unity】VS Codeにunity-agent-pluginを導入する はじめに Unity公式から、AIエージェント向けプラグインである unity-agent-plugin が公開されています。 公式ドキュメントでは Claude Code、Codex、Grok、Antigravity への対応が案内されていますが、 VS Code や GitHub Copilot については明示的な記載が見当たりませんでした。 実際に試したところ、VS Codeでもプラグインをインストールできたため、 本記事ではその手順を紹介します。 Unity-Technologies/unity-agent-plugin 環境 VS Code : v1.143.1 導入手順 1. チャットを開く 1. カスタマイズ設定を開く !image.png 1. 左メニューのプラグインを選択する 1. Userの+ボタンを押す !image.png 1. 画面上部にGitHubのリポジトリのURLの記入欄が出るので、https://github.com/Unity-Technologies/unity-agent-plugin を入力する !image.png 1. Enterキーを押してダウンロードを開始します 1. ダウンロード完了後、プラグインに含まれるスキルが利用できるようになります !image.png おわりに 執筆時点では公式ドキュメントに GitHub Copilot の導入手順は記載されていませんが、実際に試したところ VS Code 上でインストールして利用できました。 また、GitHub Copilot 向けのインストール手順を README に追加するプルリクエストがあるので今後は公式に追加される可能性があります。 このプルリクエストにはコマンドによるインストール方法も記載されているため、 コマンドで導入したい方は参考にしてください。 unity-agent-plugin#84 将来的なサポート状況や動作保証については不明ですが、導入を検討している方の参考にしてください。
it is with a certain irony I learn that unity finally makes good readable technical documentation on how to use (and not use) layout groups and content size fitters but it’s not because people need it it’s because ai needs it github.com/Unity-Technologies/unity-agent-plugin/…
How Do You Structure a Unity Project That Can Survive Years of Change? --- title: "How Do You Structure a Unity Project That Can Survive Years of Change?" published: true canonical_url: exoa.dev description: "Learn how to structure Unity projects for safer features, platform changes, team growth, and long-term maintenance." --- <p>A Unity project rarely becomes difficult because one programmer wrote one bad class. It becomes difficult because hundreds of reasonable local decisions slowly remove the project's boundaries. After 16 years in game development, including shipping Eagle Flight Arcade as a Gameplay Programmer at Ubisoft Montreal in 2016 and maintaining products such as Touch Camera PRO, I have learned to treat changeability as a production feature. A project that works today but resists tomorrow's platform SDK, control scheme, or content request is already accumulating risk.</p> <div class="key-takeaways"><strong>Key Takeaways</strong><ul><li>Organize Unity projects around features and ownership, not only file types.</li><li>Use assembly definitions to enforce a small number of meaningful boundaries.</li><li>Keep platform APIs, global state, and scene references behind explicit seams.</li><li>Automate architectural checks before conventions become optional.</li><li>Refactor incrementally while delivering features instead of waiting for a rewrite.</li></ul></div> <h2>What Actually Makes a Unity Project Hard to Change?</h2> <p>The real enemy is not the number of scripts. It is the distance between a requested change and its unexpected consequences. A menu adjustment should not require knowledge of the save format, platform achievements, character movement, and analytics. When it does, the project has lost separation between responsibilities. Unity makes this easy to miss because almost anything can reference a MonoBehaviour, find an object in a scene, or reach a static singleton.</p> <p>I saw the importance of explicit responsibilities while working on Eagle Flight Arcade at Ubisoft Montreal in 2016. A VR game shipping across PSVR, Oculus Rift, and HTC Vive could not treat hardware assumptions as harmless details. The broader lesson applies to every Unity project. Platform code changes faster than core game rules, presentation changes faster than persistent data, and prototypes change faster than production infrastructure. If those rates of change are mixed together, every update becomes a project-wide negotiation.</p> <p>I evaluate architecture by asking three questions. Which code owns this decision? What is allowed to depend on it? How would I replace it without editing unrelated features? If the answers are unclear, the system probably relies on accidental coupling. A public field in the Inspector may look convenient, but it still creates a dependency. The same is true for a static event, a Resources load, or a scene object discovered by name.</p> <p>This does not mean every game needs enterprise-style abstraction. Small prototypes should remain small. The important distinction is whether a shortcut is contained. I am comfortable taking on debt when I can name it, locate it, and remove it. Unnamed debt spread across scenes, prefabs, and global services is what turns an ordinary feature request into a dangerous change.</p> <h2>Where Should You Draw Boundaries Inside a Unity Project?</h2> <p>I start with rates of change, not a favorite diagram. Code that changes for the same reason should usually live together. Code that changes for different reasons should communicate through a narrow contract. In a typical Unity project, I separate core rules, feature implementation, presentation, persistence, platform integration, and editor tooling. Those categories can become assemblies, but the conceptual boundary matters before the file structure does.</p> <p>Features should own as much of their vertical path as practical. An inventory feature might contain its rules, data types, runtime controller, UI presenter, tests, and authoring tools. That is often easier to maintain than placing every view in one global UI folder, every data class in another, and every manager in a third. A developer investigating inventory behavior can then inspect one coherent area rather than tracing references across the whole repository.</p> <p>Platform integrations belong at the outside edge. Steam, console services, mobile notifications, VR runtimes, and vendor-specific input should adapt external APIs into contracts understood by the game. Core rules should not know which SDK provided an identity, controller pose, purchase result, or storage location. This makes editor simulation easier and reduces the blast radius when a package changes during 2025 or 2026.</p> <p>I also separate runtime code from authoring code. Custom inspectors, import processors, validation windows, and content generators are valuable, but a player build should never depend on an editor assembly. My Unity Asset Store work, especially Touch Camera PRO and tools such as Tutorial Engine and Level Designer, reinforced this discipline. A reusable package cannot assume that it owns the host project's scenes, initialization order, input setup, or folder conventions.</p> <p>A useful boundary has a clear owner and a small public surface. If two modules constantly reach into each other's internal state, they are either one module pretending to be two or they need a better contract. Architecture is not the number of boxes in a diagram. It is the set of changes that each box can absorb independently.</p> <h2>How Should Scenes, Prefabs, and Assets Be Organized?</h2> <p>Unity architecture is not only C# architecture. Scenes, prefabs, ScriptableObjects, materials, and import settings carry dependencies that are invisible to a normal code review. I organize assets so that ownership is obvious. Shared assets should be intentionally shared, while feature-specific assets should stay with their feature. A folder called Common often becomes a landfill unless the team defines what qualifies for it.</p> <p>I prefer small scenes with explicit purposes over one scene that silently owns the entire application. A bootstrap scene can establish long-lived services. Content scenes can provide environments or levels. UI can live in a dedicated scene when independent loading is useful. This is not a rule that every project must use additive loading. It is a way to make lifetime visible. The team should know which objects persist, who creates them, and who destroys them.</p> <p>Prefab variants deserve similar restraint. They are excellent when a variant expresses a real product relationship, such as several enemies sharing a stable base. They become painful when inheritance is used merely to avoid duplicating a few values. Deep prefab chains obscure overrides and make edits hard to predict. I would rather duplicate a small presentation prefab than create an inheritance structure nobody feels safe modifying.</p> <p>ScriptableObjects are useful for authored configuration and shared immutable data, but I avoid treating them as magical global variables. Runtime mutation can persist in the Editor in surprising ways, and shared references make tests order-dependent. If a ScriptableObject represents configuration, I keep runtime state elsewhere or create a runtime copy deliberately. The lifetime must be a design choice rather than an accident of Unity serialization.</p> <p>Finally, naming should describe role, not implementation history. Names such as GameplayBootstrap, InventoryCatalog, and QuestView communicate intent. Names such as NewManager2 advertise archaeology. Good asset organization shortens investigation time, improves merge safety, and helps new contributors predict where a change belongs before they open the first file.</p> <h2>When Should You Use Assembly Definitions and Interfaces?</h2> <p>Assembly definition files are most valuable as dependency rules. Faster compilation can be a welcome result, but I do not create an assembly merely to reduce compile time. I create one when a module should have an enforceable public boundary. A gameplay assembly may reference shared contracts, while a UI assembly references gameplay contracts. Core gameplay should not reference UI simply because one screen needs a new label.</p> <p>Start with a small graph. A project might have assemblies for core contracts, gameplay, presentation, platform adapters, editor tools, and tests. Feature-specific assemblies can be introduced when features are sufficiently independent or reusable. Creating an assembly for every folder produces administrative work without necessarily improving design. Circular references are usually a sign that responsibilities need to move, not that the compiler is being difficult.</p> <p>Interfaces belong at volatile seams. I use them when multiple implementations are expected, when an external SDK needs isolation, or when testing requires a controllable substitute. I do not create an interface for every class. An interface with one implementation and no plausible replacement can add ceremony while hiding a simple relationship.</p> <pre><code class="language-csharp">using System.Linq; using NUnit.Framework; public sealed class AssemblyBoundaryTests { [Test] public void GameplayAssembly_DoesNotReferencePresentation() { var references = typeof(MatchController) .Assembly .GetReferencedAssemblies() .Select(assemblyName => assemblyName.Name); Assert.That(references, Does.Not.Contain("Project.Presentation")); } }</code></pre> <p>This small architecture test turns an intention into an executable rule. The exact assembly and type names will differ by project, but the principle is stable. If gameplay accidentally takes a dependency on presentation, the test fails during development instead of allowing the dependency to spread.</p> <p>Boundaries also need escape hatches for debugging and iteration. Public contracts should expose what another module genuinely needs without revealing every internal object. If developers repeatedly bypass an interface, I inspect the contract before blaming the developers. A boundary that makes routine work unnecessarily painful will eventually be ignored. Good architecture guides the common path and makes the dangerous path visibly unusual.</p> <h2>How Can You Prevent Global State and Event Chaos?</h2> <p>Global state feels efficient because it eliminates wiring. A singleton exposes audio, configuration, inventory, scenes, analytics, and saves from anywhere. The first calls are convenient. The cost appears later when initialization order becomes implicit, tests affect one another, and every system can modify state without showing that dependency in its constructor, serialized fields, or setup method.</p> <p>I do not ban singletons categorically. Some application-wide services genuinely have one active instance. I do insist that access and lifetime remain controlled. A composition root can construct services, connect features, and pass narrow interfaces to consumers. That gives the project one place where high-level dependencies are visible. It also allows a test, editor tool, or alternate platform implementation to provide a substitute.</p> <p>Events need the same discipline. An event is useful when the publisher should not know which systems respond. It is dangerous when it becomes a hidden command bus with unclear ordering. I name events as completed facts, such as LevelLoaded or PurchaseConfirmed, rather than vague instructions. I unsubscribe symmetrically, document whether delivery is immediate, and avoid relying on event order unless a coordinator explicitly owns that sequence.</p> <p>Static events are especially easy to leak across play sessions when domain reload settings change. Unity's configurable Enter Play Mode behavior can expose assumptions about static initialization and cleanup. Every static cache or event should have a deliberate reset strategy. Otherwise, a project may behave differently after the second Play press than it does after an Editor restart or in a player build.</p> <p>The best diagnostic question is simple: can I understand this component's inputs by looking at it? Serialized references, constructor parameters in plain C# classes, and explicit initialization methods make dependencies visible. Calls to global locators and unnamed event channels hide them. Visibility does not automatically produce good design, but hidden dependencies almost always make maintenance harder.</p> <h2>What Automation Keeps Unity Architecture Honest?</h2> <p>Documentation explains intent, but automation protects it. A folder convention in a wiki will drift if nothing checks it. An assembly rule described during onboarding will be forgotten under deadline pressure. I automate the decisions that would be expensive to rediscover during a release, package update, or platform migration.</p> <p>Architecture tests can verify assembly references, forbidden namespaces, or unwanted dependencies on vendor SDKs. Editor validation can locate missing prefab references, duplicate identifiers, mutable configuration assets, and scenes that contain prohibited components. Build scripts can confirm that required scenes, scripting defines, and platform settings are present. These checks are not glamorous, but they transform tribal knowledge into repeatable feedback.</p> <p>I keep validators focused and actionable. A warning that says an asset is invalid is much less useful than one that identifies the asset, explains the violated rule, and suggests a repair. Slow validation also gets skipped, so I divide checks into fast feedback for normal development and comprehensive checks for continuous integration or release preparation.</p> <p>Tests should target boundaries rather than attempt to simulate the whole game through one enormous scenario. Pure rules can use Edit Mode tests. Component behavior can use focused Play Mode tests. Platform adapters can be tested against fake implementations of their contracts. A small number of representative scene-loading and build tests can then verify that composition still works.</p> <p>Version control is part of this system. Text serialization, visible meta files, stable asset naming, and small pull requests make Unity changes reviewable. Large scene and prefab edits deserve the same scrutiny as C# changes because they can alter dependencies just as easily. If a project has already become difficult to reason about, a focused <a href="exoa.dev">Unity architecture and performance review</a> can identify the highest-risk seams before a team commits to a broad rewrite.</p> <p>The goal is not to reject every imperfect change. It is to provide fast, objective feedback while the context is still fresh. Architecture survives when the cheapest path for a developer is also the intended path.</p> <h2>How Should You Refactor Without Stopping Feature Work?</h2> <p>I am skeptical of complete rewrites. They remove visible technical debt while introducing untested assumptions, delayed features, and a long period in which the old and new systems both demand attention. A safer approach is to improve the seam required by the next real change. Production work then pays for architectural progress instead of competing with it.</p> <p>Suppose a feature talks directly to a platform SDK. Before adding another platform, define the smallest contract the feature needs and place the existing integration behind an adapter. Keep behavior unchanged. Add tests around the contract. Then implement the second adapter. This sequence creates immediate value, proves the abstraction against real implementations, and avoids designing a universal platform layer in isolation.</p> <p>I use the same approach with large managers. First identify one responsibility, such as session state, content loading, or reward calculation. Add a clear boundary around it, move behavior with tests, and leave a compatibility path for existing callers. New code uses the extracted service. Old code migrates when touched. The original manager gradually becomes smaller instead of being replaced in one risky merge.</p> <p>Folder moves should be separated from behavior changes whenever possible. Unity meta files make asset identity stable when moved correctly, but huge reorganizations still create merge conflicts and noisy reviews. A clean hierarchy is not worth losing the ability to inspect what actually changed. I prefer a sequence of understandable commits over one perfect-looking final tree.</p> <p>Refactoring also needs a stopping rule. The target is not theoretical purity. It is reducing the cost and risk of expected changes. Once a seam is clear, covered, and easy to use, I move back to product work. Touch Camera PRO has remained valuable to me as a lesson in this balance. A reusable Unity product must evolve, but unnecessary internal churn can be just as disruptive as neglected code.</p> <p>When teams reserve refactoring for a future cleanup phase, that phase rarely arrives in the form they imagine. Sustainable projects make cleanup part of ordinary delivery, one dependency and one validated boundary at a time.</p> <h2>What Does a Maintainable Unity Project Look Like in 2026?</h2> <p>By 2026, a Unity project may need to absorb engine updates, package changes, new input devices, storefront requirements, rendering decisions, and platform SDK revisions during the same product lifetime. Maintainability does not mean predicting every change. It means arranging the project so that the unpredictable parts are contained at replaceable edges.</p> <p>A maintainable project is usually boring to navigate. Features have obvious homes. Runtime and editor code are separate. Third-party packages do not leak types through every gameplay class. Scenes have documented ownership and lifetime. Core rules can run without loading a presentation scene. Build configuration is repeatable. A developer can remove or replace a platform adapter without opening unrelated systems.</p> <p>It should also be easy to delete code. Deletion is an underrated architecture test. If removing an abandoned feature requires editing dozens of unrelated prefabs and managers, the feature never had a boundary. If its assembly, assets, registrations, and tests can be removed as a coherent unit, the structure is doing useful work.</p> <p>I would not apply all of these practices on the first day of a weekend prototype. I would apply them as uncertainty decreases and commitment increases. The moment a project gains multiple platforms, external SDKs, several contributors, reusable content pipelines, or a planned life beyond its first release, explicit boundaries begin paying for themselves. My work across shipped VR, freelance Unity development, and Asset Store products has made that transition very visible.</p> <p>The practical test is whether the team can answer a future request with a bounded plan. Which module changes? Which contract protects the rest? Which automated checks prove that the change is safe? If every answer is the entire project, architecture needs attention. If the answer is a small set of owned systems with clear integration points, the project is positioned to survive change.</p> <p>Unity will keep evolving, and production requirements will evolve with it. The durable advantage is not a particular folder template or framework. It is a codebase that makes dependencies visible, isolates volatile technology, and allows developers to improve one part without destabilizing everything else.</p> <h2>References & Further Reading</h2> <ul><li><a href="docs.unity3d.com">Unity Documentation</a></li><li><a href="learn.unity.com">Unity Learn</a></li><li><a href="Unity-Technologies/UnityCsReference">Unity C# Reference Source</a></li><li><a href="gameprogrammingpatterns.com">Game Programming Patterns</a></li></ul>
09. ml-agents by Unity Unity-Technologies/ml-agents NPC 可以自己学着玩，用强化学习和自我对弈来训练。
Cursor vs Claude Code for Game Development Verdict: Cursor is the cheaper, friendlier start because it's a code editor with a free plan. Claude Code is a coding agent with no free plan, better for people comfortable on the command line who want to hand off bigger chunks of work. Both can build a real game in Godot, Unity, Unreal or a web framework, and both leave you with code you own and can ship anywhere. Prices and plan details come from each vendor's pricing and terms pages, checked Oct 18–19, 2026. For every engine-focused coding tool in one list, see AI coding tools for game engines. At a glance Cursor (+ Godot) - Type: AI code editor and coding agent - Where it runs: desktop editor; also a CLI and in Slack - Free plan: yes (Cursor Free $0; Godot is free) - Paid plans: Plus $8 · Premium $30 · Super $100 · Ultra $200 /mo - AI models: choice of models from several AI labs - Who owns the code: terms assign Suggestions to you - Best for: learning, seeing every change, tight budgets Claude Code - Type: agentic coding tool - Where it runs: terminal, IDEs, desktop app and web - Free plan: no (not on Claude's Free plan) - Paid plans: Pro $20/mo ($17 annual) · Max from $100/mo - AI models: Anthropic's Claude models - Who owns the code: terms assign you Anthropic's rights, if any, in Outputs - Best for: handing off features, bug fixes and tests How they differ in practice Cursor: an editor first Cursor looks and works like a regular code editor, with AI built in. You open your project folder, and its agent can plan and write code across the whole project: your GDScript or C# for Godot, C# for Unity, or JavaScript for a browser game. You see each change in the editor before you accept it, which makes it a good way to learn how your game actually works. Cursor lets you pick models from several AI labs, so you can switch when one model struggles with a task. It also runs as a CLI and in Slack. The free plan means you can try it on a real project before paying, and Plus is $8 a month. Higher plans (Premium $30, Super $100, Ultra $200) are for heavier daily use. Paired with Godot, which is free and open source, your total cost can start at $0. Claude Code: an agent first Claude Code is Anthropic's agentic coding tool. It reads your codebase, edits files and runs commands, and it works across multiple files at once. You can use it from the terminal, inside IDEs, in a desktop app or on the web. The difference from an editor is the working style: instead of asking for a function and reviewing it line by line, you describe a task ("add a double jump with coyote time and write a test for it") and Claude Code plans it, makes the edits, runs commands and tests, and reports back. That suits coders who already know their project and want to move faster. It's less suited to someone who's never seen the code, because you'll still need to judge what it did. Claude Code isn't on Claude's Free plan; it's included from Pro at $20 a month ($17 billed annually), and Max starts at $100 a month for heavier use. Engine support Neither tool is tied to an engine. They work on text files, so they handle anything an engine stores as code. A few things make each engine smoother: - Godot: GDScript is short and readable, which makes it a good fit for AI-written code. Tell the AI you're on Godot 4 every time; models often mix in old Godot 3 APIs. GodotPrompter loads Godot 4.3+ guidance in both tools, and Ziva is a Godot-native agent that can use your Claude Code plan. Full guide: best AI for Godot. - Unity: both edit C# well. Unity's AI tools include a free CLI with MCP mode and an official plugin so outside coding agents can control the Editor, and Unity's official Unity Skills work in Claude Code and Cursor. Community bridges like Unity MCP and UnitySkills add scene and prefab editing. - Unreal: Epic Games publishes official Unreal Engine Skills for Claude Code, which drive the Unreal Editor over MCP, including Blueprints, materials, Niagara and automation tests. It's built for Claude Code only. For Cursor, Unreal Engine Skills for AI Agents covers UE 5.8 C++ in both tools. - Browser games: the official Phaser Agent Skills and Three.js Skills keep either agent on current APIs. - Roblox and Minecraft: both can write Luau or Java mod code. Roblox Studio has its own Roblox Assistant, and MCreator's early-access local MCP server lets either agent drive it for Minecraft mods. Agent skills: where Claude Code has an edge Agent skills are packaged instructions and scripts that teach a coding agent a specific job. Many game dev skills now load in both tools, but a few big ones don't list Cursor. Claude Code Game Studios turns a session into a game studio with 49 specialist agents and 74 slash-command skills for Godot 4, Unity or Unreal 5; its README recommends staying on the minimal process level unless you need more. godogen builds whole games from a description with Claude Code or Codex. Epic's Unreal plugin is built for Claude Code only. Cursor is well covered by cross-agent packs: awesome-gamedev-agent-skills (74 skills with a router for Godot, Unity, Unreal, Phaser, three.js, Bevy and more), the wshobson game-development plugin and Game Dev Agentic Skills all list both. Browse every pack at agent skills for game dev, or read our agent skills guide. A sample workflow with each Say you're adding a dash move to a 2D platformer in Godot. Here's how the same task usually goes in each tool. In Cursor: open the player script, select the movement function and ask the agent to "add a dash on Shift that moves the player 200 pixels over 0.15 seconds, with a 1-second cooldown, Godot 4". Cursor proposes edits in the file, often touching the input map and the player scene too, and you accept or reject each change. You run the game in Godot, notice the dash goes through walls, paste that back in, and iterate. You see every line as it changes, which is slower but teaches you where things live. In Claude Code: from the project folder, describe the feature and the acceptance criteria in one message, including "don't pass through walls" and "add a test if the project has tests". Claude Code reads the relevant files, plans, edits the script and input settings, and can run commands such as your test runner. You review the diff at the end, run the game and give feedback. You spend less time per change but more time reviewing a bigger diff. Both approaches work. The real question is whether you'd rather steer each step or hand off the task and review the result. Beginners usually learn more from the first; experienced coders usually move faster with the second. Cost for a typical solo project If you code a few evenings a week, Cursor Free may be enough to start, and Plus at $8 a month is the cheapest paid option here. Claude Code starts at $20 a month (Pro), or $17 billed annually. If you hit limits often, both have bigger plans: Cursor Premium at $30 or Claude Max from $100. Your engine adds nothing if it's Godot, and asset tools are separate; see the free AI game dev stack for free art and audio picks. Other options GitHub Copilot has a free tier with limited AI credits, is free for verified students, and Pro is $10/mo; it suggests code as you type and can turn an issue into a pull request. Devin Desktop (formerly Windsurf) is Cognition's AI IDE with a free plan, Pro at $20/mo, and an Agent Command Center for running several agents. If you'd rather not code at all, see Lovable vs Bolt for making games or Rosebud vs GDevelop. Tips for either tool 1. Use version control. Commit before each big AI change so you can roll back. Epic even advises saving and committing before long sessions with its Unreal plugin. 2. Name your engine version. "Godot 4.4" or "Unity 6" in the prompt saves a lot of broken code. 3. Ask for one feature at a time. Run the game after each change and paste errors back in. 4. Read what it wrote. You'll learn the codebase and catch mistakes before they pile up. 5. Keep a project notes file. A short file describing your game, folders and conventions helps either agent make better changes. Which to pick Pick Cursor if you're learning, want a free start, and like to see and approve each change in a familiar editor. Pick Claude Code if you live in the terminal, already have a Claude plan, and want an agent to do larger chunks of work, or if you want Claude Code-only skills like Claude Code Game Studios or Epic's Unreal plugin. Not sure? The QuickMatch matcher suggests a stack from your engine, budget and skill level. New to all this? Start with how to make a game with AI or your first AI game. Writing a Minecraft mod? Compare the best AI Minecraft mod makers, or see AI tools for game modding and the modding hub for other games. Try Cursor · Try Claude Code Questions people ask Can I use Cursor or Claude Code with Godot? Yes. Both work on your project files, so you can pair either with the free Godot engine. Godot-specific agent skills such as GodotPrompter work with both. See our Godot setup guide. Which is cheaper? Cursor has a free plan and Plus at $8/mo. Claude Code needs at least Anthropic's Pro plan, $20/mo ($17/mo billed annually); Max starts at $100/mo. Is Claude Code better than Cursor for making games? Neither is better for everyone. Cursor suits people who want to see and edit code in an editor with a free plan. Claude Code suits people comfortable in a terminal who want to hand off larger tasks like a whole feature or a round of bug fixes. Many devs use both. Can I use Claude Code inside Cursor? Claude Code runs in the terminal, IDEs, a desktop app and on the web, so you can run it in the terminal of any editor, including Cursor. You'd pay for both tools. Do I own the code Cursor or Claude Code writes? Cursor's terms assign Suggestions to you. Anthropic's consumer terms assign you its rights, if any, in Outputs. Third-party code and your engine's own license still apply. Do they work with Unity and Unreal too? Yes. Both edit C# and C++ files like any other code. Unity's official CLI has an MCP mode and plugin for outside agents, and Epic Games publishes an official Unreal Engine plugin for Claude Code that drives the editor over MCP. Do I need to know how to code? It helps a lot. Both tools write real code you'll need to run, read and debug. If you want no code at all, try a game maker like Rosebud AI or GDevelop, or a chat builder like Bolt.new. Sources - cursor.com - cursor.com - claude.com - claude.com - anthropic.com - EpicGames/unreal-engine-skills-for-claude-code-plugin - Unity-Technologies/skills --- Originally published on QuickMatch. Some links on QuickMatch are affiliate links.
官方仓库地址： Unity-Technologies/unity-agent-plugin 快速安装命令（Claude Code 会话内直接输入）： /plugin marketplace add Unity-Technologies/unity-agent-plugin /plugin install unity@unity-agent-plugin
Unity’nin resmi ajan eklentisi sadece C# yazmıyor; Unity CLI ile açık Editor’daki sahne ve asset’leri de değiştirebiliyor. README’de her değişikliğin Editor’dan geri alınamayabileceğini özellikle belirtmişler. Unity-Technologies/unity-agent-plugin
game studios are cooked again how i turn a my cozy farm game into 4-player co-op with Opus 5.5 co-op is the feature that kills most solo projects. Opus does the boring netcode part: step 1 -> Claude Code drives Unity 6 through unity-mcp CoplayDev/unity-mcp step 2 -> Netcode for GameObjects syncs players, crops, coins Unity-Technologies/com.unity.netcode.gameobjects step 3 -> Opus copies the patterns from Boss Room, Unity's own co-op sample Unity-Technologies/com.unity.multiplayer.samples.coop step 4 -> Relay + Lobby, so friends join with a 6-letter code, no server to host step 5 -> Multiplayer Play Mode runs 4 players in one editor for testing step 6 -> Opus splits the jobs: one waters, one fishes, one sells, one builds who does what: > unity 6: netcode, lobby, relay > opus 5.5: sync scripts, desync fixes, the shared economy > tripo: 4 farmer skins > you: invite 3 friends and see who slacks one farm, 4 players, zero servers to run who are you inviting first?
A new verb is a level-design bill. Ocarina of Time's remake adds on-demand jump, so the Forest Temple's crushing-block room got guard rails to stop Link hopping on top. Add a verb, re-audit every room. Unity-Technologies/unity-agent-plugin