For news, discussions and memes!
This community follows the Lemmy.zip Instance rules, with the inclusion of the following rule:
You can see Lemmy.zip's rules by going to our Code of Conduct.
What to Expect in Our Code of Conduct:
If you enjoy reading legal stuff, you can check it all out at legal.lemmy.zip.
Wait, like...all mods? Even the multiplayer mod? how the hell does that even work?
If I recall correctly, very little of rimworld actually uses unity functionality. It's just a "seperate" game viewed through unity
That would explain why it's one of the few unity games that does not try to burn a hole into my laptop! Was always wondering how they achieved that. Usually when I see that a game uses unity, I can already guess that it won't run well on my machine
interesting! for me that's always the sign of unreal engine - fans set to max, and get prepare for input lag lol
I hardly play games that use the unreal engine, but I'd expect that to be similar, especially as unreal engine is usually used for more graphics intensive 3D games.
The thing that annoys me about unity, is that it performs like ass even for games that should easily run on an iGPU, like RimWorld levels of graphic. I'm not saying their graphics are bad, it has its own style and I like it, but 2D games should definitely be able to run on an integrated graphics card, and there are a lot of games using unity that don't. Either the engine is shitty, or it's making it too easy to create unoptimized games
unreal engine is usually used for more graphics intensive 3D games.
yeah and it's optimized for shit. if you want a AAA gorgeous shooter, go unreal, otherwise, I dunno why anyone uses the fuckin thing. it's a lot more work to beat unreal into a 2d app or rts than unity requires.
but hey, fuck unity too lol, they fucked around with developers and found out, glad to see rimworld leaving; I'm becoming a big fan of godot, the engine just springs open damned near instantly.
I don't know what the other user is talking about it being a "separate game." It is heavily data-focused though. It's mostly C# code. As long as that doesn't make calls to Unity functions, it's fine, but also I'm certain they, and other mods, have. However, you can still handle this, similar to how WINE can run Windows applications without running Windows. You have a compatibility layer that routes all the calls that would have gone to Unity to your own systems that behave as close to identically as possible. If you make a call to "UnityEngine.Vector3", for example, you just create your own "UnityEngine.Vector3" that replicates the functionality.
Way to show how it is done. If only Notch could have updated MC just fucking once without breaking every mod everytime.
Designing stable interfaces is hard, they're just a smol bean $4.5T corporation.
IIRC, many, maybe most, Rimworld updates broke mods too. This one hasn't though. That's because this one seems to essentially just be a compatibility layer or something. What they must have done is routed all calls to Unity things to their own engine's alternative. At least that's my educated guess, because there's no other reasonable way this could work.
This is still amazing. I'm not diminishing that. It isn't changing the way the game functions though. It's just changing how it functions.
I really cannot comprehend how Minecraft collected such a mod base while also being this unbearable.
So many players just end up playing old versions because mod developers cannot reliably keep up with this nonsense. The last version to have decent mod support is probably 1.21.1, and there are so many mods dead after 1.7.10, 1.6.4, or even earlier.
Some of the mods, like Better than Wolves, have it literally in their name.
It's pretty simple: Notch was never a great coder and the game never had any mod support or APIs. He didn't support the idea of mødding the game at all.
Modders literally have to decompile and reverse engineer most of the game to add mods. Only last year did they remove obfuscation so the community didn't have to make up their own naming for everything.
Mødding, automatically read that with a heavy swedish accent. Thanks 😂
Swedish doesn't have that letter.
That's the Danes
Oops, written from mobile. Gonna leave it
I developed a mod until a year or so ago. Updates just come out too fast for it to be worth my time. If I want to fix one bug I have to apply it to 5 different game versions
Shocking the article left out the last surprising note on the update blog: Ludeon Studios says Rimworld isn't the only game running on the new, homemade Waylith engine. 😉
Probably because there's no details and it probably won't be out for years.
I was hoping for a new DLC announcement at least.
There are rumors it's based on the engine that Kitten Space Agency's (spiritual successor to Kerbal Space Program) devs develop. So it would be that other game.
Dean confirmed on the KSA discord that they licensed BRUTAL (the framework that KSA's engine is built upon) to Ludeon for Waylith.
Those are two games with extremely different needs...
From what I understand, BRUTAL (the thing that KSA devs made) is not a typical game engine. It's very low level and more of a set of tools and libraries to make a game and its engine with, without completely reinventing the wheel. It doesn't restrict game devs in any way and aims to give them maximum freedom (e.g. it doesn't even have a concept of a "scene" that all engines like Unity or Unreal have). Obviously this also makes it very complicated to use compared to Unity, but makes it possible to custom-tailor it to any game and use case.
This is especially important for a game like KSA that doesn't fit into Unity's model at all, but I guess it also provides some benefits for RimWorld.
Yeah, imo the term "game engine" itself has kinda evolved over the years from "framework that contains common game/renderer code" to "platform to handle the entire process of implementing a game".
It's just code in the end, so even the "full platform" option can be used as if it's just a framework, which it sounds like RimWorld was doing if it could switch engines without breaking mod support (another comment guessed LLMs were involved but IMO this goes way beyond what an LLM would handle well, as it would involve pretty much reimplementing unity's framework). Though I don't have any direct experience with Rimworld mods and how exactly they interact with the game; if they used a data-driven approach, then it could be possible to redo just that interface and keep mods working (though it would also depend on what exactly was running the mod code itself, as that part would also need to remain functional).
Why would they write a custom engine that also breaks mods? It shouldn't be surprising that they wrote it so mods keep working.
Many of their previous updates on the unity engine broke mods - for something as fundamentally massive as changing the entire game engine, it's an incredible achievement to have done so while preserving the functionality of the tens of thousands of 3rd party scripts.
I mean, it seems simple - just make the new engine compatible with the old mods....
but changing engines is hard work. building your own engine is exceptionally harder. lots of things to break.
3rd party mods are often not supported and may rely on quirky unity behavior. I don't know how much of unity they used but that sounds very impressive to me that they managed to keep mods working as supposed to all mods needing a minor update.
What a fantastic indie story RimWorld continues to be!
It seems like a good strategy to improve time-to-market by leveraging an existing engine, and then if you're successful enough then maybe you can afford to create your own.
I'm not going to say you're wrong, but it also adds a ton of complications. Presumably they wrote an entire compatibility layer to map from Unity calls to their own engine. That work doesn't need to be done at all if you start from scratch with your own engine and targets.
You are right that they probably couldn't afford to make their own engine originally though, and this presumably lets them not pay royalties on future sales. I wouldn't say it's a good strategy, but if you end up with a boatload of cash and a game with a long tail then it's a good tactic. It's just not something you should plan on doing.
Even if they didn't plan for it and build that compatibility layer, that boatload of cash gives them a lot of options.
It seems like a classic time-to-market and "don't step over good to get to perfect" example to me. Get a product out, start getting revenue, then make it perfect.
I think it would be quite rate for something like this to be feasible at all. Decisions like this are set in stone before development starts, and tend to dictate the development direction.