The Battle for Wesnoth Wiki - User contributions [en]

SideWML

2014-07-01T21:02:45Z

Thunderstruck: /* the [side] tag */

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides.

* '''controller''': how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves. This is the default setting.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.) Events that would usually occur on the side's turn will not take place. This includes healing (ability, villages and rest) and ''side turn'' events.
** '''a number''': {{DevFeature1.11}} gives this side's control to a side with '''side''' matching the number (multiplayer only).

* '''no_leader''': if "no" (default), then keys describing a unit which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using '''canrecruit=yes''') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are '''type''' (mandatory), '''id''', '''name''' and '''unrenamable=yes''', see [[SingleUnitWML]].

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* '''gold''': the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end. {{DevFeature1.11}}It is used in saved games.)

* '''[fog_override]''' {{DevFeature1.11}} With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[BuildingScenariosShroudData]].

* '''persistent''': whether the side exists in any other scenarios. If ''yes'', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to ''yes'' for sides with a human controller, and ''no'' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog.

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg.

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': {{DevFeature1.11}} the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]).

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another [village] tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

* <s>'''fight_on_without_leader'''</s>: {{DevFeature1.11|13}} this side will not be considered "defeated" until they have no units, for the purposes of determining whether the scenario ends or not. {{DevFeature1.11|15}} This attribute was replaced with defeat_condition

* '''defeat_condition''' {{DevFeature1.11|15}} Specifies when a side is considered ''defeated'' this is checked ''for all sides'', after every player action and at the beginning of every turn.
** '''no_leader_left''': (default) The side is considered defeated if it has no units with canrecruit=yes
** '''no_units_left''': The side is defeated as soon as it has no units left.
** '''never''': The side is never considered defeated.
** '''always''': The side is always considered defeated.

: For the meaning and significance of ''defeated'', see [[ScenarioWML#Scenario_End_Conditions]]

The following keys are multiplayer only:

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. False also prevents this side from being included in shuffle sides. Defaults to yes.

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''chose_random''': {{DevFeature1.13|0}} indicates if a side chose a random faction during creation

* '''controller_lock''': {{DevFeature1.11}} if true then this side's controller ("Player/Type") modification is limited. It is bound to the '''controller''' attribute in [[SideWML]].

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction_lock''': if true then this side's faction is not allowed to be modified.

* '''leader_lock''': if true then this side's leader (type or gender) is not allowed to be modified.

* '''faction''': if valid faction id is provided then this side's faction will default to it.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

{{DevFeature1.11}} N.B. the ''lock'' attributes use [[ScenarioWML]] '''force_lock_settings''' as their default value. I.e. if no value to ''lock'' was set, it will take '''force_lock_settings''' value.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

SoC Ideas Unify SP and MP 2014

2014-02-09T20:23:42Z

Thunderstruck: Created page with "{{SoC2014Idea}} =Description= <h2>Game Engine: Unify SP and MP</h2> Page for the idea: SoC_Ideas_Unify_SP_and_MP_2014 Wesnoth has lots of user made content, but some of ..."

{{SoC2014Idea}}

=Description=
<h2>Game Engine: Unify SP and MP</h2>
Page for the idea: [[SoC_Ideas_Unify_SP_and_MP_2014]]

Wesnoth has lots of user made content, but some of it works only for either singleplayer or multiplayer. To solve this, some of the engine's singleplayer and multiplayer code paths need to be unified and extended.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2014 Student Page&SoC Ideas IDEA NAME
|notcategory=SoC 2014 Not Submitted To Google
|include=#Description
|nottitlematch=SoC2014_Template_of_Student_page
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=

Last year's [[SoC2013_thunderstruck_MP_Campaign_Support|GSoC project]] made it possible to use the same configuration files for both singleplayer and multiplayer campaigns. However, there's still some WML content which is not available for both singleplayer and multiplayer due to being handled by different code paths.

The goal of this project is to unify singleplayer and multiplayer code paths which are responsible for handling configuration files. This would lead to being able to use multiplayer eras and modifications in singleplayer too. As a result of this, some GUI dialogs would have to be created in order for players to be able to use this new functionality.

=Whom to ask about this=
thunderstruck on irc.

SoC People to bug on IRC

2014-02-08T12:46:56Z

Thunderstruck:

{{SoC2014}}

== People to bug on IRC ==
We have prepared a list of people with their areas of competence. This should give you an idea of which areas those people can help you with. Of course you should always ask in the IRC channel first, but these are the most likely people to be able to help you.

=== Coffee ===
Involved mostly in the animation coding and minor bugfixes, Coffee can help with coding questions surrounding unit animations. Boucman is also a good source for animation code, although currently an inactive developer.

=== Crab_ ===
iurii chernyi (Crab) has joined the team in 2009. He restructured Wesnoth AI as part of GSoC-2009, and is an expert on all aspects of current Wesnoth AI codebase. So, he's the person to ask about anything in '''src/ai'''. He also knows much about campaign units/leaders persistence.

=== happygrue/Wintermute ===

Has been involved with multiplayer balance and testing for a number of years. Currently working on balancing the default+khalifate era, but interested in, and often available for, testing various aspects game play or mechanics. A good person to bug about getting feedback from the multiplayer community about any relevant issue.

=== loonycyborg ===
Maintainer of Wesnoth's SCons build system and windows packager. Might also help out with other buildsystems.

=== mattsc ===

Has no computer science background and doesn't really know much about how coding should be done, but has been fiddling with Wesnoth AI behavior for a while now, accumulating some empirical experience along the way. He might be able to help with questions on AI behavior and, to a lesser extent, on AI functionality.

=== Mordante ===
Many of the possible projects involve the code for which he is an area expert. Also, many of the possible projects currently listed on the ideas page require GUI parts to work. Mordante is currently busy rewriting the old gui engine, he will be our expert there as well as already being our area expert for the terrain engine. He also has limited experience with boost asio and maintains the cmake build system together with Ivanovic

=== Nils Kneuper (Ivanovic) ===
He is doing nothing special, he just does some "administrative work" like packaging fresh tarballs when it is time for them and works on setting up any kind of deadlines and timetables related to releasing. He has administrative powers in most areas, no matter if website, forum or IRC. Beside this he uploads translation updates, tries to communicate with the translation teams when it is required and translates a little bit himself every now and then. But in general he is not a real expert in anything, just has a look at things that come up and redirects people to the correct contacts.

=== Noy ===
Noy is an oddity among developers; he's got no coding skills whatsoever and possesses a limited understanding of computers, which is illustrated by his difficulty operating a Mac. Instead, Noy makes his contribution in gameplay and multiplayer design, drawing upon his background in social sciences research, military strategy and playing games online, to understand the effects of development on the playing community behavior. Along with Soliton, Noy is a useful conduit to discuss any issues in this area.

=== shadowm ===
He has been around since 2007, and has worked in many areas of the game, including WML event commands handling, image path functions, the add-ons client code, and converting and improving various user interface dialogs in GUI2. As a veteran add-on content developer, he also knows a lot about the WML language and the functionality available in single-player campaigns. Although he is by no means an expert on Lua, he may also be able to help with Wesnoth-specific Lua questions. Finally, as one of our server administrators, he can also answer most questions about our current configuration or help you with any problems you encounter with the forums, wiki, or add-ons server.

=== Soliton ===
He knows our MP server setup best. Beside this he has already done a lot of work on the MP server himself. So he probably has most knowledge about it and, being one of our MP-developers, might provide important help from the perspective of the MP player community and what is needed there.

=== thunderstruck ===
2013 GSoC student who worked on the game's engine to improve support for multiplayer campaigns. Due to the nature of his project, he can assist with questions related to both SP and MP engine internal workings.

=== vultraz ===
He can assist with questions related to the Lua GUI2 bindings and their usage.

=== zookeeper ===
Has been around for a long time and has at least a passing familiarity with most things outside the engine code, music and Lua. Maintains a large part of the mainline campaigns and knows the WML language well. Can be contacted when it comes to anything related to WML, gameplay and scenario design, or the mainline content in general.

== Inactive people ==

These people are currently not actively participating in development and are likely not available to help. You can always try, of course. They may also not be entirely up-to-date regarding their areas of expertise anymore.

=== boucman ===
As our "patch monkey" he accustomed to critiquing patches of every kind. Beside this, he knows many areas of the game due to working on applying patches. He is particularly used to answering question from new coders, and doesn't mind explaining trivial stuff. He was the one who started the "two patches, you're in" policy and the ReferenceWML part of the project.

=== Dave alias Sirp ===
Sirp started Wesnoth and is our lead developer. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.

=== Dragonking ===

He is one of our best Wesnoth players, and understands the various strategies well. He has also programmed much of the Wesnoth Formula AI system and understands it well.

=== Eric S. Raymond (ESR) ===
ESR is our project toolsmith; he has written several tools that semi-automate various aspects of WML maintenance. While most of our developers/designers concentrate on either the C++ core or WML but not both, he has a balanced understanding of both levels and may be helpful in helping students develop a grasp of the overall architecture. Finally, he did the last overhaul of the Wesnoth UI and understands UI design principles; he is well-equipped to guide students working in that area.

=== Gabriel Morin (gabba) ===

gabba joined the team in 2010 where he participated in GSoC, and is the conceptor and maintainer of Wesnoth's planning system, codenamed "Whiteboard".

=== ilor ===
2008 GSoC student, worked on and maintains the new map editor in Wesnoth 1.5/1.6/1.7. Has some fairly recent experience with getting "in" the Wesnoth codebase.

=== Karol Nowak (grzywacz) ===
Two years he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on Wesnoth for embedded devices as he worked on the gp2x support.

=== Sapient ===
This developer started working on the GUI and widgets, but recently he focused more on improving the internal mechanics of the WML engine such as variable look-ups and filtering. Sapient is not as active anymore but he does come one IRC in the evenings (U.S.A.). He has touched-up many areas of the code in small ways over time, thus he has a good general knowledge of the C++ code and also has worked a little on some python maintenance scripts.

=== YogiHH ===
Since he is the developer who know most about building under Windows, he will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.
YogiHH also knows quite a bit about the game engine and everything that has to do with replays and savegames.

=== Mythological or Rhuvaen ===
As our leading WML experts those are to be contacted when it comes to anything related WML problems since they know this stuff best. They do maintain most of the campaigns and improve them whenever they have a good idea for changes.

PblWML

2013-12-21T11:00:05Z

Thunderstruck: /* type */

{{WML Tags}}

To upload an add-on you have made, you need a .pbl file.

This is a file with name '''data/add-ons/''Addon_name''.pbl''' or, for Wesnoth 1.6 and later, '''data/add-ons/''Addon_Name''/_server.pbl''' in a subdirectory. [http://exong.net/wesnoth-attach/files/pblexample_111.png Click here for an example of what we're talking about.]

When you upload a add-on, the file '''data/add-ons/''Addon_Name''.cfg'''
and the directory '''data/add-ons/''Addon_Name''/''' will be published. Alternatively, '''data/add-ons/''Addon_Name''.cfg''' can be replaced with '''data/add-ons/''Addon_Name''/_main.cfg'''. Your add-on must be based entirely on these paths.

Be aware that translations in the .pbl-files are '''not''' used, so don't mark these strings as translatable.

== What goes into a .pbl file? ==

'''Note:''' ''You should '''not''' use special formatting or coloring in any of these keys when uploading to the official server.'''''

The following keys are recognized for .pbl files:

=== icon ===
: An image, displayed leftmost in the add-ons download dialog. It must be a standard Wesnoth file and not a custom one. A custom file will work for users who already have the relevant add-on installed. This is not related to the icon used for entries in the campaigns menu -- see [[CampaignWML]] for more information.

: If the icon is a unit with magenta team-color bits, please use [[ImagePathFunctionWML]] to recolor it.

=== title ===
: Displayed to the right of the icon, it is just text. It should usually be the same as the name of your add-on when it is played.

