Battle For Wesnoth

Web Page: http://wiki.wesnoth.org/SummerOfCodeIdeas

Mailing List: mailto:wesnoth-dev@gna.org

Battle for Wesnoth, or simply Wesnoth, is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned, they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) happened in April 2010. Version 1.10 was released earlier this year, while the current development branch is 1.11. We're early in our cycle, so there are several interesting project available for students to join

Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

• According to Ohloh, a site that collects activity statistics on open-source projects, the Wesnoth development effort is in the top 2% of largest and most active projects
• We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
• More than two thousand downloads a day
• 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
• Best rated game at the Linux Game Tome
• Game of the year 2007, 2008, 2009, 2010 and 2011 at LinuxQuestions.org
• In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games

Wesnoth's most notable features include:

• A mature project with continuing active development and frequent improvements
• High quality artwork: both original graphics and music
• Well -balanced by a tireless team of playtesters
• Fun, unique gameplay
• Even after nearly a decade of development and a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
• Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

Projects

• Improve Wesnoth's engine to allow better transitions between scenarios The idea is to clean up playcampaign.cpp and make loading/saving multiplayer campaigns more stable and less error prone. The code that handles transitions between scenarios should also be improved to make transfer of gold, units and recall lists easier for campaign designers. Other functionality, such as changes to difficulty between scenarios and interaction with GUI2 dialogs could also be added.
• Justas Tomkus: Particle engine for Battle For Wesnoth Implementing particle engine in a library-like fashion, using existing game's graphic functionality and SDL library. Final version of this engine would allow to use it anywhere in map with other drawing functions, given required init is done. In addition to simple pixel drawing, I am ready to implement version where small alpha transparent images are blitted for particles. Color transitions for particles wouldn't be a problem either.
• Simplifying and extending the LuaAI subsystem Right now, the LuaAI system is in a state, where it can be used for artificial intelligence system development for Battle for Wesnoth campaigns, but it's usage is quite complicated and requires effort to get the system off the ground and make it run. To simply to launch a campaign with an empty LuaAI(by empty, I mean, not doing anything) a UMC developer is required to write a couple dozens of lines of code(not even mentioning the bugs that he will encounter on the way). While it seems, that we could simply hide the boilerplate code in a template or behind a macro, the situation is a bit more sophisticated(Later I will describe that in more detail). Instead of running away from this problem, I will work towards an elegant solution, creating an effective back-end system, and a clean user development environment.
• Whiteboard backend polishing My project is to make the Whiteboard code cleaner and to redesign small parts of it to speed it up. The global design of the Whiteboard won't be changed a lot, each part will be reviewed individually. I'm not only planning to improve the Whiteboard backend, but also to document the overall design and each part of it as well as to write a wide variety of test to improve its stability. Moreover, I'll factorise action handling outside of the Whiteboard so that the same code will be usable in all Wesnoth.