FreeGameDev Planet - Games

One Sunday evening, oregano4 surprised us with his brand new airplane map. Yes, a real airplane map with a realistic cockpit, seats for the passengers, and even playable overhead containers.



Those who love details will find them in this map. For instance, there are numerous colourful buttons and displays in the cockpit, the spray tunnel flashes very colourfully, and the spray room – the interior of a fridge – is an artwork in itself.
Altogether it’s a fabulous map, that’s why there isn’t much more to write about it. You can download the map here.

I’ve just uploaded GH2 v0.621 to SourceForge. This release fixes a lot of bugs from v0.620, adds some new content to the core story, and should be less disjointed overall. Also, I’ve been building some really tiny giant robots. The guy on the left looks like a Transformer but I’m afraid I can’t make a positive identification.

Full list of changes below the fold.

- Fixed BuildRobot messages (robotics.pp)
- Props with undefined sprite now get one (cutegfx.pp)
- Added ERSATZ_MOUSE config option (cutegfx.pp)
- World map working in 2D mode (cutemap.pp)
- NPCs can tell PC to buzz off (arenascript.pp)
- Seeking rumors uses SocSkillTarget (arenascript.pp)
- Added \EXACT_SCENE message formatting command (arenascript.pp)
- Fixed crashing bug with monologue (arenascript.pp)
- Mullins is no longer invisible
- Create New Pilot now works in ArenaHQ (gh2arena.pp)
- Added title screen (cutegfx.pp,glgfx.pp,vidgfx.pp)
- Added ifGSealed, SayPlotMsg ASL commands (arenascript.pp)
- Removed unused NUMPLOTS config option (ui4gh.pp)
- Out of scale characters represented by small sprite (cutemap.pp)
- Updated readme file with config options and troubleshooting

Commentary will be posted over at the GearHead forum. As usual, try it out and let me know what you think.

These past three weeks have been pretty good. I took two weeks holiday as I mentioned in my previous update and this week I have been working on the save functionality of the game. Currently you can move and place buildings, however without being able to save your layouts the whole thing is totally pointless, right?

Well hopefully not for long, I have been working hard on getting save functionality working. Current I’m still having some problems, but progress is being made.

Zeljko Lazic who is a music producer submitted a music soundtrack for the game. He has included two different versions for us to use. Please comment on what you think.

The development structure of FOSS game projects can be a one-man show, it can be semi-closed by having a fixed team and little web presence, it can have lots of tasks without anybody knowing what needs to be done, or it can be plain frozen until a developer decides to pick it up.

Today, I will try to pick some of the open development ones that provide some kind of ordered task list and provide instructions in the case of media creation being the job.

Programming

Syntensity has some open tasks (having played the game helps understanding :) ), which involve tinkering with the Sauerbraten-based engine and JavaScript.

I just found out on #ufoait that UFO:AI is soon to release the first version that allows you to win the game. This will make the squad tactics game be eligible to a line on our list of complete foss games! There are still a few tasks to complete before 2.3, a humble list compared to all the open issues.

PARPG developers wants to ship the first tech demo on 10th of March but could use some Python programmers' help. The engine used by PARPG, FIFE, just released 0.3.0, introducing internationalization as one of the features. One plan for a forthcoming version is to improve rendering performance.

Never mind the sidetracking, regarding PARPG programming: here's the first step (chat) of involvement and the second (forums). :) In case you're worried about setup complications: being on Arch Linux it has been no effort for me to install fife-svn and test the svn version of PARPG many times.

I told you about the problems of getting Bitfighter to run on my x64 system. Others suffer from the same and now the development team is looking for someone willing to take a look at our errors and their code in this thread. Should you happen to take a look and have an idea of what the problem is but are too laz.. busy to register at yet another forum, please do comment on this post. :)

Assets/Media/Art

Racer is getting prettier and prettier and hopefully the instructions for making cars, using the editor and creating visual themes will let some race track artists do their magic. I recommend the racer-dev group for getting in touch with the developer.

A list of wanted voice lines for NAEV was compiled. For brainstorming, a PiratePad was used, which is based on the FOSS collaborative web text editor etherpad.

jClassicRPG recently received a new voice pack but is still looking for more voices. If you are or you know someone who likes to put their voice to use and has a way to record it, go to/direct them to the updated voice acting instructions.

irrlamb documentation now features a wiki page on level editing. For questions and feedback use this thread.