=== version ===
: Displayed to the right of the title, it is just text. However, starting with Wesnoth 1.6, the ''required'' format is x.y.z where x, y and z are numbers and a value for x greater than 0 implies the add-on is complete feature-wise. Trailing non-numeric elements are allowed, but nothing should appear ''before'' the numbers. This is necessary for the ''Update add-ons'' button to work correctly. ([[#Version Key Examples|See Examples]])

=== author ===
: Displayed to the right of the version, it is just text. Put your name or nickname here. If several people have contributed significantly to the add-on you may want to list all of their names.

=== passphrase ===
: Not displayed, it prevents others from modifying the version of your add-on on the server. You do not need to input a passphrase when initially publishing a add-on; if you do not, one will be randomly generated for you and replaced in your local copy of the .pbl file.

=== description ===
: This can be used to provide a brief description of your add-on, and for pre-1.0 versions, let people know how playable it is. The description can be viewed by users by clicking on the Description button in the built-in client, or by moving their mouse over the add-on's icon in the web interface.

=== dependencies ===
: An optional list of dependencies (a comma separated list of ''addon-name'' – the directory names of the needed add-ons), which should be provided if your add-on relies on other user-made content to work properly. ([[#Dependency Key Example|See Example]])

=== translate ===
: If set to '''true''', the add-on will be sent to and updated with [[WesCamp|WesCamp-i18n]]. (NOTE: this is a new and experimental function, which will automatically update the translations in your add-on. Make sure you make backups of your add-on in case of problems.)

: You should make sure your add-on complies with some very specific [[WesCamp#Preparing_your_add-on_for_WesCamp|conventions]] required to ease the process for translators as well as technical requirements.

=== type ===
: Indicates the type of the add-on, used for the downloads manager dialog. Possible values are:

:* ''campaign'': single player campaign.
:* ''scenario'': single player scenario.
:* ''campaign_sp_mp'': hybrid campaign.
:* ''era'': multiplayer era.
:* ''faction'': multiplayer stand-alone faction, or add-on for other available era.
:* ''map_pack'': multiplayer map-pack.
:* ''campaign_mp'': multiplayer campaign.
:* ''scenario_mp'': multiplayer scenario. (See the note below.)
:* ''mod_mp'': multiplayer modification.
:* ''media'': miscellaneous resources for UMC authors/users, for example, music packs, packages of general-purpose WML, etc.
:* ''other'': The type to use when no other type fits.

'''Note:''' If your add-on contains two or more separate multiplayer scenarios, use ''map_pack''.

=== email ===
: Hidden e-mail address used by the server administrators to contact content authors in case of major issues. Again, this will only be seen by the server administrators and it is required that you provide one in case you need to be contacted about your add-on.

The add-on server keeps track of some other information about uploaded content, including when they were uploaded, what languages they have been at least partly translated into, how large they are on the server and the number of times they have been downloaded. For more information about this you can read [[CampaignServerWML]].

== Examples ==

=== Dependency Key Example ===

The following dependency key could be used when the add-on needs the ''Imperial_Era'' and ''Era_of_Myths'' to be installed before it will work properly:

dependencies=Imperial_Era,Era_of_Myths

=== Version Key Examples ===

The following are examples of '''good''' version values:

version="1.5"

version="0.11.4"

version="0.1.4beta"

version="1.5c"

The following are examples of '''bad''' version values:

version="Beta1.5"

version="Incomplete (0.3.4)"

In both of the above examples the version number as read by the server will be '''0.0.0Beta1.5''' and '''0.0.0Incomplete (0.3.4)'''. You can clearly see why this will not be a good thing with the ''Update add-ons'' feature.

Finally, here are some example version numbers and how they will be interpreted by the ''Update add-ons'' button. The number on the left will be considered an earlier number than the number on the right in each example.

0.5 < 1.0

1.5 < 1.5c

1.0 < 1.0.1

1.0c < 1.0.1a

1.0.1a < 1.0.1c

1.0 Final < 1.0.1 Beta

=== Example .pbl File ===

title="My Campaign"
type="campaign"
icon="misc/ball.png"
version="0.1.2"
author="Me, artwork by myself"
passphrase="This is like a password"
description="You get to kill a lot of bad guys. But only the first map is done."
email="name@example.com"

== See Also ==

* [[ReferenceWML]]
* [[BuildingCampaignsThePBLFile]]
* [[CampaignServerWML]]

[[Category: WML Reference]]

CampaignWML

2013-12-21T10:58:10Z

Thunderstruck: /* The [campaign] Tag */

{{WML Tags}}



This page describes how the campaign is displayed in the "Campaign" menu, and how it starts.

==The [campaign] Tag==

The following keys and tags are recognized in '''[campaign]''' tags:
* '''id''': the internal campaign identifier used to classify saved games
* '''icon''': the image displayed in the campaign selection menu
* '''name''': (translatable) name displayed in the campaign selection menu
* '''abbrev''': (translatable) abbreviation used as a prefix for savefile names made from this campaign
* '''image''': the image shown in the information pane when this campaign is selected in the campaign selection menu (typically a transparent, 350×350 pixels portrait)
* '''description''': (translatable) text shown in the information pane when this campaign is selected in the campaign selection menu
* '''type''': {{DevFeature1.11}} campaign's type to specify if it should be visible in singleplayer, multiplayer or both. Possible values are "sp", "mp" and "hybrid". Defaults to "sp".
* '''define'''='''''CAMPAIGN_SYMBOL''''' when this campaign is started, the preprocessor symbol '''''CAMPAIGN_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the campaign file from other campaigns. Only the tags '''[campaign]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''CAMPAIGN_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''CAMPAIGN_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
* '''extra_defines''': a comma(''',''') separated list of preprocessor symbols. Those symbols will be defined ''before'' any .cfg is preprocessed. Currently supported extra_defines are:
<ul>
;ENABLE_ARMAGEDDON_DRAKE
:allows the advancement ''Inferno Drake'' -> ''Armageddon Drake''
;ENABLE_DWARVISH_ARCANISTER
:allows the advancement ''Dwarvish Runemaster'' -> ''Dwarvish Arcanister''
;ENABLE_DWARVISH_RUNESMITH
:allows the advancement ''Dwarvish Fighter'' -> ''Dwarvish Runesmith''
;DISABLE_GRAND_MARSHAL
:disallows the advancement ''General'' -> ''Grand Marshal''
;ENABLE_ANCIENT_LICH
:allows the advancement ''Lich'' -> ''Ancient Lich''
;ENABLE_DEATH_KNIGHT
:allows the advancement ''Revenant'' -> ''Death Knight'
;ENABLE_TROLL_SHAMAN {{DevFeature1.11}}
:allows the advancement ''Troll Whelp'' -> ''Troll Shaman''
;ENABLE_WOLF_ADVANCEMENT {{DevFeature1.11}}
:allows the advancements ''Wolf'' -> ''Great Wolf'' -> ''Direwolf''
</ul>
* '''difficulties''': a comma(''',''') separated list of preprocessor symbols, exactly one of which will be stored depending on the difficulty setting chosen when the campaign is started. The symbols '''EASY''', '''NORMAL''', and '''HARD''' are usually used, and there are several macros in utils.cfg (see [[UtilWML]]) which check for these values to set WML keys to different values depending on difficulty. If you use different difficulty symbols, you may need to define your own versions of these macros.
* '''difficulty_descriptions''': the menu of difficulties; this is a list of descriptions (see [[DescriptionWML]]) that correspond to different difficulty levels. Since each description is a menu option for a difficulty level, this must provide the same number of descriptions as there are levels in the ''difficulties'' list.
* '''allow_difficulty_change''': {{DevFeature1.11}} Allows difficulty switching during an ongoing campaign. Default:yes
* '''first_scenario''': the ID of the first scenario in the campaign; see ''id'' in [[ScenarioWML]]
* '''rank''': a number that determines the order of campaigns in the campaign selection menu. Lower ''rank'' campaigns appear earlier, with unranked campaigns at the end. Currently the mainline campaigns use multiples of 10 from 0 to 399, with 0-99 for Novice campaigns, 100-199 for Intermediate campaigns, and 200-399 for Expert campaigns; if you specify this, it should not be less than 400. (Note: This replaces an older convention that topped out at 50.)
* '''[about]''': inserts your own credits into the game's list of credits. See below for syntax.
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of the campaign. Defaults to ''yes''.
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End".
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500.

The following keys are additionally recognized in multiplayer:
* '''min_players''': {{DevFeature1.11}} Minimum number of players campaign supports. Defaults to 2.
* '''max_players''': {{DevFeature1.11}} Maximum number of players campaign supports. Defaults to '''min_players'''.
* '''allow_era_choice''': {{DevFeature1.11}} Whether to hide era selection and use a default one when creating a game. Defaults to ''yes''.
* '''require_campaign''': {{DevFeature1.11}} Whether clients are required to have this campaign installed beforehand to be allowed join a game using this campaign. Possible values 'yes' (the default) and 'no'.

== Campaign credits ==

The campaign's name automatically is inserted at the top of the rolling credits followed by title/text key pairs. There can be any number of '''[about]''' tags inside a '''[campaign]''' tag, but none of them will display credits if there is no "id" key present inside [campaign] (see above). The '''[about]''' tag has the following keys:
* '''title''': (translatable) large text used to start a new subsection (writers, artists, units, balancing) in the rolling credits
* '''text''': (translatable, but you probably won't want to make it such) smaller text which is displayed before the contributor names
* '''[entry]''': Contains information about a single contributor. Only the ''name'' key will be used in-game, the other three keys are for display on the [[Credits]] page ('''note:''' the values of these keys will only display on the Credits page for mainline campaigns; they will not display for UMC campaigns)
** '''name''': The name of the contributor
** '''comment''': Optional short note about what that person did
** '''email''': Optional email address
** '''wikiuser''': Optional, the user name on the wiki

== See Also ==

* [[PreprocessorRef]]
* [[ScenarioWML]]
* [[ReferenceWML]]
* [[PblWML]]

[[Category: WML Reference]]

ScenarioWML

2013-12-14T10:10:12Z

Thunderstruck:

{{WML Tags}}
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==

The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.
The difference between these tags is the way that the scenarios they describe are accessed.

The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.
Units from the first scenario will be available for recall in the second.

Some scenarios can be played without playing other scenarios first
(in this case there is nothing on the recall list).
These scenarios are called ''initial scenario''s.

A list of initial scenarios, and how to access them:

* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).

* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)

* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.

* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.

== The [scenario] tag ==

The following keys and tags are recognized in '''[scenario]''' tags:

* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.

* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.

* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.

* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.

* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.

* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]

* '''turn_at''': the turn to start on (default=1)

: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.

* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)

* '''music''': the music file relative to ''./music/'' to play during the scenario

* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].

* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''theme''': the name of the UI theme that should be used when playing this scenario.

* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.

* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.

* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.

* '''[story]''': describes the intro screen. See [[IntroWML]]

* '''[label]''': sets a label
** '''x''', '''y''': location to set label
** '''text''': the label

* '''[time]''': how a day should progress. See [[TimeWML]]
* '''current_tod''': The time of day slot number (starting from zero) active at scenario start.

* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag
** takes x and y coordinates.
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]
** '''current_time''': The time slot number (starting with zero) active at the creation of the area.{{DevFeature1.11}}
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].

* '''[side]''': describes one player. See [[SideWML]]

* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]

* '''map_generation''': another way to generate a map. The map will be generated randomly
** '''default''': the default random map generator

* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]

The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:
* '''force_lock_settings''': {{DevFeature1.11}} provides a default value for [[SideWML]] ''lock'' attributes and forces the "Use map settings" to be checked and disabled. This is useful if author wants to limit game customization in order to keep the scenario/campaign balanced. Individual options can still be enabled if this key is set to '''yes'''. E.g. color selection can be enabled by explicitly setting ''color_lock=yes'' in [[SideWML]].
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.

== See Also ==

* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

ScenarioWML

2013-10-27T09:47:59Z

Thunderstruck:

{{WML Tags}}
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==

The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.
The difference between these tags is the way that the scenarios they describe are accessed.

The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.
Units from the first scenario will be available for recall in the second.

Some scenarios can be played without playing other scenarios first
(in this case there is nothing on the recall list).
These scenarios are called ''initial scenario''s.

A list of initial scenarios, and how to access them:

* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).

* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)

* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.

* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.

== The [scenario] tag ==

The following keys and tags are recognized in '''[scenario]''' tags:

* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.

* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.

* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.

* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.

* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.

* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]

* '''turn_at''': the turn to start on (default=1)

: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.

* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)

* '''music''': the music file relative to ''./music/'' to play during the scenario

* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].

* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''theme''': the name of the UI theme that should be used when playing this scenario.

* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.

* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.

* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.

* '''[story]''': describes the intro screen. See [[IntroWML]]

* '''[label]''': sets a label
** '''x''', '''y''': location to set label
** '''text''': the label

* '''[time]''': how a day should progress. See [[TimeWML]]

* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag
** takes x and y coordinates.
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].

* '''[side]''': describes one player. See [[SideWML]]

* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]

* '''map_generation''': another way to generate a map. The map will be generated randomly
** '''default''': the default random map generator

* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]

The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:
* '''force_lock_settings''': {{DevFeature1.11}} provides a default value for [[SideWML]] ''lock'' attributes and forces the "Use map settings" to be checked and disabled.
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.

== See Also ==

* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

SideWML

2013-10-27T09:44:42Z

Thunderstruck: /* the [side] tag */

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides.

* '''controller''': how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves. This is the default setting.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.)
** '''a number''': {{DevFeature1.11}} gives this side's control to a side with '''side''' matching the number (multiplayer only).

* '''no_leader''': if "no" (default), then keys describing a unit which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using '''canrecruit=yes''') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are '''type''' (mandatory), '''id''', '''name''' and '''unrenamable=yes''', see [[SingleUnitWML]].

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* '''gold''': the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end. {{DevFeature1.11}}It is used in saved games.)

* '''[fog_override]''' {{DevFeature1.11}} With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[BuildingScenariosShroudData]].

* '''persistent''': whether the side exists in any other scenarios. If ''yes'', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to ''yes'' for sides with a human controller, and ''no'' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog. (For versions prior to 1.7.3, some extra effort to retrieve carryover information may be needed. See [[SideSwitchingWML]])

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg.

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': {{DevFeature1.11}} the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]).

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another [village] tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

The following keys are multiplayer only:

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. Defaults to yes.

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''controller_lock''': {{DevFeature1.11}} if true then this side's controller ("Player/Type") modification is limited. It is bound to the '''controller''' attribute in [[SideWML]].

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction''': if valid faction id is provided then this side's faction is not allowed to be modified.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

