sucess factors for open/free source driven apporach games

[Arax]

Hello,

I have the opportunity to held a presentation about open source/free source driven approach.

I like to take Battle of Wesnoth as an reference.

I would like to discuss the following questions:
+ What are the sucess factors of Battle of Wesnoth?
+ Are there some detailed links?
+ Which pitfalls should be avoided?
+ How to start a own open/free source driven projects sucessfully?

All the best,

Guido
Worlds of Legends
The best adventures are in your mind!

[zookeeper]

Just my personal opinion:

+ What are the sucess factors of Battle of Wesnoth?

Might sound obvious, but I think it's first and foremost the fact that (obviously) it's actually a good, interesting game in terms of gameplay and its got a lot of depth (depth of gameplay, lots of campaigns, multiplayer, and endless modding possibilities which people are constantly putting to good use). Also, it's an original game; not a simple clone of an old commercial game and featuring Tux like so many other open source games tend to be, which means that even people other than linux geeks will actually gladly play it. And finally, it's pretty accessible. You can easily just start playing it and learn how things work. On the easiest campaign difficulty levels the initial barrier for entry is pretty low (even though it's a real challenge to master the game).

I'd also count the ease with which players can create new content (campaigns, eras, scenarios, etc) as something which I'd believe has definitely kept lots and lots of people around to create the community we have, either because there's always something new for them to try out or because they're authors themselves and get the satisfaction of people playing and enjoying their work, both of which are quite an incentive to stick around, as opposed to only playing what the core developers are able to come up with.

Well, actually I'm not sure what has created the large community in the first place. Lots of games seem to have really good modding possibilities, but it seems that they simply lack the large player base to really keep many of them alive. I'm not sure how Wesnoth crossed that barrier. Maybe it's just that...Wesnoth is such a good game?

[Viliam]

Start a project that you are able to finish alone, if necessary.
People will join you, but they may come too late, or not with exactly those abilities your project needs most. For example if your project heavily depends on 3D models, and you are not ready to do them, this is bad, because few people can do good 3D models, few of them are willing to do it for free, and even those have many other available projects to join. On the other hand, if you are determined to complete the game alone, other people will join more happily, because they know their contributions will not be wasted on an unfinished project.

Wesnoth uses work of hundreds of people, but is not dependent on any of them, except during first years it was dependent on Dave. We are happy to have people doing great graphics; but even without them Wesnoth would exist, it would just look ugly. We are happy to have many campaign authors; but even with one campaign Wesnoth would exist. Etc. So if half of the team would leave tomorrow, Wesnoth would survive; at least if enough developers would stay. And this is good to know, because you cannot expect contributors to stay forever.

Use free resources.
For publishing game files use SourceForge and Freshmeat. For discussion forum use phpBB. For collaborative web page use MediaWiki. For advertising the game use Linux Game Tome. These are free, especially if you can find a volunteer to take care of them, so they will not take developers' time; for example a public forum needs moderator. (Other good possibilities, not systematically used by Wesnoth could be Blogger for announcements, and Camstudio and YouTube for capturing and publishing game videos.)

Support many platforms.
In broad stereotypes, you will get programmers from Linux release, artists from Mac release, and other contributors (scenario designers, translators, etc) from Windows release. Translations will bring your game to even more people. Even people who will not contribute, may show your game to other people, who will. Make it trivial to install and run the game.

Keep it simple, resist adding too many features. Make stable releases.
People will always suggest new things, usually based on their other favourite games. If you try to implement them all, failure is guaranteed. The code will grow until it becomes unmanageable; and most coders will prefer playing with new features than fixing existing bugs. Sometimes you should do a bug-free (almost) version, to satisfy players. If you want to receive the best ratings (among free games), your game should be pleasant to play; and the development version usually contains many unpleasant moments.

No democracy.
No matter how much it may offend someone, people who do not contribute to the game are not equal to people who do. Many people are smart enough to propose how things "should" be done, especially if it only means work for others, but only few will do it. Feel free to reject any such advice, even if it is reasonable; otherwise you will just become everyone's slave, and you will not be able to satisfy them all. Even if the idea is very good, but no one is willing to implement it, just say no.

Make it easy to contribute.
Because Wesnoth uses external CFG files, it is easy for people to write their own scenarios and campaigns, even if they do not know programming. This is great, because it allows creating a lot of content without giving much work to developers. Of course also writing a parser of CFG files, adding new WML features, and maintaining add-on server functionality takes some developer time, but it seems like a very good investment.

Let the community discuss, and moderate the discussion.
It is good to let people talk to each other, as they will create groups focused on some aspects of the game, such as graphics or translations, or later even people playing one specific campaign or multiplayer scenario. When anything is interesting to a group of people, they can discuss their ideas. Just remember that any conclusions of these discussions are only suggestions, there is no majority voting.

Some people will bring topics which are not related to the game development. Sometimes it is interesting and harmless, for example publishing players' photos or talking about hobbies. These are OK, unless they waste resources, but should be separated from the game development talk. Some topics are highly sensitive, such as politics and religion; they usually only bring anger and waste energy, so these should be avoided. Also it is good to ban offensive speech, etc. The goal of community is to contribute to the game, because there are no other places for this goal; but there are hundreds other places for offensive discussions, jokes, etc, so when it becomes harmful, do not hesitate to remove it.

[Jetrel]

/me seconds both zookeeper's and viliam's comments.

Start a project that you are able to finish alone, if necessary.
People will join you, but they may come too late, or not with exactly those abilities your project needs most. For example if your project heavily depends on 3D models, and you are not ready to do them, this is bad, because few people can do good 3D models, few of them are willing to do it for free, and even those have many other available projects to join. On the other hand, if you are determined to complete the game alone, other people will join more happily, because they know their contributions will not be wasted on an unfinished project.

I can't stress this enough. One of the primary deciding factors in why I joined wesnoth was that, despite having crappy graphics, the game was already totally functional when I joined. You could sit down and actually play a game of wesnoth; all the basic gameplay rules worked, the game could be won/lost, you could go from level to level. I knew that 1] the coders were clearly competent, and 2] they couldn't possibly fail to finish, because they were already done. So I knew my work wouldn't be wasted.


Dave knew when he started out that he was making something simple enough that if he were the only guy who ever worked on it, would be finishable, and would still be fun to play (albeit with bad graphics). This "Keep it simple, stupid" is so important as a design point that it's not funny. Be careful - failure to finish a big game project you start can discourage a lot of people for life, especially if they're not young anymore.

[Viliam]

When you are working on a free project, there is no money, and your main reward is a good feeling from a well done project. The problem is this feeling can be ruined not only when you fail to do your part, but also when others fail to do their parts, and the product as a whole just does not work. For example if the coders are unable to produce code that works without frequent crashes and serious bugs, then the game is unplayable, and whatever effort you have put into pictures, music, storyline, or translation, is just wasted time and energy. And if you are not a coder, or do not know this programming language, or just do not have time to contribute by coding, there is nothing you can do about it.

So the careful people are trying to estimate the probability of success before joining the project. It is good if the project shows that it cannot fail, it can only be improved.

[PingPangQui]

I think the speach by Dave at FOSDEM 2008 might be a nice reference to start with.

http://archive.fosdem.org/2008/slides/m ... esnoth.pdf
http://video.fosdem.org/2008/maintracks ... esnoth.ogg