キャンペーン制作手順（翻訳） - Wesnoth アンデッド研究所

キャンペーン制作手順（翻訳）

 

　　これは本家wikiにあるキャンペーン制作に必要な情報の翻訳である。ただし、全訳ではなく、不要と思われる部分は適宜省略している。訳自体も相当暴力的である。基本的にキャンペーンは、複数のシナリオをストーリーラインにのせて統合したものなので、そもそもシナリオの作り方が分からなければ話が始まらない。というわけで、シナリオ編とキャンペーン編を取り上げている。また具体的に記述される内容についてはWML(Wesnoth Markup Language)の知識が無ければならない。

 

翻訳済みページ一覧

 

シナリオ編

http://wiki.wesnoth.org/BuildingScenarios

• http://wiki.wesnoth.org/BuildingScenariosSimple
• http://wiki.wesnoth.org/BuildingScenariosIntermediate
• http://wiki.wesnoth.org/BuildingScenariosAdvanced

 

キャンペーン編

http://wiki.wesnoth.org/BuildingCampaigns

• http://wiki.wesnoth.org/BuildingCampaignsDirectoryStructure
• http://wiki.wesnoth.org/BuildingCampaignsTheCampaignFile
• http://wiki.wesnoth.org/BuildingCampaignsThePBLFile

 

シナリオWML（別ページ）

http://wiki.wesnoth.org/ScenarioWML

• http://wiki.wesnoth.org/EventWML

　　　　　http://wiki.wesnoth.org/FilterWML

　　　　　http://wiki.wesnoth.org/DirectActionsWML

　　　　　http://wiki.wesnoth.org/InterfaceActionsWML

　　　　　http://wiki.wesnoth.org/InternalActionsWML

•  http://wiki.wesnoth.org/SideWML

　　　　　http://wiki.wesnoth.org/SingleUnitWML

　　　　　http://wiki.wesnoth.org/BuildingScenariosShroudData

• http://wiki.wesnoth.org/TimeWML
• http://wiki.wesnoth.org/IntroWML
• http://wiki.wesnoth.org/UtilWML

 

---

 

シナリオ制作
http://wiki.wesnoth.org/BuildingScenarios

 

　　シナリオは二つのファイルを含む。まずマップだがこれはBuildingMapsに記述されている。次にコンフィグファイルだ。これはシナリオに関するあらゆることを記述するために使われる。両方のファイルはasciiであり、標準的なテキストエディタ(ノートパッドなど)で編集できる。

 

　　シナリオについてはWesnoth Markup Languageに書かれている。

 

　　この文書は複数のセクションに分けられている。基本的なチュートリアルから始まり、より複雑な技術へと進む。この文書に含まれる情報から、wesnothのシナリオを作るための全ての知識を得るはずだ。

 

（訳注：以下、翻訳する気のないページには取消線を入れてある）

 

目次

BuildingScenarios

BuildingScenariosSimple - BuildingScenariosIntermediate - BuildingScenariosAdvanced
BuildingScenariosSimple - French Version
BuildingScenariosComments - Comments left for advice
BuildingScenariosSamples - Basic sample code
BuildingScenariosShroudData - A tutorial on shroud_data
BuildingScenariosBalancing - How to balance your scenario
BuildingScenariosFAQ - Frequently Asked Questions

 

Quickタグ 目次

ScenarioWML the top level tags [scenario], [multiplayer], [test], and [tutorial]

EventWML how to describe an event
　FilterWML
　DirectActionsWML, InterfaceActionsWML, InternalActionsWML
SideWML how to describe a side
　SingleUnitWML
　BuildingScenariosShroudData
MapGeneratorWML the random map generator
TimeWML how to describe a day
IntroWML how to describe the intro screen
UtilWML a set of preprocessors you can use

 

---

 

シナリオ制作：初級

http://wiki.wesnoth.org/BuildingScenariosSimple

 

　　ここで非常にシンプルなシナリオを示し、そのそれぞれのラインを説明する。そのファイルは完全に機能的なのではなく、シナリオに関する全てを記述するのに必要な基礎を示す。

　　これを読む前に、Wesnoth Markup Languageのsyntaxに関することを読めば有用かもしれない。SyntaxWMLhttp://wiki.wesnoth.org/SyntaxWML

 

第1部

 

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

(続く)

 

　　それぞれのシナリオは一つのタグの中に閉じられなければならない。[scenario]タグは、キャンペーンシナリオのために用いられる。シナリオタグ中の属性の最初のセットは、このシナリオの基礎を説明する。

 

• idは君のシナリオのためのコンピュータの名前であり、ゲーム中に表示されない。しかし、ゲームの統計情報を示すのに使われるだろう（http://stats.wesnoth.org）。この名前はまた、他のタグやファイルでも参照される。例えば、first_scenario属性を用いる[campaign]タグの中で（BuildingCampaignsTheCampaignFileを見よ）。あるいは、next_scenario属性を用いる[scenario]タグの中で（以下を見よ）。

 

