The Battle for Wesnoth Wiki - User contributions [en]

InterfaceActionsWML

2022-07-25T04:06:59Z

Mesilliac: /* Other interface tags */ Added the new "screen_fade" tag and tweaked the description of "color_adjust" which was wrong.

{{WML Tags}}
== Interface actions ==

Part of [[ActionWML]], interface actions are actions that do not have a direct effect on gameplay;
instead, they show something to the player. The main interface tags
are '''[message]''' and '''[objectives]''', but several other tags affect
the interface also.

== [inspect] ==
This user interface instantly displays the gamestate inspector dialog at the current scenario state (the same one that can be brought up with [[CommandMode|the ''':inspect''' command]]), which can be used to inspect the values of WML variables, AI configuration, recall lists, and more.

* '''name''': optional attribute to specify the name of this gamestate inspector dialog. It is just a label to help differentiate between different invocations of gamestate inspector dialog.

== [message] ==
The most commonly used interface action is [message], which displays a message to the user in a dialog box. It can also be used to take input from the user.

The following key/tags are accepted for [message]:
* [[StandardUnitFilter]]: The unit whose profile and name are displayed. Do not use a [filter] tag. If no unit matching this filter is found, the message is not displayed (The unit has probably been killed). [message] elements should be constructed so that it is either guaranteed that a certain unit is alive, or so that dialog flows smoothly even if the message isn't displayed.

* '''speaker''': an alternative to standard unit filter. You may specify as the value of the speaker attribute a unit id or any of the following special values:
** '''narrator''': the dialog box is displayed without a caption for the unit speaking or a unit image
** '''unit''': the primary unit for the event is speaking
** '''second_unit''': the secondary unit for the event is speaking

