Dev-Corner: the challenges of developing long, plot-heavy FOSS games

Xenogear: Fighting Elly's Gear

Xenogears is one of my favorite games of all time. For those of you who are unfamiliar with it, it was a Japanese RPG for the Sony PS1 in 1998. Not everyone agrees that it was an amazing game, but it's undeniably one of the longest, most plot-heavy RPGs ever made, especially given the fact that most of the plot is in the form of the main story line as opposed to random side-quests that have very little to do with the overall goal. Xenogears is particularly interesting in that each time you play it through, you'll pick up more and more little plot details that you missed the first time around. This is because not only does it have a massive main plot, it also has a massive back story spanning several thousand years, which is only really revealed in small details that are only apparent once you're already familiar with the main plot.

By this time, some of you are probably wondering why I'm raving about a proprietary console game on a FOSS gaming blog. Well, there's another interesting fact about Xenogears that makes it very relevant to the topic of developing games with long, linear plots: it was never really finished. There's all sorts of speculation as to why this might have been; my own pet theory is that upper management decided they'd been waiting too long and paying too much, cut the project short, and told them to shove it out the door as-is. This becomes very apparent when you reach the second half of the game -- it goes very abruptly from a deep, plot-heavy game to an irritating scene where they briefly summarize massive amounts of plot that would have added about thirty to fifty hours of gameplay, before finally releasing you back out into the world to do a few last quests and fight the final boss.

So Xenogears, the Unfinished Symphony of JRPGs, is as example of two really important points:
  • It's difficult to predict the real scope of a project until after you've already committed to it, and...
  • Even big teams with large amounts of money often have trouble finishing ambitious projects in a timely fashion.
Painfully, these issues apply in even greater force to non-commercial game projects (a category that the vast majority of FOSS game projects fall into). On average, FOSS developers tend to have less time and be less reliable than people working on large, proprietary, commercial projects. This isn't because they're less reliable people in general, but because they're real people with real day jobs who are largely doing their FOSS coding work on a volunteer basis. Hence, developers and artists tend to come and go, and even when they're with the project for a long time, they tend to have a wildly variable amount of time that they're able to devote to it, depending on what else is going on in their lives. As such, maintaining a level of coding an artistic consistently equal to that of a large, heavily funded project is a tremendous challenge, because in general you're working with smaller units of work from a much larger team.

So as I see it, if we as FOSS developers want to create the sort of plot-heavy games that I'm referring to (be they JRPGs or whatever else), the odds are stacked against us from the outset. So here's what I'd like to discuss:

FOSS software development undeniably has certain strengths that closed development lacks -- the sheer volume of ideas, as well as the fact that, since FOSS development is primarily done on a volunteer basis, you aren't limited by time or budget in the traditional sense -- your project can continue as long as people remain interested and dedicated, and there's no one in upper management to tell you it's time to throw away your efforts. With this in mind, I'd like to pose some questions for everyone, and hopefully get some discussion going:
  • How can we, as a community, apply these strengths to the sort of project that requires a large development team and a grand, unifying vision?
  • How do you go about convincing a large number of people to join an ambitious project? As someone who has been following FOSS game development for quite a while now, overly ambitious projects tend to make me very skeptical. How do you overcome this skepticism and convince people to help you out, if you're dealing with the sort of project where it's not practical to start small?
  • Once people are on board, how do you keep the quality consistent? How do you keep a ton of people interested in working on a grand plot line that's already been fleshed out essentially from start to finish? FOSS developers need (and deserve) to give input to the projects they're helping with. How do you maintain a vision while simultaneously leaving room for input?
  • One bit of advice I find myself giving out over and over is not to be too ambitious to start with. Sometimes, though, you need to be ambitious in order to make a project work. How can you divide things up in such a way that you can be ambitious yet still start small enough to get your project going?
Anyway, I'm serious about these questions. I've been giving ambitious projects (not a particular ambitious project, but rather the idea of them in general) a lot of thought lately, and I'm hoping that maybe we can put our heads together as a community and come up with some sort of strategy for tackling them.

I'd love to hear your thoughts!

Peace,

Bart K
Founder, OpenGameArt.org

When three became two - Glests Uniting!

So, to all those familiar with the Glest project...

Not familiar? Glest is a popular 3D RTS that wowed the Free gaming scene with it's high quality graphics and polished gameplay back when it was released in 2006.

...it has evolved into 3 distinct codebases, with differing features:

  • Glest
    The original Glest, which is barely developed any more and suffers from significant issues that will likely never get addressed, and lacks many features compared to the continuations.
  • Glest: Advanced Engine aka GlestAE
    A community-led continuation of Glest by adding features and rewriting significant portions of the Glest codebase.
  • Mega Glest
    With frustrations growing about the lack of stability of early GlestAE work, and the length of time between releases, a prolific modder started to add key features such as improved multiplayer, a 'mega pack' of mods (which inspired the name), and port useful changes back from GlestAE - the result was MegaGlest.

For some good videas of both forks, go to player UltiFD's youtube channel.

My impression of the different development approaches for MegaGlest and GlestAE is that MegaGlest development is driven by a "whatever works" mentality to make rapid improvements and bring more features to players. GlestAE development seems to be based on a much longer term outlook, with most work being fairly significant in nature and few basic improvements.

Where are they now

Both MegaGlest and GlestAE have remained much lower profile than perhaps the efforts of the developers have deserved. Whilst Glest remains popular, and enjoys many downloads due to high Internet profile, there is no mention of MegaGlest and GlestAE on the homepage and only people diving into the forum will discover them.

Lacking features and stability, players who fall away after trying Glest may have stuck around if they encounter MegaGlest or GlestAE, but they are unlikely to ever try them. Hopefully this will change now MegaGlest has an amazing website and will start to gain an Internet profile of its own.

