Far Cry 1.34 source code (2006)
archive.org
archive.org
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
> 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?
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.
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.
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.
Maybe not, but we would have 100 other games that may have expanded the genre further.
You are over appreciating the geek's willingness to toil on assets and make up a compelling storyline :)
Not that Ubisoft games are worth playing, but for a single player game at least it can be much worse.
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).
And Chiral!
Man I'd love a Linux port of that 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!
Their game library had some gems but they famously made most of their ga my es by ripping off other games. I’m guessing that didn’t scale.
Their biggest seller was a small Mac utility called Snapz Pro if memory serves.
They, frankly, were never a company run for anything other than milking a quick buck.
That was one hell of a trip down the memory lane.
Also if you haven't played Endless Sky, that's inspired by EV and open source.
Releasing the old doom source code doesn't stop id software from making sequels all the way up to doom eternal.
According to Doom Eternal's wiki, it sold 3 million copies in spite of all these free to play doom games.
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.
Its still alive and kicking today as Falcon BMS.
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.
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.
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.
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.
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.
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.
People famous for optimization also know where it matters. Optimization obscures.
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.
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
Game engine development? Sure.
Game development using engine? 99% didn't change.
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.
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.
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.
Wouldn't the calling code be written (and thus copyrighted) by the company that wrote the game rather than the one that created the SDK?
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.
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.
> It could require a bit of creativity and some work but <...>
Honestly, you can stop there. This is why it's not done - the value is small, it requires creativity and work and...
> just be a one-time rename per function name + structure name + field name.
https://sgringwe.com/2019/10/10/Please-just-stop-saying-just.... In this particular case "what about legal" pretty much stops the "just" dead in it's tracks.
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.
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)
> This is not true.
You usually have to follow contracts you sign.
(Yes, I would argue that this is exempt following the ‘functional’ argument)
https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....
So of course you don't need to remove your lines of source code which call into an API.
[0] https://github.com/bulletphysics/bullet3/blob/master/example...
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.
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?
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.
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.
But last year I went to play HOMM3 online, and I imagined I could at least teach the kids a trick or two.
I was so wrong.
It's interesting watching playthroughs, and seeing the tricks used, but it's not quite the game I played 20 years ago.
I did pick up some positioning tricks and tips.
Edit: I stand corrected, it was Crytek and the CryEngine
AFAIK all development in Lumberyard has ceased and moved to O3DE.
The assets are commonly licensed, so you can't include them at all, or in large parts. Commonly the game data is not part of the release either.
As it is, the source is mostly just lost to time, making humanity poorer.
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.
https://www.reddit.com/r/dayz/comments/11nlu70/recently_dayz...
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).
Meanwhile, look at Unreal. Not even sold anymore.
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.
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)
https://hackaday.com/2023/02/16/arcaos-os-2-updated-for-the-...
I'm thinking mostly of anti competitive practices from Windows.
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 not that unusual for it to not even be wholly owned by a single entity due to licensing requirements.
You would more likely be amazed by all the dumb hacks in the system for backward compatibility, mostly for other companies' software.
https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34...
Also, Linux has a similar philosophy as Linus has eloquently described in the past. [1]
This is a myth which is mostly not true from some time.
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.
Not really dead because it’s still shipped with enterprise Edge for sites that enable IE mode: https://learn.microsoft.com/en-us/deployedge/edge-ie-mode
I’d be really surprised if Apple still had the source code and custom tools necessary to actually build the thing.
building it may be horrible, but the code would still be very interesting to hobbyists
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.
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.
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.
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.
The only problem might be the software patents that their code leverages.
Unless you mean that someone could see that you implemented their patent and retroactively go to sue them?
A patent is a method, not an implementation.
> The only problem might be the software patents that their code leverages.
We are talking about patents because Wengo brought it up and I was asking how they are applicable here.
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.
https://devblogs.microsoft.com/oldnewthing/20180515-00/?p=98...
Would add SGI's IRIX too!
They are working on a new one that I am somewhat suspicious of, but Winamp 5.9 has been a pleasant surprise.
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.
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.
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 computersAnecdotally, 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
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.
> 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.
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....
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.
Windows for example couldn't be made open source because of licensed, closed source code blocks.
It's a shame how many pieces of software are already totally lost forever.
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.
Smaller tech leaps in client-side game software is difficult to protect from instant duplicaton. The cloud and mobile is the 'last moat'.
Are we going to move into black box software designs and trusted platform modules in hardware to enforce a technology moat for devs on pc's?
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.
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.
(professional psychologist were strongly involved in the developement)
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.
There are just so many more games now that it might seem like that.
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.
And crysis 4 is coming.
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.
> 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).
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.
https://www.pcgamer.com/activision-is-making-more-money-on-p...
PC has been Ubisoft's second largest platform (ahead of Xbox but behind PlayStation) since 2018
https://www.statista.com/statistics/269679/breakdown-of-ubis...
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.
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.
$ grep -ir "remove this after e3" | wc -l
40The 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.
[1] I don't remember the name. It was so long ago that it was when I first got married, the first time!
And indeed at the end you were just pumping 500 rounds into unstoppable Doom-style monster deep inside some dark hallway.
Stopped gaming years ago but saw my cousin playing Far Cry 6 the other day and it looked better but not that much better. After 17 years. Crazy.
Far Cry 1 was a beautfiul game, absolutely, but the new iteration clearly does look a lot better than the original.
Looks like a lot of improvement to me.
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.
Dunno about "a lot". Certainly, it's improved in the area of modeling humans and faces, but landscape still looks pretty much the same.
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.
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.
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.
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.
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.
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.
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.
I played it a lot, hehe.
Coming out of the bunker was amazing and then the realization that it would be a guided tour because "Doyle" :|
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.
github.com/StrongPC123/Far-Cry-1-Source-Full
breachforums.vc/Thread-FarCry-1-Leaked-Source-Code
I guess it is interesting about github
Last I heard they were hosting Nintendo ROMs, in unarguable infringement of the copyrights.
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!”
What will come next, if it ever comes, it will be a game a whack-a-mole that the copyright owners have no chance of winning.
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.
FreeFarCry, with new assets à la Freedoom?
I wonder how it runs natively on a Raspberry Pi?
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.
If you have a closed source game and copyright expires then how does that affect the sources?
Do closed source games not require the sources to be released after copyright expires?
However, with copyright expiring 70 years after the death of the author(s), by the time copyright does expire, the sources will have disappeared.
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.
Maybe it's easier, if one uses the matching, old compiler version.
Someone could add raytracing maybe
- Multiple inheritance
- Over-abstraction
- Excessive identifier prefixing and suffixing
- Use of friend
- Use of bit fields instead of bools
- Inconsistent mixture of custom and built-in int types
- Direct storage of pointers instead of reference-counted containers
- Custom (and likely broken) _smart_ptr
- Cancerous coding style that adds too many lines
- Functions with 7+ arguments
- Lots and lots of duplicated code
- Inadequate use of const
- Inconsistent coding styles
- class name and base classes at the same indentation level
- Redundant prefixing of directories ~~and namespaces~~ with the name of the project
Edit: My bad, they don't use namespacing at all. It's a flat namespace. At least they don't using namespace std.
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.
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?
Overuse of reference counting is an anti-pattern and a performance killer.
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.
Only pontificating armchair field marshals giving their take of 'anti-patterns' in game engines built decades ago.
That game made millions. Went on to release multiple sequels after the first and still made millions.
Is your game engine making millions?
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.