{{DevFeature1.11}} N.B. the ''lock'' attributes use [[ScenarioWML]] '''force_lock_settings''' as their default value. I.e. if no value to ''lock'' was set, it will take '''force_lock_settings''' value.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

SideWML

2013-10-11T19:51:08Z

Thunderstruck: Documented "controller_lock" and other lock aspects.

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides.

* '''controller''': how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves. This is the default setting.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.)
** '''a number''': {{DevFeature1.11}} gives this side's control to a side with '''side''' matching the number (multiplayer only).

* '''no_leader''': if "no" (default), then keys describing a unit which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using '''canrecruit=yes''') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are '''type''' (mandatory), '''id''', '''name''' and '''unrenamable=yes''', see [[SingleUnitWML]].

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* '''gold''': the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end. {{DevFeature1.11}}It is used in saved games.)

* '''[fog_override]''' {{DevFeature1.11}} With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[BuildingScenariosShroudData]].

* '''persistent''': whether the side exists in any other scenarios. If ''yes'', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to ''yes'' for sides with a human controller, and ''no'' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog. (For versions prior to 1.7.3, some extra effort to retrieve carryover information may be needed. See [[SideSwitchingWML]])

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg.

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': {{DevFeature1.11}} the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]).

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another [village] tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

The following keys are multiplayer only:

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. Defaults to yes.

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''controller_lock''': {{DevFeature1.11}} if true then this side's controller ("Player/Type") modification is limited. It is bound to the '''controller''' attribute in [[SideWML]].

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction''': if valid faction id is provided then this side's faction is not allowed to be modified.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

N.B. the ''lock'' attributes use "Use map settings" option as their default value.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

ScenarioWML

2013-10-11T19:43:16Z

Thunderstruck: Undo revision 52163 by Thunderstruck (Talk)

{{WML Tags}}
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==

The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.
The difference between these tags is the way that the scenarios they describe are accessed.

The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.
Units from the first scenario will be available for recall in the second.

Some scenarios can be played without playing other scenarios first
(in this case there is nothing on the recall list).
These scenarios are called ''initial scenario''s.

A list of initial scenarios, and how to access them:

* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).

* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)

* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.

* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.

== The [scenario] tag ==

The following keys and tags are recognized in '''[scenario]''' tags:

* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.

* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.

* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.

* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.

* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.

* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]

* '''turn_at''': the turn to start on (default=1)

: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.

* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)

* '''music''': the music file relative to ''./music/'' to play during the scenario

* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].

* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''theme''': the name of the UI theme that should be used when playing this scenario.

* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.

* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.

* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.

* '''[story]''': describes the intro screen. See [[IntroWML]]

* '''[label]''': sets a label
** '''x''', '''y''': location to set label
** '''text''': the label

* '''[time]''': how a day should progress. See [[TimeWML]]

* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag
** takes x and y coordinates.
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].

* '''[side]''': describes one player. See [[SideWML]]

* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]

* '''map_generation''': another way to generate a map. The map will be generated randomly
** '''default''': the default random map generator

* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]

The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:
* '''force_use_map_settings''': {{DevFeature1.11}} forces the "Use map settings" to be checked in order to avoid broken gameplay for story based multiplayer campaigns. Defaults to no for scenario loaded from configuration screen and to yes, for consecutive scenarios.
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.

== See Also ==

* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

ScenarioWML

2013-10-09T08:12:21Z

Thunderstruck: Added "lock_side_controllers".

{{WML Tags}}
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==

The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.
The difference between these tags is the way that the scenarios they describe are accessed.

The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.
Units from the first scenario will be available for recall in the second.

Some scenarios can be played without playing other scenarios first
(in this case there is nothing on the recall list).
These scenarios are called ''initial scenario''s.

A list of initial scenarios, and how to access them:

* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).

* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)

* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.

* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.

== The [scenario] tag ==

The following keys and tags are recognized in '''[scenario]''' tags:

* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.

* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.

* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.

* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.

* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.

* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]

* '''turn_at''': the turn to start on (default=1)

: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.

* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)

* '''music''': the music file relative to ''./music/'' to play during the scenario

* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].

* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''theme''': the name of the UI theme that should be used when playing this scenario.

* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.

* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.

* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.

* '''[story]''': describes the intro screen. See [[IntroWML]]

* '''[label]''': sets a label
** '''x''', '''y''': location to set label
** '''text''': the label

* '''[time]''': how a day should progress. See [[TimeWML]]

* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag
** takes x and y coordinates.
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].

* '''[side]''': describes one player. See [[SideWML]]

* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]

* '''map_generation''': another way to generate a map. The map will be generated randomly
** '''default''': the default random map generator

* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]

The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:
* '''force_use_map_settings''': {{DevFeature1.11}} forces the "Use map settings" to be checked in order to avoid broken gameplay for story based multiplayer campaigns. Defaults to no for scenario loaded from configuration screen and to yes, for consecutive scenarios.
* '''lock_side_controllers''': {{DevFeature1.11}} locks side controllers ("Player/Type") selection according to the '''controller''' attribute in [[SideWML]]. Default value is true if "Use map settings" was checked. Otherwise, false.
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.

== See Also ==

* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

MultiplayerContent

2013-09-25T20:43:11Z

Thunderstruck: Fixed title case

This guide is intended for version '''1.11.6 and higher'''. A page about multiplayer campaigns in older versions can be found [[MultiplayerCampaigns_1.10|here]].

= Building Multiplayer Campaigns =

The development version of 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 because 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.
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 ==

As of version 1.11.6, multiplayer campaigns do use [campaign] tag, thus allowing the same campaign to work both in singleplayer and multiplayer. The only difference is that game also checks for a couple optional tags when campaign is used in multiplayer. They could be found in [[CampaignWML]] page. Additionally, '''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 in entry points selection in multiplayer configuration screen.
* For scenarios that don't set '''allow_new_game=no''', one could make use of '''new_game_title''' to have a custom title. This is useful if campaign is supposed to have multiple entry points. E.g. chapters.
* 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.

== Other Notes ==

* To ensure that your scenario settings would not get overwritten by the settings from the multiplayer configure dialog, set '''force_use_map_settings=true'''. However, if your campaign is not intended to be played strictly with default settings - 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] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [scenario] tag.

== See Also ==

* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

[[Category:Create]]

MultiplayerContent

2013-09-25T20:42:23Z

Thunderstruck: Updated for 1.11.6

This guide is intended for version '''1.11.6 and higher'''. A page about multiplayer campaigns in older versions can be found [[MultiplayerCampaigns_1.10|here]].

= Building Multiplayer Campaigns =

The development version of 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 because 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.
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 ==

As of version 1.11.6, multiplayer campaigns do use [campaign] tag, thus allowing the same campaign to work both in singleplayer and multiplayer. The only difference is that game also checks for a couple optional tags when campaign is used in multiplayer. They could be found in [[CampaignWML]] page. Additionally, '''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 in entry points selection in multiplayer configuration screen.
* For scenarios that don't set '''allow_new_game=no''', one could make use of '''new_game_title''' to have a custom title. This is useful if campaign is supposed to have multiple entry points. E.g. chapters.
* 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.

== Other Notes ==

* To ensure that your scenario settings would not get overwritten by the settings from the multiplayer configure dialog, set '''force_use_map_settings=true'''. However, if your campaign is not intended to be played strictly with default settings - 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] and [remove_shroud]. There is currently no way to remove fog. You might also want to use ''experience_modifier=100'' in the [scenario] tag.

== See Also ==

* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

[[Category:Create]]

MultiplayerContent

2013-09-24T20:15:59Z

Thunderstruck: Add redirect and development notice

'''Attention:''' This page is under development!

This guide is intended for version '''1.11.6 and higher'''. A page about multiplayer campaigns in older versions can be found [[MultiplayerCampaigns_1.10|here]].

= 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 [[http://forum.wesnoth.org/viewtopic.php?p=405807#p405807]]
* 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.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

[[Category:Create]]

ScenarioWML

2013-09-21T17:34:32Z

Thunderstruck: Documented "remove_from_carryover_on_leaders_loss", "new_game_title", "force_use_map_settings" and updated "id", "allow_new_game" attributes.

{{WML Tags}}
== the toplevel tags [multiplayer], [test], [tutorial], [scenario] ==

The top level tags '''[multiplayer]''', '''[test]''', '''[tutorial]''' and '''[scenario]''' are all formatted the same way.
The difference between these tags is the way that the scenarios they describe are accessed.

The keys '''id''' and '''next_scenario''' affect how scenarios can be accessed.
Whenever a scenario is won, the scenario with id=''next_scenario'' of the same tag type will be played.
Units from the first scenario will be available for recall in the second.

Some scenarios can be played without playing other scenarios first
(in this case there is nothing on the recall list).
These scenarios are called ''initial scenario''s.

A list of initial scenarios, and how to access them:

* All '''[multiplayer]''' scenarios (without ''allow_new_game=no'') are initial scenarios listed in the multiplayer scenario selector screen (accessed by the "multiplayer" button).

* The '''[test]''' scenario with the attribute '''id=test''' is an initial scenario. This test scenario can be accessed by running the game in test mode. (note: this is NOT the same as debug mode. It can be accessed using -t or --test)

* The '''[tutorial]''' scenario with the attribute '''id=tutorial''' is an initial scenario. The tutorial is accessed by clicking on the "tutorial" button.

* Any '''[scenario]''' scenario with an id listed in the value of ''first_scenario'' in a campaign tag (see [[CampaignWML]]) is an initial scenario accessed by selecting that campaign after clicking on the "campaign" button.

== The [scenario] tag ==

The following keys and tags are recognized in '''[scenario]''' tags:

* '''id''': A unique identifier for this scenario. All scenarios must have an id. Can't clash with '''id''' used in '''[multiplayer]''' tags.

* '''next_scenario''': The id of the scenario to load when the current one is won. This can be changed dynamically, to build non-linear campaigns.

* '''description''': (translatable) only for multiplayer maps. Will show up as a tooltip when mousing over the minimap in the multiplayer setup screen.

* '''name''': (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level.

* '''map_data''': inputs valid Wesnoth map data. See [[BuildingMaps]] for a description of the Wesnoth map syntax.

* '''turns''': sets an event on turn ''turns'' causing the player to lose. Use ''-1'' to have no turn limit (default). See also [[EventWML]]

* '''turn_at''': the turn to start on (default=1)

: Note that none of the regular start-of-turn behavior, including poison damage, healing, income and refreshing unit movement and status, will occur before the start of turn 2. All start-of-turn [[EventWML|WML events]] will still be fired, however.

* '''random_start_time''': controls random starting time of day. Possible values are yes and no or list of possible start times; starting from 1 to number of times. for example ''random_start_time=2,3,5,6'' (default=no)

* '''music''': the music file relative to ''./music/'' to play during the scenario

* '''[music]''': specifies the music tracks to play during this scenario, see [[MusicListWML]].

* '''defeat_music''': specifies a comma-separated list of music tracks which may be chosen to play on defeat. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''victory_music''': specifies a comma-separated list of music tracks which may be chosen to play on victory. If not provided, the default in [[GameConfigWML]] is used instead. May be overridden by [[DirectActionsWML|endlevel]] clauses.

* '''theme''': the name of the UI theme that should be used when playing this scenario.

