Hacker News new | past | comments | ask | show | jobs | submit login
Open Source Game Clones (osgameclones.com)
121 points by adamnemecek on Aug 15, 2014 | hide | past | favorite | 28 comments



I understand why publishers don't freely license their game engines (e.g., under the GPL): if users and the gaming community had the ability to modify the games they purchased and create their own content, companies wouldn't be able to get away with selling horse armor DLC, releasing yearly rehashes of the same game, locking purchasers out of their own games with DRM, or sabotaging their own games ( http://www.tweaktown.com/articles/6450/ubisoft-gimping-watch... ). I don't see any merit in the "stopping piracy" routine you might hear; DRM has never done anything to prevent unauthorized sharing on PC, and art assets aren't any easier or harder to share if the engines are free software. Proprietary software is purely an instrument of control by the publishers over the users in order to keep short-term profits high, even if it means mistreating the customer.

But why don't we see more companies following in id's footsteps and re-licensing old engines as free software? It keeps interest high and people coming back to purchase the art assets needed to run the games. There are several games on Steam that continue to sell well under this model (e.g., Duke Nukem 3D, Doom 3)


In short: it would be a legal mess. Most inhouse game engines have a lot of dependencies on closed-source code, mostly 3rd party specialized engines for AI, path-finding, physics, loaders for asset management code, or code that talks to the game console SDKs. Even releasing code which only calls into those closed source libs might be illegal. And even if that would be possible you would need (commercial) licenses for each of those 3rd party libs if you want to compile the engine code yourself. Also, by releasing the code you're inviting patent trolls to harvest your code for patent violations. Hardening a big inhouse engine for an open source release is easily just as much work as creating the thing in the first place.

[edit: typos]


I mean, how many engines are there, actually? Also, how many of them have source that hasn't been lost to the mists of time?

One of the big issues, for example, is that engines may contain tech that isn't easily stripped out--Source, for example, has bits (I believe) from Miles Audio and also from Havok, and as such they can't just go handing out their code without fixing those licensing concerns.


Now this might sound like a rude and blunt answer but it's true - it's because most of those other engines suck.

This is coming from game dev trenches. :)


That doesn't really make a difference though, does it? The community has shown at every opportunity that it loves being able to hack with game software. A small group of volunteers has even completely rebuilt Morrowind from SCRATCH! Even if the original code sucks, I think people would love to be able to hack it, port it, and play with it. This sort of activity can only lead to increased sales for original publisher, who otherwise would never get anything after their game falls into obscurity.


I'm not saying it wouldn't be (probably) better if they did release it but that the fact that they do not isn't surprising.


I didn't understand this response. Are you saying the company doesn't release it because the developers are embarrassed of the quality of the code in the engine?


Well, hold on - that's oversimplifying. Some developers do things like that, and some don't. Valve is an extreme example, but:

- They publish a free (as in beer) SDK and modding tools for Source, and allow people to submit mods to Steam - even if they use Valve IP, and charge users money for it (e.g. Aperture Tag). (However, users have to have purchased the original game to run mods, and removing this limitation or accessing the Source source code requires a commercial license.)

- They have the Steam Workshop, which allows users to, depending on the game, submit assets for potential inclusion in Valve games (with revenue share), and upload custom maps for others to use directly.

- They have released specialized tools such as Source Filmmaker and the Portal 2 map maker to assist with user-generated content.

- And, of course, many of their flagship games were originally community mods: Team Fortress, Counter-Strike, DotA.

...Thus it's hard to say Valve wants to "mistreat the customer" or doesn't want users to create their own content. Nor do they indulge that much in DRM. Yet thus far, they have not released any free software. Why?