• next_scenario属性の値は、現在のシナリオに勝利した後でプレイされるシナリオのidである。このシナリオからのユニットは召喚することができるようになるだろう（召喚リストを修正しない限りは。でもそれは後の話）。もし君のシナリオがキャンペーンの一部でないなら、あるいは最後のシナリオなら、このラインをスキップするか、next_scenario=nullとすべきだ。そうすれば、このシナリオに勝利したとき、Endと表示される。

 

• name属性の値は、各シナリオをプレイする前のイントロダクション画面で表示される（これはおそらくマップ画像や他に君が考えるものを含む。やり方についての説明はBuildingScenariosIntermediateを見よ）。また、セーブファイルのデフォルト名を作る際にも用いられる。

 

• 次の属性であるmap_dataは、少々厄介だ。普通、マップデータ（マップを生み出すために用いられるテキスト）は引用符の内側に直接書かれる。しかし、マップデータを別個のファイルに置き、そのファイルを（引用符の内側に）含んでpreprocesserコマンドを用いることがしばしば有用である。{@campaigns/Test_Campaign/maps/testmap}というコードは、まさにそうしていて、wesnothエンジンに、マップデータのために、campaigns/Test_Campaign/maps/testmapというファイルを見るよう告げている。@は、wesnothに、userdataディレクトリーとgamedataディレクトリーの両方の中からそのマップファイルを探すように告げている（詳しくはEditingWesnothとPreprocessorRef参照）。君は、マップエディターを使ってマップファイルを作成・編集することができる（詳しくはBuildingMaps参照）。

 

• 最後の属性がturnsだ。これは何ターンまでにシナリオをクリアしなければならないかを示す（ゲーム中に変更されうるが、やはり後の話）。もしプレイヤーが制限時間内にクリアできなければ、負ける（defeatイベントの引き金となる。詳しくはEventWML参照）。

次のセクションはWesnothのpreprocesserによって前処理されるマクロのグループである。マクロは本質的にWMLのショートカットだ。それらによって、君は必要な時にいつでも再使用されうるコードの特定部分を決められる。Wesnothは君に、問題が起こらないように、標準の前もって書かれたマクロ全てを提供する。でも自分で書くこともできるよ（後の話）。今の例に戻ろう。上にリストされるマクロは、このシナリオにおける一日がいかにして進むかを既述している。上述のマクロリストは、Wesnothを通して用いられている普通の一日だ。もし君がそのシナリオ全体を夜の出来事にしたければ、{SECOND_WATCH}を除くマクロ全てを取り除け。

 

• music属性の値は音楽ファイルの名前だ（MusicListWML参照）。このファイルは直接music/の中になければならない。またOgg形式でなければならない。

 

シナリオを作っている時によく見るタグの一つが[event]...[/event]だ。eventタグは、何らかの類のイベントが起こる時に何がなされるべきかを既述するのに用いられる。イベントの具体的なタイプは、event's name属性で述べられる。例の場合、いわゆるprestartイベントを既述している。このイベントは、シナリオの導入画面が示された直後かつマップが表示される直前に発生する。このprestartイベントは、シナリオの目的をセットするのに用いられる。例えば、プレイヤーに、そのシナリオに勝利するために何が達成されなければならないか、いかなる条件で敗北になるかを教える。こうした勝利ないし敗北条件は、[objectives]（複数形）タグを用いて定義される。さらに、それぞれの条件が[objectives]（単数形）タグ自体の中で定義される。ここで勝利条件は、conditonをwinとセットし、敗北条件はloseとセットする。上記の例では、objectivesは、"Defeat Enemy Leader"であると述べる。しかし、敗北に関しては、[objectives]がプレイヤーに二つの可能性を与えている。すなわち、[Death of Konrad]ないし[Turns run out]のいずれかである（多くの勝利ないし敗北の[objective]タグが与えられよう）。従って、Senario Objectives Dialogはだいたい次のように見えるだろう。

 

A Simple Test Scenario
Victory:
Defeat Enemy Leader
Defeat:
Death of Konrad
Turns run out
    [ OK ]

 

[objectives]タグは、ゲームエンジンに対して勝利ないし敗北条件を定義しないことに注意。これはただプレイヤーにそれが何であるか教えるだけである。特別な勝利ないし敗北条件は、様々な[event]を用いてそのシナリオにコード化しなければならない。

 

[objectives]内のside属性は、[objective]タグによって定義された条件がside1の陣営ないし同盟軍だけに対するものだということを示す(以下を見よ)。シングルプレイヤーゲームでは、side1が普通はプレイヤーの陣営ないし同盟軍を示す。アンダースコア(_)がGettextを用いた翻訳を容易にする。

第2部

 

最後に必要な部分は、プレイヤー（人間とコンピューターの両方）が何を開始し、何ができ、何ができないかを既述する。それぞれのプレイヤーは、[side]タグの中に既述されている。

 

（続き）

  [side]
    side=1
    controller=human
    team_name=2
    user_team_name= _ "Konrad's forces"

    type=Commander
    id=Konrad
    canrecruit=yes

    recruit=Elvish Fighter,Elvish Archer,Horseman,Mage,Elvish Shaman

    {GOLD 100 50 0}
    {INCOME 10 5 0}
  [/side]
[/scenario]

上で君は人間プレイヤーKonradのためのサンプル[side]を見られる。[side]タグ内の属性の最初のグループは一般的にそのサイドと関連する。

 

