Open Source 3D Game Engines Updates

Crystal Space 1.4 is out. Features include improved animations ("integrating vertex based animation with skeletal animation") and terrain ("improves rendering and handling of large outdoor areas"), OpenAL for sound and an internationalization plug-in.

Engine screenshots are very informative. This is Panda3D by the way.

Panda3D has a prettier website, it released version 1.7.0 and apparently has a web-plug in. The new version makes it easier to crash the computer, but also gives a performance boost - with the magic of 'pointer textures'.

I have a little crush on Panda3D, because it gives access to 3D and audio with no complicated setting up through a scripting language (Python). On the other hand it requires 3D models to be in its own format and I find converting not very convenient. For example there have been problems importing animations into Radakan.

OGRE mascot

Ogre has a mascot, and it might even become freely licensed, somebody just needs to confirm this (by posting in the thread). :)

Besides that, 1.7.0 RC1 has been released, which is licensed under MIT license (before, it was LGPL). Here's what seems like a changelog.

OGRE wikis

Furthermore, the OGRE wiki moves from MediaWiki to TikiWiki. I suspect that a main reason is because a nicer OGRE style was made for TikiWiki, while the MediaWiki OGRE style looks bad. That may be a strange reason, but as long as it makes people use the wiki more, why not? Here's the discussion if you have an idea.

Just for kicks: a simple comparison of OGRE, Panda and Crystal regarding lines of code. What does it tell us? Well, that OGRE has the biggest codebase (even though it only handles graphics), that Panda3D is the most compact of the tree and that Crystal Space code size had strange ups and downs. Nothing more really.

Kambi VRML v2.0 is soon to be released, as is the final version of the demo game Castle (which will only mean additional eye candy to the game). What is more important, as soon as Castle 1.0 is released, work will start on Castle 2.

Castle 1 is a three-level game and I consider it hard (easy to die) and its controls to be rough. On the other hand the level design is great: the layout invites exploration the levels are linear, each with a goal to be reached. This way the levels actually are part of a game, rather than an open-ended tech demo. This is why I have a good feeling about Castle 2.0 already. Depending on whether the developers decide to work on Castle 2 on their own or to ask the community for contributions, we might see some more use of their forum.

Morrowind scroll loaded in OpenMW

OpenMW, the Morrowind engine implementation in OGRE switched from D to C++ (because of compiler availability and language popularity) and from svn+git to git-only (because of git-svn problems). Git clone instructions here. The next feature to be implemented are animations. A video was promised as soon as they are ready.

Old news: OpenGameEngine development stopped in October 2009, until a project manager wants to take over. The form in which the project is left is described as "usable" and "still too much work to make it worth the time investment".

Enjoy another ridiculous comparison of 3D (game) engines: OpenMW, KambiVRML and OGE. I just love diagrams. :)

We have a list of 3D engines on our wiki, if you want to dig some more. Also all FOSS game engine blogs that have feeds are included in the FGD development planet feed aggregator.

Sauerbraten, Vega Strike, Project Kilo

Did I not mention this Sauerbraten update? I don't recall doing so, and I swear it was not a thread in their forum at the weekend despite being listed as posted on the 12th June. Anyway... it fixes a whole lot of bugs, adds graphical enhancements, and cleans up scripting support a little. Probably more of an update for people making mods/games with Sauer than players but, shucks, I love this project. Embarrassingly this was a 2006 release... *oops*

There's the possibility of a StarShip Troopers: Last Defense, the Glest mod, becoming available for FreeBSD.

The Java Classic RPG project has posted a snapshot for anybody who wants to play with it in it's very early stages of development. Work continues at an impressively frantic pace, soldiering away on features. Hopefully a modeller or two can start contributing to the project to make the artwork updates as impressive as those to the codebase.

I keep pestering the Vega Strike team to make a new release. I, and others, frequently get pointed to the SVN version. However it turns out that there is a Windows build of the executable made every few weeks, although you will still need a subversion client to get the latest version of the game data.

Talking of pestering projects, I'm trying to convince the Project Kilo guys to use Sauerbraten as their game engine. Project Kilo is an effort (well, currenlty mostly an idea) to create an immersive single player 3D RPG game. Sauer is the engine also behind the Eisenstern project, another 3D single player RPG effort with slightly less lofty (but still impressive) goals than Kilo.

Eisenstern

The main feature of Sauer is in-game multiplayer map editing where all map elements are defined as cubes or combinations of cubes, it makes a lot of sense to map modellers. I think the combined nature of Sauer's very easy map creation and it's development supporting Eisenstern makes it really suitable for, at the very least, prototyping a concept like Project Kilo. With little or no code the Kilo team can be up and running in no-time, and (being open source) they can build additional features into Sauer as they require them and possibly even feed back upstream. I think it's a far more pragmatic route than taking an engine like Crystal Space or OGRE3D and creating the game logic from scratch. Map modelling itself will become far more of a burden using this approach, let alone the extra effort to make a playable scenario.

I'm not saying that Crystal Space and OGRE3D don't have their place in development - they are important game creation tools - but if somebody has done 95% of the work for you like the Sauer team has, by implementing a game [engine] that not only makes map modelling easy but lets you roam around massive maps with fancy effects and is easy to customize, then surely it makes sense to start there instead of starting far behind them.

People should do as I command suggest because I am always usually right. ;-)