For those wondering, there is some discussion here with War§ow developers trying to justify their decision to keep the art assets non-free and why there isn't a open source-code repository.
Personally I am not convinced, but at least they release their engine code and promise to keep the overall game always freeware...

Monday, July 09, 2012

The following is a guest post by Lee Salzman, a contributor to several open source game projects and the lead developer of such projects as the ENet networking library and Sauerbraten, introducing IQM (the Inter-Quake Model format), a simple model format designed to meet the practical challenge of animated content for Quake(-like) 3D engines and allow more sharing of modeling tools across various engines

As much as players or fans of various open source FPS games might view all these projects as competing, isolated islands, the surprising and hopeful truth is, we developers actually get together and talk about development challenges a lot. And in past discussions, one of those issues that stuck out like a sore thumb was content, especially animated content such as player models. We were all using our own various custom model formats or cast-off commercial formats (like id's MD5 or Valve's SMD formats) with related third-party export or conversion tools, with varying degrees of (dis)satisfaction.

Yet, what we all needed in this case was so eerily similar: we all just wanted a no-fuss, binary, skeletal animation format that was quick to load, had relatively small file sizes, and provided the commonly needed mesh data for Quake(-like) player models - not bloated with unnecessary "but what if..." features while remaining just flexible enough to fulfill the artists' needs. Existing formats like MD5, SMD, Collada, and others had complex textual representations that make them painful to load and often require significant internal conversions of the loaded data to get useful, renderable animation data out of them, often with frustrating omissions such as no ability to directly export vertex normals. Engine specific formats worked around these issues to some extent, but often suffered from poorly supported tooling due to the difficulty of keeping it up-to-date with various modeling tools and artist requirements.

IQM Demo Model, Mr Fixit

Given those frustations, why did we not just throw our lots in together and make one format that could handle our needs well enough, so we all benefit from common efforts on reliable, shared tools? Sanity prevailed, and not much later, after input wrangling from various developers within the community, we hammered out a simple specification for a pair of formats that did just that: IQM, a binary skeletal animation format that provides easy integration into a game engine, and IQE, a textual format that makes it easy to quickly write exporter scripts and easily converts to IQM if one does not wish to write an exporter for it directly.

And what good is a specification without support? So again not much later, we went through the grunt-work of actually making sure the format was well-supported in the key tools our artists used and, of course, the engines we all developed. At the time of this writing, all commonly used versions of Blender have direct exporter and importer support via the IQM development kit, the model viewer and conversion tool Noesis can easily convert from and to the format, and the format has out-of-the-box support in various engines, including but not limited to, DarkPlaces (used in Xonotic, Steel Storm, and more), CRX (used in Alien Arena), Qfusion (used in Warsow), ioquake 3 (used in Open Arena and many more), Remake Quake along with its sibling engine DirectQ, and Cube 2 (used in Sauerbraten, Red Eclipse, and more). To ensure continued and future support by other game engines, the IQM development kit also provides example demos of how to easily load and animate the format, both on the CPU and also using shaders to animate the format on the GPU, for developers that are unsure of how to utilize skeletal animation or just want to see the nitty-gritty details of how the format operates.

Despite the format getting off to a great start thanks to the support of various developers within the gaming community, we still need your help and support to help this format be even more useful. If you happen to use some modeling tools other than Blender (as awesome as it is, people have their preferences) and wouldn't mind writing a simple IQE exporter script for your modeling tool of choice, or even more sophisticated IQM direct export support, we would greatly appreciate your contribution!

To get started with the format, please check out the IQM development kit and other IQM/IQE format resources at: http://lee.fov120.com/iqm

Friday, July 06, 2012

The PR machine behind AlienArena seems to have found out by rigorous focus-group testing and public surveying, that a re-branding of the idtech2 based arena FPS, was in order...
But here on the uncompromising last resort of free and unbiased game journalism we call it what it is: a nice new release, bumping the version number to 7.60; because as you should know... a higher number is always better :p

New alien spider bots!

Obviously it wasn't just the number that changed, and the list of engine, art and gameplay improvements is actually quite impressive for this release.
Another thing they updated is their website (the old one was quite horrible), and while this is a open-source game only by its engine code and sadly not media, I really like their new slogan:

Open Sourced. Ever Evolving.

Which has a certain ring to it ;)

Speaking of PR efforts, there is now a dedicated PR team for War§ow and the long awaited 0.7 release is slowly moving forward and you can see (incl. many nice screenshots) what kind of changes you can expect here.

Screenshot from the War§ow 0.7 changelog thread

There is also an BETA release of the version 0.7 (which according to standard version naming schemes should be a beta itself I guess ;) ) which can be downloaded here.

A discussion about OpenGameArt's usability for game developers started on their forums. Improvements were recently added to the texture section and this is a chance to formulate enhancement to the other sections.

Bananabread is the spiritual successor to Syntensity (which added a Javascript scripting layer to Sauerbraten) only this time running inside the player's browser. It was ported using Emscripten, a C++ (LLVM) to Javascript compiler, and seems to have quite a lot of Sauerbraten's functionality ported over, including bots, multiple weapons, map editing, and even a Javascript api to control camera cutscenes.

Linus Torvalds not only showed his annoyance with Nvidia but also his love towards open source games in a recent talk (goto 58m20s).

ctdabomb, an active community member, converted and license-clarified the Art Museum SuperTuxKart racing track over the time span of about one and a half months, after asking the community for support.

SuperTux, a cute platformer, needs help finishing an animated owl sprite. To the left, you can see the current placeholder graphics.

License: Code entries must be free and open source, and must be available under the GNU GPL 3.0. You may optionally release the code under any additional license(s) that you choose.

Source code: You must provide the complete source code for your entry. Any code you have written for your game prior to the beginning of the contest must be made available at the beginning of the contest.

Platform: Your code must be able to be compiled and run on a 100% free-as-in-freedom platform. It may not make use of any proprietary libraries or VMs. Just to be clear, we cannot accept games that will ONLY run on one of the following: Flash, Silverlight, XNA, Unity, Windows, MacOS , Mac OS X, iOS, proprietary JVMs, or similar. It is perfectly acceptable if your game runs on any of these platforms, but it must also work on an open platform (we strongly recommend making sure that your program run on modern flavors of GNU/Linux, as all of the judges will have access to it).

Framework: You may use an existing engine or framework, or build your game from scratch.

Judging Criteria:

Consistency of style: Your game should primarily make use of the art either provided for or entered into the contest. You may add additional art if needed, but all original art included in the game must be available under the CC-BY-SA 3.0 License and the GNU GPL 3.0 (existing art from other sources may be under any free-as-in-freedom license).

Ease of use: Your game should be easy to compile and run. You won't be disqualified automatically if a judge is unable to run your game, but it will count against you. You are advised to avoid having large numbers of obscure dependencies or requiring bleeding edge (unstable) libraries.

Creativity: Games will be judged on how creatively they use the artwork.