• side
  このサイドのリーダーはこの数字によって表示されるタイルの上に配置される(BuildingMaps参照)。その数は1から9までだ。

 

• controller
  これは二つの可能な値をとる。すなわちhumanかaiかだ。もしこの属性を具体化しなければ、aiがデフォルトだ。

 

• team_name
  これはそのサイドがどのチームかを既述している。デフォルトではsideと同じ数字になるが、それを2にセットすると、このサイドとサイド2とを同盟させる（もし君がside2のteam_nameを変えなければ）。

 

• user_team_name
  これはそのサイドの統計を見る時（alt+s）に表示される名前だ。アンダースコアが云々。

 

属性の次のグループはこのサイドのリーダーを既述している。

 

• canrecruit
  この属性はyesないしnoにセットされる。もしこれがnoなら、リーダーは雇用できない。canrecruit=yes属性の言明がないどのサイドも、自動的に負ける。だから必ずこの属性を含め。

 

• type
  これは、リーダーがどのタイプのユニットかを既述する。可能な値はthe Wesnoth unit tablesにリストされている。

 

• id
  これはリーダーの名前と識別である。

 

キャンペーンでは、こうした"leader-describing"属性の全てが人間のプレイヤーには無視される（canrecruit除く）。なぜなら、前のシナリオからリーダーは現在の状態を引き継ぐからだ。例外はもちろん最初のシナリオで、これは前のシナリオからのリーダーがいないからだ。しかしながら、type属性はシナリオがクラッシュするのを防ぐために依然として必要だ。

 

最後の属性であるrecruitは、unit typesのコンマで分離されたリストだ。このタイプは、そのサイドの雇用リストになる。これもまた人間プレイヤーの最初のシナリオにのみ必須だ。なぜなら雇用リストも引き継がれるから。

 

最後に、二つのマクロが呼ばれる。最初がGOLDでこれは三つの具体的な数字をとる。これらは、プレイヤーが易しい、普通、難しいのいずれかの難易度で始める際のそれぞれの金額を示す。人間に制御されるサイド（controller=human）にとって、これは金額の最小限のみを特定する。実際の開始金は、もしプレイヤーが前のシナリオから金を維持してきたなら、より多くなる。次のマクロはINCOMEであり、これはGOLDに似ているが、基本収入のためのものだ。GOLDとINCOMEの基本値は、それぞれ100goldと基本収入2だ。

完全に動くようにするには

 

このシナリオをプレイできるようにするには、キャンペーンを作る必要がある（BuildingCampaignsTheCampaignFileを見よ）。これはメインディレクトリーdata/campaignsではなく、userdata/data/campaignsに保存されるべきだ。さもなければ、公式キャンペーンの起動を阻害し、さらに悪ければ、ゲーム全体を阻害する（BuildingCampaignsDirectoryStructureを見よ）。頼むから全てのファイル（キャンペーンファイルとシナリオファイル）はファイル拡張子.cfgで保存されなければならないということに注意して。以下は短く例のキャンペーンファイルだ。

 

[campaign]
  name= _ "Test Campaign"
  first_scenario=test-1
  define=CAMPAIGN_TEST_CAMPAIGN
  difficulties=EASY,NORMAL,HARD
  difficulty_descriptions= _ "&elvish-fighter.png=Easy;*&elvish-hero.png=Medium;&elvish-champion.png=Hard"
  icon=elvish-fighter.png
[/campaign]
#ifdef CAMPAIGN_TEST_CAMPAIGN
{~campaigns/test_campaign/scenarios}
#endif

[campaign]タグはそのキャンペーンを記述している。最初の属性nameは、ゲームプレイ中に、キャンペーンの選択ボックスに表示される。次に、first_scenarioはそのキャンペーンの最初のシナリオのIDナンバーをセットする。続くシナリオは、直前のシナリオのnext_scenario属性によって指定される（チュートリアルの最初の部分を見ろ）。最初のシナリオは明らかに前のシナリオがないので、campaignタグで指定される。wesnothに実際最初のシナリオをみつけさせるために、我々はキャンペーンのシナリオディレクトリを含む必要がある。キャンペーンファイルの最後の言明がそうする。その中身は、前処理シンボル（PreprocessorRef）によって最善の保護がなされている。これはこのキャンペーンに固有なので、このキャンペーンが実際にプレイヤーによって選択されるとき、全てのシナリオが含まれるようになる。あるキャンペーンのための前処理シンボルは、defineキーによって与えられる。

 

difficulties=EASY, NORMAL, HARD属性は、もし最初の難易度選択がゲームプレイ中に選ばれたらEASY値を、2番目ならNORMAL、3番目ならHARDを用いる様にwesnothに告げる。#ifdefという表現は、この属性の値をテストするために後で用いられうる（PreprocessorRef見ろ）。EASY, NORMAL, HARD以外の名前はマクロで使わないよう推奨される。

 