* '''victory_when_enemies_defeated''': when this is set to '''yes''' (default), the player wins once all non-allied units with '''canrecruit=yes''' (aka leaders) are killed. (Currently this only controls the win condition for when all enemies are defeated; it does not prevent the player from losing if he has no leader.) When this value is true the following keys can be used:
** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''remove_from_carryover_on_leaders_loss''': {{DevFeature1.11}} when this is set to '''yes''' (default), for sides who lost all their leaders, carryover will be removed.

* '''disallow_recall''': when this is set to 'no'(default), the player is allowed to recall units from previous scenarios.

* '''experience_modifier''': the percentage that required XP to level up (for all units in the scenario) is multiplied by. Default 100. Note that when used in a campaign, weird things (like units being above the required XP to level up) can happen if this value is different for different scenarios.

* '''[story]''': describes the intro screen. See [[IntroWML]]

* '''[label]''': sets a label
** '''x''', '''y''': location to set label
** '''text''': the label

* '''[time]''': how a day should progress. See [[TimeWML]]

* '''[time_area]''': how a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag
** takes x and y coordinates.
** '''[time]''': how a day should progress in those locations. See [[TimeWML]]
** time areas can be used in events, assigned identifiers, and removed at discretion. They also accept complete Standard Location Filters. See [[DirectActionsWML]].

* '''[side]''': describes one player. See [[SideWML]]

* '''[event]''': describes an event that may be triggered at a certain point of the scenario. See [[EventWML]]

* '''map_generation''': another way to generate a map. The map will be generated randomly
** '''default''': the default random map generator

* '''[generator]''' if this is present, the map and scenario will be generated randomly. See [[MapGeneratorWML]]

The following keys and subtags are additionally recognized in '''[multiplayer]''' scenarios:
* '''force_use_map_settings''': {{DevFeature1.11}} forces the "Use map settings" to be checked in order to avoid broken gameplay for story based multiplayer campaigns. Defaults to no for scenario loaded from configuration screen and to yes, for consecutive scenarios.
* '''new_game_title''': {{DevFeature1.11}} if provided will be used instead of '''name''' for campaign entry points.
* '''allow_new_game''': (default=yes) allow/prevent the scenario to be listed in the game configuration screen. This is intended for multiplayer campaigns with multiple entry points.
* '''allow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will be allowed to be played with this scenario.
* '''disallow_era''': {{DevFeature1.11}} a list of era ids. Only the eras with matching ids will not be allowed to be played with this scenario. Cannot be used in parallel with allow_era.
* '''ignore_incompatible_era''': {{DevFeature1.11}} a list of era ids. The eras with matching ids will be considered compatible with this scenario regardless their dependencies.
* '''allow_modification''': {{DevFeature1.11}} same as allow_era, but for modifications.
* '''disallow_modification''': {{DevFeature1.11}} same as disallow_era, but for modifications. Cannot be used in parallel with allow_modification.
* '''ignore_incompatible_modification''': {{DevFeature1.11}} same as ignore_incompatible_era, but for modifications.
* '''force_modification''': {{DevFeature1.11}} a list of modification ids. The specified modifications must be enabled to play this scenario.
* '''[options]''': {{DevFeature1.11}} custom options. See [[OptionWML]] for details.

== See Also ==

* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

SideWML

2013-09-21T16:51:01Z

Thunderstruck:

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides.

* '''controller''': how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves. This is the default setting.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.)
** '''a number''': {{DevFeature1.11}} gives this side's control to a side with '''side''' matching the number (multiplayer only).

* '''no_leader''': if "no" (default), then keys describing a unit which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using '''canrecruit=yes''') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are '''type''' (mandatory), '''id''', '''name''' and '''unrenamable=yes''', see [[SingleUnitWML]].

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* '''gold''': the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end. {{DevFeature1.11}}It is used in saved games.)

* '''[fog_override]''' {{DevFeature1.11}} With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[BuildingScenariosShroudData]].

* '''persistent''': whether the side exists in any other scenarios. If ''yes'', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to ''yes'' for sides with a human controller, and ''no'' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog. (For versions prior to 1.7.3, some extra effort to retrieve carryover information may be needed. See [[SideSwitchingWML]])

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg.

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': {{DevFeature1.11}} the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]).

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another [village] tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

The following keys are multiplayer only:

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. Defaults to yes.

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction''': this lock this side to this faction.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

CampaignWML

2013-09-21T16:23:10Z

Thunderstruck: Documented "type", "min_players" and "max_players" attributes.

{{WML Tags}}



This page describes how the campaign is displayed in the "Campaign" menu, and how it starts.

==The [campaign] Tag==

The following keys and tags are recognized in '''[campaign]''' tags:
* '''id''': the internal campaign identifier used to classify saved games
* '''icon''': the image displayed in the campaign selection menu
* '''name''': (translatable) name displayed in the campaign selection menu
* '''abbrev''': (translatable) abbreviation used as a prefix for savefile names made from this campaign
* '''image''': the image shown in the information pane when this campaign is selected in the campaign selection menu (typically a transparent, 350×350 pixels portrait)
* '''description''': (translatable) text shown in the information pane when this campaign is selected in the campaign selection menu
* '''type''': {{DevFeature1.11}} campaign's type to specify if it should be visible in singleplayer, multiplayer or both. Possible values are "sp", "mp" and "hybrid". Defaults to "sp".
* '''define'''='''''CAMPAIGN_SYMBOL''''' when this campaign is started, the preprocessor symbol '''''CAMPAIGN_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the campaign file from other campaigns. Only the tags '''[campaign]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''CAMPAIGN_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''CAMPAIGN_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
* '''extra_defines''': a comma(''',''') separated list of preprocessor symbols. Those symbols will be defined ''before'' any .cfg is preprocessed. Currently supported extra_defines are:
<ul>
;ENABLE_ARMAGEDDON_DRAKE
:allows the advancement ''Inferno Drake'' -> ''Armageddon Drake''
;ENABLE_DWARVISH_ARCANISTER
:allows the advancement ''Dwarvish Runemaster'' -> ''Dwarvish Arcanister''
;ENABLE_DWARVISH_RUNESMITH
:allows the advancement ''Dwarvish Fighter'' -> ''Dwarvish Runesmith''
;DISABLE_GRAND_MARSHAL
:disallows the advancement ''General'' -> ''Grand Marshal''
;ENABLE_ANCIENT_LICH
:allows the advancement ''Lich'' -> ''Ancient Lich''
;ENABLE_DEATH_KNIGHT
:allows the advancement ''Revenant'' -> ''Death Knight'
;ENABLE_TROLL_SHAMAN {{DevFeature1.11}}
:allows the advancement ''Troll Whelp'' -> ''Troll Shaman''
;ENABLE_WOLF_ADVANCEMENT {{DevFeature1.11}}
:allows the advancements ''Wolf'' -> ''Great Wolf'' -> ''Direwolf''
</ul>
* '''difficulties''': a comma(''',''') separated list of preprocessor symbols, exactly one of which will be stored depending on the difficulty setting chosen when the campaign is started. The symbols '''EASY''', '''NORMAL''', and '''HARD''' are usually used, and there are several macros in utils.cfg (see [[UtilWML]]) which check for these values to set WML keys to different values depending on difficulty. If you use different difficulty symbols, you may need to define your own versions of these macros.
* '''difficulty_descriptions''': the menu of difficulties; this is a list of descriptions (see [[DescriptionWML]]) that correspond to different difficulty levels. Since each description is a menu option for a difficulty level, this must provide the same number of descriptions as there are levels in the ''difficulties'' list.
* '''allow_difficulty_change''': {{DevFeature1.11}} Allows difficulty switching during an ongoing campaign. Default:yes
* '''first_scenario''': the ID of the first scenario in the campaign; see ''id'' in [[ScenarioWML]]
* '''rank''': a number that determines the order of campaigns in the campaign selection menu. Lower ''rank'' campaigns appear earlier, with unranked campaigns at the end. Currently the mainline campaigns use multiples of 10 from 0 to 399, with 0-99 for Novice campaigns, 100-199 for Intermediate campaigns, and 200-399 for Expert campaigns; if you specify this, it should not be less than 400. (Note: This replaces an older convention that topped out at 50.)
* '''[about]''': inserts your own credits into the game's list of credits. See below for syntax.
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of the campaign. Defaults to ''yes''.
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End".
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500.

The following keys are additionally recognized in multiplayer:
* '''min_players''': {{DevFeature1.11}} Minimum number of players campaign supports. Defaults to 2.
* '''max_players''': {{DevFeature1.11}} Maximum number of players campaign supports. Defaults to '''min_players'''.

== Campaign credits ==

The campaign's name automatically is inserted at the top of the rolling credits followed by title/text key pairs. There can be any number of '''[about]''' tags inside a '''[campaign]''' tag, but none of them will display credits if there is no "id" key present inside [campaign] (see above). The '''[about]''' tag has the following keys:
* '''title''': (translatable) large text used to start a new subsection (writers, artists, units, balancing) in the rolling credits
* '''text''': (translatable, but you probably won't want to make it such) smaller text which is displayed before the contributor names
* '''[entry]''': Contains information about a single contributor. Only the ''name'' key will be used in-game, the other three keys are for display on the [[Credits]] page ('''note:''' the values of these keys will only display on the Credits page for mainline campaigns; they will not display for UMC campaigns)
** '''name''': The name of the contributor
** '''comment''': Optional short note about what that person did
** '''email''': Optional email address
** '''wikiuser''': Optional, the user name on the wiki

== See Also ==

* [[PreprocessorRef]]
* [[ScenarioWML]]
* [[ReferenceWML]]
* [[PblWML]]

[[Category: WML Reference]]

SoC2013 thunderstruck MP Campaign Support

2013-07-04T16:16:12Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# Indicates whether to lock multiplayer game options.
# Optional. 'no' will be used as a default value.
lock_mp_options=yes

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases).

:To make it convenient for the users to easily differentiate between campaigns and scenarios a new button would be implemented which would change "maps menu" from maps/scenarios to campaigns and vice-versa. The difficulties and chapter/scenario selection dialogs would be displayed after campaign is selected and launched. These changes would have a little effect on the visual UI part and would not interfere with lipkab's [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 plans].

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.

;Options window
:Multiplayer campaigns and scenarios might allow different options for players. Furthermore, some multiplayer campaigns are heavily story based and their authors would prefer for players to not change all or some of the options.

:To address these things, the multiplayer game options which are currently in create window should be moved to a new window or dialog. This would let to avoid the problem that multiplayer campaigns are not parsed before selecting a difficulty. It would also make multiplayer create window more nicer and would allow to re-use the new options window in between multiplayer campaign scenarios.

:Currently, lipkab has already separated game options from the multiplayer create window (see link above). I could collaborate with him to make the work to be finished faster and make the options window more modular i.e. allow to easily lock/unlock relevant options and display it between campaigns scenarios.

----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially). [https://github.com/thunders/wesnoth-old/commit/6ca07a094796dafe4e1a4cd58f1f4b7b70680021 Update]. [https://github.com/thunders/wesnoth-old/commit/ca32fb7a50b3212d0707c0cb3434f0c2440a4eeb Another update].

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==
''N.B. The progress is not currently marked here, because the expected goals, which are here, do not necessarily match the current goals I'm working on.''
{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time and implement checking mechanism to determine if upgraded add-on was updated.
|
|-
|8
|Create window 1
|MANDATORY
|Implement "Switch to" button to quickly switch between multiplayer maps/scenarios to campaigns and vice-versa.
|
|-
|9
|Create window 2
|MANDATORY
|Implement a new dialog or tweak the existing one for chapter/scenario selection for multiplayer campaigns.
|
|-
|10
|Options window
|OPTIONAL
|Collaborate with lipkab to make the options window more modular.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|11
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|12
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|13
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|14
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|15
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|16
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Make it possible to change difficulty level between scenarios in multiplayer campaign.
* Split-And-Branch multiplayer campaigns: different next_scenarios for different sides. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p553085 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-22T12:48:16Z

Thunderstruck: options window

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# Indicates whether to lock multiplayer game options.
# Optional. 'no' will be used as a default value.
lock_mp_options=yes

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases).

:To make it convenient for the users to easily differentiate between campaigns and scenarios a new button would be implemented which would change "maps menu" from maps/scenarios to campaigns and vice-versa. The difficulties and chapter/scenario selection dialogs would be displayed after campaign is selected and launched. These changes would have a little effect on the visual UI part and would not interfere with lipkab's [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 plans].

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.

;Options window
:Multiplayer campaigns and scenarios might allow different options for players. Furthermore, some multiplayer campaigns are heavily story based and their authors would prefer for players to not change all or some of the options.

:To address these things, the multiplayer game options which are currently in create window should be moved to a new window or dialog. This would let to avoid the problem that multiplayer campaigns are not parsed before selecting a difficulty. It would also make multiplayer create window more nicer and would allow to re-use the new options window in between multiplayer campaign scenarios.

:Currently, lipkab has already separated game options from the multiplayer create window (see link above). I could collaborate with him to make the work to be finished faster and make the options window more modular i.e. allow to easily lock/unlock relevant options and display it between campaigns scenarios.

----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially). [https://github.com/thunders/wesnoth-old/commit/6ca07a094796dafe4e1a4cd58f1f4b7b70680021 Update]. [https://github.com/thunders/wesnoth-old/commit/ca32fb7a50b3212d0707c0cb3434f0c2440a4eeb Another update].

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time and implement checking mechanism to determine if upgraded add-on was updated.
|
|-
|8
|Create window 1
|MANDATORY
|Implement "Switch to" button to quickly switch between multiplayer maps/scenarios to campaigns and vice-versa.
|
|-
|9
|Create window 2
|MANDATORY
|Implement a new dialog or tweak the existing one for chapter/scenario selection for multiplayer campaigns.
|
|-
|10
|Options window
|OPTIONAL
|Collaborate with lipkab to make the options window more modular.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|11
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|12
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|13
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|14
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|15
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|16
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Make it possible to change difficulty level between scenarios in multiplayer campaign.
* Split-And-Branch multiplayer campaigns: different next_scenarios for different sides. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p553085 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-22T10:23:29Z

Thunderstruck: update future aspects

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases).

:To make it convenient for the users to easily differentiate between campaigns and scenarios a new button would be implemented which would change "maps menu" from maps/scenarios to campaigns and vice-versa. The difficulties and chapter/scenario selection dialogs would be displayed after campaign is selected and launched. These changes would have a little effect on the visual UI part and would not interfere with lipkab's [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 plans].

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially). [https://github.com/thunders/wesnoth-old/commit/6ca07a094796dafe4e1a4cd58f1f4b7b70680021 Update]. [https://github.com/thunders/wesnoth-old/commit/ca32fb7a50b3212d0707c0cb3434f0c2440a4eeb Another update].

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time and implement checking mechanism to determine if upgraded add-on was updated.
|
|-
|8
|Create window 1
|MANDATORY
|Implement "Switch to" button to quickly switch between multiplayer maps/scenarios to campaigns and vice-versa.
|
|-
|9
|Create window 2
|MANDATORY
|Implement a new dialog or tweak the existing one for chapter/scenario selection for multiplayer campaigns.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|10
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|11
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|12
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|13
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|14
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|15
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Make it possible to change difficulty level between scenarios in multiplayer campaign.
* Split-And-Branch multiplayer campaigns: different next_scenarios for different sides. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p553085 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-21T14:11:01Z

Thunderstruck: Create window and demo update.

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases).

:To make it convenient for the users to easily differentiate between campaigns and scenarios a new button would be implemented which would change "maps menu" from scenarios to campaigns and vice-versa. The difficulties and chapter/scenario selection dialogs would be displayed after campaign is selected and launched. These changes would have a little effect on the visual UI part and would not interfere with lipkab's [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 plans].

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially). [https://github.com/thunders/wesnoth-old/commit/6ca07a094796dafe4e1a4cd58f1f4b7b70680021 Update]. [https://github.com/thunders/wesnoth-old/commit/ca32fb7a50b3212d0707c0cb3434f0c2440a4eeb Another update].

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time and implement checking mechanism to determine if upgraded add-on was updated.
|
|-
|8
|Create window 1
|MANDATORY
|Implement "Switch to" button to quickly switch between multiplayer maps/scenarios to campaigns and vice-versa.
|
|-
|9
|Create window 2
|MANDATORY
|Implement a new dialog or tweak the existing one for chapter/scenario selection for multiplayer campaigns.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|10
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|11
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|12
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|13
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|14
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|15
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-20T13:31:43Z

Thunderstruck: demo update

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
TODO: edit after GUI prototypes for new mp campaign create window are confirmed. Should not interfere with [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 lipkab's plans]
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chose to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially). [https://github.com/thunders/wesnoth-old/commit/6ca07a094796dafe4e1a4cd58f1f4b7b70680021 Update].

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|<strike>Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.</strike>
|
|-
|9
|Create window 1
|MANDATORY
|TODO: edit after GUI prototypes. Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|TODO: edit after GUI prototypes. Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|TODO: edit after GUI prototypes. Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-19T18:33:24Z

Thunderstruck: New syntax support, formatting and other changes.

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes for multiplayer campaigns===
'''''Campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Indicates the minimum number of players
# for multiplayers games.
# Optional. 1 will be used as a default value.
min_players=2