Hey FreeGamer crowd, I hope there are still a few people around ;) Today there will be only a short update, as I simply can't believe this gem of a game (see below) has not been featured on this page!

EDIT: Do not miss qudobup's post about FOSS engine news directly below this one!

A unique arena shooter

So someone had the balls (pun intended) and released a completely unique arena shooter with many nifty features, described by the creator as a mix of TPS/RTS/OMG/BBQ ;)

Check out A3P, if that has sparked your interest! At it's current version (0.5) it can be described as a third person arena shooter with some small RTS/squad command elements, and it is definitely fun to play: The technical specs are rather interesting too: Based on the BSD licensed Panda3D engine (while itself being licensed MIT; the media license is unclear though) it has all the bells and whistles one can expect from a modern game (Full GLSL shader based rendering, networked ODE physics, even integration into your webbrowser).

Yet it was developed by ONE man in only ONE year! That makes us fellow free game developers look a bit bad, I guess :( Maybe that's because it was developed in Python!

Check out the development blog for further insight into this miracle ;)

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.

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

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.

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.

We're pleased to share that 0 A.D. has won third place in ModDB's "Indie Game of the Year" contest for 2009! That means we're the third most voted for game on ModDB out of about eight hundred indies.

First of all, thanks! We feel it's a well-deserved vote of confidence in our endeavor, and we think it helps promote sharing ideas, learning how to develop games and appreciating ancient history. This couldn't have happened without a lot of hard work from our team members and the firm support of our fanbase, and we'd like to thank you all with a big, collective sloppy kiss.

We thought this could be a good occasion to tell everyone a little bit about what we've been doing recently. Consider it an official "state of the game" address.

How ready is the game?
Our programmers say the codebase is about 40% done. But looks can be deceiving: Even though the game has been in development since 2001, progress has been more dependent on effort than on time. As detailed below, just in the course of a few months the game has made a giant leap in progress, most of which is under the hood and is meant to lay the groundwork for future development.

By contrast, the art is very much advanced compared to the game's current stage of development. Art for the Hellenic and Celtic civilizations is pretty much complete, and we've made a great deal of progress on the Roman and Carthaginian civs too. Overall, about all the moving units, like hoplites and cavalry, are done, as well as 70% of the buildings. The bulk of remaining art work is left primarily in the Persian and Iberian civs and modeling things like ships and siege engines.

What's been the recent progress over the last few months?
Our top achievement over the last few months has probably been in the programming department. One of our programmers, Philip, known on the forums as Ykkrosh, has effectively redone one of the most important parts of the game engine, called "simulation". That part is in charge of changing the state of each entity in the "world" represented in the game, like handling harvesting resources, doing damage to stuff and handling death, which our programmers say has been proving particularly tricky. About 15,000 lines of code were changed or introduced in a single codebase update on January 9.

Meanwhile, the art department has mostly been working on the remake of several buildings for the Carthaginians, Persians and Romans. Some new ships has been designed like the Roman quinquereme, the Carthaginian trireme and two Hellenes triremes (not yet released). Also, there have been a lot of work on the animals in the game. About 10 new wild animals have come alive into the game, including African elephants, camels, giraffes, crocodiles, zebras and hawks. Artists have also given attention to the siege engines, advancing them from a primitive state, with the help of some new members.

How much has going OS promoted development so far?
Well, honestly, not quite as much as we had hoped. Most contributions have focused on small bugfixes and getting the game to run on different platforms, which is important in and of itself. But, we're looking for more contributions! And we have an idea how to get them: Making contributions easier and our progress more tangible.

By making contributions easier, we mean we've been working actively on the main development bottlenecks that have been blocking progress, to make it easier for new programmers to get involved - Like simulation, as explained above. Previously, simulation was a buggy patchwork of code, a veritable ball of mud that was difficult for new contributors to understand and debug, and we hope it will be more inviting now.

By making progress more tangible, we mean that over the next few months we intend to start releasing regular, (barely) playable alpha versions. The first of these is set to include very basic implementations of the following features: basic session GUI; pathfinding; construction; resource gathering; combat; enemy AI; victory conditions. They should be more easily installable, without fiddling with SVN or compiling code. And changes to the engine should be easier to implement now that the simulation code is much improved.

