※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

シナリオWML

 

訳はさらに暴力的になった。 

 


 

目次

ScenarioWML

  EventWML

    FilterWML

    DirectActionsWML

    InterfaceActionsWML

    InternalActionsWML

  SideWML

    SingleUnitWML

    BuildingScenariosShroudData

  MapGeneratorWML

  TimeWML

  IntroWML

  UtilWML

 


 

ScenarioWML

 

トップレベルタグ

 

[scenario]タグ

 

  • id:このシナリオ固有のid
  • next_scenario:次のシナリオのid。一直線でないシナリオを作るために変更可能
  • description:不要
  • name: (translatable) is shown in several places in the level, including the intro screen. It is also the default name for saves on the level
  • map_data:適切なウェスノスマップデータを入力。
  • turns:プレイヤーが敗北するターン数をセット。-1を使えばターンリミットがなくなる。EventWML参照
  • turn_at:開始ターン(デフォルトは1)
  • random_start_time:yesかno
  • music:シナリオ中の音楽
  • [music]:シナリオ中に流れる音楽トラックの特定、MusicListWML参照
  • defeat_music:敗北時の音楽
  • victory_music:勝利時の音楽
  • theme:シナリオをプレイする時に用いられるUlテーマ。Using custom themes in campaigns参照
  • victory_when_enemies_defeated:yesにセットすると(デフォ)、canrecruit=yes(aka leaders)を伴う全ての非同盟ユニットが殺されるとプレイヤーは勝つ。(これは、全ての敵が倒される時の勝利条件を制御するだけ。プレイヤーがリーダーを持っていないなら、プレイヤーの敗北を妨げない。)この値がtrueの場合、以下のキーが用いられうる。

carryover_percentage:デフォではゴールドの80%が次のシナリオに持ち込まれる。

caryover_add:もしtrueなら、ゴールドは次のシナリオの開始資金に追加される。もしfalseなら、次のシナリオは、現在シナリオの量で開始(課税後)あるいは最小限。

  • disallow_recall:これはnoにセットされる時(デフォ)、プレイヤーは過去のシナリオからのユニットを召喚できる。
  • experience_modifier:レベルアップに要求される経験値のパーセンテージ。デフォルトでは100 シナリオ間で違う設定にするとえらいことになる
  • [story]:導入画面の記述。IntroWML参照
  • [label]ラベルを貼る
      x,y:ラベルの場所
      text:ラベル
  • [time],[illuminated_time]一日がどのように進行するか。TimeWML参照
  • [time_area]:あるエリアで一日がどのように進行するか。[time_area]タグで特定されない場所は[scenario]タグの中の[time]と[illuminated_time]によって決められる。
      xとy座標をとる。
      [time],[illuminated_time]その場所で一日がどのように進行するか。TimeWML参照
      time areasはイベントで用いられうる。DirectActionsWML参照。
  • [side]:一人のプレイヤーを記述。SideWML参照
  • [event]:シナリオの特定ポイントで発生するイベントを記述。EventWML参照
  • map_generation:マップを作成するもう一つの方法。マップはランダムに作成される。
      default:デフォルトのランダムマップ生成
  • [generator]:これがpresentなら、そのマップとシナリオはランダムに生成される。MapGeneratorWML参照

 

