SoC Ideas Map 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 page predates Wesnoth 1.5, it was written when the editor was a separate program, and the successful replacement is documented on Map Editor Ilor.

Map editor

The map editor in Wesnoth serves two goals, making it easy to create a new map and helping the terrain artists to test their new terrains.

General description

The current editor hasn't been actively maintained for quite a while and the quality of the code isn't up to par with the main game. The student will either revive the current editor or start from scratch, the latter will probably be easier. When rewriting from scratch the student can pick the language of his/her liking as long as the result is crossplatform (at least Linux/Windows/OS X).

(Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)

Some of the things the new/revived editor should be able to do:

• Include all features of the current editor.
• When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
• The editor needs to be able to handle so called custom terrain, these are terrains used in maps but not loaded by default.
• The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
• The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
• Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.

Required knowledge and talent

• The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
• The student needs to be able to make a user friendly user interface.
• Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.

Milestones and deliverables

• The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
• From this list the student needs create a sublist of items he/she will be able to do within one summer.
• This needs to be presented and discussed with the mentor(s).
• The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

See also

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