Another issue is the increasing amount of time spent porting improvements between the two forks.

A further issue is that, since GlestAE has features that MegaGlest doesn't (and, to a lesser degree, vice versa), there is an increasing divergence in the modding communities.

Glest forms to join forces?

Well, the story may yet have a happy ending. After a brutal conflict, with bloodshed, riots, toppled dictators, eathquakes and... wait, I'm looking at the wrong screen...

After much pressing by Internet trolls and well wishers, it seems that a joining of efforts is in the offing.

Even if the efforts do merge, they may still remain separate entities. Reading through the post, there's talk of official liasons between the projects and all sorts. It seems a bit more complicated than you might expect.

There's even a distant hope that the resultant efforts of the GlestAE/MegaGlest merger may result in Glest 4.0 if the community finally takes over the now-abandoned Glest project.

In Other Glest News

Glest forks (MegaGlest, at leasT) now can have cliffs! This opens up a lot of possibilities when it comes to map design and gives the game a bit of vertical depth, making it look cooler (in my opinion - and I am incredibly cool).

Somebody with a peculiar middle name is making a fully-3D Glest-inspired game called GlestNG - it will use Glest assets but otherwise be completed written from scratch using Ogre3D. Will it ever become playable? Who knows, but it's intriguing nonetheless. So just when two forks merge, another project arises to take the spare seat. Hah!

A completely cool mod Annex Conquer The World (moddb) has been teasingly dangled in front of us, with acclaims already including: "Easily the best Glest mod since the original Magitech!!"

Let's hope it gets released as Free software! ;-)

Engines of War: Not dead!



I made the mistake of writing the Spring DOTA-like game Engines of War off as dead the other day; I could not have been more wrong. In case you are unfamiliar with the term DOTA-like, the gameplay basically consists of controlling a single hero "Engine" unit and battling waves of AI controlled units, as well as opposing player controlled Engines.



They released a playable alpha a couple of weeks back with a very un-TA like UI and gameplay (take that Julius :P). So yeah, check it out!


Lugaru animations, maps and skeletons are free (ShareAlike)

Remember when we talked about Lugaru getting ripped?

I just got reply (twice) from Wolfire that the licensing information described in this file is correct. [first ticket (img) | second ticket (img)]. Probably the permission was given in private conversation or in the hidden Wolfire forum.

I'm so glad they did license hard-to-recreate data as open content! Hopefully some completely free/open source project will come out of this. (There are many more steps/files to go though.)

Dev-corner: m64's Development Lessons and Agile in Free Open Source Game Development

In his first Lessons from Bulletstorm post, m64 talks about the importance of Level Design, Editors, Core Gameplay and Mechanics Tweaking for open source games (although most is general gamedev related).
First, a disclaimer – Bulletstorm is a big, single-player heavy, action game. If your game is different, the observations might not apply. Some observations are shaped by how Unreal Engine 3 works and might not be easily applicable to games created with other engines. Some might be difficult to apply due to technical limitations of an Open Source process – like having to exchange data through the Internet. Without any further ado, here goes.
Speaking of development: PARPG is doing an Agile/Scrum-style one-month sprint. This means that the whole team is working towards a handful of goals and that there are 30-minutes progress and planning reports twice a week [announcement]. The main theme of this development month is "Player Character Creation".

I'm currently contributing as UI designer on the project and am very motivated by the feeling of 'single-mind development' - the knowledge that man people from different spheres work on one main task at a time. It's great to know that not only I finish a design task but that it's going to be working in-game soon.

One of the mockups I produced during the sprint [more mockups]

Please note that this is not a one man's work. I actually created no part of this image but only drew some lines and moved around existing images by other artists! See this file for a list of the work in the mockup.

Do you consider m64's suggestions relevant to free game dev? Are there any principles/structures you have seen in foss game projects that improved development? What do you think of applying Scrum to open source games?

Space Combat

Space combat tutorial [MUTE (couldn't record audio on win)]

Space Combat is a low-end 3d space shooter/simulator and holds promise through it's low-entry-curve tutorial*, which features computer voice. The voice is obviously-generated, although I couldn't find out what software was used.

Asteroid Field in Space Combat

Space Combat runs on Windows (couldn't run it using Wine unfortunately [Linux port request here]).

The project has two positions to be filled:

Mission designer
  • Missions (and campaigns) are XML-files that contain lists of objects and scripts. You can also create own AI-scripts.
3D Modeller
  • The game is in need of 3d objects for space ships, stations, objects...
This makes me wonder: can any developer report success at using SF.net's Help Wanted system? (Even for getting art creators on board? :) ) Or do you perhaps know of other such listings projects could use?

*I didn't get much further yet ^^

FAR Colony Funding & Kambi Engine Donations (Is it possible to make money with open source games?)

The "Is it possible to make money" thread was revived recently. And then two projects I follow announced new funding-'features':

FAR Colony (First Autonomous Remote Colony) is "a game of exploration and space colonization being held in the 23th century". An 8 bit funding page was created [announcement] for it recently. The target is $800 in 109 days. A note at the bottom says:
Of course this project will continue to progress even if my goals aren't reached, it will be more slowly and limited without but will stay alive !
This makes me wonder: how to motivate donations towards open source games (besides making a good game ;) ).

Kambi (VRML) Engine has introduced a fundry.com page for project pledges, feature pledges and donations [announcement]. Fundry.com looks interesting and like an easy way to play the 'donation game', a concept I talked about long ago. Fundry currently accepts paypal only.

The only other open source game project to use fundry.com is the Construct SDK. Fundry has no API yet and writes "Contact us to let us know how you would use it." I think perhaps a Trac integration should be neat..

On a related note: sound specialists can earn $200 on this swamp sound task for Wesnoth.