* '''message''': (translatable) the text to display to the right of the image. ''message'' is sometimes multiple lines; if it is, be sure to use quotes(''' ' ''' or ''' " ''')
* '''male_message''', '''female_message''': {{DevFeature1.13|2}} (translatable) Used instead of ''message'' if the unit's gender matches. Never used if there is no unit (ie ''speaker=narrator''). {{DevFeature1.13|6}} This matches the primary unit, not the secondary unit.
* '''wait_description''': {{DevFeature1.13|2}} the description of this message displayed when other players in a mp game wait for one player doing input in a [message] (with [option]s or [text_input]).
* '''[show_if]''': if present then this message will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
* '''side_for''': (default: all sides) comma-separated list of sides for who message is shown. This will not work with messages that take user input ([option]/[text_input]), which can only ever be shown to the current player. {{DevFeature1.13|0}} side_for= is now also accepted for messages with user input, it specifies on which side the message is shown (defaults to the currently playing side). For messages with input it does not accept a comma seperated list only a single number.
* '''image''': (default: profile image of speaker) the image to display to the left of the message text. Append ~RIGHT() if you want the image to appear on the right side.
** {{DevFeature1.13|0}} none: display no image
* '''mirror''': {{DevFeature1.13|5}}whether to mirror the image specified by the '''image''' attribute.
* '''second_image''': {{DevFeature1.13|6}}same as the '''image''' attribute, but the image is displayed on the right of the message text.
* '''second_mirror''': {{DevFeature1.13|6}}same as '''mirror''', but for the '''second_image''' attribute.
* '''image_pos''': {{DevFeature1.13|5}} whether to show the image on the left or right; supercedes the use of ~RIGHT() described above
* '''caption''': (default: name of speaker) the caption to display beside the image. Name to be displayed. Note: use a translation mark to avoid wmllint errors.
* '''scroll''': Boolean specifying whether the game view should scroll to the speaking unit. Defaults to ''yes''.
* '''highlight''': {{DevFeature1.13|5}} Boolean specifying whether to highlight the speaker. Defaults to ''yes''.
* '''sound''': a sound effect (wav file) to play as the message is displayed. This can be a comma-separated list, from which one will be randomly chosen.
* '''voice''': {{DevFeature1.13|?}} a sound to be played as the message is displayed. This can also be a comma-separated list, from which one will be randomly chosen. This is intended for voiceovers for the message.
* '''[option]''': No '''[option]''' elements have to be used. If '''[option]''' elements are present, then each option will be displayed in a menu for the user to select one option. ''Note: Messages with options will not be shown at all in prestart events''
** '''message''': (translatable) the text displayed for the option. {{DevFeature1.15|1}} This is now a synonym for '''description='''.
** '''image''', '''label''', '''description''', '''default''': See [[DescriptionWML#WML_Format|DescriptionWML]].
** '''value''': {{DevFeature1.13|?}} Gives the option a value to be stored in a variable.
** '''[show_if]''': if present then this option will only be displayed if the conditional statement in this tag is passed (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]])
** '''[command]''': an element containing actions which are executed if the option is selected.
* '''variable''': {{DevFeature1.13|?}} If present, either the index or the value of the chosen option will be stored in the specified variable. Option indexing starts from 1. If option has '''[show_if]''' condition evaluated as false, then it is hidden and excluded from the indexing.
* '''[text_input]''': there can be only one [text_input] tag. this adds a text input field to the message. ''Note: Messages with text_input will not be shown at all in prestart events''
** '''variable''': the variable that the user's input will be written to
** '''label''': a text label to the left of the input field
** '''max_length''': the maximum number of characters that may be typed into the field
** '''text''': text that is written into the field in the beginning
* Check [[EventWML#Multiplayer_safety]] to find out in which events you can safely use '''[option]''' and '''[text_input]''' without causing OOS.

=== Formatting ===
'''[message]''' and other tags such as unit names (user_description), objectives, and floating text can make use of [https://docs.gtk.org/Pango/pango_markup.html#pango-markup Pango markup formatting codes].

Prefer to use single quotes (') instead of double quotes (") within the formatting string, as double quotes would need to be escaped in WML (""). Escaping markup can be done with [https://github.com/wesnoth/wesnoth/blob/9daa10a9f27c5a95520e871417bbd72aa52aa688/src/font/pango/escape.hpp#L38-L42 HTML entities].

For example, if you wanted to write "You are victorious!" in large, italic, gold letters, you might write it this way:

<nowiki>You are victorious!</nowiki>

These are the codes taken from the Pango markup formatting guide:

*'''font''', '''font_desc''': A font description string, such as "Sans Italic 12".
*'''font_family''', '''face''': A font family name.
*'''font_size''', '''size''': Font size in 1024ths of a point, or one of the absolute sizes 'xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', or one of the relative sizes 'smaller' or 'larger'.
*'''font_style''', '''style''': One of 'normal', 'oblique', 'italic'.
*'''font_weight''', '''weight''': One of 'ultralight', 'light', 'normal', 'bold', 'ultrabold', 'heavy', or a numeric weight.
*'''font_variant''', '''variant''': One of 'normal' or 'smallcaps'.
*'''font_stretch''', '''stretch''': One of 'ultracondensed', 'extracondensed', 'condensed', 'semicondensed', 'normal', 'semiexpanded', 'expanded', 'extraexpanded', 'ultraexpanded'.
*'''foreground''', '''fgcolor''', '''color''': An RGB color specification such as '#00FF00' or a color name such as 'red'. The full list of color names may be found in Pango's [https://github.com/GNOME/pango/blob/main/tools/rgb.txt rgb.txt] file.
*'''background, bgcolor''': An RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''underline''': One of 'none', 'single', 'double', 'low', 'error'.
*'''underline_color''': The color of underlines; an RGB color specification such as '#00FF00' or a color name such as 'red'.
*'''rise''': Vertical displacement, in 10000ths of an em. Can be negative for subscript, positive for superscript.
*'''strikethrough''': 'true' or 'false' whether to strike through the text.
*'''strikethrough_color''': The color of strikethrough lines; an RGB color specification such as '#00FF00' or a color name such as 'red'
*'''fallback''': 'true' or 'false' whether to enable fallback. If disabled, then characters will only be used from the closest matching font on the system. No fallback will be done to other fonts on the system that might contain the characters in the text. Fallback is enabled by default. Most applications should not disable fallback.
*'''letter_spacing''': Inter-letter spacing in 1024ths of a point.
*'''gravity''': One of 'south', 'east', 'north', 'west', 'auto'.
*'''gravity_hint''': One of 'natural', 'strong', 'line'.

The following pango attributes are also available directly as attributes of the '''[message]''' tag:
{{DevFeature1.13|4}}

*'''font'''
*'''font_family'''
*'''font_size'''
*'''font_style'''
*'''font_weight'''
*'''font_variant'''
*'''font_stretch'''
*'''color'''
*'''bgcolor'''
*'''underline'''
*'''underline_color'''
*'''rise'''
*'''strikethrough'''
*'''strikethrough_color'''
*'''fallback'''
*'''letter_spacing'''
*'''gravity'''
*'''gravity_hint'''

== [objectives] ==
The other tag used for plot development is '''[objectives]'''.
The '''[objectives]''' tag overwrites any previously set objectives,
and displays text which should describe the objectives of the scenario.
Scenario objectives are displayed on the player's first turn after the tag is used,
or as part of the event if it triggers during that player's turn.
Objectives can also be accessed at any time in a scenario using the
"Scenario Objectives" game menu option, making this tag useful for
scenario-specific information that the player may need to refer to during play.

Attributes of '''[objectives]''':
* '''side''': Default '0'. The side to set the objectives for. A value of 0 sets objectives for all sides. note: There are side-specific objectives and default objectives, which are used in case a side doesn't have specific ones. Specifying 0 sets the default ones.
* '''[[StandardSideFilter]]''' tags and keys: Sets the objectives of all matching sides to these passed specifications (the rest of this [objectives] tag). If no sides (such as when passing side=0) or all sides match, sets the default objectives, and the side specific ones for the matching sides otherwise.
* '''bullet''': Default '• '. Replaces the default bullet, with whatever is passed, for all objectives, gold carryover notes, and notes defined with [note].
* '''summary''': Displayed first in the objectives text, this should describe the basic objective for the overall scenario. Can be omitted.
* '''note''': Displayed last in the objectives text, this is sometimes used for hints or additional information. Can be omitted.
* '''victory_string''': Default ' _ "Victory:"', this text precedes the victory objectives. Can be set to "" too.
* '''defeat_string''': Default ' _ "Defeat:"', this text precedes the defeat objectives. Can be set to "" too.
* '''gold_carryover_string''': Default ' _ "Gold carryover:"', this text precedes the gold carryover information.
* '''notes_string''': Default ' _ "Notes:"', this text precedes the notes.
* '''silent''': Default: not present. If set to "yes", the objectives are silently changed. Else, they will be shown to the user when appropriate.
* '''delayed_variable_substitution''': {{DevFeature1.13|8}} If set to yes, any variables or [insert_tag] are not substituted right away. Instead, they are substituted whenever the objectives are actually viewed.

Tags of '''[objectives]''':
* '''[objective]''': describes a win or loss condition. Most scenarios have multiple win or loss conditions, so use a separate [objective] subtag for each line; this helps with translations.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet, with whatever is provided, for the objective defined by the [objective] block.
** '''red''': Default '0' for winning objectives, '255' for losing objectives. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255' for winning objectives, '0' for losing objectives. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '0'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''description''': text for the specific win or loss condition.
** '''caption''': a text which will be displayed above the ''description''. This can be used to display a subcategory of objectives below ''victory_string'' or ''defeat_string''.
** '''condition''': The color and placement of the text. Values are 'win'(colored green, placed after ''victory_string'') and 'lose'(colored red, placed after ''defeat_string'').
** '''show_turn_counter''': If set to yes, displays the number of turns remaining in the scenario. Default is no.
** '''[show_if]''': A condition that disables the objective if it doesn't hold. Conditional objectives are refreshed at '''[show_objectives]''' time only, or when manually opening the scenario objectives.
* '''[gold_carryover]''': describes how the gold carryover works in this scenario. This is intended to be a more convenient way of displaying carryover information than using the note= key in [objectives].
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided.
** '''red''': Default '255'. Overrides the default red coloring of the entire objective, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire objective, including the bullet.
** '''blue''': Default '192'. Overrides the default blue coloring of the entire objective, including the bullet.
** '''bonus''' (boolean): whether an early finish bonus is granted. If omitted, early finish bonus is not mentioned.
** '''carryover_percentage''': the amount of carryover gold. If omitted, the amount is not mentioned.
** '''[show_if]''': {{DevFeature1.13|11}} Gold carryover will not be shown if the specified condition isn't met. Conditional gold carryover is refreshed at '''[show_objectives]''' time only.
* '''[note]''': describes a note, usually used for hints or additional information. This is an easier way of adding several notes than concatenating them together into a single string to use with the ''note='' key.
** '''bullet''': Default '• ' or whatever is set in the parent [objectives] block. Replaces the default bullet with whatever is provided for the note defined by the [note] block.
** '''red''': Default '255'. Overrides the default red coloring of the entire note, including the bullet.
** '''green''': Default '255'. Overrides the default green coloring of the entire note, including the bullet.
** '''blue''': Default '255'. Overrides the default blue coloring of the entire note, including the bullet.
** '''description''': the text of the note.
** '''[show_if]''': The note will not be shown if the specified condition isn't met. Conditional notes are refreshed at '''[show_objectives]''' time only.

== [set_menu_item] ==
This tag is used to add a custom option in the right-click context menu which can then be used to trigger arbitrary WML commands. The menu items can be set and modified during any event, for example during "start" or "prestart" events. The user can also assign hotkeys to these WML commands unless specified otherwise. When the hotkey is pressed the event will be fired/filtered at the current mouse position.

'''Note:''' Due to limitations in portable devices where there are no scroll bars for context menus, there is a hard-coded limit of 7 custom WML menu items. If you really need to have more than 7 menu items, try combining some of them in a submenu. {{DevFeature1.13|0}} This limitation is being removed in a [http://forums.wesnoth.org/viewtopic.php?p=572554#p572554 future version] of Wesnoth.

* '''id''': the unique id for this menu item. If a menu item with this id already exists, it allows you to set specific changes to that item.
* '''description''': the in-game text that will appear for this item in the menu.
* '''image''': the image to display next to this item.
* '''needs_select''': if ''yes'' (default ''no''), then the latest select event (see [[EventWML]]) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it. {{DevFeature1.13|6}} ''needs_select=yes'' is deprecated, consider using manual variable syncing with [sync_variable].
* '''synced''' {{DevFeature1.13|1}}: if ''no'' (default ''yes'') the command handler will only be run on the client that invoked the menu item; this means that changing the gamestate in a command handler of a menu item with ''synced=no'' will cause OOS
* '''use_hotkey''': if ''no'' (default ''yes''), then the user cannot assign hotkeys to this menu item. If ''only'', the menu item is only accessible via hotkeys, not via right-click context; you can use this in combination with [default_hotkey] if you want custom hotkeys in your campaign/mp.
* '''[show_if]''': If present, the menu item will only be available if the conditional statement (see [[ConditionalActionsWML#Condition_Tags|ConditionalActionsWML]]) within evaluates to true. When this is evaluated, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked, so it's possible to for example only enable the option on empty hexes or on a particular unit.
* '''[filter_location]''': contains a location filter similar to the one found inside Single Unit Filters (see [[FilterWML]]). The menu item will only be available on matching locations.
* '''[default_hotkey]''': contains a hotkey WML to specify what hotkey to assign to this, '''if the user has no hotkey assigned to this yet'''. (Unlike the rest of a menu item definition, modifying this tag has no effect on the game; it is only effective when initially defining a menu item.) Hotkey WML matches the format in the preferences file and contains the following keys:
** '''key''': a string that contains the key to assign to this.
** '''alt''', '''shift''', '''cmd'''(apple only), '''ctrl''': boolean values.
** '''repeat_on_hold''' {{DevFeature1.13|12}}: if ''yes'' (default ''no''), holding the hotkey will repeat the action continuously, unless it blocks input with something like '''[message]'''. Due to a bug, versions older than 1.13.12 always repeat the action, with no way to disable it.
* '''[command]''': contains the WML actions to be executed when the menu item is selected. Again, the WML variables ''$x1'' and ''$y1'' will point to the location on which the context menu was invoked on.
** '''delayed_variable_substitution ''' (boolean yes|no, default: yes): If no, forces a variable substitution run onto the wml included in this [command] block. Use this, if you want variables which are to substitute to get the values they have at execution time of the event where this set_menu_item appears. Other than that, they get the values they have at invocation time of the menu item.

== [clear_menu_item] ==

Removes a menu item from the scenario.
Normally menu items are, including all their defining wml, automatically carried over between scenarios. This tag prevents this. (The behavior is comparable to set_variable/clear_variable).
* '''id''': (string): id of the menu item to clear. Can be a comma-separated list.

== Other interface tags ==

The following tags are also action tags:

=== [change_theme] ===

{{DevFeature1.13|8}}

Change the current interface theme.

* '''theme''': The ID of the new theme. Use <code>theme=</code> (empty key) to switch back to the theme that the player has selected in Preferences. On 1.14.2 and later it is also possible to omit the key entirely to achieve the same effect (on previous versions this will crash the Lua engine).

=== [item] ===
Makes a graphical item appear on a certain hex. Note this only places the graphics for an item. It does not make the item do anything. Use a moveto event to make moving onto the item do something. <tt>''('''Hint:''' There are a number of predefined items that are used in various campaigns that you can make use of. You can find [http://www.wesnoth.org/macro-reference.xhtml#file:items.cfg a list of them] if you look into the items.cfg file in the wesnoth install directory (under /data/core/macros).)''</tt>
* '''x''', '''y''': the location to place the item. (only for [event][item]: full [[StandardLocationFilter|SLF]] support)
* '''image''': the image (in ''images/'' as .png) to place on the hex. This image is aligned with the top-left of the hex (which is 72 pixels wide and 72 pixels tall). It is drawn underneath units. ''('''Hint:''' If using an image smaller than 72x72, then it might be useful to [[ImagePathFunctions#Blit_Function|BLIT]] the image onto <tt>misc/blank-hex.png</tt> (a blank 72x72 image).)''
* '''halo''': an image to place centered on the hex. It is drawn on top of units. Use this instead of ''image'' if the image is bigger than the hex or if you want to animate an image (https://github.com/wesnoth/wesnoth/issues/1219).
* '''name''' an id that can be used to remove the item.
''Example (where the integer after the colon is the duration of each frame or square bracket expansion as per AnimationWML is used): halo=scenery/fire1.png:100,scenery/fire2.png:100,scenery/fire3.png:100,scenery/fire4.png:100,scenery/fire5.png:100,scenery/fire6.png:100,scenery/fire7.png:100,scenery/fire8.png:100''
or equivalently (requires Wesnoth 1.11.2+):
''halo=scenery/fire[1~8].png:100''
* '''team_name''': name of the team for which the item is to be displayed (hidden for others). For multiple teams just put all the names in one string, for example separated by commas. {{DevFeature1.15|0}} In 1.14 the '''[side]team_name''' attribute was expected to be a substring of this '''team_name'''. In 1.15 both are expected to be comma-separated lists of names and the item is visible if the lists intersect. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* '''visible_in_fog''': whether the item should be visible through fog or not. Default yes.
* '''redraw''': (boolean yes|no, default: yes): If no, disables implicit calls to [[InterfaceActionsWML#.5Bredraw.5D|[redraw]]] when placing the items.
* '''[filter_team]''': {{DevFeature1.15|0}} A [[StandardSideFilter]]. Set '''team_name''' to the union of all '''[side]team_name''' attributes of all sides that match the SSF. ([[https://github.com/wesnoth/wesnoth/pull/3533|#3533]])
* {{DevFeature1.15|0}} If both '''team_name''' and '''[filter_team]''' are set, '''team_name''' is ignored.

=== [remove_item] ===
Removes any graphical items on a given hex.
* [[StandardLocationFilter]]: the hexes to remove items from
* '''image''': if specified, only removes the given item if one of its 'image', 'halo' or 'name' attributes is exactly this value. (for 'halo' and 'image' this in particular means that the image name must include any [[ImagePathFunctions|image path functions]] appended to the original image name.)

=== [print] ===
Displays a message across the screen. The message will disappear after a certain time, or when another [print] tag is encountered.
* '''text''': (translatable) the text to display. Can be an empty string to remove a previous message without showing a new one.
* '''size''': (default=12) the pointsize of the font to use
* '''duration''': the length of time to display the text for.
** (Before 1.15.4) This is measured in the number of 'frames', and the default is 50. A frame in Wesnoth is usually displayed for around 30ms.
** {{DevFeature1.15|4}} This is measured in milliseconds. Don't use the default value, because it's a mere 50ms.
** {{DevFeature1.15|14}} The default is 5000 milliseconds.
** {{DevFeature1.15|14}} The string '''unlimited''' displays the text until it's removed by another [print] tag.
* '''color''': (default '''0,0,0''') three comma-separated values giving the red, green and blue values (0-255).
* '''red''', '''green''', '''blue''': deprecated, use color=0,0,0 instead.

=== [move_unit_fake] ===
Moves an image of a unit along a certain path on the map. The path does not need to be a continuous list of adjacent hexes, so for example only the start and end points can be given, in which case the straightest line between those points will be calculated and used.
* '''type''': the type of the unit whose image to use
* '''x''': a comma-separated list of x locations to move along
* '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
* '''side''': the side of the fake unit, used for team-coloring the fake unit
* '''gender''': the gender of the fake unit. Example: gender=female
* '''variation''': the variation of the fake unit. Example: variation=undead
* '''image_mods''': [[ImagePathFunctions|image path functions]] sequence to be applied on the fake unit.
* '''force_scroll''': Whether to scroll the map or not even when [[#.5Block_view.5D|[lock_view]]] is in effect or ''Follow Unit Actions'' is disabled in ''Advanced Preferences''. Defaults to ''yes'' starting with version '''1.11.6'''; the attribute did not exist in previous versions and this action behaved as if ''no'' was passed instead.

=== [move_units_fake] ===
moves multiple images of units along paths on the map. These units are moved in lockstep.
* '''force_scroll''': {{DevFeature1.15|0}} Has the same meaning as in [move_unit_fake] but a different default.
* '''[fake_unit]''': A fake unit to move
** '''type''': the type of unit whose image to use
** '''x''': a comma-separated list of x locations to move along
** '''y''': a comma-separated list of y locations to move along (x and y values are matched pairs)
** '''side''': the side of the fake unit, used for team-coloring the fake unit
** '''skip_steps''': the number of steps to skip before this unit starts moving

=== [hide_unit] ===
Temporarily prevents the engine from displaying the given unit. The unit does not become invisible, as it would be with the '''[hides]''' ability; it is still the same plain unit, but without an image. Useful in conjunction with '''[move_unit_fake]''': to move a leader unit into position on-screen. Until 1.8 each '''[hide_unit]''' tag only hides one unit.
* [[StandardUnitFilter]]: All matching units will be hidden

=== [unhide_unit] ===
Stops the currently hidden units from being hidden.
* [[StandardUnitFilter]]: Only the matching units will be unhidden

=== [lock_view] ===
Locks gamemap view scrolling for human players, so they cannot scroll the gamemap view until it is unlocked. WML or Lua actions such as '''[scroll_to]''' will continue to work normally, as they ignore this restriction; the locked/unlocked state is preserved when saving the current game.

This feature is generally intended to be used in cutscenes to prevent the player scrolling away from scripted actions.

{{DevFeature1.13|8}} This now also blocks the player from zooming the gamemap view. WML or Lua zoom will continue to work normally.

=== [unlock_view] ===
Unlocks gamemap view scrolling for human players.

=== [scroll] ===
Scroll a certain number of pixels in a given direction. Useful for earthquake/shaking effects.
* '''x''', '''y''': the number of pixels to scroll along the x and y axis
* '''side''': the side or sides for which this should happen. By default, the [scroll] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll] happens for everyone.

=== [scroll_to] ===
Scroll to a given hex
* [[StandardLocationFilter]], do not use a [filter_location] sub-tag. If more than one location matches the filter, only the first matching location will be used.
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex being scrolled to (defaults to ''no'').
* '''side''': the side or sides for which this should happen. By default, the [scroll_to] happens for everyone.
* '''[filter_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to] happens for everyone.

=== [scroll_to_unit] ===
Scroll to a given unit
* [[StandardUnitFilter]]
* '''check_fogged''': whether to scroll even to locations covered in fog or shroud. Possible values ''yes'' (don't scroll to fog) and ''no'' (scroll even to fog), with ''no'' as the default.
* '''immediate''': whether to instantly warp to the target hex regardless of the scroll speed setting in Preferences (defaults to ''no'').
* '''highlight''': {{DevFeature1.13|5}} Whether to highlight the hex the unit is on (defaults to ''no'').
* '''for_side''': the side or sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.
* '''[for_side]''': a [[StandardSideFilter]] to select the sides for which this should happen. By default, the [scroll_to_unit] happens for everyone.

=== [select_unit] ===
Selects a given unit.
* [[StandardUnitFilter]]: The first unit found will be selected.
* '''fire_event''': whether a ''select'' event should be triggered or not (def. ''no''). (Note that select events aren't multiplayer save.)
* '''highlight''': whether the unit's current hex should be highlighted (def. ''yes'').

'''Note:''' fire_event does not appear to work in 1.14 or 1.16.

=== [sound]===
Plays a sound
* '''name''': the filename of the sound to play (in ''sounds/'' as .wav or .ogg). This can be a comma-separated list, from which one sound will be chosen randomly.
* '''repeat''': repeats the sound for a specified additional number of times (default=0)

=== [sound_source] ===
Creates a sound source. "Sound sources" is a general name for a mechanism which makes possible for map elements to emit sounds according to some rules, where "map elements" can be specific locations or terrain types. For now, only sound sources tied to locations are supported.
* '''id''': a unique identification key of the sound source
* '''sounds''': a list of comma separated, randomly played sounds associated with the sound source
* '''delay''': a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
* '''chance''': a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)
* '''check_fogged''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are fogged
* '''check_shrouded''': possible values ''yes'' and ''no'' - ''yes'' means the source will not play if its locations are shrouded
* '''x,y''': similar to x,y as found in a [[StandardLocationFilter]], these are the locations associated with the sound source
* '''fade_range''' (default = 3): distance in hexes that determines a "circular" area around the one specified by '''full_range''' where sound volume fades out linearly
* '''full_range''' (default = 14): distance in hexes that determines a "circular" area where source plays with full volume, relative to screen center
* '''loop''': number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000)

=== [story] ===
{{DevFeature1.13|8}}

Shows the story screen.
* '''title''': Default title used if a part does not specify one — unlike the intro storyscreen, the scenario name is not used as a default title.
* '''[part]''': As [[IntroWML]].

=== [remove_sound_source] ===
Removes a previously defined sound source.
* '''id''': the identification key of the sound source to remove

=== [music] ===
Switches to playing different music
* '''name''': the filename of the music to play (in ''music/'' as .ogg)
* see [[MusicListWML]] for the correct syntax

=== [volume] ===
Changes the game volume to a percent of the preferences volume for the game being played. Values can go from 0 to 100:
* '''music''': Changes the music volume.
* '''sound''': Changes the sound volume.

=== [color_adjust] ===
Adjust the color tint of terrain, by adjusting time-of-day coloring.
* '''red''', '''green''', '''blue''': values from -255 to 255, the amount to tint by for each color

=== [screen_fade] ===
{{DevFeature1.17|6}}

Overlay the game display with the given color, fading over the specified duration. This can be used for screen fade effects.
* '''red''', '''green''', '''blue''': values from 0 to 255, the final overlay color (defaults to 0,0,0)
* '''alpha''': value from 0 to 255, the strength of the effect. 0 means no effect and can be used to fade in. 255 means fully opaque and can be used to fully fade out to the given color. Intermediate values will end up with a partial overlay tint on the game screen.
* '''duration''': the length of time it will take to complete the fade, in milliseconds. If 0 the effect is immediate.

=== [delay] ===
Pauses the game.
* '''time''': the time to pause in milliseconds
* '''accelerate ''' (boolean yes|no, default no): {{DevFeature1.13|0}} whether the delay is affected by acceleration. When [delay] is used to make an animation, this should be set to yes so that your animation matches the ones generated by the game.

=== [redraw] ===
Redraws the screen (this normally isn't done during events, although some of the other interface actions cause the screen or parts of it to be redrawn).
* '''clear_shroud''' (boolean yes|no, default no): If yes, clears fog and shroud around existing units. Useful if you, for example, spawn friendly units in the middle of an event and want the shroud to update accordingly (otherwise units that spawn inside fog would remain invisible for the duration of the event, since the fog would not automatically get cleared around them).
* '''[[StandardSideFilter]]''': the sides for which to recalculate fog and shroud.
* '''side''': If used (forces clear_shroud=yes), clears fog and shroud for that side.

=== [unit_overlay] ===
Sets an image that will be drawn over a particular unit, and follow it around
* [[StandardUnitFilter]]: All matching units will get the overlay (do not use [filter])
* '''image''': the image to place on the unit

=== [remove_unit_overlay] ===
Removes a particular overlayed image from a unit
* [[StandardUnitFilter]]: The overlay will get removed from all matching units (do not use [filter])
* '''image''': the image to remove from the unit
Using [[DirectActionsWML#.5Bremove_object.5D|'''[remove_object]''']] is also possible, see https://github.com/wesnoth/wesnoth/commit/26c2f941f2bcdd89528481e114c0375ad2a46271

=== [animate_unit] ===
Uses an animation of a unit to animate it on screen (if the unit has the corresponding animation).
* '''flag''': The key to find the custom animation in the unit description (see the '''[extra_anim]''' description in [[AnimationWML]]). Standard animations can be triggered with the following keywords: ''leading recruited standing idling levelout levelin healing healed poisoned movement defend attack death victory pre_teleport post_teleport''
* '''[filter]''' with a [[StandardUnitFilter]] as argument, see [[FilterWML]]. By default, the unit at the event location will be animated. You can use this tag to choose any other unit to animate.
* '''[primary_attack]''': If this tag is not present, the filter for animation will be triggered with no attack. If it is here, all attacks from the unit will be filtered, and a matching one will be used to filter the animation. Takes a weapon filter as argument, see [[FilterWML]].
* '''[secondary_attack]''': Similar to '''[primary_attack]'''. May be needed to trigger a defense animation correctly, if there are more than one animations available for the defending unit.
* '''hits''': yes/no/hit/miss/kill: which according variation of a attack/defense animation shall be chosen (required)
* '''text''': a text to hover during the animation
* '''male_text''', '''female_text''': {{DevFeature1.13|2}} (translatable) gender-specific versions of the above
* '''red''': red value for the text color (0-255)
* '''green''': green value for the text color
* '''blue''': blue value for the text color
* '''with_bars''': yes/no: whether to display the status bars during the animation (e.g. the hitpoint bar)
* '''[animate]''': a sub block with the same syntax as '''[animate_unit]''' except that the '''[filter]''' block is mandatory to find the unit. This block will find and animate another unit simultaneously.
* '''[facing]''': a [[StandardLocationFilter]] specifying what direction the unit should be facing when animated

=== [label] ===
Places a label on the map.
* '''x''', '''y''': the location of the label. {{DevFeature1.13|1}} (only for [event][label]: full [[StandardLocationFilter|SLF]] support)
* '''text''': what the label should say
* '''team_name''': if specified, the label will only be visible to the given team.
* '''color''': color of the label. The format is r,g,b; r, g and b are numbers between 0 and 255.
* '''visible_in_fog''': whether the label should be visible through fog or not. Default yes.
* '''visible_in_shroud''': whether the label should be visible through shroud or not. Default no.
* '''immutable''': whether this label is protected from being removed or changed by players. Default yes.
* '''category''': the Show/Hide Labels dialog allows showing/hiding all labels of a given category by toggling a checkbox.
* '''tooltip''': A tooltip visible when mouseovering the hex the label is on
* '''side''': the number of the side that placed the label. Can be 0 for labels placed by WML.

=== [floating_text]===
Floats text (similar to the damage and healing numbers) on the given locations.
* [[StandardLocationFilter]]: the text will be floated on all matching locations simultaneously.
* '''text''': the text to display.

The default text color is '''#6b8cff'''. To change the color, use [[#Formatting|Pango markup]]. For example:

<pre>
# Float some golden yellow text at 20,20.
[floating_text]
x,y=20,20
text="" + _ "Your text here" + ""
[/floating_text]
</pre>

=== [deprecated_message] ===
Shows a deprecated message in the message area, this feature is only intended to be used to warn about deprecated macros in mainline. The message is not translatable.
* '''message''': the message to show.
* '''level''': {{DevFeature1.13|10}} The deprecation level, a number from 1 to 3.
* '''what''': {{DevFeature1.13|10}} The name of the thing being deprecated. Use this instead of '''message''' if possible; a stock message will be generated from it. Use '''message''' only if more information is required; it will be appended to the stock message. This should not be translatable
* '''version''': {{DevFeature1.13|10}} For deprecation levels 2 and 3, this indicates the version in which the feature could be removed. It does ''not'' indicate the version in which it became deprecated.

The meanings of the deprecation levels are as follows:

# Deprecated, but will only be removed if absolutely necessary. The '''version''' key is ignored.
# It will be removed no earlier than a specified version.
# It will be removed in the next stable version
# It has already been removed, leaving just a stub to inform users of how to update their code.

Note that as of 1.13.11, deprecation messages show only in the log, not in the chat message area. The '''message''' can be translatable, but does not need to be.

=== [wml_message] ===
Outputs a message to Wesnoth's console output. Intended for campaign designers to output silent text to the console, without annoying the player; then, that text might contain information useful for later bug-reporting. The log domain for it is '''wml''', and the '''debug/dbg''' log level is available for use with the '''logger''' attribute. Depending on the current log level ('''error''' by default), which may be changed with the in-game :log command, or the --log-<level>=wml command line switch, the messages are echoed to the in-game chat.
* '''message''': the message to show.
* '''logger''': the Wesnoth engine output logger that should catch the text; this might be 'err' (the errors log level), 'warn'/'wrn' (the warnings log level) or anything else (the information log level). Not all information will be displayed depending on the log level chosen when starting Wesnoth.

Note: As of 1.9.4/1.9.5 (r48805) the following "loggers" should work: If in [wml_message]: err/error, warn/wrn/warning, debug/dbg; using the :log command: Only the long forms error, warning, info and debug (this part gathered by trying rather than source inspecting). The long forms are most likely also the only ones working when starting wesnoth with --log-<level>=wml.
For log level warning or error (as during normal play), only wml_messages with logger error or warning display (for both). With logger info or debug, additionally wml_messages with logger info or debug display (for both).

=== [test_condition] ===

{{DevFeature1.13|2}}

Evaluates the contained conditional tags. If they evaluate to the expected value, it prints out a message to the console explaining which part of the condition caused this result in a way similar to [wml_message]. This can be used if your conditional test is failing and you're not sure why.

* '''result''': Whether you expect the conditions to fail or succeed. If no (the default), a message will be printed if the conditional tags fail. If yes, a message will instead be printed if the conditional tags pass.
* '''logger''': Same as for [wml_message]. Defaults to "warning".

=== [open_help] ===
Opens the in-game help.
* '''topic''': the id of the topic to open

Examples of ids:
* unit_Mage
* unit_Dark Adept
* weaponspecial_charge
* terrain_human_castle

The engine will print the topic ids if run from the command line with the ''--log-debug=help'' option.

=== [show_objectives] ===
refreshes the objectives defined by [objectives] and its [show_if] tags, and displays them. (It is also called whenever the user explicitly asks for the objectives; this matters only if the tag was overridden by a [[LuaWML#register_wml_action|Lua]] script.)
* '''side''': the side to show the objectives. If not set, all sides are used.
* '''[[StandardSideFilter]]''' tags and keys: Tag affects the matching sides instead of just all or the one given by the integer value of the side= key.

=== [chat] ===
Displays a message in the chat area, not visible for observers. Alternative unconditionally visible for everyone: [[LuaWML:Display#wesnoth.message]]. {{DevFeature1.13|9}} can be visible for observers.
* '''speaker''': (default="WML") A string for the name of the sender of the message.
* '''message''': The message that should be displayed.
* '''observable''' (boolean yes|no, default yes): {{DevFeature1.13|9}} Whether the message is displayed for observers.
* '''[[StandardSideFilter]]''' tags and keys as argument; if the same client controls multiple sides that match, then the message will only be displayed once.

=== [zoom] ===

{{DevFeature1.13|8}}

Changes the zoom level of the map.

* '''factor''': The new zoom factor
* '''relative''': If yes, zoom relative to current zoom level. Otherwise, set the absolute zoom level. Default no.

== Useful Macros ==
There are some predefined macros that you find useful for interface actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{HIGHLIGHT_UNIT}''' Highlight a unit on the map. Use this to show important units
* '''{HIGHLIGHT_IMAGE}''' Places and highlights an image on the map. Use this to show important items or locations
* '''{SET_IMAGE}''' Places an image on the map which has no other function.
* '''{QUAKE <soundfile>}''' Creates a tremor-like screenshake and plays <soundfile>. For example, '''{QUAKE (rumble.ogg)}'''.
* '''{FLASH_WHITE}''' Flash the screen white momentarily. You can also replace WHITE with RED, BLUE or GREEN for a different colour.

== See Also ==
* [[DirectActionsWML]]
* [[InternalActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

ImagePathFunctions

2022-06-05T07:17:34Z

Mesilliac: /* BLIT: Blit function */ Negative coordinates work fine.

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

If you need to practice it without having to reload all WML, you can use an add-on named ''Image loading tester''. It is available on the 1.9, 1.10, 1.11, 1.12 and 1.14 add-on servers.

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like
"units/elves-wood/fighter.png~CROP(20,20,40,40)~CROP(10,10,10,10)"
would result in taking a crop to a 40x40 rectangle whose top-left corner is x=20, y=20; and then taking a crop from ''that'' rectangle with x=10, y=10, w=10, h=10. The result is the area x=30, y=30, w=10, h=10 from the original graphic.

== Changing the colors ==

=== BLEND: Color-blend function ===
Blends the image with the given color to produce a more controlled tinting effect than color-shifting, independently of the image's contents.

'''~BLEND(r,g,b,o)'''

The color is defined by the ''r'', ''g'', and ''b'' parameters (integers ranging from 0 to 255). The ''o'' (opacity) parameter controls the amount by which the given color will be blended into the image, and may be specified either as a factor from 0.0 to 1.0, or percentage up to 100%. Thus, ~BLEND(r,g,b,0.5) and ~BLEND(r,g,b,50%) are equivalent.

=== BW: Black and White function ===
{{devfeature1.13|1}}
May be used to convert the image to pure black and white, without grey pixels.

'''~BW(threshold)'''
* ''threshold'': a value between 0 and 255 (both limits included). All pixels are converted as greyscale first, and if their average value is greater than the threshold they become white, otherwise they become black.

=== CS: Color-shift function ===
Performs simple per-channel color shifts by adding the arguments to the respective color channels.

''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

=== GS: Greyscale function ===
May be used to greyscale the image (turn to black and white)

'''~GS( )'''

=== L: Lightmap color-shift function ===
Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully grey image (RGB = 128,128,128) and any non-grey pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

=== NEG: Negative function ===
{{devfeature1.13|0}}
Also known as ''invert'', it negates all the RGB values of the image, giving it an effect similar to a photographic negative.

'''~NEG( )'''

Inverts the image, giving it an effect like a photographic negative.

{{devfeature1.13|1}} '''~NEG(''' ''threshold'' ''')'''

If a channel has a value greater than the threshold, the channel will be inverted, performing an effect known as ''solarization''.
Threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

{{devfeature1.13|1}} '''~NEG(''' ''threshold_red, threshold_green, threshold_blue'' ''')'''

If a channel has a value greater than the corresponding threshold, the channel will be inverted.
Each threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

=== PAL: Palette-switch function ===
May be used to change colors in an image following the specifications of a source and target (new) palette.

'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

=== RC: Re-Color function ===
May be used to change some colors in an image. It is possible to use ''RC'' more than once on the same image, with different source palettes.

'''~RC(''' ''source color palette'' '''>''' ''destination color range'' ''')'''

==== source color palette ====
The first parameter is a set of colors, usually the magenta palette. Do not surround this parameter with quotes. The three standard palettes are:

* '''magenta''' - the 19 colors described in [[Team_Color_Shifting]]
* '''ellipse_red''' - all 255 colors with RGB value (n,0,0)
* '''flag_green''' - all 255 colors with RGB value (0,n,0)

The palette can also be given inline as a set of hexadecimal RGB values.

The named palettes are defined using the '''[[GameConfigWML#Color_Palettes|[color_palette]]]''' tag, and you can also define your own custom color palette using that tag.

Warning: the RC function will also accept (and not give a warning about) '''red''', '''green''' and any other defined '''[color_range]'''; however the set of RGB values for those aren't guaranteed. Using '''red''' instead of '''ellipse_red''' might be equivalent to the palette 030000,060000,0a0000,...,ff0000,ff0a0a,...,fff0f0.

==== destination color range ====
This is the second parameter, signifying the ID of a color range defined in the file [http://github.com/wesnoth/wesnoth/blob/master/data/core/team-colors.cfg data/core/team-colors.cfg] (or it may be a custom ID for a color range defined locally). You can also define a custom color range inline (the rgb key from [[GameConfigWML#Color_Palettes]]; note that RC does not use the fourth color for anything).

For this destination color range, using '''red''' or '''green''' makes sense.

==== Example ====
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The following example replaces a few of the '''magenta''' pixels with green ones:

misc/orb.png~RC(690039,c30074,ec008c > 007f00,00ff00,000000,000000)

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

=== SEPIA: Sepia function ===
{{devfeature1.13|0}}
May be used to give to the image a sepia tint (like in old pictures).

'''~SEPIA()'''

=== SWAP: Channel Swap function ===
{{devfeature1.13|1}}
May be used to swap the RGBA channels of an image.

'''~SWAP(''' ''r, g, b'' ''')'''
'''~SWAP(''' ''r, g, b, a'' ''')'''
* ''r'', ''g'', ''b'', ''a'': each of these arguments may have a value equal to ''red'', ''green'', ''blue'' or ''alpha''. The RGBA channels of the original image will be exchanged accordingly (for example, <tt>~SWAP(blue,green,red)</tt> swaps the blue and red channels).

=== TC: Team-Color function ===
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Transformations ==

=== FL: Flip function ===
May be used to flip an image horizontally and/or vertically.

'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizontally.
*if the argument list is empty, the image will only be flipped horizontally.

=== ROTATE: Rotate function ===
May be used to rotate an image.

'''~ROTATE(''' ''degrees'' ''')'''
* ''degrees'' - The number of degrees by which the image will be rotated. Positive numbers indicate clockwise rotation, while negative numbers indicate counter-clockwise. (Zero indicates no rotation.)
If the number of degrees is omitted, a quarter turn (90 degrees) clockwise is assumed.

=== SCALE: Image-scaling function ===
Scales a graphic up or down.

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr. This uses the bilinear interpolation algorithm.

=== SCALE_INTO function ===
{{DevFeature1.13|5}}

Similar to SCALE, but preserves aspect aspect ratio, scaling to the minimum extent required to fit into the specified area. The resulting image will have the specified width or the specified height, but not necessarily both.

=== SCALE_SHARP function ===

{{DevFeature1.13|0}}

Scales functions using a nearest neighbor algorithm. Specify width and height. (It has the same syntax as ~SCALE.)

'''~SCALE_SHARP(200,300)'''

=== SCALE_INTO_SHARP function ===
{{DevFeature1.13|5}}

Like SCALE_INTO, but uses nearest neighbor algorithm instead of bilinear interpolation.

=== XBRZ function ===

{{DevFeature1.13|0}}

Scales functions using the XBRZ algorithm. You may scale things up either 2x, 3x, 4x, or 5x. The scaling tries to preserve the pixel art nature.

'''~XBRZ(n)'''

== Cut-and-paste ==

=== BLIT: Blit function ===
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)

'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. If missing assume (0,0).

=== CROP: Crop function ===
Extracts a rectangular section of an image file.

'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width, and must not be negative.
* ''height'': height of the selected region. Must be less than or equal to the original image's height, and must not be negative.

=== MASK: Mask function ===
Remove parts of the main image using the parameter image as a mask. Example: grass.png~MASK(circle.png) will give a circle of grass.

'''~MASK(mask,x,y)'''
* ''mask'': an image file used as mask, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to put the mask. Parts ouside of the mask are considered transparent. If missing assume (0,0).

Only the alpha channel of the mask is used and each alpha value will be the maximum alpha of the resulting image. This means that the fully-transparent parts of the mask will erase the corresponding parts of the image, but also that a semi-transparent mask will create a semi-transparent image.

== Opacity ==

=== ADJUST_ALPHA ===

{{DevFeature1.13|?}}

Alters the alpha of the image according to a WFL formula. The formula must output an integer from 0 to 255 giving the alpha across the canvas. It is evaluated for every pixel and may use the following variables: x, y, red, green, blue, alpha, width, height. {{DevFeature1.15|0}} The variables u and v are also supported now, evaluating to normalized texture coordinates (in the range 0..1); these are equivalent to <tt>x/width</tt> and <tt>y/height</tt> respectively.

'''~ADJUST_ALPHA(formula)'''.

The context object for the formula is a '''[[#CHAN:_General_function|pixel object]]'''.

=== O: Opacity modifying function ===
Changes an image's opacity at render time.

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

=== PLOT_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the color is replaced with a grey-tone reflecting the alpha value at that pixel, and the new image is fully opaque. Useful for plotting the alpha to help debug an IPF or inspect a sprite.

'''~PLOT_ALPHA()'''

=== WIPE_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the alpha value is discarded and the pixel is made fully opaque. Useful again for diagnostics.

'''~WIPE_ALPHA()'''

=== Background coloring function ===
Sets the color of all the (semi-)transparent pixels of the image.

'''~BG(r,g,b)'''

== Miscellaneous ==

=== BL: Blurring function ===

Blurs a graphic at render time using the same algorithm used for in-game dialogs.

'''~BL( ''radius'' )'''

=== CHAN: General function ===

{{DevFeature1.13|7}}

This function allows you to do pretty much anything. It takes up to four comma-separated formulas, one each for the red, green, blue, and alpha channels. Each formula functions exactly the same as the formula for '''ADJUST_ALPHA''', but the output integer is used for the corresponding channel rather than always the alpha channel. Do not surround the formula in <code>$(...)</code>, since that will erase the <tt>self</tt> variable.

'''~CHAN(formula, formula, formula)'''

The context object for each of the formulas is a '''pixel object''' with the following properties:

* '''x''', '''y''': coordinates of the pixel, from the top left
* '''u''', '''v''': {{DevFeature1.15|0}} normalized coordinates in the range [0,1]
* '''width''', '''height''': size of the image canvas
* '''red''', '''green''', '''blue''', '''alpha''': components of the pixel colour

=== NO_TOD_SHIFT: Disabling ToD ===

{{DevFeature1.13|8}}

Can be used on terrain and item images to prevent them from being affected by ToD lighting. This is in particular useful when placing unit images as items, as they will look the same as when placed as unit.

'''~NO_TOD_SHIFT()'''

=== DARKEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-dark.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-dark.png) on the image, which must be large enough to accommodate it.

'''~DARKEN()'''

=== BRIGHTEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-bright.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-bright.png) on the image, which must be large enough to accommodate it.

'''~BRIGHTEN()'''

=== NOP: Null function ===

Does nothing.

'''~NOP()'''

== Creating an image file from IPFs ==

The big advantage of Image Path Functions is that they allow you to alter an image without needing a new image file. However, you can also save the result into a new image file using Wesnoth's command line option ''--render-image'.

Assuming you find a way to open your computer's terminal:
wesnoth --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" /tmp/new_image_file.png

Or on Windows:
"C:\Path\to\Battle for Wesnoth\wesnoth.exe" --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" new_image_file.png

Use cases include:
* Experimenting with Image Path Functions. If none of the images are from an add-on, adding ''--noaddons'' will speed this up.
* If a new Image Path Function is added to the development version of Wesnoth, add-ons for older Wesnoth versions can use a generated image instead.
* In case you want to use this anywhere out of Wesnoth. On a website, in Project Haldric, …
== See Also ==

* [[FancyAddonIcons]] - Tips and tricks for advanced Image Path Function manipulation
* [[DataURI]] - An image path may also contain the image directly, as a Base64 encoded string
* [http://shadowm.ai0867.net/projects/wesnoth-rcx Wesnoth RCX] - Tool to preview unit recoloring. Covers the effects of the [[#RC:_Re-Color_Function|RC]], [[#TC: Team-Color Function|TC]] and [[#PAL:_Palette-switch_Function|PAL]] functions.
[[Category:WML Reference]]

ImagePathFunctions

2022-06-05T07:13:34Z

Mesilliac: ROTATE is not actually limited to 90° increments.

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

If you need to practice it without having to reload all WML, you can use an add-on named ''Image loading tester''. It is available on the 1.9, 1.10, 1.11, 1.12 and 1.14 add-on servers.

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like
"units/elves-wood/fighter.png~CROP(20,20,40,40)~CROP(10,10,10,10)"
would result in taking a crop to a 40x40 rectangle whose top-left corner is x=20, y=20; and then taking a crop from ''that'' rectangle with x=10, y=10, w=10, h=10. The result is the area x=30, y=30, w=10, h=10 from the original graphic.

== Changing the colors ==

=== BLEND: Color-blend function ===
Blends the image with the given color to produce a more controlled tinting effect than color-shifting, independently of the image's contents.

'''~BLEND(r,g,b,o)'''

The color is defined by the ''r'', ''g'', and ''b'' parameters (integers ranging from 0 to 255). The ''o'' (opacity) parameter controls the amount by which the given color will be blended into the image, and may be specified either as a factor from 0.0 to 1.0, or percentage up to 100%. Thus, ~BLEND(r,g,b,0.5) and ~BLEND(r,g,b,50%) are equivalent.

=== BW: Black and White function ===
{{devfeature1.13|1}}
May be used to convert the image to pure black and white, without grey pixels.

'''~BW(threshold)'''
* ''threshold'': a value between 0 and 255 (both limits included). All pixels are converted as greyscale first, and if their average value is greater than the threshold they become white, otherwise they become black.

=== CS: Color-shift function ===
Performs simple per-channel color shifts by adding the arguments to the respective color channels.

''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

=== GS: Greyscale function ===
May be used to greyscale the image (turn to black and white)

'''~GS( )'''

=== L: Lightmap color-shift function ===
Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully grey image (RGB = 128,128,128) and any non-grey pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

=== NEG: Negative function ===
{{devfeature1.13|0}}
Also known as ''invert'', it negates all the RGB values of the image, giving it an effect similar to a photographic negative.

'''~NEG( )'''

Inverts the image, giving it an effect like a photographic negative.

{{devfeature1.13|1}} '''~NEG(''' ''threshold'' ''')'''

If a channel has a value greater than the threshold, the channel will be inverted, performing an effect known as ''solarization''.
Threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

{{devfeature1.13|1}} '''~NEG(''' ''threshold_red, threshold_green, threshold_blue'' ''')'''

If a channel has a value greater than the corresponding threshold, the channel will be inverted.
Each threshold must be between -1 and 255, with -1 equivalent to full inversion and 255 as no-op value.

=== PAL: Palette-switch function ===
May be used to change colors in an image following the specifications of a source and target (new) palette.

'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

=== RC: Re-Color function ===
May be used to change some colors in an image. It is possible to use ''RC'' more than once on the same image, with different source palettes.

'''~RC(''' ''source color palette'' '''>''' ''destination color range'' ''')'''

==== source color palette ====
The first parameter is a set of colors, usually the magenta palette. Do not surround this parameter with quotes. The three standard palettes are:

* '''magenta''' - the 19 colors described in [[Team_Color_Shifting]]
* '''ellipse_red''' - all 255 colors with RGB value (n,0,0)
* '''flag_green''' - all 255 colors with RGB value (0,n,0)

The palette can also be given inline as a set of hexadecimal RGB values.

The named palettes are defined using the '''[[GameConfigWML#Color_Palettes|[color_palette]]]''' tag, and you can also define your own custom color palette using that tag.

Warning: the RC function will also accept (and not give a warning about) '''red''', '''green''' and any other defined '''[color_range]'''; however the set of RGB values for those aren't guaranteed. Using '''red''' instead of '''ellipse_red''' might be equivalent to the palette 030000,060000,0a0000,...,ff0000,ff0a0a,...,fff0f0.

==== destination color range ====
This is the second parameter, signifying the ID of a color range defined in the file [http://github.com/wesnoth/wesnoth/blob/master/data/core/team-colors.cfg data/core/team-colors.cfg] (or it may be a custom ID for a color range defined locally). You can also define a custom color range inline (the rgb key from [[GameConfigWML#Color_Palettes]]; note that RC does not use the fourth color for anything).

For this destination color range, using '''red''' or '''green''' makes sense.

==== Example ====
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The following example replaces a few of the '''magenta''' pixels with green ones:

misc/orb.png~RC(690039,c30074,ec008c > 007f00,00ff00,000000,000000)

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

=== SEPIA: Sepia function ===
{{devfeature1.13|0}}
May be used to give to the image a sepia tint (like in old pictures).

'''~SEPIA()'''

=== SWAP: Channel Swap function ===
{{devfeature1.13|1}}
May be used to swap the RGBA channels of an image.

'''~SWAP(''' ''r, g, b'' ''')'''
'''~SWAP(''' ''r, g, b, a'' ''')'''
* ''r'', ''g'', ''b'', ''a'': each of these arguments may have a value equal to ''red'', ''green'', ''blue'' or ''alpha''. The RGBA channels of the original image will be exchanged accordingly (for example, <tt>~SWAP(blue,green,red)</tt> swaps the blue and red channels).

=== TC: Team-Color function ===
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Transformations ==

=== FL: Flip function ===
May be used to flip an image horizontally and/or vertically.

'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizontally.
*if the argument list is empty, the image will only be flipped horizontally.

=== ROTATE: Rotate function ===
May be used to rotate an image.

'''~ROTATE(''' ''degrees'' ''')'''
* ''degrees'' - The number of degrees by which the image will be rotated. Positive numbers indicate clockwise rotation, while negative numbers indicate counter-clockwise. (Zero indicates no rotation.)
If the number of degrees is omitted, a quarter turn (90 degrees) clockwise is assumed.

=== SCALE: Image-scaling function ===
Scales a graphic up or down.

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr. This uses the bilinear interpolation algorithm.

=== SCALE_INTO function ===
{{DevFeature1.13|5}}

Similar to SCALE, but preserves aspect aspect ratio, scaling to the minimum extent required to fit into the specified area. The resulting image will have the specified width or the specified height, but not necessarily both.

=== SCALE_SHARP function ===

{{DevFeature1.13|0}}

Scales functions using a nearest neighbor algorithm. Specify width and height. (It has the same syntax as ~SCALE.)

'''~SCALE_SHARP(200,300)'''

=== SCALE_INTO_SHARP function ===
{{DevFeature1.13|5}}

Like SCALE_INTO, but uses nearest neighbor algorithm instead of bilinear interpolation.

=== XBRZ function ===

{{DevFeature1.13|0}}

Scales functions using the XBRZ algorithm. You may scale things up either 2x, 3x, 4x, or 5x. The scaling tries to preserve the pixel art nature.

'''~XBRZ(n)'''

== Cut-and-paste ==

=== BLIT: Blit function ===
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)

'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

=== CROP: Crop function ===
Extracts a rectangular section of an image file.

'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width, and must not be negative.
* ''height'': height of the selected region. Must be less than or equal to the original image's height, and must not be negative.

=== MASK: Mask function ===
Remove parts of the main image using the parameter image as a mask. Example: grass.png~MASK(circle.png) will give a circle of grass.

'''~MASK(mask,x,y)'''
* ''mask'': an image file used as mask, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to put the mask. Parts ouside of the mask are considered transparent. If missing assume (0,0).

Only the alpha channel of the mask is used and each alpha value will be the maximum alpha of the resulting image. This means that the fully-transparent parts of the mask will erase the corresponding parts of the image, but also that a semi-transparent mask will create a semi-transparent image.

== Opacity ==

=== ADJUST_ALPHA ===

{{DevFeature1.13|?}}

Alters the alpha of the image according to a WFL formula. The formula must output an integer from 0 to 255 giving the alpha across the canvas. It is evaluated for every pixel and may use the following variables: x, y, red, green, blue, alpha, width, height. {{DevFeature1.15|0}} The variables u and v are also supported now, evaluating to normalized texture coordinates (in the range 0..1); these are equivalent to <tt>x/width</tt> and <tt>y/height</tt> respectively.

'''~ADJUST_ALPHA(formula)'''.

The context object for the formula is a '''[[#CHAN:_General_function|pixel object]]'''.

=== O: Opacity modifying function ===
Changes an image's opacity at render time.

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

=== PLOT_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the color is replaced with a grey-tone reflecting the alpha value at that pixel, and the new image is fully opaque. Useful for plotting the alpha to help debug an IPF or inspect a sprite.

'''~PLOT_ALPHA()'''

=== WIPE_ALPHA ===

{{DevFeature1.13|0}}

At each pixel, the alpha value is discarded and the pixel is made fully opaque. Useful again for diagnostics.

'''~WIPE_ALPHA()'''

=== Background coloring function ===
Sets the color of all the (semi-)transparent pixels of the image.

'''~BG(r,g,b)'''

== Miscellaneous ==

=== BL: Blurring function ===

Blurs a graphic at render time using the same algorithm used for in-game dialogs.

'''~BL( ''radius'' )'''

=== CHAN: General function ===

{{DevFeature1.13|7}}

This function allows you to do pretty much anything. It takes up to four comma-separated formulas, one each for the red, green, blue, and alpha channels. Each formula functions exactly the same as the formula for '''ADJUST_ALPHA''', but the output integer is used for the corresponding channel rather than always the alpha channel. Do not surround the formula in <code>$(...)</code>, since that will erase the <tt>self</tt> variable.

'''~CHAN(formula, formula, formula)'''

The context object for each of the formulas is a '''pixel object''' with the following properties:

* '''x''', '''y''': coordinates of the pixel, from the top left
* '''u''', '''v''': {{DevFeature1.15|0}} normalized coordinates in the range [0,1]
* '''width''', '''height''': size of the image canvas
* '''red''', '''green''', '''blue''', '''alpha''': components of the pixel colour

=== NO_TOD_SHIFT: Disabling ToD ===

{{DevFeature1.13|8}}

Can be used on terrain and item images to prevent them from being affected by ToD lighting. This is in particular useful when placing unit images as items, as they will look the same as when placed as unit.

'''~NO_TOD_SHIFT()'''

=== DARKEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-dark.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-dark.png) on the image, which must be large enough to accommodate it.

'''~DARKEN()'''

=== BRIGHTEN: Removed function ===

{{DevFeature1.13|7}} This function has been removed. Use a ~BLIT(misc/tod-bright.png) call instead.

Puts a time-of-day schedule overlay (misc/tod-bright.png) on the image, which must be large enough to accommodate it.

'''~BRIGHTEN()'''

=== NOP: Null function ===

Does nothing.

'''~NOP()'''

== Creating an image file from IPFs ==

The big advantage of Image Path Functions is that they allow you to alter an image without needing a new image file. However, you can also save the result into a new image file using Wesnoth's command line option ''--render-image'.

Assuming you find a way to open your computer's terminal:
wesnoth --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" /tmp/new_image_file.png

Or on Windows:
"C:\Path\to\Battle for Wesnoth\wesnoth.exe" --render-image "units/human-peasants/ruffian.png~RC(magenta>green)~BLIT(units/human-peasants/woodsman.png~RC(magenta>lightblue),18,12)" new_image_file.png

Use cases include:
* Experimenting with Image Path Functions. If none of the images are from an add-on, adding ''--noaddons'' will speed this up.
* If a new Image Path Function is added to the development version of Wesnoth, add-ons for older Wesnoth versions can use a generated image instead.
* In case you want to use this anywhere out of Wesnoth. On a website, in Project Haldric, …
== See Also ==

* [[FancyAddonIcons]] - Tips and tricks for advanced Image Path Function manipulation
* [[DataURI]] - An image path may also contain the image directly, as a Base64 encoded string
* [http://shadowm.ai0867.net/projects/wesnoth-rcx Wesnoth RCX] - Tool to preview unit recoloring. Covers the effects of the [[#RC:_Re-Color_Function|RC]], [[#TC: Team-Color Function|TC]] and [[#PAL:_Palette-switch_Function|PAL]] functions.
[[Category:WML Reference]]

User:Mesilliac

2008-04-06T01:11:23Z

Mesilliac: /* Terrain WML Cleanup Proposal */

a.k.a. Yobbo

= Terrain WML Cleanup Proposal =

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. I think Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

== Terrain Macros ==

=== Current system ===

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

=== Proposed change ===

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

=== Benefits ===

* Easier to maintain, as macros are separated from terrain declarations
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

=== Drawbacks ===

none

== Randomly chosen images ==

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
{TERRAIN_BASE_PROB Uu cave/floor2 20}
{TERRAIN_BASE_PROB Uu cave/floor3 25}
{TERRAIN_BASE_PROB Uu cave/floor4 33}
{TERRAIN_BASE_PROB Uu cave/floor5 50}
{TERRAIN_BASE Uu cave/floor6}
This gives an equal probability of each listed variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

=== Current system ===

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

=== Proposed change ===

In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.

=== Benefits ===

* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

=== Drawbacks ===

Checks for the existance of many nonexistant images

== Standard set of terrain graphics macros ==

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

=== Current system ===

Macros are added as necessary.

=== Proposed change ===

The addition of a set of standard macros for common terrain types:

; Base Terrain
: Normal single-hex flat terrain.
:; Examples in current terrain: dirt, water, grass, sand
:; Defining features:
::* Generic transitions are used if present.
::* Variations are used if present.
::* Only one base terrain can be used per tile
::* Only one base transition can be drawn for each edge of the tile
::* Image dimensions are 72x72
:; Macro arguments: Terrain_identifier, Dissimilar_terrains, base_image_name, layer
:; Basic image set: 1 base image, 6 transitions

All terrain types should specify a base terrain.

; Single-Hex Overlay
: Terrain used as an overlay for a single hex
:; Examples in current terrain: forest, mushroom grove with lightbeam (double overlay)
:; Defining features:
::* Transitions are not used
::* Variations are used if present
::* A "-small" variation should be provided for use next to terrains to avoid overlapping, for example castles, cavewall
::* Image dimensions are 180x252
:; Macro arguments: Overlay_identifier, base_overlay_image_name, layer
:; Basic image set: 1 base overlay, 1 small overlay

; Fence
: Draws walls along edges of a terrain
:; Examples in current terrain: castle, keep, cavewall
:; Defining features:
::* Variations are used if present
::* Only one fence image can be drawn for each point where 3 tiles meet
:; Macro arguments: terrain_identifier, base_fence_image_name
:; Basic image set: 6 concave corners, 6 convex corners

; Path
: Directional terrain, that only makes sense in lines. Joins to certain terrain types.
:; Examples in current terrain: bridge
:; Defining features:
::* Not required to make sense in clumps
::* Only transitions to certain terrain types are used
::* Variations are used if present
::* image dimensions are 180x252
:; Macro arguments: bridge_identifier, joiner_terrain_identifier bridge_overlay_image_name, layer
:; Basic image set: 1 lone image, 6 end images, 3 across images, 6 bend images

FrankenPacks

2008-04-04T04:51:50Z

Mesilliac: added an image showing simple frankenpack

{| style="float:right"
|
__TOC__
|}

"Frankenpacks" are images containing pieces of wesnoth sprites. These pieces can be copied and pasted together to quickly make new custom sprites. The Wesnoth community calls this process "frankensteining", and it's a common way to begin spriting, requiring little previous art experience. Frankensteined sprites '''will not be accepted into mainline''', but are perfectly acceptable for use in [[WesnothAcronyms|UMC]].

== Elves ==

== Orcs ==

* http://forum.wesnoth.org/download/file.php?id=15808 orcs, goblins and trolls

== Humans ==
{| style="float:right"
|
http://exong.net/wesnoth-attach/files/lieutenant_chopped_204.png
|}

* http://forum.wesnoth.org/download/file.php?id=12868 humans
* http://forum.wesnoth.org/download/file.php?id=15699 more humans

== Dwarves ==

* http://forum.wesnoth.org/download/file.php?id=15794 dwarves and gryphons

== Undead ==

* http://forum.wesnoth.org/download/file.php?id=15789 undead

== Drakes ==

== Other ==

* http://forum.wesnoth.org/download/file.php?id=15809 nagas, mermen, saurians, ogres, yeti
* http://forum.wesnoth.org/download/file.php?id=13391 animals

== Misc ==

* http://forum.wesnoth.org/download/file.php?id=15790 mega-pack with loads of stuff, including animals

[[Category: Art Tutorials]]

Create Art

2008-04-04T04:35:27Z

Mesilliac: /* Sprite Art */ add link to new FrankePacks page

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==

=== General Information ===

Graphic artists usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=9 artwork development forum] or on the [http://www.wesnoth.org/forum/viewforum.php?f=18 restricted art development forum]. The former is a great place to post and discuss new and current Wesnoth art and graphics, and the latter to see what the art development team is working on.

Unit and terrain art is stored in the portable network graphics (PNG) format. Each frame of a unit animation, and each variation of a terrain is stored as a separate .png file in the "images" subdirectory of wesnoth, and generally these files will be 72 x 72 pixels (the size of Wesnoth's basic hexagonal tile) with an alpha channel (a part of the file that indicates how transparent each pixel is). When creating your own images, you can test them without overwriting any game data by putting them in your userdata directory (see [[EditingWesnoth]] for details on Wesnoth's directory structure). The game also supports JPEG images, though these are better suited for story art.

To edit these graphics, you'll need some program capable of creating PNGs - some of the programs in the following list are free, open-source software, and will do the job nicely: [[Art Programs]]

If you need some inspiration, we have a [[GraphicLibrary|Graphics Library]] which collects art posted on the forum. You can use this for ideas, and as a scrap heap for different parts of unit images (a technique described [[Give Your Hero A Personality|here]]).

=== Roadmap ===
A list of what's being done and what needs doing:
* '''[[Tiles Status]]''' - a roadmap/plan of sorts for future work on terrain tiles
* [http://www.wesnoth.org/forum/viewtopic.php?t=9162&sid=21cf168d2b077d06bb0017c059b4add6 A list] of current work that needs to be done with sprites.

== Art Tutorials ==

These are a work-in-progress, and describe both how to make art fit into wesnoth's style, as well as giving some considerable tips on drawing in general. Especially useful is the [[External Tutorials]] page which lists a large number of art tutorials available on the web.

=== General Art and Computer Graphics ===
* [[Using the Levels Adjustment]] - making scanned pencil drawings ''not'' look washed out.
* [[Extending dynamic range]] - The Grooviest (so far) tutorial about extending the dynamic range of images and how this technique can be used to make better scans of pencil drawings.
* [[Scanning with camera]] - How to transfer real-life art to computer using a digital camera instead of a scanner.
* [[How to Anti-Alias Sprite Art]] - A means of removing the jagged edges on pixel lines
* [[Art Supplies]] - What physical items you need to do larger cell-shaded art like that of Jetryl/Jormungadr/et al
* [[Inking With Pencils|Computer Inking a Sketch]] - Info from Jason Lutes on his portrait workflow
* [[Scaling Digital Images]] - how to properly resize an image on a computer
* [[How to Shade]] - at attempt at tackling a very complicated topic
* [[Cartography for Wesnoth|How to make Wesnoth-style Maps ]] - Kestenvarn's tricks of the trade
* [[Designing weapons and armour]] - Advice from zookeeper on designing realistic weapons for your characters
* Sgt. Groovy's vector workshop - tips and tricks for drawing with Inkscape
** [[Z-order tricks]] - few methods for faking overlapping shapes
** [[Variable-width strokes]] - how to make the strokes vary in width, like being drawn with a flat-tipped pen — no tablet needed!
** [[Shaped gradients with Gaussian blur]] - how to make gradients in other shapes than linear or radial
** [[Smooth shading in vector]] - the basic vector techniques for smooth shading, employing Gaussian blur and clipping/masking
** [[Making portrait art in vector]] - a complete tutorial for making Wesnoth unit portraits in vector graphics.

=== [[Terrain|Terrain Graphics]] ===

The following is information specific to drawing terrain for Wesnoth. Read Frame's "Tiles Tutorial" for a good overview of how terrain graphics work.

* [[Tiles Tutorial]] - Frame's tutorial describing the process of making terrain tiles in wesnoth, and how they interact with adjacent tiles.
* [[How To Make Seamless Tiles]] - The tutorial is aimed at Photoshop users, but the technique is similar with The GIMP.
* [[Seamless Tiles Using Inkscape]] - This tutorial teaches a method for making seamless hex tiles in vector craphics (to be rendered in raster).
* [[Turning Square Tiles into Hex]] - Nifty tricks for transforming square (or any rectangle) shaped seamless tiles into hexagon seamless tiles.
* [[CastleTutorial|Castle Tutorial]] - A description of how Wesnoth's castle tiles work (needs updating, but useful nonetheless)
* [[MultiHexTutorial|Multi-Hex Tiling Tutorial]] - A description of how multi-hex tiles work.
* [[Editing Castles]] - Instructions for how to make/edit castles (and other corner-based terrains) using yobbo's GIMP script.

These describe the system used to specify how terrains behave in game:
* [[TerrainCodesWML]] - A list of the letters used to represent terrain types.
* [[TerrainGraphicsWML]] - If you really need to get technical, start here.
* [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml Ayin's Terrain Graphics document] - If you really, ''really'' need to get technical, this describes the terrain graphics WML system in depth.

=== Sprite Art ===
The following are different tutorials about sprite work compiled by various wesnoth sprite artists. These will give you the most specific-to-wesnoth information about making sprites, and are well worth a read.

* [[Creating Unit Art]] - a list of specifications you will need to match.
* [[Give Your Hero A Personality]] - tricks for editing existing images, including some clip art.
* [[Basic Animation Tutorial]] - or "How to Animate Sprites for Dummies," covering the basic theory, and all of the mistakes to avoid.
* [[Advanced Animation Tutorial]] - how to wire in the animation frames to units in a way that makes the animation look good in-game. Doesn't cover any drawing as such, but focuses on timing conventions and some standard techniques for getting as much as possible out of the frames that are already drawn.
* [[Team Color Shifting]] - how to use our new team color system.
* [[Creating Shadows Under Units]] - how we create the shadows for the units in-game
* [[Making Bow Animations]] - the current standard for how we want bow animations to work
* [[Rotate Pixel Art Without Blurring]]
* [[Creating a scratch built sprite]] - an attempt to show some ways creating a sprite from scratch
* [[How to create motion blurs]] - a simple explanation on how to create attack animation weapon blurs
* [[FrankenPacks]] - a quick and dirty way to create sprites for [[WesnothAcronyms|UMC]]

=== External Tutorials ===
The following page contains dozens of links to tutorials covering all manner of artwork, including sprite art. These were not made by wesnoth artists, but should prove very useful for general instruction.

* [[External Tutorials]]

== See Also ==
* [[Create]]
* [[EditingWesnoth]]
* [[GraphicLibrary]] - Lots of usercontributed graphics (most should be GPL'ed)
* [[Project]]
* [http://wesnoth.dbzer0.com/blog/wpg2 External Graphic Library] - A project to better organize the art of Wesnoth.

[[Category:Art Tutorials]]

FrankenPacks

2008-04-04T04:31:44Z

Mesilliac: float the accursed TOC

{| style="float:right"
|
__TOC__
|}

"Frankenpacks" are images containing pieces of wesnoth sprites. These pieces can be copied and pasted together to quickly make new custom sprites. The Wesnoth community calls this process "frankensteining", and it's a common way to begin spriting, requiring little previous art experience. Frankensteined sprites '''will not be accepted into mainline''', but are perfectly acceptable for use in [[WesnothAcronyms|UMC]].

== Elves ==

== Orcs ==

* http://forum.wesnoth.org/download/file.php?id=15808 orcs, goblins and trolls

== Humans ==

* http://forum.wesnoth.org/download/file.php?id=12868 humans
* http://forum.wesnoth.org/download/file.php?id=15699 more humans

== Dwarves ==

* http://forum.wesnoth.org/download/file.php?id=15794 dwarves and gryphons

== Undead ==

* http://forum.wesnoth.org/download/file.php?id=15789 undead

== Drakes ==

== Other ==

* http://forum.wesnoth.org/download/file.php?id=15809 nagas, mermen, saurians, ogres, yeti
* http://forum.wesnoth.org/download/file.php?id=13391 animals

== Misc ==

* http://forum.wesnoth.org/download/file.php?id=15790 mega-pack with loads of stuff, including animals

[[Category: Art Tutorials]]

FrankenPacks

2008-04-04T04:28:57Z

Mesilliac: add a cople packs I missed

"Frankenpacks" are images containing pieces of wesnoth sprites. These pieces can be copied and pasted together to quickly make new custom sprites. The Wesnoth community calls this process "frankensteining", and it's a common way to begin spriting, requiring little previous art experience. Frankensteined sprites '''will not be accepted into mainline''', but are perfectly acceptable for use in [[WesnothAcronyms|UMC]].

== Elves ==

== Orcs ==

* http://forum.wesnoth.org/download/file.php?id=15808 orcs, goblins and trolls

== Humans ==

* http://forum.wesnoth.org/download/file.php?id=12868 humans
* http://forum.wesnoth.org/download/file.php?id=15699 more humans

== Dwarves ==

* http://forum.wesnoth.org/download/file.php?id=15794 dwarves and gryphons

== Undead ==

* http://forum.wesnoth.org/download/file.php?id=15789 undead

== Drakes ==

== Other ==

* http://forum.wesnoth.org/download/file.php?id=15809 nagas, mermen, saurians, ogres, yeti
* http://forum.wesnoth.org/download/file.php?id=13391 animals

== Misc ==

* http://forum.wesnoth.org/download/file.php?id=15790 mega-pack with loads of stuff, including animals

[[Category: Art Tutorials]]

FrankenPacks

2008-04-04T04:23:30Z

Mesilliac: page to link frankenpacks available for newbie spriters

"Frankenpacks" are images containing pieces of wesnoth sprites. These pieces can be copied and pasted together to quickly make new custom sprites. The Wesnoth community calls this process "frankensteining", and it's a common way to begin spriting, requiring little previous art experience. Frankensteined sprites '''will not be accepted into mainline''', but are perfectly acceptable for use in [[WesnothAcronyms|UMC]].

== Elves ==

== Orcs ==

* http://forum.wesnoth.org/download/file.php?id=15808 orcs, goblins and trolls

== Humans ==

* http://forum.wesnoth.org/download/file.php?id=12868

== Dwarves ==

* http://forum.wesnoth.org/download/file.php?id=15794 dwarves and gryphons

== Drakes ==

== Other ==

* http://forum.wesnoth.org/download/file.php?id=15809 nagas, mermen, saurians, ogres, yeti
* http://forum.wesnoth.org/download/file.php?id=13391 animals

== Misc ==

* http://forum.wesnoth.org/download/file.php?id=15790 mega-pack with loads of stuff, including animals

[[Category: Art Tutorials]]

Create Music

2008-03-25T07:35:56Z

Mesilliac: /* General Information */ oops

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on. If you have an IRC client, you can also join the [irc://irc.freenode.net/wesnoth-music #wesnoth-music] channel on irc.freenode.net, and chat with us about anything to do with music and/or Wesnoth.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "data/core/music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] and [[Wesnoth:Copyrights]] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]] - read this first!
* [[Tools for Creating Music]] details some of the hardware and software you will need to create music for Wesnoth.
* [[Music Tutorials]] provides some links to useful tutorials and general advice on creating quality music in the style that Wesnoth's music development team requires.

== Adding music to a Scenario or Campaign ==

* [[Available Music]] lists all the pieces which are already available to use in scenarios and campaigns, as well as providing some links to works in progress.
* [[MusicListWML]] has information on using the [music] WML tag to add music to a Wesnoth scenario.

[[Category:Create]]
[[Category:Music]]

Create Music

2008-03-25T07:35:04Z

Mesilliac: /* General Information */ added link to #wesnoth-music

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on. If you have an IRC client, you can also join the [irc://irc.freenode.net/wesnoth-mp #wesnoth-music] channel on irc.freenode.net, and chat with us about anything to do with music and/or Wesnoth.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "data/core/music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] and [[Wesnoth:Copyrights]] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]] - read this first!
* [[Tools for Creating Music]] details some of the hardware and software you will need to create music for Wesnoth.
* [[Music Tutorials]] provides some links to useful tutorials and general advice on creating quality music in the style that Wesnoth's music development team requires.

== Adding music to a Scenario or Campaign ==

* [[Available Music]] lists all the pieces which are already available to use in scenarios and campaigns, as well as providing some links to works in progress.
* [[MusicListWML]] has information on using the [music] WML tag to add music to a Wesnoth scenario.

[[Category:Create]]
[[Category:Music]]

Available Music

2008-03-22T02:27:10Z

Mesilliac: /* Available Music for Campaign Authors */ +track times

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost ([http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.ogg ogg])

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg ([http://download.tuxfamily.org/wesnothmusic/extras/reminisce.ogg mirror])

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2 ([http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.ogg ogg])

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.ogg ogg])

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3 4'01" ([http://download.tuxfamily.org/wesnothmusic/extras/DragonVert1.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/DragonVert1.ogg ogg])
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3 2'57" ([http://download.tuxfamily.org/wesnothmusic/extras/DragonVert2.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/DragonVert2.ogg ogg])

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/41165228/3f6c6fd2/sinf1_up2.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-03-22T02:24:38Z

Mesilliac: /* Available Music for Campaign Authors */ +mirrors

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost ([http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.ogg ogg])

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg ([http://download.tuxfamily.org/wesnothmusic/extras/reminisce.ogg mirror])

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2 ([http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.ogg ogg])

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.ogg ogg])

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/DragonVert1.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/DragonVert1.ogg ogg])
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/DragonVert2.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/DragonVert2.ogg ogg])

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/41165228/3f6c6fd2/sinf1_up2.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-03-22T02:20:44Z

Mesilliac: move jeanbrut contribs from other -> available

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost ([http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.ogg ogg])

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg ([http://download.tuxfamily.org/wesnothmusic/extras/reminisce.ogg mirror])

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2 ([http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.ogg ogg])

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.ogg ogg])

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/41165228/3f6c6fd2/sinf1_up2.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-03-22T02:17:56Z

Mesilliac: /* Works in Progress */ update to marcus's track

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost ([http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.ogg ogg])

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg ([http://download.tuxfamily.org/wesnothmusic/extras/reminisce.ogg mirror])

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2 ([http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.ogg ogg])

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.ogg ogg])

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/41165228/3f6c6fd2/sinf1_up2.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-03-22T02:15:19Z

Mesilliac: /* Available Music for Campaign Authors */ mirrored some non-core tracks, and added .ogg versions

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost ([http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/lzce-Burin%20the%20Lost.ogg ogg])

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg ([http://download.tuxfamily.org/wesnothmusic/extras/reminisce.ogg mirror])

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2 ([http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/doug_kaufman-music%20score.ogg ogg])

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3 ([http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.mp3 mirror] | [http://download.tuxfamily.org/wesnothmusic/extras/tribal_war_song.ogg ogg])

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Project

2008-03-20T00:09:34Z

Mesilliac: /* Developers */ add link to PatchSubmissionGuidelines

The Battle for Wesnoth is a [http://gna.org/projects/wesnoth/ Gna! project]. See also the [http://freshmeat.net/projects/wesnoth/ project] and [http://freshmeat.net/project-stats/view/38720/ stats] at [http://www.freshmeat.net/ freshmeat].

There are also Wesnoth pages in other languages:
French ([http://tournoiswesnoth.frbb.net/ 1], [http://wesnothfr.ww7.be/ 2]),
[http://wesnoth.fw.hu/ Hungarian],
[http://wikiwiki.jp/wesnoth/ Japanese],
[http://perso.wanadoo.es/wesnoth/ Spanish],
[http://www.wesnoth.cn Chinese].

== Artists ==
Graphic artists and musicians usually meet on the [http://www.wesnoth.org/forum/ forum].
* [http://www.wesnoth.org/forum/viewforum.php?f=9 Artwork development forum]
* [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

== Developers ==
Coders can help fixing [http://bugs.wesnoth.org bugs], adding new features...
* [[CodingStandards]]
* [[PatchSubmissionGuidelines]]
* [[Roadmap]]
* [http://devdocs.wesnoth.org/ Documentation] - generated and uploaded two times every day (05:05 and 17:05 GMT+2).
* [[WesnothSVN]]
* [[DeveloperGuide]]

== Translators ==
* [[WesnothTranslations]]
* [http://gettext.wesnoth.org Statistics]
* [[WesCamp|Translating User made Campaigns (featuring wescamp-i18n)]]

[[Category:Committers]]

PatchSubmissionGuidelines

2008-03-20T00:08:31Z

Mesilliac: initial copy from forums and cleanup

Copied from http://www.wesnoth.org/forum/viewtopic.php?f=10&t=9979

* '''All patches should be submitted at patches.wesnoth.org'''
You can post them here too for discussion, but we need to track what is their status and p.w.o helps a lot

* '''Patches should be generated using "svn diff"'''
SVN provides a cool command to generate diff, I usually run "svn diff >mypatch.patch" to create the patch, and its all nice and ready.
It even records precisely the commit against which it was generated, it makes things really easy for me...

* '''Don't forget to add an entry to the Changelog'''
* '''Add yourself in about.cfg'''
Including your name and/or nick it makes it easier for me.
New contributors should go in the contributor section of the about file

* '''When changing WML, please add a pointer in the wiki to where it should be updated when commited'''

* '''Be patient, sometime I'm not very responsive'''
* '''Don't be suprised if we discuss the patch a lot'''
Thus, you should leave us a way to contact you, either a forum nick, an email adress, or submit with a registered gna account.

* '''The patch should generate no warnings'''
Wesnoth has a large number of warnings enabled, all of them are useful. If your code spits warning, please have a look, and ask yourself why you are doing whatever causes the warning.

* '''When adding a file, don't forget Makefile.am'''
It makes things simpler for me, and is often forgotten.

* '''Sometimes patches are rejected, don't be suprised if it happens'''

== See also ==
* [[HackingWesnoth]]
* [[CodingStandards]]
* [[EasyCoding]]
* [[DeveloperResources]]

[[Category:Committers]]

SummerOfCodeIdeas

2008-03-15T02:47:04Z

Mesilliac: /* Extending the Multiplayer server */ typos

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== I want to be one of your Google Summer of Code students, what should I do... ==

Here is a quick list of things to do to get you started
* Create an account on gna.org
* Create an account on the wesnoth forum
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learnt to know during the selection process
* Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
* Start a wiki page about your idea, add a link on this page
** Fill the questionnaire on this page
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna.

== List of Ideas for the Project (Suggestions from the wesnoth developers) ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[WesnothFormulaAIBranch]]

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done.

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behavior of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviors :'' there are some typical behaviors that are not optimal for winning a force-on-force battle but are needed for storyline reasons, such as: guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviors, and allow easy addition of new behaviors

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the Wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and gameplay patterns used by human players. This will require a lot of interaction with the player community. Our gameplay developers are communicative and can give some good starting points, but a lot of game experience and good interactions with the player community will be essential for doing a good redesign.

==== Milestones and deliverables ====

It is hard to set milestones at this point, but here are some ideas of what could be done:

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behavior they need
* ''Main AI delivery :'' This milestone goal is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behavior library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviors should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behavior desired.

=== Extending the Multiplayer server ===

Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To develop ideas about how our multiplayer interface could evolve to allow it to scale to a much larger community
* And to implement as many of those changes as practical

Some ideas that we had (but that are in no way mandatory):
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? Again, inspired by IRC
* Having some way to find the type of games you are interested in. filtering by:
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not yet convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers
* game matching when players are ranked (poker, bridge...)

The scalability of the design (both in term of number of players, and in term of the possibility for players and developers to extend the concept) will be an important criterion.

Administration/moderation problems and techniques should also be studied.

Interaction with the Add-On server/forum should be explored.

==== Required knowledge and talent ====

* A fair amount of experience with C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and SDL. We can train you in some of the libraries used, but learning all of them would be a big hurdle.
* Experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that.

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinions from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Scenario/Campaign editor ===

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor to make the creative process easier.

==== General description ====

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. What exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose (but see the note on Python below). The main ideas would be for the scenario editor to be:
* cross-platform (at least Linux, OSX, Windows)
* easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even not knowing WML)
* powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
* extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

* Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
* Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
* GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
* Decide on base features. [[ReferenceWML]] lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
** WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
** Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
** Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
** Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
** Story screen editor for campaigns?
** How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
** Custom unit animations?
** Custom multi-hex terrains?
* Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
* WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

==== Required knowledge and talent ====
* Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
* Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
* Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
* Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
* Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
* Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

==== Milestones and deliverables ====
The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:
* Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
* Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
* Finish design. Should list the intended features and demonstrate how the GUI will work.
* Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
* Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

=== Addon server ===
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

==== General description ====
Neither the server nor the client side of the addon server have
seen much improvement over the years; both are overdue for a reworking.
The client side GUI needs polishing. For the
server side we would like to allow better integration with
various tools (such as wmllint), which improve the quality of the addons.

===== Server side =====
The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.

* The server only needs to run on Linux systems. Cross-platform portability would be nice but isn't required.
* At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
* We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

===== Client side =====
The client side needs improvements. There are two main clients;
one built in to the C++ game binary, and a standalone inmplementation in Python.

* Upgrade the GUI. Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
* Make it easier to see summary and status information on addons. At the moment a lot of new users download something and have no clue what kind of addon it is.
* Make it easier to see whether a newer version of the addon is on the server and update the addon.
* Make it easy to select which translations you want to download and also look for newer versions of the translations.

==== Required knowledge and talent ====
* Knowledge of C++, the game is written in C++ and modifications need to be made there.
* Knowledge of Python, various tools have been written in Python which need to be integrated with the new server.

==== Milestones and deliverables ====
* The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
** Determine the exact feature set.
** Protocol changes needed.
** Methods to integrate with both the WML tools and Wescamp with the new server.
** Determine the GUI for the client side.
** Justify the choice of language.
* These points will need to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Map editor ===
The map editor in Wesnoth serves two goals, making it easy to create
a new map and helping the terrain artists to test their new terrains.

==== General description ====
The current editor hasn't been actively maintained for quite a while and the
quality of the code isn't up to par with the main game. The student
will either revive the current editor or start from scratch, the latter
will probably be easier. When rewriting from scratch the student can
pick the language of his/her liking as long as the result is crossplatform
(at least Linux/Windows/OS X).

(Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)

Some of the things the new/revived editor should be able to do:
* Include all features of the current editor.
* When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
* The editor needs to be able to handle so called ''custom terrain'', these are terrains used in maps but not loaded by default.
* The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
* The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
* Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.

==== Required knowledge and talent ====
* The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
* The student needs to be able to make a user friendly user interface.
* Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.

==== Milestones and deliverables ====
* The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
* From this list the student needs create a sublist of items he/she will be able to do within one summer.
* This needs to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Make your own ideas ===
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.

=== Other ideas to be fleshed out ===
* A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.

== Other info to provide for GSoC ==
==== Describe your organization. ====
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp). David currently works at Google.

The general [http://www.wesnoth.org/wiki/WesnothPhilosophy Philosophy] of the game (both for gameplay and coding) puts an emphasis on simplicity. The core rules are meant to be learnt easily but provide interesting gameplay and diverse strategies.

On the other hand, or Wesnoth Markup Language (WML) provides a simple language to easily customize scenarios, which has lead to a huge modding community providing us with a large amount of content.

The first stable release (1.0) was on October 2 2005, the latest stable release (1.4) was on March 8 2008. 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.

Wesnoth has grown a lot and is now considered one of the largest open source games around.
* two servers (stable and developement) with a usual minimum load of more than a hundred players
* more than two thousands downloads a day
* 2.1 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
* best rated game at the [http://www.happypenguin.org/list?sort=avg_rating linux game tome]
* game of the year 2007 at [http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/open-source-game-of-the-year-610236/ linuxquestions.org]
* One of the top 20 rated projects on [http://freshmeat.net/stats/#rating Freshmeat] (currently 16th highest rating, and the highest rated game).

* A mature project, but with active development and many improvements
* High quality artwork: both graphics and music
* Very well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after five years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing

==== Why is your organization applying to participate in GSoC 2008? 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.

If a student were dedicated to any of these uncovered areas, we believe that person could be brought up to speed relatively quickly and function as a peer of the existing developers.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth project has applied to Google SoC.

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth project has applied to Google SoC.

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything else was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code page is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domains of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev@gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

in particular, all art developement takes place on the forum.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* Basics
** Write a small introduction to yourself.
** State your preferred email address.
** If you have chosen a nick for IRC and Wesnoth forums, what is it?
** Why do you want to participate in summer of code?
** What are you studying, subject, level and school?

* Experience
** What programs/software have you worked on before?
** Have you developed software in a team environment before? (As opposed to hacking on something on your own)
** 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?
** What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
** Open Source
*** Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
** Gaming experience
*** Are you a gamer? If so...
*** What type of gamer are you?
*** What type of games?
*** What type of opponents do you prefer?
*** Are you more interested in story or gameplay?
*** 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.

* Communication skills
** Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
** Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
** Do you give constructive advice?
** Do you receive advice well?
** Are you good at sorting useful criticisms from useless ones?

* Project
** Did you select a project from our list? If that is the case, what project did you select?
** If you have invented your own project, please describe the project and the scope.
** Why did you choose this project?
** Include an estimated timeline for your work on the project
** Include as much technical detail about your implementation as you can
** What do you expect to gain from this project?
** What would make you stay in the Wesnoth community after the conclusion of SOC?

* Practical considerations
** Are you familiar with any of the following tools?
*** Subversion
*** C++
*** Python
** Which tools do you normally use for development? Why do you use them?
** What programming languages are you fluent in?
** What spoken languages are you fluent in?
** At what hours are you awake (please specify in UTC)
** Would you mind talking with your mentor on telephone / internet phone?

* Detailed answer (optional, but writing skill is a good predictor of ability to work on a programming team, so you will improve your chances by responding to this).
** Write a small essay (750-1000 words or more) explaining why you want to participate in a Wesnoth GSoC project. You can use the above questions as guides, but feel free to throw in more information if you feel it is relevant.
** What is your perception of 'open source'? Briefly explain what you think of the whole 'open source' concept, how you discovered open source, what you expect to gain/experience by participating in an open-source project. (Answer separately or as part of above mini-essay)
** What motivates or inspires you to write programs and develop software?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====
David White (davewx7@gmail.com)

==== Who will your mentors be? Please include Google Account information.====

David White (davewx7@gmail.com)

Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)

Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)

Jörg Hinrichs alias YogiHH (joerghh.hinrichs|ATTT|googlemail.com)

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

Our first criterion was that all the people had to be volunteers. According to other open source projects, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Dave is the project leader and one of the most knowledgeable in C++. He has also written the Formula AI code which we plan to develop via the SoC. He is well known in our community for formulating simple but effective explanations for complicated topics, and has good design intuition. The growth of Wesnoth demonstrates his capacity to get other developers to work together and keep them involved in a thriving community.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the [http://wiki.wesnoth.org/UnsortedContrib Art Contribution] section of the wiki (now automated) and the [http://wiki.wesnoth.org/ReferenceWML WML Reference Manual]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org and has created the new developer process we currently use.

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 polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base.

YogiHH has been with the project for more than two years. He did a major refactoring to the gameplay engine and worked quite a bit on the multiplayer code. He also has been a professional trainer for C/C++, Java and C# for many years. Right now he works in a project where he serves as a mentor for a junior developer.

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 for which regards. 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 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.

==== What is your plan for dealing with disappearing students?====
The first thing to do is to avoid this situation altogether.

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 sensible about criticism and our community is used to people being sensible to critics.

We will 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, his mentor will be in charge of recontacting him 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 defuse the problem.

If a student disappears completely and there is no way to get back to him, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN 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 took the time to ask other former GSoC projects about the workload needed to be a mentor, and our mentors accepted the job knowing the amount of work it involved.

However, should it happen, we would continue to mentor as a developper 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, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, 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 (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles 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 maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

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 be rough at time.

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

Since our community has a history of having developers easily and quickly join, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).

Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part.

== People to bug on IRC ==
Everybody feel free to edit/correct his entry!

=== 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.

=== Elias Pscherning (elias) ===
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.

=== 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.

=== Karol Nowak (grzywacz) ===
Last year he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on embedded devices, and is actively working on the gp2x support.

=== 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. Given that Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as already being our area expert for the terrain engine.

=== 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; just don't ask him about revising the level of randomness in the game.

=== Noyga ===
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.

=== 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.

=== YogiHH or Piotr Cychowski (cycholka) ===
Since they are the two developers who know most about building under Windows, they 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.

=== zookeeper or 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.

[[Category:Future]]

SummerOfCodeIdeas

2008-03-15T02:45:39Z

Mesilliac: /* Required knowledge and talent */ type

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== I want to be one of your Google Summer of Code students, what should I do... ==

Here is a quick list of things to do to get you started
* Create an account on gna.org
* Create an account on the wesnoth forum
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learnt to know during the selection process
* Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
* Start a wiki page about your idea, add a link on this page
** Fill the questionnaire on this page
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna.

== List of Ideas for the Project (Suggestions from the wesnoth developers) ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[WesnothFormulaAIBranch]]

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done.

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behavior of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviors :'' there are some typical behaviors that are not optimal for winning a force-on-force battle but are needed for storyline reasons, such as: guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviors, and allow easy addition of new behaviors

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the Wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and gameplay patterns used by human players. This will require a lot of interaction with the player community. Our gameplay developers are communicative and can give some good starting points, but a lot of game experience and good interactions with the player community will be essential for doing a good redesign.

==== Milestones and deliverables ====

It is hard to set milestones at this point, but here are some ideas of what could be done:

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behavior they need
* ''Main AI delivery :'' This milestone goal is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behavior library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviors should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behavior desired.

=== Extending the Multiplayer server ===

Our multiplayer community is generally strong and healthy,but we believe its growth is limited by some problems in the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To develop ifeas about how our multiplayer interface could evolve to allow it to scale to a much larger community
* And to implement as many of those changes as practical

Some ideas that we had (but that are in no way mandatory):
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? Again, inspired by IRC
* Having some way to find the type of games you are interested in. filtering by:
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not yet convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers
* game matching when players are ranked (poker, bridge...)

The scalability of the design (both in term of number of players, and in term of the possibility for players and developers to extend the concept) will be an important criterion.

Administration/moderation problems and techniques should also be studied.

Interaction with the Add-On server/forum should be explored.

==== Required knowledge and talent ====

* A fair amount of experience with C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and SDL. We can train you in some of the libraries used, but learning all of them would be a big hurdle.
* Experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that.

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Scenario/Campaign editor ===

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor to make the creative process easier.

==== General description ====

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. What exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose (but see the note on Python below). The main ideas would be for the scenario editor to be:
* cross-platform (at least Linux, OSX, Windows)
* easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even not knowing WML)
* powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
* extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

* Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
* Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
* GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
* Decide on base features. [[ReferenceWML]] lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
** WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
** Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
** Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
** Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
** Story screen editor for campaigns?
** How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
** Custom unit animations?
** Custom multi-hex terrains?
* Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
* WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

==== Required knowledge and talent ====
* Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
* Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
* Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
* Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
* Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
* Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

==== Milestones and deliverables ====
The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:
* Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
* Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
* Finish design. Should list the intended features and demonstrate how the GUI will work.
* Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
* Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

=== Addon server ===
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

==== General description ====
Neither the server nor the client side of the addon server have
seen much improvement over the years; both are overdue for a reworking.
The client side GUI needs polishing. For the
server side we would like to allow better integration with
various tools (such as wmllint), which improve the quality of the addons.

===== Server side =====
The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.

* The server only needs to run on Linux systems. Cross-platform portability would be nice but isn't required.
* At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
* We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

===== Client side =====
The client side needs improvements. There are two main clients;
one built in to the C++ game binary, and a standalone inmplementation in Python.

* Upgrade the GUI. Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
* Make it easier to see summary and status information on addons. At the moment a lot of new users download something and have no clue what kind of addon it is.
* Make it easier to see whether a newer version of the addon is on the server and update the addon.
* Make it easy to select which translations you want to download and also look for newer versions of the translations.

==== Required knowledge and talent ====
* Knowledge of C++, the game is written in C++ and modifications need to be made there.
* Knowledge of Python, various tools have been written in Python which need to be integrated with the new server.

==== Milestones and deliverables ====
* The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
** Determine the exact feature set.
** Protocol changes needed.
** Methods to integrate with both the WML tools and Wescamp with the new server.
** Determine the GUI for the client side.
** Justify the choice of language.
* These points will need to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Map editor ===
The map editor in Wesnoth serves two goals, making it easy to create
a new map and helping the terrain artists to test their new terrains.

==== General description ====
The current editor hasn't been actively maintained for quite a while and the
quality of the code isn't up to par with the main game. The student
will either revive the current editor or start from scratch, the latter
will probably be easier. When rewriting from scratch the student can
pick the language of his/her liking as long as the result is crossplatform
(at least Linux/Windows/OS X).

(Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)

Some of the things the new/revived editor should be able to do:
* Include all features of the current editor.
* When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
* The editor needs to be able to handle so called ''custom terrain'', these are terrains used in maps but not loaded by default.
* The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
* The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
* Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.

==== Required knowledge and talent ====
* The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
* The student needs to be able to make a user friendly user interface.
* Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.

==== Milestones and deliverables ====
* The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
* From this list the student needs create a sublist of items he/she will be able to do within one summer.
* This needs to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Make your own ideas ===
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.

=== Other ideas to be fleshed out ===
* A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.

== Other info to provide for GSoC ==
==== Describe your organization. ====
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp). David currently works at Google.

The general [http://www.wesnoth.org/wiki/WesnothPhilosophy Philosophy] of the game (both for gameplay and coding) puts an emphasis on simplicity. The core rules are meant to be learnt easily but provide interesting gameplay and diverse strategies.

On the other hand, or Wesnoth Markup Language (WML) provides a simple language to easily customize scenarios, which has lead to a huge modding community providing us with a large amount of content.

The first stable release (1.0) was on October 2 2005, the latest stable release (1.4) was on March 8 2008. 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.

Wesnoth has grown a lot and is now considered one of the largest open source games around.
* two servers (stable and developement) with a usual minimum load of more than a hundred players
* more than two thousands downloads a day
* 2.1 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
* best rated game at the [http://www.happypenguin.org/list?sort=avg_rating linux game tome]
* game of the year 2007 at [http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/open-source-game-of-the-year-610236/ linuxquestions.org]
* One of the top 20 rated projects on [http://freshmeat.net/stats/#rating Freshmeat] (currently 16th highest rating, and the highest rated game).

* A mature project, but with active development and many improvements
* High quality artwork: both graphics and music
* Very well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after five years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing

==== Why is your organization applying to participate in GSoC 2008? 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.

If a student were dedicated to any of these uncovered areas, we believe that person could be brought up to speed relatively quickly and function as a peer of the existing developers.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth project has applied to Google SoC.

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth project has applied to Google SoC.

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything else was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code page is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domains of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev@gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

in particular, all art developement takes place on the forum.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* Basics
** Write a small introduction to yourself.
** State your preferred email address.
** If you have chosen a nick for IRC and Wesnoth forums, what is it?
** Why do you want to participate in summer of code?
** What are you studying, subject, level and school?

* Experience
** What programs/software have you worked on before?
** Have you developed software in a team environment before? (As opposed to hacking on something on your own)
** 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?
** What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
** Open Source
*** Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
** Gaming experience
*** Are you a gamer? If so...
*** What type of gamer are you?
*** What type of games?
*** What type of opponents do you prefer?
*** Are you more interested in story or gameplay?
*** 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.

* Communication skills
** Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
** Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
** Do you give constructive advice?
** Do you receive advice well?
** Are you good at sorting useful criticisms from useless ones?

* Project
** Did you select a project from our list? If that is the case, what project did you select?
** If you have invented your own project, please describe the project and the scope.
** Why did you choose this project?
** Include an estimated timeline for your work on the project
** Include as much technical detail about your implementation as you can
** What do you expect to gain from this project?
** What would make you stay in the Wesnoth community after the conclusion of SOC?

* Practical considerations
** Are you familiar with any of the following tools?
*** Subversion
*** C++
*** Python
** Which tools do you normally use for development? Why do you use them?
** What programming languages are you fluent in?
** What spoken languages are you fluent in?
** At what hours are you awake (please specify in UTC)
** Would you mind talking with your mentor on telephone / internet phone?

* Detailed answer (optional, but writing skill is a good predictor of ability to work on a programming team, so you will improve your chances by responding to this).
** Write a small essay (750-1000 words or more) explaining why you want to participate in a Wesnoth GSoC project. You can use the above questions as guides, but feel free to throw in more information if you feel it is relevant.
** What is your perception of 'open source'? Briefly explain what you think of the whole 'open source' concept, how you discovered open source, what you expect to gain/experience by participating in an open-source project. (Answer separately or as part of above mini-essay)
** What motivates or inspires you to write programs and develop software?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====
David White (davewx7@gmail.com)

==== Who will your mentors be? Please include Google Account information.====

David White (davewx7@gmail.com)

Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)

Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)

Jörg Hinrichs alias YogiHH (joerghh.hinrichs|ATTT|googlemail.com)

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

Our first criterion was that all the people had to be volunteers. According to other open source projects, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Dave is the project leader and one of the most knowledgeable in C++. He has also written the Formula AI code which we plan to develop via the SoC. He is well known in our community for formulating simple but effective explanations for complicated topics, and has good design intuition. The growth of Wesnoth demonstrates his capacity to get other developers to work together and keep them involved in a thriving community.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the [http://wiki.wesnoth.org/UnsortedContrib Art Contribution] section of the wiki (now automated) and the [http://wiki.wesnoth.org/ReferenceWML WML Reference Manual]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org and has created the new developer process we currently use.

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 polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base.

YogiHH has been with the project for more than two years. He did a major refactoring to the gameplay engine and worked quite a bit on the multiplayer code. He also has been a professional trainer for C/C++, Java and C# for many years. Right now he works in a project where he serves as a mentor for a junior developer.

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 for which regards. 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 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.

==== What is your plan for dealing with disappearing students?====
The first thing to do is to avoid this situation altogether.

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 sensible about criticism and our community is used to people being sensible to critics.

We will 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, his mentor will be in charge of recontacting him 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 defuse the problem.

If a student disappears completely and there is no way to get back to him, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN 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 took the time to ask other former GSoC projects about the workload needed to be a mentor, and our mentors accepted the job knowing the amount of work it involved.

However, should it happen, we would continue to mentor as a developper 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, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, 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 (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles 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 maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

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 be rough at time.

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

Since our community has a history of having developers easily and quickly join, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).

Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part.

== People to bug on IRC ==
Everybody feel free to edit/correct his entry!

=== 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.

=== Elias Pscherning (elias) ===
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.

=== 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.

=== Karol Nowak (grzywacz) ===
Last year he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on embedded devices, and is actively working on the gp2x support.

=== 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. Given that Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as already being our area expert for the terrain engine.

=== 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; just don't ask him about revising the level of randomness in the game.

=== Noyga ===
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.

=== 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.

=== YogiHH or Piotr Cychowski (cycholka) ===
Since they are the two developers who know most about building under Windows, they 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.

=== zookeeper or 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.

[[Category:Future]]

SummerOfCodeIdeas

2008-03-15T02:43:34Z

Mesilliac: /* I want to be one of your Google Summer of Code student, what should I do... */ typo

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== I want to be one of your Google Summer of Code students, what should I do... ==

Here is a quick list of things to do to get you started
* Create an account on gna.org
* Create an account on the wesnoth forum
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learnt to know during the selection process
* Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
* Start a wiki page about your idea, add a link on this page
** Fill the questionnaire on this page
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna.

== List of Ideas for the Project (Suggestions from the wesnoth developers) ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[WesnothFormulaAIBranch]]

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done.

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behavior of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviors :'' there are some typical behaviors that are not optimal for winning a force-on-force battle but are needed for storyline reasons, such as: guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviors, and allow easy addition of new behaviors

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the Wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and gameplay patterns used by human players. This will require a lot of interaction with the player community. Our gameplay developers are communicative and can give some good starting points, but a lot of game experience and good interactions with the player community will be essential for doing a good redesign.

==== Milestones and deliverables ====

It is hard to set milestones at this point, but here are some ideas of what could be done:

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behavior they need
* ''Main AI delivery :'' This milestone goal is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behavior library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviors should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behavior desired.

=== Extending the Multiplayer server ===

Our multiplayer community is generally strong and healthy,but we believe its growth is limited by some problems in the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To develop ifeas about how our multiplayer interface could evolve to allow it to scale to a much larger community
* And to implement as many of those changes as practical

Some ideas that we had (but that are in no way mandatory):
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? Again, inspired by IRC
* Having some way to find the type of games you are interested in. filtering by:
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not yet convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers
* game matching when players are ranked (poker, bridge...)

The scalability of the design (both in term of number of players, and in term of the possibility for players and developers to extend the concept) will be an important criterion.

Administration/moderation problems and techniques should also be studied.

Interaction with the Add-On server/forum should be explored.

==== Required knowledge and talent ====

* A fair amount of experience with C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle.
* Experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Scenario/Campaign editor ===

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor to make the creative process easier.

==== General description ====

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. What exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose (but see the note on Python below). The main ideas would be for the scenario editor to be:
* cross-platform (at least Linux, OSX, Windows)
* easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even not knowing WML)
* powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
* extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

* Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
* Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
* GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
* Decide on base features. [[ReferenceWML]] lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
** WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
** Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
** Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
** Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
** Story screen editor for campaigns?
** How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
** Custom unit animations?
** Custom multi-hex terrains?
* Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
* WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

==== Required knowledge and talent ====
* Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
* Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
* Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
* Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
* Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
* Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

==== Milestones and deliverables ====
The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:
* Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
* Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
* Finish design. Should list the intended features and demonstrate how the GUI will work.
* Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
* Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

=== Addon server ===
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

==== General description ====
Neither the server nor the client side of the addon server have
seen much improvement over the years; both are overdue for a reworking.
The client side GUI needs polishing. For the
server side we would like to allow better integration with
various tools (such as wmllint), which improve the quality of the addons.

===== Server side =====
The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.

* The server only needs to run on Linux systems. Cross-platform portability would be nice but isn't required.
* At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
* We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

===== Client side =====
The client side needs improvements. There are two main clients;
one built in to the C++ game binary, and a standalone inmplementation in Python.

* Upgrade the GUI. Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
* Make it easier to see summary and status information on addons. At the moment a lot of new users download something and have no clue what kind of addon it is.
* Make it easier to see whether a newer version of the addon is on the server and update the addon.
* Make it easy to select which translations you want to download and also look for newer versions of the translations.

==== Required knowledge and talent ====
* Knowledge of C++, the game is written in C++ and modifications need to be made there.
* Knowledge of Python, various tools have been written in Python which need to be integrated with the new server.

==== Milestones and deliverables ====
* The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
** Determine the exact feature set.
** Protocol changes needed.
** Methods to integrate with both the WML tools and Wescamp with the new server.
** Determine the GUI for the client side.
** Justify the choice of language.
* These points will need to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Map editor ===
The map editor in Wesnoth serves two goals, making it easy to create
a new map and helping the terrain artists to test their new terrains.

==== General description ====
The current editor hasn't been actively maintained for quite a while and the
quality of the code isn't up to par with the main game. The student
will either revive the current editor or start from scratch, the latter
will probably be easier. When rewriting from scratch the student can
pick the language of his/her liking as long as the result is crossplatform
(at least Linux/Windows/OS X).

(Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)

Some of the things the new/revived editor should be able to do:
* Include all features of the current editor.
* When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
* The editor needs to be able to handle so called ''custom terrain'', these are terrains used in maps but not loaded by default.
* The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
* The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
* Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.

==== Required knowledge and talent ====
* The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
* The student needs to be able to make a user friendly user interface.
* Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.

==== Milestones and deliverables ====
* The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
* From this list the student needs create a sublist of items he/she will be able to do within one summer.
* This needs to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Make your own ideas ===
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.

=== Other ideas to be fleshed out ===
* A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.

== Other info to provide for GSoC ==
==== Describe your organization. ====
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp). David currently works at Google.

The general [http://www.wesnoth.org/wiki/WesnothPhilosophy Philosophy] of the game (both for gameplay and coding) puts an emphasis on simplicity. The core rules are meant to be learnt easily but provide interesting gameplay and diverse strategies.

On the other hand, or Wesnoth Markup Language (WML) provides a simple language to easily customize scenarios, which has lead to a huge modding community providing us with a large amount of content.

The first stable release (1.0) was on October 2 2005, the latest stable release (1.4) was on March 8 2008. 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.

Wesnoth has grown a lot and is now considered one of the largest open source games around.
* two servers (stable and developement) with a usual minimum load of more than a hundred players
* more than two thousands downloads a day
* 2.1 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
* best rated game at the [http://www.happypenguin.org/list?sort=avg_rating linux game tome]
* game of the year 2007 at [http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/open-source-game-of-the-year-610236/ linuxquestions.org]
* One of the top 20 rated projects on [http://freshmeat.net/stats/#rating Freshmeat] (currently 16th highest rating, and the highest rated game).

* A mature project, but with active development and many improvements
* High quality artwork: both graphics and music
* Very well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after five years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing

==== Why is your organization applying to participate in GSoC 2008? 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.

If a student were dedicated to any of these uncovered areas, we believe that person could be brought up to speed relatively quickly and function as a peer of the existing developers.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth project has applied to Google SoC.

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth project has applied to Google SoC.

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything else was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code page is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domains of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev@gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

in particular, all art developement takes place on the forum.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* Basics
** Write a small introduction to yourself.
** State your preferred email address.
** If you have chosen a nick for IRC and Wesnoth forums, what is it?
** Why do you want to participate in summer of code?
** What are you studying, subject, level and school?

* Experience
** What programs/software have you worked on before?
** Have you developed software in a team environment before? (As opposed to hacking on something on your own)
** 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?
** What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
** Open Source
*** Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
** Gaming experience
*** Are you a gamer? If so...
*** What type of gamer are you?
*** What type of games?
*** What type of opponents do you prefer?
*** Are you more interested in story or gameplay?
*** 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.

* Communication skills
** Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
** Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
** Do you give constructive advice?
** Do you receive advice well?
** Are you good at sorting useful criticisms from useless ones?

* Project
** Did you select a project from our list? If that is the case, what project did you select?
** If you have invented your own project, please describe the project and the scope.
** Why did you choose this project?
** Include an estimated timeline for your work on the project
** Include as much technical detail about your implementation as you can
** What do you expect to gain from this project?
** What would make you stay in the Wesnoth community after the conclusion of SOC?

* Practical considerations
** Are you familiar with any of the following tools?
*** Subversion
*** C++
*** Python
** Which tools do you normally use for development? Why do you use them?
** What programming languages are you fluent in?
** What spoken languages are you fluent in?
** At what hours are you awake (please specify in UTC)
** Would you mind talking with your mentor on telephone / internet phone?

* Detailed answer (optional, but writing skill is a good predictor of ability to work on a programming team, so you will improve your chances by responding to this).
** Write a small essay (750-1000 words or more) explaining why you want to participate in a Wesnoth GSoC project. You can use the above questions as guides, but feel free to throw in more information if you feel it is relevant.
** What is your perception of 'open source'? Briefly explain what you think of the whole 'open source' concept, how you discovered open source, what you expect to gain/experience by participating in an open-source project. (Answer separately or as part of above mini-essay)
** What motivates or inspires you to write programs and develop software?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====
David White (davewx7@gmail.com)

==== Who will your mentors be? Please include Google Account information.====

David White (davewx7@gmail.com)

Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)

Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)

Jörg Hinrichs alias YogiHH (joerghh.hinrichs|ATTT|googlemail.com)

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

Our first criterion was that all the people had to be volunteers. According to other open source projects, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Dave is the project leader and one of the most knowledgeable in C++. He has also written the Formula AI code which we plan to develop via the SoC. He is well known in our community for formulating simple but effective explanations for complicated topics, and has good design intuition. The growth of Wesnoth demonstrates his capacity to get other developers to work together and keep them involved in a thriving community.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the [http://wiki.wesnoth.org/UnsortedContrib Art Contribution] section of the wiki (now automated) and the [http://wiki.wesnoth.org/ReferenceWML WML Reference Manual]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org and has created the new developer process we currently use.

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 polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base.

YogiHH has been with the project for more than two years. He did a major refactoring to the gameplay engine and worked quite a bit on the multiplayer code. He also has been a professional trainer for C/C++, Java and C# for many years. Right now he works in a project where he serves as a mentor for a junior developer.

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 for which regards. 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 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.

==== What is your plan for dealing with disappearing students?====
The first thing to do is to avoid this situation altogether.

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 sensible about criticism and our community is used to people being sensible to critics.

We will 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, his mentor will be in charge of recontacting him 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 defuse the problem.

If a student disappears completely and there is no way to get back to him, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN 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 took the time to ask other former GSoC projects about the workload needed to be a mentor, and our mentors accepted the job knowing the amount of work it involved.

However, should it happen, we would continue to mentor as a developper 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, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, 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 (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles 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 maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

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 be rough at time.

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

Since our community has a history of having developers easily and quickly join, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).

Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part.

== People to bug on IRC ==
Everybody feel free to edit/correct his entry!

=== 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.

=== Elias Pscherning (elias) ===
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.

=== 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.

=== Karol Nowak (grzywacz) ===
Last year he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on embedded devices, and is actively working on the gp2x support.

=== 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. Given that Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as already being our area expert for the terrain engine.

=== 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; just don't ask him about revising the level of randomness in the game.

=== Noyga ===
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.

=== 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.

=== YogiHH or Piotr Cychowski (cycholka) ===
Since they are the two developers who know most about building under Windows, they 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.

=== zookeeper or 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.

[[Category:Future]]

SummerOfCodeIdeas

2008-03-15T02:43:09Z

Mesilliac: /* Required knowledge and talent */ typo

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== I want to be one of your Google Summer of Code student, what should I do... ==

Here is a quick list of things to do to get you started
* Create an account on gna.org
* Create an account on the wesnoth forum
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learnt to know during the selection process
* Contact one of our SummerOfCode people (Ivanovic, Sirp, Boucman, Mordante) to have your forum nick marked as a Summer of code student
* Start a wiki page about your idea, add a link on this page
** Fill the questionnaire on this page
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna.

== List of Ideas for the Project (Suggestions from the wesnoth developers) ==

=== Writing an AI based on the formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[WesnothFormulaAIBranch]]

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done.

==== General description ====

The aim of this project is to develop a new AI that would replace the original C++ AI. The main criterias we would want for this new AI are

* ''Plugability :'' It should be trivial for any content maker to change the behavior of the AI in specific case. The exact cases are still to be defined but should typically include
** hardwiring the first few turns of the AI
** changing the recruitment pattern
** completely controlling a given unit (scenario unit)
** taking control then giving back control of a given unit
* ''tunability :'' It should be easy for a scenario author to specify the general behavior of the enemy on a given scenario (aggressiveness, intrepidity...)
* ''specific behaviors :'' there are some typical behaviors that are not optimal for winning a force-on-force battle but are needed for storyline reasons, such as: guarding a given unit, a given position, wandering aimlessly, attacking randomly, always fleeing. The AI should implement such behaviors, and allow easy addition of new behaviors

==== Required knowledge and talent ====

* ''A minimal knowledge of C++ is required, a good knowledge of C++ is desired :'' The formula AI framework is a work in progress and chances are high that some changes in the Wesnoth code base will be needed. The wesnoth developer community is used to handle people that are familiar with coding but not C++, however the Formula AI framework uses advanced C++ features and a good knowledge of the language would avoid a major hurdle when plugging in new entries or functionalities for the AI
* ''Good social interaction with a large player community :'' A preliminary phase to coding any AI is to know the strategies and gameplay patterns used by human players. This will require a lot of interaction with the player community. Our gameplay developers are communicative and can give some good starting points, but a lot of game experience and good interactions with the player community will be essential for doing a good redesign.

==== Milestones and deliverables ====

It is hard to set milestones at this point, but here are some ideas of what could be done:

* ''AI design description, and basic function library :'' This first deliverable aims to conclude the '''study and analysis''' part of the project : becoming familiar with the formula language, study of multiplayer strategies and of the need of scenario writers with regard to AI. We would like to have a description of the code structure of the AI, some basis of the play strategies it would use and how external scenario writers could configure it for the particular behavior they need
* ''Main AI delivery :'' This milestone goal is to deliver a working AI implementing the strategies described in the first phase. It would not have to systematically beat the standard C++ AI at this point, but should be able to play the game correctly (recruit, early deployment on villages, grouping units to attack, holding its ground, protecting weak/important units). Moreover most plug-in entries should be available and a test-case for these entries should be provided.
* ''Fine tunning and behavior library :'' The third phase would validate the actual strategy of the AI. The AI should consistently beat the default C++ AI, and do fairly well against an average human player. At that stage a library of scenario behaviors should also be delivered. The AI does not need to be as efficient with all scenario tweaking, but should act correctly with regard to the particular behavior desired.

=== Extending the Multiplayer server ===

Our multiplayer community is generally strong and healthy,but we believe its growth is limited by some problems in the interface of the multiplayer lobby.

==== General Description ====
The general idea of this project would be
* To study the current lobby,
* To develop ifeas about how our multiplayer interface could evolve to allow it to scale to a much larger community
* And to implement as many of those changes as practical

Some ideas that we had (but that are in no way mandatory):
* Having a simple way to register and authenticate nicknames, similar to what IRC offers. The point is not to have cryptographically safe logins, but to have something simple that gets the job done
* Having a simple room system? Again, inspired by IRC
* Having some way to find the type of games you are interested in. filtering by:
** game type
** number of free slots/players
** any other criteria you might find interesting

Other ideas we are not yet convinced are good, but that are certainly worth studying (especially how the communities based around these concepts are different from ours)
* ranking players
* guilds
* official tournaments
* titles for players
* metaservers
* game matching when players are ranked (poker, bridge...)

The scalability of the design (both in term of number of players, and in term of the possibility for players and developers to extend the concept) will be an important criterion.

Administration/moderation problems and techniques should also be studied.

Interaction with the Add-On server/forum should be explored.

==== Required knowledge and talent ====

* A fair amount of experience with C++ is required. Wesnoth uses some advanced C++ features and is heavily based on BOOST and STL. We can train you in some of the libraries used, but learning all of them would be a big hurdle.
* Experience with multiplayer games, in order to have a good idea of what multiplayer lobbies of other game look like, and (more importantly) a good idea of the social behaviours of multiple MP communities, how teams are formed in games and things like that

==== Milestones and deliverables ====

* A first milestone would be a presentation summarizing the different studies, and the proposed interface. preliminary informal stages would probably be desirable, to make sure the proposed idea is already a consensus within devs
** Study of other MP game-matching interfaces and functionalities
** Study of other MP communities
** Study of other MP moderation practices
** Study of the Wesnoth MP community, including needs, various opinons from different developers and players
* A second milestone would be the main code delivery. Code should be functional for it will be delivered in the next Wesnoth development release

=== Scenario/Campaign editor ===

Currently, in order to create campaign or multiplayer scenarios, it is necessary to manually edit WML files - XML-like configuration files. The goal of this project would be to create a graphical editor to make the creative process easier.

==== General description ====

A scenario editor for Wesnoth supporting everything possible by Wesnoth's engine would be a huge project, so the scope of the actual project must be limited for feasability. What exactly should be implemented would be decided by initial discussion. Implementation details and choice of language/tools would also be up to the student to choose (but see the note on Python below). The main ideas would be for the scenario editor to be:
* cross-platform (at least Linux, OSX, Windows)
* easy to use (someone who tries reasonably hard should be able to create a simple scenario/campaign with it, even not knowing WML)
* powerful (there already is a map editor coming with Wesnoth - the scenario editor will provide more/different things)
* extensible (also after the SoC project, it should be easy to add additional features)

There exist at least two attempts at a scenario editor, an OSX-only one which shipped with early Wesnoth versions, and CampGen, an external tool written in WxPython. The student could look at them for ideas or even use one of them as base, but that should be discussed first. The below assumes a new application is developed from scratch (which likely will be much more motivating for the student than reviving an existing attempt). The actual things to be done would be:

* Decide on a cross-platform GUI which would be best suited (Qt4, Wx, GTK, Wesnoth's builtin GUI (in that case, could maybe integrate with the existing map editor, but would have serious other problems), or others...).
* Decide on a platform/language to use (C++, Python, or others...). Wesnoth is written in C++, so it's what most developers would prefer, but as long as it can be expected to work on Linux, OSX and Windows, this is completely open.
* GUI design. This is the main part of the project. The editor should make it easy to create scenarios, so the GUI must not be confusing/hard to use.
* Decide on base features. [[ReferenceWML]] lists everything currently supported by WML. Theoretically, the scenario editor could support everything, but for the timeframe of the SoC project, it will be necessary to decide on the most important features and implement those.
** WML-centric or not? Two opposite views for such an editor would be to either strictly follow WML, as extreme case have one dialog for each WML element. Or on the other hand make a scenario creation tool which completely hides WML and then simply can export to WML, translating features as necessary. The final design likely would be somewhere in between.
** Ability to read existing WML? The editor will export to WML, but need to decide if it also should be able to read it.
** Built-in map editor? Wesnoth comes with a map editor, but it can only be used to define the terrain. The scenario editor has to allow placing events and units and other things, so it will need a way to display maps as well. Would be worth investigating if the existing C++ map-drawing code of Wesnoth can be re-used.
** Ability to enter custom WML code? For advanced users this might be nice, if it can integrate well.
** Story screen editor for campaigns?
** How powerful should the events editor be? WML basically is a turing complete language, so must decide what should be supported and how to present to the user.
** Custom unit animations?
** Custom multi-hex terrains?
* Extensibility (leave the possibility to extend the application with plugins for some of the above things, either with a plugin architecture or by making the source code modular enough)
* WML-export. The second major part besides designing and implementing all the GUI will be exporting the result to WML, and depending on some design choices this could prove more or less hard to do.

==== Required knowledge and talent ====
* Knowledge of C++. Even in case the editor is not written in C++, it will be necessary to look at some parts of Wesnoth's source code (WML-parser, editor, ...) and understand them, possibly even integrate/re-use them.
* Ability/interest in GUI/application design. A not negligible part of the project likely will be spent designing various GUI dialogs.
* Prior use of level creation tools/modding tools. Knowing existing tools for other games will help a lot in the design phase, as many good ideas can be seen there. Not required though.
* Having played Wesnoth and knowing what scenarios look like would help. Someone who never played Wesnoth before would risk losing a lot of precious time playing the game instead of working :) But it's not required of course.
* Knowledge of WML. A candidate who already knows Wesnoth's WML could save the initial time studying it. (On the other hand, not knowing WML might mean less technical bias and might lead to an application which is easer to use for non-technical users.)
* Ability to interact with developers/users. Presenting GUI mockups and test versions and incorporating early user feedback likely will improve the end result a lot. The Wesnoth community is big enough that there should be quite some willing testers.

==== Milestones and deliverables ====
The initial design will decide on many later things, and likely a lot of talking to developers and users will be necessary. But some general milestones I'd expect:
* Create a base test application in the chosen language/platform. This will not do much yet, maybe load some WML and display it as text. Try to package it for Linux, OSX and Windows (there will be help from the Wesnoth community, so no need to have access to all of them), and see if it can be expected to work. If a standard GUI like C++/Qt4 is used, this will be rather trivial. Something like Python/Wx or C#/.NET might take more time.
* Add ability to edit some very simple, maybe only textual properties of a scenario, and export to WML. It should already have base features like Save/Load/Undo, copy/paste, multiple documents, and so on. Depending on the chosen GUI this may be easy or already require some work.
* Finish design. Should list the intended features and demonstrate how the GUI will work.
* Start implementation, a natural milestone would be to make it possible to create and export a very simple, but playable scenario.
* Add more of the features (which ones and in which order depends on the design above, a detailed roadmap will be part of it).

=== Addon server ===
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

==== General description ====
Neither the server nor the client side of the addon server have
seen much improvement over the years; both are overdue for a reworking.
The client side GUI needs polishing. For the
server side we would like to allow better integration with
various tools (such as wmllint), which improve the quality of the addons.

===== Server side =====
The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.

* The server only needs to run on Linux systems. Cross-platform portability would be nice but isn't required.
* At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
* We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

===== Client side =====
The client side needs improvements. There are two main clients;
one built in to the C++ game binary, and a standalone inmplementation in Python.

* Upgrade the GUI. Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
* Make it easier to see summary and status information on addons. At the moment a lot of new users download something and have no clue what kind of addon it is.
* Make it easier to see whether a newer version of the addon is on the server and update the addon.
* Make it easy to select which translations you want to download and also look for newer versions of the translations.

==== Required knowledge and talent ====
* Knowledge of C++, the game is written in C++ and modifications need to be made there.
* Knowledge of Python, various tools have been written in Python which need to be integrated with the new server.

==== Milestones and deliverables ====
* The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
** Determine the exact feature set.
** Protocol changes needed.
** Methods to integrate with both the WML tools and Wescamp with the new server.
** Determine the GUI for the client side.
** Justify the choice of language.
* These points will need to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Map editor ===
The map editor in Wesnoth serves two goals, making it easy to create
a new map and helping the terrain artists to test their new terrains.

==== General description ====
The current editor hasn't been actively maintained for quite a while and the
quality of the code isn't up to par with the main game. The student
will either revive the current editor or start from scratch, the latter
will probably be easier. When rewriting from scratch the student can
pick the language of his/her liking as long as the result is crossplatform
(at least Linux/Windows/OS X).

(Note: Unlike the add-on server, there is no specific code-integration reason to prefer Python for the editor rewrite in advance. However. the project has been trying to reduce its dependence on other scripting languages in order to hold down overall maintenance complexity. Thus, the student should be prepared to justify the choice of any language that is not Python or C++.)

Some of the things the new/revived editor should be able to do:
* Include all features of the current editor.
* When rewritten, great care must be taken that the render engine works the same as the render engine in the main game. When rewritten in C++ it can simply use the game sources, otherwise the student needs to turn the main game C++ files into a library which can be called in the language the editor will be written in.
* The editor needs to be able to handle so called ''custom terrain'', these are terrains used in maps but not loaded by default.
* The editor needs to be able to reload the terrain graphics config files, this way terrain artist can test the changes to the config files without having to reload the editor.
* The current editor can generate random maps with help of a config file, which contains a generator definition. The editor can only use one generator hardcoded. This needs to be modified to be able to use every generator config the user has installed.
* Various ideas exist to help the artists to make it easier to tune their terrains and config files, this is a secondary goal. We think it will be too much work to do this in one summer.

==== Required knowledge and talent ====
* The current editor and the main game are written in C++ therefore knowledge of C++ is required. Even if the editor is rewritten in another language the render engine needs to be converted to a library.
* The student needs to be able to make a user friendly user interface.
* Depending on in which language and toolkit the editor is (re)written in the student will need to have skills in that language and toolkit. The current editor uses the SDL toolkit with our own widget toolkit.

==== Milestones and deliverables ====
* The first step is to make a priority list of features. This means the student has to interact with the community and determine what is most wanted.
* From this list the student needs create a sublist of items he/she will be able to do within one summer.
* This needs to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

=== Make your own ideas ===
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.

=== Other ideas to be fleshed out ===
* A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.

== Other info to provide for GSoC ==
==== Describe your organization. ====
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp). David currently works at Google.

The general [http://www.wesnoth.org/wiki/WesnothPhilosophy Philosophy] of the game (both for gameplay and coding) puts an emphasis on simplicity. The core rules are meant to be learnt easily but provide interesting gameplay and diverse strategies.

On the other hand, or Wesnoth Markup Language (WML) provides a simple language to easily customize scenarios, which has lead to a huge modding community providing us with a large amount of content.

The first stable release (1.0) was on October 2 2005, the latest stable release (1.4) was on March 8 2008. 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.

Wesnoth has grown a lot and is now considered one of the largest open source games around.
* two servers (stable and developement) with a usual minimum load of more than a hundred players
* more than two thousands downloads a day
* 2.1 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
* best rated game at the [http://www.happypenguin.org/list?sort=avg_rating linux game tome]
* game of the year 2007 at [http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/open-source-game-of-the-year-610236/ linuxquestions.org]
* One of the top 20 rated projects on [http://freshmeat.net/stats/#rating Freshmeat] (currently 16th highest rating, and the highest rated game).

* A mature project, but with active development and many improvements
* High quality artwork: both graphics and music
* Very well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after five years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing

==== Why is your organization applying to participate in GSoC 2008? 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.

If a student were dedicated to any of these uncovered areas, we believe that person could be brought up to speed relatively quickly and function as a peer of the existing developers.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that have lagged behind

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.====
This is the first time the Wesnoth project has applied to Google SoC.

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

This is the first time the Wesnoth project has applied to Google SoC.

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper aka Ivanovic

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
Our project is entirely GPL.

All code is GPL.

All art is GPL, 99% was made for the project, everything else was taken from content that was checked to be GPL.

==== What is the URL for your ideas page?====
Our main summer of code page is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domains of interest.

==== What is the main development mailing list or forum for your organization?====
Most development work takes place on "wesnoth-dev@gna.org". Beside this some work happens at http://www.wesnoth.org/forum/.

in particular, all art developement takes place on the forum.

==== What is the main IRC channel for your organization?====

All our IRC channels are on the ''freenode'' network

* ''#wesnoth-dev'' is the main development channel, where most discussion takes place
* ''#wesnoth'' is a generic channel for the community
* ''#wesnoth-mp'' is a separate channel for multiplayer games and balancing

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are wesnoth-specific and are worth pondering for any student, even if we don't need a formal answer

* Basics
** Write a small introduction to yourself.
** State your preferred email address.
** If you have chosen a nick for IRC and Wesnoth forums, what is it?
** Why do you want to participate in summer of code?
** What are you studying, subject, level and school?

* Experience
** What programs/software have you worked on before?
** Have you developed software in a team environment before? (As opposed to hacking on something on your own)
** 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?
** What development model would you use (e.g. keywords: V-model, XP programming, agile programming, iterative; with the help of prototyping, formal specifications, tests, etc).
** Open Source
*** Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
** Gaming experience
*** Are you a gamer? If so...
*** What type of gamer are you?
*** What type of games?
*** What type of opponents do you prefer?
*** Are you more interested in story or gameplay?
*** 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.

* Communication skills
** Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
** Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
** Do you give constructive advice?
** Do you receive advice well?
** Are you good at sorting useful criticisms from useless ones?

* Project
** Did you select a project from our list? If that is the case, what project did you select?
** If you have invented your own project, please describe the project and the scope.
** Why did you choose this project?
** Include an estimated timeline for your work on the project
** Include as much technical detail about your implementation as you can
** What do you expect to gain from this project?
** What would make you stay in the Wesnoth community after the conclusion of SOC?

* Practical considerations
** Are you familiar with any of the following tools?
*** Subversion
*** C++
*** Python
** Which tools do you normally use for development? Why do you use them?
** What programming languages are you fluent in?
** What spoken languages are you fluent in?
** At what hours are you awake (please specify in UTC)
** Would you mind talking with your mentor on telephone / internet phone?

* Detailed answer (optional, but writing skill is a good predictor of ability to work on a programming team, so you will improve your chances by responding to this).
** Write a small essay (750-1000 words or more) explaining why you want to participate in a Wesnoth GSoC project. You can use the above questions as guides, but feel free to throw in more information if you feel it is relevant.
** What is your perception of 'open source'? Briefly explain what you think of the whole 'open source' concept, how you discovered open source, what you expect to gain/experience by participating in an open-source project. (Answer separately or as part of above mini-essay)
** What motivates or inspires you to write programs and develop software?

''''to be completed''''

==== Who will be your backup organization administrator? Please include Google Account information.====
David White (davewx7@gmail.com)

==== Who will your mentors be? Please include Google Account information.====

David White (davewx7@gmail.com)

Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)

Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)

Jörg Hinrichs alias YogiHH (joerghh.hinrichs|ATTT|googlemail.com)

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====

Our first criterion was that all the people had to be volunteers. According to other open source projects, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Dave is the project leader and one of the most knowledgeable in C++. He has also written the Formula AI code which we plan to develop via the SoC. He is well known in our community for formulating simple but effective explanations for complicated topics, and has good design intuition. The growth of Wesnoth demonstrates his capacity to get other developers to work together and keep them involved in a thriving community.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the [http://wiki.wesnoth.org/UnsortedContrib Art Contribution] section of the wiki (now automated) and the [http://wiki.wesnoth.org/ReferenceWML WML Reference Manual]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org and has created the new developer process we currently use.

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 polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base.

YogiHH has been with the project for more than two years. He did a major refactoring to the gameplay engine and worked quite a bit on the multiplayer code. He also has been a professional trainer for C/C++, Java and C# for many years. Right now he works in a project where he serves as a mentor for a junior developer.

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 for which regards. 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 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.

==== What is your plan for dealing with disappearing students?====
The first thing to do is to avoid this situation altogether.

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 sensible about criticism and our community is used to people being sensible to critics.

We will 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, his mentor will be in charge of recontacting him 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 defuse the problem.

If a student disappears completely and there is no way to get back to him, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN 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 took the time to ask other former GSoC projects about the workload needed to be a mentor, and our mentors accepted the job knowing the amount of work it involved.

However, should it happen, we would continue to mentor as a developper 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, during and after the program?====

Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two patch... you're in" In other word, 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 (these project are usually a couple of hours long and has been chosen to provide easy access to code)

Usually, patches go back and forth a couple of time, to make sure that all secondary things are in place (indenting, coding style, modified makefiles 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 maintain our project alive.

If the student is a little proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

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 be rough at time.

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====

Since our community has a history of having developers easily and quickly join, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).

Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part.

== People to bug on IRC ==
Everybody feel free to edit/correct his entry!

=== 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.

=== Elias Pscherning (elias) ===
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.

=== 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.

=== Karol Nowak (grzywacz) ===
Last year he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on embedded devices, and is actively working on the gp2x support.

=== 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. Given that Mordante wants to tackle a rewrite of large parts of this, he will be our expert there as well as already being our area expert for the terrain engine.

=== 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; just don't ask him about revising the level of randomness in the game.

=== Noyga ===
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.

=== 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.

=== YogiHH or Piotr Cychowski (cycholka) ===
Since they are the two developers who know most about building under Windows, they 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.

=== zookeeper or 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.

[[Category:Future]]

User:Mesilliac

2008-03-13T06:58:38Z

Mesilliac: /* Randomly chosen images */

a.k.a. Yobbo

= Terrain WML Cleanup Proposal =

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

== Terrain Macros ==

=== Current system ===

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

=== Proposed change ===

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

=== Benefits ===

* Easier to maintain, as macros are separated from terrain declarations
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

=== Drawbacks ===

none

== Randomly chosen images ==

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
{TERRAIN_BASE_PROB Uu cave/floor2 20}
{TERRAIN_BASE_PROB Uu cave/floor3 25}
{TERRAIN_BASE_PROB Uu cave/floor4 33}
{TERRAIN_BASE_PROB Uu cave/floor5 50}
{TERRAIN_BASE Uu cave/floor6}
This gives an equal probability of each listed variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

=== Current system ===

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

=== Proposed change ===

In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.

=== Benefits ===

* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

=== Drawbacks ===

Checks for the existance of many nonexistant images

== Standard set of terrain graphics macros ==

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

=== Current system ===

Macros are added as necessary.

=== Proposed change ===

The addition of a set of standard macros for common terrain types:

; Base Terrain
: Normal single-hex flat terrain.
:; Examples in current terrain: dirt, water, grass, sand
:; Defining features:
::* Generic transitions are used if present.
::* Variations are used if present.
::* Only one base terrain can be used per tile
::* Only one base transition can be drawn for each edge of the tile
::* Image dimensions are 72x72
:; Macro arguments: Terrain_identifier, Dissimilar_terrains, base_image_name, layer
:; Basic image set: 1 base image, 6 transitions

All terrain types should specify a base terrain.

; Single-Hex Overlay
: Terrain used as an overlay for a single hex
:; Examples in current terrain: forest, mushroom grove with lightbeam (double overlay)
:; Defining features:
::* Transitions are not used
::* Variations are used if present
::* A "-small" variation should be provided for use next to terrains to avoid overlapping, for example castles, cavewall
::* Image dimensions are 180x252
:; Macro arguments: Overlay_identifier, base_overlay_image_name, layer
:; Basic image set: 1 base overlay, 1 small overlay

; Fence
: Draws walls along edges of a terrain
:; Examples in current terrain: castle, keep, cavewall
:; Defining features:
::* Variations are used if present
::* Only one fence image can be drawn for each point where 3 tiles meet
:; Macro arguments: terrain_identifier, base_fence_image_name
:; Basic image set: 6 concave corners, 6 convex corners

; Path
: Directional terrain, that only makes sense in lines. Joins to certain terrain types.
:; Examples in current terrain: bridge
:; Defining features:
::* Not required to make sense in clumps
::* Only transitions to certain terrain types are used
::* Variations are used if present
::* image dimensions are 180x252
:; Macro arguments: bridge_identifier, joiner_terrain_identifier bridge_overlay_image_name, layer
:; Basic image set: 1 lone image, 6 end images, 3 across images, 6 bend images

User:Mesilliac

2008-03-13T06:53:08Z

Mesilliac:

a.k.a. Yobbo

= Terrain WML Cleanup Proposal =

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

== Terrain Macros ==

=== Current system ===

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

=== Proposed change ===

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

=== Benefits ===

* Easier to maintain, as macros are separated from terrain declarations
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

=== Drawbacks ===

none

== Randomly chosen images ==

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
{TERRAIN_BASE_PROB Uu cave/floor2 20}
{TERRAIN_BASE_PROB Uu cave/floor3 25}
{TERRAIN_BASE_PROB Uu cave/floor4 33}
{TERRAIN_BASE_PROB Uu cave/floor5 50}
{TERRAIN_BASE Uu cave/floor6}
This gives an equal probability of each listen variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

=== Current system ===

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

=== Proposed change ===

In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.

=== Benefits ===

* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

=== Drawbacks ===

Checks for the existance of many nonexistant images

== Standard set of terrain graphics macros ==

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

=== Current system ===

Macros are added as necessary.

=== Proposed change ===

The addition of a set of standard macros for common terrain types:

; Base Terrain
: Normal single-hex flat terrain.
:; Examples in current terrain: dirt, water, grass, sand
:; Defining features:
::* Generic transitions are used if present.
::* Variations are used if present.
::* Only one base terrain can be used per tile
::* Only one base transition can be drawn for each edge of the tile
::* Image dimensions are 72x72
:; Macro arguments: Terrain_identifier, Dissimilar_terrains, base_image_name, layer
:; Basic image set: 1 base image, 6 transitions

All terrain types should specify a base terrain.

; Single-Hex Overlay
: Terrain used as an overlay for a single hex
:; Examples in current terrain: forest, mushroom grove with lightbeam (double overlay)
:; Defining features:
::* Transitions are not used
::* Variations are used if present
::* A "-small" variation should be provided for use next to terrains to avoid overlapping, for example castles, cavewall
::* Image dimensions are 180x252
:; Macro arguments: Overlay_identifier, base_overlay_image_name, layer
:; Basic image set: 1 base overlay, 1 small overlay

; Fence
: Draws walls along edges of a terrain
:; Examples in current terrain: castle, keep, cavewall
:; Defining features:
::* Variations are used if present
::* Only one fence image can be drawn for each point where 3 tiles meet
:; Macro arguments: terrain_identifier, base_fence_image_name
:; Basic image set: 6 concave corners, 6 convex corners

; Path
: Directional terrain, that only makes sense in lines. Joins to certain terrain types.
:; Examples in current terrain: bridge
:; Defining features:
::* Not required to make sense in clumps
::* Only transitions to certain terrain types are used
::* Variations are used if present
::* image dimensions are 180x252
:; Macro arguments: bridge_identifier, joiner_terrain_identifier bridge_overlay_image_name, layer
:; Basic image set: 1 lone image, 6 end images, 3 across images, 6 bend images

User:Mesilliac

2008-03-13T06:51:49Z

Mesilliac: /* Drawbacks */

a.k.a. Yobbo

= Terrain WML Cleanup Proposal =

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

== Terrain Macros ==

=== Current system ===

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

=== Proposed change ===

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

=== Benefits ===

* Easier to maintain, as macros are separated from terrain declarations
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

=== Drawbacks ===

none

== Randomly chosen images ==

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
{TERRAIN_BASE_PROB Uu cave/floor2 20}
{TERRAIN_BASE_PROB Uu cave/floor3 25}
{TERRAIN_BASE_PROB Uu cave/floor4 33}
{TERRAIN_BASE_PROB Uu cave/floor5 50}
{TERRAIN_BASE Uu cave/floor6}
This gives an equal probability of each listen variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

=== Current system ===

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

=== Proposed change ===

In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.

=== Benefits ===

* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

=== Drawbacks ===

Checks for the existance of many nonexistant images

== Standard set of terrain graphics macros ==

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

=== Current system ===

Macros are added as necessary.

=== Proposed change ===

The addition of a set of standard macros for common terrain types:

; Base Terrain
: Normal single-hex flat terrain.
:; Examples in current terrain: dirt, water, grass, sand
:; Defining features
::* Generic transitions are used if present.
::* Variations are used if present.
::* Only one base terrain can be used per tile
::* Only one base transition can be drawn for each edge of the tile
::* Image dimensions are 72x72
:; Macro arguments: Terrain_identifier, Dissimilar_terrains, base_image_name, layer
:; Basic image set: 1 base image, 6 transitions

All terrain types should specify a base terrain.

; Single-Hex Overlay
: Terrain used as an overlay for a single hex
:; Examples in current terrain: forest, mushroom grove with lightbeam (double overlay)
:; Defining features:
::* Transitions are not used
::* Variations are used if present
::* A "-small" variation should be provided for use next to terrains to avoid overlapping, for example castles, cavewall
::* Image dimensions are 180x252
:; Macro arguments: Overlay_identifier, base_overlay_image_name, layer
:; Basic image set: 1 base overlay, 1 small overlay

; Fence
: Draws walls along edges of a terrain
:; Examples in current terrain: castle, keep, cavewall
:; Defining features
::* Variations are used if present
::* Only one fence image can be drawn for each point where 3 tiles meet
:; Macro arguments: terrain_identifier, base_fence_image_name
:; Basic image set: 6 concave corners, 6 convex corners

; Path
: Directional terrain, that only makes sense in lines. Joins to certain terrain types.
:; Examples in current terrain: bridge
:; Defining features:
::* Not required to make sense in clumps
::* Only transitions to certain terrain types are used
::* Variations are used if present
::* image dimensions are 180x252
:; Macro arguments: bridge_identifier, joiner_terrain_identifier bridge_overlay_image_name, layer
:; Basic image set: 1 lone image, 6 end images, 3 across images, 6 bend images

User:Mesilliac

2008-03-13T06:50:27Z

Mesilliac:

a.k.a. Yobbo

= Terrain WML Cleanup Proposal =

I've been working a lot recently with the Terrain WML system, and I've spotted many, many things which could be tidied up. I've also been forced to learn first-hand how complicated the system is for adding a new terrain. It is my belief that Wesnoth is missing out on good terrain simply because potential terrain artists are unable to grasp the complexities of the terrain graphics system.

Nothing that I'm proposing will break the old system. User-made campaigns will still be able to use the old terrain-graphics system and macros. However new content will be able to be added much more easily, and current mainline terrains will become significantly easier to maintain.

== Terrain Macros ==

=== Current system ===

Important terrain macros are currently interspersed between a variety of .cfg files in data/core/terrain-graphics and the _final.cfg file that declares all the terrains.

=== Proposed change ===

Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.

=== Benefits ===

* Easier to maintain, as macros are separated from terrain declarations
* Terrain declarations can be moved to separate .cfg files in stead of all being in _final.cfg

=== Drawbacks ===

none

== Randomly chosen images ==

Randomly chosen images are currently specified using macros which take a probability value and may or may not draw the terrain depending on this probability. For example:
{TERRAIN_BASE_PROB Uu cave/floor2 20}
{TERRAIN_BASE_PROB Uu cave/floor3 25}
{TERRAIN_BASE_PROB Uu cave/floor4 33}
{TERRAIN_BASE_PROB Uu cave/floor5 50}
{TERRAIN_BASE Uu cave/floor6}
This gives an equal probability of each listen variation appearing on any given hex.

The great thing about this system is that it can be set up so that it still gives equal probabilities even if one or more of the initially specified graphics are missing.

=== Current system ===

All random terrain variations must be explicitly specified and a probability given in _final.cfg.

=== Proposed change ===

In ''new'' macros, add the probability macros for equal probability ''automatically'', using the image stem plus the numbers 1-9 for additional variations.

=== Benefits ===

* This naming system follows the current naming system, and the old system of selecting probabilities may still be used.
* New variations can be dropped in alongside current variations and they will automatically be used, with no editing of WML necessary

=== Drawbacks ===

none

== Standard set of terrain graphics macros ==

There is not currently a standard set of macros which can be used to add new terrains. Any artists wishing to add a new terrain must fully learn the complexities of the terrain WML system. Also, adding a new terrain to mainline requires editing macros in many separate places in _final.cfg.

=== Current system ===

Macros are added as necessary.

=== Proposed change ===

The addition of a set of standard macros for common terrain types:

; Base Terrain
: Normal single-hex flat terrain.
:; Examples in current terrain: dirt, water, grass, sand
:; Defining features
::* Generic transitions are used if present.
::* Variations are used if present.
::* Only one base terrain can be used per tile
::* Only one base transition can be drawn for each edge of the tile
::* Image dimensions are 72x72
:; Macro arguments: Terrain_identifier, Dissimilar_terrains, base_image_name, layer
:; Basic image set: 1 base image, 6 transitions

All terrain types should specify a base terrain.

; Single-Hex Overlay
: Terrain used as an overlay for a single hex
:; Examples in current terrain: forest, mushroom grove with lightbeam (double overlay)
:; Defining features:
::* Transitions are not used
::* Variations are used if present
::* A "-small" variation should be provided for use next to terrains to avoid overlapping, for example castles, cavewall
::* Image dimensions are 180x252
:; Macro arguments: Overlay_identifier, base_overlay_image_name, layer
:; Basic image set: 1 base overlay, 1 small overlay

; Fence
: Draws walls along edges of a terrain
:; Examples in current terrain: castle, keep, cavewall
:; Defining features
::* Variations are used if present
::* Only one fence image can be drawn for each point where 3 tiles meet
:; Macro arguments: terrain_identifier, base_fence_image_name
:; Basic image set: 6 concave corners, 6 convex corners

; Path
: Directional terrain, that only makes sense in lines. Joins to certain terrain types.
:; Examples in current terrain: bridge
:; Defining features:
::* Not required to make sense in clumps
::* Only transitions to certain terrain types are used
::* Variations are used if present
::* image dimensions are 180x252
:; Macro arguments: bridge_identifier, joiner_terrain_identifier bridge_overlay_image_name, layer
:; Basic image set: 1 lone image, 6 end images, 3 across images, 6 bend images

User:Mesilliac

2008-03-13T06:05:52Z

Mesilliac:

TerrainGraphicsWML

2008-03-09T04:23:24Z

Mesilliac: /* The toplevel [terrain_graphics] tag */ add [image]->base description

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** Conditions for [tile]:
*** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
*** '''has_flag''': a string. Matches if a flag named after the given string is attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
*** '''no_flag''': a string. Matches if no flag named after the given string has been attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** Actions for [tile]:
*** '''set_flag''': Followed by a string of characters. Attaches a flag named after the given string to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
*** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
**** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
**** '''name''': the image to apply on this tile if appropriate
**** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[Terrain Graphics Probability]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

Create Music

2008-02-28T05:11:58Z

Mesilliac: /* General Information */ "music" -> "data/core/music"

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "data/core/music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]] - read this first!
* [[Tools for Creating Music]] details some of the hardware and software you will need to create music for Wesnoth.
* [[Music Tutorials]] provides some links to useful tutorials and general advice on creating quality music in the style that Wesnoth's music development team requires.

== Adding music to a Scenario or Campaign ==

* [[Available Music]] lists all the pieces which are already available to use in scenarios and campaigns, as well as providing some links to works in progress.
* [[MusicListWML]] has information on using the [music] WML tag to add music to a Wesnoth scenario.

[[Category:Create]]
[[Category:Music]]

Available Music

2008-02-28T04:40:42Z

Mesilliac: /* Works in Progress */ named marcus rasseli's track

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; "Sing" by Marcus Rasseli ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-28T04:31:14Z

Mesilliac: /* Available Music for Campaign Authors */ add piece by hiro hito

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2

; "War Song" by hiro hito ([http://www.wesnoth.org/forum/viewtopic.php?t=17379 forum thread]) 6'27"
: http://download.tuxfamily.org/hirosound/tribal_war_song.mp3

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-28T04:17:23Z

Mesilliac: /* Core Music */ elaborate on how to play ogg files

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]]. For information on how to play .ogg files, visit http://www.vorbis.com/.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-28T04:15:57Z

Mesilliac: added some length indications for core tracks, added more info on how to listen to them, added two tracks to "available music for campaign authors"

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign. To listen to them, find the data/core/music subfolder of your Wesnoth folder, and open the files with a player capable of decoding [http://www.vorbis.com/ Ogg Vorbis] files. For information on where to find your Wesnoth directory, see [[EditingWesnoth]].

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg) 5'18"
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg) 3'35"
* "Defeat" by Timothy Pinkham (defeat.ogg) 0'08"
* "Defeat" by Ryan Reilly (defeat2.ogg) 0'14"
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg) 0'26"
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg) 3'25"
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg) 1'24"
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg) 9'17"
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg) 6'49"
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg) 2'43"
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg) 2'59"
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg) 0'48"
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg) 0'51"
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg) 0'39"
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg) 3'50"
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg) 1'17"
* "The City Falls" by Doug Kaufman (the_city_falls.ogg) 4'06"
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg) 3'41"
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg) 3'35"
* "Underground" by Aleksi Aubry-Carlson (underground.ogg) 1'52"
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg) 6'00"
* "Victory" by Timothy Pinkham (victory.ogg) 0'05"
* "Victory" by Ryan Reilly (victory2.ogg) 0'21"
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg) 4'22"

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread]) 0'32"
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

