MultiplayerContent
This guide is intended for version 1.6.4 and higher.
A forum thread about multiplayer campaigns in older versions can be found here.
Contents
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. 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
{~add-ons/My_Campaign/scenarios}
#Only needed if you have custom units
[+units]
{~add-ons/My_Campaign/units}
[/units]
#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.
- 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.
- If you want to carry over information for ai sides, they need to have a save_id defined and persistent=yes in their [side] tag.
- 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.
- If you want player's leaders to be recalled, you should either recall all units which can recruit or assign id attribute for them (unique for each leader, the same in each scenario - e.g. "p1" for leader of player 1, "p2" for leader of player 2). See [[1]]
- Each AI-controlled side should have allow_player=no in their [side] tag.
- 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
- To ensure that your scenario settings are not overwritten by the settings from the multiplayer dialog, check use map settings when creating the game.
- If any setttings are still taken from the multiplayer dialog, it is possible to overwrite them in the prestart event. 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.
- Deactivate the Quick replays setting (in the multiplayer lobby), or the [story] tags will not display for you.