Build Doom3 on MacOSX with XCode4
fabiensanglard.net
fabiensanglard.net
Also, instead of forking it on GitHub, he just reuploaded the whole thing again (https://github.com/fabiensanglard/Doom3-for-MacOSX-) so that others cannot easily merge these changes. And neither in his repo nor in his post, there is a reference to the original repo (https://github.com/TTimo/doom3.gpl).
Also, on the original repo, there were already a few fixes for Xcode4 and there is also a pull request with further fixes (https://github.com/TTimo/doom3.gpl/pull/13). I haven't checked it myself but it might actually work already.
Btw., further development is probably going on here: http://www.iodoom3.org/ (http://news.ycombinator.com/item?id=3277150) (https://github.com/TimeDoctor/iodoom3)
git remote add d3mac https://github.com/fabiensanglard/Doom3-for-MacOSX-.git
git fetch d3mac
git merge d3mac/master $ git fetch d3mac
warning: no common commits
$ git merge d3mac/master
[ many many conflicts ... ]
CONFLICT (add/add): Merge conflict in neo/ui/Winvar.h
Automatic merge failed; fix conflicts and then commit the result.https://github.com/uxp/doom3.gpl
Just like his concern, I haven't tested building this on windows (VC 2010), so this repo needs to be cleaned up before it should be merged back into the main repo.
He responded in his comments:
> If not, the fork will remain buried as a Pull Request with no visibility at all.
Which is loads of bullshit. By design git is decentralized so upstream is a mere convention, where usually the closest to upstream is either the original author's repository or the most active repository.
If the guy did things properly, although inconvenient we could just do that to merge back, but apparently what he did was rewrite or recreate history in some way, so that SHA1s changed so it's not even possible to add remote[0]. I guess that even with no common ancestor SHA1s one could still use rebase --onto to replay some part of his history.
Either way I can't tell because the repo is 404 now and I did not have a chance to browse it, let alone clone it.
[0] http://news.ycombinator.com/item?id=3277181
PS: I like some of your ideas, like hiding forks that can be fast-forwarded (i.e they have no changes i.e their HEADs are members of the parent repo), and detecting that one has pushed a repo that is obviously a clone of another, although I'd rather have it be manual (like a message on the github's console saying "we detected that this repo could be a clone of that repo, do you want to mark it as a fork?")
How might one go about making their own media for the game? Does it even make sense to do so? How tightly coupled is the released source code to the media?
The source to the game executable (rendering, script interpreter, physics, pathfinding) is free and released under GPL. The assets, however, such as scripts, textures, shaders are still under the original commercial license.
It is certainly possible to make your own media for the game; it will be a lot of work, but arguably less work than writing your own game engine AND making the assets. It makes sense because the Doom3 engine is very flexible and you can do a lot with it, some of which has already been done in the form of mods (as the SDK has been available for a long time).
So if I wanted, theoretically, to modify the mechanics of the game, how would I do that with "assets"? For example, if I wanted to add "magic" or something (like mana from diablo 2), and perhaps change the way "score" is calculated, is that part of an asset as well?
Do engines provide a DSL for making games? I guess that's my question. It seems like media assets only allow you to reskin Doom instead of making a new kind of game.
On Quake 2, you could replace the DLL to switch between the regular game and capture the flag. An expansion with new mecanics could, theoretically, be done with only DLL code and new assets. You'd need to change the engine code only to add new kind of effects that it didn't support yet.
So yes, if you don't change any code, you'll only reskin Doom by creating new assets (it's usually called Total Conversion). If you want to add new game mechanics, you have to write some code.
So you could make a magical weapon writing just scripts, for example. But yes there is a limit in the flexibility, if you want to make a completely different kind of game you probably have to change the C++ classes as well...
There are also a variety of games using idtech3 (quake 3 engine) such as UrbanTerror, OpenArena, and Nexuiz (http://www.urbanterror.info/home/ http://openarena.ws/smfnews.php http://www.nexuiz.com/).
I'm not sure idtech4 is as suited for fast multiplayer gaming like the idtech2/3 engines were, but who knows what the open source community will come up with.
You'd use a combination of general-purpose tools (Maya, Blender, Photoshop, GIMP), and more specialized tools (like Radiant for map making) to create original media assets.
Custom gameplay is achieved with a combination of a built-in scripting language and modifying a separately-loaded C++ library that encompasses most of what really constitutes the "game" beyond the core graphics engine. The game library appears to be included in the GPL3 release, and was previously available as part of the publicly-available SDK for modders.
You could take this code base and start adding your own custom models, textures, and maps, and have a workable game as-is.