; "Reminisce" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=17246 forum thread]) 3'45"
: http://gnexp.com/songs/reminisce.ogg

; (Untitled) by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=17580 forum thread]) 1'14"
: http://www.box.net/shared/yopoe1hvh2

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-27T07:57:15Z

Mesilliac: added nunc_dimitis.ogg, moved "The City Falls" to core

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Nunc Dimittis" by Jeremy Nicoll (nunc_dimittis.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "The City Falls" by Doug Kaufman (the_city_falls.ogg)
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-25T22:35:48Z

Mesilliac: add quick note at the top indicating that anyone can help make this page better

A list of music tracks written for the Battle for Wesnoth.

If you find an incorrect link, or see that something is missing from this page or filed incorrectly, please fix it! We need your help to maintain this wiki :).

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y COMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-25T22:32:47Z

Mesilliac: /* Works in Progress */ remove some "complete" markers

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y COMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-25T22:30:07Z

Mesilliac: move knalgan theme, the king is dead to core

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "Knalgan Theme" by Ryan Reilly (knalgan_theme.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "The King is Dead" by Mattias Westlund (the_king_is_dead.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3 COMPLETE

; "Tragedy" by Ryan Reilly (Rain) ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y COMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

BuildingCampaigns

2008-02-25T05:00:52Z

Mesilliac: clean up some newlines

{| style="float:right; margin-left:1em;"
|__TOC__
|}

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

See also [[DebuggingCampaigns]] if your scenario doesn't load.

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

* [[BuildingCampaignsDirectoryStructure]]
* [[BuildingCampaignsTheCampaignFile]]
* [[BuildingCampaignsThePBLFile]]
* [[BuildingCampaignsDistribution]]
* [[WesCamp]] (How to make your campaign translatable, and get in touch with translators)

What follows is a collection of advice to aspiring campaign designers extracted from the Wesnoth fora. For a more in-depth treatment including heuristics for scenario and campaign balancing, see the [http://catb.org/~esr/wesnoth/campaign-design-howto.html Campaign Design How-To].

== Start with Something Manageable ==

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

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

== Story First ==

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

;Scott (author of Liberty, the outlaw campaign) wrote<nowiki>:</nowiki>
: Here is how I wrote Liberty.
:# Write a rough story and plot
:# Decide how many scenarios you want to have
:# Divide the story between the scenarios so you can decide what will happen in each scenario
:#* where are you?
:#* who are you fighting and why?
:#* what do you have to do in this scenario?
:#* where does the hero want to go next?
:# Decide on the "hook" for each scenario. There are a lot of different possible setups for scenarios, and if you want to avoid the boring repetition of "Kill the 2 enemy leaders" you can list interesting combinations of enemies, allies, shroud/fog, day/night effects, recruiting and terrain situations, etc. and pick a good mix to keep the combat interesting and fun.
: All of this has happened without doing any WML, but now you have enough to start coding.

== Share Early ==

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

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

== Steal Often ==

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

== Next: ==
* [[BuildingCampaignsTheCampaignFile]]

== See Also ==

* [[Create]]
* [[BuildingScenarios]]
* [[Using custom themes in campaigns]]
* [[ReferenceWML]]
* [[UserScenarios]]
* [[Abandoned_Campaigns]]
* [[ExternalUtilities]]
* [http://www.catb.org/~esr/wesnoth/campaign-design-howto.html Campaign Design How To]

{{Create}}

BuildingCampaigns

2008-02-25T04:54:47Z

Mesilliac: formatting: changed "no formatting" sections into indented blocks. They were impossible to read on small displays. Also float TOC at top-right

Create Music

2008-02-25T03:57:18Z

Mesilliac: /* Creating Music for Wesnoth */ added brief link descriptions

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]] - read this first!
* [[Tools for Creating Music]] details some of the hardware and software you will need to create music for Wesnoth.
* [[Music Tutorials]] provides some links to useful tutorials and general advice on creating quality music in the style that Wesnoth's music development team requires.

== Adding music to a Scenario or Campaign ==

* [[Available Music]] lists all the pieces which are already available to use in scenarios and campaigns, as well as providing some links to works in progress.
* [[MusicListWML]] has information on using the [music] WML tag to add music to a Wesnoth scenario.

[[Category:Create]]
[[Category:Music]]

Create Music

2008-02-25T03:51:27Z

Mesilliac: /* Adding music to a Scenario or Campaign */ add link to MusicListWML and brief link descriptions

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]]
* [[Tools for Creating Music]]
* [[Music Tutorials]]

