Difference between revisions of "BuildingScenariosSimple"
(→Second part: links to macros) |
(→First part) |
||
Line 15: | Line 15: | ||
[scenario] | [scenario] | ||
− | id= | + | id=01_test-1 |
− | next_scenario= | + | next_scenario=02_test-more |
name=A Simple Test Scenario | name=A Simple Test Scenario | ||
− | map_data="{campaigns/Test_Campaign/ | + | map_data="{@campaigns/Test_Campaign/maps/testmap}" |
turns=20 | turns=20 | ||
Line 61: | Line 61: | ||
* The value of the <code>next_scenario</code> attribute is the <code>id</code> (see above) of the scenario that is played after this one is won. Units from this scenario will be available for recall (unless you modify the recall list, but that's stuff for later). If your scenario is not part of a campaign, or if this is the last scenario you should either skip this line or put <code>next_scenario=null</code> inside the file. This will tell the game to display the ''End'' screen when this scenario is won. | * The value of the <code>next_scenario</code> attribute is the <code>id</code> (see above) of the scenario that is played after this one is won. Units from this scenario will be available for recall (unless you modify the recall list, but that's stuff for later). If your scenario is not part of a campaign, or if this is the last scenario you should either skip this line or put <code>next_scenario=null</code> inside the file. This will tell the game to display the ''End'' screen when this scenario is won. | ||
− | * The value of the <code>name</code> attribute is shown on the introduction screen before each scenario is played (this may contain a picture of a map or anything else you fancy. See [[BuildingScenariosIntermediate]] for an explanation on how to do that). It's also the default | + | * The value of the <code>name</code> attribute is shown on the introduction screen before each scenario is played (this may contain a picture of a map or anything else you fancy. See [[BuildingScenariosIntermediate]] for an explanation on how to do that). It's also used to generate the default names of saved files for the level. |
− | * The next attribute, <code>map_data</code>, is a | + | * The next attribute, <code>map_data</code> is a little tricky. Normally, the map data (the text that is used to generate a map) goes directly inside of the quotation marks. However, it is often useful to keep that map data in a separate file, and then include that file (still inside the quotation marks) using a [[PreprocessorRef|preprocesser]] command. The code <code>{@campaigns/Test_Campaign/maps/testmap}</code> does just that, telling the wesnoth engine to look in the file <code>campaigns/Test_Campaign/maps/testmap</code> for the map data. The <code>@</code> symbol tells wesnoth to search for the map file in both the ''userdata'' directory and the ''gamedata'' directory (see [[EditingWesnoth]] and [[PreprocessorRef]] for more information). You can create and edit map files using wesnoth's built-in [[Editor2|map editor]] (see [[BuildingMaps]] for more information). |
* Finally, the last attribute in the top set of keys is <code>turns</code>. This is the number of turns a player is given to finish the scenario (it can be changed during the game, but again, that is stuff for later). If the player fails to finish the scenario in the given time, he has lost (''i.e.,'' the ''defeat'' event is triggered. See [[EventWML]] for more.) | * Finally, the last attribute in the top set of keys is <code>turns</code>. This is the number of turns a player is given to finish the scenario (it can be changed during the game, but again, that is stuff for later). If the player fails to finish the scenario in the given time, he has lost (''i.e.,'' the ''defeat'' event is triggered. See [[EventWML]] for more.) | ||
Line 72: | Line 72: | ||
The <code>music</code> attribute takes for its value the name of a music file (see [[MusicListWML]] for more). This file must be in the <code>music/</code> directory and <b>must</b> be in [http://en.wikipedia.org/wiki/Ogg Ogg] format. | The <code>music</code> attribute takes for its value the name of a music file (see [[MusicListWML]] for more). This file must be in the <code>music/</code> directory and <b>must</b> be in [http://en.wikipedia.org/wiki/Ogg Ogg] format. | ||
− | A tag you'll get to know very well when making scenarios is <code>[event]...[/event]</code>. <code>event</code> tags are used to describe what should be done when various sorts of ''events'' take place. The specific type of event is stated in the <code>event</code>'s <code>name</code> attribute. In this case we're describing the so-called <code>prestart</code> event. This event occurs just ''after'' all the introduction screens for the scenario have been shown but just ''before'' the | + | A tag you'll get to know very well when making scenarios is <code>[event]...[/event]</code>. <code>event</code> tags are used to describe what should be done when various sorts of ''events'' take place. The specific type of event is stated in the <code>event</code>'s <code>name</code> attribute. In this case we're describing the so-called <code>prestart</code> event. This event occurs just ''after'' all the introduction screens for the scenario have been shown but just ''before'' the map itself is displayed. This prestart event is used to set the scenario's objectives, i.e. the contents of the ''Scenario Objectives Dialog'' that will appear once the scenario begins. The purpose of the Scenario Objectives Dialog is to inform the player what must be accomplished to win the scenario and what circumstances bring about defeat. These winning and losing circumstances are defined using the <code>[objectives]</code> tag (N.B. that <code>objectives</code> is plural). Further, each circumstance is defined in its own <code>[objective]</code> (N.B. the singular here) tag with winning circumstances setting <code>condition</code> to <code>win</code>, and with losing circumstances setting it to <code>lose</code>. In the example above, <code>objectives</code> states victory to be "Defeat Enemy Leader". For defeat, however, <code>[objectives]</code> gives the player ''two'' possibilities: either "Death of Konrad" or "Turns run out" (any number of either winning or losing <code>[objective]</code> tags may be given). Accordingly, the Scenario Objectives Dialog will look vaguely like: |
<table border=1><tr><td> | <table border=1><tr><td> | ||
Line 87: | Line 87: | ||
</td></tr></table> | </td></tr></table> | ||
− | Note that <code>[objectives]</code> doesn't define the circumstances of victory or defeat to the game engine. It merely tells player what they are. | + | Note that the <code>[objectives]</code> tag doesn't define the circumstances of victory or defeat to the game engine. It merely tells the player what they are. Special victory or defeat conditions will have to be coded into the scenario using various [event]s. |
− | The <code>side</code> attribute in <code>[objectives]</code> indicates that the conditions defined here by the <code>[ | + | The <code>side</code> attribute in <code>[objectives]</code> indicates that the conditions defined here by the <code>[objective]</code> tags are for the faction or alliance ''side 1'' alone (see below). In a single-player game, side 1 would usually indicate the player's faction or alliance). The underscore ("_") facilitates translation using [[GetText|Gettext]]. |
== Second part == | == Second part == |
Revision as of 22:02, 13 March 2009
Learning things step by step
Here we will show you a very simple scenario file and explain each line of it. The file is not fully functional, but it will show the basics needed to describe what a scenario is all about.
Before reading this, it might prove useful to read something about the syntax of the Wesnoth Markup Language: SyntaxWML
First part
[scenario] id=01_test-1 next_scenario=02_test-more name=A Simple Test Scenario map_data="{@campaigns/Test_Campaign/maps/testmap}" turns=20 {DAWN} {MORNING} {AFTERNOON} {DUSK} {FIRST_WATCH} {SECOND_WATCH} music=wesnoth-1.ogg [event] name=prestart [objectives] side=1 [objective] description= _ "Defeat Enemy Leader" condition=win [/objective] [objective] description= _ "Death of Konrad" condition=lose [/objective] [objective] description= _ "Turns run out" condition=lose [/objective] [/objectives] [/event]continued below
↓ ↓ ↓
Every scenario must be enclosed in a tag; the [scenario]
tag is used for campaign scenarios. The first set of attributes in the scenario tag describe the very basics of this scenario:
id
(short for identifier) is the computer's name for your scenario and is not displayed during the game. However, it will be used to display game statistics (they will be graphed at http://stats.wesnoth.org in numerical order, so it's also a good idea to give theid
's a number). This name is also referenced in other tags and files, e.g., inside a[campaign]
tag using thefirst_scenario
attribute (see BuildingCampaignsTheCampaignFile) or inside a[scenario]
tag using thenext_scenario
attribute (see below).
- The value of the
next_scenario
attribute is theid
(see above) of the scenario that is played after this one is won. Units from this scenario will be available for recall (unless you modify the recall list, but that's stuff for later). If your scenario is not part of a campaign, or if this is the last scenario you should either skip this line or putnext_scenario=null
inside the file. This will tell the game to display the End screen when this scenario is won.
- The value of the
name
attribute is shown on the introduction screen before each scenario is played (this may contain a picture of a map or anything else you fancy. See BuildingScenariosIntermediate for an explanation on how to do that). It's also used to generate the default names of saved files for the level.
- The next attribute,
map_data
is a little tricky. Normally, the map data (the text that is used to generate a map) goes directly inside of the quotation marks. However, it is often useful to keep that map data in a separate file, and then include that file (still inside the quotation marks) using a preprocesser command. The code{@campaigns/Test_Campaign/maps/testmap}
does just that, telling the wesnoth engine to look in the filecampaigns/Test_Campaign/maps/testmap
for the map data. The@
symbol tells wesnoth to search for the map file in both the userdata directory and the gamedata directory (see EditingWesnoth and PreprocessorRef for more information). You can create and edit map files using wesnoth's built-in map editor (see BuildingMaps for more information).
- Finally, the last attribute in the top set of keys is
turns
. This is the number of turns a player is given to finish the scenario (it can be changed during the game, but again, that is stuff for later). If the player fails to finish the scenario in the given time, he has lost (i.e., the defeat event is triggered. See EventWML for more.)
The next section is a group of macros which will be processed by Wesnoth's preprocesser. Macros are essentially WML shortcuts. They allow you to define certain pieces of code which can be re-used whenever they are needed. Wesnoth provides you with a whole series of standard, pre-written macros to make life easier, but you yourself can write them too (again, stuff for later).
Let's get back to this example! The macros listed above describe how a day in this scenario will progress. The list of macros above is the normal day used throughout Wesnoth. If you want the entire scenario to take place at night, remove all the macros except for {SECOND_WATCH}
. Doing this might, for example, be useful if you've set Konrad to fight the Undead and also want the Undead to have the upper hand throughout the scenario. Remember, though, by setting this to a single time of day rather than the normal diurnal progression shown above, your scenario will effectively take place during one day (or night) rather than across many days as most scenarios do.
The music
attribute takes for its value the name of a music file (see MusicListWML for more). This file must be in the music/
directory and must be in Ogg format.
A tag you'll get to know very well when making scenarios is [event]...[/event]
. event
tags are used to describe what should be done when various sorts of events take place. The specific type of event is stated in the event
's name
attribute. In this case we're describing the so-called prestart
event. This event occurs just after all the introduction screens for the scenario have been shown but just before the map itself is displayed. This prestart event is used to set the scenario's objectives, i.e. the contents of the Scenario Objectives Dialog that will appear once the scenario begins. The purpose of the Scenario Objectives Dialog is to inform the player what must be accomplished to win the scenario and what circumstances bring about defeat. These winning and losing circumstances are defined using the [objectives]
tag (N.B. that objectives
is plural). Further, each circumstance is defined in its own [objective]
(N.B. the singular here) tag with winning circumstances setting condition
to win
, and with losing circumstances setting it to lose
. In the example above, objectives
states victory to be "Defeat Enemy Leader". For defeat, however, [objectives]
gives the player two possibilities: either "Death of Konrad" or "Turns run out" (any number of either winning or losing [objective]
tags may be given). Accordingly, the Scenario Objectives Dialog will look vaguely like:
A Simple Test Scenario
|
Note that the [objectives]
tag doesn't define the circumstances of victory or defeat to the game engine. It merely tells the player what they are. Special victory or defeat conditions will have to be coded into the scenario using various [event]s.
The side
attribute in [objectives]
indicates that the conditions defined here by the [objective]
tags are for the faction or alliance side 1 alone (see below). In a single-player game, side 1 would usually indicate the player's faction or alliance). The underscore ("_") facilitates translation using Gettext.
Second part
So far so good! The last necessary part describes what the players (both human and
computer) start with, what they can do, and what they can't do. Each of the players is described in a [side]
tag with the word side referring to a player's faction, band, or horde.
↑ ↑ ↑
continued from above[side] side=1 controller=human team_name=2 user_team_name= _ "Konrad's forces" type=Commander description=Konrad canrecruit=yes recruit=Elvish Fighter,Elvish Archer,Horseman,Mage,Elvish Shaman {GOLD 100 50 0} {INCOME 10 5 0} [/side] [/scenario]
Above you can see a sample [side]
for the human player, Konrad. The first group of attributes in the [side]
tag pertains to the side generally:
side
: the leader of this side is placed on the tile represented by this digit (see BuildingMaps). It's a number from 1 to 9.controller
takes either of two possible values:human
orai
(i.e., artificial intelligence, meaning your computer). If you don't specify this attribute,ai
is the default.team_name
describes which team the side is on. It defaults to the same number asside
, but setting it to2
allies this side with side 2 (if you haven't changed theteam_name
of side 2).user_team_name
is the name displayed when you view the side stats (by pressing alt+s during gameplay). The underscore ("_") facilitates translation using Gettext.
The next group of attributes describe the leader of this side:
canrecruit
: This attribute can be set toyes
orno
(the boolean equivalents1
and0
ortrue
andfalse
also work). If this is set tono
, the leader won't be able to recruit (not much of a leader then, is he?). Any team without acanrecruit=yes
attribute statement automatically loses, so be sure to include this attribute.type
describes what type of unit the leader will be. The possible values are listed in the Wesnoth unit tables.description
is the name and description of the leader.
In a campaign, all of these "leader-describing" attributes are ignored for human players (except canrecruit
), since the leader from the previous scenario is carried over into the current one. However, type
is still neccesary to prevent the scenario from crashing, so be sure to include it.
The last attribute, recruit
, is a comma-separated list of unit types.
Finally, two macros are called. The first, Template:LinkMacroP takes three positive numbers. These indicate the amount of money the player will start with on the easy, normal, and hard difficulty levels. For a human-controlled side (controller=human
), this specifies only the minimum amount of gold. The actual amount the player starts with can be larger if the player has retained gold from previous scenarios. The second macro, Template:LinkMacroP, is analogous to GOLD
but for the base income. The defaults values for GOLD
and INCOME
are 100 gold and 2 base income, respectively.
Making it all work
To make this scenario playable, we need to make a campaign for it (see BuildingCampaignsTheCampaignFile). This should not be stored in the main directory data/campaigns but rather inside userdata/data/campaigns. This prevents the breaking of mainline campaigns or, even worse, the entire game (see BuildingCampaignsDirectoryStructure). Please note that all files (i.e., the campaign file and the scenario files for each level) must be saved with the file extension .cfg (e.g., testcampaign.cfg). The following is a short, example campaign file:
[campaign] name= _ "Test Campaign" first_scenario=test-1 difficulties=EASY,NORMAL,HARD difficulty_descriptions= _ "&elvish-fighter.png=Easy;*&elvish-hero.png=Medium;&elvish-champion.png=Hard" icon=elvish-fighter.png [/campaign]
The [campaign]
tag describes the campaign. The first attribute, name
, is displayed in the campaign selector box during gameplay. The second, first_scenario
, is set to the ID number of the first scenario of the campaign. Subsequent scenarios are referenced by the next_scenario
attribute of their immediately preceding scenarios (see above in the first part of this tutorial). Since the first scenario, obviously, doesn't have a predecessor, it is referenced here in the campaign
tag.
The attribute difficulties=EASY,NORMAL,HARD
tells Wesnoth to use the value EASY
if the first difficulty choice is chosen during gameplay, NORMAL
if the second is chosen, and HARD
if the third is chosen.
The expression #ifdef
can be used later to test the value of this attribute (see PreprocessorRef).
It is recommended that you do not use any names other than EASY
, NORMAL
, or HARD
for your macros because doing so will cause some standard macros, such as {GOLD}
and {INCOME}
, to not work properly.
Two optional attributes are difficulty_descriptions
and icon
.
As its value, icon
holds the filename of an image to represent this campaign which will be displayed in the campaign list during gameplay.
The difficulty_descriptions
attribute must have in its value the same number of (string-enclosed) list items as difficulties
has in its (not string-enclosed) list items. This list length for both attributes is most commonly three. Also note that the list for difficulty_desciptions
is not only string enclosed, but its items are separated by semicolons rather than commas. Unsurprising, in our example during gameplay elvish-fighter.png would display associated with the easy level, elvish-hero.png with normal, and elvish-champion.png with hard.
Each list item in difficulty_description
begins with an ampersand ("&"). This is followed by the filename of the image, then an equal sign ("="), and finally the text to display (i.e., "Easy". Take note that text displayed for the easy level is not "EASY": the text used is that in difficulty_descriptions
, not difficulties
. Similary, the normal level's text is "Medium").
Optionally you may place an asterisk ("*") before one of list items of difficulty_desciptions
which will cause that corresponding difficulty level to be selected as the default during gameplay. In the example above, the normal level (along with its elvish hero) is selected as the default.