The FG forums seem to be experiencing more downtime, which sucks a little. Oh well, such is the risk ya take when using a free service.
There's an interesting article on the state of Linux gaming (parts 1, 2, 3 online with more to come) and, although it covers both commerical and open source games, since the majority of good games on Linux are open source games (ok, that's flamebait, but still...) most of the games in the article are open source. ;-)
Apparently Ubuntu is brilliant for gaming. Good to see people impressed by Free Software, even it's it is running proprietry stuff.
Ok, back to Free game matters, and a 3rd release of irrlamb is out. It's cool to see regular updates to this new and innovative 3D game where you control a sphere and use physics to overcome obstacles and puzzles. I tried it out on my Linux laptop and it both ran well and was fun to play. The graphics are never going to be earth shatteringly great but they don't need to be - the game is simple and the graphics in general are nice and clear and well suited to the game. There are binaries available to download for Linux and Windows. The development roadmap has a few interesting features plus a focus on making it a "fun game" - high scores, level unlocking, the kind of features that give you impetus to play it more.
After a bit of downtime, the VDrift website is back up. The next release will focus on polish - one very well done car and track with a nicer GUI. I think it is a good move and they should set a high standard for cars and tracks included in the default distribution. It will provide motivation for creating better tracks - if it's too easy to get stuff into a game then often the need is not there to keep working on a model once it has reached the "acceptable" standard. Raise the standard, and contribution standards should theoretically go up. Anyway, more information is available on the release planning page in their wiki.
When developing an open source project, there is always a trade off between developing new features and perfecting what you already have. Personally I think the VDrift guys have chosen the right moment to stop working on features and refine what they have done so far.
Which brings me to the title of this post - new or shiney. I think it's fair to state that code can never be both new and shiney. New code has bugs. Shiney code has been refined over time. New and shiney is not a concept that transfers from the tangible reality of goods to the abstract world of programming. New or shiney, pick one and stick at it. ;-)