GioCities

blogs by Gio

Stanley and the Death of Sourcemods

  • Posted by GiovanH in 🎮 gaming

My first published, “successful” piece of game content was The Raphael Parable, a little exploration game about wandering through an impossible office. I say “game content” here because The Raphael Parable isn’t a game per se, but a map. A mod for the Steam release of The Stanley Parable that bootstraps the assets and mechanics to create a totally different game.

A new version of The Stanley Parable is releasing soon: The Stanley Parable: Ultra Deluxe is slated to be a remake with improved graphics, new endings, and console support. When I first saw this, I thought it would be a fun opportunity to go back to The Raphael Parable and tighten up some of the work that didn’t age well (I slapped it together pretty quickly, in hindsight, and it shows in places) as a new mod for the new version of the game.

"I love my car, I just hate my engine" Unity logo mug “I love my car, I just hate my engine”

Unfortunately, I quickly realized this was a non-starter for one simple reason: Unity. Ultra Deluxe is made by crowscrowscrows in Unity, which unfortunately stops this iterative development in its tracks. Let me explain:

The Weird Genealogy of The Raphael Parable§

The Stanley Parable itself started as a mod. The original published version is a Half-Life 2 mod from 2011, of which the 2013 Steam release is an HD remix. The Source Engine, which Half-Life 2 is built on, makes it easy to author a set of new maps and release it as a “sourcemod”. Davey Wreden did exactly this to make The Stanley Parable; he took the basic 3D engine and a few generic office-themed assets and made a completely new experience.

The original Stanley Parable The HD remix

The original mod and the steam re-release

When writing the HD steam remake Davey again used Source, probably because he was familiar with the engine. (This time the engine from Portal 2, which was itself mostly based on Half-Life 2.) There’s significantly more content and it’s much more polished, but at the end of the day, just like the original mod was running on Half-Life 2, the Steam release of The Stanley Parable is essentially running on Portal 2.

The Raphael Parable, then, is a mod of a mod. Really, due to how the Source engine is built, it’s a mod of a mod of a mod of a mod, and so on, going all the way back to Quake. It’s a child of an ecosystem of iterative development, where games were built on top of each other for generations.

Engines§

The Source Engine is uniquely suited for extensibility. Valve designed the engine to be iterated on internally, and the full SDK is provided for free via Steam to anyone who owns a Source engine Valve game, so it’s extremely accessible and open. Levels are simply files that you can write and distribute very easily. (I’ll get back to this point.) If you want to make a spin-off game or even a brand new game using a few of the same engine resources, you have the tools to make a sourcemod or a new game entirely.

This model — which you saw a lot up through the 2010s in games like Half-Life, Quake, and Doom — is fundamentally different than how modern engines like Unity and Unreal work. While Unity projects can be well-organized projects in their source form, Unity builds games into opaque binaries like traditional monolithic software. Assets are compressed and packed into proprietary archive files that are stored in as few pieces as possible. Games’ code and script are compiled, and certainly not exposed by default. This makes modding a significantly more complicated undertaking. Unless the game developer explicitly built their game around it, there’s no way add textures or levels or even substitute assets unless you’re the original developer with the original source code. There’s no forking off.

If you want to modify an out-of-the-box Unity game, you can, but it’s much harder. Code is compiled, so you’ll need a disassembler and endless patience. And don’t forget to use a codepoint patcher like fan-maintained BepInEx, or else when the game updates it’ll break. Forget level design tools or a development environment, you aren’t getting any of those. Just skimming over my Steam library now, I can think of really interesting ways you could extend games like Antichamber, Downwell, Factorio, FEZ, Glitchspace, and The Turing Test, but there’s really no way to.

Mods aren’t “dead” — far from it — but game engines are making design choices that discourage it. This isn’t particularly unique to Unity either; the sad truth is no modern game engine is as easy to build on as Source was.

There have been many games made in old, open engines like Source. Counter-Strike, Garry’s mod, Antichamber, Sonic Robo Blast, MM8BDM, DOTA, and, of course, The Stanley Parable all forked off from existing games and became their own thing, but there’s less and less opportunity for that now. And I haven’t even begun to touch on accessibility or localization. Fan translations are tremendously valuable, and are made far easier when dialogue, voice audio, and text are exposed as editable files rather than precompiled hash.