# Indicates the maximum number of players
# for multiplayer games.
# Optional. The value of 'min_players' or 1 will be used as a default value.
max_players=3

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed
# to choose factions for this side.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify
# an order of turns for the sides with 'yes' here.
# Optional. 'no' will be used as a default value.
custom_turn=yes

# These might be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
<dl>
;New syntax support
:Currently engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by [multiplayer] tags which are guarded by 'MULTIPLAYER' define. That should be improved so that it would load multiplayer campaigns only with [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. This would simplify multiplayer campaign development and would allow to implement currently missing features.

:The [multiplayer] tag and 'MULTIPLAYER' define would still be used, but would play a less important role i.e. tag would be only used for stand-alone multiplayer scenarios and define would be used to guard them and make adjustments between singleplayer and multiplayer in hybrid campaigns.

;Old syntax support
:After multiplayer campaign configs start to use CampaignWML and ScenarioWML, the old multiplayer campaigns would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML.

:The upgraded files should be stored in user's data directory and would be also cached for performance reasons. To determine whether particular add-on was updated and would need to be upgraded again, the version of current upgraded add-on and original add-on would be compared.

:Upgrader's functionality:
:* [multiplayer] -> [scenario] (for campaigns only)
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** attributes such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

:As these changes are a must for a good multiplayer campaign support and maintaining it afterwards, they would probably be implemented ahead of other improvements even though they are called ''Further new syntax support''.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is chosen. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times since scenarios contain far less data than campaigns.

:However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that large campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and cause small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer savegame storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game.

:In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
TODO: edit after GUI prototypes for new mp campaign create window are confirmed. Should not interfere with [http://forums.wesnoth.org/viewtopic.php?f=12&t=38748 lipkab's plans]
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chose to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/commit/ab739ab550b8ce391a9988f062ec2076f52bfcee Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially).

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new, further and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Enable engine to work properly with both [scenario] and [multiplayer] tags when used in multiplayer games.
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|<strike>Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.</strike>
|
|-
|9
|Create window 1
|MANDATORY
|TODO: edit after GUI prototypes. Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|TODO: edit after GUI prototypes. Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|TODO: edit after GUI prototypes. Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements might sound like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 
[https://github.com/wesnoth/wesnoth-old/commit/9c4e4b1272eb6dccd9ff0298d6e21fef17b4cd45 9c4e4b1] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-10T17:59:35Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
TODO: clarify eras role in WML parsing
<dl>
;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. The [multiplayer] tag would stop be to used. However 'MULTIPLAYER' define would still be used, but would play a less important role i.e. it would only be used to make adjustments between singleplayer and multiplayer in hybrid campaigns. Additionally, stand-alone multiplayer scenarios would remain the same, except that they would use [scenario] tag.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML. Additionally, the upgrader utility should also wrap eras around with unique defines to improve multiplayer loading time. The upgraded files should be stored in user's data directory and would be also cached for performance reasons.

:Upgrader's functionality:
:* [multiplayer] -> [scenario]
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** fields such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty
:* [era]..[/era] -> #ifdef ERA_DEFINE [era]..[/era] #endif

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is created. The stand-alone multiplayer games would still be fully parsed with every other multiplayer game, but that would not drastically affect loading times, since scenarios contain far less data than campaigns. However, since game loading speed is still an important aspect, some adjustments would might have to be made; When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that big campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and causes small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer game saves storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chose to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/tree/gsoc1 Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially).

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Remove [multiplayer] tag references in the code and adjust it to work with [scenario].
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|
|-
|9
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-10T16:05:39Z

Thunderstruck: Goals, engine and wml syntax changes

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details omitted..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'hybrid'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details omitted..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details omitted..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details omitted..

[/multiplayer]

''after:''
[scenario]
# details omitted..

[side]
# details omitted..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer necessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
TODO: clarify eras role in WML parsing
<dl>
;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and recognize what type of game it is by 'campaign_type' attribute. The [multiplayer] tag would stop be to used. However 'MULTIPLAYER' define would still be used, but would play a less important role i.e. it would only be used to make adjustments between singleplayer and multiplayer in hybrid campaigns. Additionally, stand-alone multiplayer scenarios would remain the same, except that they would use [scenario] tag.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at the loading time of game configs and upgrade all configs identified as an old multiplayer WML. Additionally, the upgrader utility should also wrap eras around with unique defines to improve multiplayer loading time. The upgraded files should be stored in user's data directory and would be also cached for performance reasons.

:Upgrader's functionality:
:* [multiplayer] -> [scenario]
:* #ifdef MULTIPLAYER .. #endif -> [campaign]..[/campaign] #ifdef CAMPAIGN_SYMBOL .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** fields such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty
:* [era]..[/era] -> #ifdef ERA_DEFINE [era]..[/era] #endif

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. Additionally, part of multiplayer set-up logic could be moved to game_controller class. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is created. The stand-alone multiplayer games would still be fully parsed with every other multiplayer, but that would not drastically affect loading times, since scenarios contain far less data than campaigns. However, since game loading speed is still an important aspect, some adjustments would might have to be made. When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every add-on and using that path to load everything under that directory. Additionally, if it would appear that big campaigns would cause time-outs while they are parsed, the thread responsible for answering ping requests from the server could be created in order to avoid that.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and causes small, but important and undesirable gameplay changes (e.g. wrong carry-over or xp calculations). To address those issues, multiplayer game saves storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.

;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redundant. [https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b Already done.]
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chose to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.
:* [https://github.com/thunders/wesnoth-old/tree/gsoc1 Demo] to play SP campaigns as MP with no extra WML tweaking (works only partially).

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 15:
:* Game engine: save/restore issues, players management.
:* GUI: connect window.

;August 15 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games.
|
|-
|2
|Refactor multiplayer
|MANDATORY
|Refactor and move parts of multiplayer set-up logic in multiplayer.*pp to the game_controller.*pp.
|
|-
|3
|Multiplayer WML 1
|MANDATORY
|Enable singleplayer campaigns to be played in multiplayer.
|
|-
|4
|Multiplayer WML 2
|MANDATORY
|Remove [multiplayer] tag references in the code and adjust it to work with [scenario].
|
|-
|5
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|
|-
|9
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify the multiplayer's screen logic to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to correctly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definitely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect opportunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 
[https://github.com/wesnoth/wesnoth-old/commit/0ac9f9c532bc9065943fbf2384a622a43b14466b 0ac9f9c] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SideWML

2013-05-07T11:52:55Z

Thunderstruck:

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* '''side''': a number. The leader of this side is placed on the tile represented by this number (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far. Currently, the Multiplayer server rejects entering a scenario with more than 9 sides, even if those extra sides are AI sides.

* '''controller''': how moves for this side should be inputted.
** '''ai''': the Wesnoth AI makes this side's moves. This is the default setting.
** '''human''': a player controls this side's moves.
** '''null''': the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.)

* '''no_leader''': if "no" (default), then keys describing a unit which will begin on the side's keep will be the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys '''x''', '''y''' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using '''canrecruit=yes''') and if one is found it will be used instead of the one described in the '''[side]''' tag. Typical keys used for defining the leader unit are '''type''' (mandatory), '''id''', '''name''' and '''unrenamable=yes''', see [[SingleUnitWML]].

* '''recruit''': a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* '''gold''': the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* '''income''': the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* '''hidden''': if 'yes', side is not shown in status table.

* '''fog''': if 'yes', this side cannot see any tiles it is not within vision of, except at the start. Please note that the AI currently ignores the fog.

* '''fog_data''': describes the area which this team has de-fogged, using the same format as shroud_data. (This is not particularly useful when defining a side, though, as the game will recalculate fog as turns begin and end. {{DevFeature1.11}}It is used in saved games.)

* '''[fog_override]''' {{DevFeature1.11}} With keys x= and y=, this records the hexes that have been cleared (multiturn) with {{tag|DirectActionsWML|lift_fog}}.

* '''shroud''': if 'yes', this side cannot see any tiles it has not moved within sight of. Please note that the AI currently ignores the shroud. NOTE: with shroud=no, this team *ignores* shroud, so it is not possible to modify it using place_shroud and remove_shroud tags. If you want to do so, use "shroud=yes" and place_shroud/remove_shroud tags.

* '''shroud_data''': describes the area which this team has de-shrouded. An example:
|
|00011111000
:This would leave the first column on the map unaltered and would change the second column for 11 tiles. A '0' means: shrouded, '1' means unshrouded. You can either call an external file using {@filename} (see [[PreprocessorRef]]) or place the data in quotes. For making an external file see [[BuildingScenariosShroudData]].

* '''persistent''': whether the side exists in any other scenarios. If ''yes'', then ''save_id'' (see below) is used to identify the side in other scenarios. Defaults to ''yes'' for sides with a human controller, and ''no'' for ai controlled sides.

* '''save_id''': defaults to the leader's ''id'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog. (For versions prior to 1.7.3, some extra effort to retrieve carryover information may be needed. See [[SideSwitchingWML]])

* '''team_name''': a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''. ''team_name'' is now a comma-separated list of teams that the side is on.

* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* '''current_player''': a translatable string representing the player's or leader's name. Defaults to the leader's id; if the side's leader is a human player in multiplayer, the default is the player's username.

* '''color''': May be either a numeric color index or a color name (e.g. 'blue', 'purple', 'orange', etc.). The numeric form is deprecated. The default list of numbers and corresponding colors can be found in data/core/team_colors.cfg.

* '''flag''': a custom flag animation to use instead of the default one to mark captured villages. An automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* '''flag_icon''': a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* '''village_gold''': the amount of gold given to this side per village it controls per turn. Default specified in ''village_income'', '''[game_config]''' ([[GameConfigWML]]).

* '''village_support''': {{DevFeature1.11}} the number of unit levels this side is able to support (does not pay upkeep on) per village it controls. Default specified in ''village_support'', '''[game_config]''' ([[GameConfigWML]]).

* '''recall_cost''': the amount of gold it costs to recall a unit. Default specified in ''recall_cost'', '''[game_config]''' ([[GameConfigWML]]).

* '''share_maps''': whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* '''share_view''': whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* '''scroll_to_leader''': optional. If 'no', scroll to the leader is not performed on the start of each turn. (default: yes)

* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} If "yes", then the player will not be asked to confirm ending their turn even if they have not done anything. This is provided for some (probably few) user-made scenarios in which players often skip their turns. (default: no)

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village. If the pair of coordinates is not a village or is duplicated in another [village] tag, behaviour is undefined. Recent game engine or wmllint should warn about these.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

The following keys are multiplayer only:

* '''allow_player''': if false then this side will not be allowed to be modified and will be hidden during game creation. (default: no if controller is ai, otherwise yes)

* '''disallow_observers''': prevents observers from seeing this side turn. (default: no)

* '''team_lock''': if true then this side's team is not allowed to be modified.

* '''color_lock''': if true then this side's color is not allowed to be modified.

* '''gold_lock''': if true then this side's gold is not allowed to be modified.

* '''income_lock''': if true then this side's income is not allowed to be modified.

* '''faction''': this lock this side to this faction.

* '''faction_from_recruit''': if true then this side will be locked to the faction that matches the recruits better.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

MultiplayerContent

2013-05-07T11:51:30Z

Thunderstruck:

This guide is intended for version '''1.6.4 and higher'''.

A forum thread about multiplayer campaigns in older versions can be found [http://www.wesnoth.org/forum/viewtopic.php?t=11349 here].

= 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 [[http://forum.wesnoth.org/viewtopic.php?p=405807#p405807]]
* 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.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

[[Category:Create]]

SoC2013 thunderstruck MP Campaign Support

2013-05-04T20:37:52Z

Thunderstruck: formatting

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Specifies multiplayer campaign
# starting points (scenarios) in order
# they should appear to the user.
entry_points = scenario_id1,scenario_id3,scenario_id5

# details ommited..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details ommited..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
TODO: is it okay to re-parse WML when creating a mp game? if yes, how to boost the loading speed? if no, how to add properly working difficulties for mp without using defines?
<dl>
;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'entry_points' attributes. The [multiplayer] tag would be removed. However 'MULTIPLAYER' define would still be used, but would play a less important role i.e. it would only be used to make adjustements between singleplayer and multiplayer in hybrid campaigns. Additionally, stand-alone multiplayer scenarios would be treated as single scenario multiplayer campaigns.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at a loading time of game configs and upgrade all configs identified as an old multiplayer WML. Additionally, the upgrader utility should also wrap eras around with unique defines.

:TODO
:Upgrader's functionality:
:* [multiplayer] -> [scenario]
:* #ifdef MULTIPLAYER -> [campaing]..[/campaign] #ifdef CAMPAIGN_NAME .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** entry_points would be populated by scenarios which would not have 'allow_new_game=no'
:** fields such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty
:* [era]..[/era] -> #ifdef ERA_ID [era]..[/era] #endif

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is created. However, since game loading speed is very important for multiplayer games, some adjustments would have to be made. When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every campaign and using that path to load everything under that directory.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and causes small, but important and undesirable gameplay changes (e.g. wrong carryover or xp calculations). To address those issues, multiplayer game saves storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
</dl>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Multiplayer WML 1
|MANDATORY
|Modify controllers to load multiplayer games using CampaignWML and ScenarioWML.
|
|-
|2
|Multiplayer WML 2
|MANDATORY
|<s>Remove 'scoped_preproc_define's for 'MULTIPLAYER'. All things which depend on it will break and have to be fixed and adjusted to work with the new syntax.</s>
|
|-
|3
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|4
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|
|-
|5
|Game lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'entry_points' attributes. Multiplayer campaigns and scenarios would be separated as well. This modification would allow to display only relevent campaigns and scenarios in singleplayer and multiplayer game lists.
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|
|-
|9
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-05-04T20:21:09Z

Thunderstruck: timeline and game engine adjustments

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save and restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# Specifies multiplayer campaign
# starting points (scenarios) in order
# they should appear to the user.
entry_points = scenario_id1,scenario_id3,scenario_id5

# details ommited..
[/campaign]

#ifdef CAMPAIGN_SYMBOL
# details ommited..

#endif
----

'''''Scenario file'''''
----
''before:''
[multiplayer]
# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----
TODO: is it okay to re-parse WML when creating a mp game? if yes, how to boost the loading speed? if no, how to add properly working difficulties for mp without using defines?
<dl>
;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'entry_points' attributes. The [multiplayer] tag would be removed. However 'MULTIPLAYER' define would still be used, but would play a less important role i.e. it would only be used to make adjustements between singleplayer and multiplayer in hybrid campaigns. Additionally, stand-alone multiplayer scenarios would be treated as single scenario multiplayer campaigns.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the utility responsible for upgrading old multiplayer games will have to be implemented. It should be called at a loading time of game configs and upgrade all configs identified as an old multiplayer WML. Additionally, the upgrader utility should also wrap eras around with unique defines.

:TODO
:Upgrader's functionality:
:* [multiplayer] -> [scenario]
:* #ifdef MULTIPLAYER -> [campaing]..[/campaign] #ifdef CAMPAIGN_NAME .. #endif (only in '_main.cfg')
:** campaign_type="mp"
:** entry_points would be populated by scenarios which would not have 'allow_new_game=no'
:** fields such as 'id' and 'name' would be set up by path to campaign
:** all other non-mandatory fields would be left empty
:* [era]..[/era] -> #ifdef ERA_ID [era]..[/era] #endif

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. This would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Configs loading
:The game configs for all multiplayer games are currently loaded when "Multiplayer" option is chosen from the main menu. The proposed solution would allow to avoid that, because multiplayer campaigns would have their own campaign define and would be loaded with appropriate difficulty only once game is created. However, since game loading speed is very important for multiplayer games, some adjustments would have to be made. When creating a game, instead of loading all WML again, we would have to load only a particular campaign we are interested. This would be done by keeping track of path to '_main.cfg' for every campaign and using that path to load everything under that directory.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and causes small, but important and undesirable gameplay changes (e.g. wrong carryover or xp calculations). To address those issues, multiplayer game saves storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
<dd><pre>
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)
</pre>

''after:''
<dd><pre>
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
</pre>
<dl/>
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with 'entry_points' has more than one attribute), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax. This is going to happen gradually, along with game engine improvements, but it should be finally ported and polished at this time.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks and/or tasks from [[SoC2013_thunderstruck_MP_Campaign_Support#Additional_Improvements|Additional Improvements]] section.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update relevant wiki pages.

==Goals==

{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|1
|Multiplayer WML 1
|MANDATORY
|Modify controllers to load multiplayer games using CampaignWML and ScenarioWML.
|
|-
|2
|Multiplayer WML 2
|MANDATORY
|<s>Remove 'scoped_preproc_define's for 'MULTIPLAYER'. All things which depend on it will break and have to be fixed and adjusted to work with the new syntax.</s>
|
|-
|3
|Loading game configs
|OPTIONAL
|Improve game configs loading time by introducing a loading mechanism which would only load configs under specific sub-directory (path to campaign's '_main.cfg').
|
|-
|4
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|
|-
|5
|Game lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'entry_points' attributes. Multiplayer campaigns and scenarios would be separated as well. This modification would allow to display only relevent campaigns and scenarios in singleplayer and multiplayer game lists.
|
|-
|6
| style=white-space:nowrap | Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|
|-
|7
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|
|-
|8
|Multiplayer WML upgrade 3
|OPTIONAL
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|
|-
|9
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|
|-
|10
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it in create window.
|
|-
|11
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|12
|Save and restore 1
|MANDATORY
|Improve multiplayer save games storing in order to fix current issues.
|
|-
|13
|Save and restore 2
|OPTIONAL
|Implement stricter checks for OOS and fix any new observed issues.
|
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|14
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|
|-
|15
|Multiplayer screens 2
|OPTIONAL
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|
|-
|16
|Multiplayer screens 3
|OPTIONAL
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|
|-
|17
|Multiplayer screens 4
|OPTIONAL
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.


==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 
[https://github.com/wesnoth/wesnoth-old/commit/91faffb79fb18985aae7a6c582d908a074f401c5 91faffb] 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-04-30T19:28:40Z

Thunderstruck: added save/restore stuff

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save/restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details ommited..
[/campaign]
----

'''''Scenario file'''''
----
''before:''
[multiplayer]

# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

# Indicates a stand-alone multiplayer scenario
# or campaign entry point.
# Optional. 'yes' will be used as a default value.
allow_new_game=yes

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----

;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'allow_new_game' attributes.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the class responsible for upgrading old multiplayer games will have to be made. It should be called at loading time of game configs and upgrade all configs identified as an old multiplayer WML.

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. That would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Saving and restoring
:Wesnoth's multiplayer users experience several issues with save/restore games. Most of those issues are not immediately visible and causes small, but important and undesirable gameplay changes (e.g. wrong carryover or xp calculations). To address those issues, multiplayer game saves storing needs to be carefully reviewed and improved. Furthermore, the stricter check for OOS could be made to make it easier to notice save/restore issues.

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)

:''after:''
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with allow_new_game=yes), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----

===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks.
:* 'Additional Improvements'.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update wiki pages.

==Goals==

TODO:more concrete descriptions, better ordering, more optional tasks
{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|0
|Multiplayer WML 1
|MANDATORY
|Modify controllers to load multiplayer games using CampaignWML and ScenarioWML.
|n/a
|-
|0
|Multiplayer WML 2
|MANDATORY
|Remove scoped_preproc_define for 'MULTIPLAYER'. All things which depend on it will break and have to be fixed and adjusted to work with the new syntax.
|n/a
|-
|0
|Refactor game controller 1
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|n/a
|-
|0
|Refactor game controller 2
|MANDATORY
|Re-enable multiplayer games to be started from command line.
|n/a
|-
|0
|Game lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'allow_new_game' attributes. Multiplayer campaigns and scenarios would be separated as well. This modification would allow to display only relevent campaigns and scenarios in singleplayer and multiplayer game lists.
|n/a
|-
|0
|Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|n/a
|-
|0
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|n/a
|-
|0
|Multiplayer WML upgrade 3
|MANDATORY
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|n/a
|-
|0
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|n/a
|-
|0
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it in create window.
|n/a
|-
|0
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the same window as a button. Add drop-down box or dialog for choosing difficulties. Connect GUI changes with relevant code.
|n/a
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|0
|Save and restore 1
|MANDATORY
|Identify current issues.
|n/a
|-
|0
|Save and restore 2
|MANDATORY
|Improve multiplayer save games storing.
|n/a
|-
|0
|Save and restore 3
|MANDATORY
|Implement stricter checks for OOS and fix any new observed issues.
|n/a
|-
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|0
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|n/a
|-
|0
|Multiplayer screens 2
|MANDATORY
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|n/a
|-
|0
|Multiplayer screens 3
|MANDATORY
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|n/a
|-
|0
|Multiplayer screens 4
|MANDATORY
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|n/a
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
TODO: 
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Improve multiplayer loading time. The problem was described [https://gna.org/bugs/?11503 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-04-30T08:10:17Z

Thunderstruck: formatting

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save/restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details ommited..
[/campaign]
----

'''''Scenario file'''''
----
''before:''
[multiplayer]

# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

# Indicates a stand-alone multiplayer scenario
# or campaign entry point.
# Optional. 'yes' will be used as a default value.
allow_new_game=yes

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----

;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'allow_new_game' attributes.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the class responsible for upgrading old multiplayer games will have to be made. It should be called at loading time of game configs and upgrade all configs identified as an old multiplayer WML.

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. That would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Saving and restoring
:TODO:
*loading the game from the non-host won't let to finish scenario

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

:Multiplayer screens logic
:''before (taken from the multiplayer.cpp):''
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)

:''after:''
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with allow_new_game=yes), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----


===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks.
:* 'Additional Improvements'.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update wiki pages.

==Goals==

TODO:more concrete descriptions, better ordering
{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|0
|Multiplayer WML 1
|MANDATORY
|Modify controllers to load multiplayer games using CampaignWML and ScenarioWML.
|n/a
|-
|0
|Multiplayer WML 2
|MANDATORY
|Remove scoped_preproc_define for 'MULTIPLAYER'. All things which depend on it will break and have to be fixed and adjusted to work with the new syntax.
|n/a
|-
|0
|Refactor game controller 1
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|n/a
|-
|0
|Refactor game controller 2
|MANDATORY
|Re-enable multiplayer games to be started from command line.
|n/a
|-
|0
|Game lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'allow_new_game' attributes. Multiplayer campaigns and scenarios would be separated as well. This modification would allow to display only relevent campaigns and scenarios in singleplayer and multiplayer game lists.
|n/a
|-
|0
|Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|n/a
|-
|0
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|n/a
|-
|0
|Multiplayer WML upgrade 3
|MANDATORY
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|n/a
|-
|0
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|n/a
|-
|0
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it create window.
|n/a
|-
|0
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the save window as a button. Add drop-down box/dialog for difficulties. Connect GUI changes with relevant code.
|n/a
|-
| -
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|0
|TODO:Save/restore
|MANDATORY
|desc
|n/a
|-
| -
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|0
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|n/a
|-
|0
|Multiplayer screens 2
|MANDATORY
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|n/a
|-
|0
|Multiplayer screens 3
|MANDATORY
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|n/a
|-
|0
|Multiplayer screens 4
|MANDATORY
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|n/a
|-
| -
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
TODO: 
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Improve multiplayer loading time. The problem was described [https://gna.org/bugs/?11503 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-04-29T20:43:52Z

Thunderstruck: update goals and other minor changes

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaign improvements</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save/restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details ommited..
[/campaign]
----

'''''Scenario file'''''
----
''before:''
[multiplayer]

# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

# Indicates a stand-alone multiplayer scenario
# or campaign entry point.
# Optional. 'yes' will be used as a default value.
allow_new_game=yes

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----

;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'allow_new_game' attributes.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the class responsible for upgrading old multiplayer games will have to be made. It should be called at loading time of game configs and upgrade all configs identified as an old multiplayer WML.

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. That would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Saving and restoring
:TODO:
*loading the game from the non-host won't let to finish scenario

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

;'''''Multiplayer screens logic'''''
:''before (taken from the multiplayer.cpp):''
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)

:''after:''
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with allow_new_game=yes), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----


===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks.
:* 'Additional Improvements'.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update wiki pages.

==Goals==

TODO:more concrete descriptions, better ordering
{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|0
|Multiplayer WML 1
|MANDATORY
|Modify controllers to load multiplayer games using CampaignWML and ScenarioWML.
|n/a
|-
|0
|Multiplayer WML 2
|MANDATORY
|Remove scoped_preproc_define for 'MULTIPLAYER'. All things which depend on it will break and have to be fixed and adjusted to work with the new syntax.
|n/a
|-
|0
|Refactor game controller 1
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|n/a
|-
|0
|Refactor game controller 2
|MANDATORY
|Re-enable multiplayer games to be started from command line.
|n/a
|-
|0
|Game lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'allow_new_game' attributes. Multiplayer campaigns and scenarios would be separated as well. This modification would allow to display only relevent campaigns and scenarios in singleplayer and multiplayer game lists.
|n/a
|-
|0
|Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|n/a
|-
|0
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|n/a
|-
|0
|Multiplayer WML upgrade 3
|MANDATORY
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|n/a
|-
|0
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|n/a
|-
|0
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it create window.
|n/a
|-
|0
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the save window as a button. Add drop-down box/dialog for difficulties. Connect GUI changes with relevant code.
|n/a
|-
|-
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|0
|TODO:Save/restore
|MANDATORY
|desc
|n/a
|-
|-
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|0
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|n/a
|-
|0
|Multiplayer screens 2
|MANDATORY
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|n/a
|-
|0
|Multiplayer screens 3
|MANDATORY
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|n/a
|-
|0
|Multiplayer screens 4
|MANDATORY
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|n/a
|-
|-
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
TODO: 
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Improve multiplayer loading time. The problem was described [https://gna.org/bugs/?11503 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-04-29T09:44:05Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

==Description==
<h4>Andrius Silinskas (thunderstruck) - Multiplayer campaigns improvements (draft)</h4>
The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

==IRC==
thunderstruck

==The Project==
===Introduction===
The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save/restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

===WML syntax changes===
'''''Multiplayer campaign file'''''
----
''before:''
#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

''after:''
[campaign]
# Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'.
# Optional. 'sp' will be used as a default value.
campaign_type="mp"

# details ommited..
[/campaign]
----

'''''Scenario file'''''
----
''before:''
[multiplayer]

# details ommited..

[/multiplayer]

''after:''
[scenario]
# details ommited..

# Indicates a stand-alone multiplayer scenario
# or campaign entry point.
# Optional. 'yes' will be used as a default value.
allow_new_game=yes

[side]
# details ommited..

# Specifies whether players should be allowed to choose factions.
# Optional. 'yes' will be used as a default value.
custom_side=no

# Specifies whether players should be allowed to modify an order of turns for the sides.
# Optional. 'no' will be used as a default value.
custom_turns=yes

# These should be no longer neccessary:
# save_id=1
# persistent=yes
[/side]
[/scenario]
----

===Game Engine Improvements===
====Important====
----

;New syntax support
:Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'allow_new_game' attributes.

;Old syntax support
:After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the class responsible for upgrading old multiplayer games will have to be made. It should be called at loading time of game configs and upgrade all configs identified as an old multiplayer WML.

;Further new syntax support
:To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. That would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.

;Saving and restoring
:TODO:
*loading the game from the non-host won't let to finish scenario

;Players management
:The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.

;'''''Multiplayer screens logic'''''
:''before (taken from the multiplayer.cpp):''
lobby <-> create <-> connect <-> (game)
lobby <------------> wait <-> (game)

:''after:''
lobby <-> create <-> connect_host <-> (game)
lobby <------------> connect_player <-> (game)
----

====Not-so-important====
----
;Additional players management
:The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
;SideWML
:Default values for 'allow_player' attribute should be added to make SideWML less redudant.
----

===GUI improvements===
====Important====
----
;Create game window
:The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with allow_new_game=yes), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.

;Connect window
:The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.
----

====Not-so-important====
----
;Connect window
:Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.
----


===Additional Improvements===

[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 Some other things] not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned above and would be done at the very end if there is time left or possibly after GSoC.

And also there are some [http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs] who would be worth looking at.

==Timeline==
;May 3 - May 27 (pre-GSoC):
:* Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
:* Do a further research on project's implementation and make notes on that.
:* Exam period at the University.

;May 27 - June 17 (community bonding period):
:* Resolve any ambiguities and issues (if any) with the project's proposal.
:* Start coding.

;June 17 - July 25:
:* Game engine: new and old syntax support, save/restore issues.
:* GUI: create game window.

;July 25 - August 2 (midterm evaluation):
:* Extensive testing of implemented things.
:* Port LoW to the new syntax.

;August 2 - August 10:
:* Game engine: players management.
:* GUI: connect window.

;August 10 - September 16:
:* Extensive testing of implemented things.
:* Code clean-up and polish.
:* Implementing 'not-so-important' tasks.
:* 'Additional Improvements'.

;September 16 - September 27 (final evaluation):
:* Fix any left blocking bugs.
:* Write documentation.
:* Update wiki pages.

==Goals==

TODO:more concrete descriptions, better ordering
{| border="1"
! ID
! NAME
! PRIORITY
! DESCRIPTION
! STATUS
|-
|0
|Multiplayer WML
|MANDATORY
|Enable to load multiplayer games using CampaignWML and ScenarioWML. Involves tweaking playcampaign.cpp and game controllers.
|n/a
|-
|0
|Refactor game controller
|MANDATORY
|Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded.
|n/a
|-
|0
|Command line
|MANDATORY
|Re-enable multiplayer games to be started from command line.
|n/a
|-
|0
|Games lists
|MANDATORY
|Sort out between singleplayer and multiplayer games using 'campaign_type' and 'allow_new_game' attributes. Multiplayer campaigns and scenarios would be separated as well.
|n/a
|-
|0
|Multiplayer WML upgrade 1
|MANDATORY
|Implement a utility class to upgrade old multiplayer WML configs to the new syntax.
|n/a
|-
|0
|Multiplayer WML upgrade 2
|MANDATORY
|Use upgrader class to upgrade all relevant configs at a loading time.
|n/a
|-
|0
|Multiplayer WML upgrade 3
|MANDATORY
|Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'.
|n/a
|-
|0
|Create window 1
|MANDATORY
|Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one.
|n/a
|-
|0
|GUI2 drop-down box
|OPTIONAL
|Implement a drop-down box for GUI2 in order to use it create window.
|n/a
|-
|0
|Create window 2
|MANDATORY
|Remove "Load game" option from the scenarios list and place it in the save window as a button. Add drop-down box/dialog for difficulties. Connect GUI changes with relevant code.
|n/a
|-
|0
|Milestone 1
|MILESTONE
|Everything above to be done by July 10.
|n/a
|-
|0
|TODO:Save/restore
|MANDATORY
|desc
|n/a
|-
|0
|Milestone 2
|MILESTONE
|Everything above to be done by July 25.
|n/a
|-
|0
|Multiplayer screens 1
|MANDATORY
|Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes.
|n/a
|-
|0
|Multiplayer screens 2
|MANDATORY
|Enable engine to display multiplayer connect window instead of wait for non-host players.
|n/a
|-
|0
|Multiplayer screens 3
|MANDATORY
|Tweak engine to disable/lock relevant connect window options for host and non-host players.
|n/a
|-
|0
|Multiplayer screens 4
|MANDATORY
|Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario.
|n/a
|-
|0
|Milestone 3
|MILESTONE
|Everything above to be done by August 10.
|n/a
|}

==Future Aspects==
TODO: 
Since a whole dedicated summer for multiplayer improvements sounds like a lot, it definetely won't fix all things need to be fixed and won't implement all desirable features. So I think it is worth to note some thoughts on the possible significant (more or less) changes of multiplayer in Wesnoth.

* Allow 2 or more players to play the same side by splitting units among them. Suggested [http://forums.wesnoth.org/viewtopic.php?f=15&t=38683#p551723 here].
* Enable communal choices. Suggested in the same post as above.
* Improve multiplayer loading time. The problem was described [https://gna.org/bugs/?11503 here].

==Questionnaire==
===1) Basics===
'''1.1) Write a small introduction to yourself.''' 
Hello, my name is Andrius Silinskas and I am an enthusiastic programmer. I would describe myself as a keen and curious person. I enjoy working in many areas of Computer Science but I have not yet found the one which interests me the most. My current goal is to find it and be great at it.

'''1.2) State your preferred email address.''' 
silinskas.andrius [at] gmail [dot] com

'''1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?''' 
thunderstruck

'''1.4) Why do you want to participate in summer of code?''' 
I like to solve problems. Summer of code seems a perfect oppurtunity for this, because then I would be able to dedicate my whole time for it and meanwhile I could also do something useful to others.

'''1.5) What are you studying, subject, level and school?''' 
I have just finished my 2nd year at Heriot-Watt University in the United Kingdom. I am studying Computer Science there.

'''1.6) What country are you from, at what time are you most likely to be able to join IRC?''' 
I am from Lithuania, but I live in the UK now. I lurk on IRC all day, so that would be 7 - 23 in UTC.

'''1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.''' 
I don't have any other commitments, but I plan to go for a week or two to Lithuania. However, I would still be able to dedicate the required amount of time while being there.

===2) Experience===
'''2.1) What programs/software have you worked on before?''' 
Most of the programming I did was for university's assignments or my own small projects. Some of them:
* Whilst learning Python I developed a countdown timer with numerous features using Gtk+.
* For the Coursera's online course I wrote a lexer and parser for "COOL" programming language using Java.
* As an exercise I developed an audio recording/playing application using a low level API in C++.
* For the university's assignment I wrote a simple spell checker program with my own implemented Hash Table data structure in Java.

'''2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)''' 
I was developing software in a team for a few assignments at university. Although they didn't involve much work, I gained a good idea about developing a software in a team.

'''2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?''' 
No, it is my first time.

'''2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.''' 
No, I am not.

'''2.5) Gaming experience - Are you a gamer?''' 
I consider myself a casual gamer.

'''2.5.1) What type of gamer are you?''' 
Usually, when I play games I tend to explore as much as possible and find a most efficient way to complete a certain level, mission or some task of the game. I guess that means that I am an exploring type of gamer.

'''2.5.2) What type of games?''' 
I mostly prefer games which are rather simple in their rules, but allow great possibilities and complexity later on. As for now, World of Goo and Wesnoth (at least in principle) are the games which are like that. I also really enjoy playing a bord game GO, because of the same thing.

'''2.5.3) What type of opponents do you prefer?''' 
I prefer opponents whose behaviour is hard to predict, who sometimes do really good and who sometimes do mistakes. In other words, I like my opponents to be as similar to humans as possible.

'''2.5.4) Are you more interested in story or gameplay?
As they are both vital to a good game, it is hard to tell which interests me more. But I would probably say story, because story alone is something (e.g. a book), while gameplay alone would get boring soon.

