Open Source Game Clones(osgameclones.com)
osgameclones.com
Open Source Game Clones
http://osgameclones.com/
79 comments
Looks great. Just out of curiosity why C# for the engine but Python for the tools? What strengths does each offer that lead to those choices vs doing the tools and the engine in the same language?
I love Python for file format manipulation, especially with my Struct.py library. Also, the tools themselves are largely derived from an older version of WebArena where the client was written in Coffeescript + Three.js.
That said, the tools are unbelievably slow and will be rewritten in C# once things are functionally complete. Python just allows for very, very rapid development of this sort of thing (for me).
That said, the tools are unbelievably slow and will be rewritten in C# once things are functionally complete. Python just allows for very, very rapid development of this sort of thing (for me).
Awesome! I wrote an MD3 loader/renderer/animator years ago[0] and had a lot of fun with it—always wanted to try loading the levels as well, though I've yet to try it. Any comment on how difficult that was in comparison to dealing with characters? I imagine you are pulling the data from WAD files (err.. does quake 3 still use those?), and static geometry is in a 3D BSP tree?
[0] http://symbolflux.com/statichtml/oldprojects/md3library.html (No source or anything available atm—just a screenshot and description, though I could up it up if anyone were interested.)
[0] http://symbolflux.com/statichtml/oldprojects/md3library.html (No source or anything available atm—just a screenshot and description, though I could up it up if anyone were interested.)
The actual level loading itself is stupid easy -- I had the geometry loading and rendering in something like two hours. The tough part is converting their "shader" model over to something that modern GPUs can understand. That took about a day and a half and still isn't entirely complete -- I'm missing environment mapping and vertex deformation.
MD3 has been pretty straightforward on the whole, but I didn't design my mesh abstraction super well out the gate, so I've mainly been redesigning that and trying to make it futureproof. I think I have it to about the minimum repeated code possible at this point, but I'm sure I'll reach some other snag down the road and have to refactor again!
MD3 has been pretty straightforward on the whole, but I didn't design my mesh abstraction super well out the gate, so I've mainly been redesigning that and trying to make it futureproof. I think I have it to about the minimum repeated code possible at this point, but I'm sure I'll reach some other snag down the road and have to refactor again!
Interesting—yes, I was wondering about their shader model. I glanced through your source and saw what looked to me like some of the conversion. In any case, the shaders you have running so far (I assume they generate the animations on various objects in the scene) look very nice :) Good luck with the project!
Awesome. Looks great.
This brings back memories. I wrote a MD2 loader for my final project in my 3d graphics elective in college years ago. It was a ton of fun. Quake 3 came out my freshman year, the format wasn't very well documented yet but MD2 had tons of documentation.
Can't comment to how much easier / harder level loading would be but I'd venture to say probably much easier. Characters have more animation and such along with them.
This brings back memories. I wrote a MD2 loader for my final project in my 3d graphics elective in college years ago. It was a ton of fun. Quake 3 came out my freshman year, the format wasn't very well documented yet but MD2 had tons of documentation.
Can't comment to how much easier / harder level loading would be but I'd venture to say probably much easier. Characters have more animation and such along with them.
Thanks! That's funny, Doom 3 was just coming out when I was in college and I had the same issue when considering doing something with MD5s—and they also just appeared super intimidating to me at the time :)
hmm it breaks on Chrome on mac os:
System.Exception: TypeError: Cannot read property 'viewport' of null at ctor.Resize (http://demoseen.com/bridge/WebArena.js:180:37) at new ctor (http://demoseen.com/bridge/WebArena.js:158:22) at Function.Main (http://demoseen.com/bridge/WebArena.js:119:13) at http://demoseen.com/bridge/bridge.js:2973:39 at HTMLDocument.delayfn (http://demoseen.com/bridge/bridge.js:481:21) at HTMLDocument.listenHandler (http://demoseen.com/bridge/bridge.js:498:30)
System.Exception: TypeError: Cannot read property 'viewport' of null at ctor.Resize (http://demoseen.com/bridge/WebArena.js:180:37) at new ctor (http://demoseen.com/bridge/WebArena.js:158:22) at Function.Main (http://demoseen.com/bridge/WebArena.js:119:13) at http://demoseen.com/bridge/bridge.js:2973:39 at HTMLDocument.delayfn (http://demoseen.com/bridge/bridge.js:481:21) at HTMLDocument.listenHandler (http://demoseen.com/bridge/bridge.js:498:30)
Check for browser extensions|plugins that might be prevent "fingerprinting". These plugins often disable WebGL support by default.
Looks like it's not getting a WebGL context. Perhaps your setup doesn't support it?
Good on you! 60 FPS and looks terrific.
From 10 years ago, how they did the (mostly automated) managed port of Quake II :)
https://gregs-blog.com/category/quake-2-c-net-port/
From 10 years ago, how they did the (mostly automated) managed port of Quake II :)
https://gregs-blog.com/category/quake-2-c-net-port/
Really cool stuff, seeing that level brings back some pretty powerful memories.
Didn't know about Bridge.NET. That's way cool, how is it from a development perspective?
Didn't know about Bridge.NET. That's way cool, how is it from a development perspective?
I am absolutely loving Bridge.NET so far. There are some mild rough edges and it doesn't support C# 7 syntax yet, but I went from never having used it to having built a simple 3d engine in a matter of a couple hours. I consider that a big win.
C#7 support is coming soon to Bridge. Several features like Local Functions are done, just not in the master branch yet.
I will weep tears of joy when Bridge.NET supports destructuring. That will be so, so nice!
It would actually be really cool if games officially adopted this kind of engine-based model that we see in some of the examples, where the "engine" would be FOSS (meaning it can be ported, modded, improved, etc.), and the "game" that is sold is the compiled binary blob graphics, assets, scripts, etc.
In short, I guess it would basically be like selling RPG Maker games or DOOM wad's, but without the engine itself being proprietary.
In short, I guess it would basically be like selling RPG Maker games or DOOM wad's, but without the engine itself being proprietary.
KeeperRL is a game being developed and sold in that model! It's both on Steam (where I bought it), and on Itch.io (which seems to be the thing, for indie games now..?) and on Github -- same thing, full open source. If you buy it, you're essentially buying the build/bundle/autoupdate conveniences, and I think some assets; if you build it from source, you've got the same essential product.
Mind, this is a game, not an "engine". And I'm okay with that; building an "engine" rather than building an actual game is something that we OSS nerds are already prone to self-nerdsniping on, and the resulting engine-with-no-game doesn't really help anyone (including, typically, other game makers, because without a single trial-by-fire, that "engine" code tends to be pretty useless). It's good that it's OSS, even if (and especially if?) it's not an "engine".
- http://keeperrl.com/
- http://store.steampowered.com/app/329970
- https://miki151.itch.io/keeperrl
- https://github.com/miki151/keeperrl
Mind, this is a game, not an "engine". And I'm okay with that; building an "engine" rather than building an actual game is something that we OSS nerds are already prone to self-nerdsniping on, and the resulting engine-with-no-game doesn't really help anyone (including, typically, other game makers, because without a single trial-by-fire, that "engine" code tends to be pretty useless). It's good that it's OSS, even if (and especially if?) it's not an "engine".
I've heard a couple of good things about Godot [0]. However, I couldn't tell you any titles that use it without looking it up.
Perhaps there is no standard engine in the FOSS world because the engines are not advertised as strongly as the most popular commercial ones. Unity, after all, will gladly let you know it's being used whenever the game starts.
[0] https://godotengine.org/
Perhaps there is no standard engine in the FOSS world because the engines are not advertised as strongly as the most popular commercial ones. Unity, after all, will gladly let you know it's being used whenever the game starts.
[0] https://godotengine.org/
I had been hacking the open source quake 3 engine while in the community of Urban Terror, a closed source game on top of it. I believe a problem that studios would face with what you are suggesting is that there is still a lot you can control at the low level, ranging from cheats to game behavior.
PS. Of course one could claim you can never be certain of those (hacking disassembled code is always an option) but in any way you look at it, if you do have the resources to have your own engine you retain more control.
PS. Of course one could claim you can never be certain of those (hacking disassembled code is always an option) but in any way you look at it, if you do have the resources to have your own engine you retain more control.
Isn't UE reasonably close to that already for most practical, if not ideological purposes?
But that only works if Unity open sources the engine. A ubiquitous engine is not the same as an open engine. The fact that we now have jDoom, Doomsday, and other enhancements to the engine that let us play Doom, Doom2, Hexen, Heretic, etc. only work because id software released the source code. Otherwise, it would be like any other proprietary engine, and we'd have to reverse-engineer it if we want to be able to play those games again.
I'm sure you could argue that Unity is currently more cross-platform than engines were 10-20 years ago and already works on Mac/Win/Linux/Android/whatever, but we can't guarantee it will be around in 20 years.
I'm sure you could argue that Unity is currently more cross-platform than engines were 10-20 years ago and already works on Mac/Win/Linux/Android/whatever, but we can't guarantee it will be around in 20 years.
UE is Unreal Engine, not Unity. Presumably Unreal Engine 4, which gives full source access to anyone who agrees to their EULA and takes patches through GitHub.
[deleted]
I think he meant Unreal Engine, which isn't strictly open source but you get access with a monthly fee
There is no monthly fee, they take a % of revenue of whatever game you sell.
Oh I meant Unreal, not Unity, should have spelled it out. Unreal source is available.
This is why acronyms should be avoided on the internet, unless they are unambiguously unique or presumably understood by any reader.
ZOMG, no, IMHO. More seriously, 'UE' is a pretty standard abbreviation in the context. But yes, typing it out would have been better. lol.
Don't people usually end making changes to the Unreal Engine executable and tie their game to it? As far as I know, it's not possible for me to take the Unreal Engine source code, compile it possibly with modifications, and play arbitrary Unreal Engine games with it (like say Gears of War 4).
Considering that ideology often comes from practical considerations and that the practical consideration in UE's licensing is that you are still bound to Epic and unable take the code and run with it, then i'd say that no, it isn't reasonably close.
unable take the code and run with it
There are really very few practical limits there. You can distribute a game with a modified engine. But what the poster was talking about was a common engine with source that will be around for a long time. UE sounds like a fairly close match. Maybe they had something else in mind but 'the ideological is the practical and vice versa so this ain't nothing' seems more like some sort of odd logical (ideological?) contortion than an argument.
There are really very few practical limits there. You can distribute a game with a modified engine. But what the poster was talking about was a common engine with source that will be around for a long time. UE sounds like a fairly close match. Maybe they had something else in mind but 'the ideological is the practical and vice versa so this ain't nothing' seems more like some sort of odd logical (ideological?) contortion than an argument.
There is the very practical limit of having to pay Epic if what you make with it happens to make you money above some arbitrary point. This introduces additional overhead to your finances - you may think it is justified, but it is still a limit.
Another very practical limit is that you can only distribute changes to the engine through either Epic's marketplace or a fork of their GitHub (so you cannot distribute changes through your own website, for example).
Also you cannot make a modification to the engine itself (even through the "allowed" means) and distribute it yourself as an alternative version/fork of the engine.
Finally, yet another very practical limit, is that you cannot take source code out of the engine for use in other engines and products - no matter what.
All these are practical - not ideological - issues that proper open source projects do not have. Unreal Engine is not open source, you just have access to the engine's source code for minor and project-specific modifications and even that comes with several limitations as i already mentioned above (and there are others tool, just read the engine's EULA).
Another very practical limit is that you can only distribute changes to the engine through either Epic's marketplace or a fork of their GitHub (so you cannot distribute changes through your own website, for example).
Also you cannot make a modification to the engine itself (even through the "allowed" means) and distribute it yourself as an alternative version/fork of the engine.
Finally, yet another very practical limit, is that you cannot take source code out of the engine for use in other engines and products - no matter what.
All these are practical - not ideological - issues that proper open source projects do not have. Unreal Engine is not open source, you just have access to the engine's source code for minor and project-specific modifications and even that comes with several limitations as i already mentioned above (and there are others tool, just read the engine's EULA).
You missed the best clone of them all :P
https://github.com/raxod502/TerrariaClone
Oh... oh my Gosh..... it's full of... he globally declared his LOOP INDEXING VARIABLES?!
I really appreciate him making that available, fantastic little cautionary tale, clearly from an enthusiastic and thoughtful learner of Java - glad he's made good progress since then, though, that's... I mean, dang it is REALLY bad, but it is also amazing as a sort of exercise in him just knowing what he wants to do and finding (bad) ways to make it happen. And that's admirable, even if it is also horrifying to see unfold. :D
I really appreciate him making that available, fantastic little cautionary tale, clearly from an enthusiastic and thoughtful learner of Java - glad he's made good progress since then, though, that's... I mean, dang it is REALLY bad, but it is also amazing as a sort of exercise in him just knowing what he wants to do and finding (bad) ways to make it happen. And that's admirable, even if it is also horrifying to see unfold. :D
Just submit a PR to https://github.com/piranha/osgameclones/
This is an awesome list.
I know there are many programmers that spend long hours recreating games they like in open source. But are there artists doing the same? It would be great if many of these projects that require a copy of the original game for the assets could get contributions from artists willing to make open source skins / texture packs as well.
I know there are many programmers that spend long hours recreating games they like in open source. But are there artists doing the same? It would be great if many of these projects that require a copy of the original game for the assets could get contributions from artists willing to make open source skins / texture packs as well.
Those projects are good, but I think it is a bit sad, that the open source movement allmost only manages to produce clones of games and not a new one. Well, let's see, if I can change that one day ... lot's of ideas, but not the time, nor money at the moment. Common problem, I suppose ;)
To be fair, creating a new game that's good takes a lot more talent across a lot more domains of expertise than your average FOSS hacker might appreciate. The code is just one part of it - you've got art, music, level design, story possibly, it can be as complicated as making a movie.
Cloning an existing game is easier.
Cloning an existing game is easier.
If people want to try their hand at it, I recommend them to try to participate in game jam warm-ups, such as MiniLD[0] for Ludum Dare. Getting your feet wet gives quite some hint at the scope of things you have to handle.
[0]: http://ludumdare.com/compo/minild/
[0]: http://ludumdare.com/compo/minild/
I recently discovered Argentum Age, a high-quality, fully open-source game that is certainly inspired by other games, but also feels quite novel in many ways. My understanding is that it has some of the same folks that have worked on Battle for Wesnoth, so I have every confidence that the team can execute on their vision.
http://argentumage.com/
http://argentumage.com/
Game design is a broad study and difficult to do well. Programming a game based on an existing design is the easy part.
This is an amazing list; thanks a lot for sharing! Here is a link to the underlying github repo where people can contribute to that list: https://github.com/piranha/osgameclones/
There's this best game ever, Master of Magic, which countless people tried to rewrite over but nobody ever got anywhere. Even in this list.
Of these, Star Control (Ur-Quan Masters) is also one of the best games with tear-dropping story which I also recommend highly. The open-source port is of excellent quality.
Of these, Star Control (Ur-Quan Masters) is also one of the best games with tear-dropping story which I also recommend highly. The open-source port is of excellent quality.
This is a good example of when a site with a lot of images would actually be helpful - I could use some thumbnails!
('go submit a pr then')
I didn't know that Allegiance was switched to an MIT license from Shared Source, that's awesome! I've not been running Windows natively on a computer for some years now, and I kinda miss playing Free Allegiance with easily 200 players in a single game, so hopefully under the new license it's more likely to be ported off of Direct3D, and then perhaps off of Windows dependence. I'm probably not going to be the one to do it though, so maybe it'll never happen.
Great list!
If we were to start an archival project to preserve some of these classics for posterity, it seems there are a couple of techniques. Internet Archive's strategy of collecting (public domain?) ROMs and exposing via JSMAME. Use an open clone as reference and then port again to WebGL. Or for games ported to SDL perhaps re-compile via Emscripten to Javascript.
HTML5 and browsers are becoming performant enough. Is there some other portable emulator that might be a better target?
If we were to start an archival project to preserve some of these classics for posterity, it seems there are a couple of techniques. Internet Archive's strategy of collecting (public domain?) ROMs and exposing via JSMAME. Use an open clone as reference and then port again to WebGL. Or for games ported to SDL perhaps re-compile via Emscripten to Javascript.
HTML5 and browsers are becoming performant enough. Is there some other portable emulator that might be a better target?
libretro is pretty cool: https://www.libretro.com/index.php/mission/
I should submit https://spacewar.pro as a clone of DOS SPACEWAR
Really nice, but out of date it seems. A lot of the links don't work and sometimes good alternatives aren't mentioned.
There’s one engine missing in that list, and it’s pretty advanced:
http://fte.triptohell.info
Supports a lot of the Quake based games (started out as a QW engine but is much more today).
Had Vulkan support way earlier than vkQuake came to be. Spike, the basically single developer behind it is really talented.
http://fte.triptohell.info
Supports a lot of the Quake based games (started out as a QW engine but is much more today).
Had Vulkan support way earlier than vkQuake came to be. Spike, the basically single developer behind it is really talented.
I'd like to see an open, multiplatform clone of Subspace.
We've had a reverse-engineered server for some time: https://bitbucket.org/grelminar/asss
We've had a reverse-engineered server for some time: https://bitbucket.org/grelminar/asss
RTTR for a Settlers II remake is really good (but requires original graphics files).
If you didn't play it, and are into puzzle games, I strongly recommend you to try the Pushover reimplementation. I loved that one back in the DOS times, and the free clone contains may additional levels.
How do I know which of these could be played in Ubuntu?
I'd love it if someone made a Visual Studio Solution that correctly built as many of these as possible.
I stumbled upon this when searching for examples of successful open source games. Great list, thanks for this.
It's always seemed funny to me that there aren't a million Fantavision clones.
You include several clones built on Unity. These are not open source.
Is a game "not open source" if all the business-logic code and game assets are open-source, but it relies on a closed-source engine (that it doesn't ship with)?
Doesn't seem much different to me to e.g. writing an open-source game that uses DirectX. DirectX is not, itself, open-source, but it's not really "part of" the game. The game just uses its API; and could equivalently use anything else with the same API (like the DirectX implementation in Wine.)
Doesn't seem much different to me to e.g. writing an open-source game that uses DirectX. DirectX is not, itself, open-source, but it's not really "part of" the game. The game just uses its API; and could equivalently use anything else with the same API (like the DirectX implementation in Wine.)
>Is a game "not open source" if all the business-logic code and game assets are open-source, but it relies on a closed-source engine (that it doesn't ship with)?
Depending on a closed-source engine at all by definition makes the game not open source, when you consider "the game" from both a developer and user point of view.
Depending on a closed-source engine at all by definition makes the game not open source, when you consider "the game" from both a developer and user point of view.
This is (was?) called the Java Trap: https://www.gnu.org/philosophy/java-trap.html
If some of a program's dependencies are nonfree, this means that all
or part of the program is unable to run in an entirely free system—it
is unusable in the Free World. Sure, we could redistribute the program
and have copies on our machines, but that's not much good if it won't
run. That program is free software, but it is effectively shackled by
its nonfree dependencies.A purist would say that an open source game should use OpenGL. But I generally agree. Unity is free to download so there is no monetary barrier to compiling these games. So it's not free from a GNU sense of the word but it is free money wise and the gameplay parts are open source.
The trick is that since Unity itself is not permissively redistributable, the ability for the game to work depends on both Unity the corporation continuing to provide its proprietary part and to make it available under terms allowing games to be compiled with it.
I would consider neither Unity nor Unreal capable of producing free software titles because there is no way to get the engine parts without some barrier. It may not be monetary, but you still need to agree to EULAs for both engines, despite the later being nicer since it also includes source access.
An open source game does not, however, need to start from scratch (which saying OpenGL seems to imply). There are both legacy code bases like doom3 or free engines like Godot that let you build off them rather than reinventing all of the extremely complex and sizable code required to even start making a video game.
It is just you cannot have open code that is then tied to a proprietary part unless that proprietary bit has liberal distribution rights (and I don't mean just the game lib you ship, you need to be able to recompile the project with changes which almost always means you need the game editor). I'm not aware of any proprietary engines that give away all the tooling under permissive terms that would fit that scenario, though.
I would consider neither Unity nor Unreal capable of producing free software titles because there is no way to get the engine parts without some barrier. It may not be monetary, but you still need to agree to EULAs for both engines, despite the later being nicer since it also includes source access.
An open source game does not, however, need to start from scratch (which saying OpenGL seems to imply). There are both legacy code bases like doom3 or free engines like Godot that let you build off them rather than reinventing all of the extremely complex and sizable code required to even start making a video game.
It is just you cannot have open code that is then tied to a proprietary part unless that proprietary bit has liberal distribution rights (and I don't mean just the game lib you ship, you need to be able to recompile the project with changes which almost always means you need the game editor). I'm not aware of any proprietary engines that give away all the tooling under permissive terms that would fit that scenario, though.
Open source does not imply the definition of free as defined by GNU / the Free Software Foundation. I explicitly said it was not "free" in terms of the GNU definition. You are agreeing with me here.
Also, I used OpenGL in my example because the parent post used DirectX. I also agree with you that they don't need to start from scratch, despite what you said, I did not imply they did. I was simply replying directly to the parent reference to DirectX.
Also, I used OpenGL in my example because the parent post used DirectX. I also agree with you that they don't need to start from scratch, despite what you said, I did not imply they did. I was simply replying directly to the parent reference to DirectX.
That's not even so much what I meant. The "game" isn't the engine; and so the "game" is open source. You're free to modify and redistribute everything that constitutes the game. To play the game, you need the game engine, similar to how running a program requires a machine (real or virtual) with a compatible ISA. But there's nothing forcing you to use a closed-source implementation of the game engine. If an open-source implementation of the engine doesn't exist, you're always free to write one.
Nobody ever says that a program being written for closed-source hardware necessarily implies that the program can't be open source. Because, of course, you can just write your own open VM for that same hardware. Saying that e.g. Gameboy Advance home-brew is all closed source, because the reference implementation of the hardware is closed source, is nonsensical. People are free to write, modify, and run GBA home-brew. Doing the last one just requires an emulator for most people, which is an everyday tool for programmers (given that many languages target abstract machines like the JVM or Erlang's BEAM, where the resulting bytecode ISA is only reified as an emulator.)
Nobody ever says that a program being written for closed-source hardware necessarily implies that the program can't be open source. Because, of course, you can just write your own open VM for that same hardware. Saying that e.g. Gameboy Advance home-brew is all closed source, because the reference implementation of the hardware is closed source, is nonsensical. People are free to write, modify, and run GBA home-brew. Doing the last one just requires an emulator for most people, which is an everyday tool for programmers (given that many languages target abstract machines like the JVM or Erlang's BEAM, where the resulting bytecode ISA is only reified as an emulator.)
I think it's dishonest and unexpected to consider the engine to not be part of the game. When I buy a game, I expect that it comes with an engine, in addition to the art and the business logic. I buy with the expectation that it'll run on the stated hardware platform, e.g. Windows and some specific version of DirectX.
In that particular case, DirectX is a set of APIs provided by the OS vendor to develop games on their OS. It's part of Microsoft's platform.
In the GBA's case, Nintendo's platform is the hardware and their SDK. If I'm remembering correctly, there's an open SDK to replace Nintendo's, because the latter isn't (legally) available to homebrewers. But, the libraries linked from the SDK are universally distributed with the game. If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
Going another direction, with a specific example: The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format. Just have to write the engine, right?
In that particular case, DirectX is a set of APIs provided by the OS vendor to develop games on their OS. It's part of Microsoft's platform.
In the GBA's case, Nintendo's platform is the hardware and their SDK. If I'm remembering correctly, there's an open SDK to replace Nintendo's, because the latter isn't (legally) available to homebrewers. But, the libraries linked from the SDK are universally distributed with the game. If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
Going another direction, with a specific example: The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format. Just have to write the engine, right?
> If someone wrote homebrew on the Nintendo SDK, I'd say it's impossible for it to be "open", because not everything that is distributed as part of the game is open.
I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
Consider, as a contrasting example, C#. Microsoft's official SDK is closed source. Mono is open-source. But Mono's runtime libraries are ABI-compatible with the official runtime libraries.
In the case of the GBA, you'd expect/require a binary release to be "shipped with" the official runtime libraries linked in. But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
> The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format.
I would say that this is open-source, yes. Consider the case where someone uploaded, say, the "business logic" (and assets) of an RPG Maker game, back when ASCII/Enterbrain's own runtime was the only one available. Now there are plenty of open, ABI-compatible interpreters. So this is at least open-source code now, no?
Or, for another example, consider original-Doom .wad files. If you released one of those back in 1993 under a GPL license, it might not mean much—but today there are open DOOM clones for literally everything. One difference here is that those interpreters don't have Doom's original IP (asset packs) included in them; they expect you to add them in. But does that make the .wad file itself less open as a product? Not everything needs to be standalone. You could have an open-source expansion or mod for a closed-source game. You can interpret a level or level-pack in just such a manner.
I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
Consider, as a contrasting example, C#. Microsoft's official SDK is closed source. Mono is open-source. But Mono's runtime libraries are ABI-compatible with the official runtime libraries.
In the case of the GBA, you'd expect/require a binary release to be "shipped with" the official runtime libraries linked in. But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
> The entire "business logic" of the game Dark Forces: Jedi Knight II is available as source. Literally, human-readable scripts packaged in a trivial archive format.
I would say that this is open-source, yes. Consider the case where someone uploaded, say, the "business logic" (and assets) of an RPG Maker game, back when ASCII/Enterbrain's own runtime was the only one available. Now there are plenty of open, ABI-compatible interpreters. So this is at least open-source code now, no?
Or, for another example, consider original-Doom .wad files. If you released one of those back in 1993 under a GPL license, it might not mean much—but today there are open DOOM clones for literally everything. One difference here is that those interpreters don't have Doom's original IP (asset packs) included in them; they expect you to add them in. But does that make the .wad file itself less open as a product? Not everything needs to be standalone. You could have an open-source expansion or mod for a closed-source game. You can interpret a level or level-pack in just such a manner.
> I think this comes down to a particular design decision of the GBA homebrew SDK (https://github.com/devkitPro/libgba) to not be ABI-compatible with the official SDK.
I think it comes down to the fact of SDK libraries being statically, and inextricably, linked into the ROM.
> [about DF2:JK] I would say that this is open-source, yes.
I'd say it isn't. First, the license is just as closed as the rest of the code. Second, it's not "the game" unless there's an engine to pair the data+code elements with. And since there's no open engine to go with the closed-but-readable code, I wouldn't use the words "open source" with any part of it.
> So this is at least open-source code now, no?
If an open engine is available, then the combination of the open game logic and open game engine would be open. Otherwise you could say "An Open engine for X" or...well, a nicely-packaged way to describe open game assets on a closed engine would be called "a mod for X" or a "total conversion", I suppose.
> But does that make the .wad file itself less open as a product?
The .wad itself could be open, but it's not "a game". It's a set of game assets. Pair it with an engine, and it's a game. Pair it with a different engine, and the same assets might be a significantly different game. The whole wad+engine game couldn't be open until at least late 1997 when the Doom source was released.
> But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
Right. C#, Java, etc are expected to have an external, completely separate runtime as a dependency. When there isn't an open runtime available, it's the situation that used to be called something like "the Java trap".
I think it comes down to the fact of SDK libraries being statically, and inextricably, linked into the ROM.
> [about DF2:JK] I would say that this is open-source, yes.
I'd say it isn't. First, the license is just as closed as the rest of the code. Second, it's not "the game" unless there's an engine to pair the data+code elements with. And since there's no open engine to go with the closed-but-readable code, I wouldn't use the words "open source" with any part of it.
> So this is at least open-source code now, no?
If an open engine is available, then the combination of the open game logic and open game engine would be open. Otherwise you could say "An Open engine for X" or...well, a nicely-packaged way to describe open game assets on a closed engine would be called "a mod for X" or a "total conversion", I suppose.
> But does that make the .wad file itself less open as a product?
The .wad itself could be open, but it's not "a game". It's a set of game assets. Pair it with an engine, and it's a game. Pair it with a different engine, and the same assets might be a significantly different game. The whole wad+engine game couldn't be open until at least late 1997 when the Doom source was released.
> But with C#, you don't expect that; you just expect to receive the binary containing the individual business logic, and then use the runtime library you have available (Microsoft's on Windows; Mono everywhere else) to run it.
Right. C#, Java, etc are expected to have an external, completely separate runtime as a dependency. When there isn't an open runtime available, it's the situation that used to be called something like "the Java trap".
> If an open-source implementation of the engine doesn't exist, you're always free to write one.
This is a very strange interpretation.
When a piece of software that is released under a free license has a crucial non-free dependency, it is effectively non-free. As the software only works with the non-free dependency, but that dependency cannot be conveyed along with the free part, the whole thing cannot legally be distributed and thus is non-free.
This is a very strange interpretation.
When a piece of software that is released under a free license has a crucial non-free dependency, it is effectively non-free. As the software only works with the non-free dependency, but that dependency cannot be conveyed along with the free part, the whole thing cannot legally be distributed and thus is non-free.
The reason I take that view, is that the ability to use the software isn't actually a part of what makes software open source! As long as people have all the code, and can modify it, and can redistribute their modifications, the code is open-source... whether or not you can run it.
Consider: there are also hardware platforms that have effectively ceased to exist over the years. If you wrote a program for one of these platforms, and it was open-source, would you now consider the program closed-source, because—given that the platform hardware doesn't exist any more—you can't run the software any more?
No. Why not? Because open source is about the source, not about the binary. The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
Consider: there are also hardware platforms that have effectively ceased to exist over the years. If you wrote a program for one of these platforms, and it was open-source, would you now consider the program closed-source, because—given that the platform hardware doesn't exist any more—you can't run the software any more?
No. Why not? Because open source is about the source, not about the binary. The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
> Why not? Because open source is about the source, not about the binary.
If you have the platform and the source, but you can't run the program, then I wouldn't consider it "open source". At least not in the usual sense of FOSS. It's not just about the source; it's about the freedom to study and modify the source, produce improved versions of the original binary, and distribute that binary and the source that created it.
The division between game and platform is lower in the stack than the engine.
> The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
I agree with that statement, but it's a different argument than you were making before.
If you have the platform and the source, but you can't run the program, then I wouldn't consider it "open source". At least not in the usual sense of FOSS. It's not just about the source; it's about the freedom to study and modify the source, produce improved versions of the original binary, and distribute that binary and the source that created it.
The division between game and platform is lower in the stack than the engine.
> The source is a product in its own right, and valuable in its own right, whether or not it can be compiled into a working program.
I agree with that statement, but it's a different argument than you were making before.
And you won't get far with source modifications if you can't run the program.
That would make all GPL-licensed Windows software non-free. Not even the FSF thinks that's the case.
Still a ton to do, but I'm really digging it.
Edit to add: WASD + Space/Shift + arrows to control the camera.