You are right. But I wonder how much of Havok is there, given that Valve had its own thing: https://developer.valvesoftware.com/wiki/VPhysics

Most commercial engines that use libraries like havok will wrap them in some sort of internal library like this one to shield themselves from types from the middleware leaking into engine code, implementing convenience wrappers, and making it easier to update/swap them at some point if they ever wish to.

There is a third-party implementation of vphysics based on an open source physics engine, for example - so for Valve that seems to have been successful: https://github.com/misyltoad/VPhysics-Jolt

Havok also strikes me as a rather difficult piece to replace. A physics engine will often have hardcoded handling of special cases, and things can be sensitive to lots of numerical details.

Haven't played TF2 but at least HL2 relies heavily on physics for gameplay, so while replacing the rendering engine might lead to rendering artifacts which can be annoying but tolerable in many cases, replacing the physics engine will probably lead to game-breaking issues.

One could reverse engineer it, but then you're into copyright territory...

There have been a few attempts to replace VPhysics (Valve's library built on top of Havok: https://vghe.net/source-engine.html#vphysics

They seem fairly functional but not fully drop-in replacements.

It's not like the Havok-using version of HL2 right now on Steam is free from physics bugs. Bugs can be fixed.

Of course, just feels like a physics engine is a few steps harder than many other dependencies.

For example, one of the bugs might be inadvertently relied on in one of the map puzzles, unbeknownst to the map creator.

Yeah I've heard that it's Havok with a bunch of Valve changes and fixes on top. So presumably it's a fairly outdated version of Havok.

>Source 2 replaces everything with in-house developed alternatives

Do you have a link for this? I know the sound system is theirs as they open sourced it.[0] What about physics?

Also, I agree that they should open source Source 2 if possible. They gain almost nothing by having it closed source and gain a lot by giving developers a better deal than Unreal because more money saved on the engine means either cheaper or better/long games. (At least assuming both engines are equivalent which they are not, but in theory.) Meanwhile Epic is using Unreal as a carrot for developers to release their games in Epic Store.[1]

[0] https://valvesoftware.github.io/steam-audio/

[1] https://www.theverge.com/2024/10/1/24258723/epic-games-store...

> They gain almost nothing by having it closed source

That's not really true. As a strictly internal engine they gain the massive benefit that the only users are themselves. They don't have to make affordances or adjust for third party users. If they released it with no intention to play nice with the community then all they open themselves up to is criticism and bad press when they inevitably break third party users. To keep their nice internal workflows without more engineering effort would make the release a dump of the source tree and a "have fun" message pledging zero support.

Often in internal engines there are lots of workflows and tools that only work with access to the company's internal network. Things you can't make public. I work on (a different) internal AAA engine and our build system would not work without access to our internal network even if you had a dump of the entire source code. Do you rip that out or modify your internal workflows? Not so free to release it anymore.

You're right. I was more thinking of "they gain almost nothing by protecting their copyright over the engine" as in having a competitive advantage using their engine as a secret sauce. Because Valve is barely in the game dev industry to begin with and makes most of their money from steam sales. But yes they would have to either support the engine or make the decision to not support it.

>when they inevitably break third party users.

Wouldn't versioned releases solve this issue? You can ship a new release every 3 years (lets say) and developers would expect things to break between versions which is the case for all engines.

Honestly, a source dump with a “have fun” message is pretty useful. Adding a bit of documentation and some technical notes on how and why things work the way the work is gold.

I haven’t spent _that_ much time reading the doom3 codebase, but when I go “I wonder how that should work,” it’s a decent place to look.

Having a base of useful code to read that’s better than anything you’ve written is always a good thing.

> They don't have to make affordances or adjust for third party users. If they released it with no intention to play nice with the community then all they open themselves up to is criticism and bad press when they inevitably break third party users

I kinda get this but also don't get this. You can always open source something without giving any guarantees to third-party users about stability, feature requests, etc., no?

It would still be useful as just having the possibility to look into the code, and if someone want to build on top of it, then they know the context and have to accept the conditions.

But then what is the benefit to them? If the don't maintain the repo (benefit from bug fixes, features, security, etc) and it's free for people to build on, how does that make them money?

By having people make better mods/games that they then likely release on steam because it's very Source-friendly. Even for free games this drives more users to Steam and keeps existing users from leaving so it's a benefit for Valve.

Zero/minimal support is the norm for game source code releases.

> What about physics?

Source 2 dropped Havok in favor of their in-house Rubikon physics engine.

https://developer.valvesoftware.com/wiki/Rubikon

I'm no game developer, but I understand that Unreal comes with a massive ecosystem of tools and third-party addons. It seems like it would take a company about the size of Valve (or much larger) to compete with that kind of platform. You seem to know more about the industry than I do, so could you explain what Valve competing with Unreal would actually look like? That seems almost like a completely different market than they've been in so far despite certainly having the technical chops.

Yeah doesn't seem like their strategy - probably much more profitable to run Steam and take a cut from huge volumes of game sales than to try and license an engine to as many companies as possible.

But giving an engine to developers to make games for free (to them to release on steam) would bring more merch and volume to the store

I think that was the case with Source 1 - I can't remember the details but if you licensed the engine and released it exclusively on Steam I think there were favourable terms.

But maybe this wasn't execute well enough? Maybe Steam was too in its infancy to attract highly profitable licensees? Most of the non-Valve games made on Source 1 weren't big-budget AAA games so it was likely only a modest return on investment.

The economics of a game engine engine business are grossly inferior to an app store. Steam charges 30% of gross (25% at high volume), Unity charges by seats and not fees after (huge backlash when they tried to go the other way and indies bailed to GODOT.) Unreal Engine 3.5-5% and maybe some seat fees now.

If you were a developer you are looking the other way, getting those app store fees down.

The App Stores - Steam, iOS, Google Play, are making higher margins per game than most game devs, and that's based on hard numbers not a guess. There is no meaningful way for game developers - artists, programmers, and everyone else involved - to make more money other than getting rid of the app store fees.

There is a whole explanation about network effects here, and endless debate about what the fees should be. There is a cost to sell a game and it is not small. Several percent just go to credit card processing, refunds, and fraud. More has to go for the infrastructure to deliver games and updates. Then there has to be some margin. Then there maybe should be a premium that goes to the "app store" so that developers don't have to worry about distributing their app to thousands of locations. There is another premium that really is delivering demand for the game in the first place. Many sales would never happen on Steam if the users were not shown the game as featured or recommended. Most developers have no problem paying 30% for a sale that would otherwise never have happened.

However, if I went back in a time machine to 1999 when you drove to a retail store to pick a game box off of a shelf, and you told me some arbitrary application would get to take 30% of all game sales decades in the future, I would have said that's fucking crazy. More developers should be able to seamlessly sell their games direct to their players, and I'm not entirely sure why they don't. Selling a digital item online is definitely simpler than developing a successful game.

Edit: And if you look at Unity's financials they are in real trouble and probably will only survive if another larger, profitable, company acquires them. Not a great feeling for game developers who might suddenly be paying Facebook/Meta or someone worse their license fees.

The question is do they need all those tools and third-party addons to meaningfully compete with Unreal? Or is it enough to not have to pay the Unreal license fee? I don't know. Many (most?) AAA studios have their own game engine and they are not bothered by not having access to third party tools and addons. There are large AA studios that are still using CryEngine for new games, and I doubt there is a large ecosystem for that (although I don't actually know). At the same time, those studios have more money and employees to build those tools on their own. I imagine Valve also has a lot of internal tools that they could potentially release as well. Perhaps it's my own desire to see the industry converge on a high quality open source engine (which they can then heavily modify to their needs) that is blind-slighting me here.

surely the engine links to rather than contains proprietary third-party code. professional software developers wouldn't just copy-paste from another codebase into their project, right? that would be insane.

:)

Definitely some copy+paste - the ICE encryption code is copy+pasted and is there in the SDK.

> professional software developers

If you ever meet any you should ask them.