'''2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.''' 
Yes, I have. I know the game for about 2 years, but I haven't played it regularly all the time. Although I had peaks where I played Wesnoth quite a lot.
I would lean towards single player, because it has a better story and seems to be more finished.

'''2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.''' 
[https://gna.org/patch/?3769 #3769] 
[https://gna.org/patch/?3777 #3777] (not reviewed yet) 
[https://gna.org/patch/?3844 #3844] 
[https://gna.org/patch/?3862 #3862] (closed by my request, but it still shows my involvement in Wesnoth) 

===3) Communication skills===
'''3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.''' 
My English grammar is still not perfect, but I don't have problems whatsoever while communicating in English.

'''3.2) What spoken languages are you fluent in?''' 
English and Lithuanian.

'''3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.''' 
I think I am. I have been playing MMO games in the past and I was successful at interacting with other players. I've also been a game master for a MMORPG where I had to interact with the players and they were not always nice.

'''3.4) Do you give constructive advice?''' 
At least most of the time, yes. I always try to be positive when giving any sort of advice.

'''3.5) Do you receive advice well?''' 
I think I do. I tend to carefully listen to advice I get.

'''3.6) Are you good at sorting useful criticisms from useless ones?''' 
That is hard to tell, but I always give a thought about criticism I receive and I think I cope well with it.

'''3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want''' 
I would say I am quite autonomous but I don't mind discussing with others when it is needed either. I tend to try to do things on my own as much as possible and then discuss what is not clear to me.

===4) Project===
'''4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?''' 
I've selected 'Game Engine: Improve Multiplayer Campaign Support' project.

'''4.2) If you have invented your own project, please describe the project and the scope.''' 
-

'''4.3) Why did you choose this project?''' 
As I have already stated, I like solving problems. It seems that this project is rather an interesting problem due to lots of different aspects involved. And I would also like to make multiplayer better, since as I have already said that singleplayer surpasses multiplayer.

'''4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#Timeline|Timeline]] section.

'''4.5) Include as much technical detail about your implementation as you can''' 
See [[SoC2013_thunderstruck_MP_Campaign_Support#The_Project|The Project]] section.

'''4.6) What do you expect to gain from this project?''' 
Apart from gaining more experience and improving my technical skills, I expect to get involved in Open Source community and have a great time.

'''4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?''' 
I probably risk to sound like a guy who is promising in order to be accepted, but I already feel like staying with Wesnoth from what I have already experienced.

===5) Practical considerations===
'''5.1) Are you familiar with any of the following tools or languages?''' 
''Git (used for all commits)'' 
I am new to Git and still learning, but I know my way around pretty well.

''C++ (language used for all the normal source code)'' 
Since C++ is such a big language, I can't say that I already know it very well, but I feel confident using it for this project.

''STL, Boost, Sdl (C++ libraries used by Wesnoth)'' 
I have some experience with Boost and STL, but not Sdl.

''Python (optional, mainly used for tools)'' 
I haven't programmed with it recently, but I know it quite well.

''build environments (eg cmake/scons)'' 
I mostly use scons (for Wesnoth), but I have used cmake sometimes as well.

''WML (the wesnoth specific scenario language)'' 
I have learnt some of it while preparing my proposal, creating a few small scenarios for fun and while fixing some bugs. I think, I have a grasp of it.

''Lua (used in combination with WML to create scenarios)'' 
I know basics.

'''5.2) Which tools do you normally use for development? Why do you use them?''' 
At the moment, I am in transition to move from GUI development tools to Vim + terminal combination. Although I am still not as efficient as I would want to be, it works pretty well for me. My computer runs Linux.

'''5.3) What programming languages are you fluent in?''' 
Java - mostly used in university. 
C/C++ and Python - learned on my own. 
PHP, JavaScript, Pascal - I know the basics and a bit more. 

'''5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!''' 
No problem at all.

SoC2013 thunderstruck MP Campaign Support

2013-04-27T18:03:07Z

Thunderstruck: Created page with '{{SoC2013Student}} Category:SoC Ideas Multiplayer Campaign Support 2013 ==Description== <h4>Andrius Silinskas (thunderstruck) - Multiplayer campaigns improvements (draft)</h…'

User:Thunderstruck

2013-04-27T17:59:29Z

Thunderstruck: Blanked the page

User:Thunderstruck

2013-04-22T18:22:24Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC Ideas Multiplayer Campaign Support 2013]]

=Description=

<h4>thunderstruck's proposal draft</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks (listed by the order of implementation):
# Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
# Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
# Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
# Enable network players management between scenarios.
# Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks (listed by the order of implementation):
# In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
# Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
# Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

TODO:

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]).

And also there are some bugs who would be worth looking at ([http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]).

=Timeline=

TODO:

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

User:Thunderstruck

2013-04-22T18:21:10Z

Thunderstruck: Undo revision 50389 by Thunderstruck (Talk)

{{SoC2013Student}}
[[Category:SoC_Ideas_Your_Own_Ideas2013]]

=Description=

<h4>thunderstruck's proposal draft</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks (listed by the order of implementation):
# Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
# Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
# Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
# Enable network players management between scenarios.
# Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks (listed by the order of implementation):
# In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
# Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
# Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

TODO:

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]).

And also there are some bugs who would be worth looking at ([http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]).

=Timeline=

TODO:

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

User:Thunderstruck

2013-04-22T18:20:19Z

Thunderstruck: /* Description */

{{SoC2013Student}}
[[Category:SoC_Ideas_Your_Own_Ideas2013]]

=Description=

<h4>thunderstruck - Improve Multiplayer Campaign Support</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks (listed by the order of implementation):
# Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
# Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
# Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
# Enable network players management between scenarios.
# Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks (listed by the order of implementation):
# In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
# Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
# Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

TODO:

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]).

And also there are some bugs who would be worth looking at ([http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]).

=Timeline=

TODO:

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

User:Thunderstruck

2013-04-22T17:31:51Z

Thunderstruck:

User:Thunderstruck

2013-04-22T17:30:36Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC_Ideas_Your_Own_Ideas2013]]

=Description=

<h4>thunderstruck's proposal draft</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks (listed by the order of implementation):
# Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
# Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
# Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
# Enable network players management between scenarios.
# Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks (listed by the order of implementation):
# In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
# Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
# Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

TODO:

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]]).

And also there are some bugs who would be worth looking at ([[http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]]).

=Timeline=

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

User:Thunderstruck

2013-04-22T17:23:51Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC_Ideas_Your_Own_Ideas2013]]

=Description=

<h4>thunderstruck's proposal draft</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be mainly based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks:
# Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
# Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
# Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
# Enable network players management between scenarios.
# Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks:
# In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
# Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
# Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

(Subject to change)

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC.

[[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 ideas]]

And also there are some bugs who would be worth looking at: [[http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]

=Timeline=

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

User:Thunderstruck

2013-04-22T17:21:26Z

Thunderstruck:

{{SoC2013Student}}
[[Category:SoC_Ideas_Your_Own_Ideas2013]]

=Description=

<h4>thunderstruck's proposal draft</h4>

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

=The Project=

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be mainly based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

<h4>WML syntax modifications</h4>
Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

* [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
* [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
* Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
* Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
* 'save_id' attributes should be omitted from [side] tags.

<h4>Engine improvements</h4>
Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks:
1. Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
2. Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
3. Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
4. Enable network players management between scenarios.
5. Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:
* Add default values for 'allow_player' attributes to make SideWML less redundant.
* Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
* Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

<h4>GUI improvements</h4>
Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks:
1. In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
2. Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
3. Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:
* Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
* Players should be presented an option to modify turns of the sides.

<h4>Technical Considerations</h4>

(Subject to change)

Here are some implementation details of major engine modifications.

Multiplayer create window:

Difficulties:
To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management:
The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

<h4>Known Problems</h4>

* Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
* Synchronization for some tags ?
* The multiplayer campaigns written in the old way should still be compatible. ?

<h4>Additional improvements</h4>

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC.

[[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 ideas]]

And also there are some bugs who would be worth looking at: [[http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]

=Timeline=

Now - May 27 (pre-GSoC):
* Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
* Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):
* Resolve any ambiguities and issues (if any) with the project's proposal.
* Start coding.

June 17 - early August:
* Implementing high priority tasks.

early August - mid August:
* Testing.
* Fixing introduced bugs.
* Port LoW to the new syntax.

mid August - 16 September
* Implementing lower priority tasks.

16 September - 23 September
* Write documentation.
* Fix wiki pages.
* More testing.

=IRC=

thunderstruck

=Questionnaire=
TODO: fill out the questionnaire, on your copy of this page. Question are here : [[SoC_Information_for_Google#Does your organization have an application template you would like to see students use?]]

SoC Information for Google

2013-04-20T18:30:31Z

Thunderstruck:

{{Template:SoC2013}}

== SoC Information for Google ==
This is the information that we submit to google as Application in Summer of Code (current status: 2013). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization id ====
wesnoth

==== Organization Name ====
Battle for Wesnoth

==== Organization description ====
<code type="html">
Battle for Wesnoth, or simply Wesnoth, is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.10.6) happened in March 2013. Version 1.10 was released in January 2012, while the current development branch is 1.11.2 that was released earlier this month. We're later in our development cycle, but there are some good projects out there that students can work on.
Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:
<ul>
<li>According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects</li>
<li>We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players</li>
<li>More than two thousand downloads a day</li>
<li>6 million downloads via SourceForge; many more via various mirrors of Linux distributions</li>
<li>Best rated game at the Linux Game Tome[2]</li>
<li>Game of the year 2007, 2008, 2009, 2010, 2011 and 2013 at LinuxQuestions.org[3][4]</li>
<li>In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games</li>
</ul>
Wesnoth's most notable features include:
<ul>
<li>A mature project with continuing active development and frequent improvements after 10 years of development</li>
<li>High quality artwork: both original graphics and music</li>
<li>Well-balanced by a tireless team of playtesters</li>
<li>Fun, unique gameplay</li>
<li>Even after nearly a decade of development and a very solid, fun product already created, there are still plenty of new developers; the frequency of commits to the repository is still increasing</li>
<li>Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.</li>
</ul>
For our Ideas page, please have a look at [5]. There you can find all information required to get you started working on Wesnoth.
[1] <a href="http://www.wesnoth.org/wiki/WesnothPhilosophy">http://www.wesnoth.org/wiki/WesnothPhilosophy</a> 
[2] <a href="http://www.happypenguin.org/list?sort=avg_rating">http://www.happypenguin.org/list?sort=avg_rating</a> 
[3] <a href="http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/">http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/</a> 
[4] <a href="http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/">http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/</a> 
[5] <a href="http://wiki.wesnoth.org/SummerOfCodeIdeas">http://wiki.wesnoth.org/SummerOfCodeIdeas</a>
</code>

==== Organization home page url ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Veteran/New ====
Veteran [Dropdown box answer!]

==== Backup Admin ====
neuhausercova

==== If you chose "veteran" in the dropdown above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

Since 2008 we have participated in 5 years of GSOC, with good results. With the exception of our first year, we pass approximately 75% of our students, and usually get some really interesting code from them.

2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community, even after 5 years. Two others eventually failed, but we learned from them that while great students should be left on their own, average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students.

For our other students, multiple problems collectively led to failure:
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

2010 results:
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

2011 results:
In 2011 we mentored 5 students, with four of those successfully completed their projects. Some continued the work polishing their projects a little further even after GSoC, one continues to actively polish his work and just released a new version of his WML Editor.

2012 results
in 2012 we mentored five students with four of them completing their project successfully. Most were from a set list of ideas provided by the project, which were aimed at fixing or updating parts of the code that never seemed to get fixed.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

2008: 2/4
2009: 5/6
2010: 4/4
2011: 4/5
2012: 4/5

==== If you chose "new" in the dropdown above, have you applied in the past? If so, for what year(s)? ====
[left empty]

==== Why is your organization applying to participate in Google Summer of Code 2013? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors. By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart work in these areas and others that are lagging behind. Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly. Our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. Finally, we feel that it is part of our mandate is to provide a platform for motivated contributors to develop their skills in a positive learning environment.

Overall GSOC has been a win for all parties and we want it to continue in the future.

==== What is the URL for your Ideas list? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? ====
wesnoth-dev@gna.org

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== What criteria did you use to select your mentors for this year's program? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor 2010 and 2011. In 2011 he was a GCI mentor and administrator. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante has been a GSoC mentor for Wesnoth since 2008.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [1] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether. The key is identifying candidates with the right mix of skills and temperament. Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor are in charge of reconnecting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to resolve the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have repository write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well, most have contributed since 2008, or been organizational admins.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before and during the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In previous years, all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====
The steps meant to involve the students in the community are the same steps we use to make it easy and rewarding to stay with the community even after Summer of Code is over. We really try to make students feel part of the community, particularly as equal developers, rather than just students working a summer job. This, we think, make them feel empowered, and want to remain an important part of the community.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====
N/A

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====
[left empty]

== Application template ==
This template is no longer asked for during the initial application. Listing it here so that we can still reference it later on.

==== Does your organization have an application template you would like to see students use? ====

Students wishing to participate in GSoC should copy the questions below to a new page and fill it with the answers.

Please note that we generally plan to meet potential students through our IRC channel. So beside just answering these questions, potential candidates consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Git (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

MultiplayerContent

2013-04-19T12:31:43Z

Thunderstruck:

This guide is intended for version '''1.6.4 and higher'''.

A forum thread about multiplayer campaigns in older versions can be found [http://www.wesnoth.org/forum/viewtopic.php?t=11349 here].

= 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 [[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 ==

* 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.

== See Also ==

* [http://www.wesnoth.org/forum/viewtopic.php?t=11349 Multiplayer Campaigns HOWTO forum post]
* [[BuildingScenarios]]
* [[BuildingMultiplayer]]

[[Category:Create]]

User:Thunderstruck

2013-04-17T18:59:06Z

Thunderstruck:

User:Thunderstruck

2013-04-17T18:58:11Z

Thunderstruck: Created page with '{{SoC2013Student}} Category:SoC_Ideas_Your_Own_Ideas2013 =Description= <h4>thunderstruck's proposal draft</h4> The current multiplayer campaign support from both UMC develo…'