In general, open-source all abandonware. Here's a few examples of non-game old software that would benefit the society if open-sourced:
Windows 9x and classic Mac OS. No one has sold these OSes for 20+ years and they turned out to be evolutionary dead ends. It would make sense to release their sources so people could learn from them and run them on new hardware more easily.
Flash Player. Adobe has stated in no uncertain terms that Flash is dead. Is there any good reason why the sources need to stay closed if they aren't going to make any further gains, financial or otherwise, from this product and its ecosystem? I mean the Flash Player plugin and standalone app specifically, not the Flash authoring software — that's still alive under a new name, Adobe Animate.
Trident, the Internet Explorer engine. Again, it's dead for good as far as Microsoft is concerned, so why not release its sources for people to learn and hack on?
Presto, the Opera engine. This was leaked and of course I hoarded it, but it would be nice to see an official release.
Winamp. The company behind it pivoted to some kind of streaming social donation thing. It does not seem interested in maintaining the old Winamp app.
Path, the social media thing for "close friends", their mobile apps. The apps were insanely cool, especially at the time of Path's peak around 2013, but the service was shut down a few years ago. Unless they're going to somehow resurrect the service, there's no good reason for the sources for the apps to remain closed. I'd love to take a look at their implementation of real-time photo filters.
Thinking of it, it makes more sense for non-game apps than for games to release sources. Old games do sometimes come out as "remasters" for modern platforms. These usually reuse the engine and sometimes some of the assets. Non-game software, on the other hand, when it's dead, it's usually dead for good.
> Is there any good reason why the sources need to stay closed if they aren't going to make any further gains, financial or otherwise, from this product and its ecosystem?
I can think of lots of reasons. From a competitive point of view, you might risk having a big enough resurgence that it eats into the business of your replacement. From a technical point of view, it may reveal parts of the sausage making, or expose technology and libraries that you still use and rely on. From a legal point of view, it could open up multiple kinds of liability. From a support and staffing perspective, it typically takes at least a little time to open source something, if you want to do it well, there’s usually vetting & review by engineers and lawyers, and usually the need for more/better documentation than the internal docs.
Think about this from a business perspective- if they predict there’s going to be no financial upside, even indirectly, and there are costs and risks associated with it, then why would they? When companies open-source something, it’s not usually because the code is dead, it’s usually because the people in it are committed to open source and the org agrees to support that cause, or because the company stands to gain valuable attention from the community, and eventually or indirectly, profits.
We do have to support and celebrate when companies decide to release code, but we can’t really expect it or complain when they don’t, it just doesn’t make sense to them and they’re not obligated.
I'd guess something big as Windows 9x contains A LOT of licensed third party code which would be a nightmare to get permission for. Try finding five dozen rights holders after thirty years...
This is the usual argument you hear when it comes to old Games. It often would take way to long time to "clean" them up from 3rd party contributions/licenses etc. For a OS this is a impossible task.
Usually the argument goes that it would take time/money to rewrite the parts they don't have rights to, but simply deleting those parts and releasing the (now broken) code would be much better than nothing. Of course this assumes they kept track of who owns what code in the first place. Probably a bad assumption in the case of games particularly.
> Of course this assumes they kept track of who owns what code in the first place.
Not only that but for any large company to release code somebody in engineering needs to look at it to at least know what all is there, the legal department needs to assess the risk of potential liability, then which license to release it under needs to be decided. Finally, somebody in a senior business role needs to sign off on doing it.
I think it's great when old code gets released but the reason it's rare is it gets complex and it's nobody's job to do it. That's why many such releases are thanks to an employee deciding to care about doing it and having the internal cred and sway to push it through. Or, as it appears in this case, someone who had access to the code and is awesome enough to release it anonymously years later when the business is defunct or will no longer care.
As far as I understand, this is even true of lesser known old movies - even the work of figuring out who has the rights to what is unlikely to pay back, so it’s just never released in a digital format.
This is almost exclusively usually due to either producer credits or music licensing.
For the former, if it's really that big they'll just release it and keep a standard budget aside for if/when the unlocated people come out. The latter is what really blocks movies because it actively costs them money, so they need to be able to earn more than what it is costing them to release. This makes music-heavy/niche music films much more expensive for potential broadcasters/streamers.
As a minor musician, I have to say I find the entire legal model around music to be effing ridiculous and more harmful to the art and society than the benefit justifies
It all disproportionately benefits big names and corporations while small time creators and performers get screwed.
The moment recordings came into play it all got screwed up.
Before recordings every musician made their living exclusively from performances and every musician copied each other constantly.
We lost so much with the advent of recording and the associated development of copyrights etc.
The proof is in the numbers: management and corps take the lion's share of revenues within the industry, with the actual musicians and creatives getting a paltry pittance.
don't quote me on that but i read somewhere that microsoft has a strict policy of NIH in their codebase - everything gets reimplemented from scratch unless it's completely unfeasible.
The only problem might be the software patents that their code leverages.
If the licensed code was written by a patent licensee, then to replicate it in-house you’d also need to license the patent yourself.
In other words, the patent licensee may have a license to write and distribute their specific piece of software, but not to sublicense that to other people to write their own software, just to use the parent company's patent license. That is actually probably a common patent-license scenario, microsoft doesn't automatically get sublicensing rights just because they bought software developed by a licensee.
BSD license, because Berkeley was literally paid to port TCP/IP to Unix (and C) on basis that the resulting code would be available for incorporation by others free of charge.
man I wish they had open sourced OS/2. It could have a linux sized community at this point.
Sadly microsoft had put so much of their code in it, that they didn't allow the release (according to my dad who worked for IBM and was even called "Mr. OS/2" because he had sold it so good to companies)
I remember reading somewhere that while the developers of ArcaOS have the rights to continue the development of OS/2, they didn't obtain the source code. So they have to patch their changes into the old OS/2 binaries instead of changing the code.
There’s a bunch of costs to releasing closed source code as open source. Generally they’d have to have a team of developers review it, they’d need their lawyers to review it and any licenses. That every company that had licensed code used would also need to go through their own process.
At any time, one of them could say no and the process stops. So you’re basically paying for everyone’s time and possibly to relicense some parts. And im sure I’m missing other parts.
It's unfortunate that when a company DOES chose to release old software, the entire revision history is thrown out due to processes like that. In the software world, this probably doesn't matter too much, but video games can go through massive changes during development. But it also depends on factors like if game assets were even stored in version control in the first place.
Yep, it's a huge time sink even in the best case scenario, let alone with ancient software encumbered by transfer of ownership through multiple corporate custodians.
It's not that unusual for it to not even be wholly owned by a single entity due to licensing requirements.
It seems dumb and it is dumb, but it’s also an important feature of Windows that your terrible app from the 90s can still run today with minor changes generally. Less so if it’s win16 but anything win32 is good to go.
Also, Linux has a similar philosophy as Linus has eloquently described in the past. [1]
> It seems dumb and it is dumb, but it’s also an important feature of Windows that your terrible app from the 90s can still run today with minor changes generally.
This is a myth which is mostly not true from some time.
It's not like this kind of stuff can't be found by reverse engineering. For Windows specifically, the ReactOS team is doing lots of it to document the inner workings of internal Windows APIs so they could reimplement them.
> Is there a risk those closed source projects would be sued following the release because they disclosed some forgotten sin?
I know nothing about law, but I guess software companies would protect themselves in advance by mandating that all their developers use only software and sources that belongs to them anyway. That would be useful in case of a lawsuit where a court could force them to show the sources to prove they don't come say from the claimant's reverse engineered software, or some other FOSS project. Things might be different with 3rd party modules and libraries, where an obscure module was licensed from a company that went out of business ages ago, but all their assets were acquired by another party who finds the module in the wild and decides to sue.
Just speculating, but although I'm 100% in favor of FOSS, if the above were real possibilities, I couldn't but understand why some companies are so reluctant to release even old code they couldn't profit from anymore.
When developing software, a company might aquire a license to add some library or code to their product.
This happens all the time with OS's like Windows (licensing the ability to play media formats, etc.) or games (licensing certain engines or algorithms).
That doesn't mean the company squired a license to release the libraries or code as open source 20 years later.
So you'd have to go through the codebase with a fine-toothed comb, line-by-line, because the original developers don't work for you anymore, and the license agreements are long lost.
Releasing large software projects are a massive cost to any company that wants to be protected from potential lawsuits.
> Is there any good reason why the sources need to stay closed if they aren't going to make any further gains, financial or otherwise, from this product and its ecosystem?
Many reasons are there , it takes a lot of effort for a company to open source anything, to name a few
- Not get sued for IP infringement if your developer from 20 years back copied something or used GPL code etc
- Potentially expose active trade secrets , the program might not be sold , parts the code /algorithms whole modules might still be used in newer applications.
- Presence of PII or other sensitive/inflammatory content in comments and code, could be anything from funny(but inappropriate )method names to comments and documentation .
- poor boundaries, you could have dependencies which are used by the app which are not possible to also be open sourced.
- poor documentation, you simply no longer have all the code or is it time consuming to piece it all together
- expose vulnerabilities in your current offerings , code sometimes has way of being reused , you would be surprised how much “dead” code has a way of living on for decades later .
- third party agreements, not all your code is “your” code, you may have only licensed it from another vendor.
> No one has sold these OSes for 20+ years and they turned out to be evolutionary dead ends. It would make sense to release their sources so people could learn from them and run them on new hardware more easily.
There is a fair bit of third party code in the classic Mac OS, particularly in the extensions and cdevs. The nanokernel and some basic portions of the OS are likely releasable but they'd have to audit all of that.
> In general, open-source all abandonware. Here's a few examples of non-game old software that would benefit the society if open-sourced:
That's not the heuristic companies use to determine whether or not to release source code.
> Windows 9x and classic Mac OS. No one has sold these OSes for 20+ years and they turned out to be evolutionary dead ends. It would make sense to release their sources so people could learn from them and run them on new hardware more easily.
The companies would not do that, for the very simply reason being that it would cannibalise their existing offerings if "people could [...] and run them on new hardware more easily."
The biggest competitor to Windows 10 was not Linux or Mac, it was Windows 7. The biggest competitor to Windows 12 will be Windows 11.
> The biggest competitor to Windows 10 was not Linux or Mac, it was Windows 7.
I have to wonder how relevant Microsoft will remain in the long run. There are several projects maturing that allow people to run Windows apps — the one reason people use Windows in the first place — without any Microsoft involvement whatsoever. The fact that Win32 API has barely changed over the last 15 years also helps.
Wine compatibility is getting ever better. ReactOS is aiming to reach beta quality "soon".
the one reason people use Windows in the first place
The other reason is UX and people's familiarity with it. I tried switching to ubuntu a few times but small inconveniences adds up eventually and at some point I don't see a reason to switch. Windows works just fine and I like its UX (however we will see if that will change with 11), Linux needs to provide a bit more for people like me to switch for their personal computers
Well, ReactOS is a reimplementation of most of Windows, including the shell and the kernel.
Anecdotally, I once installed Ubuntu + Wine for someone non-technical who broke several Windows installations by infecting them with ransomware. He used it for like half a year calling it "this strange Windows" because some people don't know what an operating system is. He eventually irreparably broke its file system because apparently he was shutting down his machine by pulling the plug while it was running.
shutting down his machine by pulling the plug while it was running
Well, if windows was more reliable when it comes to unexpected shutdowns then it is also partially linux's fault.
I have a similar experience as well. I have a pi server and I was trying to use an ntfs external hdd. For some reason it breaks the file system if I remove hdd or shutdown pi unexpectedly. I am not expecting there to be no data loss if i am not writing or editing a file, just doing nothing, then why FS breaks?
When that happens, I connect hdd to Windows and it is able to repair it but there is no such option in ubuntu
> if i am not writing or editing a file, just doing nothing, then why FS breaks?
For a few reasons, but the most common is that when you write a file, you 'fwrite' operation doesn't typically immediately write blocks to the disk, instead it gets written to caches that will be written to disk in due course. Changes to the disk, tables with crucial data, etc again are just updated in memory, and written to the disk at a 'sensible' time. It's possible that you aren't actively performing operations to modify the disk, but various previous changes are sitting in memory waiting to be synced. If you kill the power then these changes aren't flushed so you can end up with corruption/filesystem problems. The main reason things work this way is for performance.
Internet Explorer is still very much alive for millions of people. Releasing the source would mean unlocking way more exploits on those people, with no plan to patch.
Umm, anything windows can't be open sourced because significant parts are still in use and source access would create serious security issues due to how MS handles legacy components, right?
Windows 9x is based on DOS. The last release of that lineage was Windows ME. The only thing modern NT-based Windows has in common with it is many application-level APIs. Everything else is different. There may be some common code, but if that's so important to keep private, fine, strip it. Heck, release just the kernel of 9x, that definitely can't possibly share anything with any commercially-relevant products.
> source access would create serious security issues due to how MS handles legacy components, right?
Security through obscurity is not real security. It's just delaying the inevitable.
You've conflated being able to use legacy apps which require a very specific stack of components with the complete absence of any such components.
Additionally you've failed to recognize that where legacy code is maintained Exactly As Is (bugs included) because users (corps and gov mostly) explicitly depend on behaviors remaining exactly as they have been for 20 years, there is effectively zero means/will to fix dangerous problems which are not being actively exploited.
And the mantra around obscurity is too often misused and misunderstood:
It's not that obscurity is not a form of security it's that its not a meaningful form of security On Its Own.
Obscurity is in fact the first line of security.
Just like with physical security, the first step is in preventing attackers from knowing it exists at all and Then having security measures to prevent access/theft/etc if they do happen to find what is being protected.
Y'know, like safes behind paintings, which are a very real thing....
> 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.
I would assume it's a lot more complicated today. Even the most simple programming projects tend to have a ton of dependencies nowadays.
And it doesn't even account for the fact that you might be killing future projects by handing out the blueprint of old games. Would Assassin's Creed Valhalla exist if we had 100 clones of Assassin's Creed III?
> Would Assassin's Creed Valhalla exist if we had 100 clones of Assassin's Creed III?
Probably, unless they all had the budget to create a shit ton of new assets and replace the old ones. And the code was released with a license that allowed commercial use.
> Probably, unless they all had the budget to create a shit ton of new assets and replace the old ones.
Isn't that what we're getting from AI generated content?
Note, I'm not saying that a random person will create something better. I'm just saying there might be a risk of saturating the market if you can play 100 versions of the same game for free.
This isn't how the games industry works for games at thia scale (or any other media). They are events. Millions of people having the same experience at the same time and having a common cultural touch point.
The 100s of clones would be more like fanfic. A set of people would get very into them, search out the good ones (perhaps better than the original), or revel in the terrible ones. But then the whole community still comes together to watch the latest marvel film anyway.
The main effect would be to build and maintain the community for the next commercial version.
Elder scrolls games are very moddable and people have made total conversions and map extensions. That didn't prevent the sales of newer TES games based on slightly improved engines and slightly better assets (fan-made assets are often still ahead of the official ones, but it takes years of refinement to get to that point).
That and things like Counter Strike / Day of Defeat that started as mods had a large number of maps back in the day. 99% of them were shit and weird experiments. The ones that did rise to the top eventually got incorporated into newer versions, and indeed became games in their own right.
DOTA as well, started as a mod for Warcraft 3 and eventually spawned a franchise.
Trying to capture ALL the value (in this case the game developer/publisher) is a mistake anyway. The healthiest game franchises have broad ecosystems around them. Releasing the source code of old games just encourages that.
If there is one set of games I wish were released it is Ambrosia Software's catalog. Of all their games the only one I can find that is open source is Maelstrom (It's the Escape Velocity series, I'd love to see opened).
I always wonder what happened with Ambrosia, they had a good library of games that they could update and could still sell but they just disappeared suddenly.
This dynamic is conspicuously missing from modern gaming. I think the anti-moddability is one of the primary factors in the industry's enshittification. Maybe even worse than microtransactions.
dayz and the arma series aswell they would not have sold nearly the amount of copies without it, it also ended up as a standalone however controversial it might be.
Escape Velocity was what got me into coding. I was huge into moding that game when I was younger on my old mac OS 7.x system. Absolutely fell in love with being able to extend the game.
Thanks for bringing that up. Those were good times. And agreed. Would love the source to original EV alone. Gonna take a gander at maelstrom! Thank you!
Before having an idea of how "proper" cracks should be done, EV copy protection was corrected in resedit by turning Cap'n Hector into an escape pod (so he couldn't kill you) and something else I forget right now to unlock some missions
> And it doesn't even account for the fact that you might be killing future projects by handing out the blueprint of old games. Would Assassin's Creed Valhalla exist if we had 100 clones of Assassin's Creed III?
Releasing the old doom source code doesn't stop id software from making sequels all the way up to doom eternal.
Less commercially motivated uninspired follow ups and more original content seems like a huge win for culture at large. Large video game and movie studios are mostly churning out copy-pasted garbage nowadays.
In the very short term, sure. All of the discussions of this kind of thing (and of copyrights and patents in general) have this same very-short-term perspective. "Patents SUCK, they're MEANT to encourage innovation but it's been SIX MONTHS and we STILL can't use [technique X]." Sure, but 20 years from now that patent will expire and we'll all be able to use it thanks to the fact that it was patented, and so significant parts of the 'secret sauce' are a matter of public record.
In the case of Doom, the engines being released has lead to an active community developing the engine (eg. GZdoom which can now be played in VR, with ray tracing, fancy shading, etc.) on pretty much any hardware with a processor.
Oh man, I remember building a new PC for Falcon 4.0. I think I still have the manual binder somewhere. I didn’t actually stick with it for that long in the end - I should check out what the community has done in the meantime!
Absolutely, and those releases weren't even that old (<10 years).
There are so many things that I learnt from tinkering with the Quake 3 source code in 2007, I am still very happy and grateful that I had the opportunity at the time. My understanding of topics like real-time applications, AI, platform independent code and debugging would be very different if that code would not have been released.
I guess this is legally unfeasible. Take a look at the splash screens next time you're loading a game - especially AAA but also smaller ones too. There will beone page with a bunch of logos. Havok physics is the one that comes to mind but there's loads more. Each of these is a plugin with proprietary code. They would need to be stripped out before the code could be released, which would probably be a lot of work. And then the code wouldn't run anyway.
This isn't a recent thing - as another comment points out, even the original Doom ran into this problem and only the Linux source was released.
It's often legally feasible but the result is difficult to get value out of (and obviously worthless for the company).
For instance Frictional open-sourced their HPL engine, Penumbra: Overture, Amnesia: The Dark Descent and Amnesia: A Machine For Pigs.
However the Amnesia games are built with Autodesk's FBX SDK, and I don't think they include any assets, they're not necessarily uninteresting artefacts but there's not much you can do with them either.
I'd be fine if they put up their code with the proprietary parts removed. They can just include a FIXME stating that the physics engine/video player etc. is missing. If the community picks up the code, they can just replace the missing parts.
I've worked on games before. We ported our game to havock between versions. That took 8 months for one dev. The code review was 3 weeks. Ripping ours out was a month by itself. There were several libraries like that. The sound system was similar and we had to upgrade it every game which was similar work to havock. Heck there was a really simple font to bitmap lib/utility we used and that would have taken several months to replace. A month to rip out.
I moved us from PlayStation 3 to PlayStation 4 for our debugging UI and literally just removing all the calls to the old debugging UI system was something like 2 weeks my only goal there was to get it to not compile. Wiring up all 3,900 debug UI connection points to the engine with access to all the rest of the game engine library and having written parts of both systems in the engine and the debugging library and the new UI library still took me almost 2 weeks I did it with both systems working at the same time which was actually easier than doing a full rip out. The studio I worked at tried really hard not to use proprietary libraries and it was a big deal for us using havoc but we needed to they ended up going back for the next title. They also wrapped literally every library with shims to make it easier to Port but things like physics engines are just basically impossible to wrap fully as our sound engines and font libraries the implementation details leak into everywhere.
The suggestion you're making is a very large amount of work probably on the level of several engineers for several years on a Triple-A title now you're talking like a million dollars for the company to open source it and locking up some good devs for a year or more. There's literally no economic trade off in doing that unless you can come up with a way to make one.
Porting would be an okay economic trade off there.
Thanks for taking your time to answer my suggestion in detail.
I was just trying to suggest something very simple - just don't include the files that you don't have the rights to - so in your case just don't publish those font and physics library files. No need to completely rip out all references to it.
The resulting code will be broken, but if the community cares enough, they can fix it up.
I don't think this would be a huge effort to do - do you see any issues (legal or otherwise) with this approach?
We did have our code mostly sorted into 3p and 1p... However I'm not a lawyer and not sure how the taint might leak up. I forget where Google/oracle landed on apis being copyright but havock ids and other concepts leak into your code everywhere. Heck even proprietary details might or algos. It would still be hard and the lawyers would be skeptical. You'd need a business case besides goodwill to get over those humps.
I bet a ton of companies don't follow those best practices. And there's also the fact that you've now exposed yourself to litigation where some dev violated copyright of previous companies or libraries or whatever and put it in the wrong place or copied it. Before open sourcing you were fine. After you have essentially incriminated yourself.
The doom/quake case is kinda an exception. In that you likely (I'm guessing) had Carmack who is a founder/owner, deeply understand the tech base, understands cost and estimates, likely understands licensing quite well, able to go do the work, but also able to make the cost benefit tradeoff and override objections in some cases. That's not common in many companies.
Removing these proprietary parts can actually be a lot of work or potentially impossible without a major refractor, especially if they're foundational to gameplay, like a physics engine.
Why? You just ship the code that you wrote without the third part libraries. I don't think you did copy/paste the library code inside your own, it's probably linked to the executable in some form. Of course it would be impossible to compile the program without it, but as it's said, the component may be recreated by the open-source community, or sourced form the closed-source game in some other ways.
Probably true, but that is probably also against the license agreement (even if unenforcable). Most companies don't want to take this risk (and potential legal costs) just to release code that won't bring them any (direct) revenue.
To use bullet physics as a hypothetical example, if my game was the hello world example [0], I would expect that practically that entire file would be un-distributable.
Surely that part of the code is AT LEAST fair use?
Or one has to be at the wrong part of THAT historical argument (not necessarily pointing at parent)?
(Yes, I would argue that this is exempt following the ‘functional’ argument)
Depends, if it’s code calling a console SDK API then you are bound by terms of the NDA to not publicly share it — forever. Even just function names!
More realistically, a drop of source code is basically painting a big target on your company to get sued by a troll. I’ve wanted to release my game’s source but am terrified of this.
> Depends, if it’s code calling a console SDK API then you are bound by terms of the NDA to not publicly share it — forever. Even just function names!
This is not true. API itself (function names and parameters) does not hold copyright. Otherwise you wouldn't have open-source applications on any proprietary OS, since they have the function calls of proprietary APIs inside.
What can be copyrighted are the header files itself: these you can't redistribute, as you can't redistribute the binary that is linked to the executable. Of course without these you wouldn't be able to compile and run the software, but you can reverse engineer the API from the function names and parameters and even the binary executable (because for an EU law reverse engineering for the purpose of substituting proprietary parts, that is this case, is allowed) and build a replacement for sure.
> What can be copyrighted are the header files itself: these you can't redistribute, as you can't redistribute the binary that is linked to the executable.
Note that while the exact header file is covered by copyright, the "information"/"facts" the header file describes (e.g. said function names, parameters, constants, etc) is not - at least as far as EU is concerned anyway (BTW the case you most likely have in mind wasn't for substituting proprietary parts but for interoperability between parts - i.e. it would still be valid for substituting one proprietary part with another proprietary part). This is also why different compilers for Windows have a "windows.h" (or language equivalent) with each having its own copyright but describing the exact same API.
(obviously this is for unsubstitutable fact-like information a header file contains and does not apply for any code like macros or inline methods like in C++ classes/templates)
Perhaps you could just rename the function names, structure fields, etc, to something different but similar?
e.g. instead of ps3_fly_up(...) you'd rename to something a bit more generic like sdk_float_up(...) or something like that.
It could require a bit of creativity and some work but with a sufficiently-intelligent IDE it'd just be a one-time rename per function name + structure name + field name.
I believe most popular libraries and middleware (like Havok) aren't freely available/leaked, OR at the very least it's some ancient version with massive API differences compared to newer versions. Around the time of the Pokemon leaks in 2020 I was watching people live on Discord struggling getting Pokemon Diamond to compile, because apparently the DS Wi-Fi component of the official SDK was never actually leaked online (at the time)
What should really happen is a law that video games get declared public domain and have their source code released after 10 years. All assets and dependencies would get automatically released under a license allowing for their use in that game and derivatives of it.
As it is, the source is mostly just lost to time, making humanity poorer.
Doom, Quake and System Shock all have high profile remasters in spite of their source releases. Hell, one could argue they had high profile remasters because the source ports kept the game and communities alive.
That (maybe) would have worked in the olden days of physical disks or catridges.
Today it is trivial to keep the game on steam with zero sales (or almost zero).
If lawmakers wanted to pass a law that actually made this happen they needed to stipulate a cut off date (and potential compensation) as well as rigid rules about what one can do with the released code.
Why would there be a need for compensation. Copyright is only granted in the first place so that more things will (eventually) enter the commons. Rolling back the perversion that is the current copyright terms doesn't need anything to balance it out since the current sitation is already so unbalanced in the other direction.
Practically only games that are continuously updated have longer shelf lifes. In that case only the original version would have to be opened after 10 years and later modifications would have to wait ten years after their release.
That dynamic has changed a lot with multiplayer games which are in continuous development. For instance DayZ just hit record player numbers after nearly a decade:
But even if that's an outlier, online games can have a surprisingly long tail where the game remains profitable even if the player count doesn't grow anymore (as long as the developer supports the game at least).
I guess the best way woul dbe to regulate that.
If you want to sell any software (including firmware) you have to deposit the sources and encryption keys into some state-owned repository.
If you decided to stop maintaining the code it would be released into public domain after some reasonable grace period (e.g. 5 years).
That would solve many issues including excess e-waste.
As an aside, have you played red alert lately. Holy crap. I tried a while back and it's like people have just been studying that game non stop since I was a kid. I got owned. But year totally agree.
I sort of think that with a smart OS license for game IP you could put a lot of stuff into the public domain and it would flourish in really interesting ways like fan fiction.
The reason is often that those codebases are usually a giant hairball of closed source 3rd party dependencies which would be a nightmare to put under a common open source license, no matter if the companies behind those products still exist or not.
And O3DE is mostly a rewrite. It's really interesting to compare the last public CryEngine releases and O3DE for example how the rendering architecture is laid out.
It‘s still interesting to see how certain challenges have been solved back in the day.
Or as a case study in what _not_ to do today. For example, Quake‘s ingame console commands were stored in a linked list. I believe looking up a command was a linear search through that list. You wouldn‘t do it like that today.
> For example, Quake‘s ingame console commands were stored in a linked list. I believe looking up a command was a linear search through that list. You wouldn‘t do it like that today.
Sure you would! You think those dinosaurs like Carmack didn't know about tree-like structures and hash tables back in the 90s? They did, it is just that (I assume) their main goal was to optimize something that is computed every frame, not once in a blue moon when player inputs a console command, which latency doesn't matter that much anyway whether is is 1ms or 10ms. In fact, toying with advanced data structures for console optimization sound like something junior engineer would get reprimanded for by seniors, if caught up wasting time on it.
I don’t know about quake, but in quake 2 it consisted of a big list of:
else if (strcmp(cmd, “somecmd”) == 0)
somecmd()
I remember reading it at the time and being inspired by the simplicity of it. It didn’t need to be more complicated than it was, and so Carmack didn’t make it more complicated. That was in stark contrast to a lot of the object oriented c++ design stuff that I was also reading at the time.
So much of the quake 2 game source was like that. Beautifully straightforward code.
The example sounds like a quite basic insight into algorithmic complexity or complexity of lookup operation of data structures. A linked list is fine, if you need or want to go through the entries sequentially anyway, but if you need random access, then you probably want something different. I can tell that without ever having looked at something like Quake's console commands implementation. However, it might have been the case, that there were not that many commands anyway, so that the linked list did not noticably slow things down.
> it might have been the case, that there were not that many commands anyway, so that the linked list did not noticably slow things down.
Also, unlike the game code itself which has to finish running its work in time for every frame, it probably doesn’t matter if running a command from the Quake terminal takes a little bit extra time.
Would anyone notice or care about a difference in the amount of time it takes to run the /noclip command for example, in a O(n) vs O(1) lookup of the command in the probably short list of available commands? I don’t think so.
Speaking for myself, if I bring up the terminal in a game like quake to run a command, I’m probably standing stationary somewhere out of danger at the moment. And the amount of time I spend to tab open the terminal and type /noclip would be much greater than the amount that the game then takes to look for that command in its list of commands.
> Also, unlike the game code itself which has to finish running its work in time for every frame, it probably doesn’t matter if running a command from the Quake terminal takes a little bit extra time.
Except we did, because back then, the console command loop was part of the work done every frame - so your lookup still had to fit in the budget, or the player would see frames being skipped. Which, if memory serves me, happened as far as Quake 3.
Here's another important insight about how games were written back then: they were single-threaded. Rightfully or not, the cost of context switching was seen as too big, so everything was run in a single thread - maybe with an event loop (what kids these days call "async") thrown in for convenience, especially around UI. The games that did use threads, would use a small amount of them to offload some work that wasn't strictly frame-bound, or when outside main gameplay (e.g. in menu). I actually can't think of any game from that era, which would run multiple threads during main gameplay.
And sure, you can adapt the console with your linked list lookup to run on the event loop ("async"), so it would e.g. do a fixed number of search steps, then yield, and resume next frame. But the code for that would get much, much more complex than replacing a linked list with an array, even if you then also replaced linear scan with binary search.
So one other thing about games back then: things were much simpler, and skipping frames wasn't that big of a deal-breaker. Multiplayer wasn't so popular, there was nothing you could honestly call physics code - which would explode if you skipped frame without compensating, etc. And players were used to getting anything from 6 to 60 FPS, depending on hardware they owned. These days, a game console blocking main gameplay thread and causing frame skips, would be unthinkable.
Single threaded kind of makes sense for machines with single core CPUs. And multiplayer was usually limited because internet wasn’t that good typically being dialup.
Games required more cutting edge machines (maybe 2 years old) I remember getting a notebook with enough power (66mhz, 4 megs of ram) to place doom. Taking my machine to a friends and playing one on one death match over a serial cable.
But you were not typing a console command each frame didn't you? A spike of 0.X ms when you type a console command and hit enter won't be anything to worry about
The game studio I did did many many things in linked lists or arrays still because literally searching an array is still much much faster than computing out hash algorithm when the total number of entries is less than a thousand and it gives you memory predictability. So generally when you're searching it almost all of it has been loaded into RAM especially if you limit the size of the items in the length list which games almost always do and you list limit the size of the array which games almost always do almost everything in a good game engine is fixed size arrays for repeatable performance. I was surprised by this as well when I moved from doing Ruby and Java apps into AAA game studio but the engineers were kind and explained it to me and showed me the math and I was like yep that is way faster. I also didn't appreciate the things like cash coherence that they highly leveraged to make every frame sing
Intrusive lists are not bad. Building one does not require heap allocation unless the object itself is heap allocated. I can imagine this being case for a list of console commands, just a bunch of static allocated structs in various places tied together via intrusive list. In fact we (abother game company) are also how are doing it today as well
As for the linear search, it is just console commands. User types it and then it makes a search in what, a couple hundred entries at most? Sounds perfectly fine
Does Quake 3 also use a linked list for the console commands? That game even has command completion, whereby pressing tab after typing a couple of characters, the console fills in the command you most likely wanted. The console in Q3A is extremely fast IME.
I wonder how many people still program modern game engines? Sometimes it feels like everybody just take the newest release of the Unreal Engine and drops assets and scripts into it.
Just to be clear, I am not saying that there are no alternative engines, just that these things are so complex that there are very few people, who dare to compete with Unreal.
Most of the old engines have been modernized. IoQuake3 for Open Arena, Doom3, even the Quake 1 src it's not the same as the one ID released. And I am not talking about DarkPlaces, but QuakeSpasm, SDLQuake...
My own personal and private opinion is that I wish the legislation would opensource things that are not being actively sold where the owner is a corporation.
You still have registration in USA, so if you register then you have to deposit, if you register with corporate ownership then you pay a yearly renewal, if you stop paying the deposit goes to public domain. Simples.
Agree. I would even be happy if the game was stripped of all licensed code/assets/tools/etc. And honestly, I don't even care if it can successfully compile/run. Just having the code alone would be tremendously useful for the purpose of study.
I remember when Far Cry came out. Around the time, Doom 3 and Half-Life 2 were the most anticipated games for quite a while, mostly because they promised graphics far ahead of anything released so far. But as they were delayed multiple times, Far Cry stole a lot of their thunder when it came out months before them, with similarly impressive graphics.
We don't see technically ambitious PC exclusive games like this anymore, as the market for these games greatly decreased in relevance. Most people don't own an expensive desktop PC anymore (due to smartphones and laptops doing most of their jobs) and they just buy a console if they want to play games.
Huh? That doesn't seem right. We absolutely have ambitious games on pc that bring generational leaps in graphical fidelity.
Like the Witcher 3, which was absolutely stunning when it first released.
Similarly (although originally a console exclusive) Red Dead Redemption 2 looks incredible on PC.
We also have releases like Hellblade: Senuas Sacrifice which pushed the limit of what was possible to achieve with limited resources (regarding the development, not the hardware).
Honorable mentions should probably also include Star Citizen, which although still unreleased is definitely an incredibly technically ambitious project.
As is Cyberpunk 2077. The launch might have been a total disaster, but afaik it's the first big game to ship a full ray-tracing renderer.
Maybe we have a different understanding of what a 'technically ambitious' game is. But I see technical improvements left and right. Unreal Engine 5 comes with some features that are just mind-blowing and make a whole new level of graphical fidelity available even to small indie developers. Just take a look at the recently released footage of "Unrecord", where lots of people thought it was real life footage.
It depends what your reference point for the rate of progress is. The release date of Crysis is closer to release date of Doom than today, but visually Crysis holds up dramatically better than what Doom did at the time of Crysis release.
On the other hand I bet there are more people playing Doom 1 & 2 today than Crysis. Doom's gameplay held up better, and 3rd party WADs (in large part facilitated by the primitive graphics making it easy for one-man creators) gave Doom a life of its own.
Hell, if you were making a game that looked like Ultima VI (1990) in the mid-late 90s, that would be treated as embarrassingly retro. Call it 5 or 6 years.
Once we settled on quasi-realistic 3D games with a mostly consistent control scheme as the norm, that process of obsolescence has slowed down dramatically. Games have sort of plateaued in that way. So you really can go back and play Crysis and it's still fine. It's noticeably "retro", but I think only serious graphics nerds would be bothered by its deficiencies.
idk. 80s-early 90s pixel art style was all the rage 10 years ago as retro, nowdays the action is at late 90s-early 00s wonky polygon graphics, so it seems to have advanced pretty proportionally
Parent comment said PC-exclusive, Witcher 3 and RDR2 are examples where the PC port came out way after the console release and they are both fairly old games at this point.
Witcher 3 came out on PC at the same time as consoles. CDPR has a long history with PC gaming and they tend to emphasize the PC experience. They also own GOG which is a PC game store/platform. RDR2 on the other hand was indeed a timed console exclusive.
Most ambitious games are now primarily developed for console while only being ported to PCs. Cyberpunk 2077 was apparently primarily optimized for PC (while still being a cross platform title) but that's an exception.
Witcher 3 is 8 years old and considered an old persons game. I learned that the hard way when I tried talking to my nephew about video games.
In all seriousness, most of your examples I would consider part of the previous era of gaming, which ended with Fortnite’s explosion. Hyper realistic games will continue to be developed of course, but the overall industry trend is moving towards mobile-friendly graphics, which presents its own set of technical challenges.
I agree that Witcher 3 doesn't count as "current gen" anymore, but it wasn't meant to represent that. I picked my examples to show that we've seen high fidelity games throughout the last decade. All of those games pushed the boundaries of what's possible in some way and I don't think we've seen a decline of that at all.
There are just so many more games now that it might seem like that.
In general I agree, but I rather remember The Witcher 3 for the story and atmosphere, than for the graphics. Likewise Senuas Sacrifice - it pushed the limit for psychological games(the game is about processing loss through a psychosis, so it is not a casual game). In either case, both titles are really worth it.
That's definitely worth it. But just to repeat myself, it is not a casual game and I recommend head phones, for the full experience.
Meaning you should not be on the call, when playing it.
It also has a decent fight mechanic but the main experience for me, was the mind trip.
(professional psychologist were strongly involved in the developement)
Witcher 3 caught a lot of flak when released for looking worse than what was shown at E3. Why gamers still pay attention to early-access peeks of games at E3 is beyond my comprehension, it seems like a recipe for disappointment every time..
The PC gaming market is actually bigger now than it was back then.
The difference is that consoles didn't really start to become viable for the FPS genre until the Xbox/PS2 generation (and even then it was really just Halo).
So an FPS was PC exclusive by default with only the biggest games getting a clumsy console port or spinoff years later (like FarCry Instincts). Consoles became a first class citizen in the world of FPSes with the 360/PS3 generation in the mid-2000s. That's why FarCry 1 (2004) was a PC exclusive but FarCry 2 (2008) released on consoles and PC at the same time.
Competitive FPS games did even exist on the N64 (James Bond Golden Eye, Perfect Dark), and in the next generation they were very common and mostly had the modern two stick controls which is still used today. So I don't think that had anything to do with it.
> The PC gaming market is actually bigger now than it was back then.
This might be true, but I'm fairly certain that the market share of the PC platform has strongly decreased relative to the consoles. AAA games have largely shifted to consoles or console ports. The most plausible reason is that the desktop PC market has collapsed. The heyday of PC gaming was probably somewhere between Quake (1996) and Crysis (2007).
The "next generation" after N64 was Xbox/PS2. In my previous comment, I pointed out that FPSes on consoles became viable during that time. There were FPSes on consoles even prior to Golden Eye/Perfect Dark. For instance, there were SNES ports of Doom and Wolfenstein 3D. They were just all pretty bad. Even the "good" ones like Golden Eye don't really hold up against the PC shooters of the time.
Shooters didn't become a premiere genre for consoles until the 360/PS3 era. Like I said, as far as popularity went, there was Halo and MoH (to a way lesser degree) during the Xbox/PS2 days but not much else. And then all of a sudden, shooters became the hottest genre on consoles in the mid-late 00s. That's when CoD and Battlefield made the transition over to consoles in earnest. It's when Sony invested heavily (and ultimately failed) in creating a "Halo killer". It's when CoD went from a pretty successful PC franchise to consistently being the highest selling game year after year.
As far as the PC gaming market goes. There was a dark age starting in the mid-00s. But PC gaming is very popular right now (we'll have to see what impact high GPU prices has on its future) .
For instance, Activision makes more money from the PC platform than all consoles combined.
No one in the industry ignores the PC market anymore. Everyone (except Nintendo) is releasing their games on PC now even companies that weren't traditionally in the PC gaming market like Japanese publishers. Genres that had a spotty history of PC support (Sports, JRPGs, Fighting games, etc) are seeing consistent PC releases. And even Sony conceded and started releasing their exclusives on PC (years later but it's still a dramatic shift from even a few years ago).
As someone who was primarily a PC gamer in the 90s, I can tell you anecdotally that I know several people who were console gamers only 20+ years ago who are now PC gamers.
By the time Far Cry, Doom 3 and Half-Life 2 came out, shooters were very common on consoles. There were many more console shooters apart from Halo. The fact that we see hardly any PC-exclusive AAA shooters anymore, but did back then, calls for an explanation. And it's not just shooters. In general there are few AAA games nowadays that are PC-exclusive or mainly targeted at PCs and only ported to consoles. The situation was very different in 2004.
> We don't see technically ambitious PC exclusive games like this anymore
You should consider A Plague Tale: Requiem. Even without ray-tracing, it is by far one of the most beautiful games I've played in a long time (since The Witcher 3, at least). Not to mention it has a sucker-punch of a story and a phenomenal soundtrack.
It was a weird time. The Xbox existed and while not as powerful as PCs of the day, were closer in terms of cutting edge features thanks it's GPU with prorammable shaders. Doom 3 managed a decent port and Far Cry was remade as Far Cry Instincts which while less graphically impressive, was the better game. Half Life 2 got a port in 2005, but woof, it's pretty rough.
The real winner that year was The Chronicles of Riddick: Escape from Butcher Bay, which did what Doom 3 did (stencil shadows, normal maps, unified lighting) on Xbox months before Doom 3's release on PC. It's the better game, too.
Crytek still makes graphical masterpieces (and IMO crysis has one of the best FPS stories).
Crysis 1 and 2 remastered are very good, and crysis 3 is still a masterpiece after more than 10 years.
I remember that the initial levels of Far Cry 1 were amazing jungle/beach scenarios that enabled a lot of different strategies for overcoming the smart human enemies.
The last levels, however, were all inside claustrophobic buildings with weird monsters running around.
If all levels had the feeling of the first ones, it would be my favorite game of all time.
The demo was the first level in the bay. I think after 100 playthroughs there were like 5 different strategies to clear that level, all equally fun and effective.
And indeed at the end you were just pumping 500 rounds into unstoppable Doom-style monster deep inside some dark hallway.
Agreed. I had amazing fun playing the first bits of Far Cry 1, sneaking through the jungle and playing sniper. It was great. Then I got to the end part, inside dark buildings and suddenly stealth isn't important at all, its more of a twitch shooter full of jump scares and requiring fast reactions over anything. I never finished the game
I agree. Wasn't it zombies? The first levels set a great feeling and atmosphere, everything was mysterious, and then it felt like they ran out of ideas and were like "hm yeah let's add zombies, because that's not totally something overused". And yes, I don't even remember the later levels and didn't even finish the game.
Those early levels where you fight against humans in a tropical setting were the best part. Every Far Cry game that came after, emulated those first levels, and scrapped not monsters in hallways.
This was one thing that surprised me when playing the remastered version of Halo. It looked exactly as I remembered it. Then I swapped to the original graphics and realized my nostalgia and memories had added lots of extra details.
Somewhat, you can still see how the sky looks unnatural from the HDR effect which just ruins everything. The top is a more natural realistic sky. Shoreline is kinda weird too.
But I don’t think it is just simple HDR tonemapping, it doesn’t do that, but rather some type of color grading going on. The bottom is over saturated and over contrasty.
Far Cry 3 was miles better than the first two. In fact it was because of the success of 3 that every later game was just a copy of it, and the franchise stagnated.
Far Cry 3 and subsequent games were pop fun with little replayability. FC2 was a game I've lived in, with a printout of the map, marked up for patrols, so I could navigate safely from A to B for each mission.
Better? I'd rather say less challenging, more accessible, but also far less rewarding. More successful, no doubt. But the only sequel I spent a lot of time in was Blood Dragon.
There's a lot to be admired by Far Cry 2: the environmental mechanics, the introduction, the lighting effects, the gritty and exotic atmosphere... but to me it was not a fun game. Not in the way that Far Cry 1 was fun.
The immersion is what sold it to me. No hud, no on screen markers. Need to look at map? Pull it out, hold it in your hand and look at it. I'm surprised no other AAA game has tried this formula.
FC1 lost its fun with the mutants. FC2 never stopped being fun to me, because it was essentially a giant open world game of Thief: get from A to B without being detected (since enemy patrols respawned, there was no point killing them).
> (since enemy patrols respawned, there was no point killing them)
This is the main thing that made it not fun for me, lol. There really is no point in partaking in random combat in the open-world. It's always better to run away or sneak past them. Fine in a stealth game, but FC2 didn't have great stealth mechanics beyond crouching and staying far away from enemies.
I thought it simulated reasonably well the dynamics of a lone gunman on a mission in a civil war. It seems to me the only way to navigate such warzones would be stealth or disguise.
All the other FC games are stealth games too, BTW. The later FC games made it even more explicit, with bonuses for never setting off alarms and so on.
True but it just felt too fast with the respawns. Maybe my memory is wrong but it felt like going far away enough to despawn that zone from RAM was enough to make them respawn. I would have preferred a few days. If I clear a camp enough, maybe have them bring backup.
I stopped playing the series after 3 because they did feel that way, but without gameplay features I wanted to match. Games that rewarded stealth, but without stealth-specific mechanics like you'd find in Hitman or MGS. It feels like the writers want to encourage stealth but the game designers didn't. At least for 1-3. The original I definitely accepted it more because of the era.
If they’d re-release Far Cry 2 with graphics on par with FC 5, I might never play anything else. I could hike around all day admiring the scenery in FC 5, or ride a jet ski from one end of the river to the other. But the story was hokey and tropey, most of the characters were uninteresting, and the ending was enough to put me off of Ubisoft for good. FC 2 had a great story, great characters, lots of interesting mechanics. And of course, the Standard Ubisoft Paradigm (climb a $TALL to unlock a map quadrant, sneak into $PLACE and fight $HEAVY, $SNIPER, and $LIGHT, have a $FORCEDENCOUNTER with $SUBBBOSS for some exposition), was still new enough that we weren’t tired of it yet.
> FC 2 had a great story, great characters, lots of interesting mechanics. And of course, the Standard Ubisoft Paradigm (climb a $TALL to unlock a map quadrant, sneak into $PLACE and fight $HEAVY, $SNIPER, and $LIGHT, have a $FORCEDENCOUNTER with $SUBBBOSS for some exposition), was still new enough that we weren’t tired of it yet.
FC2 didn't have that. FC2 was set in Africa. It's still my favourite of the bunch for a lot of reasons (only a little because I understand the local language the mooks are screaming to each other when you're in the middle of a firefight).
It's funny, when I first bought FC2 I played for about 8 hours and I hated it.
When I went back to it after about 8 years, I found that I appreciated the immersion a lot more, and it quickly became my favourite.
I liked Far Cry 4's setting and characters, but the game otherwise seemed very lazy and uninspired. Bland map and very little do to in between outposts. Little emergent fun to be had, except for doing missions or clearing outposts. Same complaint with Far Cry Primal; really neat idea but lazy/rushed execution.
What is really interesting, is that lots of people would accuse you of rose-tinted spectacles and similar, I have continued to game from about 1998 until today.
the gaming industry is in a very odd place, and not unlike the film industry. Rehashes and sequels to increasingly aging 80s and 90s franchieses is the done thing. It generates nostalgia bucks from the older folks, the new folks are ignorant of the originals so just consume them at face value, and there is the magic 3rd property of being much cheaper to develop than creating something original.
This has lead to a huge drought of good new things because MBAs are not condusive to creative risks.
In gaming, what also follows the same line is stuff like graphical development. It's far more economical to take the Original game engine, and just gradually modify it as each generation passes. As a result, the most recent Far Cry game is almost identical in graphical quality to the last 3-4 at least (and it's not massively far away from the original either).
Because of cost-saving increment culture. Now, there is an additional element at play here, increasing polygon counts are exponentially uneffective - if a car with a circular wheel has 3 points, it looks awful. Double those points to 6, and hexagonal wheels look a hell of a lot better, and are passable in many older games. Double it again to 12 and it becomes indistinguishable from a circle at a glance. Double it to 24 and you would barely notice, double it again and it looks no different to the last generational increment.
The other issue is despite tooling coming so far, we it still takes a human artist the same amount of time to draw and design something. If that has to be done at increasingly extreme levels of detail, it's going to require more artists (and artists also don't even work well like that). So that also presents new problems.
So along with all the cost-saving and business optimisation of the pipeline of games production, there are real factors at play in how things have improved that really change how things look and feel.
I will say, if you watch a youtube video of the original game being played in high detail on a high end machine (this would have been before 1080p was a thing I believe) and watch a video of FC6 with a modern high-end machine at max settings, it's still impressive.
As a Far Cry fanatic, even the difference between Far Cry 3 and Far Cry 4 is substantial. Far Cry 3 is one of those games where the gameplay is so good, you don't even pay attention to graphics, but with 4, you are on a different planet.
I would advise NOT using this to learn from. There are so many antipatterns in here that it's a hot mess. There are plenty of better resources that teach good habits than learning how to become another high turnover C++ developer intern about to throw in another broken, fragile lava layer.
I remember there is a bug with the hang glider that if you move down and up you gain momentum
Back in the day far cry 1 was ultra realistic graphics.
The game was fun to play, the most annoying thing is if you throw a rock or grenade where they can see if your stealth meter in instantly goes to zero and they start shooting you.
The game is riddled with small bugs, like you can knock the phone off the rock in the first level bunker then the cut scene will have him picking it up.
Having the trigens fight the people throughout the game was fun, and stealth aspect as well.
It's funny how the game emphasis seemed to be on the realistic mode, but it's like it was only tested on medium - the trigens would die very quickly and easily on realistic if the guards shot them, if I had to guess probably the bullet damage is turned up on that mode.
The internet can wipe things completely given enough want from corporations. For instance the hulk hogan tape seems utterly gone no matter where you look.
Well that sounds bad. Are they all-in on piracy like their server is hosted on international waters or rotating between some whack-a-mole servers from like kazakhstan and mongolia and eswatini?
Yup. Hosted on a server farm aboard a repurposed cargo ship flying a pirate flag roaming international waters, spending its life evading the coast guard, using starlink satellites to provide connectivity to the rest of the world. The crew is made up of former cyber criminals evading the law from their home countries for hacking related offenses, along with a few actual Somali pirates or random killers and war criminals. They have the greatest collection of pirated software, raw leaks and rare media files that you won’t find anywhere else.
“Information… wants to be free.” says one of the administrators before taking a final drag on an unfiltered cigarette and flicking it off the deck.
There’s a distinct Russian accent in his voice, from his days living under the Soviet Union. After its collapse, he moved out west to what is now Belarus, and fought in underground cage matches for money. After a few years spent getting beaten and bloodied, he decided to start looking for new work when he learned about this thing called the World Wide Web from one of his former Soviet colleagues. From there he picked up skills writing programs and hacking into systems, taking random contract jobs through IRC for anonymous clients.
One day after a botched job involving millions of dollars stolen from some wealthy government officials, authorities were finally close to catching him.
Seeking help, an IRC user by the name of “Чудовище“ offered him an opportunity, to come aboard a special ship, the first of its kind, and live freely on board as a stateless citizen in international waters. There he would be able to continue developing his technical skills and contribute to a good cause: information freedom.
“In the old days, it was tough getting data on and off the ship. We had to exchange pallets of hard drives with other passing ships out on the ocean. But now…” he gestures back at the array of satellite dishes along the deck “…much easier, and anyone anywhere can connect to our network.”
“Whatever you look for, we have. Classified documents, private snuff videos, Epstein’s lists… and even FarCry source code!”
Kinda, Amazon purchased the code and forked it as Lumberyard. Then they realised their own studios didn't want to use it and their game-dev projects failed, so they donated the engine to the Linux Foundation.
But the engine didn't even support Linux yet, so they spawned a new Open 3D Foundation for it, and renamed the engine Open 3D. I haven't heard of anyone using it seriously yet.
Actually, before Lumberyard was released, Crytek had already open-sourced Cryengine and gave it away under a pay-what-you-want model until the engine's 5.5 release.
Far Cry was an excellent multiplayer game, we use to play it at LAN parties (remember those?)
The huge maps, tropical setting and vehicles meant you could hide in the jungle and snipe at someone on the other side of a bay, or sneak right up behind them.
There's no reason why a company would be required to release the source code once copyright expires. Someone finding an old copy of the source could spread it around, but that's about all.
However, with copyright expiring 70 years after the death of the author(s), by the time copyright does expire, the sources will have disappeared.
Under the Sonny Bono Act in the US corporate copyrights were extended beyond 100 years. The original US Copyright Act was limited to 14 years, and allowed a single renewal of the same length. After that, public domain. The short term goal was to provide authors with some income during the term, but with the ultimate purpose of enriching the commons to benefit the public. "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries." US CONST, Art I, Sec 8, Cl 8. It could be argued that copyright copyright terms of over a century, especially during a particularly dynamic period in world history such as ours, no longer serve that purpose. As you point out, the end result of the current regime is the debasement of any real practical value many works would otherwise have. All that will be left are the cold entries in whatever royalty ledgers survive.
In my opinion, copyright and patent law needs to be altered significantly, with the copyright term obliterated so people can build upon advances in technology and culture within a reasonable amount of time.
Sadly, I don't think it's realistic to think copyright terms will ever be reduced. They'll only be extended, probably when one of the many Disney properties is about to become public domain.
That's spectacular. I still enjoy playing Far Cry 1 in my Windows VM (with the Sniper MP5 mod) to this day. It was a fantastic game for its time, and I find it has aged well.
12 out the 22 projects with VS2022, but that's most likely just the start, as there are dependencies shipped as binaries, which most likely require a recompilation for compatibility.
Maybe it's easier, if one uses the matching, old compiler version.
Sounds like a real world project that focused on shipping a good game rather than have perfect code.
There is a reason perfectionist devs do not run big projects. They focus on minutiae rather than the big picture.
Even in my own experiences, one of my most successful projects (eventually acquired by Amazon) was a quickly written hacked together project that solved a big issue well. Over time it became better engineered but it taught me successful projects are about market fit, not code quality, especially super minor things like antipatterns.
Or maybe, just maybe, 'good practices' simply changed over the span of literally 20 years?
Naah, it must simply be those 'perfection vs practicality' dichotomy again.
...Not to mention that your point is the definition of survivor ship bias.
Maybe the devs actually were super mad at themselves how the codebase looked cause it slowed down their development. Maybe they initially had 3 more times the ammount of anti-patterns, but they reduced them.
Or maybe that's how their roll, but the fact that this code shipped is almost insignificant when it comes to judging its quality.
We could spin infinite ammount of examples where bad code works, where good code fails, where bad code fails and were good code works.
How about we actually talk about arguments instead, though?
I don't really think good practices changed that significantly in the last 20 years. Good practices must be seen like guidelines, not a strict dogma. They are mostly for the benefit or other humans to read and modify it without introducing (many) bugs. So, it's always a balance between the time you can reasonably imagine that code base will still be relevant, the number of people changing it, how much harder certain bending of the guidelines make it to change the code in future, etc.
About half of those are because of "performance", which in game engines is more important than future-proofing for maintenance that will likely never occur.
Best practices evolve. This code base predates modern smart pointers, and from experience bit fields were a requirement on some of those... tougher platforms.
It was a little bit tongue in cheek. But I'm currently in a code base that is almost exactly 10 years old. And of course all of the developers have personally grown in that time. But some of the practices were dependent on the technology choices available at the time.
Pretty much everything you mentioned is also in Unreal Engine and they affected it so much that companies left and right throw away their own engines to switch to it. My favorite part of UE5 is that its "base of all classes" object class (UObject) has its own base object class (UObjectBase).
Actually not just UE, but almost everything you mentioned was in every single engine i worked on (to be clear these were all engines that started long before i worked on them and designed by completely different people). With a single exception they were all used to release well received AAA games.
None of that stuff actually matter at all in practice.
If anything, this is a perfect example of how little these things actually matter in the real world. This game alone sold over 2.5 million units and kickstarted one of the most popular franchises in gaming today.
I always have a feeling this type of comment must be necessarily written by someone who hasn't shipped anything of substance in the industry. It's trivial to point out irrelevant minutiae like this as opposed to having an in-depth discussion about the merits of the terrain rendering system or, you know, literally any of the hard problems the game is solving and that actually contribute to making it a technical success.
People who work on such projects tend to focus on finding solutions to difficult problems and many things that you would consider weird or bad could be there because they were part of a solution, either at the time or sometime in the past in a previous project.
It's weird to criticize all this stuff considering modern dev companies often have teams like 'billing' that have more people in them than the dozen or so developers who have built the entire video game (plus editor) from the ground up.
Maybe take game assets resize everything to 1/10th so that it looks like sht but can still be used as placeholder.
Would boost the pipeline of talent for the entire industry