Upcoming Features
The Unturned modding feature set is under active development, and Smartly Dressed Games maintains a public roadmap of features under consideration. This article documents the current state of the feature pipeline, explains how mod developers can stay informed about upcoming changes, and provides practical advice for planning mod projects around an evolving feature set. The roadmap is not a release schedule; it is a collection of ideas and priorities that SDG is evaluating for future development cycles, and the items on it may change, be reordered, or be removed as development priorities shift.
Understanding the feature pipeline is essential for mod developers who are planning long-term projects. A feature that is under consideration today may ship in the next SDK update, and a mod that duplicates the upcoming feature's functionality will need to adapt when the official implementation arrives. Conversely, a feature that the roadmap indicates is not being prioritised may be a safe target for community development without fear of official replacement.
This article is the companion to the Official FAQ, which documents the current state of the SDK and its licensing. Together, the FAQ and this article provide a complete picture of the present and future of Unturned modding.
Who this article is for
This article is written for active Unturned mod developers who want to align their development plans with SDG's announced feature direction. New mod developers who are just starting out should read the Getting Started articles and the Official FAQ before consulting this article; the feature pipeline is relevant primarily after the developer has established a working development environment and is planning a mod project that will span multiple SDK update cycles.
Server operators and community fork maintainers who need to plan infrastructure investments around the expected feature trajectory will find the roadmap information especially relevant, because the SDK updates that ship roadmap features may require server-side configuration changes, plugin compatibility updates, and player-facing migration efforts.
What you will learn
- Where to find the official Unturned modding feature roadmap
- How to interpret the roadmap cards and their priority indications
- What categories of features are under active consideration
- How to stay informed about feature progress and SDK updates
- How to plan mod projects around an evolving feature set
- The distinction between roadmap items and committed features
- How to provide feedback on features under consideration
- The practical implications of SDG's development cadence for mod developers
Background
Smartly Dressed Games maintains the Unturned modding feature roadmap on a public Trello board. The roadmap is the canonical source of information about features that SDG is considering for future development. It is not an ordered release schedule, and the cards on the board are not arranged in any particular order - they do not dictate the sequence of future updates. The roadmap is a window into SDG's development priorities, not a commitment to specific features or timelines.
The roadmap exists alongside the official modding documentation and the U3 SDK repository. While the documentation describes what is already available, and the SDK repository contains the current state of the source code, the roadmap describes what may become available in future updates. The three sources together - documentation, repository, and roadmap - form the complete information surface for mod development planning.
Miscellaneous requests and tasks that arise during development take priority over the roadmap. SDG's development team handles bug fixes, security patches, and emergent issues as they occur, and these unplanned tasks can delay progress on roadmap items. Several high-priority ideas that do not yet have a solid implementation plan - such as a crafting system revamp - are not listed on the roadmap at all, because the roadmap only includes features that have reached the evaluation stage. Features that are too early in the planning process to have a concrete direction are tracked internally by SDG and are not visible to the community.
The 57 Studios cohort has observed that the SDG development cadence for modding features has historically been measured in months rather than weeks. Major feature additions typically ship with larger SDK updates that may bundle multiple roadmap items together. Minor improvements and bug fixes may ship in between major updates. The developer should not expect a specific roadmap item to ship in any given month; the roadmap is a directional indicator, not a delivery calendar.
The flowchart above shows the typical lifecycle of a modding feature from initial idea to stable release. The cycle from roadmap card to SDK update can span multiple months, and features frequently iterate after initial release based on community feedback. A developer planning a project around a roadmap feature should budget for this cycle time and should not assume that the feature will be available in its initial form when the project reaches the implementation phase.
The official roadmap
The Unturned modding feature roadmap is published on a public Trello board. The board is accessible to any developer without requiring an account, although creating a free Trello account enables the developer to watch the board and receive notifications when cards are added, moved, or updated.
The board is organised into lists that represent the stages of the feature evaluation process. The exact list names and organisation may change over time as SDG refines the roadmap structure, but the general pattern is:
| List | Meaning |
|---|---|
| Under Consideration | Features that SDG is evaluating for inclusion. These items may or may not be developed. |
| Planned | Features that have passed initial evaluation and are scheduled for development when resources become available. |
| In Progress | Features that are currently being developed. These items are the most likely to ship in the near term. |
| Recently Completed | Features that have shipped in a recent SDK update. These items serve as a changelog of delivered work. |
The cards on the board contain a title describing the feature and, in some cases, additional details in the card description. Cards may be moved between lists as their evaluation status changes. A card that moves from "Under Consideration" to "Planned" is a signal that SDG has committed to developing the feature, though the timeline remains unspecified. A card that moves from "Planned" to "In Progress" indicates active development. A card that moves to "Recently Completed" indicates that the feature has shipped and can be used in current SDK versions.
Finding the roadmap
The Trello board URL is provided in the official SDG modding documentation under the Upcoming Features chapter. The board is the single source of truth for the feature pipeline. Community-discussed features that do not appear on the board have not been confirmed by SDG as under consideration, regardless of how widely they are discussed in the community.
How to interpret roadmap cards
A roadmap card is a signal of interest, not a guarantee of delivery. The developer should read each card as "SDG is considering or working on this" rather than "this feature will ship." Features that have been on the board for an extended period without movement are still under consideration but are not being actively developed. Features that have moved through multiple lists in a short period are receiving active attention.
The absence of a feature from the roadmap does not mean the feature will never be developed. SDG may be evaluating the feature internally without having reached the stage where a public roadmap card is warranted. The developer who wants a specific feature should not assume that its absence from the roadmap means it has been rejected; they should also not assume that its presence on the roadmap means it will ship on any particular timeline.
Roadmap interpretation
The roadmap is not a contract. Features can be removed from the roadmap without notice if SDG determines that they are not feasible, not aligned with development priorities, or superseded by other work. A mod project that depends on a roadmap feature should include a contingency plan for the scenario in which the feature does not ship or ships in a form that is incompatible with the project's design.
Categories of features under consideration
The features on the Unturned modding roadmap span several broad categories. Understanding these categories helps the mod developer identify which roadmap items are relevant to their specific mod project.
Modding toolchain improvements
Features in this category improve the toolchain that mod developers use to create, test, and publish mods. These may include improvements to the Unity Editor integration, enhancements to the build tool, better diagnostic tooling, and streamlined publishing workflows. Toolchain improvements affect every mod developer equally, regardless of the specific content the developer is creating. New mod developers benefit disproportionately from toolchain improvements because they lower the barrier to entry for creating functional mods.
Asset pipeline enhancements
Features in this category extend the types of assets that mod developers can create or modify. New asset types, new fields on existing asset types, and new interactions between asset types fall into this category. Asset pipeline enhancements enable mod developers to create content that was not previously possible within the modding system, and they typically require corresponding updates to the SDK documentation and the community knowledge base to become fully accessible to the developer community.
Engine and rendering features
Features in this category modify the game engine itself: rendering improvements, physics changes, networking enhancements, and performance optimisations. Engine features are the most impactful category because they affect every aspect of the game, but they are also the most complex to develop and the most likely to introduce compatibility issues with existing mods. A mod developer who plans to use a roadmap engine feature should budget substantial testing time after the feature ships to ensure that their mod functions correctly on the updated engine.
Server and multiplayer features
Features in this category affect the dedicated server, the networking model, and the multiplayer experience. Server features are especially relevant for community fork maintainers and server operators because they may require configuration changes, plugin updates, or infrastructure modifications. A server-side feature that changes the networking protocol, for example, would require all servers and clients to update simultaneously, which is a coordination challenge for forks with an active player base.
Community and platform features
Features in this category affect how mods are distributed, discovered, and managed by the community. Platform features may include changes to the Steam Workshop integration, new mod discovery mechanisms, or improved compatibility between different SDK forks. These features affect the mod ecosystem as a whole rather than individual mod projects, and they are typically developed in consultation with the community.
How to stay informed about Unturned updates
The developer who wants to stay current with Unturned modding feature development should monitor several information sources. No single source provides complete coverage; the developer should consult all of them periodically to maintain a comprehensive picture of the development landscape.
Primary information sources
| Source | What it provides | Update frequency |
|---|---|---|
| Official Trello roadmap | Feature pipeline status | Variable; updated when feature status changes |
| SDK GitHub repository | Source code changes, commit messages, release tags | Continuous; release tags at SDK update intervals |
| GitHub Discussions | Community questions, SDG responses, developer conversations | Continuous; daily activity |
| Official modding documentation | Definitive reference for shipped features | Updated with each SDK release |
| Unturned Steam news | Official announcements, patch notes for the Steam version | With each Steam update |
Monitoring strategy
The minimum effective monitoring strategy for an active mod developer is:
- Weekly: Check the Trello roadmap for card movements. A card that moves between lists is the earliest signal of an upcoming feature change.
- With each SDK release: Review the release notes, the updated documentation, and the commit log for changes that affect the developer's active mod projects.
- Daily or every few days: Scan the GitHub Discussions for conversations about features that are in active development. The Discussions often contain informal progress updates from SDG developers that do not appear in formal channels.
- Monthly: Review the Steam news for the vanilla game. Changes to the vanilla game may signal corresponding changes coming to the SDK, because SDG maintains the SDK in sync with the official releases.
The developer should calibrate monitoring frequency to their development activity. A developer who is actively building a mod should monitor more frequently than a developer who is in the planning phase. A developer who maintains a community fork with an active player base should monitor daily, because a breaking change in an SDK update could affect their players immediately.
Pro tip
Set up GitHub repository watch notifications for the U3 SDK repository, configured to notify on releases only (not on all activity). Release notifications are the highest-signal, lowest-noise monitoring mechanism because they fire only when a new SDK version is published. The release notes typically summarise the features that have moved from roadmap to delivered, and the developer can evaluate the impact on their projects from the release notes alone in most cases.
The relationship between roadmap items and the vanilla game
The Unturned modding feature roadmap and the vanilla game's development are related but distinct. Features that appear on the modding roadmap are specifically for the SDK and the modding toolchain. Features that SDG develops for the vanilla game may or may not appear on the modding roadmap; the presence of a feature in the vanilla game does not guarantee that the feature will be exposed through the modding API, and the presence of a feature on the modding roadmap does not guarantee that the feature will appear in the vanilla game.
This distinction is important for mod developers who build mods that extend or modify vanilla game features. A vanilla game feature that is not exposed through the modding API is a "hardcoded" feature - the mod developer can use it as a player but cannot modify it as a developer. When a vanilla game feature is added to the modding roadmap, SDG is signalling an intention to expose that feature through the modding API, making it configurable or replaceable by mods. The mod developer who wants to modify a vanilla feature should watch for that feature to appear on the modding roadmap; its absence from the roadmap suggests that the feature is not currently planned for modding exposure.
How to plan mod projects around an evolving feature set
Mod developers who plan projects that will span multiple SDK update cycles should adopt a development strategy that accommodates an evolving feature set. The strategy has three components: awareness, decoupling, and contingency.
Awareness
The developer should know which roadmap features are relevant to their project. Before starting development on a feature that duplicates or extends a roadmap item, the developer should consider whether waiting for the official implementation is more efficient than building a custom implementation. A custom implementation that takes weeks to build and test may be superseded by an official implementation that ships in the next SDK update and provides equivalent functionality with better engine integration.
The developer should maintain a document that maps their project's features to the corresponding roadmap items. When a roadmap item moves from "Under Consideration" to "Planned" or "In Progress," the developer should evaluate whether the project's corresponding feature can be deferred until the official implementation ships, or whether the project's timeline requires proceeding with the custom implementation.
Decoupling
The developer should design their mod's architecture so that features that correspond to roadmap items are decoupled from the rest of the mod. A decoupled feature can be replaced with the official implementation when it ships without requiring changes to the rest of the codebase. Decoupling is achieved through interface boundaries, dependency injection, and abstraction layers that isolate the custom implementation from the code that consumes it.
For example, a mod that implements a custom crafting system should define the crafting system's interface in terms of what the rest of the mod needs (inputs, outputs, recipes) rather than in terms of the custom implementation's internal data structures. When the official crafting revamp ships, the developer can replace the custom implementation with a new implementation that wraps the official API, and the rest of the mod continues to function unchanged because it depends on the interface, not on the implementation.
Contingency
The developer should have a plan for the scenario in which a critical roadmap feature does not ship or ships in a form that is incompatible with the project's design. The contingency plan should identify the minimum viable product that can ship without the feature, the alternative implementation paths that are available, and the go/no-go criteria for continuing the project if the feature is delayed beyond the project's acceptable timeline.
A contingency plan is not a prediction that the feature will not ship. It is a recognition that software development is uncertain, that external dependencies are risks, and that professional project planning accounts for those risks. The contingency plan ensures that the project can continue even if the roadmap feature does not materialise, and it prevents the project from stalling indefinitely while waiting for an external dependency that may never arrive.
The decision flowchart above formalises the strategy for each project feature that corresponds to a roadmap item. Following this flowchart ensures that the project's relationship with the roadmap is deliberate rather than reactive.
How to provide feedback on features under consideration
SDG accepts community feedback on the modding feature set through several channels. The developer who wants to influence the feature pipeline should understand which channels are appropriate for which types of feedback.
Appropriate feedback channels
| Channel | Best for | Not for |
|---|---|---|
| GitHub Discussions | Feature suggestions, use-case descriptions, community polling | Bug reports, urgent issues |
| GitHub Issues (U3 SDK repo) | Bug reports, feature requests with specific technical detail | General suggestions, "I want X" without detail |
| Trello board comments | Feedback on specific roadmap cards | New feature suggestions, bug reports |
| Email (SDG) | Security vulnerabilities, private inquiries | General feedback, feature requests |
How to write effective feature feedback
Effective feature feedback describes the problem the developer is trying to solve, the use case that the feature would enable, and the constraints that the developer operates under. Ineffective feature feedback describes the solution the developer wants without explaining why. SDG's development team is better positioned to design the solution; the developer's role is to articulate the problem clearly and let the development team determine the best implementation.
An effective feature feedback post in GitHub Discussions would read: "I am building a weapon mod that needs to apply a damage-over-time effect when a bullet hits. The current modding API supports damage-over-time through consumable items, but there is no way to attach a status effect to a projectile. This means I cannot build incendiary ammunition without resorting to server-side scripting, which limits the mod to servers that run my custom plugin. A mechanism for attaching status effects to projectiles would enable a whole class of specialty ammunition mods."
An ineffective feature feedback post would read: "Add status effects to bullets." The ineffective post forces SDG to guess at the developer's intent, the use case, and the scope of the request, and it is less likely to result in the feature being prioritised because the development team does not have enough context to evaluate its importance.
Pro tip
When providing feedback on a roadmap card, reference specific mods or use cases that depend on the feature. SDG prioritises features that enable a broad range of mods over features that serve a single narrow use case. Describing the ecosystem of mods that would benefit from the feature makes a stronger case than describing a single mod.
Disclaimer about feature timelines
The information in this article and on the official roadmap reflects the state of SDG's development planning at the time the information was published. Feature timelines, priorities, and the feature set itself are subject to change without notice. SDG reserves the right to modify, delay, or cancel any feature under consideration, and the developer should not make irreversible project decisions based on the assumption that a roadmap feature will ship on any particular timeline or in any particular form.
The 57 Studios cohort has observed that the most successful mod projects are those that are designed to function with the currently available feature set and that treat upcoming features as opportunities for enhancement rather than as prerequisites for the project's minimum viable product. A project that cannot ship without a roadmap feature is a project that is dependent on an external schedule that the developer cannot control. The developer should design their project so that the roadmap feature, when it arrives, makes the project better - not so that the project cannot function without it.
Important
The official SDG modding documentation states that miscellaneous requests and tasks take priority over the roadmap, and that the roadmap may go a while between progress updates. The developer should interpret "a while" conservatively. Features that have been on the roadmap for an extended period without movement may remain there for an extended additional period. The developer should not make project plans that assume a feature will move from the roadmap to a shipped SDK update within any specific calendar period.
Features known to be under active consideration
The following is a summary of the categories of features that the 57 Studios cohort has identified as recurring themes on the official roadmap. This summary is not a reproduction of the roadmap (which the developer should consult directly for the current state) but rather a categorisation of the types of improvements that SDG is evaluating.
Modding workflow
Improvements to the end-to-end workflow of creating, testing, and publishing mods. These may include Unity Editor tooling enhancements, build pipeline optimisations, and improved integration between the SDK and the Steam Workshop publishing flow. Workflow improvements are the category most likely to affect the daily experience of mod development, and they tend to be the most frequently shipped roadmap items because they provide broad benefit with relatively contained development scope.
Asset type expansion
New asset types and new fields on existing asset types. The community has requested expanded support for custom animations, new weapon behaviours, vehicle customisation options, and map editing features. Asset type expansion features are among the most impactful for mod developers because they directly expand the creative palette, but they are also among the most complex to implement because they require engine-level changes that must maintain backward compatibility with existing assets.
Performance and optimisation
Improvements to the SDK's runtime performance, particularly for large mods and servers with many simultaneous players. Performance features include rendering optimisations, networking improvements, and memory management enhancements. These features are especially relevant for total conversions and large-scale community forks, where the vanilla game's performance profile may be inadequate for the mod's scope.
Documentation and learning resources
Improvements to the official documentation, including expanded field references, more worked examples, and better onboarding materials for new mod developers. Documentation improvements are lower-cost than engine changes and provide immediate value to the community, which makes them a common category of shipped features.
Frequently asked questions
Where exactly is the official roadmap?
The official Unturned modding feature roadmap is published on a public Trello board. The board URL is provided in the Upcoming Features chapter of the official SDG modding documentation. The developer should consult the documentation for the current URL, as Trello board URLs can change when boards are reorganised.
Why are some important features not on the roadmap?
SDG's roadmap only includes features that have reached the evaluation stage and for which SDG is willing to signal public interest. Features that are too early in the planning process, features that SDG is not yet ready to discuss publicly, and features that do not have a solid implementation plan are not listed on the roadmap. The absence of a feature from the roadmap does not mean the feature will never be developed; it means the feature is not currently at a stage where SDG considers it appropriate for public listing.
How often does the roadmap get updated?
There is no fixed update cadence. SDG updates the roadmap when feature statuses change, which is typically driven by development milestones rather than by a calendar schedule. The roadmap may go weeks or months between updates, particularly when SDG's development team is focused on unplanned tasks (bug fixes, security patches, emergent issues) that take priority over roadmap items.
Can I suggest a feature for the roadmap?
Yes. The GitHub Discussions are the appropriate channel for feature suggestions. The developer should describe the problem the feature would solve, the use case the feature would enable, and the ecosystem of mods that would benefit from the feature. SDG reviews the Discussions and may add suggested features to the evaluation pipeline, but there is no guarantee that a suggested feature will appear on the roadmap.
What happens if a roadmap feature conflicts with my mod?
The developer has several options. The most common approach is to adapt the mod to work with the official implementation when it ships, which is why decoupling the custom implementation from the rest of the codebase is recommended. If the official implementation is fundamentally incompatible with the mod's design, the developer can fork the SDK at a version before the feature was introduced and maintain the mod on that fork, though this approach means the mod will not benefit from future SDK updates. The developer can also implement the mod's version of the feature in a way that coexists with the official implementation, giving players the choice of which system to use.
How do I know which SDK version a roadmap feature shipped in?
SDK release notes document the features included in each release. When a roadmap card moves to "Recently Completed," the corresponding SDK release notes will describe the feature in detail and note any breaking changes or migration steps. The developer should read the release notes for every SDK update that ships during their project's development, even if the update does not appear to contain features relevant to their mod, because seemingly unrelated changes can have unexpected effects on mod behaviour.
Can I participate in beta testing for upcoming features?
SDG does not currently operate a formal beta testing programme for SDK features. However, developers who monitor the SDK GitHub repository can build from the development branch (as opposed to the release branch) to test features that are in active development. The development branch may be unstable, may contain incomplete features, and is not recommended for production use, but it provides the earliest access to features that are approaching release.
What is the difference between the modding roadmap and the vanilla game roadmap?
The modding roadmap covers features specific to the SDK and the modding toolchain. The vanilla game roadmap (which SDG may or may not maintain publicly) covers features specific to the Steam version of Unturned. The two roadmaps overlap where a feature affects both the modding API and the player-facing game, but they are maintained separately because the audiences and development priorities differ. A mod developer who is interested only in modding features should focus on the modding roadmap; a developer who is interested in the full Unturned ecosystem should monitor both.
How does the U3 SDK release affect the modding roadmap?
The U3 SDK release was a major event that reshaped the modding landscape, and the roadmap reflects the post-SDK reality. Features that were planned before the SDK release may have been accelerated, delayed, or re-scoped in light of the SDK's availability. The developer should assume that the current roadmap reflects SDG's post-SDK priorities and that features that were discussed in the pre-SDK era may no longer be relevant in the SDK-based development model.
Should I wait for a roadmap feature before starting my mod?
Generally, no. The developer should start building with the currently available feature set and treat roadmap features as opportunities for future enhancement. Waiting for a roadmap feature introduces an indefinite delay - the feature may not ship for months, may ship in a form that does not meet the developer's needs, or may not ship at all. A mod that is built and playable today with the current feature set can be improved when the roadmap feature ships; a mod that has not been started because the developer is waiting for a feature provides no value to anyone.
Can roadmap features be removed without notice?
Yes. SDG can remove, re-scope, or indefinitely defer any roadmap feature at any time. The roadmap is a planning tool, not a contractual commitment. A developer whose project depends on a feature that is removed from the roadmap must fall back to their contingency plan. This is why the contingency plan is a recommended component of every mod project's planning documentation.
How can I tell if a roadmap feature is a high priority for SDG?
Card movement frequency is the strongest available signal. A card that moves from "Under Consideration" to "Planned" and then to "In Progress" within a few months is clearly receiving active attention. A card that has remained in "Under Consideration" for a year or more is being evaluated but is not being actively developed. The developer should also watch for SDG developer comments in GitHub Discussions that reference specific roadmap items - a developer comment that mentions working on a particular feature is a stronger signal than the card's list placement alone.
What should I do if the roadmap has not been updated in several months?
The developer should continue monitoring through the other information channels (GitHub repository commits, Discussions, Steam news). A quiet roadmap does not mean development has stopped; it may mean that SDG is focused on unplanned work (bug fixes, security patches, emergent issues) that takes priority over roadmap items. The developer should not interpret roadmap silence as a signal that specific features have been abandoned unless SDG explicitly communicates that a feature has been removed from consideration.
How do I evaluate whether my mod should adopt an official feature or keep a custom implementation?
The evaluation turns on three factors: the maturity and stability of the official implementation, the maintenance cost of the custom implementation, and the compatibility benefit of using the official implementation. A mature, stable official implementation that is well-documented and backward-compatible should generally be adopted, because it reduces the developer's maintenance burden and ensures compatibility with other mods that use the same official feature. A custom implementation that provides functionality the official feature does not may be worth retaining, especially if the developer expects to extend the feature further. The 57 Studios cohort recommendation is to adopt official implementations for commodity functionality (standard asset types, standard behaviours) and retain custom implementations for differentiating functionality (unique gameplay mechanics, custom visual effects).
Can I build a mod that depends on a feature that is still "Under Consideration"?
Technically, yes - the developer can implement the feature themselves in their mod. Strategically, it depends on the developer's timeline and the feature's likelihood of shipping. If the feature is likely to ship before the developer's project reaches its minimum viable product, the developer should decouple the implementation and plan to adopt the official version when it ships. If the feature is unlikely to ship on any timeline relevant to the project, the developer should proceed with the custom implementation and not plan around the official version. The ambiguity is the hard case: a feature that might ship during the project's development but might not. In that case, the decoupled architecture approach is the correct one - build the custom implementation in a way that makes it easy to swap for the official implementation later.
Best practices
- Monitor the official Trello roadmap weekly for card movements that signal upcoming feature changes.
- Read the SDK release notes for every update, even if the update does not appear relevant to the developer's mod.
- Participate in GitHub Discussions to provide well-structured feedback on features under consideration.
- Design mod features that correspond to roadmap items with decoupled architectures so they can be replaced when the official implementation ships.
- Maintain a contingency plan for every mod feature that depends on an unreleased roadmap item.
- Budget testing time after every SDK update to verify that existing mod functionality is not broken by upstream changes.
- Do not plan project milestones around unreleased roadmap features.
- When providing feature feedback, describe the problem and the use case, not the desired solution.
- Maintain a document mapping the project's features to the corresponding roadmap items so that the impact of roadmap changes can be assessed quickly.
- Treat the roadmap as a directional indicator, not a delivery schedule.
Appendix A: Information source quick-reference
| Information need | Source | URL |
|---|---|---|
| Feature pipeline status | Trello roadmap | Listed in official SDG modding documentation |
| Source code changes | U3 SDK GitHub repository | Refer to official documentation for repository URL |
| Community discussion | GitHub Discussions | Accessible from the SDK repository page |
| Shipped feature reference | Official modding documentation | https://docs.smartlydressedgames.com/en/stable/ |
| Game announcements | Unturned Steam news | https://store.steampowered.com/app/304930/Unturned/ |
| 57 Studios context | This knowledge base | https://docs.57studios.net |
Appendix B: Feature lifecycle tracking template
The following template is a recommended format for tracking the status of roadmap features that affect a mod project. The developer should maintain one row per relevant roadmap feature and update the status column weekly.
| Roadmap feature | Affected project component | Last observed status | Status date | Contingency plan |
|---|---|---|---|---|
| Example: Crafting revamp | Custom crafting module | Under Consideration | 2026-07-26 | Decouple crafting interface; fall back to custom implementation |
The template forces the developer to explicitly track which roadmap features affect the project, what the current status of each feature is, and what the developer will do if the feature does not ship or ships in an incompatible form. Projects that maintain this tracking document are substantially better positioned to adapt to roadmap changes than projects that treat the roadmap as background information.
Appendix C: Monitoring calendar template
The following is a recommended monitoring schedule for an actively-developed mod project. The developer should adapt the frequency to their development cadence and the criticality of the features they depend on.
| Frequency | Action | Time investment |
|---|---|---|
| Daily | Scan GitHub Discussions for conversations about active development | 5 minutes |
| Weekly | Check Trello roadmap for card movements | 5 minutes |
| Per SDK release | Read release notes; evaluate impact on project features; update tracking document | 30-60 minutes |
| Monthly | Review Steam news for vanilla game changes that may signal SDK changes | 10 minutes |
| Quarterly | Review the full roadmap for strategic alignment with project direction | 30 minutes |
The total time investment for the recommended monitoring schedule is approximately two hours per month, which is a small fraction of the time the developer spends on active development. The return on this investment is the early detection of changes that would otherwise surface as surprises - broken builds, incompatible features, and missed opportunities to adopt official implementations before investing in custom ones.
Appendix D: Stakeholder communication template
When a roadmap feature changes status in a way that affects the developer's mod project, the developer should communicate the impact to the project's stakeholders (players, server operators, fellow contributors). The following template provides a consistent format for these communications.
Subject: [Mod Name] development update - [feature name] roadmap change
The [feature name] feature on the Unturned modding roadmap has moved from
[old status] to [new status] as of [date].
What this means for [mod name]:
- [Impact statement 1]
- [Impact statement 2]
Our plan:
- [Action 1 the team is taking]
- [Action 2 the team is taking]
Timeline impact:
- [Effect on the mod's development timeline, if any]
Questions? Reply to this thread or reach out on Discord.Consistent stakeholder communication builds trust and reduces the volume of "is the mod still being developed?" inquiries that accumulate when the development team goes quiet.
Appendix E: Communication strategy for roadmap-dependent projects
Mod projects that depend on roadmap features should maintain an active communication presence in the GitHub Discussions. The communication strategy serves two purposes: it signals to SDG that there is active developer interest in the feature, and it enables the developer to receive informal progress updates from SDG developers who participate in the Discussions.
The effective communication pattern is:
- Post an initial discussion thread describing the mod project and the roadmap feature it depends on, including the specific use case and the expected benefit of the feature.
- Update the thread when the roadmap card changes status, noting the project impact.
- Share work-in-progress implementations of the feature (if the developer is building a custom version) so that SDG can see how the community is using the feature space.
- Respond to SDG developer comments promptly and with specific technical detail.
The ineffective communication pattern is posting "when will feature X ship?" in multiple threads. This pattern consumes community attention without providing SDG with useful information, and it does not advance the feature's priority. The effective pattern treats the communication as a collaboration with SDG rather than as a demand for a delivery date.
Appendix F: Historical feature delivery patterns
The 57 Studios cohort has observed several patterns in how SDG has historically delivered modding features. These patterns are observational, not predictive; past delivery behaviour does not guarantee future delivery behaviour. However, understanding the patterns helps the developer calibrate expectations about how new features are likely to be delivered.
| Pattern | Description | Frequency |
|---|---|---|
| Bundled delivery | Multiple roadmap items ship together in a single SDK update, often themed around a shared system (e.g., multiple asset type improvements in one update) | Common |
| Incremental delivery | A feature ships in a minimal form and is expanded in subsequent updates based on community feedback | Common |
| Surprise delivery | A feature that was not on the roadmap ships in an SDK update, typically because it was developed as part of an unplanned task that created the feature as a side effect | Occasional |
| Long-tail delivery | A feature remains on the roadmap for an extended period (a year or more) and then ships in a form that is substantially different from the original card description | Occasional |
| Silent removal | A feature is removed from the roadmap without announcement, typically because it was superseded by a different approach or deprioritised indefinitely | Rare |
The developer should not assume that any specific pattern will apply to any specific feature. The patterns are a historical reference, not a prediction tool.
Appendix G: Vocabulary reference for roadmap interpretation
The following vocabulary is used on the official roadmap and in SDG communications about upcoming features. Understanding the precise meaning of each term helps the developer interpret roadmap status accurately.
| Term | Meaning |
|---|---|
| Under Consideration | SDG is evaluating the feature for inclusion. No development has begun. The feature may or may not be developed. |
| Planned | SDG has committed to developing the feature when resources become available. Design work may have begun. No delivery timeline. |
| In Progress | Active development. The feature is being implemented and tested. A delivery timeline may exist internally but is not typically shared publicly. |
| Recently Completed | The feature has shipped in a recent SDK update. The developer can use it in the current SDK version. |
| On Hold | Development has been paused, typically due to higher-priority work or unresolved design questions. May resume later. |
| Superseded | The feature concept has been replaced by a different approach. The original card is retained for historical reference. |
| Backlog | A low-priority feature that SDG intends to develop eventually but is not actively planning. May remain in the backlog indefinitely. |
Appendix H: Community fork feature planning supplement
Community fork maintainers have an additional consideration beyond what individual mod developers face: the fork's feature set affects every mod and server that runs on the fork, and changes to the fork's feature set must be coordinated across the fork's entire ecosystem. The following supplement extends the project planning guidance in the main article for the specific needs of community fork maintainers.
Fork feature roadmap publication
A community fork that has a user base beyond the maintainer should publish its own feature roadmap. The fork roadmap serves the same purpose as the official SDG roadmap: it signals to the fork's community what features are under consideration and what direction the fork is heading. The fork roadmap should be maintained in the fork's repository (typically as a ROADMAP.md file) and should be updated when feature statuses change.
The fork roadmap should distinguish between features that the fork is developing independently and features that the fork plans to adopt from the upstream SDK when they ship. This distinction helps the fork's community understand which features depend on the fork maintainer's development resources and which depend on SDG's development schedule.
Upstream merge planning
When the upstream SDK ships a feature that the fork has independently implemented, the fork maintainer must decide whether to adopt the upstream implementation or retain the fork's implementation. The decision affects every mod and server that uses the fork.
The cohort-recommended decision framework is:
- Compare the upstream implementation to the fork's implementation on feature completeness, performance, and maintainability.
- If the upstream implementation is equal or superior, adopt it and deprecate the fork's implementation. Provide a migration guide for mods and servers that depend on the fork's implementation.
- If the fork's implementation is superior, retain it but ensure it is compatible with the upstream API so that mods that expect the upstream API can function with the fork's implementation.
- If the implementations are incompatible (the fork's approach and the upstream approach cannot coexist), publish a decision document explaining the fork's choice and the implications for the fork's ecosystem.
Ecosystem communication
Fork maintainers should communicate upstream SDK changes to their ecosystem before the changes ship in the fork. The communication should explain what is changing, why it is changing, what mod and server operators need to do to prepare, and when the change will take effect. The 57 Studios cohort recommends a minimum of two weeks' notice for breaking changes and a minimum of one month's notice for changes that require server operators to modify their infrastructure.
Cross-references
- Official FAQ - the previous article; documents the current state of the SDK, licensing, and community involvement.
- Getting Started with Unturned Modding - the practical setup guide for new mod developers.
- Legacy Tutorials - the next article; documents legacy Steam Guide content that predates the current documentation.
- What is Modding? - the discipline of modding and its relationship to ongoing development.
- Smartly Dressed Games modding documentation - the official documentation including the Upcoming Features chapter that links to the Trello roadmap.
- Steam Workshop Submission - the publishing workflow for mods that incorporate newly-shipped roadmap features.
- How to Write a Workshop Description That Sounds Authoritative - guidance for communicating roadmap-dependent features to players in Workshop listings.
Appendix I: Frequently overlooked monitoring signals
Beyond the official roadmap and GitHub repository, several secondary signals can indicate upcoming feature activity. These signals are not reliable indicators individually, but when multiple signals appear simultaneously, they strengthen the case that a feature is approaching release.
| Signal | What it indicates | How to monitor |
|---|---|---|
| Increased SDG developer activity in relevant GitHub Discussions threads | A developer is researching the feature's requirements or gathering community input | Watch for SDG-staff responses in discussion threads about the feature |
| New branches appearing in the SDK repository with feature-related names | Active development on the feature has begun | Monitor the repository's branch list |
| Documentation stubs or placeholder pages appearing in the official docs | Documentation is being prepared ahead of the feature's release | Periodically check the documentation site for new or changed pages |
| The feature is mentioned in an unrelated SDK release's notes as "foundational work" | SDG is laying groundwork for the feature in incremental updates | Read every SDK release note, even for updates that appear unrelated |
| Multiple community developers report seeing the same feature in the development branch | The feature is in late-stage testing | Monitor GitHub Discussions for reports from developers who build from the development branch |
None of these signals is a guarantee, but a developer who observes three or more of them simultaneously for a specific feature can reasonably conclude that the feature is approaching release and should accelerate their preparation to adopt or integrate with the official implementation.
Appendix J: When to abandon a roadmap-dependent approach
The developer should establish criteria for abandoning a roadmap-dependent approach before the approach becomes a project bottleneck. The following criteria are the cohort-validated thresholds at which the developer should seriously consider switching to an alternative approach:
- The roadmap feature has been "Under Consideration" for more than twelve months without movement.
- The roadmap feature has moved to "Planned" and remained there for more than six months without movement to "In Progress."
- The developer's project has reached a milestone where the missing feature is blocking further progress, and the feature is not "In Progress."
- The SDK has shipped two or more major updates since the feature was added to the roadmap, and neither update included the feature.
- SDG has publicly stated that the feature is being re-scoped or that its design is being reconsidered.
When one of these criteria is met, the developer should activate the project's contingency plan: implement the feature independently, redesign the project to not require the feature, or postpone the project component that depends on the feature. Continuing to wait beyond these thresholds without a contingency plan is the cohort-documented pattern that leads to stalled projects and developer burnout.
The developer should review these criteria at every project milestone review. A feature that was acceptable to wait for at the project's start may become a critical blocker six months later, and the criteria ensure that the developer re-evaluates the waiting strategy periodically rather than continuing to wait by default.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Comprehensive documentation of the official roadmap, feature pipeline interpretation, project planning around an evolving feature set, monitoring strategies, stakeholder communication templates, and community fork supplement. Expanded with appendices covering monitoring signals, abandonment criteria, communication strategy, historical delivery patterns, road map vocabulary, and fork feature planning. |