Citadel makes big promises

There's a new big remake effort a-brewing in the Free Software world, this time for prominent shooter/RPG, System Shock. under the shape of project Citadel. According to project description, the goal is to recreate the original game using the widely known GPLed platform Darkplaces Engine, upgrading the game's graphics to full 3D but keeping game aesthetics close to the origianl game. Added modding capabilities and cooperative multiplayer will also be a part of the project. 

Details, however, are somewhat scarce, so far, as development is happening behind closed doors, and creator Josiah Jack just announced the existence of the project itself after months of programming in secret. While the code will certainly be all GPL or GPL-compatible due to Darkplaces licensing requirements, the game appears to rely on original proprietary assets, as well as using its own whose license nature is yet to be disclosed.

With a release date planned for the the 23rd of December, System Shock's CD release anniversary, I guess we'll have to wait and see if this project will deliver.

Read More

DevCorner: Underapprechiated game engines

In my never ending search for a FOSS game engine that is usable for game modding with out having to reinvent the wheel (nor requiring to be a C++ code master) & having decent tools for content creation (because I am spoiled and think that is a minimum requirement for a game engine) I have become quite disillusioned lately. That is because *spoiler alert* sadly there is none so far... but a few are close luckily.

The usual contenders for 3D action games are your mixed assortment of idTech based engines, most notably ioQuake3. There are a few upcoming contenders like Unvanquished's Daemon engine (which is a mix of ET:Wolf, ioQuake3 and Xreal) and a yet to emerge idTech4 based champion (my uninformed guess is that it will be dhewm3). But all of them lack a decent game-play scripting function.
On the other side of the idTech spectrum, there is the idTech1 based granddaddy DarkPlaces, which while having advanced to an quite impressive feature set, suffers a quite a bit from its nut-bolted & mostly undocumented client side add-on on the already a bit arcane script language QuakeC.

Interestingly the idTech2 based engines get little attention though. I have highlighted a few nice game projects based in it in the past, but it is probably due to the fact that each project is hacking on their own engine fork, that none has gained prominence as a game engine on it's own. But feature wise the engines behind AlienArena, Overdose and Warsow are probably the most advanced.
The last one of these, has been probably the most overlooked, with the game itself not exactly open-source friendly and the engine being developed more or less behind closed doors. It seems however that this has changed now, although given recent project news it is unclear what made them change their approach. But an all new version of it is now on Github with the main developer mentioning a few really nice changes here. Let's hope it isn't just a "source-drop" of a dying project, as after digging into it a bit (the documentation is really fragmented and lacking) I have to say that it includes a few really awesome features not commonly seen in other FOSS engines:
Besides being really performant, it is fully scriptable and has some quite unique multiplayer features like awards, friendlists and persistent game statistics. It also seems to make good process in having easy to edit GLSL shaders, which I have realized is a much rarer feature than I originally thought. Last but not least it has a really modern looking and fully scriptable menu and HUD.

Ah and before I move on to non-idTech based engines I should mention Engoo for those looking for a modernized software rendering engine based on idTech1 (there was some controversy over it, so I am trying to show some support for its further development here).

Ok, that covered, what are some maybe under appreciated non-idTech 3D engines?
First of all I should probably mention the well known ones for the sake of completeness: Cube2, Ogre3D and the new big player Torque3D. All of which are IMHO still failing to provide a good platform for easy game creation (mainly due, following the same order: in-fexibility & lack of scripting; huge mess of independent parts & bad toolchain; lack of Linux port & buggy and overly complicated toolchain).

One of the shining but lesser known examples of trying to improve the status quo is the jMoneky3 engine. Even though it is still a bit bare-bone (e.g. lacking game frameworks) the nicely integrated SDK and the great new node based GLSL shader editor keeps on attracting my attention. Similary the BlenderGameEngine sure has a few great advantages due to its tight integration. Sadly it seems to be the unliked stepchild of the Blender3D project though, which some quite serious limitations and awesome additions like the candy branch never reaching the the main release.

Then there are the still very much alive big names of the past: Irrlicht and Crystal Space. I am not exactly sure why those never quite reached the required mass to become the engines of choice, but I guess the license mess around Irrklang (and other non free but more or less required addons) and the CS Yo Frankie disaster might have to do with it. But at least Crystal Space was accepted as a hosting organization for this year's GSoC again, so they must be doing something right.

Last but not least, I would like to give a mention to a relatively new contender: Octaforge, which has supplied a steady stream of updated betas lately. The interesting things about Octaforge is that it takes all the good things from Cube2 and combines it with a much updated renderer (Tesseract) and full lua script support. But sadly it isn't quite there yet, and the move to a scripting language required the removal of all the nice game-code that it inherited from Cube2.

As closing remarks I have to admit that this article was rather lopsided towards FPS game engines (and more general purpose ones). Of course there are many great other game engines in the FOSS sphere that focus on RTS or (MMO)RPG games etc. I do however feel that many of the grievances voiced here probably apply there too, but maybe it isn't quite as frustrating there as in the FPS genre.
But if you have some better insights into those type of engines feel free to comment below!

tl;dr: the author (as an old school modder) is frustrated that after all these years there still isn't an FOSS FPS engine that can be modded as comfortably as the Half-Life2 engine or UDK. Don't miss the new qfusion stuff though.

Read More

Dead Morning, an open-source horror game

Today I bring you news of yet another rather low profile Darkplaces engine game (e.g. the same engine that runs Xonotic), called Dead Morning:



As you can see in these other, more game-play oriented videos (1, 2, 3), it seems to be quite heavily influenced by another recent 1st person horror game...

The website mentions a fully open-source release at the end of this year, so I am rather intrigued what they will come up by then!

Read More

Dev-Corner: Inter Quake Model Format and Open Source Gamedev Collaboration

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

Read More

Modern retro-graphics: RetroBlazer

Short call for help: Awesome looking retro-graphics game is looking for a Darkplaces QC programmer.
So far only two screen-shots have been released (and no word on the license of the media):

I am loving the style... so here is the other:

So if you know your way around Quake's QC scripting language try to get into contact with them :) Otherwise you can still follow the progress of this game over at QuakeOne's forums.

Oh and taking about Darkplaces... Xonotic finally implemented client-side networked players in their most recent development release. Meaning that there is now client-side movement prediction and thus less (visually) laggy game-play on slower netspeeds!

Read More