The Battle for Wesnoth Wiki - User contributions [en]

EventWML

2010-08-13T16:03:29Z

Absh1us: /* [event] */

{{WML Tags}}
== The [event] Tag ==

This tag is a subtag of the [scenario], [unit_type] and [era] tags which is used to describe a set of actions which trigger at a certain point in a scenario. When used in a [scenario] tag (also includes [multiplayer], [tutorial] and [test]), the event only occurs in that scenario. When used in a [unit_type] tag, the event will occur in all scenarios in which a unit of that type appears in (only after such a unit appears during the scenario, however). When used in an [era], the event will occur in any scenario which is played using that era.

This tag has keys and child tags that control when and if the event actions will be triggered. Most important of these is the '''name''' key. Without it, no error will be raised but the event will never fire. Therefore, from a practical standpoint, it can be considered mandatory. All of the others can be used or not and the event actions will fire either way.

'''Lexicon side note:''' ''The word "event" in the [event] tag itself may be considered an abbreviation of the word "event handler" because it is technically not a game "event" but an event '''handler''' for the game events fired with the given 'name'. However, this distinction is usually unimportant in most discussions and the event handlers are therefore simply referred to as "events" in this documentation.''

=== The 'name' Key (Mandatory) ===

Usage:
name=<value>

This key defines which game event or trigger your [event] tag will be handling. This 'name' key should not be confused with a descriptive comment; it is rather a precise value which must match the predefined game event's name to be valid.

