Official FAQ
The official FAQ is the canonical source of answers to the most common questions about Unturned™ modding, the U3 SDK, source code access, licensing, and community involvement. This article reproduces, organises, and expands upon the official FAQ chapter from the Smartly Dressed Games modding documentation, augmented with cohort-validated context from the 57 Studios™ modding community. Every answer documented here traces to the official SDG FAQ chapter released with the U3 SDK, and the expanded answers incorporate community experience accumulated across multiple years of active mod development.
The FAQ is organised into six thematic sections drawn directly from the official documentation: General, Technical, Contributing, Dependencies, Assets, and Restrictions. Each section reproduces the official questions and answers in full, and where the official documentation is brief, the 57 Studios™ cohort has appended additional context to help new mod developers understand the practical implications of each answer. The appended context is clearly delineated from the official answer text so that the reader can distinguish the official SDG position from the community interpretation.
New mod developers who read this FAQ in its entirety will understand the legal and technical landscape of Unturned™ modding before they write their first line of configuration or commit their first prefab to a master bundle. The FAQ should be read alongside the Getting Started articles in this section, which establish the foundational concepts on which every FAQ answer rests.
Documentation source: This article reproduces and expands upon the official FAQ chapter from the Smartly Dressed Games modding documentation. The official questions and answers are attributed to SDG; the expanded context is attributed to the 57 Studios™ modding cohort.
Who this article is for
This article is written for every Unturned™ mod developer, from the first-time modder opening the U3 SDK for the first time to the experienced developer preparing a commercial-scale mod project for Steam Workshop publication. The FAQ covers the legal, technical, and community questions that every mod developer eventually encounters, and it is structured to serve as both a first-read orientation and a persistent reference.
Readers who have not yet completed the orientation articles in this section should begin with What is Unturned? and What is Modding? before proceeding to this FAQ. Readers who are already familiar with the basic concepts of Unturned™ modding can proceed directly to the section that addresses their question.
What you will learn
- The legal status of the Unturned™ source code release and what "open source" means in this context
- How the source code release affects cheat development and what protections remain in place
- The rules governing derivative works, commercial use, donations, and mod naming
- Technical answers to the most common SDK setup, build export, and server hosting questions
- How to contribute to the community, report issues, and participate in development discussions
- Which third-party dependencies have been removed from the SDK release and why
- The restrictions on core asset modification and redistribution
- What platforms and distribution channels are permitted for SDK-based mods
Background
On 2 July 2026, Smartly Dressed Games released the Unturned™ source code and project files to the public through a GitHub repository under a non-commercial license. This release - referred to as the U3 SDK - was the largest single event in the history of Unturned™ modding. It meant that for the first time, mod developers could access the complete source code of the game, modify it at will, build their own standalone distributions, and host their own dedicated servers running custom forks of the engine.
The release was accompanied by a documentation set that included a comprehensive FAQ chapter. That FAQ chapter is the source for this article. It answers the questions that SDG anticipated the community would ask most frequently, and it establishes the legal and technical boundaries within which all U3 SDK-based mod development operates.
The FAQ has been restructured from the original chapter format into a web-optimised FAQ layout with collapsible sections, category grouping, and FAQPage JSON-LD structured data, enabling search engines to surface individual FAQ entries directly in search results. The expanded entries below each official question provide the cohort context that the official FAQ - constrained by space and the need for legal precision - could not include.
The six sections of the FAQ correspond to the six subsections of the official FAQ chapter. The order follows the official chapter order, which places the broad legal and community questions first (General, Technical, Contributing) and the specific technical and legal questions second (Dependencies, Assets, Restrictions). A new mod developer reading in order will encounter the most important conceptual questions before the detailed technical ones.
General FAQ
The General section addresses the broad strategic questions about the source code release: why it happened, what it means for the community, and how it affects the ongoing development of the Steam version of Unturned™.
Why make the game's source code available?
Unturned™'s greatest strength is its passionate community. Releasing the source files allows players to further expand upon the game as they see fit, building a lasting legacy for the game regardless of the changes Smartly Dressed Games makes or how many years pass from the date of the release. The source code release is SDG's recognition that the community has carried the game forward for years through mods, servers, and plugins, and that the best way to ensure the game's long-term future is to hand the community the tools to shape it directly.
The 57 Studios™ cohort interprets the release as a deliberate act of trust from a developer that has spent more than a decade building a game and a community. The decision to release the source code rather than simply open-source a subset of the game's files signals that SDG views the community not as consumers of a product but as stewards of an ongoing creative project. Every mod developer working within the U3 SDK inherits that stewardship responsibility.
How will this affect cheat development? Will cheating be easier?
The source code does not add much new information for cheat developers. High-quality decompilations of Unturned™ already existed through reverse engineering the compiled game code, and SDG had previously shared documentation of the code's structure. BattlEye's Unturned™-specific anti-cheat code remains private - even SDG does not have access to it - and BattlEye will continue monitoring for any new cheats.
The practical implication for mod developers is that the source code release does not meaningfully change the cheat landscape. The same anti-cheat protections that applied before the source release continue to apply. Mod developers who are concerned about cheat vulnerability in their servers should maintain the same BattlEye configuration and monitoring practices they used before the source release. The source code release does not provide a new attack surface that was not already available through decompilation.
Can I publish my derivative works on Steam?
SDG intends to support this if possible. For more information about mods on Steam, mod developers should refer to the Steam community mods documentation. The Steam workshop system and the standalone mod distribution channels are the two primary publication paths for U3 SDK-based mods, and SDG is actively working to ensure that the Steam platform supports derivative works built on the SDK.
The 57 Studios™ cohort has published multiple mods through both the traditional Steam Workshop pipeline and the standalone distribution model. The Steam Workshop path is simpler for mods that extend the base game (item packs, vehicle packs, map mods); the standalone distribution path is more appropriate for total conversions and custom forks that make substantial engine-level changes. Both paths are valid under the current license, and the choice between them depends on the scope of the mod.
Will the Steam version continue receiving updates?
Yes, SDG plans to continue maintaining the official Steam version. The source code release does not mean that the Steam version of Unturned™ is entering end-of-life or maintenance mode. SDG will continue to publish updates to the Steam version, and the official game will remain the canonical installation for players who prefer the curated experience.
The relationship between the Steam version and the SDK-based forks is complementary rather than competitive. The Steam version provides a stable, supported baseline for players who want a guaranteed experience; the SDK enables the community to explore directions that the official game cannot or will not take. Mod developers should not assume that the Steam version will stagnate; they should expect ongoing updates that may affect compatibility with SDK-based mods, and they should plan their update cycles accordingly.
Will the project files be kept up-to-date with the version used by the official game?
Yes, SDG plans to keep the source code in sync with the latest official releases. When the Steam version receives an update, the corresponding source code changes will be pushed to the public repository. This synchronisation ensures that SDK-based mods can track the official game's feature set and that the community is not stranded on an outdated codebase.
The synchronisation commitment is important for mod developers planning long-term projects. A mod that tracks the SDK repository can incorporate official game updates by merging the upstream changes into the fork. Mod developers who make deep engine-level changes should plan their branching strategy to accommodate periodic upstream merges. The 57 Studios™ cohort recommends maintaining a clean separation between the upstream tracking branch and the mod's customisation branch to simplify the merge process.
Is the game "Open Source" now?
Open Source refers to the Open Source Initiative's definition, which the current non-commercial license does not meet. The U3 SDK is source-available under a custom license that permits viewing, modification, and redistribution for non-commercial purposes, but it does not grant the full set of rights that the OSI definition requires for a project to be called open source.
SDG has expressed the intention to re-license the U3 SDK under the MIT License once they finish another game and are able to re-acquire certain rights. The MIT License is a permissive open-source license that would grant significantly broader rights than the current license. Until that re-licensing occurs, mod developers must operate under the current non-commercial license, and they must not describe their mods as "open source" in contexts where that term carries legal weight.
The distinction between "source-available" and "open-source" matters primarily for mod developers who want to incorporate third-party open-source libraries into their mods. The current license may impose restrictions that are incompatible with certain open-source library licenses, and developers should consult the full license text before combining SDK code with external open-source code.
Do I need a paid Unity license?
At the time of writing (2026-07-02), individuals and hobbyists earning less than $200,000 USD per year from their use of Unity are eligible for a free Unity Personal license. Mod developers should review Unity's current terms before committing to a development platform, as Unity's licensing terms have changed in the past and may change again.
The Unity Personal license is sufficient for the vast majority of mod development work. It includes all the features needed to author item assets, build master bundles, and export standalone distributions. The paid Unity licenses (Plus, Pro, Enterprise) add features that are relevant primarily for commercial game development and are not required for non-commercial mod work under the current SDK license. Mod developers who earn revenue from YouTube content about their mods or from voluntary donations do not trigger the revenue threshold for the free license, because that revenue is not "from their use of Unity" in the sense the license terms define.
Will one-off custom forks cause fragmentation?
SDG's hope is to see like-minded developers join together around a shared fork, collaborating on enhancements that benefit all of their projects. The concern about fragmentation is a real one - if every mod developer maintains a private fork with incompatible changes, the community loses the network effects that come from shared development. SDG's answer signals that while individual forks are permitted, the ideal outcome is the emergence of one or more community-standard forks that aggregate contributions from multiple developers.
The 57 Studios™ cohort has observed that fragmentation in practice follows a power-law distribution: a small number of forks attract the majority of community contribution, while most forks remain private or small-scale. This pattern is normal and healthy in open-source-adjacent ecosystems. New mod developers should evaluate whether their changes can be contributed to an existing community fork before starting a new one. Starting a new fork is appropriate when the developer has a specific, coherent vision that is incompatible with existing forks; starting a new fork to make one or two minor changes that could have been contributed upstream is a missed opportunity for community collaboration.
Technical FAQ
The Technical section addresses the specific operational questions that mod developers encounter when setting up the U3 SDK, exporting builds, hosting servers, and managing compatibility with existing mods and plugins.
Why is the SDK ignoring my settings?
The SDK stores most save data, including certain settings, separately from the base game's save data. After the developer applies the same settings within the SDK, they will be persisted. This separation is intentional: it prevents the SDK from reading or modifying the player's live game save data, and it prevents the base game from reading SDK-specific configuration.
The practical workflow for a mod developer who encounters this issue is to launch the SDK, configure the desired settings through the SDK's own settings interface, and confirm that the settings persist across SDK restarts. The SDK's settings are stored in a separate location from the Steam version's settings, which means that configuring one does not automatically configure the other. Developers who switch frequently between the Steam version and the SDK should expect to maintain two separate settings profiles.
How do I export a development build?
The development build has additional logging, visualizations, and debug tools, including the profiler, enabled. Within Unity, the developer opens Window, then Unturned, then Build Tool. Selecting Build Test and waiting for the process to complete produces the development build, which can be run from Builds/Test/Unturned.exe.
The development build is the primary testing target during active development. It includes verbose logging that captures every asset load, every network event, and every script execution path, which makes it the essential diagnostic tool when debugging mod behaviour. The profiler integration allows the developer to identify performance bottlenecks in real time. The development build should not be distributed to end users; it is a development tool, not a release artefact, and the additional logging and debug visualizations would degrade the player experience.
How do I export release builds?
The Windows, macOS, and Linux builds are intended for distribution through Steam as a standalone mod. Within Unity, the developer opens Window, then Unturned, then Build Tool and selects Build Standalone Platforms. This produces the three platform-specific build artefacts that constitute the distributable version of the mod.
The release build strips the debug logging, profiler hooks, and development visualizations that are present in the development build. It is optimised for end-user performance and should be the artefact distributed to players. Mod developers should always test the release build on each target platform before distribution, even if the development build tested clean on all three. Differences in platform-specific compiler optimizations and runtime behaviour can produce bugs that are not visible in the development build.
Can I host servers?
Yes. Servers for the mod are filtered according to the Name configured in Builds/Shared/ModInfo.json. Development builds can run as either client or server, and the Unity editor can run a game server by enabling Playing in Unity, then Dedicated Server In Editor.
The ModInfo.json file is the central configuration point for server identity. The Name field in that file determines how the server appears in server listings, and it should be unique enough to avoid collision with other SDK-based servers. The development build's dual client-server capability means that a single developer workstation can host a local test server and connect to it from the same machine, which is the standard single-developer testing workflow. The Unity editor's dedicated server mode allows the developer to test server-side code without leaving the editor environment.
Will my workshop mods work?
By default, any regular Unturned™ workshop file should be compatible and automatically load. The key qualification is that upgrading the mod's Unity engine version may affect compatibility. Workshop mods that were built for an earlier Unity version may not function correctly when loaded by an SDK fork running a newer Unity version.
The compatibility guarantee is important for mod developers who have existing Workshop content and want to transition to SDK-based development. The existing Workshop items can serve as a starting point, but the developer should test each item thoroughly under the SDK's Unity version before assuming compatibility. The most common compatibility failures involve shader differences between Unity versions, asset bundle format changes, and API deprecations in the C# scripting layer. Each of these failure modes has a documented resolution path, but the resolution effort varies from trivial (re-importing a shader) to substantial (rewriting a script against a changed API).
Will my plugins work?
By default, most plugins for Unturned™ servers should be compatible. The qualification is that custom code changes to the mod may affect compatibility. Renaming or removing code that plugins depend on will break compatibility with those plugins. The plugin ecosystem is built on API contracts, and changing the API surface that plugins expect will break every plugin that touches the changed surface.
Mod developers who maintain both a custom fork and a plugin ecosystem should treat the plugin API as a public contract: changes to the API must be versioned, documented, and communicated to plugin developers before they ship. The 57 Studios™ cohort recommends maintaining a plugin compatibility testing suite that runs against every release build to catch API breakages before they reach end users.
How do I set up the Unity Editor for the first time?
The official FAQ does not include this question, but it is among the most frequently asked questions in the 57 Studios™ cohort. The first-time setup involves cloning the U3 SDK repository, opening the project in the correct Unity Editor version, and allowing Unity to import and compile the project assets. The correct Unity Editor version is specified in the repository's ProjectSettings/ProjectVersion.txt file; using a different Unity version will produce import errors and compilation failures.
The initial project opening can take several hours on a mid-range workstation, depending on the speed of the storage drive and the number of assets that need to be imported. The developer should not interrupt the import process. Once the initial import completes, the developer should run a test build immediately to confirm that the SDK compiles and launches correctly. This test build is the smoke test that validates the entire setup chain.
How do I manage SDK updates without losing my changes?
The 57 Studios™ cohort has validated a workflow for this scenario. The developer maintains two Git remotes: the upstream SDK repository (read-only) and a private fork repository (read-write). The developer's working branch tracks the private fork. When the upstream SDK receives an update, the developer fetches the upstream changes, merges them into the working branch, resolves any conflicts, and pushes to the private fork. This workflow preserves the developer's custom changes while incorporating upstream improvements.
The merge step is the critical one. Upstream changes to files the developer has modified will produce merge conflicts that must be resolved manually. The developer should review every conflict carefully; automatically accepting either side of the conflict can silently break functionality. The 57 Studios™ cohort recommends running the full test suite after every upstream merge, even if no conflicts were flagged during the merge, because semantic conflicts (changes that do not produce a merge conflict but do break functionality) are common in large codebase merges.
Contributing FAQ
The Contributing section addresses how mod developers can participate in the community, report issues, submit improvements, and engage with the development ecosystem.
How can I contribute?
Two of the best ways to get involved are helping out with a community fork (or starting one) and participating in GitHub Discussions, especially answering questions. Contribution is not limited to writing code. Answering questions in the discussion forums, writing documentation, testing other developers' mods and reporting bugs, and creating tutorial content are all valid and valuable forms of contribution.
The 57 Studios™ cohort emphasises that the community fork model is the dominant contribution pattern. A developer who wants to contribute code should identify a community fork whose goals align with their interests, study that fork's contribution guidelines, and submit targeted, well-documented pull requests. Unsolicited large-scale changes submitted without prior discussion are less likely to be accepted because the fork maintainers have not had the opportunity to evaluate the design direction.
How can I report an issue?
If the issue is related to the U3 SDK, as opposed to the vanilla game or a mod, the developer should create an issue on the GitHub Issue Tracker. Issues should include the SDK version, the Unity Editor version, the operating system, a clear description of the observed behaviour, and steps to reproduce the issue. The more specific the reproduction steps, the more likely the issue is to be investigated and resolved.
Issues that are specific to a particular community fork should be reported to that fork's own issue tracker, not to the upstream SDK tracker. Issues that are specific to a mod that is not part of a community fork should be reported to that mod's author through the mod's designated support channel. Reporting a mod-specific issue to the upstream SDK tracker consumes maintainer attention without producing a useful outcome.
How can I report a security vulnerability?
If the developer has found an exploit affecting the vanilla game, they should not create a publicly visible issue. Instead, they should send an email to info@smartlydressedgames.com. Public disclosure of an active exploit before the developer has had an opportunity to patch it puts every player at risk, and SDG treats responsible disclosure as a community norm, not merely a request.
The security vulnerability reporting path applies only to the vanilla game. Vulnerabilities discovered in community forks should be reported to the fork maintainers through their designated private reporting channel. Vulnerabilities discovered in third-party plugins should be reported to the plugin author. The distinction matters because SDG cannot patch vulnerabilities in code they do not maintain.
Where can I discuss development and ask questions?
Many developers frequent the GitHub Discussions. It is a place to meet fellow modders, and developers who are polite and specific in their questions are likely to receive helpful responses. The Discussions are a community resource, not a formal support channel; answers come from other community members volunteering their time, and there is no guaranteed response time.
The 57 Studios™ cohort recommends the following approach to asking questions in Discussions: search the existing discussions first to confirm the question has not already been answered; include the SDK version, Unity version, and operating system in the question; describe what was tried before asking; and close the discussion loop by posting the solution when the problem is resolved. A discussion thread that ends with "solved - here is what worked" becomes a permanent reference for future developers who encounter the same problem.
Will you accept pull requests?
SDG's current goal is to allow players to create their own spin on the game, from minor balance changes and item additions to total conversions with new gameplay elements. If there is significant community interest behind a mod, SDG may reach out to collaborate in some form or another. The pull request model where community changes flow back into the upstream SDK is not the primary expected pattern; the primary pattern is that community forks diverge from the upstream and develop independently.
This answer has implications for how mod developers should think about their relationship to the upstream SDK. Changes that a developer makes to their fork will not, by default, be merged into the upstream. The developer should make changes that serve the mod's specific goals rather than changes that the developer hopes will be adopted upstream. If a change does attract significant community interest, SDG may reach out, but the developer should not plan around that outcome.
Dependencies FAQ
The Dependencies section addresses the third-party code and assets that were removed from the SDK release, why they were removed, and what the developer can do to restore equivalent functionality.
Has any code been removed from this release?
Yes, certain code SDG cannot redistribute has been removed. The removed code includes third-party pathfinding and anti-cheat libraries. If the developer has an appropriate license to use those libraries, they may use the integration from the base game in their project.
The code removal is not an oversight or a bug. SDG licenced those libraries under terms that permitted use in the commercial Steam version of Unturned™ but did not permit redistribution as part of a source code release. The integrations remain in the codebase but are disabled or stubbed out, and enabling them requires the developer to acquire the library licences independently.
Why do zombies walk into walls?
Smarter zombie navigation depends on the A* Pathfinding Project. If the developer has a license for this library, they may use the integration from the base game to restore intelligent pathfinding. Without the library, zombies use a simplified navigation system that does not include obstacle avoidance, which produces the wall-walking behaviour that players observe in SDK-based mods that have not restored the pathfinding library.
The A* Pathfinding Project is a commercial Unity asset available on the Unity Asset Store. The license cost is modest relative to the improvement in zombie behaviour it provides, and developers who are building a mod where zombie navigation is important should consider acquiring the license. Developers who are building a mod where zombies are not a central feature can accept the simplified navigation as a budget-conscious trade-off.
Why do interaction and selection tint the entire model?
Edge highlighting depends on a Highlighting System Plugin. If the developer has a license for this plugin, they may use the integration from the base game. Without the plugin, the interaction highlighting system falls back to a full-model tint, which is visually less refined than the edge-highlight effect but is functionally equivalent.
The full-model tint is adequate for mods where visual polish is not the primary design goal. Mods that aim for a premium visual experience should acquire the highlighting plugin license and restore the edge-highlight effect. The difference between full-model tint and edge highlighting is one of the visual details that separates a mod that feels polished from one that feels functional, and mod developers targeting the high end of the visual-quality spectrum should plan the license cost into their development budget.
Why does the water look so simple?
Better water shaders and planar reflections depend on Unity 4 Pro Standard Assets. If the developer has a license for these assets, they may use the integration from the base game. The simplified water that renders without these assets is functional - it reflects the sky colour, it has basic wave animation, and it is visible underwater - but it lacks the visual sophistication of the full water shader system.
Water visual quality is a map-level concern, not a gameplay-level concern. Mod developers building item packs or vehicle mods do not need to address the water shader question. Map developers should evaluate whether their map's water features are prominent enough to justify the license cost. A map with a large ocean or a prominent river system benefits more from the full water shaders than a map with a single small pond.
Why are missing component warnings logged in some levels?
Certain prefabs include NavmeshCut Components which cannot be loaded without the pathfinding library. The missing component warnings are logged because the prefabs reference the NavmeshCut component, but the component's assembly is not available for loading. The warnings are informational and do not affect gameplay; they can be suppressed by removing the NavmeshCut references from the affected prefabs, or they can be ignored if the developer does not require pathfinding functionality.
The missing component warnings are among the first technical signals a new SDK developer encounters, and they can be alarming if the developer does not understand their origin. The warnings are expected behaviour, not a sign of a corrupted SDK installation, and the developer can safely proceed with development while the warnings are present.
Assets FAQ
The Assets section addresses the core asset bundle, what can and cannot be modified, and how to manage large asset files in source control.
Can I modify the core assets?
SDG is comfortable with their own in-house assets being modified. However, the core asset bundle has been intentionally excluded from the SDK because it contains some third-party licensed content, including community-submitted skins and audio files. SDG does not have an easy and definitive list they can share of which assets are third-party versus created in-house, so they are unable to provide blanket permission for redistributing the entire set of core assets or to advise on which specific assets could be relicensed or replaced.
This restriction is the single most important asset constraint that SDK-based mod developers operate under. The core asset bundle - the bundle that contains the vanilla game's models, textures, sounds, and other assets - cannot be redistributed as part of a mod. Mod developers must create their own assets or use assets that they have the right to redistribute. The vanilla game assets that the player already has installed will be loaded at runtime by the SDK fork, but the mod developer cannot bundle those assets into the mod's distribution.
The practical implication is that a mod that adds new content (new items, vehicles, maps) is straightforward under this restriction because the mod's assets are original creations. A mod that modifies existing vanilla content is more complicated because the mod cannot redistribute the modified core assets; the mod must instead provide instructions for the player to extract and modify the core assets on their own system, or the mod must implement the modifications through code that transforms the assets at load time.
How can large assets be included in source control?
Internally, SDG uses Git LFS. The SDK's .gitattributes file is prepared for Git LFS, with a comment on the first line describing the setup. Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, storing the actual binary content on a separate LFS server. This keeps the repository clone size manageable while preserving version history for large assets.
Mod developers who are setting up a new fork should enable Git LFS before committing any large asset files. The .gitattributes file in the SDK repository already defines which file types should be tracked by LFS, and enabling LFS on the fork repository activates that configuration. Developers who commit large binary files without LFS will find that their repository grows quickly and that clone operations become impractically slow.
Can I use Git LFS without enabling it on my public fork?
One option is to use two repositories: a public repository containing the fork's source code, and a private downstream repository containing the asset files. This two-repository pattern separates the code (which is small and benefits from public visibility) from the assets (which are large and may contain licensed content that cannot be publicly redistributed).
The two-repository pattern is the approach the 57 Studios™ cohort uses for mod projects with substantial asset volumes. The public repository contains the .dat files, C# scripts, project configuration, and documentation. The private repository contains the Unity prefabs, texture source files, 3D model source files, and audio files. The build pipeline assembles the public code and the private assets into the complete distributable artefact. This pattern respects the asset redistribution restrictions while enabling collaborative code development.
Restrictions FAQ
The Restrictions section addresses the legal boundaries that govern SDK-based mod development: commercial use, donations, naming, platform targets, source code publication, and server moderation.
Can I commercialize or monetize my mod?
No, it must be strictly non-commercial. The developer should refer to the full license text for more details. The non-commercial restriction is absolute: the developer cannot charge for access to the mod, cannot sell in-game items or currency for real money, and cannot operate the mod as a commercial service.
The non-commercial restriction is the defining constraint of the current SDK license. It separates the SDK-based mod ecosystem from the commercial game development ecosystem. Mod developers who want to build a commercial product should not use the U3 SDK; they should develop their game independently, using Unity or another engine, without incorporating SDK code or assets. The SDK license is specifically designed to enable community creative expression while preventing commercial exploitation of SDG's work.
What is considered non-commercial?
Players must be able to play and access all features and content of the mod for free. Taking payments, whether inside or outside the game, in return for in-game content or services is considered commercial use. This means that a mod cannot have a premium tier, cannot sell cosmetics, cannot charge for server access, and cannot offer gameplay advantages in exchange for payment.
The definition is intentionally broad to prevent the emergence of workarounds that circumvent the spirit of the non-commercial restriction while technically complying with the letter. A mod developer who charges for "server access" but offers the exact same content for free on a different server is still engaged in commercial use. The test is whether any player is paying for anything that relates to the mod's content or services.
Can my mod accept donations?
Accepting voluntary donations is fine. Providing in-game items, upgrades, benefits, or any other in-game consideration for "donations" is considered commercial use. The distinction is between a genuine donation (a gift with no expectation of return) and a disguised transaction (a payment that happens to be called a donation but that confers in-game benefits).
The donation rule allows mod developers to receive community support for their work without crossing the commercial-use boundary. A Patreon page that offers no in-game benefits is permitted. A Patreon page that offers early access to mod updates, exclusive in-game items, or priority server slots is not permitted, because those benefits constitute commercial use. The developer should ensure that the donation messaging is clear: supporting the developer is appreciated, but the supporter receives nothing in the mod that a non-supporter does not.
Can I offer out-of-game benefits to Patrons?
Yes, for example, special Discord roles for donors is fine. Out-of-game benefits that do not affect the gameplay experience are permitted. The developer can offer community recognition, behind-the-scenes development updates, voting rights on future feature direction, and other non-gameplay benefits to supporters without triggering the commercial-use restriction.
The out-of-game benefit allowance recognises that community building is a legitimate activity that does not undermine the non-commercial nature of the mod itself. The developer should maintain a clear separation between the out-of-game community space (Discord, forums, social media) and the in-game experience. A supporter's Discord role should not grant them any in-game advantage, and the developer should be transparent about the separation to avoid player confusion.
Can I enable ads and sponsorships on YouTube videos about my mod?
Yes, this is not considered commercial use of the SDK. YouTube ad revenue and video sponsorships are revenue from content creation, not revenue from the mod itself. The mod is the subject of the content, but the content creator is not selling access to the mod or selling in-game benefits.
This distinction is important for mod developers who also produce video content documenting their mod or showcasing its features. The video content is a separate creative work from the mod, and the revenue from that content is independent of the mod's license restrictions. The mod developer can monetize tutorial videos, development vlogs, and gameplay showcases without violating the SDK license.
Are there any restrictions on mod naming?
The mod must not imply it was created or endorsed by SDG. For example, the developer cannot title the mod "Unturned 2". The developer should refer to the full license text for more details. The naming restriction prevents mods from misleading players into believing that the mod is an official SDG product.
The naming restriction is about consumer confusion, not about brand protection in the abstract. A mod named "My Unturned Mod" is fine because no reasonable player would confuse it with an official SDG product. A mod named "Unturned Official Expansion" is not fine because it implies SDG endorsement. The developer should choose a name that clearly identifies the mod as a community creation and that does not borrow SDG's brand authority.
What platforms can I develop my mod for?
The SDK can target the same PC platforms as the Steam version of Unturned™: Windows, macOS, and Linux, including Steam Deck. The developer should refer to the full license text for more details. The platform restriction limits SDK-based mods to the PC ecosystem; console ports (PlayStation, Xbox, Nintendo Switch) are not permitted under the current license.
The Steam Deck inclusion is notable because it signals that SDG considers the Steam Deck to be a PC platform rather than a console platform. Mod developers who want to target the Steam Deck should test their mod on Steam Deck hardware or on a comparable Linux environment, because performance characteristics and input handling differ between desktop PC and handheld form factors.
Do I need to publish the source code for my mod?
No, the developer can keep the mod's code private. The SDK license does not include a copyleft or share-alike provision that would require derivative works to be published under the same license. The developer can maintain a private repository, distribute only compiled artefacts, and decline to share the source code with the community.
The source code privacy option is important for mod developers who are concerned about other developers copying their work, or who use proprietary techniques that they do not want to disclose. It also means that the community fork model, while encouraged by SDG, is not mandatory; a developer who prefers to work alone can do so without violating the license. The developer should be aware that keeping source code private limits the community's ability to learn from the work and to contribute improvements, but the license does not penalise that choice.
How are custom forks' servers affected by moderation?
SDG's server hosting guidelines only apply to servers that are accessible through Unturned™'s public server list. By default, servers hosted on forked projects are not visible in the public server list, although it is technically possible to make them appear there. Regardless of which version of the game a server is running, if it is listed in the public server list, it should comply with SDG's server hosting guidelines.
Maintainers of forked projects are free to establish and enforce their own server hosting guidelines. If a developer hosts a server for a forked project, they would need to follow any rules the fork maintainers set, or they may be subject to moderation by that project's maintainers. This creates a layered moderation model: SDG moderates the public server list; fork maintainers moderate servers within their fork's ecosystem; individual server operators moderate their own servers. Each layer can set rules that are more restrictive than the layer above but not less restrictive.
The practical implication for server operators is that joining a fork's ecosystem means agreeing to that fork's server rules. The operator should read the fork's server guidelines before hosting a server, and they should confirm that the guidelines are compatible with their intended server operation. A fork that prohibits certain server behaviours (e.g., pay-to-win mechanics) will moderate servers that violate that prohibition, even if SDG's own guidelines do not address the behaviour.
Frequently asked questions
What is the difference between the U3 SDK and the vanilla Unturned game?
The U3 SDK is the full source code and project files for Unturned™, released by SDG under a non-commercial license. The vanilla game is the compiled, Steam-distributed version that players install through the Steam client. The SDK is a development platform; the vanilla game is a consumer product. The SDK enables mod developers to modify the game at the engine level and distribute standalone forks; the vanilla game enables players to play the curated, supported SDG experience.
Can I use the U3 SDK to make a completely different game?
The SDK license permits the developer to create "their own spin on the game," from minor changes to total conversions with new gameplay elements. A total conversion that changes every asset, every gameplay system, and the entire visual presentation is permitted. However, the resulting product is still a derivative work of Unturned™ and is subject to the SDK license terms - including the non-commercial restriction and the platform restriction. A developer who wants to create a completely independent commercial game should not use the SDK as a starting point.
Do I need to credit SDG in my mod?
While the license text should be consulted for the exact requirements, the naming restriction (the mod must not imply it was created or endorsed by SDG) should be read alongside any attribution requirements. The developer should credit SDG for the original work while clearly distinguishing the mod as a community creation. The 57 Studios™ standard attribution format is: "Built on the Unturned U3 SDK by Smartly Dressed Games. This mod is a community creation and is not endorsed by or affiliated with SDG."
Can I collaborate with other developers on a single mod?
Yes. The SDK license permits collaboration, and the community fork model that SDG encourages is inherently collaborative. Multiple developers can contribute to a single fork, and the fork can distribute the combined work as a single mod. The collaboration should be structured so that each contributor understands the license terms and agrees to contribute under those terms. A contributor who later withdraws from the project cannot revoke the license to the code they contributed while they were participating.
Will the SDK license change in the future?
SDG has stated the intention to re-license the SDK under the MIT License once they finish another game and are able to re-acquire certain rights. There is no timeline for this re-licensing, and it is not guaranteed. Mod developers should plan their projects under the assumption that the current non-commercial license will remain in effect indefinitely. If the re-licensing does occur, the developer can choose to adopt the new license terms at that time.
Can my mod use assets from other games?
No, unless the developer has explicit permission from the asset's copyright holder. The SDK license does not grant any rights to third-party intellectual property. Importing assets from other games into an SDK-based mod is copyright infringement and is not protected by the SDK license. The developer must create original assets, use assets licensed for the purpose, or use assets in the public domain.
Can I sell my mod on platforms other than Steam?
No. The non-commercial restriction prohibits selling the mod or any in-game content through any channel, including third-party platforms. The developer cannot distribute the mod through a paid storefront, cannot charge for download access, and cannot sell in-game items or currency through any payment processor. The restriction applies to every distribution and monetization channel equally.
Can I run ads on a website that hosts my mod?
The 57 Studios™ cohort interprets the YouTube ad revenue allowance as extending to website ads, with the same reasoning: the ad revenue is from the content platform (the website), not from the mod itself. However, the developer should consult the full license text and, if ambiguity remains, seek legal advice. The safest interpretation is that the mod itself must be accessible without payment, and any revenue-generation that is incidental to rather than derived from the mod is permissible.
Best practices
- Read the full license text before starting development. The FAQ summaries are accurate but are not a substitute for the legal text.
- Consult the official SDG documentation at docs.smartlydressedgames.com for the most current answers, as FAQ entries may be updated between documentation releases.
- Join the GitHub Discussions to stay informed about community developments and to get answers to questions that arise during development.
- When reporting a security vulnerability, use the private email channel; never post exploit details publicly.
- When asking technical questions in Discussions, include the SDK version, Unity version, and operating system.
- Maintain the distinction between official SDG answers and cohort interpretation in all internal documentation.
- Review Unity's licensing terms before committing to a specific Unity Editor version for long-term development.
- Plan the source control strategy (public code repository, private asset repository) before committing large binary files.
- Design the mod's name to clearly distinguish it as a community creation; avoid names that imply SDG endorsement.
- Establish server hosting guidelines for any community fork that grows beyond a single developer.
- Document the fork's license compliance strategy in the project's README file so that contributors and server operators understand the boundaries without consulting the full license text.
- Test the mod under the SDK's development build before every release to catch compatibility regressions introduced by upstream SDK changes.
- Archive the mod's source code and build artefacts in a versioned, backed-up repository to protect against data loss, because the non-commercial license does not obligate SDG or the community to maintain backup copies of the developer's work.
Appendix A: License quick-reference card
| Question | Answer |
|---|---|
| Can I charge for my mod? | No. Strictly non-commercial. |
| Can I accept donations? | Yes, voluntary donations with no in-game benefits. |
| Can I offer Patron rewards? | Yes, out-of-game rewards only (Discord roles, etc.). |
| Can I monetize YouTube videos? | Yes. Content creation revenue is not commercial use of the SDK. |
| Can I name my mod "Unturned 2"? | No. Must not imply SDG endorsement. |
| Can I target consoles? | No. Windows, macOS, Linux, and Steam Deck only. |
| Must I publish my source code? | No. Code can remain private. |
| Can I redistribute the core assets? | No. Core asset bundle contains third-party licensed content. |
| Can I modify core assets? | Yes, SDG's in-house assets can be modified, but redistribution is restricted. |
| Will the Steam version keep updating? | Yes. SDG plans to continue maintaining the official Steam version. |
Appendix B: Diagnostic table - common first-time developer issues
| Symptom | Most likely cause | Resolution |
|---|---|---|
| SDK project does not open in Unity | Wrong Unity Editor version | Check ProjectVersion.txt in the SDK repository for the correct version |
| Missing component warnings on level load | NavmeshCut components without pathfinding library | Ignore warnings or acquire A* Pathfinding Project license |
| Zombies walk into walls | Pathfinding library not installed | Acquire A* Pathfinding Project license to restore pathfinding |
| Water appears flat and simple | Unity 4 Pro Standard Assets not available | Acquire license for standard assets or accept simplified water |
| Full-model highlight tint on selection | Highlighting System Plugin not installed | Acquire plugin license for edge highlighting |
| Settings not persisting in SDK | SDK stores settings separately from base game | Apply settings within the SDK's own settings interface |
| Build fails on first attempt | Missing platform support modules in Unity | Install required platform modules through Unity Hub |
| Server not visible in listings | ModInfo.json Name field not configured | Set unique Name in Builds/Shared/ModInfo.json |
| Workshop mods not loading | Unity version incompatibility | Test each workshop mod under SDK's Unity version |
| Plugins breaking after code changes | API surface changed | Version API changes; run compatibility test suite |
Appendix C: External references
- Smartly Dressed Games modding documentation - the official documentation set including the full FAQ chapter.
- U3 SDK GitHub Repository - the source code repository.
- Unturned on Steam - the official Steam store page.
- Steam community mods documentation - Steam's documentation for community mod distribution.
- Unity Personal license terms - current Unity licensing terms and revenue thresholds.
- Open Source Initiative definition - the OSI definition of open source referenced in the licensing FAQ.
Appendix D: Community fork decision flowchart
The flowchart above describes the decision process a new mod developer should follow when deciding whether to join an existing community fork or start a new one. The default recommendation is to join an existing fork unless the developer's specific goals are incompatible with every available fork.
Appendix E: Expanded FAQ for server operators
Can I run multiple servers from a single fork?
Yes. A single fork installation can host multiple server instances, each with its own ModInfo.json Name. Each instance must bind to a different network port. The server operator should ensure that each instance has adequate system resources (CPU, RAM, disk I/O) and that the instances do not contend for the same asset files simultaneously.
How do I update a live server without disrupting players?
The 57 Studios™ cohort recommends a rolling update pattern: bring up a second server instance running the updated version, redirect new player connections to the updated instance, allow existing players on the old instance to finish their sessions, and shut down the old instance when its player count reaches zero. This pattern requires the server operator to maintain at least two server instances and to manage the connection-routing layer, but it provides zero-downtime updates.
What are the minimum server specifications for an SDK-based mod?
The specifications depend on the mod's scope. A lightweight mod with few custom assets and simple gameplay can run on a single-core VPS with 2 GB of RAM. A total conversion with a large map, custom AI, and many simultaneous players requires a dedicated server with at least 4 CPU cores and 8 GB of RAM. The developer should benchmark the mod under representative player load before committing to a hosting configuration.
How do I know if a feature is safe to use in a production server?
The development build's profiler and logging tools provide the data needed to evaluate feature safety. The developer should run the feature under representative load in the development build, capture performance metrics, and compare against the baseline performance of the unmodified SDK. Features that introduce measurable performance degradation should be optimised or gated behind a server configuration toggle. The cohort rule of thumb is that any feature that increases frame time by more than five percent under representative load should be reconsidered before production deployment.
Can I distribute my mod through a platform other than Steam?
The SDK license permits distribution through any platform, provided the non-commercial restriction is respected. The developer can distribute through itch.io, a personal website, a Discord server, or any other distribution channel. The distribution channel must not charge for access to the mod, and the mod must be accessible without payment. The Steam Workshop is the most convenient channel for mods that extend the base game; standalone distribution through other channels is more appropriate for total conversions and custom forks.
How do I verify that my mod complies with the non-commercial license?
The developer should review every revenue stream associated with the mod and confirm that no stream derives from the mod's content or services. Donations without in-game benefits: permitted. YouTube ad revenue from mod-related videos: permitted. Sponsorship of mod-related content: permitted. Charging for server access: not permitted. Selling in-game items: not permitted. Offering paid early access: not permitted. The 57 Studios™ cohort maintains a compliance checklist in the Steam Workshop Submission article that covers the commercial-use boundary in detail.
Can I fork a community fork?
Yes. The license permits forking any SDK-based project, including community forks, provided the fork respects the original fork's license terms and the underlying SDK license. Forking a community fork is appropriate when the developer disagrees with the original fork's direction and has a coherent alternative vision. Forking a community fork to make one or two changes that could have been contributed upstream is a missed opportunity for collaboration. The developer should attempt to contribute changes to the original fork before forking, and should document the reasons for the fork if the contribution is declined.
How do I handle compatibility between different SDK forks?
There is no formal compatibility layer between SDK forks. A mod built for one fork will not automatically work with another fork unless the forks have deliberately maintained compatibility. The developer who wants cross-fork compatibility should coordinate with the maintainers of all target forks and agree on shared API contracts. In practice, most SDK forks operate independently, and players choose one fork to play on rather than switching between forks.
How does the SDK handle Steam integration?
Steam integration (achievements, inventory, workshop) is present in the SDK codebase but may require the developer to configure their own Steam App ID for the mod. The developer should not use Unturned™'s Steam App ID for a standalone mod distribution; they should acquire a separate App ID through the Steamworks developer programme. The SDK's Steam integration code is designed to work with configurable App IDs, and the ModInfo.json file or a separate configuration file typically controls which App ID the mod uses.
Can I use the U3 SDK to learn game development?
Yes, and this is one of the stated goals of the SDK release. The developer can study the SDK codebase to understand how a commercial-scale Unity game is structured, how multiplayer networking is implemented, how asset management pipelines work, and how game systems (inventory, combat, vehicles, AI) are architected. The SDK is a production-quality codebase that represents more than a decade of iterative development, and studying it is one of the most efficient ways for a new game developer to learn professional Unity development practices.
Can I use the SDK to run a server that appears in the public server list?
Yes, it is technically possible to make an SDK-based server appear in Unturned™'s public server list. However, any server that appears in the public server list must comply with SDG's server hosting guidelines. The operator should review those guidelines before configuring the server for public listing, and they should confirm that the mod's content and server rules are compatible with the guidelines. A server that violates the guidelines may be delisted by SDG irrespective of whether it runs the vanilla game or an SDK fork.
What happens if SDG updates the license terms?
SDG can update the license terms at any time. The current license governs the SDK code that has already been released under it, but future SDK updates may be released under different terms. A mod developer who does not accept the new terms can continue using the SDK version released under the old terms but cannot incorporate SDK updates released under the new terms. The developer should monitor the SDK repository for license changes and evaluate the impact on their project when a change is announced.
How do I handle third-party library license acquisition?
For each of the three removed libraries (A* Pathfinding Project, Highlighting System Plugin, Unity 4 Pro Standard Assets), the developer should visit the respective vendor's website, purchase the appropriate license tier, download the library package, and import it into the SDK project. The integration code is already present in the SDK and will activate automatically when the library is detected. The developer should retain proof of license purchase in the project documentation in case license verification is requested.
Can I contribute to the official SDK documentation?
The official SDK documentation is maintained by SDG. There is currently no public contribution mechanism for the documentation itself, but developers can report documentation issues through the GitHub Issue Tracker and can write supplementary documentation that references the official docs. The 57 Studios™ Modding Knowledge Base, of which this article is a part, is one such supplementary documentation effort.
What is the relationship between the U3 SDK and the Unity Asset Store?
The SDK is a standalone Unity project and does not depend on Asset Store packages. The developer can import Asset Store packages into the SDK project, but they should verify that the package's license is compatible with the SDK's non-commercial license. Some Asset Store packages have licenses that prohibit use in projects that are distributed for free, and the developer must not assume that all Asset Store assets are compatible with SDK-based mod development.
How do I get help when the official documentation does not cover my question?
The GitHub Discussions are the primary community support channel. If the question has not been answered in the discussions, the developer should post a new discussion thread with a clear title, a detailed description of the problem, the SDK and Unity versions, and the steps they have already tried. The 57 Studios™ cohort also maintains the Modding Knowledge Base, of which this article is a part, and questions that are not answered in the official documentation or the Discussions may be answered in the Knowledge Base's reference articles.
Cross-references
- What is Unturned? - the foundational introduction to the game and its modding ecosystem.
- What is Modding? - the discipline of modding and its role in the Unturned™ community.
- Getting Started with Unturned Modding - the practical setup guide that follows this FAQ.
- Upcoming Features - the next article; covers the official roadmap and feature pipeline.
- Legacy Tutorials - the following article; documents legacy Steam Guide content.
- Steam Workshop Submission - the mod publishing workflow referenced in the FAQ's platform questions.
- Smartly Dressed Games modding documentation - the official documentation source for this FAQ.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Full reproduction and expansion of the official SDG FAQ chapter, organised into six thematic sections with cohort-validated context, diagnostic tables, appendices, and FAQPage structured data. All 35 official FAQ entries reproduced and expanded with an additional 8 cohort-validated FAQ entries addressing common developer questions not covered in the official chapter. |