以下のキーはマルチプレイヤーでうんぬん(省略

 


 

EventWML

 

[event]タグ

 

このタグは[scenario][unit_type][era]タグのサブタグであり、シナリオの特定ポイントで発生する一連のアクションを記述するために用いられる。[scenario]タグで用いられる時、そのイベントはそのシナリオにおいてのみ発生する。[unit_type]タグで用いられる時、そのイベントはそのタイプのユニットが登場する全てのシナリオで発生する(ただし、そうしたユニットがそのシナリオ中に登場した後でのみ)。[era]タグで用いられる時、そのイベントはそのeraを用いてプレイされるシナリオ全てで発生する。

 

このタグは、イベントアクションが発生する時を制御するキーや子供タグを持つ。最も重要なものはnameキーである。それが無ければ、エラーは発生しないがイベントが発生しない。それゆえ、実際の見地からすれば、必須と考えられる。

 

nameキー(必須)

 

使用:

  • name=<value>

これは普通のnameキーではない。これはイベントがいつ発生するかの基礎的な記述だ。これはまた非常に大きな数の規定値を持ち、その一つは適切なキーで用いられなければならない。

  • Lexicon side note:あるイベントのtriggerとしてこれらの値を指すことは普通でないことはない。さらにその引き金nameによって全てのイベントを呼ぶことも普通でないことはない。例えば、name=movetoを含むイベントでは、ある人はそのイベントをmoveto eventとして指すかもしれない。あるいはまた、そのイベントにおいてmoveto triggerを指すかもしれない。あるいは、そのイベントでnameキーのmoveto値を指す時、event triggerについて話しているかもしれない。

nameキーは、そのイベントが発生する時を記述しているコンマで分離された値のリストを許容する。これらの値は既定のイベントタイプないし既定タイプとは合わないカスタムイベント名であるかもしれない。

 

例:

name=attacker misses, defender misses

注意:first time only=noを使用しない限り、そのイベントは一度だけ発生し、リストされているそれぞれのタイプにつき一度ずつではない。


既定のnameキーの値

 

全ての既定イベントタイプは、ここにリストされている。この値がいつそのイベントを発生させるかの記述と一緒にだ。ここにリストされていないあらゆる値は、他の場所の[fire_event]タグによってのみ発生しうるカスタムイベントnameである。イベント名の中のスペースは、アンダースコアと交換可能である(例:name=new turnとname=new_turnは同等)。

 

  • preload(development versionのみ)

当然省略

  • prestart

シナリオstarts前のtriggers。画面に何も表示される前。村の所有などを設定するために用いられる。キャラクターダイアログなど画面に表示させるものについては、代わりにstartを用いろ。

注意:この値はfirst time onlyキーとは無関係。定義上、一度しか発生しない。

  • start

マップが表示された後、シナリオが始まる前(プレイヤーが何かできる前)のtriggers。

注意:この値はfirst time onlyキーとは無関係。同上。

  • new turn

毎ターン(サイドターンではない)の最初のtriggers。first time only=no参照。このタイプのイベントが発生する前、WMLの変数turn_numberの値は、開始ターンの数をセットする。

  • side turn

あるサイドがそのターンを開始しようとする時のトリガー。このタイプのイベントが発生する前に、WMLの変数side_numberの値はプレイヤーのサイド数をセットする。これは、そのサイドでヒーリングが発生する前、収入の計算前、ユニットの移動力や状態の回復前だ。

  • ai turn

AIがあるサイドで発動される前に発生する。これはside turnの後に呼び出される。そして、WMLの様々なside_numberはこのサイドの数を持つ。注意:このイベントはターンごとに複数回呼び出されるかもしれない(人間に戻したりやドロイド化が発動される場合)。例えば、もし人間プレイヤーが彼のサイドをドロイド化すると、side1の人間のターンの途中で発生する。そのターンをプレイするaiの選択の後、AIに新しいターンが来ると告げる前に発生する。

注意:このイベントはリプレイを壊す。

  • turn refresh

side turnのように、あるサイドがコントロールを取る前だが、ヒーリング、収支計算、移動力状態の回復の後で、発生する。

  • turn X

ターンXの最初に発生する。それは最初のサイドの初期化イベントだ。サイドの初期化イベントは次の順序で起こる。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

このイベントはサイドYのターンXの最初に発生する。(Development version only)

  • side X turn

(Development version only)

  • time over

turnsターンに発生する。(turnsは[scenario]で特定される)

  • enemies defeated

side1と同盟していないcanrecruit=yesを伴う全てのユニット(すなわち全てのリーダー)が殺される時、発生する。

  • victory

このシナリオでは、[endlevel] result=victory [/endlevel]という形のいかなるタグも、このタグ中の全てのアクションによって自動的に始められる。もし勝利イベントが、:nコマンドの使用後、なんらか可能な次のマップへと君を問題なく進めさせるかどうかデバッグする助けとなる。勝利前にキーユニットを選択したり、何らかの選択アクションによってどのマップへ進むかを先に決定したりするシナリオは、あるキャンペーンでシナリオをテストするのを難しくする。[endlevel],DirectActionsWML参照

  • defeat

このシナリオでは、[endlevel] result=defeat [/endlevel]の形のいかなるタグも、このタグ中の全てのアクションによって自動的に始められる。([endlevel],DirectActionsWML参照)


フィルターは以下のイベントトリガーに割り当てられうる(FilterWML参照)。イベントタグで特定されるアクションは、そのフィルターがtrueになる場合のみ実施される。これらのイベントトリガーは、ユニットによる全てのアクション(moveto, attack)あるいはユニットに生じること(recruit, advance)である。これらのイベントの一つが発生する時、アクティブユニット(primary unitとして指示される)位置は、変数x1とy1に保存されており、primary unitが何かを為す場所は変数x2とy2に保存されている(このユニットは、以下secondary unitとして指示される)。これらのユニットは、変数unitとsecond_unitに自動的に保存される。まるでそれらユニットが[store_unit]タグを用いて保存されていたように。SingleUnitWML参照。

  • moveto

primary unitが動いた後で発生する。典型的にこれが用いられるのは、primary unitが特定の場所に到着し、primary unitの場所に関するフィルターが含まれる時である。覚えておかなければならないのは、これはprimary unitが到着する場所であって、それが活動したり、進む場所ではないということだ。
moveto event中のどこにあっても[allow_undo]タグは、そのイベントが引き起こしたであろうundo機能の欠如をキャンセルする。注意せよ。undo機能は、ユニットを前の場所にもどすだけだ。そのイベントによって引き起こされたゲームに他の変化はもたらさない。このように、このタグを正しく用いることはシナリオデザイナー次第だ。

  • sighted

primary unitが特にsecondary unitの視界に入った時、secondary unitのサイドの視界に入らなくとも発生する(だから、もしsecondary unitのサイドが幕や霧を持たないなら、このイベントは決して発生しない)。これは、primary unitがそのターン中に視界に移動する時、およびsecondary unitがprimary unitを見られる場所へ移動する時の両方で生じる。(このエディターは、primary unitが一度に複数のunitの視界に入った場合、そのイベントが複数回発生するか否か、あるいはどのユニットがここでsecondary unitに選ばれているか、テストしていない)(注意:明らかに、敵ユニットが君の視界に入ったためにsightedイベントが引き起こされる時、ゲームエンジンは、(君のサイドの)どのユニットが動いたユニットを見るか決定できない。だから、そのイベントは$second_unitの設定なしにname=sighted eventを発生させる。これは例えば、messageタグ内のspeaker=second_unitを用いることが失敗するかもしれないということを意味する)(重ねて注意:以下もまた明らかである。ゲームのより最近のバージョン(1.6とか1.7とか?)でのsighted eventは敵のターンでは発生しない。このイベントはまた一般的にバグがある。普通は、sighted eventを用いるよりも、[filter_vision]タグと一緒にmoveto eventを用いる方がよい(またその二つのコンビネーションが古いsighted eventによくにたものを達成できるということに注意))

  • attack

primary unitがsecondary unitを攻撃する時に発生する。

  • attack end

attackと似ているが、戦闘前ではなく、戦闘後に発生する。もしいずれかのユニットが戦闘で死んだ場合、このイベントはdieイベントの前に発生することに注意

  • attacker hits

primary unit(attacker)がsecondary unit(defender)を殴る時に発生する。WML変数のdamage_inflictedの値は、attackerによって与えられたHPの数を設定する。

  • attacker misses

attacker hitsと同様だが、attackerがミスった時に発生する。

  • defender hits

primary unit(attacker)がsecondary unit(defender)に反撃で殴られる時に発生する。WML変数のdamage_inflictedの値は、defenderによって与えられるHPの数を設定する。

  • defender misses

defender hitsと同様だが、defenderがミスった時に発生する。

  • stone

primary unitがsecondary unit(stonesアビリティを有するユニット)にstonesアビリティ付きの攻撃で殴られた時に発生する(stones, AbilitiesWML参照)。

  • last breath

primary unitがsecondary unitに殺される時、ただし死のアニメーションが発生する前に、発生する。

  • die

primary unitがsecondary unitに殺される時に発生する。

  • capture

primary unitが村を占拠したときに発生する。その村は元は中立であるか、あるいは別のサイドに所有されているだろう。単に自分が所有する村へ移動してもcaptureは起こらない。

  • recruit

primary unitが雇用されるときに発生する。(すなわち、あるユニットが雇用される時、このイベントを発生させ、このイベントのフィルターがそのユニットにフィルターをかける)

  • prerecruit

primary unitが雇用される時、ただしそれが表示される前に発生する。

  • recall

あるユニットが召喚された後、発生する。

  • prerecall

あるユニットが召喚される時、ただしそれが表示される前に発生する。

  • advance

primary unitが別のユニットのところへ行く直前に発生する。

  • post advance

primary unitが別のユニットのところへ行った直後に発生する。

  • select

primary unitが選択される時に発生する。また、ある移動を終える時に発生する。なぜなら、このゲームは、移動の終わりに再びユニットを選ぶことによって、移動ユニットを選択状態に保つからだ。

  • menu item X

WMLメニューアイテム(id=X)が選択される時に発生する。注意:もしメニューアイテムが[command]を持っているなら、このイベントはそのcommand前ないし後に実行される。保証はない

 

===カスタムイベント

 

カスタムnameつきのイベントは、[fire_event]タグを用いて呼び出される。普通、既定タイプのイベントによって呼ばれるように、名付けられたサブルーチンのようなカスタムイベントを用いるだろう。この一例は、一つ以上のsightedイベントが、シナリオの目的を変更する同じカスタムイベントを引き起こすような場合である。


任意のキーとタグ

 

これらのキーとタグは、あるイベントが発生すべき時をフィルターするより複雑な方法である。

 

  • first_time_only

イベントが一度発生した後、そのシナリオから取り除かれるべきか否か。このキーはbooleanを取る。例えば、

  • first_time_only=yes
    キーが省かれる場合はデフォルトの振る舞いである。そのイベントは、初回だけ発生可能であり、二度とは発生しない。
  • first_time_only=no
    そのイベントは初回のみの代わりに、条件が満たされればいつでも発生する。
  • [filter]

そのイベントは、primary unitがこのフィルターと合致する場合のみ発生する。
・StandardUnitFilter:selection criteria

  • [filter_second]

[filter]と同様だが、secondary unitのためのものである。
・StandardUnitFilter:selection criteria

  • [filter_attack]

これは、標準的なユニットフィルターで一般的に利用可能ではない、primary unitとsecondary unitのための付加的なフィルタリング条件を設定するために用いられうる。attack, attacker hits, attacker misses, defender hits, defender misses, attack endのイベントで用いられうる。さらなる情報や他のフィルターキーについては、FilterWML参照
・name:用いられる武器の名前
・range:用いられる武器の範囲
・special:攻撃の特殊効果に関するフィルター

  • [filter_second_attack]

[filter_attack]と同様だが、secondary unitのためのものである。
・name:用いられる武器の名前
・range:用いられる武器の範囲
・special:攻撃の特殊効果に関するフィルター

  • [event]

ある特別なケースのアクション。[event]タグはnested eventを作るために用いられる。

delay_variable_substitution

このキーはnested eventの内部にのみ関連し、いつ変数の代入が、それら特別なケースのアクションにおいて発生するかを制御する。


[event]によって引き起こされるアクション

 

トリガー条件が満たされた後、[event]タグ内の全てのアクションタグは、記述されている順番で発動する。

アクションには3つの主要タイプがある(それぞれ該当ページあり)。

・direct actions ゲームプレイに直接的影響を持つ
・display actions ユーザーに何かを見せる
・internal actions WMLによって内的に用いられる

いくつかのアクションは、どのユニットがそのコマンドを実行すべきかを見出すために標準的なフィルターを用いる。これらはstandard unit filterおよびstandard location filterというフレーズで呼ばれる。

  • Nested Events

一つの特別なタイプのアクションがある。[event]タグを別の[event]タグのなかに置くことによって、nested eventが作成されるのは、親イベントがその内容を実行する時である。(例を見よ)

  • Delayed Variable Substitution

nested eventのための変数代入は、親イベントによって引き起こされる時かあるいはそれ自体が引き起こされる時に発生しうる。これはnested eventで用いられるdelayed_variable_substitutionキーで制御される。

もしこのキーがyesにセットされるなら、nested event内の変数は、そのnested eventが発生したターンからの値を含むだろう。これは、キーが省略された場合のデフォルトの振る舞いである。もしnoにセットされるなら、nested event内の変数は、親イベントが発生する時にセットされる。

この振る舞いは、変数を参照する時に、特別なsyntaxでうまく調整されうる。通常の$variableシンタックスの代わりに、$|variableを用いて、delayed_variable_substitutionがnoにセットされている時でさえ、nested eventが発生したターンと関連する値を含むようにしろ。このようにして、親イベントとnestedイベントの発生時間に関連する変数のミックスを持てる。
(例を見よ)


A Trap for the Unwary

 

同じ既定のnameを持ち、同じトリガー条件を持った複数のイベントを持つことは可能である(実際に有益だ)。しかしながら、どの順番でそうしたイベントがフィルターするかは決定されていないので、順番が問題にならないようにコードする必要がある。

上述のため、イベントを生み出すマクロを用いることを知る必要がある。もしあるイベント定義を二回に拡張するマクロを含むなら、そのイベントは、ソノトリガー条件が満たされるたびに(一度ではなく)二回発生する。

 

次のコードを見よ

#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"}

それが実行した後、デバッグメッセージが、その変数が4ではなく8にセットされていたことを明らかにする。

 

種々のメモと例

 

Primary/Secondary Unit Speakerの例

 

イベント中、speakerキーを用いる[message]タグ内で、primary unitはunitとして指示され、secondary unitはsecond_unitとして指示される。

 

例:

[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の例

 

[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]


こうする同等の方法は、ターン数をチェックする[if]言明を持つmoveto eventを作成することであるが、nestedな[event]タグを用いることは、[if]言明に頼ることなくこのタスクを達成する便利なショートカットである。


Delayed Variable Substitutionの例

 

このコードは、nestedなmovetoイベントが発生するターンを表示する。

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=yes

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

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

 

これはdelayed_variable_substitutionキーのデフォルトの振る舞いであるから、以下の例は同じものである。

[event]
    name=turn 10

    [event]
        name=moveto

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

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

次のコードは、nestedなmovetoイベントが発生する時、Turn 10と常に表示するだろう。これは、その変数の代入が、nestedイベントが発生する時ではなく、その親イベントが発生しnestedイベントが生じる時に為されるからである。

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=no

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

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

最後に次の例は、最初の二つと同じものである。そこでは、delayed_variable_substitutionキーがnoに設定されているにもかかわらず、nestedなmovetoイベントが発生するターンを表示する。これは特別な$|variableシンタックスが用いられているからである。

[event]
    name=turn 10

    [event]
        name=moveto
        delayed_variable_substitution=no

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

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

 

 

 


 

FilterWML

 

WMLでのフィルタリング

 

フィルターは特別なWMLの塊である。フィルターは、一組のユニット、ヘクス、武器を記述するために用いられる。フィルターは、フィルター内の全てのキーがなにものかと合致する場合、そのものを合致させるものとして定義される。例えば、もしあるユニットフィルターが二つのキーを含むのなら、あるユニットはそのフィルターに合致するために、両方のキーと合致しなければならない。

 

  • ユニットのフィルタリング

 

フィルターはしばしばアクションタグ内で用いられる(EventWML参照)。この場合、standard unit filterというフレーズが、standardキーのセットの場所で用いられる。時々、フィルターは、そのフィルターに合致する最初のユニットを発見するために用いられる。例えば[recall]タグはそのユニットを召喚する。

 

Standard unit filterはまた、[filter]および[filter_second]タグで用いられる。これらはそのイベントがいつ発生するかを記述する[event]のサブタグである。ほとんどのイベントname(EventWML参照)は、primary unitやsecondary unitと呼ばれるユニットと関係づけられるユニットを持つ。あるイベントが引き起こされるためには、primary unitは[filter]内のフィルターと合致しなければならず、secondary unitは[filter_second]内のフィルターと合致しなければならない。

 

詳細はStandardUnitFilter参照

 

  • 場所のフィルタリング

 

見てきた通り、standard unit filterは場所(location)フィルターを含む。[terrain]ようないくつかのアクションもまた場所フィルターを用いる。場所フィルターは、standard location filterというフレーズによってこの場所で表される。

 

詳細はStandardLocationFilter参照

 

  • 武器のフィルタリング

 

時折、武器はWMLでフィルターされる。EventWML,EffectWML,AnimationWMLも参照。以下のキーは武器フィルターをインプットするフィルターとして用いられる。

 

range:フィルターする範囲
 melee:格闘攻撃のみパスする
 ranged:投射攻撃のみパスする

name:攻撃名に関するフィルター
特定ユニットの攻撃名については、data/units/ないしhttp://www.wesnoth.org/units/参照

 

type:攻撃タイプに関するフィルター
値はblade,pierce,impact,fire,cold,arcane

 

damage(Development version only)

 

special:攻撃の特殊効果に関するフィルター
値についてはAbilitiesWML参照

 

  • 地形のフィルタリング

 

[filter]内の[filter_location]を用いよ

例:
[event]
    [filter]
        [filter_location]
            terrain=Ch
        [/filter_location]
    [/filter]
[/event]

いくつかの場所では、地形は合致リストでフィルターされうる。そのリストは、コンマで分離されたリストであり、合致は最初に合致したterrain stringで止まるだろう。合致の意味を逆にする「!」という特別な文字がある。Terrain stringsは、0ないしより多くの続く文字と合致するため、ワイルドカードである「*」を用いることができる。「*」の後ろに文字は許されず、結果は未定義である。

 

例:

ww*はww, www, wwWと合致するが、WWWとは合致しない
!, wwは、もしwwが発見されるなら偽、発見されなければ真になる
!, ww, wa, !, aaは、wwないしwaが見出されるなら偽、aaが見出されるなら真でそうでないなら偽である。
terrainタイプのリストやそのstringコードについてはTerrainCodesWML参照

 


 

DirectActionsWML

 

Direct actions

ダイレクトアクションは、ゲームプレイに直接的な影響を持つアクションである。

 

以下のタグがアクションである。

 

  • [endlevel]:そのシナリオを終わらせる。

・result:そのシナリオが終わる前に、name=resultの全てのイベントが発生する。先頭がresult_headingのresult_messageであるメッセージ(LanguageWML参照)が表示される。もしresult=victoryなら、プレイヤーは次のレベルへ進む。もしresult=defeatなら、ゲームはメインメニューへ戻る。以下二つは、滅多に用いられない。result=continueは、プレイヤーのゴールドが80%に減じられることを除いて、result=victoryと同様に振る舞う。そして「Victory」メッセージないしゴールドを変えるメッセージは生じない(変わらないんだから)。result=continue_no_saveも同様に働くが、プレイヤーはゲームをセーブするか否か問われず、何のメッセージもなく次のシナリオへと直接進む。(Development version only)以下略

 

result=defeatでないなら、以下のキーも用いられうる。

 

・bonus:プレイヤーがボーナスゴールドを得るべきか否か。(最大可能ゴールド)デフォルトではbonus=yes。

・carryover_report:プレイヤーがシナリオの収入の一覧を受け取るべきか否か。デフォではcarryover_report=yes。

・save:シナリオ最初のセーブは、次のシナリオのために作成されるべきか否か。デフォではsave=yes。

・linger_mode:もし...=yesなら、スクリーンは灰色になり、次のシナリオに進む前に、セーブする余地がある。デフォはlinger_mode=yes。

・next_scenario:(デフォでは[scenario]タグで特定される)プレイされるべきnext scenarioのID。この点でside1がコントロールする全てのユニットは、next_scenarioで召喚できるようになる。

・結果がvictoryの時、以下のキーが用いられうる。
○carryover_percentage:デフォではゴールドの80%が次のシナリオに持ち込まれる。このキーでその量が変更可能。
○carryover_add:もしtrueなら、ゴールドは次のシナリオの開始資金に付け加えられる。もしfalseなら、次のシナリオは現在シナリオの量で始まる(課税後)か、次のシナリオの最小限で始まる。デフォはfalse。

・music:(デフォでは[scenario]ないし[game_config]タグで特定される)音楽トラックのコンマで分離されたリスト。その中から一つが選ばれ、演奏される。これはレベル結果の終わりに関係するあらゆるイベントが発動後。デフォではvictory_musicが勝利に用いられ、defeat_musicが敗北に用いられる。

・end_text:キャンペーンの終わりに黒い画面の真ん中に表示されるテキスト。デフォは「The End」。注意せよ。これはそのキャンペーンに累加的な(cumulative)効果を持つ―たとえendlevelがキャンペーンの最後に発生しなくとも。CampaignWMLも参照。

・end_text_duration:キャンペーン終わりにゲームクレジットが表示される前のミリ秒のディレイ。換言すれば、end_textが画面に表示されるのがどのぐらいの時間かということ。デフォでは3500。以下略

 

  • [unit]:マップ上にユニットを置く。シンタックスに関してはSingleUnitWML参照。
    (ヒント:GENERIC_UNITマクロを用いろ)

○to_variable:そのマップでの代わりにある変数へと直接発生する。

 

  • [recall]:あるユニットを召喚する。そのユニットはチャージ料なしで召喚され、リーダーの近くに配置される。
    ○StandardUnitFilter:最初に合致するユニットが召喚される。もしどのユニットも合致しないなら、このタグは無視される。[filter]タグはつかうな。
    ○x,y:そのユニットは、リーダーの隣ではなく、この場所に配置される。
    ○show:もしnoでないなら、ユニットが召喚される様が表示される。

 

  • [teleport]:マップ上のあるユニットをテレポートさせる。
    (ヒント:TELEPORT_UNITマクロを使え)
    ○[filter]:StandardUnitFilter そのフィルターに合致する全てのユニットがテレポートされる。
    ○x,y:テレポート先の場所
    ○clear_shoroud:到着で幕がクリアされるべきか。
    ○animate:テレポートアニメが再生されるべきか。(もしユニットがテレポートアニメなしなら、ユニットはフェードアウトないしフェードインする)
    ○ignore_passability:(Development version only)普通は移動不可地形にテレポートできない。

 

  • [terrain_mask]:マップの地形を変える。TerrainMaskWML参照

 

  • [terrain]マップ上の地形を変える
    ○terrain:使用する地形の文字。地形のタイプでどんな文字を使うかはTerrainCodesWML参照。
    ○x,y:変える場所(ないし場所の範囲)
    ○layer:(overlay|base|both, default=both)特定のレイヤーのみ変える
    ○replace_if_failed:(default=no)役に立たなくなったただ一つのレイヤーを置き換える時、全地形を置き換えようとする。もしterrainがoverlayの地形であるなら、default_baseをbaseレイヤーとして用いよ。もしその地形がdefault baseを持たないなら、何もするな。

 

  • [gold]:一つのサイドに金を与える
    ○amount:与える金の量
    ○side:(default=1)金を与えるサイドの数

 

  • [unstore_unit]:ゲームの変数からあるユニットを作り、そしてプレイしているフィールドにそれをアクティベイトする。これはあるユニットを記述する特定の変数でなければならない。また配列(array)でなくともよい―ある完全な配列をunsoreし、それを反復するため。その変数はクリアーされない。[store_unit],[while],[clear_variable]も参照。注意:負の量のHPを持つユニットはHP1でunstoreされるだろう。
    ○variable:変数の名前
    ○find_vacant:そのユニットが特定の場所に最も近い空きタイルに置かれるべきか否か。もしこれがno(default)にセットされるなら、unstoreされるユニットと同じタイル上のいかなるユニットも破壊されるだろう。
    ○text:(translatable)ダメージ量のように、ユニットの上に表示する浮かんだテキスト。
    ○red,green,blue:(default=0,0,0)textが表示される際の色。値は0-255で変化する。分かるだろうけど、代わりに{COLOR_HARM}ないし{COLOR_HEAL}マクロを用いた方が便利だ。(全部のred,green,blue=lineの代わりにこれらマクロを使え)
    ○advance:(default=true)もしtureなら、ユニットが十分なXPを得た時、レベルアップする。When modifying XP make sure to do it from inside a synchronized event or it may lead to OOS errors especially when several advancement paths exist.
    ○x,y:ユニットの場所を変更する

 

  • [allow_recruit]:あるサイドに以前は雇用できなかったユニットを雇用できるようにする。
    ○type:そのサイドが今雇用できるユニットのタイプ
    ○side:(default=1)そのユニットを雇用できるようにされたサイドの数

 

  • [disallow_recruit]:あるサイドが、以前雇用できたユニットを雇用できなくする。
    ○type:そのサイドがもう雇用できないユニットのタイプ
    ○side:(default=1)もうそのユニットを雇用できないサイドの数

 

  • [set_recruit]:あるサイドが雇用できるユニットをセットする。
    ○recruit:そのサイドが今雇用できるユニットのタイプ
    ○side:(default=1)その雇用をセットされているサイドの数

 

  • [modify_side]:シナリオの半ばで特定サイドの詳細を修正する。以下にリストされた特性は、[modify_side]が影響しうる唯一の特性である。
    ○side:(default=1)変更されるべきサイドの数
    ○income:各ターンの最初に与えられる収入
    ○team_name:そのサイドがシナリオをプレイする際のチーム
    ○user_team_name:チームの記述を表す翻訳可能なstring。これは同盟に影響しない。team_nameにとってのデフォ。
    ○gold:そのサイドが所有するゴールドの量
    ○village_gold:そのサイドにとっての村ごとに設定する収入
    ○controller:そのサイドのコントローラーの識別string。[side]タグの中でcontrollerキーの同じシンタックスを用いる。
    ○fog:そのサイドのための霧の状態を記述するboolean string(yes/no)
    ○shoroud:そのサイドのための幕の状態を記述するboolean string
    ○hidden:ステータステーブルにサイドが表示されるか否かを特定するboolean string
    ○[ai]:あるサイドのAIパラメーターを新しい特定のものと置き換える。AiWMLで記述される同じシンタックスを用いる。
    ○switch_ai:(Development version only)
    ○share_maps:(Development version only)
    ○share_view:(Development version only)

 

  • [modify_turns]:シナリオの途中でターンリミットを修正する。
    ○value:新しいターンリミット
    ○add:もしvalueの代わりに用いられるなら、現在のリミット(負でもありうる)に追加するターン数を指定
    ○current:ターンリミットの修正を適用した後、現在のターン数を変化する。現在のターン数を現在のものより大きいものに変えることは可能である。また、ターンリミットを超えるようにターン数を変えることは不可能である。

 

  • [capture_village]:村の所有を変える
    ○side:村のコントロールを取るサイド。もし与えられなければ、村は中立になる。
    ○x,y:村の場所

 

  • [kill]:ゲームからフィルターに合致する全てのユニット(召喚リストのユニットを含む)を排除する。
    ○StandardUnitFilter:選択基準。[filter]タグを使うな。
    ○animate:もしyesなら、ユニットが死ぬ様を表示する。
    ○fire_event:もしyesなら、何らか固有のdieイベントを引き起こす(EventWML参照)。注意せよ。これによって引き起こされるいかなるlast breathやdieイベントも、直ちに実行され、現在のイベントを中断させ、x1, y1, x2, y2の変数は、dieイベントのためにリセットされる。それが今度はそうした変数を、このイベントのリマインダーにとって妥当なものにする。

 

  • [unpetrify]:ソノフィルターに合致する全てのユニットを石化解除する。(Development version only)1.6以前では、これは[unstone]である。

 

  • [object]:あるユニットにあるオブジェクトを与える。そしてそのユニットがいるタイル上の全てのアイテムを排除する。
    ○id:(任意)オブジェクトが拾われると、フラグがidのためにセットされる。オブジェクトは、idのためのフラグがセットされていると、拾えない。これは、idを持ついかなるオブジェクトも一回だけ用いられうるということを意味する。それはたとえ、first_time_onlyがそのイベントのためにセットされているとしてもである。この制限はレベルごとである。キャンペーンでは、同じidのオブジェクトはレベルごとに一度だけ割り当てられうる。
    ○[effect]一つ以上の要素がリストされるだろう。[effect]の記述についてはEffectWML参照
    ○duration:もしlevelなら、効果はそのレベルの最後まで続く。(注意:levelはそのシナリオのことであり、これはユニットがレベルアップするまで続くと言うことを意味してはいない)
    ○[filter]:独立変数(argument)としてのStandardUnitFilterと共に。そのフィルターと合致すると見出された最初のユニットはそのオブジェクトを与えられる。もしどのユニットもそのフィルターに合致しないなら、メッセージが表示され、そのオブジェクトは排除されない。
    ○[then]:そのフィルター条件が合致する場合に、君にアクションを実行させるサブタグである。この中にある最も普通のアクションは、[removeitem]タグである。しかし、君はおそらく、さもなければ[then]タグの中で働くあらゆるタグを置くだろう。
    ○silent:メッセージが無くされるべきか否か。デフォではno。
    ○image:そのオブジェクトの表示されるイメージ
    ○name:(翻訳可能)イメージのキャプションとして表示される。
    ○user_description:(翻訳可能)イメージのメッセージとして表示される。
    ○cannot_use_message:(翻訳可能)もしどのユニットもフィルターテストに通らないなら、descriptionの代わりに表示される。
    ○もし君がフィルターを提供しないなら、そのオブジェクトアクションはmovetoイベントの場所にいるあるユニットに割り当てられる。今はこれは推奨されない。これがこのように働き続けることは明らかでないからだ。代わりに、場所フィルターを明確に含む方がよい。
    ○オブジェクトアクションは召喚リストにいるユニットに作用しない。これを許可するための特別なリクエストが存在する。が、それが受け入れられるか否かは明らかでない。

 

  • [remove_shroud]:あるサイド(shroud=yesを有するサイドにのみ関わる)に対して、そのマップから幕を取り除く。
    ○side:(default=1)幕を取り除くサイド
    ○StandardLocationFilter:幕が取り除かれるタイルの範囲

 

  • [place_shroud]:あるサイド(shroud=yesを持つサイドにのみ関わる)に対してそのマップ上に幕を置く。
    ○side:(default=1)幕を置くサイド
    ○StandardLocationFilter:幕が置かれるタイルの範囲

 

  • [allow_undo]:プレイヤーに、このタグの内にあるイベントをアンドゥする許可を与える。movetoイベントの中でのみ効果を持つ。もしその移動がアンドゥされるなら、そのユニットの場所だけが保存されるだろう。ゲームに対する代替の変数や変更は、移動がアンドゥされた後も変更されたままである。このコマンドの誤用を避けることはシナリオデザイナー次第である。
    ○技術的には、もし[allow_undo]がfirst_time_only=yes(デフォ)を伴う[event]の中にあり、ユーザーがそのイベントをアンドゥするなら、ゲームの状態はこのようにして変化した。そのイベントは、ユーザーが最初に移動をアンドゥしたとしても、2回目には起こらない。

 

  • [heal_unit]:あるユニットを回復する。変数$heal_amountは、回復されるポイントの正確な数をセットする。(すなわち、もしそのユニットが完全に回復されるなら、パラメーターamountよりも少ないだろう)
    ○[filter]:StandardUnitFilter そのフィルターに合致する最初のユニットが回復される。
    ○[secondary_unit_filter]:StandardUnitFilter そのフィルターに合致し、healsアビリティを持っている全てのユニットはそのアニメーションを起こす。(もしanimateがtrueにセットされているなら)
    ○amount:ユニットが回復される最大ポイント
    ○animate:もしヒーリングアニメーションがプレイされなければならないなら、示すboolean。

 

  • [time_area]:一日が特定のエリアでどのように進行するか。[time_area]タグで特定されていない場所はどこも、[scenario]タグ内の[time][illuminated_time]タグによって影響される。
    ○StandardLocationFilter:影響する場所
    ○TimeWML:新しいスケジュール
    ○id:あるtime_areaに割り当てられる固有の識別名。君が後でtime_areaを排除したいのでないなら、任意。time_areasを排除する時、コンマで分離されたリストでありうる。以下を見よ。
    ○remove:(boolean)yes/no値。特定のtime_areaが排除されるべきか否かを示す。ある識別名を要求する。しかし、もしどんな識別名も用いられないなら、全てのtime_areasは排除される。

 

  • [end_turn]:現在のサイドのターンを終わらせる。(Development version only)


有用なマクロ

 

ダイレクトアクションにとって有用な既定のマクロがいくつかある。詳細はこちらhttp://www.wesnoth.org/macro-reference.xhtml(ダウンロード)。

 

{MOVE_UNIT}: あるユニットをそのマップの別の場所へ移動させる。そしてプレイヤーはその移動を見る([teleport]とは違う)。

{FULL_HEAL}: あるユニットを最大HPまで回復

{LOYAL_UNIT}: 忠義ユニットを作成

{MODIFY_TERRAIN_MASK}: 地形のあるエリアを修正

 


 

InterfaceActionsWML

 

Interface actions

インターフェイスアクションは、ゲームプレイに影響はしないが、代わりに、プレイヤーに何かを示すアクションである。主なインターフェイスタグは[message]と[objectives]であるが、いくつか他のタグがインターフェイスに影響する。

 

[message]

最も普通に用いられるインターフェイスアクションは[message]である。これはダイアログボックスにおいてユーザーにメッセージを見せる。これはまたユーザーからのインプットを受けるためにも用いられる。

 

以下のキーないしタグは[message]に受け入れられる。

 

  • StandardUnitFilter:プロフィールや名前が表示されるユニット。[filer]タグを用いるな。もしこのフィルターに合致するユニットが見つからなければ、そのメッセージは表示されない。(そのユニットはおそらく殺されてしまっている)

[message]要素は、特定のユニットが生きていることを保証されるか、あるいはメッセージが表示されずともダイアログがスムーズに流れるように構成されるべきである。

  • speaker: standard unit filterに対する選択。ユニットidが元となるスピーカーの値ないし以下の特別な値として特定する。
    ・narrator: そのダイアログボックスは、話しているユニットやあるユニットイメージのためのキャプション無しに表示される。
    ・unit: そのイベントのprimary unitが話している。
    ・second_unit: そのイベントのsecondary unitが話している。
  • message: (翻訳可能)そのイメージの右に表示するテキスト。messageは時々、複数のラインに渡る。もしそうなら、必ず引用符('or")を用いること。
  • [show_if]: もしpresentなら、このメッセージはこのタグ内の条件言明がパスされる場合に表示されるのみである。(ConditionalActionsWML参照)
  • side_for: (デフォは全サイド)メッセージが表示されるサイドのコンマで分離されたリスト。
  • image: (デフォは話者のプロフィール画像)メッセージの隣に表示する画像。
  • caption: (デフォは話者の名前)画像の脇に表示するキャプション。表示される名前。
  • duration: (デフォは10)表示されるこのメッセージのためのフレーム最小数。(1フレームは約30ミリ秒続く)この時間の間、ダイアログの決定は無視される。
  • sound: メッセージが再生される際に演奏されるサウンド効果(wavファイル)。これはコンマで分離されたリストでありえ、そこから一つがランダムに選ばれる。
  • [option]: 0以上の[option]要素がpresentかもしれない。もし[option]要素がpresentなら、それぞれの選択肢はユーザーが一つの選択肢を選ぶために、メニューに表示される。
    message: (翻訳可能)選択肢のために表示されるテキスト(DescriptionWML参照)
    [show_if]: もしpresentなら、この選択肢は、このタグ内の条件言明がパスされる場合に表示されるだけだ。(InternalActionsWML参照)
    [command]: もしその選択肢が選択されると、実行されるアクションを含む要素。
  • [text_input]: [text_input]タグのみがありうる。これはそのメッセージにテキスト入力欄を追加する。
    variable: ユーザーの入力が書かれる変数
    label: 入力欄の左にあるラベル
    max_chars: その欄にタイプされうる文字の最大数
    text: 初めその欄に書かれているテキスト
  • OOSを引き起こすことなく、[option]および[text_input]を安全に用いることができるのはどのイベントにおいてか、知るためには、EventWML#Multiplayer_safetyをチェックせよ。


Formatting

 

[message]のための選択肢の体裁を整えるテキスト。これらは、ユニット名(user_description)、目標などで用いられうる。(訳注:以下はマルチプレイのラベルでも使える)

 

  • チルダ (~) :そのラインを太字にする語頭の文字
  • アットマーク (@) :そのラインを緑色にする語頭の文字(勝利条件など)
  • シャープ (#) :そのラインを赤色にする語頭の文字(敗北条件など)
  • アスタリスク (*) :そのラインをより大きくする語頭の文字
  • バッククォート (`) :そのラインをより小さくする語頭の文字
  • もし使用されれば、そのキャプションのキーテキストは太字になる。
  • 最初のRGBカラーコードは、そのラインを既定の色にする。これは上述の文字の前に置く。例:message=_"<255,0,0>Red!"

以下(Development version only)省略


[objectives]

 

プロット開発で用いられる他のタグが[objectives]である。[objectives]タグは、以前にセットされたobjectivesを上書きし、そのシナリオの目標を記述するテキストを表示する。シナリオの目標はプレイヤーの最初のターンに表示されるが、その前にそのタグが用いられるか、あるいはプレイヤーのターン中に発生するのなら、そのイベントの一部分として用いられる。目標は「シナリオの目標」ゲームメニューオプションを用いるシナリオでいつでもアクセスされ、プレイヤーがプレイ中に参照する必要のあるシナリオの具体的な情報によって、このタグを有用にする。

 

このタグは[scenario]のobjectives属性を無用にする(objectives, ScenarioWML参照)。objectivesを用いる代わりに、現在のイベント内でシナリオの目標をセットするために[objectives]を用いよ。また、シナリオの途中で、最初の目標を上書きするために用いられうる。

 

[objectives]の属性

 

  • side: デフォは0。目標がセットされるサイド。0値は全てのサイドに目標をセットする。
  • summary: 目標テキストにおいて最初に表示される。これはシナリオ全体の基本目標を記述する。省略可。
  • note: 目標テキストにおいて最後に表示される。これは時々、ヒントや付加情報のために用いられる。省略可。
  • victory_string: デフォは、 _ "Victory:"。このテキストは勝利目標に先行する。
  • defeat_string: デフォは、 _ "Defeat:"。このテキストは敗北目標に先行する。
  • silent: デフォは、not present。もしyesにセットされると、目標は暗黙の内に変更される。その代わり、appropriate時に、ユーザーに示される。

 

[objectives]のタグ

 

  • [objectives]: 勝利ないし敗北条件の記述。ほとんどのシナリオは、複数の勝敗条件を持っている。だから、各ラインに分離された[objective]というサブタグを用いよ。これは翻訳を助ける。
    description: 具体的な勝敗条件に関するテキスト
    condition: テキストの色と場所。値はwin(緑色、victory_stringの後)かlose(赤色、defeat_stringの後)
    [show_if]: もし持たないなら、その目標を不可能にする条件。条件付きの目標は、[show_objectives]時にのみ回復する。

 

マクロ

 

コードを短くするために用いることのできる目標のための既定のマクロが少しある。SET_OBJECTIVES, VICTORY_CONDITION, DEFEAT_CONDITION。完全なシンタックスや使用例を見るためにはリンクをたどれ。


[set_menu_item]

 

このタグは、右クリックメニューにカスタムオプションを追加するために用いられる。このカスタムオプションは、任意のWMLコマンドを発生させるのに用いられうる。

 

  • id: このメニューアイテムの固有id。もしこれを伴うメニューアイテムが存在するなら、これがそのアイテムに対する具体的な変更をセットできるようにする。
  • description: そのメニューでこのアイテムのために現れるゲーム中のテキスト
    image: このアイテムの隣に表示される画像
  • needs_select: もしyesなら(デフォはno)、このメニューアイテムが選ばれる前に発生した最新の選択イベント(EventWML参照)は、このメニューアイテムアクションが伝えられる前に、ネットワーク上に伝えられる。これは、ネットワークのマルチプレイヤーにおいて影響を持つだけである。OOSエラーを引き起こさずに、そこでもっと精巧なメニューアイテムの振る舞いを可能にするように作られている。 意味が分からないなら、ただfalseにしておけ。
  • [show_if]:もしpresentなら、そのメニューアイテムは、条件付きの言明(InternalActionsWML参照)がtrueの場合にのみ利用可能となる。WML値$x1と$y1は、コンテクストメニューが関係した場所を指し示すだろう。従って、例えば、空のヘクスや特定のユニットにおけるオプションを可能にすることはできる。
  • [filter_location]: Single Unit Filters(FilterWML参照)内で見出されるものと類似の場所(location)を含む。そのメニューアイテムは、合致する場所において利用可能となる。
  • [command]: そのメニューアイテムが選ばれる時に、発動されるWMLアクションを含む。再び、WML値$x1と$y1は、コンテクストメニューが関係した場所を指し示すだろう。

 

Other interface tags

 

以下のタグもまたアクションタグである。

 

  • [item]: グラフィカルなアイテムが特定のヘクスに現れるようにする。注意せよ。これはあるアイテムのグラフィックを置くだけだ。そのアイテムが何かをするようにはしない。そのアイテムの上に移動することで何かをさせるようにするには、movetoイベントを使え。(ヒント:君が利用でき、様々なキャンペーンで用いられる既定のアイテムがたくさんある。もし君がwesnothのインストールディレクトリの中のitem.cfgファイルを探すなら、a_list_of_themを見つけられる。(/data/core/macrosの下))
    x,y: そのアイテムを置く場所
    image: そのヘクスに置く画像(images/の中、.pngとして)
    halo: そのヘクスの中心に置く画像。もし画像がヘクスよりも大きいなら、imageの代わりに使え。
    team_name: そのアイテムが表示されるチーム名(他には隠される)。というのは、複数のチームのためには、一つのstringに全ての名前をコンマで分けて置け。
    visible_in_fog: そのアイテムが霧を通して見えるか否か。デフォではyes。
  • [removeitem]: 特定ヘクスのグラフィカルなアイテムを取り除く
    x,y: アイテムを取り除くヘクス
    image: もし具体化されるなら、特定のイメージアイテムを取り除くだけ。
  • [print]: 画面を横断するメッセージを表示する。このメッセージは、特定の時間が経てば消える。
    text: (翻訳可能)表示されるテキスト
    size: (default=12)使用するフォントのポイントサイズ
    duration: (default=50)そのテキストを表示する時間の長さ。これはフレーム数で計られる。wesnothにおける1フレームは、通常約30ミリ秒間表示される。
    red, green, blue: (default=0,0,0)そのテキストを表示する色。値は0-255で変化する。
  • [move_unit_fake]: そのマップ上の特定の道を通ってユニットの画像を動かす。その道は、隣接したヘクスの連続的なリストである必要はない。例えば、最初と最後が与えられうる。そうした場合、それらの地点の間の最短ラインが計算され用いられる。
    type: 用いる画像を持つユニットのタイプ
    x: 移動するx位置のコンマで分割されたリスト
    y: 移動するy位置のコンマで分割されたリスト(xとyの値はペアで組み合わされる)
    side: ファイクユニットのサイド。フェイクユニットにチーム色を付けるのに用いられる。
  • [hide_unit]: 特定ユニットを見えなくする。あるリーダーユニットを画面上で場所を移させるために、[move_unit_fake]と連接すると有用。それぞれの[hide_unit]タグはただ一つのユニットを隠すだけだ。
    x, y: 隠されるユニットの位置。(standard unit filterではない。ただxとyだけだ)
  • [unhide_unit]: 現在隠れているユニットを隠れないようにする。
  • [scroll]: 特定の方向に特定のピクセル数スクロールする。地震などの効果として有用
    x, y: x,y軸に沿ってスクロールするピクセル数
  • [scroll_to]: 特定ヘクスにスクロールする。
    x, y: スクロール先のヘクス
    check_fogged: 霧や幕で覆われている場所にさえスクロールするか否か。可能な値はtrue(霧にはスクロールしない)かfalse(霧にさえスクロールする)。デフォではfalse。
  • [scroll_to_unit]: 特定ユニットまでスクロール
    StandardUnitFilter
    check_fogged: 霧や幕で覆われている場所にさえスクロールするか否か。可能な値はtrue(霧にはスクロールしない)かfalse(霧にさえスクロールする)。デフォではfalse。
  • [sound]: サウンドを演奏する
    name: プレイするサウンドのファイル名(sound/内、.wavか.oggとして)
    repeat: そのサウンドを指定の追加回数分だけ繰り返す。(デフォは0)
  • [sound_source]: サウンドソースを作る。サウンドソースは、なんらかのルールに従ってサウンドを発するマップ要素のために可能にするメカニズムのための一般的な名前。そこでマップ要素は具体的な場所ないし地形タイプでありうる。今のところ、場所に限定されたサウンドソースのみがサポートされている。
    id: a unique identification key of the sound source
    sounds: a list of comma separated, randomly played sounds associated with the sound source
    delay: a numerical value (in milliseconds) of the minimal delay between two playbacks of the source's sound if the source remains visible on the screen; if one scrolls out and back in, the source will be considered as ready to play
    chance: a percentage (a value from 0 to 100) describing the chance of the source being activated every second after the delay has passed or when the source's location appears on the screen (note that it cannot play more than one file at the same time)
    check_fogged: possible values "true" and "false" - if true the source will not play if its locations are fogged
    check_shrouded: (Development version only) possible values "true" and "false" - if true the source will not play if its locations are shrouded
    x,y: a StandardLocationFilter for the locations associated with the sound source
    fade_range (default = 3): distance in hexes that determines a "circular" area around the one specified by full_range where sound volume fades out linearly
    full_range (default = 14): distance in hexes that determines a "circular" area where source plays with full volume, relative to screen center
    loop: number of times a sound sample should be looped if it stays visible. -1 means infinite (~65000)
  • [remove_sound_source]: 以前定義されたサウンドソースを取り除く
    id: 取り除くサウンドソースの識別キー
  • [music]: 異なる音楽を演奏するスイッチ
    name: 演奏する音楽のファイル名(music/内、.oggとして)
    正確なシンタックスについてはMusicListWML参照
  • [colour_adjust]: 画面の色に色合いを付ける
    red,green,blue: 値は-255から255まで。各色に関して色合いを付ける量。
  • [delay]: ゲームにポーズをかける
    time: ミリ秒単位でポーズをかける時間
  • [redraw]: 画面を描き直す。(これは普通イベント中には為されない。ただし他のインターフェイスアクションのいくつかが、画面ないしその一部を再描写させるが)
    side: もし用いられれば、そのサイドに関して霧や幕が再計算される。イベント中にフレンドリーユニットを生み出し、結果として幕を更新したいなら、役に立つ。(さもなければ、霧の中に生じたユニットは、イベント継続中は目に見えないままであろう。霧は彼らの周囲から自動的に取り除かれるないから)
  • [unit_overlay]: 特定ユニットの上に描かれるイメージをセットする。
    x, y: オーバーレイするユニットの場所。
    image: そのユニットに置く画像。
  • [remove_unit_overlay]: あるユニットから、特定のオーバーレイされた画像を取り除く。
    x, y: オーバーレイを取り除くユニットの位置。
    image: ユニットから取り除く画像
  • [animate_unit]: 画面上でユニットをアニメイトするために、ユニットのカスタムアニメーションを用いる。 (もしそのユニットが対応するアニメーションを持っているなら)
    flag: ユニットの記述におけるよいカスタムアニメーションを見つけるキー。AnimationWMLにおける[extra_anim]記述を見よ。標準的なanimsは、以下のキーワードで発生しうる。leading, recruited, standing, idling, levelin, levelout, healing, healed, poisoned, movement, defend, attack, death, victory, pre_teleport, post_teleport
    [filter] 独立変数としてのStandardUnitFilterを伴う。FilterWML参照。デフォでは、そのイベントの場所にいるユニットがアニメイトされる。このタグを用いることでアニメイトする他のユニットを選ぶことができる。
    [primary_attack]: もしこのタグがpresentでないなら、アニメーションのためのフィルターは攻撃とは関係なく発動する。もしここにあるなら、そのユニットからの全ての攻撃はフィルターにかけられ、合致するものは、そのアニメーションにフィルターをかけるために用いられる。
    [secondary_attack]: 同上。second attackに関わる。
    hits: ユニットにフィルターをかけるヒットタイプ
    text: アニメーション中に浮かぶテキスト
    red: テキスト色に関する赤の値
    green: テキスト色に関する緑の値
    blue: テキスト色に関する青の値
    with_bars: ステータスバーを表示するか否か
    [animate]: ユニットを発見するために[filter]ブロックが必須である場合を除き、[animate_unit]と同じシンタックスを伴うサブブロック。このブロックは同時に別のユニットを見つけ、アニメイトする。
    [facing]: アニメートされる時、そのユニットが向かう方向を具体化するStandardLocationFilter。
  • [label] マップ上にラベルを置く。
    x, y: そのラベルの位置
    text: そのラベルが言うこと
    team_name:  もし具体化されるなら、そのラベルは特定チームにのみ見える。
    visible_in_fog:  そのラベルが霧を通しても見えるか否か。デフォではyes
  • [deprecated_message] メッセージエリア上の非難(deprecated)メッセージを示す。この特徴はメインラインの非難マクロについて警告するために用いられる。そのメッセージは翻訳されない。
     message: 示すメッセージ
  • [wml_message]  メッセージを、wesnothのコンソールアウトプットへとアウトプットする。キャンペーンデザイナーが、プレイヤーを煩わせることなく、暗黙のテキストをコンソールにアウトプットするよう意図されている。そのテキストは後のバグレポートに役立つ情報を含む。(以下大幅に略)
    message: 示すメッセージ
    logger:
  • [open_help] ゲーム中のヘルプを開く。
    topic:  開くトピックのid
  • [show_objectives]: (Development version only)

 

有用なマクロ

 

インターフェイスアクションに役立つ既定のマクロがいくつかある。詳細についてはこちらhttp://www.wesnoth.org/macro-reference.xhtml

 

  • {FLOATING_TEXT} ダメージ数と同じようにユニットの上にテキストを流す
  • {HIGHLIGHT_UNIT} マップ上のあるユニットをハイライトする。重要なユニットを示すのに使え。
  • {HIGHLIGHT_IMAGE} マップ上にある画像を置いてこれをハイライトする。重要なアイテムないし場所を示すために使え。
  • {SET_IMAGE} マップ上に他の機能を持たない画像を置く。
  • {QUAKE <soundfile>} 画面振動のような揺れを作り、<soundfile>を演奏する。 ({TREMOR} は非難バージョン、 {QUAKE (rumble.ogg)}と同じ)
  • {FLASH_WHITE} 瞬間的に画面を白く光らす。WHITEを異なる色REDやBLUEやGREENに置き換えられる。

  


 

 InternalActionsWML


インターナルアクションはゲームプレイに直接的な影響を与えない、WMLが内的に用いるアクションである(あるいは、少なくとも、プレイヤーにはすぐ見えない)。例えば、変数の蓄積はインターナルアクションである。

 

変数アクション

 

これらのアクションは、一つないし別の方法で、variablesに焦点を当てる。それらを作り、修正し、ゲームデータをそれらに入力しする。君はそれを名付ける。これらのアクションが変数に関する全てだ。

 

[set_variable]

 

[set_variable]タグは、WML変数を作成し、操作するために用いられる。VARIABLEマクロは簡単な変数作成のためのクイック・シンタックス・ショートカットである。VARIABLE_OPマクロは、変数に対する簡単な数学的操作を実行するためのクイック・シンタックス・ショートカットである。

 

・name:操作する変数の名前
・value:変数を特定の値にセットする(数字ないしstringでありうる)。代入が無いならliteralを使え(VariableWML参照)
・literal:変数を特定の値にセットする(数字ないしstringでありうる)。これはいかなるドル印も解釈しない。
・format:この属性は1.7から以下略。valueと同じ振る舞い。
・to_variable:特定の変数の値に変数をセットする。例えば、to_variable=tempはvalue=$tempと同じ。
・add:その変数に特定の量を追加。引き算するためには、負の数を加えよ。
・sub(Development version only)
・multiply:その変数に特定の数をかける。割り算するためには、逆をかけろ。例:2で割りたかったら、0.5をかける。負にしたければ、-1をかけろ。Floating point valuesは四捨五入されない。
・divide:変数を特定の数で割る。その結果は整数である。Floating point valuesは四捨五入されない。もし両変数が整数なら、Integer_divisionが用いられる。
・modulo:割り算のリマインダーを戻す。
・random:その変数はランダムにセットされる。
可能性のあるコンマ分割リストを与えられる。例:random=Bob,Bill,Bella
数(整数)の範囲を与えられる。例:random=3..5
これらを組み合わせられる。例:random=100,1..9 この場合、1/10の確率で100ないし1から9のどれかになる。
・rand:ランダムと同じだが、よりよいMPサポートを持つ。MPの場合の詳細はBuildingMultiplayerExamples参照。ランダム化のこの特性を用いることが強く推奨される。
・time=stamp:wesnothが始められてから、ミリ秒のタイムスタンプを回復する(retrieve)。タイミングの助けとして用いられうる。OOSエラーが発生するので、MP内のランダム値としてこれを使うな。
・string_length:この属性の値としてとおされるstringのcharactersの長さを回復する。そうしたstringは構文解析され、変数の代入は自動的に適用される。(詳細はVariablesWML参照)
・[join]:テキスト状のリストを作成するため、stringsの配列を加える。
○variable:その配列の名前
○key:それぞれの配列要素(array[$i].foo)のキー。その中にstringsが蓄えられる。
○separator:諸要素を繋ぐセパレーター
○remove_empty:空の要素を無視するか否か。
・ipart:参照される変数の整数部分(コンマの左部分)を割り当てる。
・fpart:参照される変数の小数部分(コンマの右部分)を割り当てる。
・round:その変数を、プレシジョンの特定の桁数で四捨五入する。負のプレシジョンは予期される通りに働く(19517を-2で四捨五入すると19500)。
○ceil:最も近い整数に切り上げる。
○floor:最も近い整数に切り下げる。

 

[set_variables]

 

WML配列を操作する。

 

・name:操作するコンテナの名前
・mode:以下の値の一つ
○replace:配列のnameを消して、特定のデータで置き換える。
○append:特定のデータにおいてnameに統合する。
○insert:name=my_array[1]のようなname属性において具体化されるインデックスに特定データを挿入する。デフォルトのインデックスは0であり、これは配列の前に挿入する。注意:もしある不適切なインデックスが用いられると、空のコンテナが、挿入の実行前に作成される。換言すると、その変数がそのインデックスに既にデータを含んでいない限り、インデックスに挿入しようとするな。この制限は将来のバージョンで取り除かれよう。
・to_variable:データは特定の配列にセットされる。
・[value]:[value]内のWMLはデータ内に蓄えられる。変数は直接挿入される。$印を避けるために$|を用いろ。君は複数の[value]タグを供給することによってWMLの配列を蓄えられる。(Example参照)
・[literal]:[value]と同じだが、変数は代入されない。[literal]と[value]は同じ[set_variables]タグで用いられない。つまり、[value]と[literal]タグのミックスを重ねることでは配列を作成できない。
・[split]データにセットされる配列にテキスト状のリストを分ける。
○list:分けられるテキスト状のリスト
○key:そのstringsが蓄えられている各配列要素のキー
○separator:諸要素を分割するセパレーター
○remove_empty:空の要素を無視するか否か。

 

ゲームデータの記録

 

これらのアクションは、ゲームデータのそれぞれの部分を記録し、変数に蓄える。それらは検査ないし操作されうる。

 

[store_gold]

 

あるサイドのゴールドを変数に蓄える。
・side:(デフォは1)ゴールドが蓄えられるサイド
・variable:(デフォはgold)ゴールドを蓄える変数の名前

 

[store_locations]

 

ある特定の基準をある配列にパスする一連の場所を蓄える。配列の各メンバーは、xとy(位置)やterrain(地形タイプ)やowner_side(村のみ)といったメンバーを持つ。

・variable:その場所を蓄える変数(配列)の名前
・terrain:地形コードのコンマ分割リスト。(可能な値についてはTerrainCodesWML参照)もしpresentなら、場所は、その場所の地形タイプのためのコードがリストされる場合に、選ばれるだけである。
・radius:もしpresentなら、場所フィルターのradiusヘクス内にある場所が蓄えられる。
・[filter]独立変数としてのStandardUnitFilterを伴う。そのフィルターに合致するそれらの上のユニットを伴う場所のみが蓄えられる。ユニットを伴う場所を蓄えるためにのみ空白のフィルターを用いろ。

 

[store_map_dimensions]

 

変数にマップの大きさを蓄える。

 

・variable:その値が保存される変数の名前。もしそれがスキップされるなら、map_size変数が用いられ、もしそれらが既に存在するなら、その内容が優先する。その結果はwidthやheightというメンバーを伴うコンテナ変数である。

 

[store_side]

 

変数にあるサイドについての情報を蓄える。その変数は'name', 'team_name', 'gold' and 'income', 'fog', 'shroud', 'hidden', 'user_team_name', 'colour', 'controller', 'village_gold', 'recruit'といったメンバー変数を含む。

・side:情報を蓄えられるサイド
・variable:情報を保存する変数の名前

 

[store_starting_location]

 

変数にあるサイドのリーダーの開始場所を蓄える。その変数は、x,y,terrain(開始場所のための地形タイプは、変えられない限り、常にKである。)、owner_side(村のみ)といったメンバーを持つ混合タイプである。

・side:開始場所が蓄えられるサイド
・variable:(デフォはlocation)場所が蓄えられる変数の名前

 

[store_time_of_day]

 

現在のシナリオから時刻情報をWML変数コンテナに蓄える。

・variable:(デフォはtime_of_day)その情報を蓄えるコンテナの名前。そのコンテナはTimeWMLで見出される同じ属性で満たされる。
・turn:(デフォは現在のターン数)時刻情報が回復されるターン数を変更する

 

[store_unit]

 

ユニットに関する詳細をコンテナ変数に蓄える。あるユニットが蓄えられる時、ユニット定義内の全てのキーやタグが操作され、他の者を[set_variable]と共に含む。これらのタグやキーのサンプルリストはここhttp://wiki.wesnoth.org/InternalActionsWMLUnitTagsで見つかる。もし君が、どんなキーが適切で、あるいは各キーにとって適切な値の範囲が何であるかについての疑問があるなら、[store_unit]イベントをコードし、ゲームをセーブし、どのキーがファイルにあるかを検討せよ(あるいは単にセーブファイルのどれかの[unit]タグを検討せよ)。

普通の利用は、それを変数に蓄えるために、[store_unit]を用いることによって、あるユニットを操作することである。続けて、その変数を操作し、それから修正された変数を伴うユニットを再作成するために[unstore_unit]する。

注意:蓄えられたユニットもまたそのフィールドに存在する。そして蓄えられた変数の修正は、そのユニットの統計を自動的には変更しない。君は[unstore_unit]を用いる必要がある。[unstore_unit]やFOREACHも参照。

・[filter]:独立変数としてのStandardUnitFilterを伴う。このフィルターに合致する全てのユニットが蓄えられる。もし複数のユニットが存在するなら、それらは変数の配列に蓄えられる。
・variable:そのユニットを蓄える変数の名前
・mode:デフォルトはalways_clear。これは合致が見出されるか否かにかかわらず変数をクリアする。もしmodeがreplaceにセットされるなら、合致が見出される場合にのみ、その変数はクリアされる。もしmodeがappendにセットされるなら、その変数はクリアされない。
・kill:もしyesなら、蓄えられるユニットはプレイから取り除かれる。これは、後で召喚リストを蓄える目的で、プレイヤーの召喚リストへのアクセスを排除するのに役立つ。

 

[store_villages]

 

特定の基準にパスする村の一連の場所を配列に蓄える。その配列の各メンバーは、x,y(場所),terrain(地形タイプ),owner_sideといったメンバーを持つ。

・owner_side:あるサイドの数。もしpresentなら、このサイドによって所有される村のみが選ばれる。もしowner_side=0なら、所有されていない村を蓄える。
・variable:その場所を蓄える変数(配列)の名前
・terrain:一連の地形文字。(可能な値についてはTerrainLettersWML参照)もしpresentなら、場所の地形タイプの地形コードがリストされる場合のみ、村が選ばれる。君は地形のコンマ分割リストを与えてよい。

 

[clear_variable]

 

これは特定の変数ないし配列を削除する。これは変数のセットを消すのに使うとよい。例えば、正しく振る舞うシナリオは、そのシナリオが終わる前に、次のシナリオに継続されるべきでないなんらかの変数を削除するだろう。

 

・name:クリアする変数の名前。複数のコンマ分割変数が与えられうる。

 

他のインターナルアクション

 

[fire_event]

 

WMLイベントを引き起こす。

 

・name:引き起こすイベントの名前
・[primary_unit]:(任意)そのイベントのための主体ユニット(普通は攻撃者)。召喚リストのユニットには決して合致しない。もし複数のユニットに合致するなら、一つだけが選ばれる。
○x,y:(任意)このユニットの場所
・[secondary_unit]:(任意)客体ユニットのためのものであるという点を除けば同上。
・[primary_attack]:primary attack filterにパスされる情報と新しいイベントにおける$weaponの変数
・[secondary_attack]:second attack filterにパスされる情報と新しいイベントにおける$second_weaponの変数

 

[insert_tag]

 

WMLとしての変数を挿入。換言すると、パスされる変数の値は、それらがWMLフォームで書かれたかのように、そのゲームに導入される。(Example参照)

 

・name:そのタグに与えられる["name"]。(The ["name"] to be given to the tag.) これは何かが起こる適切なWMLタグ名でなければならない。
・variable:その値をそのタグに挿入させる変数の名前

 

[role]

 

ある役割を割り当てるユニットを見つけようとする。

これは、もし君が、ゲーム中に何かを言うためにメジャーでない文字を選びたいなら、役に立つ。一度役割が割り当てられると、君は、その役割を持つユニットを識別するユニットフィルター内にrole=を使える。(FilterWML参照)

しかしながら、役割が割り当てられるかという保証はない。君はある役割が割り当てられたか否かを知るために[have_unit]を用いることができる(Condition_Tags参照)。このタグは、タイプによって探索を秩序立てるための修正と共にStandardUnitFilterを用いる([filter]無しに)。その役割を見出される最初のユニットのみをマークし、その役割の属性はその探索において用いられない。もしなんらかの理由で君は存在する役割を持つあるいは持たないユニットを探したいのなら、君は一つ以上の[not]フィルターを用いることができる。それは、そのマップ上のユニットに加えて召喚リストをチェックするだろう。普通の使用では、君はおそらく特定サイドにユニットが存在するように強制するside属性を含ませたいだろう。

・role:ユニットの役割として蓄える値。この役割は、この役割を割り当てるユニットを探す時、StandardUnitFilter内で用いられない。
・type:そのユニットがなりうる可能なタイプのコンマ分割リスト。もし何らかのタイプが与えられるなら、ユニットはリストされた順番でタイプによって探索される。もしタイプが与えられないなら、タイプに関してなんの特定の順序も保証されない。


WMLの配列を作成するために [set_variables]を使用する。

 

[set_variables]
    name=arr
    mode=replace
    [value]
        foo=bar
    [/value]
    [value]
       foo=more
    [/value]
[/set_variables]
{DEBUG_MSG $arr[0].foo}
{DEBUG_MSG $arr[1].foo}

 

これは二つのアウトプットメッセージを生み出す。前者はbarと言い、後者はmoreと言う。

 

[insert_tag] Example

 

[event]
    name=moveto
   
    [set_variable]
        name=temp.speaker
        value=Konrad
    [/set_variable]
   
    [set_variable]
        name=temp.message
        value= _ "Yo Kalenz!"
    [/set_variable]   
   
    [insert_tag]
        name=message
        variable=temp
    [/insert_tag]
[/event]

 

これは事実上、次と同じ。

 

[event]
    name=moveto
   
    [message]
        speaker=Konrad
        message= _ "Yo Kalenz!"
    [/message]
[/event]

  


 

SideWML

 

[side]タグ

 

[side]タグは特定のシナリオでのあるサイドを記述するのに使われる。

 

以下のキーが認識される。

 

・side:数字。このサイドのリーダーは、この数字によって表現されるタイルに置かれる(BuildingMaps参照)。サイドを定義する時、それらは、そのサイドの数が、これまで見られたサイドの数に対してチェックされる順番で定義されなければならない。

 

・controller:このサイドの移動がどのようにして入力されるか。
○ai:Wesnoth AIがこのサイドの移動を行う。これはデフォ設定。
○human:プレイヤーがこのサイドの移動を制御する。
○null:このサイドは移動する番を持たない。その[side]タグの内容から生み出されるリーダーを持たない。(それはなお[side]タグ内の[unit]タグからユニットを得ることができる。)

 

・no_leader:もしnoなら(デフォ)、そのサイドの主塔で始まるユニットを記述するキーは[side]タグの合図である。SingleUnitWML参照。注意せよ。もしそのキーx,yが含まれるなら、そのリーダーは主塔の場所とは関係なくそこから始まる。もしこのサイドが以前のレベルから召喚リストを持つなら、その召喚リストはあるリーダー(canrecruit=yesを用いる)のために探される。そしてもし一つが見出されるなら、[side]タグ内に記述されるものの代わりにそれが用いられる。リーダーユニットを定義するのに用いられる典型的なキーはtype(必須)、id、name、unrenamable=yesである。SingleUnitWML参照。

 

・recruit:ユニットタイプのリスト。そのシナリオの最初、そのサイドはこれらのユニットの雇用を得る。

 

・gold:このサイドの開始資金。デフォは100。(もしゴールドが、以前のシナリオから持ち込まれるなら、この値は最小開始資金である)

 

・income:このサイドの基礎収入。デフォは0。これはbase_incomeに付け加えられる。そのサイドの基礎収入を決定する[game_config]。(GameConfigWML参照)

 

・hidden:もしyesなら、サイドはステータステーブルに示されない。

 

・fog:もしyesなら、このサイドは視界内に無いいかなるタイルも見ることができない。最初を除いて。AIは現在、霧を無視するということに注意。

 

・shroud:もしyesなら、このサイドは視界内に移動しなかったタイルを見ることができない。AIは現在この幕を無視することを注意せよ。注意:shroud=noで、このチームはshroudを無視する。だからplace_shroudとremove_shroudタグを用いてそれを修正することはできない。もし君がそうしたいなら、shroud=yes、place_shroud/remove_shroudタグを用いよ。

 

・shroud_data:このチームが非幕化するエリアを記述する。
例:

|
|00011111000

これはマップ上の最初のコラム(縦棒)を変更しないで、2番目のコラム11タイルを変える。0は幕化、1は非幕化を意味する。{@filename}を用いて外部ファイルを呼び出すか(PreprocessorRef参照)、あるいは引用の中にそのデータを置くことができる。外部ファイルの作り方はBuildingScenariosShroudData参照。

 

・persistent:そのサイドが他のなんらかのシナリオに存在するか否か。もし1(yes)なら、他のシナリオにおけるそのサイドを識別するためにsave_id(次を見ろ)が用いられる。デフォでは、人間が操作するサイドは1(yes)、aiが操作するサイドは0(no)である。

 

・save_id:もし利用可能ならデフォのdescription。さもなければUnknown。前と次のシナリオに関するそのサイドのID。そのサイドの召喚リスト(そのサイドのリーダー含む)、雇用リスト、開始資金をシナリオからシナリオへ持ち越すために用いられる。また勝利ゴールド計算ダイアログの中に表示されるそのサイドの名前としても用いられる。(1.7.3以前のバージョンでは、持ち越し情報を回復するためのある余分な努力が必要とされる。SideSwitchingWML参照)

 

・team_name:チームの記述を表示する翻訳不可能なstring。同じteam_nameのサイドは同盟する。デフォはside。(Development version only)以下略。

 

・user_team_name:チームの記述を表示する翻訳可能なstring。これは同盟に何の影響も与えない。デフォはteam_name

 

・colour:数的な色インデックスないし色の名前(例:blue, purple, orangeなど)。数的な形態はdeprecateされる。デフォルトの数や対応する色のリストは、data/core/team_colors.cfgの内で見出されうる。

 

・flag:占拠された村を示すデフォルトのものの代わりに用いるカスタムフラグアニメーション。自動的なサイドカラーリングが適用される。
○例のアニメーションは、三つのフレームを持ち750ミリ秒でループする。
flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250

 

・flag_icon:そのステータスバーでプレイするサイドを示すカスタムフラグアイコン(24×16のサイズが推奨)。自動的なサイドカラーリングが適用される。

 

・village_gold:このサイドに与えられる村ごとのゴールド量。デフォではvillage_incomeと記述される。[game_config](GameConfigWML)。注意:もし君が村ゴールドを0にする必要があるなら、その変数を-1にセットせよ。

 

・share_maps:このサイドと同盟のサイドが、このサイドに見える地形全て(幕の上にある)を見られるか否か。

 

・share_view:このサイドと同盟のサイドが、このサイドに見えるユニット(FoW(fog)の上にいる)を見られるか否か。

 

・disallow_observers:観戦者がこのサイドのターンを見れないようにする。デフォはno。

 

・[ai]:もしcontroller=aiなら、そのAIにパラメーターを与える。AiWML参照。

 

・[village]:そのサイドがコントロールし始める村を記述
○その村のx,y位置。もし座標のペアが村でないか、別の[village]タグ内で繰り返されるなら、振る舞いは未定義になる。最近のゲームエンジンないしwmllintはこれらについて警告する。

 

・[unit]:そのサイドで始めるユニットを記述する。SingleUnitWML参照。もしそのサイドが召喚リストを有しており、ある場所を与えられないなら、その召喚リストで始める。注意:[unit]下のそのside属性は無視される。なぜなら、そのサイドは[side]のside属性に由来するから。

 

以下のキーはマルチプレイヤーのみ。省略。
  


 

SingleUnitWML

 

単体のユニットをいかに記述するか

 

このタグ、[unit]は、マップ上の単体のユニット、例えばKonrad、を記述する。これは[units]の中の[unit_type](ユニットのクラスを記述)とは違う。しかし、多くの同じキーを取るので、一般に、関連付けられる[unit_type]から引き継がれた性質を上書きできる。

 

以下のキーが認識される。

 

・type:そのユニットのユニットタイプのID。UnitTypeWML参照

 

・side:そのユニットが属すサイド。たとえそのユニットが変数内に作られるとしても、これは存在するサイドでなければならない。

 

・gender:そのユニットの性別を示すため、maleないしfemaleをセットできる。デフォはmale。しかし、もしそのユニットがfemaleしかないのなら、それはfemaleになる。

 

・x, y:そのユニットの場所。もしある場所が提供されず、そのユニットが属すサイドが召喚リストを有するなら、そのユニットは、召喚リストに生み出される。

 

・find_vacant:bool。デフォはno。サイドリーダーのためではなく、[side][unit]内でのみ機能する。もしfind_vacant="yes"で、x,yが提供されないなら、リーダーと最も近い空きへクスにユニットを生み出す。(もしマップにリーダーがいないなら、開始位置と最も近い空きヘクス)もしfind_vacant="yes"でx,yが妥当な場所なら、その場所と最も近い空きヘクスにユニットを生み出す。

 

・to_variable:そのマップ上にユニットを置くかわりに、特定の変数の中へそのユニットを生み出す。

 

・id:そのユニットの固有の識別名。これはプレイヤーに示されず、ユニットを識別し、フィルタリングするためにのみ用いられる。もし具体化されないなら、あるいはユニットが普通に雇用される時、各ユニットが固有のid属性を確実に持つようにするため、そのユニットとして、ランダムなユニットが生み出される。昔のバージョンでは、description属性が固有のIDを特定した。

 

・name:そのユニットのユーザーに見える名前。注意せよ。そのプレイヤーはこれを変更する「rename unit」アクションを用いるかもしれない。

 

・generate_name:(デフォは=yes)もしそのユニットに特定の名前が存在しないなら、まるでそのユニットが新たに雇用されたものであるかのように、新しい名前を生み出す。

 

・unrenamable:もしyesなら、そのユニットのユーザーに見える名前はプレイヤーによって変更されない。(いずれにせよ、そのユニットがそのプレイヤーのサイドにいる時にのみ可能)

 

・traits_description:表示されるそのユニットの特性の記述。しかし、もしそれが明確に特定されないなら、そのユニットの実際の特性の名前が代わりに用いられる。従って、普通はこれをセットする必要はない。

 

・random_traits:"no"は、各ユニットにランダム特性が生み出されるのを防ぐ。マルチプレイヤーゲームでリーダーを置かない場合や、そのユニットタイプに普通与えられるよりも少ない特性をあるユニットに与えたい場合にのみこれをセットする必要がある。あるユニットに特性を生み出すとき、そのユニットが既に与えられている最初の特性は排除される。そのユニットに対するmusthave特性(undead, mechanical)は与えられる。各リーダー(canrecruit=yes)にとって、が利用不可能であるような特性は、考慮から除外される。特性は、そのユニットタイプに許される最大限に達するまで、あるいはこれ以上利用可能な特性がなくなるまで、ランダムに追加される。ランダム特性は、MPゲームで用いられうる。しかし,あるイベントにおいて発生させられる時、リーダーや[side]定義内の他のユニットのためではない。

 

・random_gender:"yes"だと、男女の別を持つユニットの性別は50%で男、50%で女になる。もしそのユニットが唯一の性別しか持たないなら、正しい者が与えられる。

 

・canrecruit:リーダーのための特別なキー
○no:デフォ。ユニットはリクルートできない。
○yes:ユニットはリクルートできる。
普通、あるチームがcanrecruit=yesのユニットを一切制御しない時、そのチームは負ける。しかし、たとえ君のチームが負けたとしても、君はそのシナリオが終わるまで、君が有するユニットを何であれ使ってプレイし続ける。普通、一つのチームから雇用できるリーダーがいなくなるとシナリオは終了する。しかし、特別な勝利条件がキャンペーンではセットされうる。普通、君はcanrecruit=yesを持つサイドのリーダーをセットしたいだろう。もし君がそのリーダーに雇用させたくないなら、普通は、特別な勝利条件を設定するよりも、リクルートするユニットタイプを何も与えない方がよりよい。canrecruit=yesのユニットは維持費がかからない。従って、リーダーにはloyal特性を与える必要がない。

 

・variation:そのユニットが作成されるそれ自体のバリエーション

 

・upkeep:ユニットを維持するコスト量
○loyal:維持費無し。effect"loyal"で変更可能。(EffectWML参照)
○full:ユニットのlevel維持費。(UnitTypeWML参照)
○維持費をその数にセットするためには整数が用いられる
○デフォはfull
○リーダー(canrecruit=yes)はどんな維持費がセットされようが決して維持費を払わない。
○普通、君はこの値をについて失敗したくない。もし維持費のかからないユニットをあるサイドにあたえたいなら、そのユニットにloyal特性を付けよ。

 

・overlays:そのユニットにオーバーレイされる画像のリスト

 

・goto_x goto_y :コースを制御するUl設定。デフォは0,0。つまり、そのユニットはある方向にいかない。

 

・hitpoint:そのユニットのHP。デフォはtypeのための最大HP

 

・experience:そのユニットの経験値。デフォは0

 

・moves:そのユニットが残す移動ポイントの数。デフォはユニットタイプの移動力。

 

・resting:そのユニットがこのターンにまだ動いていないかどうか。あるユニットに残りのヒーリングを与えるか否か決定するのに用いられる。

 

・role:standard unit filterで用いられる(FilterWML)。[role]を使用してセットされうる。(InternalActionsWML参照)

 

・ai_special:そのユニットを違った風に行動させる。
○"guardian"そのターンに移動して何かを攻撃する場合以外でユニットは動かない。(だから、もしある的ユニットが射程内にいるなら、そいつは動くことができる)

 

・facing:そのユニットがどの方向を向くか。(これはそのユニットがいかに表示されるかにのみ影響する)
○可能な値は、se, s, sw, nw, n, ne。swの使用は「反対向き」(左向き)として選ばれる。seが普通の向き(右向き)である。

 

・profile:このユニットのためのデフォルト肖像画をセットする。もしそのユニットタイプが既に肖像セットを有しているなら、これはこのユニットの代わりに用いられる。そのユニットがレベルアップするとき、もしプロフィールの値がユニットタイプポートレイトと違うなら、その値は維持される。もしそのプロフィールフィールドが空ないし、ユニットタイプポートレイトと同じなら、レベルアップは、そのユニットのポートレイトを新しいレベルおよびタイプにとってのデフォに変える。
○unit_image もしファイル名の代わりに与えられるなら、そのユニットの基本的な画像が肖像として用いる。(肖像を持たないユニットタイプもデフォで同様にする)

・animate:もしyesなら、それが雇用ないし召喚されるときのようにそのユニットをフェードする。

 

・[status]:そのユニットのステータス。これはそのユニットの異なる特徴に影響する。例えば、そのユニットが各ターンに健康を失うか否か。デフォは全てのキーがoff。しかしこれはシナリオや特殊能力によって変更されうる。(AbilitiesWML参照)。あるユニットのステータスはステータステーブルに表示される。各ステータス修正statusmodはその画像misc/statusmod.pngによって表示される。
○poisoned:もしyesなら、そのユニットは各ターン8HP失う。heals, cures,AbilitiesWML参照。
○slowed:もしyesなら、そのユニットは通常の移動力の50%、半分のダメージになる。そのユニットのターンの操作が終わると、slowedは解除される。
○stoned:もしyesなら、そのユニットは動けず、攻撃できず、攻撃されない。
○hidden:もしyesなら、そのユニットは対戦者から見えない。
○guardian:これはai_special=guardianによってyesにセットされ、それを解除することで再びそのユニットは普通に動けるようになる。
○healable:もしnoにセットすると、そのユニットは回復されえない。

 

・[variables]:このユニットが蓄えられているとき、蓄えられている一組の変数([store_unit], InternalActionsWML参照)。variable=value属性は、そのユニットが配列ユニットに蓄えられている時、変数unit、変数variableは、値valueを持つ。(VariablesWML参照)

 

・[modifications]:そのユニットになされる変更。
○[trait]:そのユニットが持つ特性。[trait], UnitsWMLと同じフォーマット。
○[object]:そのユニットが持つオブジェクト。[object], DirectActionsWMLと同じフォーマット。

 

・unit_description:このユニットのためのユニットタイプの記述を上書きする。君はおそらく、promotionsの後、デフォの記述を上書きするため、post_advance eventをセットアップしたいだろう。ユニットタイプにフィルターをかけ、ユニットの記述や肖像を変えるためには、profile effect(s)を持つオブジェクトを使え。

 

・[event]:そのイベントは、作成されたユニットの内容からそのシナリオへコピーされる。[scenario][event]内の適切な全てのものは、[unit][event]内で適切である。[unit_type][event]と違って、[unit]タグはそのユニットを作る前に変数の代入を実行する。これは$|variable_nameシンタックスを使うことによってずっと働かされうる。

 

 


 

BuildingScenariosShroudData

 

shroud_dataの作成

 

SideWMLで指摘されるように、マップのどの部分があるサイドにとって幕化されるか、あるいはどの部分がされないかを記述するために、[side]タグにshroud_dataキーを追加できる。これは、ゲームの開始からそのマップの大きな部分を非幕化する必要がある時に役立つ。この目的のために(例えばprestartイベントで)[remove_shroud]タグを用いる時、君はx,y座標のリストを持ち、これがいくらか冗長になりえ、どの座標がセットされる必要があるのか見つけるのが難しい。

 

このチュートリアルは、君が非幕化したいマップの部分を非幕化するデータを含むファイルを作成しようとしている。君が必要とするのは以下だけだ。

 

・wesnoth map editor
・君の好きなテキストエディタ(検索と置換機能があるもの)
・エクセルやオープンオフィスなどの表計算ソフト

 

マップ作成

 

まず最初にマップが必要だ。これはwesnoth map editorで作成される(詳しくはWesnothMapEditorやBuildingMaps参照)。一度作ったらコピーを取れ。もしそうしたいなら、君はこのファイルが幕データを含むことを示すために、たとえばMapName_Shroudにこのコピーをリネームできる。

 

どのタイルが非幕化されるのか選ぶ+マップのフリッピング

 

(もしそれを閉じたなら、再びエディターでMapName_Shroudを開け)非幕化したいタイルをエディターで選ぶことができる。シフトを押したまま左をクリックして単独のタイルを選べ。シフト+altを押したまま左をクリックし、同じタイプの隣接地形タイルを選べ。さて、一つの地形タイプで君の選択を満たし、それから他全てのタイルを選び、他のタイプでそれを満たせ。一度それが為されると、君は再びセーブし、エディタを閉じることができる。

 

君の表計算ソフトにそのファイルをインポートし、分割するのにコンマを選択せよ。君はそれがどのように働くのか例を見るべきだ。もしそれぞれの文字の組み合わせがそれ自分のセルを持っていれば、上手く行っている。そのセルの術とぉ選択肢、ctrl+xを押せ。それからそのシートの左上のセルを選び、そこで右クリック。Paste specialを選べ。ダイアログウィンドウが現れる。transposeという名前のチェックボックスがあるからチェックせよ。さて君はそのマップの列とコラムをスイッチした。君のセルの全てを選び、ctrl+cを押せ。君の好きなテキストエディタを開き、新しいファイルでctrl+vを押せ。このファイルを、MapName_Shroudファイルのうえにセーブ。


マップデータのリライト

 

(もし閉じたのなら再びテキストエディタでMapName_Shroudを開け)今君はマップデータを含む(text)テーブルを見ている。君は、たった二つの文字の組み合わせだけが存在する。非幕の文字組み合わせを探し、それを1で置き換えるために、検索と置換を用いろ。幕の組み合わせにも同じ事をして、それを0に置き換えろ。1と0を分割するものは無い。一度全てがなされると、君はこのファイルの各ラインの最初にパイプを追加する必要があるのみだ。その結果は次のようになる。

|000000000000000000
|000000000000000000
|000000000000000000
|000001111111000000
|000001111111000000
|000001111111000000
|000001111111000000
|000001111111000000

そのファイルをセーブし、君のシナリオ.cfgファイルでそれを以下のようにして参照せよ。


[side]
   ...
   shroud_data="{@url/MapName_Shroud}"
   ...
[/side]

 


 

MapGeneratorWML

 

自動マップ作成のWMLくさいので省略 

 


 

TimeWML

 

時刻は、秩序ないし混沌ユニットによって与えられるダメージに影響する。これは君の攻撃タイミングを重要なものにする。時刻はステータステーブルの絵(太陽や月の光景)によってグラフィカルに表現され、夜間は画面が暗くなる。

シナリオ制作者はシナリオの時刻をスケジュールできる。既定のマクロを用いるか、新しい時刻を制作せよ。

 

[time]および[illuminated_time]タグ

 

[time]タグは[scenario]タグのサブタグである。しかしながら、ほとんどのシナリオは直接的にこれらを用いる。しかし普通はすぐ使えるマクロ {DAWN}, {MORNING}, {AFTERNOON}, {DUSK}, {FIRST_WATCH}, {SECOND_WATCH} , {UNDERGROUND}を用いて日夜のサイクルを特定する。これらのIDの定義についてはdata/core/macros/schedules.cfg参照。

 

[time]タグは継起する日夜の一つのターンを記述する。あるシナリオがプレイされる時、最初のターンは最初の[time]タグによって記述される。2番目は2番目。全てのタグが一つのターンを記述した後、次のターンは再び最初のタグによって記述される。

 

[time]タグは以下のキーを認識する。

 

・id:君が今のtimeを参照する際のid。例、AiWMLのtime_of_dayタグ。
・name:(翻訳可能)カーソルが日夜イメージの上に置かれるとき表示される名前。
・image:このタイプのターン中、ステータステーブルのトップに表示される画像。
・mask:このタイプのターン中、全てのヘックスの上に表示されるイメージ。
・lawful_bonus:alignment=lawful付きのユニットは、このタイプのターン中、+//lawful_bonus % damageを与える。alignment=chaoticのユニットは-lawful_bonus % damageを与える。alignment=neutralのユニットはこのキーで影響されない。lawful_bonusは負の数をとりうる。これは、秩序ユニットの代わりに、混沌にユニットに優位を与えたいなら役立つ。
・red, green, blue:その時期中、画面の色合いを記述する。-255から255までの整数値。例としては、schedules.cfg参照。
・sound:この時刻に変える際、演奏する音(sounds/の中)。

 

時間のスケジューリング

 

[scenario]タグは少数の[time]タグ(ないしマクロ)を含む。これらのtimeタグはループで用いられる。最初のtimeタグは、最初のターン中に用いられ、続けて2番目の・・・。そして全てのタグがパスすると、再び最初のタグが始まり、次に2番目・・・。

典型的な日夜のサイクルは以下の通り。

{DAWN}
{MORNING}
{AFTERNOON}
{DUSK}
{FIRST_WATCH}
{SECOND_WATCH}

日夜サイクルを避けるためには、ニュートラルな時刻を使え。例えば、

{DAWN}

地下においては、特別な時刻を使え。これは夜のように働き、混沌ユニットを有利にし、秩序ユニットを不利にする。

{UNDERGROUND}

 



IntroWML

 

[story]タグ

 

[story]タグは、イントロ画面の最初の部分として表示する一連の画像とテキストである。

[part]は[story]の下でのみ認識される特別なタグだ。各[part]は、一つの画像およびテキストを表示する。そのパートは、ユーザーがネクストボタンを押すまで表示される。

 

以下のキー/タグは[part]に認識される。

 

・background:表示する画像。ストーリー画像は、マップのため以外では、この目的で特に作られるのが普通だ。

・scale_background:backgroundをスケールするか否か。デフォはyes

・story:(翻訳可能)画像の下に表示されるテキスト。

・show_title:トップのシナリオタイトルを表示するか否か。

・title (DVO)

・music:現在の音楽を変える。

・sound (DVO)

 

・[image]:表示する画像

○x, y:その画像を描くピクセルの位置。x,yピクセル位置は、backgroundに記述される画像と関係する。が、普通の仕方ではない。background画像は、画面解像度を満たすようにスケールアップないしダウンされるが、画像は決してサイズについてスケールされない。しかしながらその座標はスケールされる。それは基本的に裏側では大きな労苦である。例:私は640×480のbackground画像と640×480のオーバーレイを持っている。オーバーレイを1024×768スクリーン上で水平位置を中央にするために、私はx=192でそれを配置したい。これは、1024-640=384が余白合計で、この半分が192だからである。これでオーバーレイの両サイドが等しいスペースになる。しかしながら、今君はbackgroundのスケーリングを説明しなければならない。640のbackground画像は1024にスケールアップされる。これは1.6倍のスケーリングファクターだ。全ての画像位置はスケールアップされ、従ってオーバーレイは192で描かれない。むしろそれはx=192×1.6ないしx=307!で描かれる。これを補正するためには、そのスケーリングファクターで望ましいピクセル位置を割れ。例:x_compensated=192/1.6 ないし x_compensated=120

○centered:もしyesなら、x,y座標に配置する際、そのイメージの中央を用いる。これは、この画像が背景のようにスケールされないので有用だ(そして中央化することにより、これについて心配する必要がない)。

○file:表示する画像

○delay:この画像の描写を送らせる時間

 

・text_layout(DVO)

・title_alignment (DVO)

 

[deprecated_message], [wml_message], [image], [insert_tag]タグは、[story]タグの下で許される。ほとんどの他のWMLタグは、この文脈では認識されない。しかし注意せよ。最初の二つのタグで産出されるメッセージは、実際のゲームマップが出現するまで、ゲームのインターフェイスに出現しない。

 

[story]下で認識される他のタグは、[if]/[then]/[else]である。これらは、変数の値について条件的にpartsを示すために用いられうる。しかし注意せよ。[switch]/[case]はこの文脈で機能しない。

 

また道程と戦闘のマクロをUtilWMLで参照

 

 


 

UtilWML

 

既定のユーティリティマクロ

 

data/utils.cfg内に定義され、常に含まれている多くのすぐ使えるマクロがある。多くは変数設定のための一行見出しのように比較的単純なショートカットである。しかしより複雑な仕事をするマクロがある。例えば、存在するユニットの性質を修正したり、マップ上でユニットを動かしたりする。各マクロが何をするかについての正確な記述は、data/utils.cfg参照。

 

Macro記述

 

我々はもはや手書きのユーティリティマクロに関する参照文書を持ってない。代わりに、1.3.2のように、マクロソースコードに埋め込まれたコメントから作られたautomatically generated pageがある。

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 





| 新しいページ | 編集 | 差分 | 編集履歴 | ページ名変更 | アップロード | 検索 | ページ一覧 | タグ | RSS | ご利用ガイド | 管理者に問合せ |
@wiki - 無料レンタルウィキサービス | プライバシーポリシー