約 143,668 件
https://w.atwiki.jp/coolnaurl/
BMS制作のすすめは、主にDTM作曲者が初めてBMSを作るとき、参考にするべきまとまった資料がないという意見を受けて、ROKINAが勝手に作り始めた似非wikiです。 ここでは自分が作った曲をBMSにするときに気をつけるべき点や知っておくと便利なことなどを随時追加していく予定です。 このサイト上ではコメントを受け付けませんので、ご質問やご意見などありましたら筆者のツイッターまでご一報ください。
https://w.atwiki.jp/shiori_yuhna-se/pages/28.html
結奈SEでゴーストを作る前に--結奈SEでゴーストを作るメリット、デメリット 結奈SEゴーストエディタの入手--ゴーストエディタを同梱するゴーストたち ディレクトリ及び、ファイル構成について--それぞれのファイルの役割 結奈SEによるゴースト編集--結奈SEゴーストエディタによるゴースト作成 結奈SEによるネットワーク更新--一人前の立派なゴーストになれるように 結奈SEで作ったゴーストを公開!--…の前に? ※編集中
https://w.atwiki.jp/kakusin/pages/12.html
1.源平シナリオ 881 :名無し曰く、:2007/01/17(水) 17 03 42 ID 14xkcn1L んじゃ俺も源平合戦シナリオに挑戦しよう 義経や弁慶の顔グラもあることだし 問題は源平の知識がほとんど無いことだな 882 :名無し曰く、:2007/01/17(水) 17 18 12 ID ZP1oc43L よし まずはこれを買うんだ っ[コーエー定番シリーズ 源平合戦] 890 :名無し曰く、:2007/01/17(水) 22 45 18 ID 14xkcn1L サンクス、姉婿が持ってたんでさっそく借りてきた やっぱ源平は弓騎馬最強になるかな 今の鉄砲の威力を弓に置き換えるといいかも とりあえず武将登録だな・・・時間かかるな 2.有名人の野望 903 :707:2007/01/19(金) 17 13 39 ID bGY6Zxga 707です 大体顔グラ半分くらい集め終わりました(まじしんどいw) 能力はというと、 スポーツ選手は武勇がたかめ リーダー適正のある選手は統率も高い 大学出てる選手は知略、政治も高め 政治家は政治、知略が高め 総理や幹事長などの指揮する立場の人間は統率も高い 武勇はお察しください(大仁田厚議員は例外w) 学者は知略、政治が高い 芸能人は魅力が高いと設定したかったんですが、 革新魅力のステないw 芸能人は顔グラめちゃめちゃ集めやすいんで、 能力に色つけていろんなところに配置してます お笑い芸人で上杉憲政並の人材がいたりしますので、気をつけてください 戦法は 柔道(井上、谷)、ボクシング(かめだw)などの選手に足軽戦法 野球(松井、イチロー)、サッカー(へなぎさわw)選手に騎馬戦法 アーチェリー銀メダルの山本博さんに三矢訓 学者(吉村さんとか)、大学教授(うえくさwとか)に計略 有名な医者(和田秀樹とか)に治癒 そしてなぜかWaTの小池徹平に釣瓶打ち 適正は結構適当かもしれません 役職はいまんとこ総理大臣(指揮兵力+13000)が最強です(安部が持ってます) 官位はまだ手をつけてません まぁ、みなさんにも小池徹平がさわやかなスマイルで釣瓶打ちして来るのは 一度見てもらいたいですね 有名人の野望凄く面白そう -- 名無し (2008-01-29 15 32 28) 名前 コメント
https://w.atwiki.jp/owntcg/pages/17.html
思考派と直感派 良いカードゲーム 「面白い」とは? 「つまらない」とは? カードゲームの作り方 デッキの存在 メタゲームや三竦みの存在 合成(融合・合体)の存在 カード外の要素(ダイス・コイン・カウンター)の存在 世界観の存在 思考派と直感派 思考派:既存のゲームを何故面白いのかを理詰めで考え、取り入れる製作者のこと。 もしくは、単にゲームを理詰めでゲームシステムを作ろうとする製作者のこと。 直感派:直感的に面白いものを探してゲームに採用する製作者のこと。 もしくは、直感的なアイデアでゲームシステムを作ろうとする製作者のこと。 直感派、思考派はその言葉の曖昧さも相俟って、論争になりやすい。 個人によって手段はそれぞれであり、必ずしもどちらかが正しいということは無い。 スレ内には直感派でもあり思考派である人も多く居る。 直感派は云々、思考派は云々という固定概念に捕らわれない事は大切である。 システムの基本は直感派、カード能力は思考派など、分野によって作り方を 変える製作者も少なくない。 良いカードゲーム 非常に主観的であいまいな表現で、使うと大抵論争になる。 良いカードゲームという場合、少なくとも以下のような例がある。 漠然と面白いカードゲーム 遊んだ時に漠然と面白いと感じられるカードゲーム。 「プレイ感が良い」もこれに関係するか? よく売れるカードゲーム ゲームシステムの入りやすさ、カードの販売戦略とのかみ合いが良く、 多くの人々に遊んでもらえるor一部の人が多く買ってくれるカードゲーム。 よく考えるカードゲーム プレイヤー同士の思考の末、より良く考えたプレイヤーが勝てるゲーム。 「将棋やチェスのような」もこれに関係するか? 「面白い」とは? 人によって面白いと感じる事はさまざまであるため、論争になりやすい。 この項では一部の例を紹介する。 考えることが面白い (一方的に/接戦の上で)勝てることが面白い 格好いいモンスターを操るのが面白い 個性的なモンスターを操るのが面白い オリジナリティーを発揮できるのが面白い ドローする(カードゲーム独特の動きをする)のが面白い 友達とコミュニケーションを取れるのが面白い つまらないゲームでないものは面白い できること(選択肢)が増えるのが面白い 「つまらない」とは? 人によって、つまらないとされることを面白いと感じることもあるため、論争になりやすい。 この項では一部の例を紹介する。 どちらかのプレイヤーが一方的に勝ち続ける ターンが回ってこない ロック(行動制限)やハンデス(選択肢を減らす) ルール、処理が複雑で面倒くさい(=プレイ感が悪い) 考えること(=選択肢)が少なすぎるor多すぎる 一部のカードが強すぎる(=デッキ構築の選択肢が少ない) カードゲームの作り方 思考派、直感派でも触れたとおり、ゲームの作り方は人それぞれ。 カードゲームはこう作る「べき」といった考えは多くの場合論争を生む。 デッキの存在 【デッキが存在する利点】 プレイヤーにランダムな選択肢を与え、毎回違った思考を与える。 デッキトップを参照する効果、デッキサーチなど、効果のバリエーションが増える。 カードをドローする感覚に快感を覚える人も居る。 【存在しない利点】 ランダム性が無くなり、運によって勝敗が左右されない。 メタゲームや三竦みの存在 大会では何人もの対戦相手と戦うことになる。 そのため、「大会で多く使用されているデッキ」に対して効果的なカードを使うと勝率を上げやすい。 そういったことを考え、勝率が高くなるようにデッキ(サイドボードを含む)を組むことが「メタゲーム」である。 略して「メタ」とも言われる。 (MTGwiki(http //mtgwiki.com/wiki/%E3%83%A1%E3%82%BF%E3%82%B2%E3%83%BC%E3%83%A0)より抜粋) 小型速攻と中型万能と大型パワー(22-115)のような三竦みはこの メタゲームの一角である。 メタゲームは多くのカードゲームにおいて自然と発生する。 メタゲームの無いカードゲームは作るのが困難かもしれない。 【メタゲームが存在する利点】 環境の読み合いが発生する。 【メタゲームが存在しない利点】 デッキ相性で勝負がつくことが無い。 【トップメタ(トップデッキ)が存在する利点】 初心者でも上級者に勝ちやすい。 上級者がトップデッキを使わない事で、意図的なハンデ戦を行える。 「弱いデッキで強いデッキに勝つ」ができる。 【トップメタ(トップデッキ)が存在しない利点】 あらゆるデッキが対等に戦える。 【メタゲームが複雑化する利点】 メタを読みづらく、その中でより多くの思考が生まれる。 【メタゲームが複雑化する欠点】 プレイ感が悪くなることがある。 また、製作者がメタゲームを想定していたとしても、 実際の環境がそうでないものになる場合がある。 それを防ぐにはより多くのプレイヤーに自由に遊んでもらう事が必要だが、 それが出来ない場合、いっそメタゲームを考えるのを放棄するのも一つの手である。 合成(融合・合体)の存在 【合成(融合・合体)が存在する利点】 合成する行為そのものが格好いい 強力なカードである事が解りやすい 強力なカードを支配できることが面白い 【合成(融合・合体)が存在する欠点】 合体のルールを覚える必要がある(=複雑になる) 合体のルールが世界観に反して違和感がある 合体ありきのゲームになる 合体が弱すぎて使う気になれない カード外の要素(ダイス・コイン・カウンター)の存在 【カード外の要素が存在する利点】 完全な(ゲーム要素に左右されない)ランダムを使える 数が多くなるものが制御しやすい 【ガード外の要素が存在しない利点】 持ち運びや片付けが簡単 紛失する可能性がない 世界観の存在 【世界観が存在する利点】 カードのイメージが強化される カードの魅力が増し、ヒロイックさや支配欲を掻き立てられる その世界観が好みのプレイヤーに遊んでもらえる 【世界観が存在しない利点】 世界観を気にせずカードを作れる プレイヤーの世界観の好みに左右されず、遊んでもらえる。
https://w.atwiki.jp/kikenyoutuber/pages/5.html
ここはただのコメント欄です、youtuberのページを作成希望をよこせください #comment( {[above], [below], [nodate],} )
https://w.atwiki.jp/wagashi/pages/9.html
同人ゲーム製作のまとめ 今後の活動内容 シューティングゲームやアクションゲームを中心に活動して行く予定。 パズルゲームも検討中。 ノベルゲーム製作も視野に入れるつもりです。 製作のメンバー グラフィック担当 流星群 プログラムミング担当 わたくぅ シナリオ担当 甘実ayato
https://w.atwiki.jp/advtukuro/pages/19.html
①概要 ◆ゲーム概要◆ 基本的に一本道。ほぼ見るだけのゲーム。 全11エピソード予定(増減する場合あり)。 PC・スマホ向けに配信。 製作はティラノビルダー(予定)。 お値段:0万円 ◆世界観・ストーリー◆ 現代の日本が舞台…だが、プレイヤーは細部に違和感を感じるだろう。 現実ではとっくの昔に失われた物が存在していたり、あるはずの物が失われていたり。 ひょっとしたら、この物語の世界は誰かの創作物かもしれない。誰かが描いた理想の世界。 と、意味深なことを言ってみたが、物語の大筋はなんてことはない。 ある年の冬、普通の青年が見知らぬ美少女と奇妙な共同生活を始める。 手垢がつきまくった、よく見かける三流ラブコメ的なアレだ。 ◆ゲームの狙い◆ 企画の源流はまとめによる「ライターやってみたい」という独りよがりな想いにある。 特殊な仕様はないから、製作難度はそんなに高くないはず。 とりま完成できればいい。肩の力を抜いて、製作に取り組んでいこう。 ◆作品の展開◆ 1話完結型なので、単話配信形式とし、完結後、1本にまとめて配信する。 と考えているのだがどうだろう…。 ◆イメージボード◆ ②ゲームの流れ ◆大まかな流れ◆ タイトル画面 ↓ 前回までのあらすじ(2章以降) ↓ ほんへ ↓ 次回予告 ↓ エンディング ↓ タイトル画面 ③システム ◆操作方法◆ 特殊な操作やシステムは無い。 ティラノビルダーにもともと備わってる機能だけでいけるはず。 ④アートディレクション ◆世界観◆ なんというか、現実世界と同じとしか言いようがない。 ◆ストーリー◆ wiki参照 ◆キャラクター◆ wiki参照 ⑤スケジュール 特にスケジュールとか考えてない。 ちゃんと制作進行を考えた方が製作しやすいのはわかってるが…。 とりま第一話を年内に完成。クリスマスエピソードとかあるけど別に気にしなくてよろしい。 6割くらいの素材は第一話で揃う(はず)なので、第一話が完成すればその後のエピソードの 制作は多少楽…だと思う。
https://w.atwiki.jp/wuri/pages/163.html
キャンペーン制作手順(翻訳) これは本家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 - BuildingScenariosAdvancedBuildingScenariosSimple - French VersionBuildingScenariosComments - Comments left for adviceBuildingScenariosSamples - Basic sample code BuildingScenariosShroudData - A tutorial on shroud_dataBuildingScenariosBalancing - How to balance your scenarioBuildingScenariosFAQ - 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 BuildingScenariosShroudDataMapGeneratorWML 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 TheCampaignFilehttp //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] BuildingCampaignsThePBLFilehttp //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ファイルのストリングを翻訳可能にするな。これは問題を起こし、決して機能できなくなる。同様に、前処理プログラムのマクロないしこのファイルに含まれているものを使うな。それらは全く前処理されないから。
https://w.atwiki.jp/vbmaker/pages/28.html
お願いと諸注意 当wikiはUTAU音源を自作することについての情報に重点を置いてます。 従ってUTAUの操作方法やustの作り方、DAWの操作などは他のサイトや解説動画を参照してください。 また、いわゆるUTAU式人力には言及いたしません。(参考になる部分はあるかと思いますが) 編集する方はこれらの点について留意していただくようお願いします。 音源制作支援・補助ツールについて 各ツールには利用規約や注意事項があります。 利用規約や注意事項をよくお読みの上規約を守り正しくお使いください。 当wikiでは紹介できていない、拾いきれていない情報もあります。 調べる方法は自分で検索したり詳しい人に聞いたり方法は様々ですが、最終的にはやる気や根気・試行錯誤が必要になります。 初めて音源を作りたい方は諦めずに完成までがんばってください。 piapro(ピアプロ)へのリンクに関して piaproではコラボ(コミュニティ)内に利用を限定しているものもあります。 その為piaproへのリンクは貼らないようにお願いします。 当wikiはリンクフリーです。 ツイッターなどで当wikiを紹介していただけると更新の励みになります。 編集について 個別ページの番号は極力変更しないようにしていますが変わる可能性があるのでご注意ください。 『載せてほしいものがあるけど編集の仕方が分からない』等ございましたら管理者までお問い合わせください。 また、万が一リンクしてほしくない記事・サイトがありましたら管理者までお知らせください。 お問い合わせ お問い合わせは下記連絡先までお願いします。 お問い合わせの際は「UTAU音源制作wikiについて」と添えていただけると分かりやすいです。 管理者:巽 Twitter: @UTAUVBwiki その他 2011年06月24日ごろに開設したらしい 当初はsetParamの操作方法を中心にまとめただけのサイトでした。
https://w.atwiki.jp/kkdgame/pages/20.html
スライム 攻3 HP30 アビ1 スラストライク 敵一体にダメージ(3) CT4 アビ2 ホイミ 自身のHPを回復(5) CT5 サポ 自動HP回復 自身に再生効果(2)