二つの任意の属性がdifficulty_descriptionsとiconだ。その値として、iconはゲームプレイ中にキャンペーンのリストに表示されるこのキャンペーンを表すイメージのファイル名を述べる。difficulty_descriptions属性はその値に、difficultiesがリストアイテム（引用符で閉じられていない）の中に有するのと同じ数字のリストアイテム（引用符で閉じられている）を持たなければならない。両属性のリストの長さはほとんどの場合3つである。またdifficulty_descriptionsのリストは単に引用符で閉じられているだけでなく、そのアイテムはコンマではなくセミコロンによって分離されていることに注意せよ。驚かなくてもいいが、我々の例ではゲーム中、elvish-fighter.pngがeasyレベルと、elvish-hero.pngがnormalとelvish-champion.pngがhardと関連付けられて表示される。

difficulty_description内のそれぞれのリストアイテムは、「&」で始まる。これにイメージのファイル名が続く。それから「=」がきて、最後に表示するテキストだ（"Easy"とか。easyレベルで表示されるテキストは"EASY"じゃないってことを注意しろ。そのテキストはdifficulty_descriptionsで使用されるんであって、difficultiesでではない。普通のレベルのテキストは"Medium"である）。

　　君は任意で、ゲームプレイ中デフォルトとして選択される難易度レベルの前に「*」をおいてもいい。上の例ではノーマルレベルがデフォルトに選ばれている。

 

---

 

シナリオ制作：中級

 http://wiki.wesnoth.org/BuildingScenariosIntermediate

 

 

このチュートリアルでは、WMLとシナリオ制作の秘密（イベント、特殊な属性の使用説明、より発展的なsideのセットアップ）を幾分掘り下げる。

 

イベント

 

君はイベントメカニズムを用いて、シナリオ中に発生する特定のアクションを引き起こせる。シンプルイベントの例を見よう。君は、Konradが4.8に移動した時、彼に"it's getting cold"と言わせたいと仮定しよう。

 

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

 

まず君はイベントの名前を持つ。ここで、我々はmovetoイベントを持っているが、これはユニットがどこかへ動く度に発生するということを意味する。異なる可能な可能なイベントの名前のリストはEventWMLを参照。

　　もちろん、誰がどこに動くかを指定したいだろう。そこで、[filter]タグを用いて、我々が望むmovetoイベントを指定するのだ。フィルターがいかにして使用されるかは、FilterWML参照。

特殊属性

 

一般的に、一連のアクションは一度だけ引き起こされる。一連のアクションをイベントが発生する度に引き起こしたければ、そのイベントの属性first_time_only=noを付け加えればよい。

　　また、あるイベントが引き起こされる時はいつでも、プレイヤーは移動をアンドゥできない。たとえそれがmovetoイベントであったとしてもだ。我々はイベントを加えることによって、移動がキャンセルできないシナリオを作ることが出来よう。

 

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

（これは何もしないが、プレイヤーが移動をキャンセルするのを防ぐ）

 

次のようなイベント、

 

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

 

これは、暗黙の引き金であり、シナリオの終了時に自動的に現れる。このイベントを防ぐには、次の属性victory_when_enemies_defeated=noをメインタグ（普通は[scenario]）の内側に付け加えよ。

 

属性disallow_recall=yesは、プレイヤーがこのシナリオでユニットを召喚できないようにする。

 

属性fog=yesとshroud=yesは、[side]タグの中に置かれ、そのサイドが戦霧ないし幕を持つようにする。（戦霧はあらゆる敵の動きが見えないようにし、幕はそのマップ全体を見えなくする）

side発展編

 

BuildingScenariosSimpleで見ただろうから、君は人間プレイヤーとAIプレイヤーが何を始めるのか、AIがいかに動くか制御するためのいくつかのオプションをセットアップできる。以下にリストされた[side]タグから、我々はそこから制御されるもっと面白いことを学べるだろう。私は全てのキーを説明することはない。ただ新しいやつだけだ。

 

[scenario]
.
.
.

  [side]
    type=Lich
    description=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]

[side]タグは少々複雑になりうる。#ifdefは比較的単純だ。もしユーザーがEASYをプレイしているなら、#ifdefEASYと#endifの間にある全てがセットされ、他は無視される。もしユーザーがNORMALをプレイしているなら、#ifdefNORMALと#endifの間の全てがセットされ、他は無視される。最後に、プレイヤーがHARDをプレイしているなら、#ifdefHARDと#endifの間の全てがセットされ、他は無視される。こうすることで、シナリオはユーザーが選択するゲームレベルに応じてコンフィグされる。また二つの新しいキーがリストされている。すなわち、village_valueとleader_valueだ。

 

マップファイルは地形タイルを有する。これは最下層(very bottom layer)にある。あるゲーム中に歩き回るユニットは、最上層(very top layer)にある。これで十分だが、そのマップに固有のアイテムを配置できたらナイスじゃないかい？もし君が自分のシナリオのどこかにビルやポーションなんかを置きたかったら？できるぜ！[item]タグを使うんだ。

 

[scenario]
.
.
.

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

.
.
.
[/scenario]

[item]タグは、見たとおり、非常にシンプルに使える。三つのキーがあって最初の二つは、xとyだ。これはマップ中の位置だ。三つ目のキーは、その場所に置くイメージファイルだ。このイメージは、imageディレクトリーに置かれなければならない。

 

