Slashdot Mirror

I'd like to see more projects like 0ad Game or
unknown-horizons they are open source.

and yet still launches in *this* state...? (ripped from Steam forum)

Issues: No Custom settings for Video Cards
Video Cards not being detected properly by the Auto-Detector Resulting in using 0MB of Vram and using the lowest texture/gfx settings...
No Console command
No Vsync options - Results in screen tearing - Forcing Vsync causes the game to crash the drivers and game(AMD)
Unable to skip intros??? To disable the intro videos put this "+set com_skipIntroVideo 1" in the launch options of Rage Via Steam.
Mouse acceleration?
Can't use Crossfire or SLI..
Bad FoV for PC's - Short-term solution: FOV adjustment howto
(Nvidia)Enabling V-sync by forcing it in the control panel causes the game to Stutter and have lines appear:
OpenGL Issues: GL_ARB_draw_elements_base_vertex not available
Missing Files or GFX card not compatible? - List of compatible card: http://feedback.wildfiregames.com/re...ts_base_vertex this issue seems to be common with laptops and mobile video GFX processors meaning the game may not run on a mobile GFX chip(Laptops)


Bugs:
Texture Streaming is bad and slow resulting in always reloading the same textures thus causing the textures popping in effect - http://www.youtube.com/watch?v=N7Ch6TX-Cbs&hd=1
Missing/blinking textures...
Random Crashing: when exiting the Arc, after intro video, including when trying to start a new game and loading new areas.
LoD issues(popins dispersing items)
Audio stuttering and not blending properly.
Occasional Artifacts appearing- http://img812.imageshack.us/img812/9...0322215294.jpg
Low Frame rates with occasional fps spikes
Loading saves causes videocard drivers to crash...
Game Fails to start with error code #51.
Shadows turn Green
Binding keys don't always save and remain unbound and unable to be set
No Sound? this is a common issue with creative soundcards - Possible Fix: Buy a new soundcard or try and use your onboard sound.


But for some reason, because one of the guys who worked on it did some cool stuff a few years ago, this is somehow acceptable?

http://trac.wildfiregames.com/wiki/GettingStarted

...
Playing 0 A.D. - details on how to run the game. ...
How to build 0 A.D. ...

I can't believe how much digging I needed to do. The donation page is on their main developer page: wildfire games

I found a paypal link off the main site page:

http://wildfiregames.com/0ad/page.php?p=6438

And on the lord created The Dude, and it was good.

http://www.wildfiregames.com/0ad/album_image.php?pic_id=10984

-rt

Shut the fuck up, Donny.

Access to the often overlooked and underappreciated "Make Dude" command. And on the lord created The Dude, and it was good.

http://www.wildfiregames.com/0ad/album_image.php?pic_id=10984

-rt

Are you aware that the year 0 A.D. did not technically exist?
Indeed. Think of 0 A.D. as a hypothetical time period that never existed. It is a snapshot in time where major players of the classical ages were placed in an observatory. This is your chance to see them 'duke it out'. Your job as the player is to create the hypothetical and recreate the historical.

It's called suspension of disbelief, and there are times when it's a good thing. Situations may include books, movies, video games, and other works of fiction.

one of the big goals of a lot of open source games is to be able to run on older hardware. This isn't necessarily a bad thing, but it does mean that it limits the quality of the artwork. Many commercial games are released when even a top-of-the-line gaming rig can barely get top performance, while many open source games tend to be written to run on any machine built in the last 5 or 6 years.

Five years ago saw the GeForce 3 (although admittedly as the high end, not "any machine"), which is perfectly capable of making good-looking games as long as you rely on decent art rather than just adding HDR and bloom and bump-mapping and specular highlights and hoping it'll look good - we've had some reasonable success using none of those features. Currently the only pixel shader in the game is for high-end water, and we have an equivalent effect for GF3/4s; pretty much everything else is just a plain texture map. You can even run modern games like Oblivion on a GeForce 3 and it looks good (though it doesn't run quite so smoothly).

It is a bit harder if you want to support the common integrated graphics chips with limited memory and processing power - but I'd tend to blame ugly games on bad art instead of a bad graphics engine. Anyone can download OGRE and set up a rendering system with modern features, but artists are much harder to find - contributions from people like you can make a big difference (at least when the programmers are happy to accept it)!

It is squarely intended at the hobby coder who wants to work on what the book calls "desktop games" -- not the multi-million dollar multimedia productions that demand a new graphics card every half year, but the games that you play while thinking out a knotty problem or that have some educational value for your kids. The kind of project a single coder, or a small team can complete and maintain while still staying sane.

That seems like pretty sensible advice - the phrase "game development" immediately brings to mind the big successful commercial games, but that's not the area in which open source seems capable of competing, and it is much more productive to realise that simple games can be more worthwhile to make.

As for why open source game development has problems when trying to emulate commercial game development, there was some discussion a while back; shamelessly reposting my comment from there:

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

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 :-)

Unreal Doom3 HalfLife2 Enemy Territory Cube Savage Stratagus Freeciv Wesnoth NeverwinterNights Tribes2 Vendetta YohohoPuzzlePirates Civilization AlphaCentauri FrozenBubble Pydance Teg DeusEx BZFlag XPlane Flightgear Torcs Scorched3d Pingus Lincity Tuxcart Torcs Quake 123 VegaStrike Railz LBreakout Armagetron PPRacer Vendetta and there more impressive titles under development.

Here's my opinion. What "we" need are fewer people saying we need more games, and more people recognizing some of the excellent offerings we have right now. If we support these games (even with nothing more than just a little recognition), the companies WILL notice, see us as a market, and want to cater to us.

it doesn't mean Linux won't continue to see a few good games. Wildfire Games are developing a 3D real-time strategy game, 0AD. Just like we enjoy free/open source software applications such as openoffice and the mozilla suite, there will be free games worth playing. America's Army has a large fanbase, 0AD most likely will have one when released, more will come :).

it doesn't mean Linux won't continue to see a few good games. Wildfire Games are developing a 3D real-time strategy game, 0AD. Just like we enjoy free/open source software applications such as openoffice and the mozilla suite, there will be free games worth playing. America's Army has a large fanbase, 0AD most likely will have one when released, more will come :).

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.