BuildingCampaigns

This page describes how to make your own user campaign for use with Battle for Wesnoth. Please note that this document is not normative - its author is not a Wesnoth Developer. I'm simply reporting on what works for me, and on what developers have prescribed elsewhere. If you see any errors, please fix them.

See also forum post Eight things to check when your scenario doesn't load.

There are several steps to building a single player campaign in Wesnoth. The mechanics are covered in the sections below:

• BuildingCampaignsDirectoryStructure
• BuildingCampaignsTheCampaignFile
• BuildingCampaignsThePBLFile
• BuildingCampaignsCreatingScenariosAndMaps
• BuildingCampaignsAddingUnitsArtworkMusicAndSounds
• BuildingCampaignsBalancing
• BuildingCampaignsDistribution
• WesCamp (How to make your campaign translatable, and get in touch with translators)

What follows is a collection of advice to aspiring campaign designers extracted from the Wesnoth fora.

Start with Something Manageable

If you set out to make an epic campaign spanning the whole history of Wesnoth, you'll likely (not necessarily, though) become bored or frustrated along the way somewhere and give up. It's much easier to start with a small story and add elements to it than it is to cut an epic down to the lenght of a haiku.

Shade (author of The Rise of Wesnoth) wrote:

    I started TRoW last April, even after it was scenario complete it was still eating all of my free time
    (Time not spent sleeping, at school / work, or with loved ones / friends) until mid-November...
    Even now there is still bugfixing and a couple of things I'd like to add... and keeping it up to date with the
    game engine and any new happenings on the WML front... so there is still quite a lot to keep you busy after you are
    done...
    The forums are littered with half finished epics...
    Before you commit to an epic think long and hard. I don't want to discourage you too much...
    But it is a lot of 'work' (& fun)

Story First

What separates a campaign from a single scenario is the ability to tell a story. Consequently, what keeps people coming back for more is a good, interesting story mixed with good, interesting game play. If you have a good idea of where the story of your campaign is going when you start, the little piece will fall into place much more easily. After all, it's worked for Pixar!

Scott (author of Liberty, the outlaw campaign) wrote:

    Here is how I wrote Liberty.

    1. Write a rough story and plot
    2. Decide how many scenarios you want to have
    3. Divide the story between the scenarios so you can decide what will happen in each scenario
        - where are you?
        - who are you fighting and why?
        - what do you have to do in this scenario?
        - where does the hero want to go next?
    4. Decide on the "hook" for each scenario. There are a lot of different possible setups for scenarios, and
    if you want to avoid the boring repetition of "Kill the 2 enemy leaders" you can listing out interesting
     combinations of enemies, allies, shroud/fog, day/night effects, recruiting and terrain situations, etc.
    and pick a good mix to keep the combat interesting and fun.

    All of this has happened without doing any WML, but now you have enough to start coding.

Share Early

Don't be shy to post whatever you've created for others to look at. We all had to learn too, and there are many people on the Scenario and Campaign Development forum (http://www.wesnoth.org/forum/viewforum.php?f=8) who are eager to help people learn.

Turin (author of Eastern Invasion) wrote:

    I'm working on a loyalist campaign now. I already have the basic plot. I am wondering if anyone wants
    to playtest my completed levels (i am done with two).  Thus i want to know if i should just post the new files
    as attachments, or what. There are two map files, two scenario files, an image file, a unit file, and you have
    to change the game file to access the campaign from the 'campaign menu. So tell me how i should make them accessable.

Steal Often

There are too many quotations to pick one for this maxim. The best way to learn how to do something is to copy it from someone else's campaign. It's polite to ask first, and most Campaign designers are happy to see small bits of their WML living in other campaigns. It's generally poor form to copy whole scenarios, maps, and campaigns, though. And especially poor form to do so without permission.

Next:

• BuildingCampaignsTheCampaignFile

The Old Page (Deprecated)

There are two parts, usually, to a scenario: the scenario itself, which is written in WML, and a map, which is a plain text file, usually created with wesnoth_editor. The map can also be included in the scenario, though that makes it hard to edit. Probably the best way to start is by designing the map, then create a simple scenario file, then alternative between playing and modifing your scenario file until you are satisfied with it.

There is a very good tutorial on this under the BuildingScenarios topic. Unfortunately, it is a little out of date. Once you have read that, look at the sources to the MainlineScenarios, which are installed with wesnoth itself (but beware, these campaigns are not set up in the same way a user campaign should be - see below). Prescriptive documentation of WML can be found at ReferenceWML.

Of course, before you can play a scenario, you need to install it...

Your campaign file should contain three things:

1) a WML [campaign] tag,