さて、君はAIプレイヤーの調整と共に、面白い見た目のシナリオを作るのに十分な情報を得た。これは大きな一歩だよ。次に我々は、君の新しく作ったシナリオをキャンペーンにうまくフィットさせる方法を学ぼう。これはシナリオがプレイされる前に示されるイントロを含む。これは全て[story]タグの内側でなされる。

 

[scenario]
.
.
.

  [story]
    [part]
      story= _ "... but one of the Orcs survived long enough to send the news to the queen..."
      image=misc/story6.png
    [/part]
    .
    .
    .
  [/story]
.
.
.
[/scenario]

storyタグは、プレイヤーがそのシナリオを始める前に語られるストーリーを含む。君はこれを省略できる。そうすれば導入画面をスキップすることになるだろう。一つのstoryタグは、パート（[part]タグの中にある）の外側に存在する。それぞれのパートは、複数のキーを含むことができ、それがどのような内容を持っているか記述する。詳しくはIntroWML参照。

 

---

 

シナリオ制作：発展

http://wiki.wesnoth.org/BuildingScenariosAdvanced

 

ここですること

 

ここにはBuildingScenariosIntermediateの中に既にあったものの繰り返しが含まれている。以下を含む。

• 前処理システム(preprocessors)の作り方使い方についての（さらなる）情報(PreprocessorRef)
• シナリオファイルの一般的なレイアウトに関するガイドラインの情報
• 発展的なフィルタリング

 

発展的イベント

 

内的アクション

全てのタグと値の完全なリストはInternalActionsWMLを見よ。以下では変数の作成と操作の基礎を説明する。

 

変数(variables)

 

（もし君が変数の概念に精通しているならスキップ可）
（詳しくはVariablesWMLを見よ）

＜省略（例としては座標）＞

 

操作

 

以下三つのアクションは、一つのタグ[set_variable]において実行される。我々が、message_to_the_worldと名付けられた変数に'Hello World'を入れたいとしよう。これは次のようにしてなされる。

 

[event]
.
.
.
  [set_variable]
    #The name of our variable:
    name=message_to_the_world
    #The value of message_to_the_world, notice the underscore!
    value= _ "Hello World!"
  [/set_variable]
 .
 .
 .
[/event]

 

さて、もし我々がその変数を後で何かしら変更したいなら（例えば'Goodbye World'に）、我々は上と正確に同じコードを用いることができる。もし我々がメッセージに何か追加したいなら、次のようにする必要がある。

 

[event]
.
.
.
  [set_variable]
    name=message_to_the_world
    value= _ "$message_to_the_world Have a nice day!"
  [/set_variable]
 .
 .
 .
[/event]

 

今までは、テキスト変数（ストリングスstrings）を用いてきた。しかし我々はまた、数字を入れることもできる。以下の例がこれにあたる。

 

[event]
.
.
.
  [set_variable]
    name=number_x
    value=10
  [/set_variable]
  [set_variable]
    name=number_x
    add=-9
  [/set_variable]
  [set_variable]
    name=number_x
    multiply=200
  [/set_variable]
  [set_variable]
    name=number_x
    multiply=0.5
  [/set_variable]
 .
 .
 .
[/event]

 

上で我々は、number_xと名付けられた変数に10の値をセットした。我々はこれを9減らし(=1)、200掛けて(=200)、そして2で割る(つまり0.5を掛ける)。結果は100である。

 

変数の使用

 

我々は、変数の作成・操作方法が分かった。次にその使い方を学ぼう。まず最初に、君がどんな変数を自由に使えるかを知る必要がある。

 

• side_number: 現在のプレイヤーのサイド数 (おそらく開始ないし開始前イベント中は空だろう)
• turn_number: 現在のターン数 (同上)
• x1: 直近のイベントが発生した場所のx座標
• y1: 直近のイベントが発生した場所のy座標
• x2: 直近のイベントが発生する際、手助けをした場所のx座標
• y2: 直近のイベントが発生する際、手助けをした場所のy座標
• unit: あるイベント中、$x1,$y1にいるユニット
• second_unit: あるイベント中、$x2,$y2にいるユニット
• this_unit: 標準のユニットフィルターの中で、現在可能な組み合わせを考慮されたユニット

 

これらのいつくかは、単に他の変数の入れ物である。unit変数が一つの例だ。君は、ドットを用いて、サブ変数('sub'-variables)にアクセスできる。

 

unit.hitpoints
unit.side
･･･

 

一つの例で$unitを用いて、これ全てがいかにして用いられうるか示そう。

 

[scenario]
.
.
.
  [event]
    #A unit moves onto a tile:
    name=moveto
    [filter]
      x,y=25,26
    [/filter]
   
   
    [set_variable]
      name=unit.hitpoints
      add=-5
    [/set_variable]
    [set_variable]
      name=unit.status.poisoned
      value=yes
    [/set_variable]

    #After we have changed the values, we need to apply them.
    #We do this by using the unstore_unit tag like this:
    [unstore_unit]
      variable=$unit
      find_vacant=no
    [/unstore_unit]
  [/event]
  #We're finished!
.
.
.
[/scenario]