Files§

I think one of the key features that really makes a game naturally extensible is the way it physically stores files on the disk.

For example, here’s how sourcemods work: you download the mod and save it to Steam\steamapps\sourcemods\. That’s it. Restart Steam and if you have the base game, the mod will show up in your list of installed games automatically. Run it and it’ll fire up the game, patching in the mod files when appropriate.

Maps for Source games are stored in the maps folder. You can put any BSP file you like in common\Half-Life 2\hl2\maps, fire up the game, run map [file].bsp, and you’ll load into that level. Since each logical resource is stored as a file, it’s easy to add levels or replace textures by simply replacing the files. Steam will even do this for you on-the-fly with sourcemods.

Compare this to Unity games, where all the files and resources are thrown together in huge .assets archive files that are only readable with specialized user hacks. There’s nothing close to logical segmentation, and arbitrary on-the-fly patching is a fever dream.

This article is about sourcemods, but I’m such an adamant believer in the logical file approach that I want to talk about one of the games I think did modding best: Blockland.

Blockland got it so right§

Blockland screenshot Look, it’s little baby Giovan

Blockland used to be one of my favourite games, back when it had an active community. It’s a pre-Minecraft Lego-style building game, a bit like Roblox but populated with adults that hated each other.1 I need to write another article about Blockland some day, it was a really interesting experience. (Don’t try to play it now, though, it’s been unplayably broken for years.)

The base game is pretty slim, but driven by a powerful “add-ons” system. Add-ons — which were written in TorqueScript2 and packaged in zip files — defined almost every aspect of the game. Every block shape, every custom texture, every tool, every weapon, every vehicle, every particle, every scripting trigger.

The few things the game ships with were themselves add-ons which could be selectively toggled or studied. If you wanted to build something for the game, you could just find how Blockland did it, make a copy, and start editing. Because the whole game was built around add-ons as first-class members there arose a thriving modding community. Users didn’t even have to extract these addons; the game read and assembled everything at runtime. This made it them simple to handle and easy to distribute.

I still love Blockland’s add-on system. When I think of how to design a truly extensible game, it always comes back to mind. There are plenty of other games that use logical files excellently, of course — Hack n’ Slash, Haydee, Rimworld, Stellaris, Audiosurf 2, and Starbound, to name a few — but the way Blockland treats the base game as modular add-ons has always made it stand out to me.

Unity Bad?§

So, are Unity games like Ultra Deluxe preventing new creators from building on past work like they were able to, effectively pulling the ladder up behind them? Well, yes, but don’t get angry at crowscrowscrows just yet.

To be clear: you definitely shouldn’t still be making games in Source in 2020. It’s particularly good at the incremental design I’ve described in this article but it’s really bad at a whole list of other, more important things. If you’re making a game, you really need to be using something modern like Unity or Godot (or Game Maker for something simple) if you want to use an engine at all. I also can’t give Source too much credit; it’s very easy to author new levels and visual assets, but the mechanics of the 3D engine are much less flexible. Being developed with Unity lets Ultra Deluxe have much better game flexibility, as well as lighting, shaders, and console support. The fact that modern engines have shifted to a model that’s less easy to extend than Source was for maps is just a modern reality, I certainly won’t fault Ultra Deluxe for that.

If someone tells you to use the Source engine, don't listen

With the current tools, developers need to make the active choice to support modding or extending their game, which is a shame. Any mod support needs to be planned from the start, and extra resources budgeted accordingly. “Making your game moddable” is an extra step you have to take, and significantly increases the complexity of your project. Many developers do this, of course, and the Steam Workshop has become a great way of supporting extensibility in games. But for games like The Stanley Parable where there isn’t an obvious use for moddability, there isn’t the built-in support for extensibility that there used to be.

