Difference between revisions of "BuildingScenariosIntermediate"

From The Battle for Wesnoth Wiki
 
 
(17 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 +
{{BuildingScenariosNav}}
  
<table width=100% border=0>
+
In this tutorial we will dig somewhat deeper into the secrets of WML and scenario building: events, explaining the use of some special attributes, setting up somewhat more advanced sides, ...
<tr>
 
<td>[[BuildingScenarios]]</td>
 
<td>[[BuildingScenariosWML]]</td>
 
<td>[[BuildingScenariosSimple]]</td>
 
<td>[[BuildingScenariosIntermediate]]</td>
 
<td>[[BuildingScenariosAdvanced]]</td>
 
</tr><tr>
 
<td></td>
 
<td>[[BuildingScenariosComments]]</td>
 
<td>[[BuildingScenariosSamples]]</td>
 
<td>[[BuildingScenariosFAQ]]</td>
 
<td></td>
 
</tr>
 
</table>
 
  
 
+
== Events ==
<<<<<<< [[BuildingScenariosIntermediate]]
+
You can trigger certain actions that occur during a scenario using the events mechanism. Let us look at an example of a simple event. Suppose you wanted Konrad to say "it's getting cold" when he moves to the location (4,8):
 
 
You can trigger certain actions that occur during a scenario using the events mechanism. Let us look at an example
 
of
 
a simple event. Suppose you wanted Konrad to say "it's getting cold" when he moves to the location (4,8):
 
  
 
   [event]
 
   [event]
  name=moveto
+
    name=moveto
  [filter]
+
    [filter]
  description=Konrad
+
      id=Konrad
  x=4
+
      x=4
  y=8
+
      y=8
  [/filter]
+
    [/filter]
  [message]
+
    [message]
  description=Konrad
+
      speaker=Konrad
  message= _ "It's getting cold"
+
      message= _ "It's getting cold"
  [/message]
+
    [/message]
 
   [/event]
 
   [/event]
  
Firstly you have the name of the event.
+
First you have the name of the event.
This is a 'moveto' event, meaning it is fired every time a unit moves somewhere.
+
Here, we have a 'moveto' event, meaning it is fired every time a unit moves somewhere.
 
For a list of the different possible event names, see [[EventWML]]
 
For a list of the different possible event names, see [[EventWML]]
  
Of course, we don't want it to be fired everytime any unit moves anywhere,
+
Of course, we don't want this to be fired every single time some unit moves somewhere! So, we use the '''[filter]''' tag to filter out what kind of moveto event we want.
so we use the '''[filter]''' tag to filter out the kind of moveto event we want.
+
How filters are used is described in [[FilterWML]].
Events can be filtered on many different parameters.
 
Filters are described in [[FilterWML]].
 
  
''Special attributes''
+
== Special attributes ==
  
 
Note that generally, a set of actions is triggered only once.
 
Note that generally, a set of actions is triggered only once.
Line 51: Line 32:
 
by adding the attribute '''first_time_only=no''' in the event.
 
by adding the attribute '''first_time_only=no''' in the event.
  
Also, whenever an event is triggered, the player cannot undo the move,
+
Also, whenever an event is triggered, the player cannot undo the move, even if it was a moveto event. We could make a scenario where moves cannot be undone by adding the event
even if it was a moveto event.
 
We could make a scenario where moves cannot be undone by adding the event
 
  
 
  [event]
 
  [event]
name=moveto
+
  name=moveto
first_time_only=no
+
  first_time_only=no
 
  [/event]
 
  [/event]
  
which would not do anything, but would prevent the player from undoing moves.
+
(which would not do anything, but would prevent the player from undoing moves)
  
The event
+
The event:
  
 
  [event]
 
  [event]
name=enemies defeated
+
  name=enemies defeated
  [endlevel]
+
  [endlevel]
  result=victory
+
    result=victory
  bonus=yes
+
    bonus=yes
  [/endlevel]
+
  [/endlevel]
 
  [/event]
 
  [/event]
  
 
is an implied trigger and appears automatically at the end of each scenario.
 
is an implied trigger and appears automatically at the end of each scenario.
To prevent this event, add the attribute '''victory_when_enemies_defeated=no'''
+
To prevent this event, add the attribute '''victory_when_enemies_defeated=no''' inside the main tag (usually [scenario]).
inside the main tag (usually [scenario]).
+
 
 +
The attribute '''disallow_recall=yes''' prevents the player from recalling units in this scenario.
  
The attribute '''disallow_recall=yes''' prevents the player
+
The attributes '''fog=yes''' and '''shroud=yes''' can be put in a '''[side]''' tag to make that side have fog of war/shroud. (Fog of war prevents seeing all enemy movement, shroud prevents seeing all of the map.)
from recalling units in this scenario.
 
  
The attributes '''fog=yes|| and ||shroud=yes|| can be put in a ||[side]''' tag
+
 
to make that side have fog of war/shroud.
+
== Advanced Sides ==
(Fog of war prevents seeing all enemy movement,
 
shroud prevents seeing all of the map.)
 
=======
 
>>>>>>> 1.4
 
  
 
Ok, so as you have seen in [[BuildingScenariosSimple]], you can setup what the human player and AI player start with, and some simple options for controlling how the AI works. From the '''[side]''' tag listed below you can see we are going to learn some more interesting things that can be controlled from there. I'm not going to explain all the keys, just the new ones.
 
Ok, so as you have seen in [[BuildingScenariosSimple]], you can setup what the human player and AI player start with, and some simple options for controlling how the AI works. From the '''[side]''' tag listed below you can see we are going to learn some more interesting things that can be controlled from there. I'm not going to explain all the keys, just the new ones.
Line 93: Line 68:
 
  .
 
  .
 
   
 
   
[side]
+
  [side]
type=Lich
+
    type=Lich
description=Galga
+
    id=Galga
side=2
+
    side=2
canrecruit=1
+
    canrecruit=yes
 
   
 
   
#ifdef EASY
+
    #ifdef EASY
  recruit=Skeleton,Revenant,Blood Bat,Ghost,Bone Shooter
+
      recruit=Skeleton,Revenant,Blood Bat,Ghost,Bone Shooter
  recruitment_pattern=fighter,fighter,archer,scout
+
      recruitment_pattern=fighter,fighter,archer,scout
  gold=300
+
      gold=300
#endif
+
    #endif
 
   
 
   
#ifdef NORMAL
+
    #ifdef NORMAL
  recruit=Skeleton,Revenant,Chocobone,Blood Bat,Wraith,Bone Shooter,Dark Adept  
+
      recruit=Skeleton,Revenant,Chocobone,Blood Bat,Wraith,Bone Shooter,Dark Adept  
  recruitment_pattern=fighter,fighter,archer,scout
+
      recruitment_pattern=fighter,fighter,archer,scout
  gold=500
+
      gold=500
#endif
+
    #endif
 
   
 
   
#ifdef HARD
+
    #ifdef HARD
  recruit=Skeleton,Revenant,Chocobone,Wraith,Bone Shooter,Dark Adept
+
      recruit=Skeleton,Revenant,Chocobone,Wraith,Bone Shooter,Dark Adept
  recruitment_pattern=fighter,fighter,archer,scout
+
      recruitment_pattern=fighter,fighter,archer,scout
  gold=700
+
      gold=700
#endif
+
    #endif
 
aggression=1.0
 
village_value=0.0
 
leader_value=50.0
 
enemy=1
 
[/side]
 
 
   
 
   
 +
    aggression=1.0
 +
    village_value=0.0
 +
    leader_value=50.0
 +
    enemy=1
 +
  [/side]
 
  [/scenario]
 
  [/scenario]
  
As you can see from the above listing, the '''[side]|| tag can get a little complex. The ||#ifdef|| is relitivly simple to explain. If the user is playing EASY then everything between ||#ifdef EASY|| and ||#endif|| is set and the others are ignored. If the user is playing NORMAL then everything between ||#ifdef NORMAL|| and ||#endif|| is set and the others are ignored. Finally if the user is playing HARD then everything between ||#ifdef HARD|| and ||#endif|| is set and the others are ignored. This allows a scenario to be configured differently for each level of gameplay the user may choose. There are also two new keys listed, ||village_value|| and ||leader_value'''.
+
As you can see from the above listing, the '''[side]''' tag can get a little complex.  
 +
The '''#ifdef''' is relatively simple to understand. If the user is playing EASY then everything between '''#ifdef EASY''' and '''#endif''' is set and the others are ignored. If the user is playing NORMAL then everything between '''#ifdef NORMAL''' and '''#endif''' is set and the others are ignored. Finally if the user is playing HARD then everything between '''#ifdef HARD''' and '''#endif''' is set and the others are ignored. This allows a scenario to be configured differently for each level of gameplay the user may choose. There are also two new keys listed, '''village_value''' and '''leader_value'''.
  
  
Lets get into some more interesting stuff. The map files hold the ground tiles. This is the very bottom layer of things. The units walking around during a game are on the very top layer. This is all well and good, but wouldnt it be nice to be able to place some unique items on the map? What if you wanted to place a building, or a potion, or anything somewhere in your scenario? Well you can with the '''[item]''' tag.
+
Lets get into some more interesting stuff. The map files hold the ground tiles. This is the very bottom layer of things. The units walking around during a game are on the very top layer. This is all well and good, but wouldn't it be nice to be able to place some unique items on the map? What if you wanted to place a building, or a potion, or anything somewhere in your scenario? Well you can! Using the '''[item]''' tag:
  
 
  [scenario]
 
  [scenario]
Line 135: Line 110:
 
  .
 
  .
 
   
 
   
[item]
+
  [item]
x=31
+
    x=31
y=43
+
    y=43
image=item-holywater.png  
+
    image=item-holywater.png  
[/item]
+
  [/item]
 
   
 
   
 +
.
 +
.
 +
.
 
  [/scenario]
 
  [/scenario]
  
The '''[item]|| tag is actually very simple to use, as you can see from above. There are three keys, the first two are ||x|| and ||y||. They are the location on the map. The third key is ||image'''. This it tha image file to place in that location. This image must be located in the images directory. Ok, that was simple wasn't it?
+
The '''[item]''' tag is actually very simple to use, as you can see from above. There are three keys, the first two are '''x''' and '''y'''. They are the location on the map. The third key is '''image'''. This it the image file to place in that location. This image must be located in the images directory. Ok, that was simple wasn't it?
  
  
Line 153: Line 131:
 
  .
 
  .
 
   
 
   
[story]
+
  [story]
[part]
+
    [part]
id=intro_13
+
      background=portraits/elves/transparent/high-lord.png
story="... but one of the Orcs survived long enough to send the news to the queen..."  
+
      story= _ "...And so he entered the dark and gloomy cave..."
image=misc/story6.png
+
    [/part]
[/part]
+
    .
[/story]
+
    .
   
+
    .
  [scenario]
+
  [/story]
 +
  .
 +
.
 +
.
 +
  [/scenario]
 +
 
 +
The story tag contains the story told before the player starts the scenario. You can ommit this, then you will skip the introductionary screens. A story tag exists out of parts (inside [part] tags). Each part can contain several keys describing what content it has got. See [[IntroWML]] for more information.
  
FIXME: finish [story]
+
== See Also ==
 +
* [[ScenarioWML]] & [[SyntaxWML]]
 +
* [[BuildingScenarios]]
  
 +
[[Category:Create]]

Latest revision as of 22:05, 10 October 2018

In this tutorial we will dig somewhat deeper into the secrets of WML and scenario building: events, explaining the use of some special attributes, setting up somewhat more advanced sides, ...

Events

You can trigger certain actions that occur during a scenario using the events mechanism. Let us look at an example of a simple event. Suppose you wanted Konrad to say "it's getting cold" when he moves to the location (4,8):

 [event]
   name=moveto
   [filter]
     id=Konrad
     x=4
     y=8
    [/filter]
    [message]
      speaker=Konrad
      message= _ "It's getting cold"
    [/message]
 [/event]

First you have the name of the event. Here, we have a 'moveto' event, meaning it is fired every time a unit moves somewhere. For a list of the different possible event names, see EventWML

Of course, we don't want this to be fired every single time some unit moves somewhere! So, we use the [filter] tag to filter out what kind of moveto event we want. How filters are used is described in FilterWML.

Special attributes

Note that generally, a set of actions is triggered only once. You can make a set of actions be triggered every time the event occurs by adding the attribute first_time_only=no in the event.

Also, whenever an event is triggered, the player cannot undo the move, even if it was a moveto event. We could make a scenario where moves cannot be undone by adding the event

[event]
  name=moveto
  first_time_only=no
[/event]

(which would not do anything, but would prevent the player from undoing moves)

The event:

[event]
  name=enemies defeated
  [endlevel]
    result=victory
    bonus=yes
  [/endlevel]
[/event]

is an implied trigger and appears automatically at the end of each scenario. To prevent this event, add the attribute victory_when_enemies_defeated=no inside the main tag (usually [scenario]).

The attribute disallow_recall=yes prevents the player from recalling units in this scenario.

The attributes fog=yes and shroud=yes can be put in a [side] tag to make that side have fog of war/shroud. (Fog of war prevents seeing all enemy movement, shroud prevents seeing all of the map.)


Advanced Sides

Ok, so as you have seen in BuildingScenariosSimple, you can setup what the human player and AI player start with, and some simple options for controlling how the AI works. From the [side] tag listed below you can see we are going to learn some more interesting things that can be controlled from there. I'm not going to explain all the keys, just the new ones.

[scenario]
.
.
.

  [side]
    type=Lich
    id=Galga
    side=2
    canrecruit=yes

    #ifdef EASY
     recruit=Skeleton,Revenant,Blood Bat,Ghost,Bone Shooter
     recruitment_pattern=fighter,fighter,archer,scout
     gold=300
    #endif

    #ifdef NORMAL
     recruit=Skeleton,Revenant,Chocobone,Blood Bat,Wraith,Bone Shooter,Dark Adept 
     recruitment_pattern=fighter,fighter,archer,scout
     gold=500
    #endif

    #ifdef HARD
     recruit=Skeleton,Revenant,Chocobone,Wraith,Bone Shooter,Dark Adept
     recruitment_pattern=fighter,fighter,archer,scout
     gold=700
    #endif

    aggression=1.0
    village_value=0.0
    leader_value=50.0
    enemy=1
  [/side]
[/scenario]

As you can see from the above listing, the [side] tag can get a little complex. The #ifdef is relatively simple to understand. If the user is playing EASY then everything between #ifdef EASY and #endif is set and the others are ignored. If the user is playing NORMAL then everything between #ifdef NORMAL and #endif is set and the others are ignored. Finally if the user is playing HARD then everything between #ifdef HARD and #endif is set and the others are ignored. This allows a scenario to be configured differently for each level of gameplay the user may choose. There are also two new keys listed, village_value and leader_value.


Lets get into some more interesting stuff. The map files hold the ground tiles. This is the very bottom layer of things. The units walking around during a game are on the very top layer. This is all well and good, but wouldn't it be nice to be able to place some unique items on the map? What if you wanted to place a building, or a potion, or anything somewhere in your scenario? Well you can! Using the [item] tag:

[scenario]
.
.
.

  [item]
    x=31
    y=43
    image=item-holywater.png 
  [/item]

.
.
.
[/scenario]

The [item] tag is actually very simple to use, as you can see from above. There are three keys, the first two are x and y. They are the location on the map. The third key is image. This it the image file to place in that location. This image must be located in the images directory. Ok, that was simple wasn't it?


Now you have enough information to make some interesting looking scenarios with tuned AI players. This is a big step. Next we are going to learn how to make your newly created scenario fit nicely into a campaign. This involves making the intro shown before the scenario is played a bit more descriptive. This is all done from within the [story] tag.

[scenario]
.
.
.

  [story]
    [part]
      background=portraits/elves/transparent/high-lord.png
      story= _ "...And so he entered the dark and gloomy cave..."
    [/part]
    .
    .
    . 
  [/story]
.
.
. 
[/scenario]

The story tag contains the story told before the player starts the scenario. You can ommit this, then you will skip the introductionary screens. A story tag exists out of parts (inside [part] tags). Each part can contain several keys describing what content it has got. See IntroWML for more information.

See Also

This page was last edited on 10 October 2018, at 22:05.