君がまだ知らないタグに、[unstore_unit]がある。このタグを説明するため、私はその相方[store_unit]を説明しよう。[store_unit]は、君が選ぶ一つの変数の中に一つないし複数のユニットを収容している。君は上述のようにその変数を操作することができる。しかし、君はこれらの変更を与える必要があるだろう。これは[unstore_unit]タグを用いてなされる。詳しくはInternalActions参照。

GetText & Translations

 

As Viliam pointed out(彼の発言を整理したものだ)：

 

翻訳の問題は二つのステップからなる。第一段階は、翻訳可能な、より好ましいのは翻訳が容易な、シナリオを作ることだ。第二段階は、テキストの翻訳だ。これは翻訳者に任せろ。

 

キャンペーン／シナリオ開発者である君は、自分のキャンペーンが容易に翻訳できるようにしなければならない。アンダースコア（_）を、ユーザーが画面で見るテキスト全てに先行させることで、これは容易に達成できる。これは、翻訳可能なストリングであることを示している。そうすればGetTextは、君のローカル設定に基づいた翻訳を探すことができるようになる。これを明確にするため、以下に例がある。

 

.
.
.
[message]
  description=Konrad
  message= _ "I am mighty Konrad! I fought many dummies and now I will fight you!"
[/message]
.
.
.

メッセージキーは、Konradが話す時、表示される言葉を含む。だからこれは翻訳可能なストリングだ。だから、アンダースコアで先行させる。

 

Viliamはまた次のように言った。

何よりも最も重要なルールは、「文を分けるな」である。いくつかの言語では、ある言葉を一つの文に置くことが、単なるストリングの連結以上に必要だ。いくつかの言語は、格変化declensionを用いる。

 

 

  

 

---

  

キャンペーン制作
http://wiki.wesnoth.org/BuildingCampaigns

 

wesnothの1pキャンペーン作成にはいくつかの段階がある。

・DirectoryStructure
・TheCampaignFile
・ThePBLFile
・Distribution
・WesCamp（自作キャンペーンを翻訳可能にする方法）
・Wesnoth UMC Dev（UMCプロジェクトを共同制作できる場所）

最初の制作は難しいだろうけどチュートリアルは工事中

 

操作しやすいものから始めろ

 

もしwesnothの全歴史に及ぶ壮大なキャンペーンを作ろうとしたら挫折するからやめとけ。短い話から初めて、後から付け加えた方がはるかに楽である。

 

ストーリーが最初

 

一つのシナリオとキャンペーンとを分けるのは、物語る能力である。人々を引きつけるのは、面白いゲームプレイがミックスされた面白いストーリーである。

 

☆キャンペーン'Liberty'制作者のお言葉
1.ラフなストーリーとプロットを書け
2.いくつのシナリオをつくりたいのか決めろ
3.複数のシナリオの間でストーリーを分けろ。そうすればそれぞれのシナリオで起こることを決定できる。
・どこにいる？
・誰とたたかってんの？なぜ？
・このシナリオで何をしないといけないの？
・ヒーローは次にどこへ行きたいの？
4.シナリオ間の「留め金」を決めろ。シナリオには多くの異なる可能な設定がある。もし、「二人の敵リーダーを殺せ」のように退屈な反復を避けたいのなら、敵や仲間や戦雲／霧、日夜の効果、雇用、地形配置などの面白い組み合わせを列挙し、戦闘が面白くなるようなよい組み合わせを選べばいい。

これ全てが、WMLに手を加える前になされたことであった。でも今や君はコーディングを始めるのに不足はない。

 

早く共有せよ

 

他人が見るためにつくったものなら投稿するのを躊躇うな。

 

時には盗め

 

何かしらの方法を学ぶ最善の途は、別の人のキャンペーンからコピーしちまうことだ。自分のWMLの一部が他人のキャンペーンで生きているのを見ることは、デザイナーにとって幸せなのさ。全部コピペは論外。

 

---

DirectoryStructure

http://wiki.wesnoth.org/BuildingCampaignsDirectoryStructure

 

windows版

作ったキャンペーンは
C:/Program Files/Wesnoth/userdata/data/campaigns
に置くこと。

 

Structure例：'simple_campaign'

    …/simple_campaign/_main.cfg        -- main file of the campaign
    …/simple_campaign/scenarios/       -- directory for campaign scenario files
    …/simple_campaign/maps/            -- directory for of maps
    …/simple_campaign/units/           -- directory for of WML for campaign-specific units
    …/simple_campaign/images/          -- directory for portraits, unit animation sprites, etc
    …/simple_campaign/sounds/          -- directory for sound effects and music, if any
    …/simple_campaign/utils/           -- directory for campaign-specific macros
    …/simple_campaign/_server.pbl      -- PBL file top be used for server uploads

 

---

 

TheCampaignFile
http://wiki.wesnoth.org/BuildingCampaignsTheCampaignFile

 

　　キャンペーンはWMLファイルを含んでいなければならない。このWMLファイルは[campaign]タグを含んでいる。そのキャンペーンを翻訳可能にするためには、[textdomain]タグを含まなければならない。このタグは、[campaign]タグに先行すべきである。

