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.
They couldn't release the windows port of Doom either, as that had been done by Microsoft, and would therefore include Microsoft copyrighted code.
With Quake, Id did their own windows port, so it was possible to release the source code for winquake.
> The bad news: this code only compiles and runs on linux. We couldn't release the dos code because of a copyrighted sound library we used (wow, was that a mistake -- I write my own sound code now), and I honestly don't even know what happened to the port that microsoft did to windows.
> Still, the code is quite portable, and it should be straightforward to bring it up on just about any platform.
It seems like they just didn't have immediate access to the code for the Windows version. The DOS source code eventually leaked a couple years ago along with the code to the Mac port of Doom. https://archive.org/details/doom-mac-source
How does that follow? Normally copyright would transfer to the company paying for it.
But Microsoft essentially licensed the Doom source code and ported it themselves, it's not work-for-hire, so the copyright on any changes would default to Microsoft. Though, I'm really not sure if Microsoft paid anything for this licence, or if there even was a contract.
Nope, not true. Work by non employees is only work-for-hire if it falls into one of the qualifying categories and the contract explicitly says that it is work-for-hire.
Oddly enough, the project of "porting Doom to Windows" was started by Gabe Newell, who worked at Microsoft at the time,
- https://www.doomworld.com/idgames/historic/wdoom
- https://www.doomworld.com/idgames/historic/wdoom2
- https://virtuallyfun.com/2011/03/29/windoom-wing-win32s-on-w...
The implementations get compiled in based on whatever platform you’re compiling for using a bunch of #ifdef statements
In that case it’s just a matter of not including certain .h/.cpp files
reminds of the whole "opensourcing solaris" drama that Bryan Cantrill talked about in his speech at usenix some ten years ago.
i wonder if the culprit is i18n again, "lol"
Probably other stuff there but not sure off the top of my head.
And yeah too much effort to re-encode all the game audio most likely.
This just seems like a lazy excuse. Ok so some of the code can’t be released. Fine, what stops you from open sourcing the rest of it that isn’t licensed? The OS community will surely fill in The blanks.
I do think that the source code of source was leaked. Its just that valve has to themselves give the code of source. FLOSS community would really do it. Trust me.
Modders in general won't care though.
So they could probably do it, but it would be costly, while just releasing the TF2 code is basically free.
You’d think so, but some developers have a very adversarial relationship with abstractions, such as abstracting away platform-specific code behind a common interface. It happens more often than you’d think.
> And even if the developers were that crazy those calls need to be excluded when building for other platforms so can also be stripped form the source code in an automated fashion.
So they’re going to leave people code that either doesn’t compile or, if it does, doesn’t work? And what’s stripped out may have very important technical considerations that might only be known based on which function calls were yanked out.
I think that in general, potential open source developers would not care at all about that. Some code (that doesn't yet work) is better than no code. As someone else mentioned, a motivated open source group could probably easily fill in all the missing gaps within a month.
It's all legal risk with little commercial upside
https://github.com/id-Software/DOOM-3/blob/master/neo/render...
I remember that being somewhere in the neighborhood of 1 LOC to fix, and exactly where to change it was “common knowledge” the moment the source came out
On one hand, at one point we had CEO and CTO publicly stating in townhalls that they want us to be a technological forefront and looking for ways to showcase our capabilities. At the same time it was virtually impossible to open source even something as trivial as a string formatting library, because once you started talking to stakeholders about approval their POV was that it's part of a project that took X amount of employees Y amount of time and that equation is in millions, so that has to be really valuable.
hell, when I joined the frontend circus in 2013 I was flabbergasted that most people needed to install 3rd party library to perform "isEven(num)" operation
... not to mention that aforementioned library had at least 3 dependencies itself.
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.
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
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...
They seem fairly functional but not fully drop-in replacements.
For example, one of the bugs might be inadvertently relied on in one of the map puzzles, unbeknownst to the map creator.
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...
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.
>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.
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.
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.
Source 2 dropped Havok in favor of their in-house Rubikon physics engine.
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.
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.
If you ever meet any you should ask them.
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.
For Source 2 it ends up being a constant source of leaks where strings for engine features of in-development games get shipped out in Dota 2 and CS2 updates. We learned tons of stuff about Deadlock that way.
FFS some of the best indie games out there made was made on RPG Maker and let's say it's far less advance than Godot. After all games are all about enjoyable core loop and player expirience. And no game engine magically give you any of it.
Company I co-founded released 2 games on PC and about to release 3rd one on PC and all the consoles. One of them was made with Godot, two with Unity. The only reason we had to switch to Unity are consoles. And the reason why Godot cant efficiently complete on consoles is the fact that platforms are backward and proprietary.
And of course I appreciate what you do. Thing is if you shoved it into a first person shooter, would it be even more successful? The answer to that question is often yes. Same as Roblox being basically Tavern Brawl but for third person platformers. Coming from a POV of game design for phones, Roblox games suck, but look: they are extremely popular and the clunky format of that engine makes them work. My point is that it’s impossible to generalize, but basically there is nothing you could make better with Godot today than with Unity or Unreal, as lamentable as that is, and even the things they make you want to make, it’s better to make those things instead.
If you look past TOP100 most popular games by player count you will find there are hundreds of less popular niche titles and wast majority of them likely not even 3D at all and there is reason for this.
Anyone who tried to start game development company and get their project funded knows that majority of publishers in the world operate well under $500,000 per project. This could sound unreal for US-based person who knows of FAANG salaries, but this is how game development industry is: lots of enthusiast trying to make some games working for penies.
So nope, wast majority of game developers dont need Unreal or even Unity feature set simply because they dont have budget for building modern 3D game.
The kind of discourse that litigates why that fact is true doesn’t serve curiosity or add knowledge.
Do you see Source being used in virtual soundstages? No. Does Source support Metal or Vulkan? No.
Does it have anything approaching the 3D or 2D or rendering style capabilities of any modern engine? No.
Is Source going to be remotely relevant for metaverse stuff? No.
All the money in the world won't change the fact that Source is an outdated pile of garbage.
Respawn uses it to this day for Apex, and it's horrific. Its graphics quality is atrocious especially for the demands it places on hardware. It has the worst latency of any similar multiplayer game (some events can take half a second to make it from a player's action to another player's system!) It lacks modern features that have been in other games for many years, like variable event rates (some games, for example, will use much higher event update rates for stuff happening within the player's field of view.)
Its game engine has so many bugs around inputs, movement, and collisions that high level play revolves around abusing all of them for competitive advantage in what is lauded as "movement", and because Respawn never treated these issues as exploits, they got painted into a corner where they can't ever switch to a modern game engine because trying to get the quirks of movement behavior would be impossible.
The game's input processing is done in relation to framerate, for fucks sakes....so input processing behavior changes depending on framerate.
The security and anti-cheat in the game is so hamstrung by Source that multiple world tournaments have been hacked live and ultimately had to be done in secret, later broadcast - because Respawn was so powerless to stop the hacker(s).
With more Unity shifting to a royalty model you're going to see a lot more interest in open source game engines like Godot; Godot is, for example, working on being usable for massive multiplayer and open-world games.
Vulkan support is now there (it was added in the last couple of years). Might not be for all engine branches though.
Given that the engine has been in, essentially, maintenance mode for almost a decade now, that is not really surprising. A more apt comparison would be Source 2 I assume.
> some events can take half a second to make it from a player's action to another player's system
What are events here? At least in normal source this should be impossible for anything movement/input related as the server processes the input each tick and then distributes that to each client (the Apex implementation should still do this). If it takes half a second to forward such an action, the whole server should hang for this time in the eyes of each client.
> The game's input processing is done in relation to framerate
This is a behavior added by Respawn, not something normal Source does.
> The security and anti-cheat in the game is so hamstrung by Source
That is a really broad claim imo. AFAIK CSGO only had this issue once in its lifetime and that was caused not by an issue in the engine but in the matchmaking service. So isn’t it more likely that Respawn just screwed something up?
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?
Sadly, you need to put in a lot of work to get good results out of it (neither of its predecessors had a reputation for being easy to work with) and for whatever reason many studios aren't exactly rushing to invest a bunch of time into it (many just go for Unreal Engine 5, or stick with Unity etc., indies often opt for Godot), so you don't get much past simple example projects. Part of this is probably that it never generated a lot of hype or much of a community around it.
Godot has a big community around it and is maturing pretty quickly, the early versions were pretty rough when it came to 3D (2.X and 3.X), but it's better now. Not as stable as Unity or Unreal but those have had the advantage of lots of years of work put into them, by more people than Godot has up until now.
There's also more niche options like Stride (https://www.stride3d.net/) and Flax (https://flaxengine.com/) but they suffer from the same issues as O3DE, even if otherwise are promising.
My guess is the primary use for this is going to be corps cloning it for their own internal use, whatever that might be. I see lots of huawei-aligned commits.
if someone just does a `git push` and changes license it won't be much help to anyone until there is a proper documentation.
[1]https://sbox.game or https://store.steampowered.com/app/590830/sbox/
https://vghe.net/source-2-engine.html#source-2-engine-games shows Valve almost exclusively.
PS: I am the guy who wrote the long paragraph about crowdfunding.
After reading the hackernews , it became evident that yes it would be nice for foss source code but its never gonna happen because its gonna take effort and money for valve for what? they might not do it , because I guess they are there for making money ?
I believe that crowdfunding is the way to go , Instead of forcing companies to give what we want for free , we need to provide an incentive for them.
This crowdfunding could also be a great PR for valve itself as well. Crowdfunding is the win-win situation I could think of , but oh I am more than happy to eat my own word , if I can get source's source code and really run team fortress 2 fully open source.
Maybe remove that part if you really want valve to listen to this professionally please ?
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.
I steer clear of Xash3D because of it's legal grey area too.
https://github.com/ValveSoftware/source-sdk-2013/issues/624
I don't think it reflects well on this site either
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.