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. ;-)