'''Lexicon side note:''' ''It is not uncommon to refer to these values as the 'trigger' for an event and, furthermore, to call an event by its 'trigger' name. For example, in an event containing '''name=moveto''', a person might refer to the event as a ''''moveto''' event' and/or refer to the ''''moveto''' trigger' in the event or even talk about the 'event trigger' when referring to the '''moveto''' value of the 'name' key in that event. Some or all of this usage can, in fact, be found throughout this page.''

The '''name''' key can accept a list of comma separated values describing when the event will be triggered.* These values may be either predefined event types or custom event names not matching any predefined type.

For example:

name=attacker misses,defender misses

''* Note that unless you use [[#first_time_only|first_time_only=no]], the event will fire only once, '''not''' once for each listed type.''

==== Predefined 'name' Key Values ====

All predefined event types are listed here along with a description of when this value will cause the event to be triggered. Any value ''not'' listed here is a custom event name which can be triggered only by a '''[fire_event]''' tag somewhere else. Spaces in event names can be interchanged with underscores (for example, '''name=new turn''' and '''name=new_turn''' are equivalent).

; preload
: Triggers before a scenario 'prestarts' and when loading a savegame -- before anything is shown on the screen at all. Can be used to set up the [[LuaWML|Lua]] environment: loading libraries, defining helper functions, etc.
: '''Note:''' Unlike prestart and start, the preload event '''must be able to fire more than once!''' This is because it is triggered each time a savegame is loaded in addition to the initial time when it loads before the scenario 'prestart'. This means that it is effectively ''mandatory'' to have the [[#first_time_only|first_time_only=no]] key value in a preload event.

; prestart
: Triggers before a scenario 'starts' -- before anything is shown on the screen at all. Can be used to set up things like village ownership. For things displayed on-screen such as character dialog, use '''start''' instead.
: '''Note:''' ''This value makes the [[#first_time_only|first_time_only]] key irrelevant since, by definition, it can only fire once.''

; start
: Triggers after the map is shown but before the scenario begins -- before players can 'do' anything.
: '''Note:''' ''This value makes the [[#first_time_only|first_time_only]] key irrelevant since, by definition, it can only fire once.''

; new turn
: Triggers at the start of every turn (not side turn). See also [[#first_time_only|first_time_only=no]]. Before any events of this type trigger, the value of the WML variable '''turn_number''' is set to the number of the turn that is beginning.

; side turn
: Triggers when a side is about to start its turn. Before events of this type trigger, the value of the WML variable '''side_number''' is set to the number of the side of the player about to take their turn. This is before any healing takes place for that side, before calculating income, and before restoring unit movement and status.

; ai turn
: Triggered just before the AI is invoked for a side. This is called after ''side turn'', and thus the WML variable '''side_number''' still holds the number of this side. Note that this event might be called several times per turn in case that fallbacks to human or droiding is involved. I.e. it happens at the middle of turn of human side 1 if the human player droids his side. It happens after the selection of ai to play the turn but before AI is told that new turn has come.
: '''Note:''' ''This event currently breaks replays since it is not explicitly saved in a replay and there is no AI involved in replays...''

; turn refresh
: Like '''side turn''', triggers just before a side is taking control but '''after''' healing, calculating income, and restoring unit movement and status.

; turn ''X''
: Triggers at the start of turn ''X''. It's the first side initialization event. Side initialization events go in the order of:
: 1) '''turn ''X''''' 2) '''new turn''' 3) '''side turn''' 4) '''side ''X'' turn''' 5) '''side ''X'' turn ''Y''''' 6) '''turn refresh'''

; side ''X'' turn ''Y''
: This event triggers at the start of turn ''Y'' of side X {{DevFeature}}

; side ''X'' turn
: This event triggers at the start of any turn of side X {{DevFeature}}
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''

; side X turn Y refresh
: This event triggers at the turn refresh for side X on turn Y {{DevFeature1.9}}

; side ''X'' turn refresh
: This event triggers at the turn refresh for side X {{DevFeature1.9}}
: '''Note:''' ''Of course, [[#first_time_only|first_time_only=no]] is needed for this event to be triggered more than once.''

; time over
: Triggers on turn ''turns''. (''turns'' is specified in [scenario])

; enemies defeated
: Triggers when all units with '''canrecruit=yes''' (that is, all leaders) not allied with side 1 are killed.

; victory
: In this scenario, any tag of the form '''[endlevel] result=victory [/endlevel]''' will be automatically preceded by all actions in this tag. It helps debugging if the victory event allows you to safely advance to any of the possible next maps after using the ":n" command. Scenarios where key units are picked up before the victory, or where some action chosen earlier determines which map to advance to, make it hard to quickly test scenarios in a campaign. (See also: [endlevel], [[DirectActionsWML]])

; defeat
: In this scenario, any tag of the form '''[endlevel] result=defeat [/endlevel]''' will be automatically preceded by all actions in this tag. (See also [endlevel], [[DirectActionsWML]])

Filters can be applied to the following event triggers (see [[FilterWML]]; see also below). The actions specified in the event tag will be executed only if the filter returns true.
These event triggers are all actions by units ('''moveto''', '''attack''') or things that happen to units ('''recruit''', '''advance'''). When one of these events is triggered, the position of the active unit (referred to as the '''primary unit''') is stored in the variables '''x1''' and '''y1''' and the position of any unit that primary unit does something to is stored in the variables '''x2''' and '''y2''' (this unit is referred to as the '''secondary unit''' below). '' These units are also automatically stored in the variables 'unit' and 'second_unit' as if they had been stored using the '''[store_unit]''' tag. see [[SingleUnitWML]]

; moveto
: Triggers after the primary unit moves. Typically this is used when the primary unit gets to a particular location and a filter for the location of the primary unit is included; remember that this is the location that the primary unit lands on, not the location it started on or any location it travels on.<br />''An '''[allow_undo]''' tag anywhere within a moveto event will cancel any lack of undo functionality the event would have caused. Note that undo functionality will only move the unit back to its former location; it will not undo other changes to the game caused by the event. Thus it is up to the scenario designer to use this tag correctly.'' {{DevFeature}} $x2 and $y2 refer to the hex the unit came from.

; sighted
: Triggers when the primary unit becomes visible to the secondary unit in particular after not being visible to the secondary unit's side (so if the secondary unit's side doesn't have shroud or fog, the event never triggers). This happens both when the primary unit moves into view during its turn, and when the secondary unit moves to a location where it can see the primary unit. (This editor hasn't tested whether the event triggers multiple times if the primary unit moves into view of multiple units at once, or if not, which one gets chosen to be the secondary unit here.) (Note: it appears that when a sighted event is triggered because an enemy unit moves into your field of view, the game engine cannot determine which unit (on your side) sees the unit that moved, and so it fires a ''name=sighted'' event without setting ''$second_unit''. This means that, for example, using ''speaker=second_unit'' inside a message tag may fail.) (Double note: it also appears that the sighted event in more recent versions of the game (1.6 and 1.7, maybe?) does not fire on enemy turns. That is, it only fires for units that become visible as a result of the motion of another unit, not for units that move into the vision of an enemy. This event is also buggy in general... it's usually better to use a moveto event with a [filter_vision] tag than to use a sighted event (and note that the combination of the two can achieve something like the old sighted event)).

; attack
: Triggers when the primary unit attacks the secondary unit.

; attack end
: Similar to '''attack''', but is triggered ''after'' the fight instead of before. Note that if either unit is killed during the fight, this event triggers before any '''die''' events.

; attacker hits
: Triggers when the the primary unit (the attacker) hits the secondary unit (the defender). The value of the WML variable '''damage_inflicted''' is set to the number of hitpoints inflicted by the attacker.

; attacker misses
: Same as ''attacker hits'', but is triggered when the attacker misses.

; defender hits
: Triggers when the primary unit (the attacker) is hit in retaliation by the secondary unit (the defender). The value of the WML variable '''damage_inflicted''' is set to the number of hitpoints inflicted by the defender.

; defender misses
: Same as ''defender hits'', but is triggered when the defender misses.

; stone
: Triggers when the primary unit is hit by an attack with the 'stones' ability (See ''stones'', [[AbilitiesWML]]) by the secondary unit (the unit with the 'stones' ability). In {{DevFeature}}, this event name is changed to "petrified".

; last breath
: Triggers when the primary unit is killed by the secondary unit, but before the death animation is triggered. Use this instead of name=die when you want the primary unit to make a final [message].

; die
: Triggers when the primary unit is killed by the secondary unit. ''Note: The primary unit is not removed from the game until the end of this event. The primary unit can still be manipulated, will block other units from taking its hex, and will still be found by standard unit filters (except [have_unit]). To prevent this behavior, you can use [kill] to remove the unit immediately. However, this will stop any (still unfired) other events that also match the unit from firing afterwards, so use with caution.'' If you want to the primary unit to make a final [message], use name=last_breath, see above.

; capture
: Triggers when the primary unit captures a village. The village may have been previously neutral, or previously owned by another side; merely moving into your own villages does not constitute a capture.

; recruit
: Triggers when the primary unit is recruited. (That is, when a unit is recruited it will trigger this event and this event's filter will filter that unit.).

; prerecruit
: Triggers when the primary unit is recruited but before it is displayed.

; recall
: Triggers after a unit is recalled.

; prerecall
: Triggers when a unit is recalled but before it is displayed.

; advance
: Triggers just before the primary unit is going to advance to another unit.

; post advance
: Triggers just after the primary unit has advanced to another unit.

; select
: Triggers when the primary unit is selected. Also triggers when ending a move, as the game keeps the moving unit selected by selecting it again at the end of movement. ''Note: in networked multiplayer, these events are only executed by the client on which the event is triggered, leading to out of sync errors if you modify the game state in the event.''

; menu item ''X''
: Triggers when a WML menu item with id=''X'' is selected. ''Note: if the menu item has a [command], this event may be executed before or after the command; there is no guarantee.''

==== Custom events ====

An event with a custom name may be invoked using the [[InternalActionsWML#.5Bfire_event.5D|[fire_event]]] tag. Normally you'll use such custom events as named subroutines to be called by events with predefined types. One common case of this, for example, is that more than one '''sighted''' events might fire the same custom event that changes the scenario objectives.

=== Optional Keys and Tags ===

These keys and tags are more complex ways to filter when an event should trigger:

==== first_time_only ====
: Whether the event should be removed from the scenario after it is triggered. This key takes a [[ConditionalActionsWML#Boolean_Values|boolean]]; for example:
: ''first_time_only=yes''
:: Default behavior if key is omitted. The event will trigger the first time it can and never again.
: ''first_time_only=no''
:: The event will trigger every time the criteria are met instead of only the first time.

==== [filter] ====
: The event will only trigger if the primary unit matches this filter.
:* [[StandardUnitFilter]]: selection criteria

==== [filter_second] ====
: Like [filter], but for the secondary unit.
:* [[StandardUnitFilter]]: selection criteria

==== [filter_attack] ====
: Can be used to set additional filtering criteria for the primary unit and the secondary unit that are not generally available in a standard unit filter. Can be used in events ''attack'', ''attacker hits'', ''attacker misses'', ''defender hits'', ''defender misses'' and ''attack end''. For more information and other filter keys, see [[FilterWML]].
:* '''name''': the name of the weapon used.
:* '''range''': the range of the weapon used.
:* '''special''': filter on the attack's special power.

==== [filter_second_attack] ====
: Like [filter_attack], but for the secondary unit.
:* '''name''': the name of the weapon used.
:* '''range''': the range of the weapon used.
:* '''special''': filter on the attack's special power.

==== [event] ====
: A special case 'action', the [event] tag may be used to create a [[#Nested Events|nested event]].

[http://www.california-liability-insurance.com/ Liability Insurance CA]

==== delayed_variable_substitution ====
: This key is only relevant inside of a [[#Delayed Variable Substitution|nested event]] and controls when variable substitution will occur in those special case actions.

=== Actions triggered by [event] ===

After the trigger conditions have been met, all action tags within the [event] tag are executed in the order they are written in.

There are 3 main types of actions:
* direct actions ([[DirectActionsWML]]) which have a direct effect on gameplay
* display actions ([[InterfaceActionsWML]]) which show something to the user
* internal actions ([[InternalActionsWML]]) which are used by WML internally

Several actions use standard filters to find out which units
to execute the command on. These are denoted by the phrases
"standard unit filter" and "standard location filter".

=== Nested Events ===

There is one special type of action: event creation. By placing an '''[event]''' tag inside another '''[event]''' tag, the nested event is spawned (created) when the parent (outer) event is encountered (when executing the contents of the parent event).

([[#Nested Event Example|See Examples]])

==== Delayed Variable Substitution ====

Variable substitution for a nested event can happen either when it is spawned by the parent event or when it is triggered itself. This is controlled with the key '''delayed_variable_substitution''' which is used in the nested event.

If this key is set to ''yes'', the variables in the nested event will contain values from the turn in which the ''nested'' event was triggered. ''This is the default behavior if the key is omitted.'' If set to ''no'', the variables in the nested event are set at the time the ''parent'' event is triggered.

This behavior can be fine tuned with a special syntax when referencing variables. Instead of the normal '''$variable''' syntax, use '''$|variable''' to cause a variable to contain values relevant to the turn in which the nested event was triggered even when '''delayed_variable_substitution''' is set to ''no''. In this way you can have a mix of variables relevant to the parent and nested event trigger times.

([[#Delayed Variable Substitution Example|See Examples]])

== Multiplayer safety ==

In multiplayer it is only safe to use WML that might require synchronization with other players because of input or random numbers (like [message] with input or options or [unstore_unit] where a unit might advance) in the following events. This is because in these cases WML needs data from other players to work right and/or do the same thing for all players. This data is only available after a network synchronization.

List of synchronized events:
* moveto
* sighted
* attack
* attack_end
* attacker hits
* attacker misses
* defender hits
* defender misses
* stone
* last breath
* menu item X
* die
* capture
* recruit
* prerecruit
* recall
* prerecall
* advance
* post_advance
getting message options (etc) from the following events is not synchronized, except in the development version (1.9+svn):
* new turn
* side turn
* turn X
* side X turn
* side X turn Y
* turn refresh

There is also the possibility of events that are normally synchronized when fired by the engine but can be non-synchronized when fired by WML tags from non-synchronized event. So when you are using them you must be extra careful. For example [unstore_unit] may trigger a unit advancement that will fire ''advance'' and ''post advance'' events.

== A Trap for the Unwary ==

It is perfectly possible (and, in fact, useful) to have multiple events with the same predefined name and thus the same trigger condition. However, it is not defined what order such events will fire in, so you need to code so the order
will not matter.

Because of the above, you need to beware of using macros to generate events. If you include a macro expanding to an event definition twice, the event will be executed twice (not once) each time the trigger condition fires. Consider this code:

#define DOUBLE
[event]
name=multiply_by_2
{VARIABLE_OP 2_becomes_4 multiply 2}
[/event]
#enddef

{DOUBLE}
{DOUBLE}

{VARIABLE 2_becomes_4 2}

[fire_event]
name=multiply_by_2
[/fire_event]

{DEBUG_MSG "$2_becomes_4 should be 4"}

After it executes, the debug message will reveal that the variable has been set to 8, not 4.

== Miscellaneous Notes and Examples ==

=== Primary/Secondary Unit Speaker Example ===

In events, the primary unit can be referred to as '''unit''' and the secondary unit can be referred to as '''second_unit''' in [message] tags using the '''speaker''' key. For example:

[event]
name=die
[message]
speaker='''second_unit'''
message= _ "Hahaha! I finally killed you!"
[/message]

[message]
speaker='''unit'''
message= _ "It's not over yet! I'll come back to haunt you!"
[/message]
[/event]

=== Nested Event Example ===

An event is created for a portal that opens on turn 10. The parent (or 'outer') event executes on turn 10 at which point the nested moveto event is created. This nested event executes when a player steps on a certain spot.

[event]
name=turn 10

[event]
name=moveto

[filter]
x,y=5,8
[/filter]

# moving to 5,8 will trigger this event only on turn 10 and after
[/event]
[/event]

An equivalent way of doing this would be to create a single moveto event with an '''[if]''' statement to check for turn number but using nested '''[event]''' tags is a convenient shortcut to accomplish this task without resorting to '''[if]''' statements.

=== Delayed Variable Substitution Example ===

This code will display a message showing the turn number on which the nested ''moveto'' event happens.

[event]
name=turn 10

[event]
name=moveto
delayed_variable_substitution=yes

[filter]
x,y=5,8
[/filter]

{DEBUG_MSG "Turn $turn_number"}
[/event]
[/event]

Since this is the default behavior for the '''delayed_variable_substitution''' key, the following example is identical.

[event]
name=turn 10

[event]
name=moveto

[filter]
x,y=5,8
[/filter]

{DEBUG_MSG "Turn $turn_number"}
[/event]
[/event]

The following code will always display "Turn 10" when the nested ''moveto'' event happens. This is because the variable substitution is done when the parent event is triggered and spawns the nested event, ''not'' when the nested event is triggered.

[event]
name=turn 10

[event]
name=moveto
delayed_variable_substitution=no

[filter]
x,y=5,8
[/filter]

{DEBUG_MSG "Turn $turn_number"}
[/event]
[/event]

Finally, the following example is identical to the first two in that it will display a message showing the turn number on which the nested ''moveto'' event happens, despite the fact that the '''delayed_variable_substitution''' key is set to ''no''. This is because the special '''$|variable''' syntax is used.

[event]
name=turn 10

[event]
name=moveto
delayed_variable_substitution=no

[filter]
x,y=5,8
[/filter]

{DEBUG_MSG "Turn $|turn_number"}
[/event]
[/event]

=== Multiple Nested Events ===

Every delayed_variable_substitution=no causes a variable substitution run on the subevent where it occurs at the spawn time of this event and on all following subevents. For any specific event, variable substitution happens at least one time when the event is executed. For each delayed=no key appearing in itself or in an event of an "older" generation, which is not the toplevel event, an additional variable substitution run is made.
[event]# parent
name=turn 2
#delayed_variable_substitution=no # In the parent event, delayed= has no effect.

[event]# child
name=turn 3
delayed_variable_substitution=no # Causes variable substitution in the child, grandchild and great-grandchild event
# at execution time of the parent event = spawn time of the child event.

[event]# grandchild
name=turn 4
delayed_variable_substitution=yes # no variable substitution in the grandchild and great-grandchild event
# at execution time of the child event = spawn time of the grandchild event

[event]# great-grandchild
name=turn 5
{DEBUG_MSG $turn_number}# output: 2 - value from the variable substitution at execution time of the parent event,
# caused by delayed=no in the child event

{DEBUG_MSG $||turn_number}# output: "$turn_number"
# Each variable substitution transforms a "$|" to a "$" (except when no | left).

{DEBUG_MSG $|turn_number}# output: 5 - from the variable substitution at execution time
# of the great-grandchild event
[/event]
[/event]
[/event]
[/event]

== See Also ==

* [[DirectActionsWML]]
* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[FilterWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

AdvancedTactics

2010-08-13T16:01:15Z

Absh1us: /* Zone of Control (ZoC) */

{|align="right"
|-
|__TOC__
|}
This page assumes that the reader has read [[GettingStarted]] and is familiar with the [[WesnothManual]].
It assumes you have played enough games to be familiar with the system,
and know how to push units around, and are now looking for insight in how to
outthink the AI or a human opponent.
Some tactics are only useful in specific circumstances and would be foolish at other times.
Pick and choose those that fit your particular style.
Do you overwhelm your opponent with sheer numbers, or a few well-chosen
high-level units? Do you prefer to "roleplay" one race?
Do you want to play many scenarios, or replay one over and over until you achieve the perfect game?

=== Strategy ===

==== Strategy Before Tactics ====
Tactics relate to move-by-move decisions relating to the units on the map. When tactics are not related to a sound strategy, they may be sometimes overcome by a weaker or less tactically advanced force which is better able to craft such a strategy.

In general, before you begin a scenario or battle, you should survey the map. The following considerations are important:

* Areas where your forces can/cannot move quickly
* Areas where your forces have defensive advantages
* Areas where your opponents' forces can/cannot move quickly
* Areas where your opponent has a defensive advantage.
* Size of the map (larger maps stress scouting and mobility while smaller maps stress close fighting more.

Often maps will have areas where opposing forces will have to cross slow terrain (such as a river) and be vulnerable except for small channels (such as a bridge or a ford), Because it is difficult to mount an attack across these choke points, they can be controlled with fewer units while the rest of the army is elsewhere. Once you have a full flow plan relating to where you want to hold the enemy and where you want to overrun, you can proceed to the next step.

==== Broad Opening Strategy Categories ====

Depending on the size of the map, the distance between you and your nearest opponent, amd mobility considerations you may want to decide to open make your initial opening stress a specific competency of your force. In general these can be divided into the following categories:

* Scouting Game. In this case, one recruits a large number of scouts in order to control as many villages as possible as soon as possible. This works best in large maps where the distance to the nearest opponent is quite large. Scout games tend to end up being large army games where all sides amass substantial numbers of units.
* Formation Game. In this case one recruits slower moving heavier fighters followed by more mobile forces. The goal here is to have a line which can withstand an initial attack solidly and then have other, swifter forces enter the battle to overrun the enemy. For example, a line of spearmen could have horsemen behind them, so that the horsemen get to attack enemy troops which have already been wounded in the fight with the front-line. This is a specialized form of leap-frogging (see below) where the relief troops actually expect to break through the opponent's line. This is most effective on small maps or where the distance to the nearest opponent is small.
* Vanguard Game. This strategy is somewhere between the above strategies. In this case, heavy, fast moving troops are recruited first (for example a combination of knights and horsemen or dragoons and cavalry). These forces advance rapidly and then hold an area long enough for heavier infantry to arrive. The original vanguard can then retreat to heal if necessary. This is most effective on mid size maps.

=== Tactics ===

==== Fight unfair ====
From Sun Tzu to "Shock and Awe", military writers have stressed that
one must not enter into a conflict unless substantially stronger
than your enemy. In Wesnoth, this means
* more units
* better (stronger, higher level) units, and
* superior healing ability in your second line.

In general, a good rule to follow is 3-1. If you can fight with three times the power, you can overrun your opponent quickly. A smaller numerical advantage can allow you to create focused points where that ratio exists.

Napoleon was especially skilled at manoeuvring his forces so as to gain an
advantage even when outnumbered. By attacking his enemy in the centre, he broke
their lines and divided the enemy forces in two. Then, a small detachment
fortified their position and held off one flank, while Napoleon's main
force attacked the now outnumbered other half. After reducing the
first half, the main force would rejoin the flank-holders and destroy the
remaining half. (This strategy is known as "defeat in detail".)

To implement this in Wesnoth, leave a few units with many hit points
in favourable terrain on one flank, while the majority of your force
attacks on a different front.
For example, two red and one white mage, or three paladins.
By combining healers and the healing effect of villages,
a small force can hold off superior numbers for a very long time.

==== Feints ====
You can misdirect the AI (and a surprising number of human opponents)
by sending a few units towards an objective like an enemy leader, village,
or bridge. They will overreact and position their units badly.
Similarly, you can send fast units behind the enemy lines to capture villages.
Do not attempt to hold them; instead move onto the next while the enemy diverts
front line troops or reinforcements.
Flying units are particularly adept at this since they ignore terrain.
Sometimes a feint can turn into your main offensive as well,
if the enemy calls a bluff and ignores your feinting units.

Against human opponents, remember to guard against this kind of tactic. If you see an enemy mounting an attack that doesn't seem to make sense, then it's likely to be a diversion. This doesn't mean that you should ignore it, however - instead, try to counter and contain the attacking force until your opponent's plan becomes clearer, but do not use your entire army - you might wipe out several enemy units, but that won't help you if another detachment corners your leader without support.

==== Bounding (or leap frog) ====
Every strategist throughout history warns to "keep a reserve".
In Wesnoth, this means that you must not attack with all your units.
Instead, hold back units to exploit holes caused by your initial attacks.
Or, you might need to move a fresh unit with many hit points to the
front line so they can 'take a beating' and hold your lines.

In modern times, the "reserve" concept has been expanded as follows.
Divide your main force into two groups, and attack with the first
while holding the second back. When the first group is chewed up,
withdraw it to healers or villages, while you attack with the second group.
This approach allows you to distribute experience more evenly among your units,
particularly useful in a longer campaign.
However, if you need the higher-level units, selecting which units deliver a fatal blow levels units faster.
This way, you are less likely to lose units with higher exp,
resulting in more units succeeding in levelling up.

Do not use high level units, and definitely not your commander,
to guard the healers or villages, as the enemy might focus on them instead,
and attack the wounded seeking aid.

Sometimes, if it is a favourable time of day, you can quickly achieve victory
with an all-out assault. If the enemy is clearly weaker than you, or the conditions are right, this can be an effective
strategy. Most of the time, however, commanders are advised to use other, more elegant strategies.

==== Small and strong ====
Develop a small core group of high level units. Recall a strike force
for one or two turns, then move off in a tight pack.
Most should be level 2, with a few level 3 units to hold the flanks or
commit in the 2-3 most decisive rounds.
With this strategy, you'll need fewer villages to provide income,
and thus be less distracted with acquiring them.

Remember to recruit level 1 units to absorb the enemy's first attacks,
as well as for feints and holding unimportant villages.
Allow those that survive to finish off dying enemy units to replace
any of your core group that make the final sacrifice.
In other words, since some of your levelled units are expected to die,
you need to level up new units to replace them.

==== Advanceable vs Non-advanceable Units ====
In general you want as much experience to go to advanceable units as possible. However, units which are no longer capable of advancing further can be of great help in specific circumstances including:

* Holding strategic terrain while the bulk of the army is elsewhere.
* Softening up opponents before they can be taken out by other, advanceable forces.
* Skirmisher units, advancible or not, are extremely useful for attacking choke points because they can help break up an opposing army quickly.
* Rescuing vulnerable but important troops (shamans, white mages, etc) from overwhelming opposition.

==== Hit Point Conservation ====
Hit points are a units only non-renewable resource.
Choose the attack which causes your unit the least damage,
not deals out the most to the enemy.
For example, assume you are attacking a unit that does 6-3 close combat,
and has no range attack.
Your unit has a 4-4 close combat and a 3-3 range attack.
Consider the tactical situation carefully.
Do you need to kill the unit this turn?
Is it on a village or next to a healer?
Do not automatically accept the computer's recommendation
(it is simply the attack likely to do the most
damage, regardless of how much you take!).

Remember, when a unit levels up, it regenerates its full HP allowance and heals.

Finally, attacking an enemy leader, especially in a castle,
is an expensive proposition, even if you use magical attacks.
Expect to lose units while wearing down its hit points.

==== Using the Level-Up ====
When mopping up at the end of a scenario, try to balance the experience so that several units are close to their next level. It is better to start the next scenario with lower-level units that are about to level than with those same units at a higher level. This way, you save 1 gold for every turn between recalling a unit and when it levels up. You can also use these units (along with some level-1 fodder) as the first assault with the promise that they will regenerate full hit points and become stronger attackers when they do level-up. Using the power of the level-up to it's full potential can significantly improve your odds of finishing scenarios quickly and without having any units die.

All units, even those at their max level, heal now when they reach their full experience. However, an At Max Level Advancement (AMLA) usually only provides +3 hitpoints and a heal; not nearly as useful as a regular level up. This is why it is usually better to give experience to your lower-level units.

==== The Spearhead Principle - a dangerous gamble ====
A blunt stick is unlikely to penetrate any defense whatsoever - its power is spread across too wide an area. But a sharpened spear can break through defences far more easily, because its energy is all focused onto a single point. This also applies on a strategic level - in most, though not all, circumstances, it is more useful to inflict massive damage on a small part of the enemy line, rather than spreading your forces thinly to attack every point at once.

This can take much more planning than is immediately obvious - study the battlefield and the enemy's deployment well before attempting a 'spearhead' maneuver. Then, when the light is about to become favourable for you (or bad for your enemy, if your troops are neutral), attack fast, moving as many hard-hitting troops as possible into the smallest possible area (this is a variation on Napoleon's 'defeat in detail' strategy, outlined above). Look carefully at the terrain, and decide on an area to focus on.

If you have the manpower, you should try to surround this entire area with light, fast, expendable troops - they don't need to fight, but you should try to have a complete Zone-of-Control net around your chosen theater of battle. Your objective is then very simple - you are attempting to wipe out every enemy unit in that area, before the light changes. Do not let any enemy escape, they will heal in a village and come back into the fight. When the light starts to change, or earlier if you have already broken the enemy, move your entire force together (except for the scouts), along the enemy line to destroy one flank of their army. Use your scouts to harass and contain units on the other flank, try to keep them in one place until your main force can reach them and overwhelm them.

With sound tactics and moderate luck, you should now have destroyed most of the enemy force, with few losses of your own. Several units are likely to advance while doing this - these troops, and any that are close to advancing, should then be used to hunt down and kill the enemy leader and whatever forces he or she has left.

Be aware, however, that this is a risky strategy - if you are unlucky, poorly-prepared, or your enemy mounts a strong counterattack, it is likely that your troops will be bogged down and slowly wiped out - or, even worse, confined by scouts, while your enemy's main force simply marches around them to kill your leader. This kind of tactic can win you a game in a few turns - but it can lose it just as easily, if not executed well.

=== Weapon specialties ===
==== Backstab ====
{{Quote|
|quote="Thieves are deft of foot, and elusive, making them difficult to hit. Being skilled at backstabbing, thieves do double damage when attacking an enemy that has an ally of the thief on its opposite side. Being of chaotic disposition, thieves fight better at night than during the day."
|source=Thief description
|}}

Assassins, Nightgaunts, Rogues, Shadows and Thieves can backstab.
A Thief costs 13 gold and has base attack of 4-3. But with a backstab,
it does an impressive 8-3, the equivalent of most Level 2 units.
Backstabbing at night with a Strong Thief does 12-3.
After 24 Experience Points, they level up to a Rogue doing 6-3 base...

You don't have to ''attack'' with another unit to get the backstab
bonus -- there just needs to be a unit on the opposite side of the enemy.
The ally can even move after the backstab, if it didn't use up its moves
by moving into the enemy's Zone of Control this turn.
Thieves work well in pairs against weak or unsupported units.
They can surround a unit and attack it turn after turn.

It's often effective to use units with backstab in pairs, so that each
provides the bonus to the other. This is especially effective with
Shadows, due to their good movement rate. Keep one or two such pairs
around your flanks to ambush lone scouts and village-stealers.

==== Slow ====
Shamans, being slow, weak, and of limited firepower, need to be
used carefully, but don't dismiss their offensive ability.
Their Slow attack can cripple strong enemy units by effectively halving their damage.

Of course this tactic is even more useful for your higher-level units:
Druids, Shydes, the Sorceress line, and Goblin Pillagers, because they can more reliably slow the enemy unit and are more likely to survive a counterattack (especially from additional unslowed units).

You can also keep a unit that slows the enemy in your attack force, to slow down
a wounded enemy unit that wishes to escape, or to cripple their attacks at the
beginning of your attack, then proceed to use fighters that will take less damage
from the halved attacks.

==== Healing and Curing ====
Move your healers in pairs so that you retain the
freedom to use them in combat when appropriate without having to retire
to a village afterward.
Remember the difference between healing and curing, put your better healers
where they will be more needed.

Don't forget that with a Curing unit nearby, you needn't fear poison.
An assassin's darts are only a serious threat if they can poison an unsupported unit.
Your Druid or White Mage will cure the poison before it has time to work,
(However, they cannot remove damage from a unit on the same turn they cure
poison from that unit). and they can cure poison from ''every'' adjacent unit -
irrespective of damage they have to heal.

==== Poison ====

When using poisonous units (Ghouls, Orcish Assassins, Assassins), your goal should be to distribute their poison attack among as many units as possible, rather than concentrating on a single enemy. Units that are already poisoned should be a low priority for your other units' attacks as well, unless they can score a kill.

Don't underestimate the usage of poison against regenerating units, or units in a village or next to a curer. While the healing will remove the poison, it does so in lieu of healing hit points. Repeated poisonings can prevent these (often tough or hard-to-hit) units from recovering while your other units whittle them down.

Against units with high defense or high evasion, poison can help a lot to weaken them, since you just have to hit them once, then they will take damage(until healed) every turn, no matter how many times you hit them or how much damage they take from your attacks. After they are weak, just a lucky hit could kill them.

It also helps if lawful units are poisoned at the end of an attack during the night by chaotic units. It is risky to chase chaotic units with poisoned lawful units during the day, which could force them to retire and lose their chance to attack during their most favorable time of the day.

==== Swarm ====

When a unit's attack is listed as "swarm", the number of attacks per round is based on its current fraction of maximum health. That is to say, if a unit with swarm is at 3/4 health, it will only do 3/4 of its maximum attacks. This does not affect the damage of each attack.

If you are the owner of such a unit then keeping it in good health should be your top priority. If you are facing a swarmer, the best idea is to poison it and then avoid it as they are usually high level monsters. As of 1.1.1 using "slow" on these units is very effective as it halves their movement speed, making avoiding them while the poison works easier. Once they are at low health, move in for the kill.

(From the manual - Henkutsu_tama)

=== Recruiting ===

Remember that your commander may recruit units when standing on ''any'' Keep tile,
not only the one you start on. If you have two enemies, where one is some
distance beyond the other (like in 'The Siege of Elensefar'), you recruit enough
units to take out the first enemy Commander (and possibly hold off the second
enemy's front troops), then you move onto the slain Commander's Keep, and
recruit the units you need to take out the remaining opposition.
This saves you money in the long run, and keeps your Commander closer
to the action so he may level up sooner.

If there are several enemies with significant difference in their strength
of arms, first concentrate on the weakest, or else the one with the
highest income potential.
Move your Commander along with your troops, and after you have wiped
this enemy out, use their Castle as your new base.
This has the added benefit of protecting your Commander, often a target
of enemy troops, so you don't need to recruit units only for protecting him,
while your main force is engaged somewhere else.
In the end, this will save you lots of gold.
Such tactics are essential on maps with many opponents,
for example against the AI on multiplayer map 'Dwarven Doors'.

==== Plan placement of units ====
Place recruited and recalled units manually.
Choose the best castle tile for a unit to be placed by clicking on the
tile before recruiting or recalling.
This way you can often capture villages a turn earlier,
or move units to critical map squares before your opponent.

For maps with narrow passages leading out of the castle
(like Bay of Pearls or some of the random underground maps in
Heir to the Throne), recruit or recall pairs of slow and fast units.
Both units in such a pair will then be able to use their maximum
movement without impeding each other. So recruit an Elvish Fighter
together with a Horseman, or even an Elvish Fighter with an Elvish Archer.

==== Unit Choice ====
* Some units, such as Orcish Grunts or Horseman, have no ranged attack. Take advantage of this by using units that are skilled in both melee and ranged, such as Elvish Rangers, so that your opponent will be helpless when you are attacking, and you will not be at a disadvantage when you defend. The same goes for units with no melee attack, such as Dark Adepts.
* When a battle is raging, use fast-moving units (your scouts) to distract the enemy by sneaking past enemy troops and conquering enemy villages, cutting off their gold supply or sometimes forcing them to split up their armies.
* If a battle occurs at a river or some other narrow pass, it can be beneficial to use skirmishing units such as Duelists to easily cross the river and surround your opponent or use airborne units like Gryphons to use the river squares without being at a great disadvantage.
* If you need to cross a large body of shallow water, mountains, cave floor, or other difficult terrain, use units whose moves are divisible by their movement on such terrain so moves don't go to waste. For example, if a unit takes three moves to get through one water tile, make sure it has three, six, or nine movement. Recalling 'quick' units can help ensure you've chosen the right ones. If you recall a unit with five movement points, they will only be able to move one hex per turn in terrain that requires three movement points, while a similar unit with six movement points can move two hexes per turn.
* Units such as Elvish Fighters that are cheap to produce in mass and that have both decent melee and ranged attacks can often be good for holding your front lines, since they will cause harm to their opponents no matter what they are. A front line of horsemen, on the other hand, is not good for holding a position, for they are costly, fall quickly to enemy archers, and probably will never be able to strike back.

=== Know the Battlefield ===

==== Reconnaissance - Know the Map ====
While attack is influenced by the time of day, defense is affected
by terrain. First find all the castles and note the different kinds
of terrain immediately surrounding them. If you're playing under
Shroud, send out two or three scouts to locate the castles.
This is also often worth it on Fog of War, because you learn
what faction your enemy is (if you don't know already) and
how defended their castle is. Expect to recruit more when they die.
The knowledge they provide is worth more than their cost.

==== Survey - Know the Terrain ====
Take an overall look at the size of each terrain type and note which
are the most important.
This affects what units to select and their overall effectiveness.
Then examine whether the main terrain is evenly
distributed, scattered, or in a few large areas.
Note what terrain you want to avoid and why.
Mountains and deep water are bad for all but a few unit types.
These act as walls which the opponents can use to trap you:
of course, you can do likewise to your opponents. If you have
saved some of your starting gold, you can also decide which units will
be better for reinforcements based off a more common terrain.

==== Transport - Know the Pathways ====
Try to link advantageous terrain areas together in your mind
from where your units are (your castle at start of play)
to opposing ''and'' friendly castles. Use villages scattered between
you and the target to influence the route to take, especially if you
can't recruit any healing units.
Decide which terrain is most favourable for your units and
less favourable for the enemy.
If your goal is to reach an object or hex, then do the same for that.

If one route proves difficult, switch to another. Get to know
which routes work best for different units and locate meeting
places to regroup units.
Try to keep the opponents guessing what you're going to do next.
By using several adjacent routes to a target, the opponents
will have a tougher time stopping your advance.
In some cases it is easier to send a main group directly towards
the target and use fast units to circle around behind.

==== Features - Know the Traps ====
Note carefully where favourable terrain on either side of
unfavourable reach their closest point. These are defense positions
for you to ambush approaching opponents (with or without a thief) and
provide protection for friendly units. Sometimes the terrain forms
passages for units to pass through quickly. Check whether it takes
fewer turns to move around slow terrain than through it.
In slow terrain, it is tougher to encircle units and immobilise them,
so drive them toward better suited terrain (using ZoC, see elsewhere)
and encircle there.

==== Distance - Watch the Time ====
Use caution when setting up your front line and advancing immediately, as often the time of day will be exactly in its least advantageous point right when you meet your enemies. If you wait a few turns just passing the time by capturing nearby villages and meet the enemy at First Watch/Dawn, respectively, you can cut down the majority of the enemy's army before they can do anything about it. Also, if you find yourself in a evenly matched or losing position during your worst part of the day it can be ideal to fall back to villages or simply hold tight without attacking the enemy, as you want the battle to progress as slowly as possible during this part of the day. (Note: If you have units that can attack at no risk [mages to trolls, for example] don't waste their actions, keep on fighting no matter what.)

==== Intelligence (part one) - Know your Enemy====
Remember to check the hit points, movement and attacks of all enemies, before rushing into combat. It's also a good idea to check the description of each new type of enemy unit, before attacking. Some units have unusual resistances, defense values or movement costs - do not assume that every unit is exactly what it looks like. This is particularly important if you are facing enemies of several different races, the classic example being Drakes and Saurians - Drakes are very tough, but have poor defense and are vulnerable to cold and piercing weapons, so you might reasonably recruit an army of archers and cold-using magicians, with a few high-powered attacks. But Saurians are much faster and very fragile, with excellent defense in almost any terrain - so you might find yourself wishing for fast cavalry to pursue them, and units with a high number of attacks to guarantee at least a few hits. The same applies to any other enemy - make sure you know exactly what you're dealing with, before entering battle.

==== Intelligence (part two) - Know Yourself====
Always be aware of what forces are available to you. Whenever you gain the ability to recruit a new unit, read the description and look carefully at its stats. If you find yourself using only two or three types of units (a perfectly good strategy, if it works), it is easy to forget that there are others available to you. When you meet an enemy which your existing troops are poorly-equipped to fight, you should (almost) always have something that will be effective - the key is to know what, and to use it at the right time and in the right way. An extension of this, is to become familiar with the individual units that you have recruited (especially in a campaign) - the system of traits means that there can be a lot of variation, even between units of the same type and these different units should be assigned different roles. Strong, resilient units are good for front-line fighting or defending strongpoints, while quick units are better used as scouts or to outflank the enemy (especially quick mounted troops, since most units will not be able to force them into a fight). Intelligent units should be sent wherever they are needed, but it is often best to keep them away from heavy fighting (firstly, because they need less experience to advance, which means they do not need to kill as many enemies, and second, because they give you a better chance of getting a higher level unit - but only if they survive.)

=== Zone of Control (ZoC) ===

The Zone Of Control allows you to build artificial barriers at will.
With it, you can reduce the likelyhood that a weaker, injured unit will
be killed, by reducing the number or kind of enemies that can reach it.
It is hard to measure who has Movement Control because it depends
on where the units are positioned more than how many there are.
Although this is a tactical device, it is more strategically
significant than tactical because Zone of Control applies before
and after encounters, rather than during. Establishing and maintaining
good Zones of Control gives you better mobility and control over most other
aspects of the game, even against stronger units less well positioned.

Your units influence space beyond the hex they're standing on.
The total area of influence includes the hexes adjacent to the units
and ''this'' is the Zone Of Control. When strong opposing units
approach your weaker ones, pay particular attention to the ZoC
and terrain types. Combine the ZoC of your units to form a solid barrier.
Your goal is to rearrange your units such that the opponent's attack
occurs where your units are well positioned defensively and at the worst
time of day for opposing units.
Check that none of your units can be attacked by more than two enemy units
''and'' that no enemy unit can pass between them.
In this case, you spread your units out, extending your ZoC and forcing
the enemy to select one or more targets.
[http://www.california-liability-insurance.com/ Liability Insurance CA]

In most cases, the opponent will target one unit. You should
ensure that each of your units is within the ZoC of at least two others.
So when the enemy hits one unit, you can close in (encircle, encircle...)
until reinforcements arrive. It is often as important to hold a ZoC
as it is a village or passage.

While ZoC isn't very important against slow moving units, it is
very effective against fast ones, such as horsemen, bats, ghosts,
and wolf riders. The approach to handling these is assign two or
three of your fastest units, target one long range opposing unit
and spread yours out defensively between its target (usually villages)
and itself in a semi-circle or line. Move these units toward the enemy
so that it has increasingly less space to move. When it is within your ZoC,
encircle and kill. Move on to the next long range unit and repeat.

After the first round (when everyone has recruited), all the units are
grouped, so try to create a ZoC against all of the long range units
as quickly as you can. In this way you can prevent them from
spreading out, while you systematically encircle and kill each one.
Since the opponent won't have occupied enough villages, there is a
good chance all you'll have left are short range units to deal with.

Under FoW and Shroud, it is impossible to know what the opponent has
recruited, but it is good practice to check your ZoC around your villages
so you are not surprised by a sudden invasion. Early on, long range
units are used to occupy villages, so the sooner you engage them,
the less villages they can possess. Creating a ZoC quickly around
unoccupied villages allows you to possess them at your leisure and keep them.

Another use in ZoC is deciding when and where battles will be fought.
If the opponent moves into your ZoC, but positioned near unfavourable
attack terrain, you have several choices. Either attack anyway,
which is mostly bad, wait for the opponent to attack on its next turn,
which gives it the choice of target, or move your units out of its ZoC
to favourable terrain. You can check how far forward the units can move
and place guard units to maintain your ZoC and centralise the others
behind and protecting the guards. This forces the opponent to commit
and gives you time to prepare a tactical counter-attack. Keep your
guards guarding! If the ZoC crumbles your units will be overwhelmed.

The ZoC is effective when wounded units need to pass through hostile areas.
Rather than closing in, form a large circle around the wounded presenting
a much wider perimeter.
This makes it harder for opposing units to attack all yours and allows you
to keep healthy units within the ZoC and leap-frog when needed.

On approaching an opponent's castle, ZoC can be critical to your success.
In some scenarios events are triggered when you occupy hexes directly next
to a castle hex. Make sure the approaching units keep their distance from the
castle, but within their ZoC. When assembled, move directly on to the castle.

For skirmishing units who ignore ZoC, you have little choice but to build a solid
wall of units. Alternatively, you may make a ZoC to block the typical units and
prepare a welcoming party for the skirmishers.

In a campaign scenario, where the objective is to move a unit to a certain point
on the map (often specified by a signpost) you can use more unimportant units
and ZoC by placing them a space or two away from your leader and a space apart
from each other, since in battle units can quite suddenly die, and you don't want
that one to be your leader.

==== Encirclement ====
The encircling tactic by two units is very powerful, particularly against long range units. By placing two units on either side, you limit the opposing unit to 1 hex move in any direction. When the unit sidesteps in the following turn, you can re-encircle.
This means you can hold the unit until reinforcements arrive and then adopt a
leap-frog approach against very strong units.

=== Retreating ===

Sometimes the battle doesn't go your way. Either you battle to the last unit, or
retreat. The purpose of retreating is to regroup your units more effectively and
give them time to heal. Retreating can be organised with a reverse leap-frog
approach, where you give ground, encouraging the opponent to push forward.
Now your healers are in front and moving toward better terrain
where you can make a final stand.

Being prepared for, and knowing when to retreat, is also important.
Too often a player tries to retreat, but has no reinforcements to halt the retreat.
Try to leave a "safe zone" on a flank, protected by ZoC, where you can pull back.

The real problem with retreating is putting distance between your units and the
opponents. If they can move faster than yours, you may have to setup a ZoC to
last long enough for you to get your slow units to safety. Invisibility units
are the best because they cannot be seen and will take the opponent valuable
turns to find them. Once the group is safe, they can slip away unnoticed.
Sometimes sending out a unit or two as a kamikaze works to slow them down -
if the exp they gain matters less to them than saving more of your units does to you.

====Day-night cycle retreat====

Usually on a 1vs1 map there is some space between your villages and your opponents villages. Depending on the map and speed of your units, the distance is 1-2 turns.

The idea of retreating starts with your own attack. You are stronger during your preferred time of day, so you march forward and your opponent retreats (lets take aside the matchups where both factions have the same preferences).

As drakes, you normally start marching at dawn. You move into the free area, your enemies retreat. First day is the critical turn. Ideally you should be able to attack the enemy's villages now. Maybe your party is not complete because of some slower units and you are therefore not strong enough yet (that is what your opponent hopes for and will try to arrange). If so, you've only got one turn for your attack, else it is two turns. At dusk you pull back your units.

Starting from the enemies villages, he will need at least one turn (dusk) to cross the free area, maybe two until he can start his attack. Nevertheless you might have to decide if you keep the village or let him take it for one or two turns. It usually depends on how sure you can be that the unit holding the village will survive. If the enemy's got magic, chances are normally low. In that case you should leave the village open, otherwise your unit will die without having an advantage.

However, if you play this a little smart, it will only be one village in question and only for one or at most two turns. Remember, that 1 turn costs you a net loss of 4 gold per lost village (2 less for you and 2 more for your enemy). But 4 gold is a lot less than a lost unit.

When dawn comes, you get the village back. If the enemy is stupid enough to stay you will crush him into pieces during the day cycles.

Even if you don't want to attack it is essential to occupy the space between villages in order to delay the enemy when his preferred time comes.

<noinclude>=== See Also ===

* [[GettingStarted]]
* [[WesnothManual]]
* [[PlayingOrcs]]
* [[How to play Undead]]
* [[BestForumStrategies]]
* [[CampaignStrategies]]
* [[Advanced Tactics (Russian)]]
* [[Advanced Tactics (French)]]
* [http://wesnoth.fsf.hu/?q=node/164 Haladó taktikák (Hungarian)]
</noinclude>

[[Category:Playing Wesnoth]]

Create Art

2010-08-13T16:00:40Z

Absh1us: /* See Also */

{| 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=2014 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
* [[Portrait Tutorial]] - a guide on how to draw unit/character portraits by Kitty.
* 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
** [[Vector Inking]] - vector techniques, including mouse-only, for inking your sketches
** [[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.
* [[Team Color Shifting]] - how to create art that uses our new team color system.
* [[TeamColoring]] - how to automatically team-color sprites to see what they look like in various colors.
* [[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]]
* [[Fire Animation]] - a great guide to creating fire FX by rhyging5

=== 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.
* [http://www.california-liability-insurance.com/ Liability Insurance CA]

[[Category:Art Tutorials]]

StartingPoints

2010-08-13T16:00:14Z

Absh1us: /* Other */

__NOTOC__

What would you like to learn about Wesnoth in this wiki? [[Play]] it, [[create]] with it, [[support]] for it, examine the [[project]], view [[credits]] of it.

This is a page with starting points to exploring this wiki about The Battle for Wesnoth. In addition to the wiki, there's also a [http://www.wesnoth.org homepage], a [http://www.wesnoth.org/forum forum], and a [http://gna.org/projects/wesnoth/ Gna project page].

* [[Special:Categories|List of all page categories in this wiki]]
* [[Special:Allpages|List of all pages in this wiki]]

== Getting the Game ==
==== Downloading ====
* [[Download]] - get the most recent source-files and many binaries
** [[WesnothBinaries]] - precompiled for GNU/Linux, BeOS, PDAs, ...
** [[WesnothBinariesLinux]] - precompiled for many GNU/Linux distributions

==== Compiling ====
* [[CompilingWesnoth]] - on Unix, Mac, Windows, GNU/Linux, PDAs, ...
* [[UsingSourceinstall]] - using GNU Source Installer to automate installation and upgrades from source (Unix-likes only)
* [[DebuggingWesnoth]] - on GNU/Linux and Unix-like systems
* [[WesnothOnLinuxPDAs]] - on the Qtopia/OPIE and thepdaXrom/Zaurus C series

== Playing the Game ([[Play]]) ==

==== For New Players ====
* [[GettingStarted]] - read me first!
* [[WesnothManual]] - the rules
* [[MainlineCampaigns]] - walkthroughs for the game-supplied campaigns

==== For Not-So-New Players ====
* [[AdvancedTactics]] - beating the AI and other people
* [[MultiplayerServers]] - where to play against other people online
* [[Replays]] - archive of replays new and old
* [[How to play...]] - learn more about various faction vs faction strategies

==== Reference ====
* [[HotKeysSystem]] - keyboard shortcuts
* [[CommandMode]] - commands you can use in-game
* [[ServerAdministration]] - commands that authenticated users can use to administer the server
* [http://units.wesnoth.org/ Units] - Units advancement trees and stats
** [http://units.wesnoth.org/1.4/ Stable version]
** [http://units.wesnoth.org/trunk Trunk version]
* [[Races]] - [[Drakes (race)|Drakes]], [[Dwarves]], [[Elves]], [[Humans]], [[Orcs]], [[Undead (race)|Undead]], etc.
** [[Factions]] - all major factions, mainline and user-made
* [[Wesnoth_Acronyms_and_Slang|Wesnoth Acronyms and Slang]] - common wesnothian acronyms and slang explained
* [[Maps]] - 1v1 default

== Tweaking the Game ([[Create]]) ==
==== Scenarios & Campaigns ====
* [[UserScenarios]] - user-written scenarios, campaigns and game modifications
* [[Wesnoth UMC Dev]] - where you can do collaborative UMC development
* [[BuildingCampaigns]] - how to make your own single player campaigns
* [[MultiplayerCampaigns]] - how to make your own multiplayer campaigns
* [[BuildingScenarios]] - how to make your own scenarios
* [[BuildingUnits]] - how to make your own units
* [[UnitAnalysis]] - tool to analyze units

==== References ====
* [[ReferenceWML]] and [[AlphabeticalWML]] - all about Wesnoth Markup Language
* [[ReferencePythonAPI]] - upcoming Python interface for AI
==== Tools & Utilities ====
* [[ExternalUtilities]] - scripts to help create scenarios, campaigns, and graphics
* [[WesnothMapEditor]] - summary of controls
* [[CustomizingStartup]] - some tweaks for optimizing the game's startup&performance

==== Art related ====
* [[Create_Art#Art_Tutorials|Art Tutorials]] - help in creating art
* [[GraphicLibrary]] - unit and terrain images posted on the forums
* [[Tiles_Status]] - terrain tiles: proposed and in progress.

== Improving the Game ==
* [[ReportingBugs]] - use Gna!
* [http://www.wesnoth.org/wiki/ReportingBugs#Guidelines_for_suggesting_features Guidelines for suggesting features] - To submit a feature request, use http://bugs.wesnoth.org
==== Developer information ====
* [[DeveloperResources]] - useful links
* [http://changelog.wesnoth.org Changelog] - the most recent changes made to the game
* [[WesnothSVN]] - accessing the source code
* [[HackingWesnoth]] - guide for programmers
* [[CodingStandards]] - for programmers
* [[DeveloperGuide]] - for those who received SVN commit rights
* [http://www.wesnoth.org/units/trunk/animations.html Missing unit animations] - what's available and what's missing
* [[WritingYourOwnAI]] - write a C++ plugin
* [[FormulaAI]] - Guide to the experimental formula AI branch
* [[ThemeSystem]] - customizing the screen layout for the game and the editor
* [[ReleasingWesnoth]] - steps to follow to release a new version
* [[WesnothPackagersGuide]] - guidelines for packaging Wesnoth for different platforms
* [[EasyCoding]] - Bugs and features that are easy to implement for new coders
* [[NotSoEasyCoding]] - Bugs and features which are doable but lacking someone working on them
* [[WesnothGL]] - Guide to programming the Wesnoth OpenGL branch
* [[WesnothdDesign]] - Guide to the design of wesnothd, the multiplayer server.

==== Game translations ====
* [[GettextForTranslators]] - how to translate Wesnoth under [[GetText]]
* [[WesnothTranslations]] - completely unknown stats...
* [[WesCamp]] - a project for translating user-made campaigns

== About the Game ==
* [[WesnothPhilosophy]] - Dave on Wesnoth
* [[History of Wesnoth]] - the Ages of Wesnoth
* [[Geography of Wesnoth]] - description of Wesnoth and surrounding lands
* [[WesnothFigures]] - notable figures of valorous and infamous deeds in Wesnoth
* [[WesnothReviews]] - third party reviews of Wesnoth
* [irc://irc.wesnoth.org/wesnoth #wesnoth] - our IRC channel
* [[Trailer]] - the Wesnoth trailer

== Other ==
* [[UsefulLinks]]
* [http://en.wikipedia.org/wiki/Battle_for_Wesnoth Wikipedia entry for Wesnoth]
* [http://www.california-liability-insurance.com/ Liability Insurance CA]
* [[WikiHaiku]]

== About this Wiki ==
* [[Help:Editing|Editing]] - learn how to edit pages
* [[Sandbox]] - experiment with the wiki
* [[WikiMigration]] - we were looking for a replacement for our old wiki (and ended up using Mediawiki)
* [http://www.wesnoth.org/forum/viewtopic.php?t=19462 Obsolete] - help in updating the wiki for v1.4

[[Category:Wesnoth Wiki]]