2) WML preprocessor instructions to load your scenarios, units, etc. and

3) (if your campaign adds images or sounds) a [binary_path] tag to help load those files.

For reference documentation on this, see CampaignWML.

Here's the example from the forum post, slightly tidied up:

[campaign]
id=sample_campaign
icon=some_icon.png
name= _ "Sample Campaign"
define=CAMPAIGN_SAMPLE_CAMPAIGN
first_scenario=some_scenario_id
difficulties=EASY,NORMAL,HARD
difficulty_descriptions= _ "&easy_icon.png,Easy;*&normal_icon.png,Normal;&hard_icon.png,Hard"
[/campaign]

#ifdef CAMPAIGN_SAMPLE_CAMPAIGN

[+units]
{campaigns/Sample_Campaign/units}
{~campaigns/Sample_Campaign/units}
[/units]

{campaigns/Sample_Campaign/scenarios}
{~campaigns/Sample_Campaign/scenarios}

[binary_path]
path=data/campaigns/Sample_Campaign/
[/binary_path]
#endif

There are two important features of this that aren't self-explanatory. First, the use of the #ifdef. Wesnoth loads its configuration once at startup, and then again when you start playing. The first time, CAMPAIGN_SAMPLE_CAMPAIGN will not be defined, and your scenarios will not be loaded, nor will the [binary_path] tag be used. The second time, when the user starts your campaign, CAMPAIGN_SAMPLE_CAMPAIGN will be defined, and the scenarios will be loaded. This prevents your campaign from treading on others' toes (for example, if two user campaign are installed this way, they can both give the same name to a scenario without clashing). It also means that you can customise global wesnoth settings (the terrain configuration, for example) on a per-campaign basis.

However, notice that [+units] is not inside the #ifdef. This is due to a bug in Wesnoth programming that causes savegames in your campaign to be corrupt if you try to put it in. Unfortunately, this means that you need to make sure that none of your units conflict with other user or mainline units. This sounds completely wrong, [units] tags should be inside the campaign

1. ifdef at least since 0.9.0, can someone please confirm if this

is still an issue?//

Second, the [binary_path] tag allows images and sounds to be installed inside the {campaigns/Sample_Campaign} directory instead of the default Wesnoth path. (Note: If you want to use one of these images as your campaign icon, you need to move [binary_path] out of the #ifdef.)

Now, you install all the rest of your campaign under the directory {campaigns/Sample_Campaign}. Maps go in {campaigns/Sample_Campaign/maps}, scenarios go in {campaigns/Sample_Campaign/scenarios}, images go in {campaigns/Sample_Campaign/images}, and so on. This makes it easy for a user to delete your campaign from their system, and is required in order to upload it to the campaign server (see bottom).

You can refer to your images, installed this way, as "some-image.png" (that's the work of [binary_path]), and include maps by using the preprocessor syntax "{@campaigns/Sample_Campaign/maps/mymap}" with the map_data attribute. You might also define a preprocessor macro to abstract away from the title of your campaign. For example, you might write the end of the campaign file like this:

...
#ifdef CAMPAIGN_SAMPLE_CAMPAIGN

#define MAP NAME
  map_data="{@campaigns/Sample_Campaign/maps/{NAME}}"
#enddef

{@campaigns/Sample_Campaign/scenarios}

[binary_path]
path=data/campaigns/Sample_Campaign/
[/binary_path]
#endif

Now your scenarios can refer to their maps by saying "{MAP mymap}", without having to know the name of the campaign they're included in, which might be helpful - if you ever change the name of your campaign, you don't want to have to edit all the scenarios.

See Also

• Create
• BuildingScenarios
• ReferenceWML
• UserScenarios
• ExternalUtilities

Creator's Guide

Add-on Structure • Maps • Scenarios • Campaigns • Multiplayer • Units • Distributing Content