Battle For Wesnoth Seeks New Developers

jones_supa writes: Twelve years ago, David White sat down over a weekend and created the small pet project that we know today as the open source strategy game The Battle For Wesnoth. At the time, Dave was the sole programmer, working alongside Francisco Muñoz, who produced the first graphics. As more and more people contributed, the game grew from a tiny personal project into an extensive one, encompassing hundreds of contributors. Today however, the ship is sinking. The project is asking for help to keep things rolling. Especially requested are C++, Python, and gameplay (WML) programmers. Any willing volunteers should have good communication skills and preferably be experienced with working alongside fellow members of a large project. More details can be found at the project website.

Comments

Here's a thought: Just freeze the project

[Anonymous Coward]

I think it's time for Wesnoth to declare itself in deep freeze. Stop tinkering with the project. Do what professional game developers do: Freeze the format of game definition files. Don't change them, breaking third party addons, every time you release a new version of Wesnoth. In the linked article, this developer whines about "unmaintained mainline campaigns". If the WML (Wesnoth's own language used to describe game rules and campaigns) did not change with every Wesnoth release, breaking third-party content, content developers would be able to spend time making better compelling content instead of playing the "catch up with the developers' arbitrary API changes" game.

The Wesnoth developers did this to themselves. They now have 10, count that 10 unmaintained campaigns in the main game. If Wesnoth was properly managed, those campaigns would be fully functional today. The Wesnoth development team did not have the discipline to keep the content interface stable.

Re:Here's a thought: Just freeze the project

[del_diablo]

No.
Lets say you make a module.
You finish it.
And you rid it of bugs.
After a few months, when you don't really care about that project, a update arrives.
The update breaks the scripting language, and you get angry or scared eposts about your module. They want it to work on new and shiny.
So you fix it....

How many times do you repeat fixing it, before you get tired of fixing it?
I expect projects like Libretro, a frontend for Emulators, to eventually reach this point. Where at some point, people will only contribute ports to stable, and only towards the next stable if the emulator is still alive.
And I am honestly not sure what projects will compare.

Re:Here's a thought: Just freeze the project

[Anonymous Coward]

you're one of the lazy cunts

I'm just a passerby but seriously, do you expect people to not have a life? Do you expect everybody else to maintain stuff forever and not be able to develop new stuff because they are forced to go back to their previous projects? Ever wondered why many open source projects seem more like a graveyard than a lively bazaar? I've been part of free software projects which were maintained with thought and care for other developers and projects which broke compatibility at each version. Guess which ones had more success?

Just like you taunt other developers as "lazy cunts" for not upgrading their part every time, you could taunt the original developer a "lazy cunt" for not doing their work properly or offering a backwards compatibility layer or at least a migration tool. But yeah, naming everybody else cunts solves stuff. Maybe that's also the reason nobody wants to step up, because they don't like being named cunts?

PS. Been a developer maintaining backwards compatibility on developer libraries for many years, there is no better joy than taking source code I wrote 10 years ago and recompiling it with a newer version of a library (sometimes even on a platform it wasn't available originally!) and have it work out of the box. But hey, I had to not be a cunt and force others (and myself) to upgrade at each release version...

Thanks for all the turns

[Squiggle]

I have many fond memories of wasting too much time playing Wesnoth. Thanks to all the people who brought the game this far and here's too many more years! /cheers

Sometimes popular things die.

[jellomizer]

I miss the single player adventure games like from Sierra and Lucas Arts where you can engross yourself in a story game line, and have work to solve puzzles and you celibate when you continue the story plot, without having to use twitch like hand eye coordination, or play online with a bunch of people just trying to mess you up.

But those times have ended. It is too easy and tempting to get spoilers on line, people tolerance towards game frustration has diminished...

Now he made a popular open source game, people liked it and it grew for a time. That is great... however times change, and popular games soon become tiresome. Updates and fixes and new content doesn't really excite as much after a while.

There isn't really that much to gain in Open Source games, because of the entertainment value of the game vs practical value. A game will offer a few months of joy perhaps a couple of years, then it will get old and tiresome, and they will be a new one out. You are better off selling it make a lot of money from it, then go on to new projects once it has peaked. I am not trying to be Mr. Anti Open Source, but Open Source works better on serious infrastructure type of projects, Operating Systems, Web Servers, Databases, programming languages... These tend to have long term demand, and invested interests on maintaining the project, including full time support. If my company is dependent on the success of an Open Source project, it may be useful, to hire resources to contribute to it, it may be a better value then buying stock into a closed source company, as you are actively contributing you get a better say on what goes on in your critical infrastructure software needs.

It's actual work

[Dutch Gun]

What you're asking for is developers to volunteer their time to work on what is the most difficult and least-rewarding part of game development - bug-fixing, maintenance, and compatibility issues. As a contract programmer, I get paid a lot per hour for helping out projects up against a deadline. It's difficult, frustrating work, and it takes me several times longer to find and fix a bug than a regular dev who has been working on the project for the last few years. Even so, they pay me to do this, because any bug I do find frees their internal devs to fix other issues.

In short, it's *real work*. There's a reason you generally need to pay people to do this. The previous devs have already finished the fun part of the game - designing and building the game from the ground up. What's left is now is the hard, shitty work - trying to fix all the bugs, and work around an old, crusty engine that can't seem to keep from breaking scenarios from release to release - signs that there are serious under-the-hood problems (which they sort of admit themselves).

I wish you guys all the best, and hope you find some philanthropic devs to help you. Unfortunately, any free time I find myself with goes into my own personal project. There's simply no way I can spread myself even thinner.