== Adding music to a Scenario or Campaign ==

* [[Available Music]] lists all the pieces which are already available to use in scenarios and campaigns, as well as providing some links to works in progress.
* [[MusicListWML]] has information on using the [music] WML tag to add music to a Wesnoth scenario.

[[Category:Create]]
[[Category:Music]]

MusicListWML

2008-02-24T23:37:52Z

Mesilliac: add to Music category, add a link to Available_Music

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

This tag is a subtag of [scenario] and [event] which is used to describe a music track to play. You can repeat this tag as many times as you like; if you set the ''append'' tag to ''yes'' they will form a playlist from which tracks will be selected at random.

Tags describe the music track:
* ''name'' specifies the music file, relative to '"music/"'. This is compulsory.
* ''append=yes'' specifies this is to be added to the current playlist. Without this, the current playlist is replaced by this track.
* ''play_once=yes'' immediately switch to playing this track, but then return to the play list, which is unchanged.
* ''immediate=yes'' immediately switch to playing this track. Without this, the song will play when the entire [event] is over or the current song ends. This exists to force music changes '''during''' dialog exchange or other [event] which take significant time.
* ''ms_before'' (optional) specifies how many milliseconds to delay before playing this track. Currently this does not apply when the scenario first starts, or with ''play_once'' or ''immediate''.
* ''ms_after'' (optional) specifies how many milliseconds to delay after playing this track.