　　このファイルは以下の情報を含む。orderファイルにまき散らされた自作キャンペーンの小部分の残りをみつけ、それらを一つにしてプレイできるキャンペーンにするために、そのゲームが必要とする情報である。これについての多くの情報は、CampaignWMLエントリーにある。以下は、キャンペーンファイルの各ラインの記述と、それがなんであるかの説明である。

我々の目的のために、DirectoryStructureページのsimple_campaignというキャンペーンを我々は既に作ったと考えよう。

　　キャンペーンファイルの最初のラインは、[textdomain]WMLタグである。このタグは、そのゲームが、キャンペーン中のstrings（記号列？）への翻訳を探す場所を特定する。textdomainタグは、textdomainのためのある名前を特定する。これは、[campaign]タグで用いられ、またstringsを翻訳と結びつけるため、f exキャンペーンシナリオで用いられるものである。texdomainは、既定のシステムにおいて特定されるかもしれない他のtextdomainと対立しないように、唯一のものであるべきであり、'wesnoth-'で始められるべきである。textdomainはまた、コンパイルされた翻訳ファイルが置かれているディレクトリーへのパスを特定する。これはキャンペーンディレクトリー内のファイルであるべきだ。

 

例）

    [textdomain]
         name="wesnoth-Simple_Campaign"
         path="data/campaigns/simple_campaign/translations"
    [/textdomain]

 

それから、ゲームにこれがキャンペーンであることを知らせる[campaign]WMLタグを続けろ。

 

    [campaign]

 

まず、そのキャンペーンと君がすでに定義したtextdomainとを関連付けよ。

 

    #textdomain wesnoth-Simple_Campaign

 

ラインの次のグループは、そのキャンペーンを単独に識別する。

 

    name= _ "A Simple Campaign"
    abbrev=ASC
    define=CAMPAIGN_SIMPLE_CAMPAIGN

（初期のバージョンではidというのもあった。今は不要）

 

• nameは、ユーザーが見るであろう君のキャンペーンの名前である。それは引用符中に置かれ、その前にアンダースコアがなくてはならない。

 

• abbrevは、キャンペーンの略称を定義する。これは、セーブファイルの名前の先頭に来るものとして用いられる。

 

• defineは、ユーザーがいつ君のキャンペーンのあるシナリオをプレイすることを選んだかをゲームに知らせる鍵である。

 

nameとdefineは必須、abbrevは任意だが推奨。

 

次のグループは、ユーザーがキャンペーンメニューから君のキャンペーンを選択する際、彼にそのキャンペーンについての情報を与える。

 

    icon=a_wesnoth_icon.png
    image= simple_campaign_logo.png
    description= _ "Some text about my campaign!"

 

• iconは、標準のWesnothイメージに対する指示である。それはキャンペーン選択メニューに表示される。適当な場合、そのアイコンに深紅色の代わりにあるチームカラーを与えるためには、ImagePathFunctionWMLを用いるべきである。

 

• imageは、ユーザーがキャンペーンをクリックした時、表示されるイメージである。

 

• descriptionは、imageと同時にユーザーに示されるテキストである。

 

これら三つのいずれも厳密には必須でないが、君のキャンペーンをナイスにプロフェッショナルに見せるものである。

 

    difficulties=EASY,NORMAL,HARD
    difficulty_descriptions={MENU_IMG_TXT2 *&units/human-loyalists/peasant.png~TC(1,magenta) _"Civilian" _"(trivial)"} +
    ";" + {MENU_IMG_TXT2 units/human-loyalists/spearman.png~TC(1,magenta) _"Soldier" _"(simple)"} +
    ";" + {MENU_IMG_TXT2 units/human-loyalists/pikeman.png~TC(1,magenta) _"Veteran" _"(easy)"}

 

• difficultiesは、三つの異なる難易度のための三つの定義を作る。難易度とバランスに関するさらなる情報は、Campaign Design HOWTOを参照。

 

    first_scenario=the_first_scenario

 

• first_scenarioは君が最初にロードされプレイされるよう意図したシナリオのシナリオidの指示である。このラインは絶対必要である。君が自分のキャンペーンをデバッグないしテストする際、このラインを変えると、よけいなシナリオをプレイしなくて済むので、便利である。（セーブしてもいいんだけどね）

 

    [/campaign]

 

[campaign]タグで必要なのはこれで全てだ。だからここで閉じることができる。でももっとすることがある。我々は、Wesnothに、我々の様々な追加ファイルがどこに置かれているのかを伝えなくちゃいけない。（例えば、マップとかシナリオとかユニットとかイメージとかサウンドとか）

 

君は、全てを[campaign]タグの中に置くべきではない。

 

 #ifdef CAMPAIGN_SIMPLE_CAMPAIGN
 ...
 #endif

 

そうすれば、君のカスタムマクロやWMLコードやファイルの含有物が、他のゲームに影響したり、ゲームを遅くしたりはしない。唯一の例外は、君のキャンペーン内のカスタムイメージへのパスを特定する[binary_path]タグだ。もし君がキャンペーン選択メニューと難易度選択メニューのためのカスタムイメージを必要としているなら、これを#ifdefの外側に置くべきだ。そうでないなら、これさえ#ifdefの内側に属する。

 

正しく最小限の#ifdef部分は、君のシナリオへのリンクを含むだけだ。

 

