Version and licence choices, URP rendering, the plugins worth adding, and how to ship a build to Steam, Android, and iOS without losing a month to setup mistakes.
Unity indie game development is one of the most common starting points for a small studio, and for good reason: the editor is free for most solo developers, the tutorial material is enormous, and the same project can target desktop, mobile, and console without being rewritten. It is also the engine where indie teams most often lose time, because the licensing terms are conditional, the render pipeline choice is expensive to reverse, and the publishing steps for Steam, Android, and iOS are genuinely different from each other. This guide covers the decisions in the order you should make them: which version to install, what the Unity free indie licence actually permits, how to set up a Unity URP indie game project, which plugins are worth the dependency, how to publish a Unity game to Steam and to mobile stores, and the specific mistakes that cost small teams weeks.
The first Unity decision is which release channel to install, and it matters more than it looks. Unity ships two kinds of release: long-term support streams that stay on a stable, patched feature set for years, and the current release stream that moves fastest and breaks the most third-party assets. For an indie project with a two-year runway, the long-term support stream is the safer default because the version you start on will still be the version you ship on, and the packages you depend on will have had time to be updated for it.
The second decision is which licence tier your studio needs, and that one is not really a technical decision at all. It depends on your revenue and funding, and it can change over the life of a project.
| Tier | Typical fit for an indie team | Editor and build access | Cost shape | Watch out for |
|---|---|---|---|---|
| Personal | Solo developers, hobbyists, and small studios under the published revenue and funding threshold | Full editor, standard render pipelines, desktop and mobile builds | No licence fee while you stay inside the threshold | The threshold is a moving target — re-read the terms in your launch year |
| Plus | Small studios that have outgrown the free tier but still want per-seat pricing without revenue share | Same editor plus higher asset store payout and seat management features | Per-seat subscription, generally no revenue share | Seat count must match your actual team; extra seats are pure waste |
| Pro | Studios with funding or revenue above the free threshold, or teams that need console build targets | Adds console and platform build access, deeper analytics, and larger cloud build capacity | Per-seat subscription plus a revenue share above a stated threshold | The revenue share is the expensive part — model it against your real revenue plan |
| Enterprise | Almost never relevant to an indie team | Custom agreements, dedicated support, private source access | Negotiated, sales-led | Wrong tier for a small team on every axis |
A practical rule for a small team: if you are unsure which tier applies, install the free tier and start building. You can upgrade later, and upgrading a licence is a purchase, whereas rewriting a game in a different engine is a project. That reasoning reverses only in one case — if you know on day one that you will need console targets and will have funding above the free threshold, buy the right tier before you build, because console certification is a separate cost and schedule regardless of which engine you use.
The question "is Unity free for indie games" has a simple answer and a complicated footnote. The simple answer is yes: Unity's Personal tier is a genuine commercial licence for most solo developers and small teams, not a trial and not an educational restriction, and a game you ship with it can be sold. The footnote is that the free tier is conditional rather than unlimited — it applies while your revenue and funding stay under a threshold that Unity publishes, and the terms have been revised more than once.
For the Unity personal licence indie game commercial question specifically, three things are true at the time of writing. You can ship a paid game. You can use the free tier on the condition that your studio stays inside the published threshold. And if you cross the threshold, the paid tiers add a revenue share on top of the seat fee, which means the total cost of a successful game is higher than a flat subscription would suggest.
Do this before you commit. Read the current licence terms on Unity's own site, save a dated copy of the version you accepted, and re-check it in the year you release. The number has moved before, and the shape of the terms has moved with it. A summary written on a documentation site is a worse source than the licence text itself.
Two adjacent questions come up constantly. The first is whether Unity requires a paid licence to use assets from the asset store — it does not, but individual asset store assets carry their own licence terms, so check them per asset. The second is whether mixing in a paid plugin changes your Unity tier — it does not, but the plugin's own licence is a separate commitment. If a licence that is unconditionally free matters more to you than Unity's asset store and console pipeline, the best free indie game software list covers engines under genuinely unlimited licences.
The Unity URP indie game setup is the single decision most likely to cost you a week if you get it wrong, because render pipeline changes reach into every material, shader, and lighting setup in the project. The three pipelines in current Unity releases are the built-in pipeline, which is what older projects use and what most tutorials from several years ago assume; the Universal Render Pipeline, which is the modern default and scales from 2D sprites to stylised 3D on desktop and mobile; and the High Definition Render Pipeline, which targets realistic lighting on capable desktop hardware at the cost of a larger build and heavier hardware requirements.
| Built-in | Universal (URP) | High Definition (HDRP) | |
|---|---|---|---|
| Best for | Maintaining an existing legacy project | Almost every new indie project, 2D or 3D | Realistic desktop visuals |
| 2D support | Basic sprite renderer only | Full 2D renderer with batching, lights, and sorting layers | Not designed for 2D |
| Mobile performance | Workable but unoptimised | Strong — the default target for mobile releases | Poor — too heavy for most phones |
| Build size and shader cost | Small | Moderate, with faster shader compilation | Large, with long shader compilation times |
| Upgrade risk | None, it is the legacy default | Must be chosen at project creation | Must be chosen at project creation |
The setup itself is short. Create the project, choose the Universal Render Pipeline template from the project creation window rather than converting an empty 3D project afterwards, and commit to it before importing art. Then set the render pipeline asset in the project settings, add a 2D or 3D renderer depending on your game, and configure the quality settings per platform so your mobile target gets its own shadow resolution, texture limits, and post-processing volume rather than inheriting desktop settings.
The advice that saves the most time: pick the pipeline once, at project creation, and never switch mid-project unless the project is small. If you are porting an old project, treat the migration as its own task with its own branch in version control, because material conversion is where the hours disappear. When you need the visual vocabulary — shader, material, renderer, and the difference between them — the game development terminology glossary is the fastest reference, and the Godot shader tutorial note covers the equivalent concepts in the other engine so the ideas transfer.
The best Unity plugins for indie developers are the ones that remove a category of work rather than adding a category of dependency. Unity's package manager covers a lot of ground already, so the useful additions fall into a few groups: camera and cutscene tooling, asset loading, input, animation, and the small utility libraries that stop you writing the same utility code.
Unity's first-party camera solution, covering follow cameras, framing shots, and timeline-driven camera work. It removes hand-written camera rigs, and it is the standard answer when a designer asks for a cutscene. Check the listing for its current licence and version support before adding it to a shipping project.
Loads assets on demand from remote or local catalogs instead of shipping everything in the build. This is how you keep a download size manageable and how you patch content without shipping a new executable. It also introduces a build step and a content-update workflow, which is real complexity — worth it once your content exceeds what you want in a first download, not before.
Unity's newer input stack, supporting multiple control schemes, rebinding, and devices that mix keyboard, mouse, and controller. The migration cost is real for an existing project, but for a new project it is the sensible default, especially if you plan console or Steam Deck support where a player expects to swap input devices mid-session.
Unity's Timeline gives you a visual track for cutscenes, dialogue timing, and scripted events. It is first-party, so no licence negotiation, and it integrates with Cinemachine and the animation system rather than sitting beside them. For 2D sprite work, an external tweening library such as DOTween is the common choice — free to use under its own terms, with an optional paid tier for extras.
A JSON library, a tweening library, and a small event system cover most of what indie teams otherwise hand-roll. Prefer open-source options with permissive licences so they do not become an audit question later. The best free game development tools guide covers the wider set with licence details for each.
Plugin discipline. Every plugin is a dependency on somebody else's release schedule. Pin your package versions, keep the dependency list short, and check the licence of anything paid before it enters the project. A plugin that saves two days but blocks your release for a week has a bad ratio.
How to publish a Unity game to Steam is less mysterious than it sounds, because Unity produces an ordinary standalone executable and Steam ships ordinary executables. The integration work is the Steamworks SDK, and the distribution work is SteamPipe.
Console targets are the one part of Unity's platform support that is genuinely gated: building for a console requires platform approval, a licensed development kit, and a certification process through the platform holder. Plan for it as a separate budget line with its own timeline rather than as a build target you can add in a week.
Mobile is where a Unity indie game meets the most friction, because the two stores have opposite rules. Android is comparatively open: you enable a module in the build settings, point the project at your Android SDK and NDK, produce an app bundle, and sign it with a keystore you create and keep. The parts that catch people out are the minimum API level and the 64-bit requirement, both of which are worth setting correctly the first time rather than discovering at upload.
iOS is the opposite. Building for iOS requires macOS with Xcode, an Apple Developer Program membership, a bundle identifier, provisioning profiles, and signing certificates, all of which are managed through Apple's developer portal. The membership is an annual fee per organisation, and the build itself has to happen on a Mac — Unity cannot produce an iOS build from a Windows machine. The compile is also typically the slowest build in the project, so plan to run it less often than you run your desktop build.
Unity's cross-platform development story is strong on the shared-code side and uneven on the tooling side: the same scene and scripts usually work on both, but the input, the performance budget, and the store rules do not. If your plan involves more than one platform, read the cross platform indie game dev note for the differences that actually bite, and treat mobile as a target from the first week rather than a port at the end.
Most Unity problems that reach a small studio are not engine bugs. They are process decisions that seemed cheap at the time.
Every asset in a Unity project has a companion .meta file holding its import settings and its generated GUID. If those files are not committed, every teammate regenerates different GUIDs, and references break silently. If they are committed with binary assets, the repository becomes unusable. The standard fix is Git LFS for the binary assets plus a text-serialisation mode for scenes and prefabs so merges are readable instead of binary conflicts.
Scenes and prefabs conflict badly in version control no matter which settings you choose. A workable indie rule is to split the scene into smaller prefabs, name a single owner for each prefab while it is being changed, and merge through the inspector rather than by hand-editing YAML.
Managed allocations inside Update cause garbage collection spikes that look like stutter on a device but not in the editor. The profiler's allocation tracker finds them quickly. This is a code-hygiene issue rather than an engine issue, and it is far cheaper to prevent with a rule about no allocations in the hot path than to hunt later.
The scripting backend choice (Mono or IL2CPP) and code stripping settings can remove code paths you call only through reflection, and the failure shows up as a null reference in a shipped build that works fine in the editor. Test with the shipping configuration before you believe any build works, and keep a debug build for the platform you are not currently testing.
Different team members on different Unity versions produce different behaviour in the same project, and importing assets in a newer editor can rewrite import settings for everyone. Pin the exact version in version control, install it from a version manager, and put the version in the repository README so a new contributor cannot miss it.
Unity vs Godot indie decisions come down to constraints rather than quality. Unity offers the deeper asset store, the smoother path to console, a large body of hire-and-pay documentation, and a C# ecosystem many studios already know. It also ships a heavier editor, a larger player download, and a licence whose cost scales with your success. Godot is MIT-licensed with no revenue share, downloads in seconds, and is comfortable for 2D and mid-weight 3D; it asks more of you on console publishing and third-party integrations, which you either arrange yourself or pay for.
A workflow that works for a lot of small teams: spend one week prototyping the same core loop in both engines and compare the results against your own criteria — how fast you can iterate, how small the build is, how easy the target platform is, and how the licence affects you at your realistic revenue. The game engine comparison indie guide has the full feature, pricing, and platform table, and the Godot 4 indie starter guide walks the free path from an empty project to a shipped build. If you are still setting up the rest of your pipeline, start with how to start indie game development and the complete indie game dev workflow.
Yes for most solo developers and small teams. Unity's Personal tier is free, including the full editor, the standard render pipelines, and the ability to ship commercial builds. The catch is that the free tier is conditional rather than unlimited: it applies while your studio's revenue and funding stay under a threshold that Unity publishes, and Unity has revised that threshold and the surrounding terms more than once. If you cross the threshold you need a paid tier, and paid tiers add a revenue share on top of the subscription fee. Read the current terms on Unity's own site before you commit, and re-check them in the year your game launches, because the number and the conditions have moved before. If a genuinely unlimited licence matters more to you than Unity's asset store and console support, Godot's MIT licence removes the question entirely.
It is a legitimate commercial licence, not a trial or an educational restriction, so you can ship a paid game with it as long as your studio stays inside the revenue and funding threshold at the time of release. The two practical risks are threshold changes between now and your launch date, and mixing in a second tool that carries its own licence conditions. Keep a dated copy of the terms you accepted, track your revenue against the published threshold, and check the licence of every paid asset or plugin in the project before you commit to shipping. If your funding situation is uncertain, decide the threshold question first and pick the engine afterwards, because changing engine late is far more expensive than switching licences early.
For most independent games, the Universal Render Pipeline is the right default. URP scales from 2D sprite projects to stylised 3D, supports mobile and desktop from the same material and shader setup, and has far lower hardware requirements than HDRP. Pick the built-in pipeline only if you are maintaining an existing project that already uses it, since upgrading an old project to URP means converting materials and shaders. Choose HDRP only when the visual target genuinely demands it, such as realistic lighting on desktop hardware, and accept the larger build size, longer shader compilation, and the extra work of maintaining a separate look for lower-end targets. A sensible indie workflow is to build the game in URP and treat HDRP as a late-stage desktop upgrade rather than a starting point.
Unity has no built-in Steam publishing, so you integrate the Steamworks SDK yourself. The order matters: register the game on Steamworks, pay the Steam Direct fee per title, fill in the store page, then build your player from Unity as a desktop standalone. Upload the player through SteamPipe, which handles content distribution and depot versioning, and use Steamworks for achievements, cloud saves, controller input, and overlay features. SteamPipe is free to use and only requires a machine that stays online to serve the build. Note that you still need a Steamworks partner account and must observe the platform fee that Steam takes on each sale, which is separate from anything Unity charges. Test a closed beta with real players before you open the store page, because the majority of first-week sales for an indie launch usually come from people who already follow the game's community.
Both are legitimate choices and the decision is mostly about your constraints rather than quality. Unity has the larger asset store, deeper console support, more hire-and-pay documentation, and a more familiar pipeline if you already know C# and want console releases later; the cost is a heavier editor, a licensing model tied to a published threshold, and a larger download for players. Godot is open source under the MIT licence with no revenue share and no seat limits, starts from a much smaller download, and is comfortable for 2D and mid-weight 3D projects; the trade-off is a younger 3D ecosystem and fewer ready-made console and third-party integrations, which you will have to arrange yourself or pay for. If you have no strong prior allegiance and the game is 2D or stylised 3D, prototyping the same core loop in both for a week is a cheap way to decide. The game engine comparison indie guide lays out the full feature and pricing table, and the Godot 4 indie starter guide covers the free path end to end.
最后更新：2026-11-02