From The Battle for Wesnoth Wiki
Revision as of 18:24, 29 May 2006 by Xan (talk | contribs) (Reverted edit of TRSaMBa, changed back to last version by Jetryl)


Two years have passed since Sirp started developing Wesnoth. He laid the foundation of today's version and gathered a group of enthusiastic developers to help him work on Wesnoth. In these 2 years the project grew and we worked slowly towards the 1.0 release, while fixing bugs and staying true to the KISS philosophy. This is probably one of the main reasons why this project succeeded where others had failed.

Now with the 1.0 release just behind us, it is time to look forward and decide what we want Wesnoth to become and state goals we want to reach for the 2.0 release. This document describes a proposal for a roadmap towards the 2.0 release.


The current development method is that of "evolutionary programming". This means that the project started out with a simple prototype, and from that point, developers worked on the code to improve it bit by bit, without a grandiose, pre-planned design. Thanks to this method we now have a group of dedicated developers and a game which has reached 1.0-final.

Developers have made efforts to modularize wesnoth; For example, the network code and the widgets system are independent modules. Unfortunately, there are some parts of the code that function as 'glue code', code to connect the different modules together and make everything work. One example of the is the display class, which is bloated with all kinds of methods which are remotely related to drawing on the screen. We need to identify this code and create a seperate module for it.

Another thing that needs to be done is documentation. At the moment, it's very hard to see the different modules because most of them don't have their own subdirectories. A developers' document should be created to point out the different modules and their respective APIs.


  • Multiplayer campaigns:

It's currently possible to play multiplayer games; players can play solo or in teams against other players or AI-controlled sides. The next version of wesnoth should allow entire campaigns to be played in multiplayer.

  • Upgrade editor:

The editor is currently under-developed and should be updated. It would be wonderful to have a full-fledged campaign editor with support for multiplayer campaings.

  • Art upgrades:

The artists never stand still and are already working on new terrain art and other pictures, sounds, music, etc.

  • More translations:

Wesnoth is currently being translated into 30 languages (not all are complete). It would be nice if we could increase this number.

  • Improved GUIs:

We need a GUI manager to manage the GUIs in and around the game, both to make it easier to create GUIs and to make GUIs more flexible. This GUI manager should be a wrapper around the SDL package, with a clear API, and should remove the current polling method.

  • Replacing SDL_ttf and SDL_net with our own code:

SDL_ttf and SDL_net package are said to be inflexible and force us to write bad code; also, they don't support certain essential features, for which the new version of wesnoth is hopefully going to replace those dependencies, either with alternative packages or our own code.

  • Input method support for all the languages that require one along with full UCS4 codepoint range in textbox.
  • Procedural particle and sprite engine:

Relative to ground position, it should be possible to create "animation objects," existing purely for graphical flair, which travel along a scriptable path. These could be instantiated by WML events, during the animation of a unit, or based on the location of objects, including units and terrain. Both dot-based particles, and sprite-based entities should be possible.

Examples of use would include such things as smoke rising from fires (including the offensive variety), fire effects themselves, such terrain niceties as snow drifting off of mountains, leaves falling from trees, or water splashing against the rocks.

New architecture

As mentioned above the development focus of Wesnoth 2.0 is going to be slightly different than the development prior to Wesnoth 1.0. In this section I'll propose a design for Wesnoth 2.0.

- Modular

As said before, we wish to make wesnoth totaly modulairized. The 'glue code' needs to be removed and put into its own module. Doing this will result in clearer code which will make the development of Wesnoth easier.

The modules that are already in place should be moved to their own subdirectories, so that it is clear which files belong to what module. Each module should be defined in its own namespace and the API should be documented.

Perhaps as a next goal, we can give people responsablitiy of a module. This'll take some load of the head developer (Sirp) and divide it among the module maintainers.

- Design

The design of the new modules isn't yet available but is in the making. The following list gives an idea of the modules which can be created:

  • Wesnoth Core - The game core with mostly the game logics, almost all modules depend on this module.
  • Editor - The Wesnoth editor
  • Server - The Wesnoth server
  • Networking - The Wesnoth networking code
  • Data - Units / Terrains / Game data
  • GUI Manager - Dialogs, menu system, input devices

- Old code

Wesnoth already has several modules in place. These modules, as said before, should be placed in their own subdirectories and should be in their own namespaces. However, before we do that, we should evaluate if these modules can't be further split and relieved of 'glue code'.

- Keep It Simple Stupid!

KISS has brought us where we stand today and it would be unwise to simply flush this philosophy down the drain by introducing a brand new, top-down design. We use evolutionary programming to meet our goals, and this means that modules will only be split or created if it is necessary to meet one of those goals. Not just because it is cool or neat.


Wesnoth 1.0 just been released. We've created a new branch on the SVN server to enable developers to work on the 1.x release. Fixes and graphical upgrades appropriate for both branches will be propagated to both.

We won't create a timetable, because, as our friendly IRC citizen wesbot says, "IIRWIIR". But, we will point out the goals we have for the various releases. With each release we will work toward a modular design to meet our goals for that release.

A diagram of the schedule will follow as soon as a clear design has been approved and development on the 1.x release can start.

Project management

The current project leader is Sirp. If we decide to assign module owners we'll list them here.

- The Wesnoth dev. team Template:Home