We've learned that many contributors start out by fixing a bug they encounter when playing, and that removing barriers makes it more likely for potential developers to try out the game. Also, we're now inclined to believe that regular releases provide a momentum that is very inviting to potential contributors, and we hope all of that works out soon.

Overall, thanks again for your interest in 0 A.D. Everyone is, of course, welcome to get involved. Together, we can make 0 A.D. worthy of awards in 2010 too.

As many of you may have noticed, we now have a chip-in donation box on the right panel of the site. I wanted to explain the box to you, tell you what we're doing and why we're doing it.

First off the donations will be used to fund the development of the iPad and iPhone versions of Hedgewars. We need to purchase these devices in order to develop for them. So the money will fund two iPads at the cheapest price we can find.

The iPhone version of Hedgewars is coming along nicely, the game now runs well on the iPhone, we're currently modifying the controls and adding an iPhone specific frontend/features. We will be basing the iPad version on the iPhone version and hope to have the iPad version ready close to the launch of the new device.

As a thank you to anyone who decides to donate, we're going to take (appropriate) hat requests from anyone who donates over $15, these hats will be implemented in 0.9.13.  
On top of this, anyone who donates will get a small bonus trophy when stats/XP are implemented.
Anyone who decides to be extremely generous and donate $50 or more will get their money back if/when the iPad version breaks even on sales.

Koda and Myself will donate up to £400 towards this fund ourselves.

The sales model hasn't been decided for sure yet, but we're most likely to put the game in the appstore for free, then sell a small amount of premium content. I.e. hats/flags/voicepacks. The PC versions will always be free, including all content.

Okay, very much happening lately, so sorry if I forgot anything. I will try to summarize without leaving out important details - just notify me if you think I missed something.

New 'feature unlocked' animation

Looking for the treasure everywhere, even in the darkness of outer space, you finally got what you were looking for. The Beach track! :)

The track exporter has been updated again with most notably this feature (quoting the commit log message):

The lap counting line is now automatically taken from the first line of the main driveline.
This avoids problems of the kart order being inconsistent (if the driveline edge and
new lap line were not identical).

This means the current tracks probably got two lap counting lines now, and that would need to be fixed at least before the stable release.

The translation "mother-file" has been updated as well, to include a few strings that were missing. Furthermore, translations for Ukrainian and Simplified Chinese has been committed to SVN.

What's this?

Well, I can tell you. It's an improved version of the Lighthouse track, with actual light coming from the lighthouse! :D
But it's not only that. Presenting a new weapon (drum roll): the item swapper!
It works in this way: when using it, all good items (bonus boxes, nitro bottles) are turned into bananas, and all bananas are turned into bonus boxes for a limited amount of time. It makes the tracks more unpredictable, something I personally like. Use it before your opponents collects bonuses, and they will find themselves eating bananas like monkeys. But be careful: it affects you as well!

Last, but not least, Irrlicht 1.7 has been released. It fixes a couple of graphical issues present with STK + Irrlicht 1.6. Many thanks to the Irrlicht developers for always cooperating well with the STK developers.

I've been dressing things up a little.

Preview here
Click to Enlarge

Stellar Forces development continues unabated, stopping only to actually take my turn in one of the various games I'm losing in.

Here's all the major tweaks since the last update:-

* Users can now subscribe to forum topics.
* Players can now show their website address in their public page.
* Each game is now automatically given its own sub-forum.
* Added a Miscellaneous Statistics page.
* Now shows the armour details on the armour buying page.
* Armour protection is now reduced if the attack is from the sides or rear.
* There are now small explosions wherever bullets hit a target.
* And last ut not least, a new mission: Rescue from the Mines.

The current "most voted for new feature" is to improve the GUI when equipping units. That is going to be no small task, but I'll get round to it eventually. I promise!

Two interesting spottings from the internet:

• Bruce Shelley, the mind behind the Age series, says there's a huge demand for RTS games that's not being satisfied. He also says he feels closing Ensemble Studios was a mistake. Most of the interview is about Settlers 7, though, which I found less interesting. (via HeavenGames)
• For all those who've been wondering when 0 A.D. will be ready, a few words of wisdom from 37signals, the small, zippy, famous software company:

<blockquote>Software development is inherently unpredictable. There are just too many moving parts and ice tips that turn out to be icebergs.

If you treat the estimate as a “best guess based on the limited information available to me before I start the work”, though, you’ll change the frame and break the cycle of deadline anguish. Now the task becomes collaborative and you can share new discoveries with the stakeholders.</blockquote>