From a developer perspective, picking on Unity again, making an extensible game isn’t easy. Unity has a robust project management system with organized assets and design tools, but since it’s precompiled there’s no way of exposing those interfaces to users. If you google “Making a moddable unity game” you’ll probably get this thread from 2015 that covers some of the technical challenges. Since user content doesn’t have access to the pre-compilation C# environment at runtime, Unity’s default code pipeline makes first-class addons impossible. One common workaround has been to use lua scripting for mods, but that’s a major level of additional complication. Suffice it to say there is not a robust structure for automatically extensible games in Unity.

Interestingly, a lot of modern games that do have robust mod support aren’t made in common game engines. Gunpoint, Haydee, Starbound, and Stardew Valley, for example, aren’t made in Unity, Unreal, or Godot. Stardew Valley was actually written from the ground-up in C# using XNA, which the developer has admitted you probably shouldn’t do. It’s counter-intuitive, but the modern quick-to-start, easy-to-prototype, high-compatibility game engines are inadvertently worse at modding than just doing everything from scratch. That just shouldn’t be.

In my opinion, it would be tremendously beneficial for game engines to have built-in tools for extensibility. From what I’ve seen, those systems don’t exist in a robust form in modern engines, and that’s a real deficiency. In my ideal world, structuring a game as to be easily extensible would be simple, easy, and the engine default. There’s no pressing need for developers to manually make games like The Stanley Parable extensible, but if they weren’t experimental projects like The Raphael Parable never could have existed.

A fairly recent change to Unity has been the “addressables” module, which makes referencing custom assets slightly easier. Hopefully this represents an interest in making the engine more conducive to modding, but only time will tell.

Meanwhile, good news for The Raphael Parable fans: a fellow called max_34 is working on a Stanley Parable mod called The Stanley Parable: Ultimate Edition. From what I’ve heard, in addition to new levels, environments, and endings, it’s going to include a remastered version of The Raphael Parable. That’s going to be released some time after Ultra Deluxe, I think. As much fun as it is to see people enjoying what I made, seeing someone build on it is really something special. 🦆

Things I’m aware I’m glossing over§

  • A discussion of specific feature lists and version comparisons between modern game engines and Source: This is far more granular than this conversation needs. Plus, with modern engines constantly updating, any specific feature list I gave here would be out-of-date within a few years. Suffice it to say modern engines are better than Source at most things.
  • A discussion of the specific technical reasons for file packing and compiled binaries: this is a technical topic that far exceeds the scope of this little opinion piece.
  • The legal side of code reuse and licensing: Again, this would require far more detail, but for those interested here is a brief summary:
    1. You generally cannot just take something someone else made and owns and sell it for a profit without their involvement and consent.
    2. The Source engine is specifically licensed to allow the creation of sourcemods and new games, and even sell them for profit. You are not allowed to redistribute the original assets, maps, stories, or other creative aspects of Source games. This is all very sensible, imo.
      • Sourcemods are very clever: if you use assets from other games in your mod, you can distribute it and Steam will fill in the needed resources for people who already own the required games. The Stanley Parable (2011) uses HL2 textures and it’s perfectly fine to distribute. Again, the benefits of logical files and resource management.
    3. Unity and Unreal have licensing systems where you either pay for the development software and/or the engine gets a cut of the profits of our game. This is also sensible but disincentives those engines from being open or easy to use without authorization and authentication.
  • The incentives and economics behind engine licensing: Because I don’t know! This is not something I am an expert in or have particular insight into, aside from the blurb above.
  • I am generalizing things to Unity a lot: Because it’s 1. very popular and 2. generally has the same sorts of problems in this regard as other engines, especially Unreal and Godot.

Related Reading§

The Forgotten City (2015 Skyrim Mod) which was developed into The Forgotten City (2021)

Special thanks to dom of crowscrowscrows for sending me the mug texture from this trailer and for just talking to me in general

  1. I assume this isn’t what Roblox is like. I haven’t played the game. ↩

  2. Orignally this article incorrectly called the addon language C# (because both formats use the same file extension) but I was helpfully corrected. As I mention, C# isn’t a great fit with addon-type systems because it’s a compiled language, so Blockland addons using C# didn’t make sense anyway. ↩

Howdy! If you found my writing worthwhile, the best thing you can do to support me is to share an article you found interesting somewhere you think people will appreciate it. Thanks as always for reading!

Comments

Loading...