This is good for modding but don't be misled, this is the TF2-specific code which sits on top of the still-closed-source Source engine. For example you couldn't port TF2 to a new platform with this, at least not without reimplementing Source or wrangling it into working with one of the leaked Source codebases and dealing with the legal fallout of that.
Hard to understand their stance on keeping Source closed. It is not an exciting engine to work with in any way. There are at least 3 major open source alternatives today, way more powerful and easier to work with (O3DE, Godot, Wicked). Only people that have been involved with Source in the past decades would enjoy working with it.
The community around the engine is vibrant and well-versed in the caveats of the Source workflow. With a GPL release, just like Carmack did with id tech, the amount of creative projects from indies would sky rocket. No longer bound by obscure deals.
Most in-house game engines built after a certain point use a non-trivial amount of third party code, including console stuff which is under strict NDA, so it's a huge hassle to open source them. Most iterations of the Source engine use Havok physics for example.
IdTech probably was only open sourced because Carmack pushed for it, but it helps that IdTech of that vintage was all in-house code exclusively targeting the PC. I think the only thing they had to cut out for legal reasons was the patented shadowing algorithm in Doom 3.
> 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.
IMO the source engine codebase is probably chock-full of duct tape and cruft, full of undocumented, legacy, bespoke, hacky and deprecated stuff that it's not worth the dev resources for valve to bring it up to an OSS standard worthy of their reputation.
- assumptions about Valve's server architecture/implementation for most multiplayer stuff used by Valve games, the codebase(s) of which are probably as vast as Source itself and closed-source too
- bespoke engine modifications made for specific games like HL2 or CS1.6 which hasn't been touched for a decade, the authors of which may not be accessible to document them trivially
Adding sufficient documentation to a massive closed-source system meant for internal use, over multiple decades, to bring them up to par for functional OSS publication is a monumental feat that honestly probably isn't worth the risk of bad publicity from the modder community who'd just be mad about how unusable it would be.
Valve has given Facepunch the Source 2 license for S&Box[1] which will indirectly allow making games in Source 2. That's as far as they've gone towards releasing it as a game engine so far.
I pretty sure you'll soon get reply about how making it open source will increase cheating. So for those people it's important to know that Source engine source code was leaked many many times and anyone who will spend 5 minutes will find sources.
> There are at least 3 major open source alternatives today, way more powerful and easier to work with (O3DE, Godot, Wicked).
My general impression from lurking on these kinds of threads (with no relevant personal experience) was that Godot is a good 2D engine but not a good 3D engine. Do you find it comparable to the other two?
Ever since I joined the industry, I've heard that many companies are reluctant to open source code because it's so bad that if they did, no one would dare use their products. I guess Source is one of them.
When Winamp published their source code on Github, not only did they breach third party licenses, but they also had to deal with trolls who across the entire Internet that wanted to make a show out of them. It's hard to blame developers for avoiding open sourcing when you may not get anything out of that except for criticism.
> Hard to understand their stance on keeping Source closed
Forget Source, what about GoldSrc.
... which was based on Quake which is now GPL.
There's Xash3d which lives in a kind of licensing limbo because it was developed mostly from scratch except for some header files which could now be replaced by GPL QuakeWorld ones yet the current Xash maintainers can't do anything about it because they're tainted by non-clean-roomness.
Even if the above issue was solved, this is about the engine; the HL1 game code (the "SDK") is open but licensed by Valve in a way (MIT-ish permissive with a non-commercial clause) that is incompatible with the GPL.
This makes both legally undistributable as binaries together.
It will be easier to understand when you see the hundreds of Jira tickets to wade through to get it released and the fact they have better shit to do that contributes directly to revenue instead of trying to open source an old game engine that only a handful of people will even care about.
Aside from the good middleware licensing arguments, if my memory serves me, Valve employees get to shift their work to what interests them at the time, and who knows what tidbits of could-be versions of HL3, Portal 3, or other interesting but unannounced (let alone unreleased) games could be in there.
Indeed, I wish the first iteration gets released as GPL or something like that eventually. I get not wanting to open-source Source 2, but the original is another thing entirely.
Given the leaks, the fact it's been over 10 years since last major game released using Source 1, and the fact most of the rendering code (probably the most valuable bits, aside from physics) in Source2 must have been rewritten given the new developments in game graphics; makes me wonder if there is any reason for them to keep it closed source.
Do you think they will release it at any point? Maybe there are licensing issues where they don't have the rights to all of it and couldn't easily opensource it. Or maybe there is in fact still too much secret sauce left there?
There's always "too much secret sauce". I remember a time when CryTek published papers about how they implemented things, now they don't.
There's always in-house ways to deal with graphics drivers and certain effects. Remember how Source 1 was the only engine which was able to render HDR with measly ATI 9600XT, without a performance penalty most of the time?
You carry this know how in evolved form for generations, and it gets buried under as the foundation of the new things you're building on top of it.
This is what I remember from a friend who implemented his own game engine and created a company for it, and half the woes were making the graphics drivers and processors behave as they said in their manuals.
IIRC (from memory) it was called Source because it was a derivative of the Quake 2 engine that id gave them a copy of after a meeting (on a cd simply labeled “source”) even before they had a contract in place.
If this apocryphal story is true, they might only have a license to it (making it a derivative work) and depending on the terms of their licensing agreement from id they might not be able to do that without having their legal people talk to ZeniMax’s (they bought out id software and are their parent company now) lawyers, which runs to thousands of dollars in pure costs even if everyone is totally cooperative and on board and wants to make it happen immediately.
I'm still a bit confused on why Source is close sourced when Valve moved on to Source 2 over a decade ago. I suppose it'd becsuse there's some basic overlap, but they still also feel comfortable releasing their gsmes' source?
> when Valve moved on to Source 2 over a decade ago.
I feel like that's irrelevant, because the same logic can be used to justify having Source2 open as well.
After all, what value is there in keeping the game code private at all? The only things I can think of are a) anticheat, b) NDA'd 3rd party code, and c) protecting important secret sauces made by the company itself
a) and b) are both solved by simply not releasing those portions of the code, while c) is a bit moot. Any competitor can already (legally) RE the binaries and recreate any juicy proprietary algorithms, unless they're patented. But in that case they would be protected even if the source was released so it's still the same situation.
I didn’t realize source wasn’t open source. Aren’t titanfall and apex legends made with a modified source engine? I guess respawn licenses it from valve?
Maybe that's where a project like Nuclide could step in? I'm always a bit confused between their projects' names, but I've read somewhere they had progress on the HL2 front.
"Emulator" is the wrong word, but the answer is yes. The word you actually meant was "re-implementation" - writing a completely new, clean-room program which reads Source data files (levels, assets, scripts) and allows the user to play a Source game is perfectly legal.
It is necessary to avoid distributing any copyrighted material, so the user must provide the game assets from a legitimate copy for using the program to be legal. In addition, the 'clean-room' must be maintained by ensuring that no contributors to the re-implementation have ever seen the source code for Source, or they become tainted with forbidden knowledge.
Indeed, it's quite common for beloved old games to be re-implemented on new codebases to allow easy play on modern OS's and at high resolution, etc.
Source engine is so outdated at this point anyways. Valve should use the profits from their cash cow, CSGO, and use it to invest in retooling with open source engines such as GoDot or Bevy.
I remember downloading a leaked version of the source code for source engine, and in general it was laughable at how awful it was. I dont know if it was ever discussed mainstream but only based on recollection of IRC chats.
I think it was about 6 months out of date, but even so it would explain why HL sequels would become vaporware despite years of teasing the community by Gabe Newell himself.
As someone who used mod TF2 on the server side, this is fantastic. I've spent countless hours analyzing the binaries in IDA and now you can just open github. This will definitely accelerate new features and bugfixes from the community.
It's about damn time, really. The TF2 source code has already leaked twice. And a group even made a cloned version of the game in an earlier version of the engine. The community support this game still has is massive.
edit: here's the announcement from the TF2C Discord:
==============
@everyone We'll have more to say later, but you might not be able to launch TF2 Classic for a little bit due to the massive SDK update and public release of Team Fortress 2's code.
We're already preparing for the porting efforts and a potential Steam release now that we've been legally enabled to pursue that, but in the meantime, you will have to shift Source SDK Base 2013 Multiplayer to the "previous2021" beta branch that still has the previous revision of the SDK files to continue playing. See the screenshot for an example.
Given they call out derivative works of the original games being ok, and those works can be released as new games on steam seems to clear the way for TF2 Classic.
Woah... woah WOAH I wasn't expecting to see this on HN. I've been expecting this for a long time, and if I was valve I would have done something like this a long time ago: release a "final" celebratory content update, port the game to vulkan, and open source the codebase (keeping the item servers and whatnot tied to valve's servers). I don't know if this is the beginning of the end or the end of the beginning of TF2. There have been leaks before but this is huge news.
Beginning of the end? It's been the end for years - they're passing it off to the community, as they should! The team for TF2 is probably very low double digits now and it's almost 18 years old, it's time to outsource the continuing developments.
In the 90’s, iD made Doom, made money off of it for a few years, and then released the source code. They then did the same with Quake. This is part of the reason companies like Valve exist today, as their early games used modified engines from Doom and Quake. Valve is now continuing that 25+ year tradition. People are still making new Doom maps and playing the game. If history is anything to go by, people could be playing TF2 in some form in the 2050’s and beyond.
The fact that they did this before bothering to recompile it for 64-bit Mac says a lot—Valve clearly doesn’t see Apple as a friendly place to do business. Makes sense, with Apple trying to lock game devs into the App Store.
Writing games for Mac seems like a great challenge. You have a relatively non-standard CPU architecture with a proprietary graphics API for a small set of devices, many of which embed screens with ridiculously high resolutions while coupled to a GPU that's "good enough" at best. Apple proudly announced the mid-tier Tomb Raider 2 graphics, which doesn't promise much for game devs that don't have support from Apple's promotional campaign. All of that, on a platform that's smaller than Linux based on player count.
Unless you know for sure that you're going to get a decent player base, I don't think optimising for Mac makes much business sense for games companies. Users that can afford a Mac can probably also afford a console anyway.
You can trick games into running by using the same wrappers and workarounds that you'd use to game on Linux (except you need to optimise the wrappers yourself because they're less mature) but gaming on Linux already has plenty of DRM/anti-cheat incompatibility issues, and using less mature tools will only make that worse. And, of course, Apple doesn't care much about backwards compatibility; they've killed 32 bit for no apparent reason other than "we don't want to maintain compatibility" and who knows how long they'll maintain the current set of replacement APIs. Linux suffers from similar issues, and that's why the go-to method of playing games on Linux is to run them in an emulated Windows environment.
I think games companies will recompile games for Snapdragon before they'll bother with Mac. By the time they got all their 32 bit x86 libraries to work on ARM without emulation, Apple has probably switched around a couple of APIs and requirements anyways, so why bother.
from various interviews I've seen of folks in the games industry apple has historically been actively hostile to working with game companies, it seems to have softened with the iphone appstore.
People make fun of "devs devs devs" from Balmer but he was heavily right, Microsoft spent a ton to court developers and they got a monopoly on PC gaming as a result.
> Microsoft spent a ton to court developers and they got a monopoly on PC gaming as a result.
I think "courting" is underselling what they actually did.
They invested heavily into building tooling and APIs specifically for games, which eventually powered their own gaming console. They were practically the only company doing this on PCs since the mid '90s, and they became a monopoly because nobody else was focused on this. Developers and consumers jumped aboard because there was nowhere else to go. This is the same reason Steam won. For many years, there were just no alternatives.
Microsoft gets a lot of flack for many things, but they deserve a ton of credit for inventing and supporting the PC gaming landscape as we know it today.
Don't think that's the case anymore, "Game Porting Toolkit 2" seemingly opened the floodgates on gaming on a mac.. It's up to the developers if they think it's worth the time/ effort; but with how great apple the hardware is, and how easy it is to port a game, I think we're going to see a huge influx of mac gaming.
> We're also doing a big update to all our multiplayer back-catalogue Source engine titles (TF2, DoD:S, HL2:DM, CS:S, and HLDM:S), adding 64-bit binary support, a scalable HUD/UI, prediction fixes, and a lot of other improvements!
So that seems to be coming, at least in the sense of x86-64 which Apple Silicon supports better via Rosetta 2.
About 30% of the games I own on Steam would run on my Mac. I think that's quite much for a platform that nobody likes to develop for. But to be fair, I have few mainstream games like CoD, LoL or whatever.
steamdeck runs on linux so that should eventually make games on linux mostly compatible and maybe even one day make it so that pc gamers don't have to have windows at all... chicken and egg thing though
There was a video explaining to why Valve games were never ported to the Macintosh.
I can't find it. But essentially it was Apple not wanting their machines to be used for gaming. And so axed all the work of the port and refused to publish the game.
The best I can find is from 2007 from Gabe:
> We have this pattern with Apple, where we meet with them, people there go "wow, gaming is incredibly important, we should do something with gaming". And then we'll say, "OK, here are three things you could do to make that better", and then they say OK, and then we never see them again. The cycle then repeats itself when a new group of people replace the old ones at Apple.
All of their games were ported to Mac in 2013 or so but that support has been wound back in the last year or so with Intel Macs dying, 32-bit Mac support dying and presumably no interest from Apple in helping keep the Mac ports alive.
You're over-analyzing it. TF2 is 17 years old, and basically has a skeleton crew keeping it running. They simply decided it's not worth the effort. I'm mad about it too, but hard to blame them.
Technically so doesn't Windows, nor game consoles in spite of urban myths (Switch being the exception).
Windows Vulkan and OpenGL drivers exist, because Microsot still hasn't removed the ICD plugin interface from the OS, which is used by GPU vendors themselves, not Microsoft, to provide drivers on Windows for VUlkan and OpenGL.
Likewise, Valve could have use MoltenVK if they actually wanted to.
You can cross-compile to a mac if that's what you are asking. Not as easily as to Windows/Linux though, but that's just because there is less interest.
They don't have a disdain for games... At least not anymore. They're actively pushing it on both mobile and mac, even introducing "Game Mode" and the like. You wouldn't do that if you have a disdain for games.
Readit News
The community around the engine is vibrant and well-versed in the caveats of the Source workflow. With a GPL release, just like Carmack did with id tech, the amount of creative projects from indies would sky rocket. No longer bound by obscure deals.
IdTech probably was only open sourced because Carmack pushed for it, but it helps that IdTech of that vintage was all in-house code exclusively targeting the PC. I think the only thing they had to cut out for legal reasons was the patented shadowing algorithm in Doom 3.
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.
Contributing to this is probably
- custom external hooks (eg: homemade test framework, patchnotes publishing, steamapp backdoor integrations, hardware-specific firmware interfaces, 3rd party closed source SDK hooks)
- assumptions about Valve's server architecture/implementation for most multiplayer stuff used by Valve games, the codebase(s) of which are probably as vast as Source itself and closed-source too
- bespoke engine modifications made for specific games like HL2 or CS1.6 which hasn't been touched for a decade, the authors of which may not be accessible to document them trivially
Adding sufficient documentation to a massive closed-source system meant for internal use, over multiple decades, to bring them up to par for functional OSS publication is a monumental feat that honestly probably isn't worth the risk of bad publicity from the modder community who'd just be mad about how unusable it would be.
[1]https://sbox.game or https://store.steampowered.com/app/590830/sbox/
My general impression from lurking on these kinds of threads (with no relevant personal experience) was that Godot is a good 2D engine but not a good 3D engine. Do you find it comparable to the other two?
Forget Source, what about GoldSrc.
... which was based on Quake which is now GPL.
There's Xash3d which lives in a kind of licensing limbo because it was developed mostly from scratch except for some header files which could now be replaced by GPL QuakeWorld ones yet the current Xash maintainers can't do anything about it because they're tainted by non-clean-roomness.
Even if the above issue was solved, this is about the engine; the HL1 game code (the "SDK") is open but licensed by Valve in a way (MIT-ish permissive with a non-commercial clause) that is incompatible with the GPL.
This makes both legally undistributable as binaries together.
Deleted Comment
https://github.com/ValveSoftware/source-sdk-2013/issues/624
I don't think it reflects well on this site either
https://github.com/ValveSoftware/source-sdk-2013/issues/624
if someone just does a `git push` and changes license it won't be much help to anyone until there is a proper documentation.
Do you think they will release it at any point? Maybe there are licensing issues where they don't have the rights to all of it and couldn't easily opensource it. Or maybe there is in fact still too much secret sauce left there?
There's always in-house ways to deal with graphics drivers and certain effects. Remember how Source 1 was the only engine which was able to render HDR with measly ATI 9600XT, without a performance penalty most of the time?
You carry this know how in evolved form for generations, and it gets buried under as the foundation of the new things you're building on top of it.
This is what I remember from a friend who implemented his own game engine and created a company for it, and half the woes were making the graphics drivers and processors behave as they said in their manuals.
If this apocryphal story is true, they might only have a license to it (making it a derivative work) and depending on the terms of their licensing agreement from id they might not be able to do that without having their legal people talk to ZeniMax’s (they bought out id software and are their parent company now) lawyers, which runs to thousands of dollars in pure costs even if everyone is totally cooperative and on board and wants to make it happen immediately.
There are maybe four still in development and due hopefully this year, plus Apex Legends is still going strong.
I feel like that's irrelevant, because the same logic can be used to justify having Source2 open as well.
After all, what value is there in keeping the game code private at all? The only things I can think of are a) anticheat, b) NDA'd 3rd party code, and c) protecting important secret sauces made by the company itself
a) and b) are both solved by simply not releasing those portions of the code, while c) is a bit moot. Any competitor can already (legally) RE the binaries and recreate any juicy proprietary algorithms, unless they're patented. But in that case they would be protected even if the source was released so it's still the same situation.
https://www.youtube.com/watch?v=09CvpQrnTEY
We can not fix problematic netcode (this is a running joke in the TF2 comminity)
We can fix game balance issues (that could also be fixed through configs)?
I think some of these fixes were through something a bit more complicated like sourcemod which hooks various methods.
Deleted Comment
I am asking this from a total legal standpoint.
It is necessary to avoid distributing any copyrighted material, so the user must provide the game assets from a legitimate copy for using the program to be legal. In addition, the 'clean-room' must be maintained by ensuring that no contributors to the re-implementation have ever seen the source code for Source, or they become tainted with forbidden knowledge.
Indeed, it's quite common for beloved old games to be re-implemented on new codebases to allow easy play on modern OS's and at high resolution, etc.
See https://github.com/Interkarma/daggerfall-unity, https://openrct2.io/, https://github.com/AlisterT/openjazz
Dead Comment
I remember downloading a leaked version of the source code for source engine, and in general it was laughable at how awful it was. I dont know if it was ever discussed mainstream but only based on recollection of IRC chats.
I think it was about 6 months out of date, but even so it would explain why HL sequels would become vaporware despite years of teasing the community by Gabe Newell himself.
Volumetrics, physical sound, pbr, great snapshot based networking.
Godot doesn't really come close.
It's about damn time, really. The TF2 source code has already leaked twice. And a group even made a cloned version of the game in an earlier version of the engine. The community support this game still has is massive.
edit: here's the announcement from the TF2C Discord:
==============
@everyone We'll have more to say later, but you might not be able to launch TF2 Classic for a little bit due to the massive SDK update and public release of Team Fortress 2's code.
We're already preparing for the porting efforts and a potential Steam release now that we've been legally enabled to pursue that, but in the meantime, you will have to shift Source SDK Base 2013 Multiplayer to the "previous2021" beta branch that still has the previous revision of the SDK files to continue playing. See the screenshot for an example.
Thank you, and we'll have more news soon!
and
https://en.wikipedia.org/wiki/Team_Fortress_2
https://github.com/ValveSoftware/source-sdk-2013/blob/0759e2...
frogs and graphics programming are good friends.
(Also includes links to recent updates for other Source engine titles)
Double digits? That's very very optimistic. It's closer to like two people.
I see what you did there
Unless you know for sure that you're going to get a decent player base, I don't think optimising for Mac makes much business sense for games companies. Users that can afford a Mac can probably also afford a console anyway.
You can trick games into running by using the same wrappers and workarounds that you'd use to game on Linux (except you need to optimise the wrappers yourself because they're less mature) but gaming on Linux already has plenty of DRM/anti-cheat incompatibility issues, and using less mature tools will only make that worse. And, of course, Apple doesn't care much about backwards compatibility; they've killed 32 bit for no apparent reason other than "we don't want to maintain compatibility" and who knows how long they'll maintain the current set of replacement APIs. Linux suffers from similar issues, and that's why the go-to method of playing games on Linux is to run them in an emulated Windows environment.
I think games companies will recompile games for Snapdragon before they'll bother with Mac. By the time they got all their 32 bit x86 libraries to work on ARM without emulation, Apple has probably switched around a couple of APIs and requirements anyways, so why bother.
See also: Win32 is the only stable ABI on Linux - https://news.ycombinator.com/item?id=32471624
People make fun of "devs devs devs" from Balmer but he was heavily right, Microsoft spent a ton to court developers and they got a monopoly on PC gaming as a result.
I think "courting" is underselling what they actually did.
They invested heavily into building tooling and APIs specifically for games, which eventually powered their own gaming console. They were practically the only company doing this on PCs since the mid '90s, and they became a monopoly because nobody else was focused on this. Developers and consumers jumped aboard because there was nowhere else to go. This is the same reason Steam won. For many years, there were just no alternatives.
Microsoft gets a lot of flack for many things, but they deserve a ton of credit for inventing and supporting the PC gaming landscape as we know it today.
> As [1]announced on the official TF2 website
[1] https://www.teamfortress.com/post.php?id=238809 states:
> We're also doing a big update to all our multiplayer back-catalogue Source engine titles (TF2, DoD:S, HL2:DM, CS:S, and HLDM:S), adding 64-bit binary support, a scalable HUD/UI, prediction fixes, and a lot of other improvements!
So that seems to be coming, at least in the sense of x86-64 which Apple Silicon supports better via Rosetta 2.
That is actually more than I thought, but its clear without compatible games there is very little reason to install Steam.
Also, Apple only recently started to be more gaming friendly, so it's really not surprising they would try to port a 20 year old game.
About 30% of the games I own on Steam would run on my Mac. I think that's quite much for a platform that nobody likes to develop for. But to be fair, I have few mainstream games like CoD, LoL or whatever.
I can't find it. But essentially it was Apple not wanting their machines to be used for gaming. And so axed all the work of the port and refused to publish the game.
The best I can find is from 2007 from Gabe:
> We have this pattern with Apple, where we meet with them, people there go "wow, gaming is incredibly important, we should do something with gaming". And then we'll say, "OK, here are three things you could do to make that better", and then they say OK, and then we never see them again. The cycle then repeats itself when a new group of people replace the old ones at Apple.
Windows Vulkan and OpenGL drivers exist, because Microsot still hasn't removed the ICD plugin interface from the OS, which is used by GPU vendors themselves, not Microsoft, to provide drivers on Windows for VUlkan and OpenGL.
Likewise, Valve could have use MoltenVK if they actually wanted to.
Deleted Comment
Deleted Comment