5 ms·

> Hard to understand their stance on keeping Source closed. It is not an exciting engine to work with in any way. Source uses Havok, which is a licensed middle

> Hard to understand their stance on keeping Source closed. It is not an exciting engine to work with in any way. Source uses Havok, which is a licensed middleware. Convincing Havok to be also open source is likely a nonstarter. Repeat for any other middlewares they might have used, such as Adobe's ScaleForm used by CSGO, and it quickly is just an endless legal nightmare. idTech handled this by either spending time to rip out those components, allowing for a partial open source release which is what you're ripping on Valve for doing right this moment, or by avoiding using any licensed middlewares at all which is a significant development limitation that not everyone can get away with. As Source 2 replaces everything with in-house developed alternatives, it's possible we might see that open sourced in the future. Who knows.

klaussilveira 2y ago
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 https://developer.valvesoftware.com/wiki/VPhysics
- meibo 2y ago
  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 https://github.com/misyltoad/VPhysics-Jolt
magicalhippo 2y ago
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...
- jamesfinlayson 2y ago
  There have been a few attempts to replace VPhysics (Valve's library built on top of Havok: https://vghe.net/source-engine.html#vphysics https://vghe.net/source-engine.html#vphysics They seem fairly functional but not fully drop-in replacements.
- account42 2y ago
  It's not like the Havok-using version of HL2 right now on Steam is free from physics bugs. Bugs can be fixed.
  - magicalhippo 2y ago
    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.
  - jamesfinlayson 2y ago
    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.
fngjdflmdflg 2y ago
>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/ https://valvesoftware.github.io/steam-audio/ [1] https://www.theverge.com/2024/10/1/24258723/epic-games-store-unreal-engine-launch-everywhere-royalty https://www.theverge.com/2024/10/1/24258723/epic-games-store...
- jsheard 2y ago
  > What about physics? Source 2 dropped Havok in favor of their in-house Rubikon physics engine. https://developer.valvesoftware.com/wiki/Rubikon https://developer.valvesoftware.com/wiki/Rubikon
- TransAtlToonz 2y ago
  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.
  - jamesfinlayson 2y ago
    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.
    - 2y ago
thescriptkiddie 2y ago
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.
- aprilnya 2y ago
  :)
- jamesfinlayson 2y ago
  Definitely some copy+paste - the ICE encryption code is copy+pasted and is there in the SDK.
- account42 2y ago
  > professional software developers If you ever meet any you should ask them.

klaussilveira 2y ago

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 https://developer.valvesoftware.com/wiki/VPhysics

meibo 2y ago
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 https://github.com/misyltoad/VPhysics-Jolt

magicalhippo 2y ago

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...

jamesfinlayson 2y ago
There have been a few attempts to replace VPhysics (Valve's library built on top of Havok: https://vghe.net/source-engine.html#vphysics https://vghe.net/source-engine.html#vphysics They seem fairly functional but not fully drop-in replacements.
account42 2y ago
It's not like the Havok-using version of HL2 right now on Steam is free from physics bugs. Bugs can be fixed.
- magicalhippo 2y ago
  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.
- jamesfinlayson 2y ago
  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.

fngjdflmdflg 2y ago

>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/ https://valvesoftware.github.io/steam-audio/ [1] https://www.theverge.com/2024/10/1/24258723/epic-games-store-unreal-engine-launch-everywhere-royalty https://www.theverge.com/2024/10/1/24258723/epic-games-store...

jsheard 2y ago
> What about physics? Source 2 dropped Havok in favor of their in-house Rubikon physics engine. https://developer.valvesoftware.com/wiki/Rubikon https://developer.valvesoftware.com/wiki/Rubikon
TransAtlToonz 2y ago
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.
- jamesfinlayson 2y ago
  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.
  - 2y ago

thescriptkiddie 2y ago

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.

aprilnya 2y ago
:)
jamesfinlayson 2y ago
Definitely some copy+paste - the ICE encryption code is copy+pasted and is there in the SDK.
account42 2y ago
> professional software developers If you ever meet any you should ask them.