Read the whole thing.

In the following video you can see Syntensity being run inside a browser, as a plugin:



This is a followup to my post from last week, 3D and the Open Web. After the speculation in that post, I got to coding, and the result is a working proof of concept.


Status

The plugin works, as you can see in the video, and you can enter Intensity Engine servers (including Syntensity's) normally, just as you would with the regular client. This is still in early stages, however, so you should expect some limitations:

• The plugin will currently only build on Linux (where I develop). However the code on which I worked is cross-platform (see below), so this should not be a problem to remedy later. Meanwhile, Linux users can try it out for themselves using the instructions at the end of the COMPILE.txt file.
• Works in Firefox and Chrome, not tested elsewhere (that's Chrome you see in the video).
  
• Mouse input works reasonably well. Keyboard input should work as well, but doesn't, probably for some minor GDK reason I will look into later.
  

Technical Details and Notes

• Built using the O3D plugin code (which in turn is closely related to the Chrome codebase). The O3D code is not meant to be a general-purpose basis for browser plugins in general, so it took some hacking to get things working, especially to integrate with SDL (which we use for rendering and input). Not surprising I guess. Anyhow, the O3D code was very useful here, thank you to the authors!
  
• The implementation I wrote runs client instances in separate processes, which is good for security and stability. In other words, the browser plugin is a small component that runs actual clients (that render, run physics etc. etc.) in separate processes.
  
• Interprocess communication is done using boost::interprocess (Chrome's more powerful IPC turned out to be more complicated to set up, and anyhow it's probably overkill for what we need).
• Very few modifications were necessary in the main Intensity Engine codebase. Rendering is still done using SDL, etc. A couple of minor tweaks were needed here and there, though.
• A combination of Firefox and Chrome turned out to be useful during development - Firefox is easier to use in debug mode, to figure out crashes, while Chrome is more resilient to crashes bringing down the entire browser (although I hear Firefox will be adding a similar feature soon).
• Overall, my conclusion is that the browser plugin approach is not easy (there were several technical hurdles that I ran into, like this) - but it is possible.
  

Other Approaches

As an experiment, I think it is now clear that the browser plugin way is feasible. It's still an open question of whether it is the best approach, or whether one of the alternatives (mentioned in the previous post) would make more sense. I tend to favor this approach though (making our own browser plugin), for the following reasons.

I have gotten no response on the O3D mailing list, where I asked about possible collaboration (like contributing our code to there, to add features games need like networking, physics, etc.). I guess it isn't relevant for them. In that case, it probably doesn't make sense for us to move to O3D - porting the rendering engine would be a lot of work, and it turns out that making our own browser plugin (in part using their non-rendering code) is feasible.

WebGL seems to be favored by some people in the virtual worlds community. It's definitely an interesting technology, but I am doubtful it would work for games, or more specifically action games like we have in Syntensity, for several reasons:

• WebGL is not complete, and WebGL's performance limitations are not yet clear (and not sure when they will be).
• WebGL + JavaScript - a pure web implementation - would be too slow for very complex clientside physics. NaCl might help with that, eventually.
  
• Network protocol-wise, TCP (even with nifty things like Comet, etc.) can't give the performance that UDP can, in terms of realtime updates.
• Also, it is unclear if WebGL will ever make its way into Internet Explorer. After all, WebGL is based on OpenGL, which Microsoft has been trying to kill. A related issue is that not only is a major browser hostile to WebGL, but also a major desktop operating system - users often need to manually install OpenGL drivers from the manufacturer's website, which is no better than installing a browser plugin (in some ways worse).
  

That said, the Intensity Engine has always been a web-oriented project, what with JavaScript used for scripting, HTTP for asset downloads, asset and server management done using a web interface (on Django), etc., so if later on WebGL matures into something relevant for us, we can certainly consider moving to it.


Bottom Line

The open source community can have something like a FOSS Quake Live, or more generally a proper open solution for 3D content on the web, from casual stuff to multiplayer action games. The potential here is vast, and it is within reach, basically right now.

If we are to go forward with this, we will need help from the open source community, as browser plugins need a lot of testing on all the different operating systems and browsers and so forth. So, help is welcome. Also, ideas on how to do things would be appreciated, in particular about how to get the licensing issue right - as mentioned in the previous post, if changing our license will get more people on board, we are open to discussing that.