there are hundreds or thousands of GPL game projects on SourceForge, and most of them are dead
Perhaps the open source idea of havings thousands of eyes, and encouraging anybody to jump in and out of the code making changes, is incompatible with the process of creating a game?
I don't know of any open source applications that are "finished", or even try to be - their early releases are at least slightly useful, and they are always releasing new versions and adding new features. And there always are new features that can be added, each of which will improve the application, so people can work on their favourite features and the project will continue on its path of continual improvement.
Traditional games don't work like that. They're barely recognisable as a game for a large part of their development time - during that time, there has to be a vision for the finished product, and everybody on the project has to work towards that distant vision. It'll be years before anybody can really see the results of their work. That's not very enticing for somebody who can only be certain of spare time for the next couple of months - they would rather work on something much smaller, like a mod or a tech demo, just to get visible results.
And unlike most open source projects, people can't just add features they think are cool and useful - everything has to fit into the overall design of the game. You cannot simply add features without considering the consequences on the whole of the rest of the game - and you can't consider all the consequences unless you've already spent months working on the game and getting a feel for how everything interacts.
For professional game development companies, they get people working towards the vision by simply paying them to do so. That won't work for community-based open source projects, so they need some other way of doing it.
But I don't know what way that would be. I've been working on a "freeware, hobbyist" game instead (0 A.D.), which is a full 3D RTS with its own game engine, comparable in scope to commercial games (or at least to those of a few years ago) - it's making use of various open source libraries (SpiderMonkey, Vorbis, Xerces, etc), but is not itself open source. And I think that's a factor in how it has kept going for so long: 'membership' is still open to anyone who has the right abilities and dedication, but that means there is a strong concept of membership - we're part of a team and feel some responsibility towards making progress, following the design, and seeing the game through until it's finished. I don't think that feeling would be as strong if we were primarily a loose community of people who are just poking around the code with no commitment, which is how I perceive most open source projects.
And programmers are only a small part of game development - you need artists, designers, sound effects, music... (We have historians too, though that obviously depends on exactly what game you're making). They're far less likely than programmers to jump into an open source project - it's much more comfortable to jump into a well-defined team.
In any case, we still have a long way to go before our game is actually complete and released, so we don't have much more tangible results than the many open source games which haven't been finished. But I don't see how we could have got as far as we have done, if we didn't have the organisation that we do:-)
Last week Gamasutra asked our professional audience, "What hardware capabilities and software would be needed for a third company to create a competitive rival to the Nintendo DS and Sony PSP, and which companies might be capable of doing so? Should they try?"
[...] Of the cited companies who might possibly compete in this area, Apple and Microsoft were by far the most mentioned, with many readers citing Xbox Live and iTunes as superior distribution mediums.
Movies take several years to generate two hours of content. Games are often ten times that long, with a much smaller budget. How can they possibly be of comparable visual quality? and why do people try?
I would much rather have games that concentrate on art instead of graphics. (Rez and Darwinia come to mind as examples of visually impressive games with non-realistic styles. Unfortunately, it doesn't seem to work well in terms of sales...)
I remember something about this from Physics World, around five months ago. That article reports experiments in which a resolution of a quarter of the wavelength was achieved. As far as I can tell, the idea is that diffraction doesn't work quite how it's taught in classrooms: there is a standard "far-field" portion, which is limited to a resolution equal to the wavelength of the light; but there is also a "near-field" portion, which "contains all of the sub-wavelength spatial details about an object, but... decays quickly as a function of distance from the object". A lens with a refractive index of -1 causes an exponential increase in the near-field waves as they pass through the superlens, and so the information can be more easily recovered, giving an image with better resolution than if only the far-field light was used. The object, lens and image all have to be located within the near-field, less than one wavelength in size, else the waves decay too much - that limits the practical applications, but it could apparently be useful for the optical storage industry.
52MB WMV torrent. Also magnet:?xt=urn:btih:YVWX5ASA63LAOYSHSXG7Y2ULDEZE57 VF (minus spaces) for Azureus users, since that tracker won't be kept up for long.
One of the game's aims is to make it easy for people to alter almost every aspect of it. That's partly done by providing all the tools (the same as are used to actually create the game), and partly by using human-readable file formats - rather than making e.g. a visual GUI editor, we just use XML and a text editor. (That probably makes it harder to do the layout, but easier to embed scripting code; WYSIWYG wouldn't really work when all the objects are repositioned at run-time, anyway. And it requires less effort from the programmers.)
XML is mostly being used for graphical objects (specifying a combination of models, animations, textures, etc) and for units (setting strength, speed, scripted event handlers, etc). Those files tend to be generated automatically by the scenario editor, but end up being hand-edited: the data needs to be extended as features are added to the game, and it's far easier to just edit the text file than to add new fields to the graphical editor. (That's mostly laziness again; but there's nothing wrong with laziness, and it seems like a fairly good reason for using a text-based format.)
It's quite nice having the XML parser do some validation of the data with DTDs, but we could easily live without that. The only interchange of data is between different parts of the program (if you don't count humans who want to mess with it), so there's little need to follow any standards. But there's still the consideration of laziness: XML can be fairly readable, and libraries exist for handling it, and it seems good enough. I don't think anyone actually knew of any alternatives (although the decision was made a long time before I joined the project), but there's nothing particularly bad about XML given that we really want a text-based structured format - except for its speed, which was mostly solved by caching it in a binary format. We don't use XML where it's completely inappropriate - terrain height-maps, configuration files, network communication, etc - but it seems to work fairly well for most other types of data.
Self-describing is incidentally useful for people who don't want to put up with tools that we've made. I spent literally months trying to understand the giant data file used by Age of Empires 2, since there was no known way to edit it, and still could only read half of it. The game's developers probably never worried about that, but people always want to do things that the developers didn't think of, so a self-describing format is extremely helpful for those kinds of hackers. But a binary format with some documentation would be just as good - self-description isn't really an advantage when any other format can come with some form of description.
As for when the game will be finished (at least to a beta-testing level), I would imagine 2006 is not an unreasonable guess. But we're all just working on it in our spare time, so progress is a bit erratic, and so it's more a case of "when it's done";-)
As here, XML is ten times slower than a binary format, at least for very simple data files that don't get processed much after being read (which are very common in what I've been using XML for). It's still pretty fast, but the speed does become a problem when there are hundreds of files loaded at once. Age of Mythology also uses XMB, so presumably they encountered the same performance problem.
I've been working on a free RTS game (0 A.D.) that uses XML for storing most of its data, with Xerces to load those files. It seemed a little slow, so I made a simple binary XML format which eliminates the parsing step and just loads the data directly into memory.
Loading a simple XML file (a couple of hundred bytes of data, plus another few hundred for a DTD), Xerces took about 10ms. The binary format took about 1ms. For a larger file, Xerces took 160ms while Xeromyces (the binary version) took 80ms (of which most was spent in other bits of code, handling the data that it read).
When there are hundreds or thousands of such files that need to be loaded before the game can start, speed is critical, and XML by itself is just too slow. Our implementation of the binary format retains the advantages of XML (such as... erm... I'm sure there must be some), since you can always just edit the original XML, and it upates the cached binary version whenever it needs to; but it greatly reduces the performance problems that are inherent in parsing a text file. So, if you're loading lots of fairly static data files, binary XML is definitely a worthwhile thing to implement.
It's near the large lake full of floating explosive barrels, with the helicopter dropping hundreds of bombs. After destroying the helicopter, you open the large gate into another section of water. Somewhere around the edge of that area, there are the two sewer grates. Climb through the open one (I had to jump on top of the boat to reach it), run through the pleasantly radioactive sludge, and there's an opening on the left with the vortigaunt. (He speaks the vmono_*.wav files, whose contents are listed here)
I've been using the shareware version of NetTransport, which seems to work quite nicely - give it the.ram or.asx URL, wait half an hour, and it'll save the 26MB of.rm or.asf data.
Or "listen again" right now at rtsp://rmv8.bbc.net.uk/radio4/comedy/tue1830.ra - you can access anything from the past 7 days, without waiting for them to add it.
Net Transport seems to be able to download the raw.ra file if you want a permanent copy.
Slashdot Mirror
Perhaps the open source idea of havings thousands of eyes, and encouraging anybody to jump in and out of the code making changes, is incompatible with the process of creating a game?
I don't know of any open source applications that are "finished", or even try to be - their early releases are at least slightly useful, and they are always releasing new versions and adding new features. And there always are new features that can be added, each of which will improve the application, so people can work on their favourite features and the project will continue on its path of continual improvement.
Traditional games don't work like that. They're barely recognisable as a game for a large part of their development time - during that time, there has to be a vision for the finished product, and everybody on the project has to work towards that distant vision. It'll be years before anybody can really see the results of their work. That's not very enticing for somebody who can only be certain of spare time for the next couple of months - they would rather work on something much smaller, like a mod or a tech demo, just to get visible results.
And unlike most open source projects, people can't just add features they think are cool and useful - everything has to fit into the overall design of the game. You cannot simply add features without considering the consequences on the whole of the rest of the game - and you can't consider all the consequences unless you've already spent months working on the game and getting a feel for how everything interacts.
For professional game development companies, they get people working towards the vision by simply paying them to do so. That won't work for community-based open source projects, so they need some other way of doing it.
But I don't know what way that would be. I've been working on a "freeware, hobbyist" game instead (0 A.D.), which is a full 3D RTS with its own game engine, comparable in scope to commercial games (or at least to those of a few years ago) - it's making use of various open source libraries (SpiderMonkey, Vorbis, Xerces, etc), but is not itself open source. And I think that's a factor in how it has kept going for so long: 'membership' is still open to anyone who has the right abilities and dedication, but that means there is a strong concept of membership - we're part of a team and feel some responsibility towards making progress, following the design, and seeing the game through until it's finished. I don't think that feeling would be as strong if we were primarily a loose community of people who are just poking around the code with no commitment, which is how I perceive most open source projects.
And programmers are only a small part of game development - you need artists, designers, sound effects, music... (We have historians too, though that obviously depends on exactly what game you're making). They're far less likely than programmers to jump into an open source project - it's much more comfortable to jump into a well-defined team.
In any case, we still have a long way to go before our game is actually complete and released, so we don't have much more tangible results than the many open source games which haven't been finished. But I don't see how we could have got as far as we have done, if we didn't have the organisation that we do :-)
With the Intel C++ Compiler? (plus some more compatibility information (PDF))
Movies take several years to generate two hours of content. Games are often ten times that long, with a much smaller budget. How can they possibly be of comparable visual quality? and why do people try?
I would much rather have games that concentrate on art instead of graphics. (Rez and Darwinia come to mind as examples of visually impressive games with non-realistic styles. Unfortunately, it doesn't seem to work well in terms of sales...)
I remember something about this from Physics World, around five months ago. That article reports experiments in which a resolution of a quarter of the wavelength was achieved. ... decays quickly as a function of distance from the object". A lens with a refractive index of -1 causes an exponential increase in the near-field waves as they pass through the superlens, and so the information can be more easily recovered, giving an image with better resolution than if only the far-field light was used.
As far as I can tell, the idea is that diffraction doesn't work quite how it's taught in classrooms: there is a standard "far-field" portion, which is limited to a resolution equal to the wavelength of the light; but there is also a "near-field" portion, which "contains all of the sub-wavelength spatial details about an object, but
The object, lens and image all have to be located within the near-field, less than one wavelength in size, else the waves decay too much - that limits the practical applications, but it could apparently be useful for the optical storage industry.
Like this? (magnet:?xt=urn:btih:4LRCV4AOJUMY2XDE3ZDHZ2VAZUYXC NEO)
52MB WMV torrent. Also magnet:?xt=urn:btih:YVWX5ASA63LAOYSHSXG7Y2ULDEZE57 VF (minus spaces) for Azureus users, since that tracker won't be kept up for long.
One of the game's aims is to make it easy for people to alter almost every aspect of it. That's partly done by providing all the tools (the same as are used to actually create the game), and partly by using human-readable file formats - rather than making e.g. a visual GUI editor, we just use XML and a text editor. (That probably makes it harder to do the layout, but easier to embed scripting code; WYSIWYG wouldn't really work when all the objects are repositioned at run-time, anyway. And it requires less effort from the programmers.)
;-)
XML is mostly being used for graphical objects (specifying a combination of models, animations, textures, etc) and for units (setting strength, speed, scripted event handlers, etc). Those files tend to be generated automatically by the scenario editor, but end up being hand-edited: the data needs to be extended as features are added to the game, and it's far easier to just edit the text file than to add new fields to the graphical editor. (That's mostly laziness again; but there's nothing wrong with laziness, and it seems like a fairly good reason for using a text-based format.)
It's quite nice having the XML parser do some validation of the data with DTDs, but we could easily live without that. The only interchange of data is between different parts of the program (if you don't count humans who want to mess with it), so there's little need to follow any standards. But there's still the consideration of laziness: XML can be fairly readable, and libraries exist for handling it, and it seems good enough. I don't think anyone actually knew of any alternatives (although the decision was made a long time before I joined the project), but there's nothing particularly bad about XML given that we really want a text-based structured format - except for its speed, which was mostly solved by caching it in a binary format. We don't use XML where it's completely inappropriate - terrain height-maps, configuration files, network communication, etc - but it seems to work fairly well for most other types of data.
Self-describing is incidentally useful for people who don't want to put up with tools that we've made. I spent literally months trying to understand the giant data file used by Age of Empires 2, since there was no known way to edit it, and still could only read half of it. The game's developers probably never worried about that, but people always want to do things that the developers didn't think of, so a self-describing format is extremely helpful for those kinds of hackers. But a binary format with some documentation would be just as good - self-description isn't really an advantage when any other format can come with some form of description.
As for when the game will be finished (at least to a beta-testing level), I would imagine 2006 is not an unreasonable guess. But we're all just working on it in our spare time, so progress is a bit erratic, and so it's more a case of "when it's done"
As here, XML is ten times slower than a binary format, at least for very simple data files that don't get processed much after being read (which are very common in what I've been using XML for). It's still pretty fast, but the speed does become a problem when there are hundreds of files loaded at once. Age of Mythology also uses XMB, so presumably they encountered the same performance problem.
I've been working on a free RTS game (0 A.D.) that uses XML for storing most of its data, with Xerces to load those files. It seemed a little slow, so I made a simple binary XML format which eliminates the parsing step and just loads the data directly into memory.
Loading a simple XML file (a couple of hundred bytes of data, plus another few hundred for a DTD), Xerces took about 10ms. The binary format took about 1ms. For a larger file, Xerces took 160ms while Xeromyces (the binary version) took 80ms (of which most was spent in other bits of code, handling the data that it read).
When there are hundreds or thousands of such files that need to be loaded before the game can start, speed is critical, and XML by itself is just too slow. Our implementation of the binary format retains the advantages of XML (such as... erm... I'm sure there must be some), since you can always just edit the original XML, and it upates the cached binary version whenever it needs to; but it greatly reduces the performance problems that are inherent in parsing a text file. So, if you're loading lots of fairly static data files, binary XML is definitely a worthwhile thing to implement.
It's near the large lake full of floating explosive barrels, with the helicopter dropping hundreds of bombs. After destroying the helicopter, you open the large gate into another section of water. Somewhere around the edge of that area, there are the two sewer grates. Climb through the open one (I had to jump on top of the boat to reach it), run through the pleasantly radioactive sludge, and there's an opening on the left with the vortigaunt. (He speaks the vmono_*.wav files, whose contents are listed here)
I've been using the shareware version of NetTransport, which seems to work quite nicely - give it the .ram or .asx URL, wait half an hour, and it'll save the 26MB of .rm or .asf data.
How about rtsp://rmv8.bbc.net.uk/radio4/comedy/tue1830.ra (or rtsp://rmv7.bbc.net.uk/radio4/comedy/tue1830.ra etc) which does actually work? :-)
Or "listen again" right now at rtsp://rmv8.bbc.net.uk/radio4/comedy/tue1830.ra - you can access anything from the past 7 days, without waiting for them to add it. Net Transport seems to be able to download the raw .ra file if you want a permanent copy.