RimWorld has spent its entire commercial life running on Unity. On 12 October 2026, Ludeon Studios announced that update 1.7 replaces that engine with Waylith, an in-house engine the studio built for the game. The blog post — credited to Tia Young — frames the swap as one that changes nothing visible: “The game looks and plays exactly the same, but in our tests performance is improved by 2-4x4X. eXplore, eXpand, eXploit, eXterminate — a grand-strategy subgenre about building a civilization over a long arc..”
That claim is the headline. The part that decides whether most players can move is compatibility. RimWorld’s community runs on mod lists that routinely number in the hundreds, and an engine change is the classic way to break every one of them. Ludeon’s answer is that this one mostly does not: saves carry forward and back, and the studio says the vast majority of mods work unmodified.
What changed: Update 1.7 moves RimWorld off Unity and onto Waylith, Ludeon Studios’ in-house engine, with 2-4x performance in the studio’s own tests. Why it matters: An engine swap normally breaks mods and saves. Ludeon says 1.6 saves load on 1.7, 1.7 saves load on 1.6, and most mods need no changes from their authors. Who should care: Anyone running a large mod list, mod authors deciding whether to recompile, and players on hardware more than about ten years old.
What Waylith actually is
Waylith is a full engine replacement, not a branch of Unity or a framework bolted onto it. Ludeon describes it as “our own in-house engine built by Ludeon Studios,” and the studio credits RocketWerkz, “whose Brutal framework helped make Waylith possible.” More than two dozen modders tested the build ahead of the announcement, Ludeon says, and their feedback shaped the release.
The mechanism that keeps old mods alive is a compatibility layer. The RimWorld Wiki’s technical guide states that 1.7 “is using a custom made shim to translate former Unity calls to new Waylith calls.” That shim is the reason an assembly compiled against Unity does not simply fail to load. The wiki adds that mods should see “significant performance increases” if authors shift code onto native Waylith methods instead of the Unity stub calls.
1.7 is not yet the default. It is live “right now on the unstable Steam branch,” and Ludeon notes that “the main branch that most people play on is unaffected and still on version 1.6 for now.”
The performance claims, in Ludeon’s numbers
Ludeon’s blog post is unusually specific about what it measured, and equally clear about the limits of those measurements. The studio’s own figures are below; the parenthetical hedge in the original post — “These are just our results; individual performance improvements may vary due to your specific PC or mods” — applies to all of them.
| Measure | 1.6 (Unity) | 1.7 (Waylith) | Whose test |
|---|---|---|---|
| Late-game colony, overall | baseline | 2.2x better | Ludeon stress test |
| Modpack load time, 1,500 mods | 14 minutes | 6 minutes | Ludeon |
| General performance | baseline | 2-4x | Ludeon |
Beyond the headline numbers, Ludeon lists specific areas that improved: “faster startup time, game load time with big mod lists, map generation, world generation, general ticks-per-second, and just about everything else.” The post’s illustration is a colony of “40 colonists, 200 ducks, and 100+ mods.”
There is one hardware caveat. Ludeon warns that “if your PC is more than 10 years old, 1.7 may not run on it,” and asks affected players to report the problem on the official RimWorld development Discord so the studio can consider changes. This is a real break in platform reach, not a bug: some older machines that ran 1.6 will not run 1.7.
Which mods keep working
Ludeon’s compatibility position is deliberately blunt: “You don’t need to do anything when switching to 1.7.” On mods specifically, the studio says “the vast majority of mods work on 1.7 without any changes from the authors.” Mods that display a yellow “potentially unsupported” marker are flagged only “because the version number changed,” not because anything is known to be broken.
The RimWorld Wiki’s modding guide goes further and puts a figure on it: “99% OF MODS BUILT FOR 1.6 SHOULD WORK OUT OF THE BOX, even without rebuilding the assembly.” Both sources agree on the exception that matters. The wiki names it: “any mod that uses Prepatcher will no longer function as Prepatcher itself must be updated for 1.7.” That is a dependency-level break, not a per-mod one — the fix sits with Prepatcher, not with every mod built on top of it.
Save compatibility runs in both directions, which is the detail that makes trying 1.7 low-stakes. Ludeon states that “your 1.6 savegames will load on 1.7, and 1.7 saves also work if you go back to 1.6.” A player can move a long-running colony forward, test the engine, and roll back to 1.6 without losing the run.
What mod authors have to change
For most players, none of this matters. For anyone maintaining a C# mod, the wiki lays out a migration path that is mostly tooling work. The headline requirement is a runtime jump: 1.7 targets .NET 10 (net10.0), replacing the .NET Framework 4.7.2 or 4.8.1 targets that 1.6 mods used.
| Migration step | What it involves |
|---|---|
| Runtime target | Switch to .NET 10 (net10.0); the wiki notes the “.0” matters |
| IDE | Visual Studio 2026 or Rider 2026; Visual Studio 2022 does not support .NET 10 |
| Project format | Convert older csproj files to the SDK-style format |
| References | Remove Unity DLL references; add Assembly-CSharp.dll, UnityStubs.dll and Waylith.dll |
| Harmony | 1.7 requires Harmony 3.0; Harmony 3 enforces type checks on injections and rejects mismatched patches |
| Shaders | 1.6 asset-bundle shaders keep working; new shaders must be written in GLSL |
| Asset bundles | Still supported but no longer necessary; 1.7 caches assets on first load |
The Harmony change is the one most likely to surface as a visible error. The wiki says Harmony 3 “now enforces type checks on injections such as __instance and __result, and will reject attempts to patch methods if the types do not match.” The Harmony mod’s own change notes record the timeline: version 3.0.0 on 12 October added “RimWorld 1.7 support with Harmony 3 for .NET 10,” and version 3.0.1 on 15 October moved to a release candidate that reduces “startup time and memory allocation while mods install their patches” and rejects “invalid patch IL … during installation, so errors in affected mods are reported immediately.”
Shaders carry a platform trap. Because Waylith uses Vulkan, the wiki warns that 1.7 “will load the Linux version of any shaders you provide,” and a Windows-only shader will not load at all. Ludeon’s own ask of mod authors is small: after testing, “publish a version marked as 1.7-compatible so the yellow warning goes away for players.” The studio also says Waylith lets modders “use the latest C# language features,” makes it “easier to write complex mods without negatively impacting the game’s performance,” and opens up “big visual changes and complex custom effects.”
What players are reporting so far
Early hands-on reports sit close to Ludeon’s claims, with one resource cost attached. PC Gamer’s Joshua Wolens wrote on 13 October that players on Reddit were “finding impressive results,” quoting one who reported “Stable 120 fpsframerate. How many images (frames) the game shows per second; higher = smoother motion. 60 fps is a common target. and 900 [ticks per second]. Normally I have at max speed 60/700ish.” The same report flags memory: “it eats RAM like there is no tomorrow. 12-13 GB RAM directly at startup is… something.” Wolens also relays a second player who loaded “1,477 mods” and saw load time fall from “at least 30 minutes” to “six minutes and 17 seconds.” These are player-reported figures relayed by a secondary outlet, not measurements Ludeon published, so treat them as the direction of travel rather than a specification.
GamingOnLinux’s Liam Squires-Hand reported the same announcement on 13 October, quoting Ludeon’s numbers directly and noting that “everything should work as before including saves and existing mods but really old PCs might have issue with it.” That is a Linux-focused outlet reaching the same compatibility read as the studio.
How to try 1.7 without risking your colony
Opting in is a Steam branch switch, and it leaves the normal game untouched. Ludeon’s steps: in your Steam library, right-click RimWorld, select “Properties,” open the Betas tab, and choose branch “unstable.” Restart Steam if the game does not update on its own, then choose “Play 1.7 Unstable” when Steam prompts you. Because the main branch stays on 1.6, a mod list you rely on there keeps working while you test the new engine on the side.
The save rules make the experiment reversible, but they do not make it free. A 1.6 colony loaded in 1.7 and saved there will load again in 1.6 — that is Ludeon’s stated behavior — but mod state can still move underneath a save when authors publish 1.7-tagged versions. If you run the kind of colony built around mobile bases, the RimWorld Odyssey gravship guide is the closer read on how those saves behave across versions. The practical move is to copy your save folder before a first launch, and to expect a startup hitch while RimWorld rebuilds caches on the new engine.
A second game is on Waylith
Ludeon closed the announcement with a tease rather than a product. “RimWorld isn’t the only game on Waylith,” the post reads. “We’re working on something new! It may be a little while before we can share more details, but we couldn’t resist telling you.” GamingOnLinux notes the studio gave no details and that it “may be some time before they give out any details on it.” Waylith, in other words, is infrastructure Ludeon intends to build on, not a one-off migration.
For now, the actionable part of 1.7 is narrow: an opt-in branch, a large performance claim the studio attributes to its own testing, and a compatibility story whose weak points are known and named. If your mod list avoids Prepatcher and your machine is newer than roughly a decade, the migration is designed to be a branch toggle rather than a rebuild.