SoC Ideas Scenario and Campaign Editor

This page is a candidate for deletion. Someone has decided that this article does not (or no longer) serve a purpose. It may be deleted once suitable time has elapsed for others to contest the deletion on its discussion page.

Reason: this was written prior to Wesnoth 1.5, when even the terrain editor was a separate program. An up-to-date equivalent would be a project planning template and the list of bugs and feature requests tagged "Editor".

Scenario/Campaign editor

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor to make the creative process easier.

General description

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. What exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose (but see the note on Python below). The main ideas would be for the scenario editor to be:

• cross-platform (at least Linux, OSX, Windows)
• easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even not knowing WML)
• powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
• extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

• Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
• Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
• GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
• Decide on base features. ReferenceWML lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
  • WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
  • Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
  • Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
  • Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
  • Story screen editor for campaigns?
  • How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
  • Custom unit animations?
  • Custom multi-hex terrains?
• Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
• WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

Required knowledge and talent

• Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
• Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
• Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
• Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
• Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
• Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

Milestones and deliverables

The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:

• Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
• Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
• Finish design. Should list the intended features and demonstrate how the GUI will work.
• Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
• Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

See also

Summer of Code Ideas - The root where all information regarding SoC is (or better should be) linked from.