Difference between revisions of "MultiplayerContent"

From The Battle for Wesnoth Wiki
m
 
(14 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This guide is intended for version '''1.6.4 and higher'''.
+
{{Translations}}
 +
{{Create}}
  
A forum thread about multiplayer campaigns in older versions can be found [http://www.wesnoth.org/forum/viewtopic.php?t=11349 here].
+
This page is dedicated to the syntax modifications necessary to enable a scenario or campaign to work in multiplayer mode. Only the differences between multiplayer and singleplayer are documented here, so you might want to read [[BuildingScenarios]] and [[BuildingCampaigns]] first.
  
= Building multiplayer campaigns =
+
<b>Note:</b> This page assumes you have a basic add-on set up as described in [[AddonStructure]], as well as some coded content.
  
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.
+
== Multiplayer scenarios ==
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 ==
+
You can play standalone scenarios in multiplayer mode without setting up a campaign (this isn't possible in singleplayer). Simply make the following modifications:
  
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:
+
* In the _main.cfg file, use <b>#ifdef MULTIPLAYER</b> as the load conditional
 +
* In the scenario configuration file, use a toplevel <b>[multiplayer]</b> tag instead of <b>[scenario]</b> tag
  
#ifdef MULTIPLAYER
+
== Multiplayer campaigns ==
{~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.
+
<b>Note:</b> This section is relevant for version '''1.11.6 and higher'''.
  
== Scenarios ==
+
Wesnoth has 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 since some functionality for multiplayer campaigns is still being developed. 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.
  
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 Campaign Tag ====
  
* The [scenario] tag should be replaced with a [multiplayer] tag.
+
Multiplayer campaigns use the [campaign] tag, thus allowing the same campaign to work both in both modes. The only difference is that game also checks for a couple optional tags when campaign is used in multiplayer. They could be found on the [[CampaignWML]] page. Additionally, the '''type''' attribute should be explicitly set to '''mp''' or '''hybrid''' or otherwise a campaign would not be visible in multiplayer.
* 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 [[http://forum.wesnoth.org/viewtopic.php?p=405807#p405807]]
 
* 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 ==
+
==== The Scenario File ====
  
* To ensure that your scenario settings are not overwritten by the settings from the multiplayer dialog, check '''use map settings''' when creating the game.
+
A scenario in a multiplayer campaign is almost identical to a scenario in a singleplayer campaign. You only need to change the following:
  
* 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.
+
* Every scenario which should not be available to start directly, should have '''allow_new_game=no''' inside the [scenario] tag. This will prevent it from showing as an "entry point" in the multiplayer configuration screen. {{DevFeature1.13|?}} This is no longer true, '''allow_new_game=no''' is now the default
 +
* For scenarios that don't use '''allow_new_game=no''', one could make use of '''new_game_title''' to have a custom title. This is useful if the campaign is supposed to have multiple entry points such as chapters.
 +
* Each human-controlled side needs to have a '''controller=human''' key defined in its [side] tag to work in network mode.
 +
* Each human-controlled side also needs to have a '''save_id''' defined inside its [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. {{DevFeature1.13|?}} This is no longer true, '''save_id''' defaults to '''id''', just like in sp
 +
* If you want to carry over information for ai sides, they need to have a '''save_id''' defined and '''persistent=yes''' in their [side] tags. (The same is true for singleplayer campaigns)
 +
* {{DevFeature1.13|?}} You can use '''previous_save_id''' to tell the engine which player shodul control which side. For example if you have a multiplayer campaign and in scenario1 you have two sides with ids Kalenz and Landar, and in scenario2 you have sides with ids Konrad and Delfador you can use '''previous_save_id=Kalenz''' and '''previous_save_id=Landar''' in scenario2 to make sure that the player that previously controlled Kalenz now controls Konrad and the player that previously controlled Landar now controlls Delfador.
  
* Deactivate the '''Quick replays''' setting (in the multiplayer lobby), or the [story] tags will not display for you.
+
== Other Notes ==
 +
 
 +
* To ensure that your scenario settings won't get overwritten by the settings from the multiplayer configure dialog, you can set '''force_use_map_settings=true'''. However, if your campaign is not intended to be played strictly with default settings, you can set it to '''false'''.
 +
 
 +
* If any settings are still taken from the multiplayer configure dialog, it is possible to overwrite them in the prestart event. Useful tags include [set_recruit], [modify_side], [modify_turns],[remove_shroud], and [lift_fog]. You might also want to use <b>experience_modifier=100</b> in the [scenario] tag.
 +
 
 +
==== Synchronization ====
 +
 
 +
When creating multiplayer content, you should be cautious of code that might change on one client but not the other players'. Not doing so can result in an [[OOS_(Out_of_Sync) | Out of Sync]] error. Most [event]s are synced across all clients, but a few still have issues. A full list of safe events can be found on the [[EventWML#Multiplayer_safety | EventWML]] page.
  
 
== See Also ==
 
== See Also ==
  
* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
+
* [[Create]]
 
* [[BuildingScenarios]]
 
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]
+
* [[BuildingCampaigns]]
  
 
[[Category:Create]]
 
[[Category:Create]]

Latest revision as of 04:58, 10 December 2023


This page is dedicated to the syntax modifications necessary to enable a scenario or campaign to work in multiplayer mode. Only the differences between multiplayer and singleplayer are documented here, so you might want to read BuildingScenarios and BuildingCampaigns first.

Note: This page assumes you have a basic add-on set up as described in AddonStructure, as well as some coded content.

Multiplayer scenarios

You can play standalone scenarios in multiplayer mode without setting up a campaign (this isn't possible in singleplayer). Simply make the following modifications:

  • In the _main.cfg file, use #ifdef MULTIPLAYER as the load conditional
  • In the scenario configuration file, use a toplevel [multiplayer] tag instead of [scenario] tag

Multiplayer campaigns

Note: This section is relevant for version 1.11.6 and higher.

Wesnoth has 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 since some functionality for multiplayer campaigns is still being developed. 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.

The Campaign Tag

Multiplayer campaigns use the [campaign] tag, thus allowing the same campaign to work both in both modes. The only difference is that game also checks for a couple optional tags when campaign is used in multiplayer. They could be found on the CampaignWML page. Additionally, the type attribute should be explicitly set to mp or hybrid or otherwise a campaign would not be visible in multiplayer.

The Scenario File

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

  • Every scenario which should not be available to start directly, should have allow_new_game=no inside the [scenario] tag. This will prevent it from showing as an "entry point" in the multiplayer configuration screen. (Version 1.13.? and later only) This is no longer true, allow_new_game=no is now the default
  • For scenarios that don't use allow_new_game=no, one could make use of new_game_title to have a custom title. This is useful if the campaign is supposed to have multiple entry points such as chapters.
  • Each human-controlled side needs to have a controller=human key defined in its [side] tag to work in network mode.
  • Each human-controlled side also needs to have a save_id defined inside its [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. (Version 1.13.? and later only) This is no longer true, save_id defaults to id, just like in sp
  • If you want to carry over information for ai sides, they need to have a save_id defined and persistent=yes in their [side] tags. (The same is true for singleplayer campaigns)
  • (Version 1.13.? and later only) You can use previous_save_id to tell the engine which player shodul control which side. For example if you have a multiplayer campaign and in scenario1 you have two sides with ids Kalenz and Landar, and in scenario2 you have sides with ids Konrad and Delfador you can use previous_save_id=Kalenz and previous_save_id=Landar in scenario2 to make sure that the player that previously controlled Kalenz now controls Konrad and the player that previously controlled Landar now controlls Delfador.

Other Notes

  • To ensure that your scenario settings won't get overwritten by the settings from the multiplayer configure dialog, you can set force_use_map_settings=true. However, if your campaign is not intended to be played strictly with default settings, you can set it to false.
  • If any settings are still taken from the multiplayer configure dialog, it is possible to overwrite them in the prestart event. Useful tags include [set_recruit], [modify_side], [modify_turns],[remove_shroud], and [lift_fog]. You might also want to use experience_modifier=100 in the [scenario] tag.

Synchronization

When creating multiplayer content, you should be cautious of code that might change on one client but not the other players'. Not doing so can result in an Out of Sync error. Most [event]s are synced across all clients, but a few still have issues. A full list of safe events can be found on the EventWML page.

See Also

This page was last edited on 10 December 2023, at 04:58.