MultiplayerContent

Multiplayer campaigns are working again in versions 1.3.5+, they are broken in both stable and development versions of Wesnoth prior to 1.x.5. Check the forums or bug tracker for more information.

Building multiplayer campaigns

Both the stable and development versions of wesnoth have basic support for campaigns that can be played in multiplayer mode, with your friends, or even with an AI. Since version 1.1.8, more features and support have been added so we recommend a versions 1.1.8+. There will still be some things that don't work as expected as multiplayer campaigns are an area for exploration. While you can and should test your work in hotseat mode, there are a number of things that might behave differently under real network conditions (mostly affecting scenario and side parameters). Keep this in mind and make sure to test your campaign over the net, too. This page only documents the differences between writing multiplayer campaigns and single player campaigns, so you might want to read up on BuildingCampaigns and BuildingMultiplayer first.

The campaign file

Multiplayer campaigns do not use the [campaign] tag. As a result of this, multiplayer campaigns only support one difficulty level, though you could support more with enough WML, if you're feeling ambitious. The "campaign file" should look something like this:

#ifdef MULTIPLAYER
{@campaigns/My_Campaign/scenarios}
#endif

Anything that you would normally put in the campaign tag now goes into the first scenario, if it's supported there. The order of scenarios is determined by next_scenario tags, just like in single player.

Scenarios

A scenario in a multiplayer campaign is almost identical to a scenario in a single player campaign. You only need to change the following:

The [scenario] tag should be replaced with a [multiplayer] tag.
The next_scenario key points to the id of the next scenario.
Every scenario after the first should have allow_new_game=no inside the [multiplayer] tag. This will prevent it from showing up in the map selection menu. This does not work in v1.1, but it causes no harm, and it will work in the future. (This still doesn't work in 1.2.2, and even prevents your campaign from working. I suggest you leave this commented out until the bug gets fixed.)
In v1.1, every scenario in the campaign will appear on the map selection menu, so be sure to include your campaign's name in the [multiplayer] tag's name key. Alternatively, include a warning like "DO NOT PLAY".
Each human-controlled side needs to have a controller=human key defined in their [side] tag to work in network mode.
Each human-controlled side also needs to have a save_id defined inside their [side] tag. Each side's save_id should be unique, and it should be the same in every scenario. Without this, your recall lists and leaders will not carry over from one scenario to the next.
Each human-controlled side has to have a leader type= definition in every scenario except the first one . It doesn't matter which type you choose cause the type set here gets replaced by the actual leader in the recall list.
Each AI-controlled side should have allow_player=no in their [side] tag.
The [story] tag will only display for the first player (or maybe it's the host player). You'll have to use [message] tags in the start event if you want everyone to read the story.
If you have a file containing macros, it must be referenced by every scenario, since there is no proper campaign file to include it from.

The first scenario

The first scenario might need some extra work, because the settings from the multiplayer dialog will override the settings in the scenario. However, most of the multiplayer settings can be overridden in the prestart event.

Use a macro like this to force a side to have a particular type of leader.

#define MP_SIDE SIDENO TYPE DESC
        [store_unit]
        variable=oldunit
        kill=yes
                [filter]
                side={SIDENO}
                [/filter]
        [/store_unit]

        [unit]
        type={TYPE}
        description={DESC}
        unrenameable=yes
        side={SIDENO}
        x,y=$oldunit.x,$oldunit.y
        canrecruit=1
        [/unit]

        [clear_variable]
        name=oldunit
        [/clear_variable]
#enddef

Other useful tags include [set_recruit], [modify_side], [modify_turns] and [remove_shroud]. There is currently no way to remove fog. You might also want to use experience_modifier=100 in the [multiplayer] tag.

Custom units

Since there is no [campaign] tag, there is no natural way to include custom units in a multiplayer campaign. However, there are two workarounds. One way is to use EffectWML or [store_unit] to modify a mainline unit. The other way is to make your custom units available via an era, or by dropping them into ~wesnoth/data/units. If you go this route, using an era is better, because you can keep the units in your campaign directory.

Current Bugs

linger mode introduces a bug

You can completely circumvent this problem as a host if you tell your players to leave linger mode (by clicking "end turn") before you do so. Only if the host leaves linger mode last will the game progress with all players. The download of the next scenario will not start before the host ends linger mode (but it will be at 0% downloaded), so an impatient player may be inclined to abort the game beforehand. Inform your players.

OOS on recalls

All observers will get OOS on the second and following scenarios. Giving an observer control of a player side will not allow that player to recall. You need to [i]save and reload[/i] if you need to hand control to an observer.

[story] is unavailable over the net

All your carefully crafted [story] information is not available to players who haven't downloaded your content. It's thus not a reliable way to share the story with all players.

allow_new_game=no

Still doesn't work properly. I recommend not using this right now.