For a list of music tracks you can use in your scenario, see [[Available Music]].

=== Example ===
This creates a new playlist with three entries in it. The second track is always preceeded by 1/2 a second of silence.
[music]
name=background-music-1.ogg
[/music]
[music]
name=background-music-2.ogg
ms_before=500
append=yes
[/music]
[music]
name=background-music-3.ogg
append=yes
[/music]

[[Category: WML Reference]]
[[Category:Music]]

Create Music

2008-02-24T23:30:33Z

Mesilliac: remove "see also"

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]]
* [[Tools for Creating Music]]
* [[Music Tutorials]]

== Adding music to a Scenario or Campaign ==

* [[Available Music]]

[[Category:Create]]
[[Category:Music]]

Tools for Creating Music

2008-02-24T23:29:50Z

Mesilliac: remove

== Hardware ==

== Software ==
=== Non-Free ===
Pro-grade (thus quite costly) applications:
* [http://www.steinberg.net/983_1.html Cubase] Mac / Windows
* [http://www.apple.com/logicstudio/logicpro/ Logic Studio] Mac
* [http://www.cakewalk.com/Products/SONAR/default.asp Sonar] Windows
* [http://www.digidesign.com/index.cfm?navid=24&langid=100& ProTools] Mac / Windows
Less expensive alternatives:
* [http://www.cockos.com/reaper/ REAPER] Mac / Windows
* [http://www.flstudio.com/ FL Studio] Windows

=== Free ===
* [http://ardour.org/ Ardour] Linux

== Samples ==
=== Non-Free ===
=== Free ===
* [http://hosted.filefront.com/gtownsounds G-Town Percussion] Excellent orchestral percussion sounds.

* [http://www.northernsounds.com/forum/showthread.php?t=51293 Celtic Harp] Beautiful 250MB celtic harp soundfont (d/l links are in the thread; there's also a giga version available)

* [http://come.to/bovbjerg Soeren Bovbjerg's Pianos] A few pianos in sf2/gig format. Sound good considering their size.

* Very good clarinet by Mats Helgesson (the site requires registration):
** [http://www.sf2midi.com/index.php?page=sdet&id=7017 Maestro clarinet Legato]
** [http://www.sf2midi.com/index.php?page=sdet&id=6675 Maestro clarinet Breath]
** [http://www.sf2midi.com/index.php?page=sdet&id=6674 Maestro clarinet Staccato]

* [http://lesitedeburnie.free.fr/matshelgesson-maestro-en.html Maestro Concert Grand] 985MB concert grand piano by Mats Helgesson.

* [http://www.sf2midi.com/index.php?page=sdet&id=9337 Alex Glockenspiel] A nice little glockenspiel.

* [http://www.emulatorxone.com/free_emulator_x_sounds/free_emulator_x_sounds.htm EmulatorXone Trumpet] 60 meg solo trumpet in emulatorX format.

* [http://www.sf2midi.com/index.php?page=sdet&id=6050 Douglas Concert Timpani] Very good timpani freebie from Naturalstudio.

[[Category:Music]]

Music Tutorials

2008-02-24T23:28:53Z

Mesilliac: remove "see also"

== External Tutorials ==
* [http://northernsounds.com/forum/forumdisplay.php?f=77 Principles of Orchestration] Free online version of Nikolay Rimsky-Korsakov's "orchestration bible" complete with audio examples.
* [http://www.philharmonia.co.uk/thesoundexchange/the_orchestra/ Philharmonia Orchestra] An invaluable resource. I recommend everyone who wishes to learn more about the orchestra and its instruments to take a look at this site.
* [http://www.lynnemusic.com/phoenix-article.html Making orchestral music... without an orchestra] An insteresting insight into creating a virtual orchestra by composer Bjorn Lynne.
* [http://www.garritan.com/Orchestral_Simulation_Tutorial.html Improving Orchestral Simulation through Musical Knowledge] An article about making realistic orchestral simulations by Alan Belkin.
* [http://www.musique.umontreal.ca/personnel/Belkin/bk.o/index.html Artistic Orchestration] Another great and in-depth piece ny Alan Belkin.
* [http://www.shopjt3.com/midi_tips.html 10 tips for making your MIDI orchestrations sound real] The title says it all.
* [http://www.soundonsound.com/sos/dec99/articles/orchestral.htm CREATING REALISTIC SAMPLE-BASED ORCHESTRAL ARRANGEMENTS: PART 1] Old but very informative SOS article about sample-based orchestration.
* [http://www.paintingbynumbers.com/print/images/html/orchestral_manoeuvres.html ORCHESTRAL MANOEUVRES] Another good SOS article.
* [http://library.thinkquest.org/22673/orchestra.html The symphony orchestra] Some basic info about seating and instruments.
* [http://hyperphysics.phy-astr.gsu.edu/hbase/music/orchins.html Instrument data] Some technical data on orchestral instruments.
* [http://metmagazine.com/mag/sequencestration/index.html Sequence-stration] Another article about getting good results from MIDI orchestration.
* [http://www.prorec.com/Articles/tabid/109/EntryID/252/Default.aspx Using Advanced Orchestral Libraries] Some tips on... yeah, it's all in the title.
* [http://www.jerrygerber.com/soniccontrolinterview.htm An interview with Jerry Gerber] Uh... yep.
* [http://www.jerrygerber.com/unrealorchestra.htm The Unreal Orchestra] Interesting article about moive scoring by Jerry Gerber and Michael Prager
* [http://www.maartenspruijt.com/digitalorchestration.com/ Digital Orchestration.com] The personal site of composer Maarten Spruijt. A lot of good info on MIDI orchestration and music production.
* [http://www.classicalworks.com/html/glossary.html Glossary of Musical Terms] Might come in handy.

[[Category:Music]]

Available Music

2008-02-24T23:27:26Z

Mesilliac: remove "see also"

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3 COMPLETE

; "Knalgan Theme" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=18737 forum thread])
: http://www.allacrost.org/staff/user/rain/KnalganTheme.ogg COMPLETE

; "Tragedy" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The King is Dead" by Mattias Westlund (West) ([http://www.wesnoth.org/forum/viewtopic.php?t=18277 forum thread])
: http://www.soundclick.com/bands/default.cfm?bandID=754266&content=music (The King is Dead) COMPLETE

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y COMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

[[Category:Music]]

Available Music

2008-02-24T12:18:43Z

Mesilliac: /* Works in Progress */ typo

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3 COMPLETE

; "Knalgan Theme" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=18737 forum thread])
: http://www.allacrost.org/staff/user/rain/KnalganTheme.ogg COMPLETE

; "Tragedy" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The King is Dead" by Mattias Westlund (West) ([http://www.wesnoth.org/forum/viewtopic.php?t=18277 forum thread])
: http://www.soundclick.com/bands/default.cfm?bandID=754266&content=music (The King is Dead) COMPLETE

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y COMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

== See Also ==
* [[Create Music]]

[[Category:Music]]

Create Music

2008-02-24T12:16:06Z

Mesilliac: /* Creating Music for Wesnoth */ add FAQ link

{| style="float:right; margin-left:1em;"
|__TOC__
|}

== Getting Started ==
=== General Information ===
Musicians usually meet on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. This is the best place to discuss new music and potential contributions, as well as to hear what is currently being worked on.

Wesnoth's music is stored in the [http://www.vorbis.com/ Ogg Vorbis] format. This is similar to the MP3 format, only it is [http://www.vorbis.com/faq/#artist completely free]. The current music can be found in the "music" subdirectory of Wesnoth (see [[EditingWesnoth]] for details on Wesnoth's directory structure).

Music composed for Wesnoth should be orchestral with realistic sounding samples, and 3 to 6 minutes in length. Most of the pieces in the "Core Music" section of [[Available Music]] are good examples of this.

To be included in the Battle for Wesnoth, music must be released under the [http://www.gnu.org/copyleft/gpl.html Gnu General Public License]. Read [http://www.wesnoth.org/forum/viewtopic.php?t=2015 this forum post by Jetryl] for more information on this.

=== Where Should I Start? ===
The first thing any potential music contributor should do is read the [[Music Contribution FAQ]]. It outlines what Wesnoth's music development team is looking for in terms of contributions, and who is likely to be able to contribute work that will be accepted into the core Wesnoth distribution.

If after reading the [[Music Contribution FAQ|FAQ]] you believe you can contribute something to the project, introduce yourself on the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]. You will most likely be asked for a sample of your previous work, so if you can provide a link to one in your post it would be very helpful.

== Creating Music for Wesnoth ==

* [[Music Contribution FAQ]]
* [[Tools for Creating Music]]
* [[Music Tutorials]]

== Adding music to a Scenario or Campaign ==

* [[Available Music]]

== See Also ==
* [[Create]]
* [[Project]]

[[Category:Create]]
[[Category:Music]]

Available Music

2008-02-24T11:56:11Z

Mesilliac: my head hurts

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.

* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

; "Burin the Lost Theme" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19605 forum thread])
: http://www.tindeck.com/audio/my/lzce/Burin-the-Lost

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread])
: http://www.tindeck.com/audio/my/urih/Maabad16

; bluerc ([http://www.wesnoth.org/forum/viewtopic.php?t=19136 forum thread])
: http://neuron.fei.tuke.sk/~rockai/mp3/DruhaPiesenPreKatarinu.mp3

; jeanbrut ([http://www.wesnoth.org/forum/viewtopic.php?t=18835 forum thread])
: http://o.militon.free.fr/Morceaux/DragonVert1.mp3
: http://o.militon.free.fr/Morceaux/DragonVert2.mp3

; Tlogner ([http://www.wesnoth.org/forum/viewtopic.php?t=18364 forum thread])
: http://benyates.info/high%20seas%20for%20wesnoth.mp3
: http://benyates.info/forgottenwoods.mp3

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3 COMPLETE
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3 COMPLETE

; "Knalgan Theme" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=18737 forum thread])
: http://www.allacrost.org/staff/user/rain/KnalganTheme.ogg COMPLETE

; "Tragedy" by Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; "Flight of the Drakes" by [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; "The King is Dead" by Mattias Westlund (West) ([http://www.wesnoth.org/forum/viewtopic.php?t=18277 forum thread])
: http://www.soundclick.com/bands/default.cfm?bandID=754266&content=music (The King is Dead) COMPLETE

; "The City Falls" by Doug Kaufman ([http://www.wesnoth.org/forum/viewtopic.php?t=18775 forum thread])
: http://www.box.net/shared/5s01e0zd9y CVOMPLETE

; "Snowfall" by Jeremy Nicoll ([http://www.wesnoth.org/forum/viewtopic.php?t=18311 forum thread])
: http://www.gnexp.com/songs/snowfall.mp3

; "Orc Theme" by Aleksi Aubry-Carlson ([http://www.wesnoth.org/forum/viewtopic.php?t=6162 forum thread])
: http://aleksi.free.fr/Wesnoth/Gameplay%2006.ogg

== See Also ==
* [[Create Music]]

[[Category:Music]]

Available Music

2008-02-24T11:06:26Z

Mesilliac: starting to link music from the forums

A list of music tracks written for the Battle for Wesnoth.

== Core Music ==

These tracks are included in the official Battle for Wesnoth distribution, and are automatically available to any user-made scenario or campaign.



* "Battle Music" by Aleksi-Aubry-Carlson (battle.ogg)
* "Breaking the Chains" by Mattias Westlund (breaking_the_chains.ogg)
* "Defeat" by Timothy Pinkham (defeat.ogg)
* "Defeat" by Ryan Reilly (defeat2.ogg)
* "Elf Land" by aleksi-Aubry-Carlson (elf-land.ogg)
* "Elvish Theme" by Doug Kaufman (elvish-theme.ogg)
* "Frantic" by Aleksi-Aubry-Carlson (frantic.ogg)
* "The Knolls of Doldesh" by Timothy Pinkham (knolls.ogg)
* "Legends of the North" by Mattias Westlund (legends_of_the_north.ogg)
* "Loyalists" by Joseph G. Toscano (Zhaytee) (loyalists.ogg)
* "Main Menu" by Aleksi Aubry-Carlson (main_menu.ogg)
* "Main Theme" by Aleksi Aubry-Carlson (main_menu_new.ogg)
* "Northerners" by Aleksi Aubry-Carlson (northerners.ogg)
* "Revelation" by Joseph G. Toscano (Zhaytee) (revelation.ogg)
* "Traveling Minstrels" by Mattias Westlund (traveling_minstrels.ogg)
* "Underground" by Aleksi Aubry-Carlson (underground.ogg)
* "Vengeful Pursuit" by Jeremy Nicoll (vengeful.ogg)
* "Victory" by Timothy Pinkham (victory.ogg)
* "Victory" by Ryan Reilly (victory2.ogg)
* "Still Another Wanderer" by Timothy Pinkham (wanderer.ogg)

== Available Music for Campaign Authors ==

These tracks have not been accepted for mainline inclusion, but campaign authors are free to include them in their campaigns. As they are not part of the official Battle for Wesnoth distribution, campaign authors will need to include the .ogg files in their campaign package.

(need to search the forums a bit to populate this)

== Other Potential Contributions ==

These were indicated by the author to be potential contributions to the Battle for Wesnoth, but their use has not been explicitly allowed and they have not yet been released under the GPL. The authors of these pieces may agree to release them under the GPL if someone has a use for them. In this case, try to contact the author directly.

; barisium ([http://www.wesnoth.org/forum/viewtopic.php?t=19536 forum thread]) : http://www.tindeck.com/audio/my/urih/Maabad16

== Works in Progress ==

These pieces are still being worked on, or have not been declared as finished. The author may welcome constructive criticism and would most likely welcome encouragement or praise. If you intend to use these in a campaign, it would be polite to let the author know of your intention, as they might not wish for their work to be used until it is complete.

This list is unlikely to be regularly updated. The best place to check out the music that is currently being developed for Wesnoth is the [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

; Joseph G. Toscano (Zhaytee) ([http://www.wesnoth.org/forum/viewtopic.php?t=16105 forum thread])
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_fanfare.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_lovetheme.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_newtruths.mp3
: http://zhaymusic.com/music/mp3/gpl/zhaytee-wesnoth_tragedy.mp3

; Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=18737 forum thread])
: http://www.allacrost.org/staff/user/rain/KnalganTheme.ogg

; Rain ([http://www.wesnoth.org/forum/viewtopic.php?t=19600 forum thread])
: http://www.allacrost.org/staff/user/rain/WesnothTragedy5.mp3

; [PA]NotUncleDave ([http://www.wesnoth.org/forum/viewtopic.php?t=19362 forum thread])
: http://www.tindeck.com/audio/my/azxe/Flight-of-the-Drakes

; marcusvinicus ([http://www.wesnoth.org/forum/viewtopic.php?t=20002 forum thread])
: http://www.4shared.com/file/38438486/d3ac5c39/sinf1.html

; Mattias Westlund (West) ([http://www.wesnoth.org/forum/viewtopic.php?t=18277 forum thread])
: http://www.soundclick.com/bands/default.cfm?bandID=754266&content=music (The King is Dead)

== See Also ==
* [[Create Music]]

[[Category:Music]]