#ifdef CAMPAIGN_SIMPLE_CAMPAIGN

{@campaigns/simple_campaign/scenarios}

#endif

 

この{@campaigns/simple_campaign/scenarios}ラインは、君のキャンペーンの"senarios"ディレクトリーの中をのぞき、そこで見つける.cfgファイル（シナリオファイル制作の情報は、BuildingScenariosを参照）を構成要素に分析するだけである。もし君がなんらか他の.cfgファイル（マクロ、カスタム地形など）を持っているなら、同様にしてそれらをリンクすることができる。ただし、もしカスタムユニットを用いたいなら、[+units]タグの中からそれらをリンクしなければならない（+は、それらをwesnothの格納されたユニットに加える。これは重要）。次のようにせよ。

 

[+units]
{@campaigns/simple_campaign/units}
[/units]

 

---

BuildingCampaignsThePBLFile
http://wiki.wesnoth.org/BuildingCampaignsThePBLFile

 

　　PBLファイルは、非公式キャンペーンの三つの要素のうちの一つだ（あと二つはキャンペーン.cfgファイルと、キャンペーンフォルダ）。それは、拡張子が.pblだという点を除けば、キャンペーン.cfgファイルと同じ名前を持つASCIIテキストファイルである。完全な資料はPblWMLで見つかる。

例はこちらhttp://exong.net/wesnoth-attach/files/pblexample_111.png

　　PBLファイルは、キャンペーンサーバーによって用いられている。これによって君は、サーバーにある自分のキャンペーンを公開したりアップデートしたり削除したりすることができる。キャンペーン制作者として、君だけがそのPBLファイルへのアクセス権を持ち、それ無しにはキャンペーンサーバーの自分のキャンペーンを管理することはできない。

　　サーバーはカスタムプロトコルを用いており、http/ftp/sshアクセスを許さない。

PBLファイルは、以下のタグを含む。

 

     author=" "
     title=" "
     icon=" "
     version=" "
     description=" "
     type=" "

 

次のタグは任意である。もし君がpassphraseを与えないなら、最初にキャンペーンを公開する時、passphraseはサーバーによってランダムに生み出される。次に君がPBLファイルを見る時、passphraseが君のために付け加えられているのを目にするだろう。もしこれを削除すれば、君はもはや自分のキャンペーンを管理（アップデート、削除）することはできなくなる。そして、フォーラムのpersonal messageをIvanovicに送って、直してもらうように頼まなければならなくなる。

 

     passphrase=" "

 

推奨されているのは、管理者が君のアドオンに関して困った時に連絡する方法を提供することだ。例えば、サーバーがクラッシュし、内容を再アップロードしなければならない場合である。自分のメールアドレスを提供するため、君の.pblファイルに次のタグを用いよ。それはクライアントには明かされないということに注意。

 

     email=" "

 

PBLタグのメモ

 

• author
  アドオン作者の名前を示す。もし複数人でそのキャンペーンを作ったのなら、重要な貢献者全ての名前をリストすべきだし、おそらく各人の責任が何であったのか記述すべきだ。

 

• icon
  これは、キャンペーンサーバーによって、imageディレクトリーから入手可能な標準イメージのファイル名であるべきだ。君は自分のキャンペーンのカスタムイメージへのアクセス権を持っていないだろう。必ずフォワードスラッシュ(/)を使え（バックスラッシュはダメ）。自分のキャンペーンをアップロードしたら、そのアイコンがキャンペーンダウンロードページに表示されるか確認すべきだ。
  関連ページhttp://wiki.wesnoth.org/ImagePathFunctionWML

 

• version
  どんなのでもいい。推奨されているフォーマットは、x.y.z(数字)だ。以前だと、バージョンは必要とされるwesnothのバージョンをしばしば示した。でも今はそうじゃない。

 

• description
  今のところ、クライアントには表示されないが、キャンペーンサーバーへのwebインターフェースでは示される。これを使って、そのキャンペーンの内容について簡潔な説明を提供できる。
  　　もし「title」キーワードがセットされなければ、そのキャンペーン.cfgファイルネームが、キャンペーンサーバーによってキャンペーンネームとして表示されるだろう。この場合、表示される名前においてアンダースコア(_)が空白に置き換えられ、また接尾辞の(.cfg)は落とされる。まあでもタイトルぐらい書きたまえ。

 

• translate(任意)
  もしその値が「true」なら、そのキャンペーンは翻訳されることを示し、wescampに自動的にアップロードされる（この機能性はまだ完全に運転中だ）。
  技術的には、君は初回のアップロード前にpassphraseを指定できるが、省く方がよりシンプルである。passphraseを指定する利点は、多分忘れないだろうということだ。

 

• email
  そのアドオンの作者ないしメンテナーの電子メールアドレスだ。サーバー管理者だけがコンテンツ登録者に連絡することができる。

 

• type
  それを分類するためのアドオンのタイプだ。詳しくはPblWML参照。

 

警告
.pblファイルのストリングを翻訳可能にするな。これは問題を起こし、決して機能できなくなる。同様に、前処理プログラムのマクロないしこのファイルに含まれているものを使うな。それらは全く前処理されないから。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---