I think it's mainly a culture thing. Free software games are essentially nonexistent. In PC gaming there are plenty of small developers, and lately there's a trend toward very early release and community engagement, all things associated with free software - but it's all in a context where developers can and want to make money selling games, and source access is not expected. This is nothing unusual, of course: in all of programming there are many, probably a majority, who are more likely to consider GPL a "cancer" preventing them from doing what they want than something to embrace. (In mobile this is basically everyone.) It's just that the pockets of free software enthusiasm which exist in other subfields aren't nearly as significant in gaming. In such a context, GPL releases would just be a distraction from supporting users/indies in the way they want, and so we don't see them.

I'm still holding out for a GPL release of Source 2, though... And, as a point of hope: while the new Unreal Engine is not free software, its licensing and development model seems very much inspired by it, and to be designed to provide some of its benefits while allowing Epic to make money.


er, just sayin..gpl might not be necessary? paradox's ck2 and many of bethesda's games are much modded(er, i dont play fps, but i think there are many 'source mods' on desura?), but not gpl? i think they all have drm, yet manage to sell some dlc? so er, the comparison is not as clean as foss vs proprietary?


As a game developer I see the GPL as something I don't want to deal with.

Game engines licensed as MIT? Yes please.


As a gamer, I see games that cost money as something I don't want to deal with.

Games that are given to me for free? Yes Please.


That's good, and there are plenty of them for you to play. The more the merrier.

But doing my own game means a lot of actual work, and I can and should be able to choose the license of that work.

GPL takes away that choice from me.


As a developer, you have the same right to choose license as the right a gamer has to choose the price of games. Every time a game is not a GOG-pay-what-you-want, you are violating this right of mine!

Alternative, you might simply not like the fact that people are giving you something for free and then ask you to not put restrictions on it. Its like when someone give to charity and they ask that money sent to starving children do not get spent on booze and guns. Its immoral and wrong, but hey, everyone is free to their opinion.


The “freedom” to choose a license is in reality the right to have power over other people:

https://www.gnu.org/philosophy/freedom-or-power.html


Should point out that OpenTTD is also an excellent open source engine for Transport Tycoon, fixing many quirks and irritations in the original game.

It's not truly open source because it requires the original files, but then they've listed emulators for ScummVM and the Infinity engine, so I don't see the difference.


>It's not truly open source because it requires the original files

It hasn't for a while, since 1.0 - they have their own graphics and sound assets now.


> It's not truly open source because it requires the original files,

Art assets are not software, if that's what you're talking about. Character design, dialogue, plotlines, etc. will remain under copyright even if you do go in and replace every image and sound with freely licensed art.


The Debian project believes things like art and sound files and documentation are software. The FSF does not.


I know the Debian project only officially supports art assets that are in the public domain or licensed under a Creative Commons style license, but I can't imagine they actually consider these things software. Can you show me where they call these things software? Because if that's true, I find that use of terminology to be quite ridiculous.

Stallman thinks all users should be able to share and remix artwork freely, btw.


Sorry for disappearing for a couple days.

I'm well aware of Stallman's subtle and well developed stance with respect to human freedom and software, art, and documentation and I think it's perfectly consistent and reasonable.

The Debian project has adopted a stance that everything distributed as a part of the project should come with a set of rights, whether it's executable programs, game textures, or documentation.

Every part of Debian must conform to the Debian Free Software Guidelines, even if it's just a text document describing a library. So text files are considered software in Debian for purposes of the DFSG. That's all I was implying by saying that Debian considers non-executable parts of a project to be software.


I would say that AM2R deserves to be on this list (it's a remake of Metroid 2): http://metroid2remake.blogspot.com/p/about-project.html


Is it open source though? I agree it's a terrific game (I was really impressed by DragonDarch's speedrun back in April/May for a Metroid marathon), but I can't find a link to get the code and build it myself.



Recent addition of The Neverhood to ScummVM is a great release.


I still listen to Terry S. Taylor's soundtrack to it on basically a regular basis.


Same here ;)


Then you upvote! Like I did!


(Originally) open source games seem to be a lot less popular than their commercial counterparts. I wonder if there is any systematic reason for why this might be true, or if it's just a matter of the different ways in which their creators invest effort in their creations.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: