氷川 TRPG 研究室 / trpgtoolbox


RecentChanges Last 60

  1. RecentDeleted (1327d)
    • 2013-09-11 (水) 19:19:40 差分
  2. FrontPage (1729d)
    • 2012-08-06 (月) 00:09:10 by kilica 差分

      コミックマーケット82

      • 8/11 2日目 西地区す-3b 『犬山屋算譜』
      • 8/12 3日目 西地区ね-6b 『幻創体』
        に委託させていただく予定です!
  3. dungeon/​04編集/​​introduction (2013d)
    • 2011-10-26 (水) 23:07:50 by kilica 差分
  4. dungeon/​04編集/​​building (2014d)
    • 2011-10-25 (火) 23:33:54 by kilica 差分
  5. dungeon/​​introduction (2014d)
    • 2011-10-25 (火) 23:11:51 by kilica 差分

      特定のTRPGシステムに依存した内容ではなく、汎用的に使える内容になっています。主にファンタジー世界を舞台にしたTRPGを想定していますが、中核となる考え方は現代物やサイバーパンクなどでも応用できるようになっています。

      想定している読者 anchor.png Edit

  6. dungeon/​02編集/​​tactics (2023d)
    • 2011-10-16 (日) 23:20:43 by kilica 差分
  7. dungeon/​02編集/​​goal (2023d)
    • 2011-10-16 (日) 22:29:29 by kilica 差分

      ダンジョンの構成要素の一つにわかりやすく「宝物」を挙げましたが、実はこれは「シナリオの目的」と言い換えることができます。この場合、キャラクタたちは宝物を手に入れるためにダンジョンに入るのです。
      しかし、ダンジョンに入る目的は必ずしも宝物でなくても構いません。盗まれた形見を手に入れるでも、貴族の館から裏切りの証拠となる手紙をとってくることでも、さらわれたお姫様を救い出すことでも構いません。
      あるいは、宝物に相当するものはなく、ダンジョン内の敵を殲滅する、邪悪な魔術師を倒す、防御施設を破壊する、備蓄されている兵糧を焼き払う、といった「シナリオの目的」を設定しても構いません。

      単なる宝物の入手からシナリオの目的を変更すると、変わるのはフレーバーだけでなく、キャラクタたちがとるべき戦術も変わるばあいがあります。むしろシナリオを作る場合には、そちらの影響の方がずっと重要になります。

      例えば、敵の殲滅や邪悪な魔術師の退治が目的であれば、逃げられないよう工夫する必要があるかもしれません。人質を救出するのであれば、その命を盾に取られないようなるべく隠密裏に潜入しなければならないでしょう。裏切りの証拠となる手紙を手に入れたいのであれば、その目的を悟られないようにしないと燃やされ証拠隠滅を図られてしまうかもしれません。

  8. dungeon/​​component (2023d)
    • 2011-10-16 (日) 22:03:25 by kilica 差分

      _ ダンジョン anchor.png Edit

      ダンジョンとは、もともとヨーロッパの城の中核部分を意味する単語からきています。ウィキペディアでは、次のように説明されています。

      ダンジョンは、君主を意味するラテン語の "dominus" に由来する古フランス語である。 中世においては、城の最重要部である天守 (Keep) を意味した。(中略)また、ダンジョンは典型的な城の作りとして城の真下に作られる、地下納骨堂や牢屋をも意味するようになった。

      また、多くのゲームでは怪物のうろつく地下迷宮や洞窟などを指してダンジョンと呼ぶことが多いかと思います。

      本書では、「ダンジョン」を広い意味でとらえ、危険な「敵」のいる閉鎖的な空間を指して呼ぶことにします。洞窟、地下迷宮、城の地下牢などを始め、館、砦、遺跡、鉱山、ビル、一般の家屋なども「ダンジョン」に含めます。また「敵」にも、凶暴な動物、怪物、邪悪な魔術師をはじめ、キャラクタたちに害をなすのであれば警備員などが含まれることになります。

      Page Top

      ダンジョンシナリオのなりたち anchor.png Edit

  9. dungeon/​​system (2023d)
    • 2011-10-16 (日) 20:31:41 by kilica 差分
  10. dungeon/​03編集/​​objects (2023d)
    • 2011-10-16 (日) 20:18:49 by kilica 差分
      • 隠し扉
      • テーブル・椅子・ベンチ
      • 寝台
      • 棚(食器、金品、書籍、薬品、衣類、雑貨)
      • 箱・櫃
      • 暖炉
      • 絨毯
      • タペストリ
      • 階段
      • はしご
      • 像・浮き彫り
      • 手紙
      • 書籍
      • 紋章入りの物品
      • 照明・燭台
      • 牢獄
      • 倉庫(武器、食料、薬草、雑貨、衣類)
      • 死体
  11. dungeon/​03編集/​​terrain (2028d)
    • 2011-10-11 (火) 22:39:17 by kilica 差分
  12. dungeon (2029d)
    • 2011-10-10 (月) 10:35:10 by kilica 差分
        • 舞台編集
        • 整合性編集
        • ダンジョンに入る前編集
  13. dungeon/​​summary (2029d)
    • 2011-10-10 (月) 10:32:12 by kilica 差分
  14. dungeon/​​dungeon4 (2029d)
    • 2011-10-10 (月) 09:54:47 by kilica 差分
  15. dungeon/​​dungeon3 (2029d)
    • 2011-10-10 (月) 09:26:54 by kilica 差分
  16. dungeon/​01編集/​​improvement2 (2030d)
    • 2011-10-09 (日) 22:19:21 by kilica 差分
  17. dungeon/​01編集/​​action (2030d)
    • 2011-10-09 (日) 13:10:16 by kilica 差分

      また、部屋から出入りすることはないとしても、パーティが近づいてくることを察知したときに何かアクションを起こすかもしれません。武器を構える、隊列を整える、不意を討とうと扉の影に隠れる、防御の呪文をかける、奥の部屋に増援を呼びに行く、などなど。

  18. dungeon/​01編集/​​improvement (2030d)
    • 2011-10-09 (日) 13:06:36 by kilica 差分
      モンスターのいる部屋を入れ替えてみる
      モンスターのいる部屋を入れ替えて考えてみてください。一番よく見るのは、入り口の敵は弱く、奥の敵は強く、一番奥にラスボスがいる、という順番です。でもそれが一番でしょうか? 大胆に、ラスボスを入り口に配置するとどうでしょうか?
      部屋の中の配置を変えてみる
      パーティが部屋に足を踏み入れた時のモンスターの配置を変えてみます。入り口付近にいるのか、部屋の奥にいるのか、塊っているのかバラバラにいるのかによって、戦闘の中でキャラクタたちの取るべき戦術が変わってきます。
  19. dungeon/​01編集/​​info (2030d)
    • 2011-10-09 (日) 12:37:24 by kilica 差分
  20. dungeon/​​dungeon1 (2030d)
    • 2011-10-09 (日) 11:29:38 by kilica 差分
  21. dungeon/​​size (2031d)
    • 2011-10-08 (土) 11:18:16 by kilica 差分
  22. dungeon/​​building (2031d)
    • 2011-10-08 (土) 11:00:02 by kilica 差分
  23. shop (2085d)
    • 2011-08-15 (月) 17:33:52 by kilica 差分

      コミックマーケット80で頒布した同人誌『TRPGシナリオ作成の道具箱』の委託先ショップ様を探しています。B5サイズ 60ページ の同人誌です。
      本書は、同会場で開場後2時間で100部完売致しました。

  24. about (2107d)
    • 2011-07-25 (月) 00:31:24 by kilica 差分

      ご意見、追加の課題や制約などありましたらお気軽にお寄せください。

  25. challenge/​​trip (2107d)
    • 2011-07-25 (月) 00:22:25 by kilica 差分
      ページ内コンテンツ
      • 《突破》
        • 《課題》で設定する項目
        • ポイント
        • 制約

      _ 《突破》 anchor.png Edit

      《突破》の課題では、守備隊に守られている場所を越えて移動しなければなりません。
      国境の関所、都市の門などが《突破》の対象の典型です。時には強引に力づくで、時にはひっそりと人知れず、また時には警備を言いくるめて、防御網の突破を目指すのがこの課題です。

      Page Top

      《課題》で設定する項目 anchor.png Edit

      指揮系統
      指揮者の能力
      警備
      警備者の種類と数、警戒レベル、モラル
      場所
      突破対象の地図、警備者の配置
      経路
      突破時の移動経路。複数設定することもできる。
      Page Top

      ポイント anchor.png Edit

      この課題のポイントは、突破のルートと突破の方法の選択にあります。《捕獲・救出》の課題に似たゲームのポイントを持ちます。

      • 戦闘で力押しをする
      • こっそりと忍び込み、知られないように通過する
      • 陽動作戦で警備を手薄にして通過する
      • 買収など交渉によって警備をかわす
      Page Top

      制約 anchor.png Edit

      〈情報〉の制約をかける
      守備隊に関する情報の一部が分からない、あるいは間違っている、複数の矛盾した噂があるなど、不確定になっています。
      〈お忍び〉の制約をかける
      正体がバレてはいけません。強行突破するときに一部の武器(素性がバレるようなもの)が使えなくなるかもしれません。
  26. challenge/​​cooperate (2107d)
    • 2011-07-25 (月) 00:19:12 by kilica 差分

      _ 《説得》 anchor.png Edit

      《説得》の課題では、キャラクタたちは説得、脅迫、買収、交渉などにより対象となる人物の協力を取り付けます。
      説得が成功すれば、交渉相手はその権力、財力、情報力、戦力などを使ってキャラクタたちを手助けしてくれます。

      Page Top

      《課題》で設定する項目 anchor.png Edit

      交渉内容
      交渉相手に何を頼むか
      交渉相手
      交渉相手、能力、キャラクタたちとの関係、交渉材料。交渉相手は複数設定する。
      Page Top

      ポイント anchor.png Edit

      交渉は多くのシステムでルール化が進んでおらず、サイコロなどの一振りで決まるか、それすらなくプレイヤの口八丁に委ねられる場合がほとんどです。そのため、複数の交渉相手を用意しておくのは、失敗した場合のセーフティネットにもなります。

  27. challenge/​​procurement (2107d)
    • 2011-07-25 (月) 00:17:38 by kilica 差分
      ページ内コンテンツ
      • 《調達》
        • 設定する項目
        • ポイント
        • 制約

      _ 《調達》 anchor.png Edit

      Page Top

      設定する項目 anchor.png Edit

      Page Top

      ポイント anchor.png Edit

      大量購入
      通常では考えられない量のものを購入しなければなりません。当然一店舗で扱う範囲を超えていますので、街中の店を手分けして探し回る、さらには隣町まで行くといった行動を要求されるでしょう。最悪の場合は、入荷待ちとなり、流通に顔のきく人物を探したり割増の料金を支払うなどして一刻も早く入手できるよう取り計らってもらう必要が出てくるかもしれません。
      良品を選別
      粗悪な品が流通する中、良品を手に入れなければなりません。キャラクタにそれを見抜く目が備わっていれば選ぶだけですが、そうでなければ購入先を吟味する、目利きを探して確認してもらう、運にかける、などの対策が必要となります。
      Page Top

      制約 anchor.png Edit

      〈時間〉の制約をかける
      一定時間内に入手しなければなりません。スムースに行かなければ、[資金]や[コネ]などのリソースを費やして入手することになります。
      〈隠密〉の制約をかける
      第三者(多くは敵)に、調達活動を悟られないようにしなければなりません。ばれた場合は、調達活動の妨害(買い占め、価格の吊り上げなど)が入ったり、もっと直接的に襲われる危険性が出ます。
  28. challenge/​​information (2107d)
    • 2011-07-25 (月) 00:15:43 by kilica 差分
      ページ内コンテンツ
      • 《情報収集》
        • 設定する項目
        • ポイント
          • 情報に優先度をつける
          • リソース消費の判断
          • リスク

      _ 《情報収集》 anchor.png Edit

      多くの小説や映画で、序盤から中盤にかけて主人公達の中心的な活動を占めます。

      Page Top

      設定する項目 anchor.png Edit

      入手方法
      情報を入手可能な手段:特定の人物に聞く/特定の人物から情報を買う/うわさ話として流れている/書物に書かれているetc
      情報の信頼性
      情報の真偽、正確性、鮮度、精度
      Page Top

      ポイント anchor.png Edit

      Page Top

      情報に優先度をつける anchor.png Edit

      すべての情報を揃えられればいいですが、時間や資金の都合上、必ずしもそうは行きません。その場合、どの情報を優先して手に入れるかを判断しなければなりません。情報の優先度は、状況やキャラクタの能力によっても変わってきます。場合によって敵の数が重要になることも、指揮官の能力や性格のほうが重要になることもあります。

      また情報によって入手の難易度を変えてやります。プレイヤとしては「簡単に手に入る重要な情報」を優先したいところですが、そんな都合のいい情報はつくらずに、「重要だけど手に入るかどうか分からない情報」にかけるか、「あまり重要ではないが確実に手に入る情報」で我慢するかなど、選ばせます。

      Page Top

      リソース消費の判断 anchor.png Edit

      Page Top

      リスク anchor.png Edit

      情報がただで手に入らないのは常識ですが、さらには対価だけでなくリスクを犯さなければ手に入らないこともあります。危険な場所に赴かないと手に入らない、情報を知っていることを快く思わない勢力に目をつけられる、といった危険な情報(殺人鬼の正体とか)も世の中にはあるのです。

  29. challenge/​​defense (2107d)
    • 2011-07-25 (月) 00:14:09 by kilica 差分
      ページ内コンテンツ
      • 《防衛》
        • 設定する項目
        • ポイント
          • 情報を与える
          • 戦術

      _ 《防衛》 anchor.png Edit

      押し寄せる敵軍から城を守ったり、野盗に襲われる村を守ったりと、「守る」という行動によってキャラクタたちがヒーローになれる《課題》です。

      Page Top

      設定する項目 anchor.png Edit

      防衛対象
      場所、防衛設備
      指揮官、敵の種類、数、配置、行動パタン
      場所
      防衛対象の地形、侵入ルート、防衛に有利な場所と不利な場所
      Page Top

      ポイント anchor.png Edit

      Page Top

      情報を与える anchor.png Edit

      この課題のポイントは、敵の動きを予測し、それにいかに備えるかというところにあります。敵の総勢が分かっていれば、攻め手の意図や陽動の可能性、リソースの配分を考慮することができますが、分からなければ守るのは非常に困難になります。アカウンタビリティの観点から、敵の総勢がかなりの精度で分かっている方がいいでしょう。

      敵指揮官の情報も重要です。頭がよく指揮能力が高ければ、陽動のような戦術を取ってくる可能性も考えられます。反対に、頭が良くなければ単純な力押しの可能性が高いでしょう。せっかちな性格であれば全軍ですぐにも押し寄せてくるかもしれませんし、慎重な性格であれば偵察隊を出して様子を見ながら攻めてくるかもしれません。

      敵が諦める条件が分かっていれば、その条件をみたすように積極的に行動することが可能になります。

      Page Top

      戦術 anchor.png Edit

      敵の攻撃は一回とは限りません。最初に偵察的に小部隊を出してくるかもしれませんし、陽動を仕掛けてくるかもしれません。援軍を待ちきれずに、先走る連中が頭の悪い攻撃をかけてくるかもしれませんし、攻撃しては逃走する行動を繰り返しパーティを休ませないといったいやらしい攻撃を仕掛けてくるかもしれません。

      侵入ルートの数に比べてキャラクタたちの人数が少なければ、苦労することになります。撤退しながら時間を稼ぎ援護を待つなど、高度な戦術を要求されますので、ルートは二つかせいぜい三つ程度に抑えたほうが良いでしょう。

      戦力的には固まっていたほうがいいのですが、その場合、攻撃を受けたときに迎撃準備をする間もなく全員が戦闘に巻き込まれることになってしまいます。

  30. challenge/​​capture (2107d)
    • 2011-07-25 (月) 00:12:17 by kilica 差分
      〈情報〉の制約をかける
      警備状況、標的の活動パタンなど、一部の情報が分かっていません。
  31. challenge/​​defeat (2107d)
    • 2011-07-25 (月) 00:10:32 by kilica 差分

      _ 《制圧》 anchor.png Edit

      シナリオのクライマックスでは、たいていこの《制圧》の課題が待ち受けています。

      Page Top

      設定する項目 anchor.png Edit

      指揮官
      能力、戦術、目的
      目的、敵の種類、数、配置、士気、行動パタン
      環境
      地形(地下、野外、足場、障害物、遮蔽、川)、高低差、閉所、天候、風、時間、照明
      Page Top

      ポイント anchor.png Edit

      TRPGシステムの多くは、《制圧》の課題を解決するための戦闘ルールが充実しており、単純にルールブックに載っている敵を見繕って出せば、それだけでゲームとして成立します。一方、そのようなTRPGシステムでは、毎回のように戦闘が発生するため、そのうち単に敵を出すだけでは飽きられてきます。
      そこで、以下のような工夫を凝らします。

      戦場の広さ
      広い場所と狭い場所の使い分けが基本です。キャラクタたちの人数が多ければ、なるべく広い場所で戦う方が有利ですし、敵の数が多ければなるべく狭い場所で戦うほうが有利です。
      環境
      障害物の多い場所(飛び道具は不利。隠密系のキャラクタには有利)、水辺、船上、暗闇、高低差など、戦場の種類で様々な変化をつけることができます。
      敵の強さと数
      強力な力を持った敵をひとりだけ出す、そこそこの力の敵を数体出す、弱い敵をたくさん出す、という組み合わせが基本です。
      敵に有利な環境・戦術
      やや弱めの敵を多数用意し、パーティの中でも弱いキャラクタに攻撃を集中する、飛び道具で全員武装している、少数の強い敵が狭い通路で待ち受けている、多数の敵が広い場所で戦う、奇襲しようと待ち構えている、などなど。

      パーティに有利な環境・戦術|敵を強めにし、パーティに奇襲させる、有利な地形で戦わせる、敵を一度に出さず数ラウンド後など分散して登場させるなどで戦力差を補うよう仕向けます。

      さらにレベルの高いプレイヤたちには、敵の意図を読んでその弱点を突くことを要求してみましょう。例えば、(援軍などを期待して)時間稼ぎをしようとしている、特定の敵(ボスなど)をとにかく守ろうとしている、短期間に決着をつけようとしている、力を出し惜しみしている、など敵が何を第一に考えているか、敵にとっての勝利条件を敵の行動から察して、逆手に取らなければ勝てない敵を用意します。

      敵の行動から類推させるのが難しそうであれば、事前の情報収集で敵の目的あるいはそのヒントを得られるようにします。

  32. reference (2107d)
    • 2011-07-24 (日) 23:44:27 by kilica 差分

      _ 参考文献 anchor.png Edit

      今回本書を書くにあたって特に参考にしたものに絞っております。
      概ね、参考になった順に並んでおります。

      • 馬場秀和、『馬場秀和のマスターリング講座』、http://www004.upp.so-net.ne.jp/babahide/​master.html
      • 馬場秀和、『馬場秀和のRPGコラム』、http://www004.upp.so-net.ne.jp/babahide/​bbcolumn.html
      • 「ニフティサーブ」 #FRPGM ※現在サービス廃止
      • 「ペテン師の戯言」 http://blog.talerpg.net/rpg/
      • 『ダンジョンズアンドドラゴンズ第4版 ダンジョンマスターズガイド』、ホビージャパン、2009
      • 『ダンジョンズアンドドラゴンズ第4版 ダンジョンマスターズガイド II』、ホビージャパン、2010
      • 榊原遥子、『TRPGのある風景 総集編(3)』、サークル欠食児童、2007
      • 桐生茂、『シナリオメイキングガイド』、新紀元社、1991
      • 「オリジナルシナリオをつくろう!」『ロール&ロール vol.42』、新紀元社、2008
      • 江渡浩一郎、『パターン、Wiki、XP』、技術評論社、2009
      • 大塚英志、『キャラクターメーカー』、アスキー新書、2008
      • 大塚英志、『ストーリーメーカー』、アスキー新書、2008
      • 井上純弌+菊池たけし/F.E.A.R.、『エブリデイマジック』、エンターブレイン、2007
      • 北沢慶/グループSNE、『挑戦!魔剣が呼ぶ迷宮』、富士見書房、2008
      • 北沢慶/グループSNE、『風雲!歌声が響く都市』、富士見書房、2008
      • 「ゲームマスターをやろう!2009」『ロール&ロール vol.56』、新紀元社、2009
        なお、TRPGとは関係ありませんが、本書における《課題》のイラストには「無料アイコン素材」の素材を利用させていただいています。
        http://free-icon.org/index.html 「サイト・チラシ作成によく使う 無料アイコン素材」
  33. column編集/​​CreativeCommons (2107d)
    • 2011-07-24 (日) 23:42:53 by kilica 差分
      <a rel="license" href="http://creativecommons.org/licenses/by/2.1/jp/"><img alt="クリエイティブ・コモンズ・ライセンス" style="border-width:0" src="http://i.creativecommons.org/l/by/2.1/jp/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">TRPGシナリオ作成の道具箱</span> by <a xmlns:cc="http://creativecommons.org/ns#" href="trpg-labo.com" property="cc:attributionName" rel="cc:attributionURL">HIKAWA Kilica</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/2.1/jp/">Creative Commons 表示 2.1 日本 License</a>.
  34. scene/​​pattern (2107d)
    • 2011-07-24 (日) 23:39:47 by kilica 差分
      ページ内コンテンツ
      • シーン構成のパターン
        • ダンジョンシナリオ
        • F.E.A.R.シナリオ
        • 《情報収集》+《踏破》+《制圧》

      _ シーン構成のパターン anchor.png Edit

      「TRPGシナリオ作成の道具箱」では、【シーン】を組み合わせてシナリオを作ります。どんなシーンをどう組み合わせるかは自由ですが、市販されているシナリオを見ていると、典型的と呼んでいいような組み合わせも存在します。

      Page Top

      ダンジョンシナリオ anchor.png Edit

      ダンジョンシナリオは、シナリオの基本中の基本です。世界で最初のTRPG、D&Dはまさにダンジョンシナリオから始まりましたし、最近でも『ソード・ワールド2.0』の最初のシナリオ集はダンジョンシナリオがテーマでした。
      さて、ダンジョンシナリオのパタンは、ひたすら《制圧》です。《制圧》+《制圧》+《制圧》+……と、モンスタのいる部屋の数だけ《制圧》シーンを繰り返します。
      ダンジョンシナリオは、追求していくとそれだけで一冊本が書けるくらいの奥の深さを持ちます。

      少々古いですが、こちらもどうぞ。

      http://www.trpg-labo.com/rpg/dungeon/dun​geon.pdf

      Page Top

      F.E.A.R.シナリオ anchor.png Edit

      F.E.A.R.社が出している『アルシャード』『ブレード・オヴ・アルカナ』『ダブルクロス』『アリアンロッド』などの一連のTRPGのシナリオで共通して使われているシナリオフォーマットがあり、本書の流儀で読みなおすと、《情報収集》+《制圧》になります(もう一種類シナリオのパターンがあり、それは一つ、または二つの《制圧》シーンのみからなります)。

      もっとも、このフォーマットはF.E.A.R.製のものに限らず広くTRPGのシナリオで使われており、ダンジョンシナリオと並んで基本的なパターンと言えます。

      Page Top

      《情報収集》+《踏破》+《制圧》 anchor.png Edit

      F.E.A.R.シナリオに《踏破》が加わったパターンです。情報を集めて、敵の本陣まで移動して、敵を倒す、というこれまた基本的な流れを踏襲したパターンです。

  35. column編集/​​independentscene (2107d)
    • 2011-07-24 (日) 23:37:05 by kilica 差分

      _ イメージからシナリオを作る anchor.png Edit

      「TRPGシナリオ作成の道具箱」では、シナリオについてなんのイメージもないところからバラバラにシーンを作り、それを組み立ててシナリオにする、という作り方をします。といいますか、そういう説明の仕方をしてきました。しかしそれは、先に全体のストーリーを考えてから作る方法だと、ストーリーが思い浮かばずに止まってしまう人がいるからです。先に《課題》や〈制約〉を選んでからストーリーを考えるやり方は、三題噺で物語を作るように、発想のとっかかりになってくれます。
      一方、作りたいシナリオのイメージがある程度頭の中にある方は、それに沿って《課題》や〈制約〉を選んでシナリオを作ることもできます。その場合、頭の中にあるストーリーのうちどの部分をゲームとして切りだしてシーンにするかを吟味します。

      Page Top

      シーン間のつなぎ anchor.png Edit

      思い描いている物語全てを、【シーン】で表現する必要はありません。

      というより、「TRPGシナリオ作成の道具箱」は、TRPGのシナリオ全体をカバーしているわけではないので、シナリオのすべての要素を「道具箱」に用意された道具立てで表現するのは無理があります。

      例えば「TRPGシナリオ作成の道具箱」は、シーンとシーンの間をどうつなぐかについて、なんのサポートもしていません。その部分はシナリオ作成者に丸投げになるのですが、おすすめはシーンとシーンの間に何があったかはゲームマスターが一方的に説明する、というやり方です。これを「シーン独立型シナリオ」と呼んでいます。

      Page Top

      シーン独立型シナリオ anchor.png Edit

      あるシーンが終わり、次のシーンの開始まで、キャラクタたちがどう行動し、どんな事件が発生したかをゲームマスターが説明します。シーン開始時の状況は、ゲームマスターの思うがままです。例えば、「情報収集を終えて敵の砦に向かったパーティであったが、途中運悪く敵兵に発見され囲まれ捕まってしまった。武具は取り上げられ、いま君たちは錆びかけた鉄格子の檻の中にいる。」と、超強引にストーリーを展開することができます。

  36. column編集/​​infohandling (2107d)
    • 2011-07-24 (日) 23:36:08 by kilica 差分
  37. column編集/​​selectscene (2107d)
    • 2011-07-24 (日) 23:35:03 by kilica 差分

      キャンペーンレベルで選ばせる anchor.png Edit

  38. column編集/​​inspiration (2107d)
    • 2011-07-24 (日) 23:33:56 by kilica 差分
  39. column編集/​​exgame (2107d)
    • 2011-07-24 (日) 23:29:42 by kilica 差分
      ページ内コンテンツ
      • イベント
        • イベントの役割
          • セッションを立て直すイベント
          • ゲーム性を増すイベント
        • イベントの発生

      _ イベント anchor.png Edit

      「イベント」はシーンの途中、あるいはシーンの間(シナリオの開始時と終了時を含む)に挟み込まれる出来事で、原則としてゲームマスターから一方的にキャラクタたちに起こったことが伝えられます。「イベント」は、しばしばゲームの条件を変更する役割を持ちます。

      Page Top

      イベントの役割 anchor.png Edit

      イベントそのものはゲームの要素ではありませんが、イベント発生の結果、ゲームの要素である《課題》〈制約〉[リソース]が変化することがあります。

      《課題》の追加・削除
      イベントの発生により、新たな《課題》が追加になったり、今やっている《課題》や次に取り組む予定の《課題》が取り消されたりします。また、過去に失敗に終わった《課題》がフォローされることもあります。親しいNPCが誘拐され《救出》の課題が発生したり、これから説得に向かおうとしていたNPCがそれを聞いて急に協力的になったりします。
      〈制約〉の追加・削除
      イベントの発生により〈制約〉が追加になったり、解除されたり、厳しくなったり緩められたりします。
      [リソース]の追加・削除
      イベントの発生により[リソース]が追加になったり使えなくなったりします。伝令が到着して思ったより敵の援軍が早く到着しそうだと分かり、[時間]のリソースが減ったり、事情を知った有力者が協力を申し出てくれたため[動員]ができるようになったりします。
      情報
      イベントの発生により情報がもたらされます。敵の根城がわかったり、アイテムの使い方がわかったりします。
      謎の発生
      イベントにより謎が発生します。
      関係の変化
      イベントの発生により味方だったNPCが敵に回ったり、敵だったNPCが協力してくれたりします。

      ゲームの要素(《課題》〈制約〉[リソース])が変化すると、プレイヤたちの計画は崩れ、過去の意志決定に対する無力感が生じてしまう危険性があります。そのため、イベントでこれらを変化させる場合は、プレイヤたちの納得のいく形で発生させるよう十分注意してください。例えば、そのようなイベントが将来発生するかもしれないことを噂やNPCを通じて予め伝えておきます。

      Page Top

      セッションを立て直すイベント anchor.png Edit

      コンベンションなど制約の多いプレイ環境では、一種の保険としてイベントを用意します。例えば、コンベンションの終了時刻までに終わりそうになければ、イベントを発生させて途中の《課題》を省略します。反対に、思ったより早く進んでいるのであれば、イベントを発生させて課題を追加します。

      ゲームバランスが厳しすぎた場合は、イベントを発生させて[リソース]を追加したり、失敗した《課題》のフォローをしたりします。

      ただしこれらの行為は、ともするとゲームの楽しさを減じかねませんので、乱用は避けるべきです。

      Page Top

      ゲーム性を増すイベント anchor.png Edit

      先述のとおり、イベントを安易に使うとゲームとしての面白さを壊しがちなのですが、うまく使うことで反対にゲームを面白くすることもできます。

      イベントによって《課題》や〈制約〉が変化するかもしれない、という前提に立つと、プレイヤたちがシナリオの展開を読むことが難しくなります。また、「TPRGシナリオ作成の道具箱」でシナリオをつくると、シーンの独立性が強いためこじんまりとしたセッションになりがちですが、イベントをうまく使うことでダイナミックにストーリーが変化していく楽しさをそこに付け加えることができます。

      Page Top

      イベントの発生 anchor.png Edit

      イベントは、特定の条件(決められた日時になる、キャラクタたちが特定の場所にいたり特定の行動をする)を満たしていればキャラクタたちが能動的に動いてなくても発生します。

      例えば、ある日時になるとNPCがキャラクタたちに接触してきて相談事を持ちかけるイベント、町の酒場に行くと噂を耳にするイベントなどがあります。

      その他、イベントの典型例としては、シナリオ開始時の導入部、シナリオ終了後のエピローグがあります。

  40. resource (2107d)
    • 2011-07-24 (日) 23:27:02 by kilica 差分
      ページ内コンテンツ
      • リソース
        • リソース:[時間]
        • リソース:[資金]
        • リソース:[人員]
        • リソース:[NPC]

      _ リソース anchor.png Edit

      キャラクタによっては、[リソース]と同じものを個人的に所有しているかもしれませんが、それは[リソース]としては扱いません。あくまでもシナリオを通じて提供されるものを[リソース]と呼びます

      Page Top

      リソース:[時間] anchor.png Edit

      [時間]リソースは通常、シナリオのタイムリミットという形で提示されるリソースです。

      時間に関しては〈制約〉にも同じく〈時間〉の制約がありますが、これは特定の【シーン】または《課題》に付随しているのに対し、[時間]リソースはシナリオ全体に対して設定され、どのシーンにどれだけの時間を費やすかはキャラクタたちの判断に委ねられます。

      Page Top

      リソース:[資金] anchor.png Edit

      [資金]のリソースは、シナリオ中にパーティが使うことのできる経費を表し、シナリオの依頼主から提供されるのが一般的です。キャラクタたちが個人的に持っている資金とは別に考えます。

      [資金]のリソースは、報酬の一部として渡される場合と、一定の上限が設けられ申告によって払い戻される経費の形を取る場合があります。

      報酬の一部として渡される場合、使わなければその分キャラクタたちの報酬が増えることになります。経費の形を取る場合は、使おうが使うまいがキャラクタたちの報酬に変化はありません。ゲーム的には、思い切りよく使える後者の経費の形を取るほうが面白くなると思います。

      Page Top

      リソース:[人員] anchor.png Edit

      [人員]リソースでは、単純な作業に従事できる多数の人員をキャラクタたちは動員できます。通常は、依頼主などが[人員]リソースを用意し、キャラクタたちに指揮権を与えます。

      代表的なところでは、建物周辺の警備、街を出入りする人々の見張り、街中での聞き込み、図書館での単純な検索などがあります。

      [人員]リソースでは、技術を要する高度な作業や難しい判断をさせることはできません。警備はできますが強敵を前にすればやられるでしょうし、優秀な密偵を相手にすれば出入りを見逃してしまいます。専門書を読みこなすことはできませんし、集められる情報は誰もが耳にすることができるようなうわさ話です。

      当然、[人員]リソースも有限です。人数が限られているのはもちろん、使える回数も1回だけ、3日間だけ、など決まっています。

      Page Top

      リソース:[NPC] anchor.png Edit

      [NPC]は、強い力を持つNPCをキャラクタの判断で動員できるリソースです。

      [人員]リソースとは異なり、通常はひとりだけで、専門的な能力を持っていたり、高い地位についているなど、強力に、また柔軟にキャラクタたちをサポートすることができます。

      [人員]リソースと同様にこのリソースも有限です。動員できる回数や日数に限りがあります。

  41. restriction (2107d)
    • 2011-07-24 (日) 23:26:21 by kilica 差分
      ページ内コンテンツ
      • 〈制約〉
        • 制約:時間
        • 制約:〈隠密〉
        • 制約:〈お忍び〉
        • 制約:〈装備〉
        • 制約:〈情報〉
        • 制約:〈移動〉
        • 制約:〈足手まとい〉
        • 制約:〈敵対者〉

      _ 〈制約〉 anchor.png Edit

      〈制約〉は《課題》とセットで使われ、キャラクタたちがその《課題》を解決するに当たって禁止されていること、使えない物を指します。
      物理的な制約(地形的に入り込めない〈移動〉の制限)、社会的な制約(武器の携行が禁止されている〈装備〉の制約)、依頼主の指定(正体がバレないようにという〈お忍び〉の制約)など、理由は問いません。

      キャラクタたちが〈制約〉を破った場合の影響は様々です。「正午迄に約束のものを持ってこい」というような〈時間〉の制約を破った場合は、そのシーンの失敗になるかもしれません。〈隠密〉や〈お忍び〉の制約を破ると、敵対者に追われることになったりします。〈情報〉の制約はそもそも破れなかったりします。〈制約〉を破った場合にどうなるかは、シナリオ制作者が決めます。多くの場合は、なぜ制約が設けられているのか、その理由と密接な関係があるでしょう。

      ゲームマスタとしてやってみたいシーンがあるんだけど、平凡な行動なので《課題》にならない、という場合は〈制約〉を加えてみてください。〈制約〉を加えることで、なんでもない作業をとてつもないチャレンジに変えることができます。30分以内に渋谷駅の改札に来い、誰にも見られずに城を出ろ、亡者の群れを前にナイフ一本しかない、などなど。1時間あれば寄り道しても到着できるし、見られてもよければ目をつむっていても出られるし、愛用の聖剣があれば1分であの世に送り返せるよう、そういった作業が、〈制約〉によって困難な課題へと姿を変えます。

      Page Top

      制約:時間 anchor.png Edit

      〈時間〉の制約は厳しいもので、簡単にクリアできる【シーン】を、一転、困難にしてしまうくらいの制限をかけることでゲームを作り出します。例えば、「3日間のキャンプに必要な物資を揃える」という課題は難しくありませんが、「1時間以内に」というと、簡単ではなくなります。ひとつのお店で揃わないかもしれませんし、たまたま品切れだったものが出てきた時の対処も考えておかなければなりません。予算が決まっていれば、なんでも買えばいいというわけでもありません。パーティで分担して段取りを決めてかからなければならないでしょう。

      〈時間〉の制限を課す場合、制限時間を示すのではなく、制限時間内に何回行動できるか、をはっきりと示すことが重要です。例えば、「制限時間は6時間です」と示すのではなく、「制限時間は6時間で、1回の行動あたり2時間かかります」(つまり3回の行動が許されている)とプレイヤたちに伝えます。

      Page Top

      制約:〈隠密〉 anchor.png Edit

      〈隠密〉の制約のもとでは、一定の期間、キャラクタたちは活動していることを知られてはなりません。活動していることが知られた場合、キャラクタたちのもとに守備隊が押し寄せてきたり、人質に危害が加えられたり、依頼者の政治的立場が悪化したりすることになります。

      〈お忍び〉の制約に似ていますが、〈お忍び〉の制約は正体が掴まれなければ活動自体は構わないのに対して、〈隠密〉では活動自体知られてはならないため、より厳しい制約となっています。

      Page Top

      制約:〈お忍び〉 anchor.png Edit

      〈お忍び〉の制約のもとでは、キャラクタたちは正体がバレないように活動しなければなりません。例えば顔を見られて覚えられてはいけませんし、身元情報につながるような、クレジットカードで購入する、特定の人間しか使えない特殊な能力を使う、指紋を残す、といった行為にも注意する必要があります。

      この〈制約〉を選んだら、シナリオ制作者は「何が」バレてはいけないかを決めます。最も厳しい制約はキャラクタたちの素性がばれないような制約ですが、護衛対象のお姫様の正体さえばれなければよい、国宝とも言われる魔剣を所持していることがばれなければよい、といった制約のかけ方もあります。

      Page Top

      制約:〈装備〉 anchor.png Edit

      キャラクタたちの使える装備が制限されています。

      Page Top

      制約:〈情報〉 anchor.png Edit

      〈情報〉の制約では、課題の解決のために重要となる情報が欠落しています。そのため、プレイヤたちは簡単に最適解を導き出すことができなくなります。

      例えば、キャラクタたちが敵の砦を《制圧》する課題を考えてみましょう。そのために有益な情報としては、

      • 砦の地図
      • 指揮官
      • 守備兵の種類
      • 守備兵の装備
      • 守備兵の数
      • 守備兵の配置
      • 備蓄
      • 援軍の有無

      などがあります。これらすべてがわかった状態であれば、どこからどう攻めるのが有効か、割り出すのも難しくないかもしれません。しかし例えば、このうち「守備兵の配置」の情報が分かっていないとすると、どこが手薄なのかわからず、地図などから推測するしかありません。また「指揮官」の情報が欠けていれば、最初に指揮官を叩いて短期決戦に持ち込む戦術が難しくなるでしょう。

      他の〈制約〉に比べると、〈情報〉の制約はやや高度で注意しなければなりません。

      まず、「この情報が無いとシーンをクリア出来ない」という情報に〈制約〉をかけてはいけません。例えば、「砦の位置」に制約をかけるとキャラクタたちは砦にたどり着けなくなってしまいます。

      また、〈情報〉の制約をかけてゲーム的に面白くなるかどうかを見極めるのは簡単ではありません。隠蔽した情報の価値が低ければキャラクタたちには無視されてしまいますし、価値の高すぎる情報を隠蔽すると、キャラクタたちは運を天に任せて作戦もなく課題にとりかかるようになってしまいます。上の砦の例では、砦の備蓄情報を分からないことにしても気にもとめずに突入する可能性は高いですし、砦の地図が分からないことにすると「まあとにかく入ってみないことには仕方ないよね」という結論になりがちです。

      Page Top

      制約:〈移動〉 anchor.png Edit

      〈移動〉の制約は、何らかの理由で移動手段あるいは侵入が制限されているかリスクを伴う状態です。

      シナリオの都合でパーティに特定のコースを取らせたい場合には、侵入を制限します。

      一方、パーティがどの移動手段をとるかでゲームにしたい場合は、移動にリスクが伴う状態にします。

      嵐のため渡し船が出ない。

      北回りの街道には最近危険な魔物が出没している。旅人のみならず、騎士たちまで襲われている。

      街道の途中に検問所が設けられ、行き来する旅人を厳しく調べている。

      Page Top

      制約:〈足手まとい〉 anchor.png Edit

      〈足手まとい〉の制約では、キャラクタたちが庇護しなければならない人物が同行します。

      この〈制約〉は複合的な影響を【シーン】にもたらします。キャラクタたちが危険な行動を取ることを抑制したり(=足手まといを危険にさらす事になるので)、危険を冒すことが避けられないのであれば足手まといを庇護するために何らかの対策が必要になるかもしれません。

      足手まといの足が遅かったりすぐ疲れて休憩が必要だったりすると移動に制限がつきますし、要人で人目に付くとまずいのであれば〈お忍び〉の制約と同じことになります。

      Page Top

      制約:〈敵対者〉 anchor.png Edit

      シナリオとは直接関係ない人物・勢力がキャラクタたちに敵対します。キャラクタたちは、この「敵」の目に付かないように行動したり、敵の攻撃をかわしながら《課題》を解決しなければなりません。

      「敵」の能力や権力によって、直接肉体的な攻撃を仕掛けてくることもありますし、物を売らない、街に入れない、情報を与えないといった形で妨害してくることもあります。キャラクタたちが何らかの法を犯した(と誤解された)場合は、警察権力が〈敵〉となります。

  42. challenge (2107d)
    • 2011-07-24 (日) 23:24:10 by kilica 差分

      _ 課題 anchor.png Edit

      《課題》は【シーン】の中心となる要素で、《課題》を選ぶと、そのシーンの大枠が決まります。そのため「TRPGシナリオ作成の道具箱」に慣れてくれば、シーンに含まれる《課題》を見れば、そのシーンのおおよそを掴むことができます。
      《課題》は、そのシーンでキャラクタたちが解決しなければならない問題、取り除いたり乗り越えたりしなければならない障害を表しています。《制圧》の課題であればキャラクタたちは敵勢力を倒さなければなりませんし、《踏破》であれば障害を乗り越えて目的地まで移動しなければなりません。
      また、《課題》は単にシーンの概略を決めるだけでなく、そのシーンのゲーム的なポイントも定めます。各《課題》の解説では、シーンをどのようにしてゲームに仕立て上げるか、そのポイントを説明してあります。

      通常、一つのシーンに一つの《課題》を含みますが、ときには二つ以上の《課題》を含むこともあります。

      Page Top

      《課題》を設定する anchor.png Edit

      シナリオ作成の初期段階では、まずは各シーンについて、一覧の中から《課題》をそれぞれ一つ選びます。この段階では、《課題》の具体的な内容やゲームのポイントを決める必要はありません。

      シナリオの全体像がだいたい固まってきたところで各【シーン】の詳細の作り込みに入りますが、同時に《課題》の詳細についても決めます。

      《課題》の詳細では、以下のような点を決めます。詳細は各《課題》の解説を参照してください。

      • 《課題》の達成条件
      • ゲームのポイント
      • 《課題》の具体的な内容
      • 目的と手段

      厳密には、《課題》はシーンにおける目的/達成目標を表しています。例えば、《制圧》の課題であれば敵を無力化するのが目的なので、殴っておとなしくさせてもいいし、札束を積んで黙らせてもかまいません。

      しかしながら、ゲームのポイントを作り込む段階で、シナリオ作成者は特定の解決方法を想定して課題の詳細を決めていきます。

      Page Top

      《課題》一覧 anchor.png Edit

      「TRPGシナリオ作成の道具箱」では、次の八種類の《課題》を用意しています。

      説得
      説得、脅迫、交渉などにより対象人物に協力させる課題。
  43. scene (2107d)
    • 2011-07-24 (日) 23:21:43 by kilica 差分

      _ シーン anchor.png Edit

      【シーン】はシナリオを構成する主要素です。シナリオは、一つ以上のシーンを組み合わせて作ります。その【シーン】は、一つ以上の《課題》と、任意の〈制約〉を選んで作ります。
      シーンを図示する場合は、左図のようにシーン名、課題名、制約名、シーンの概要を記述します。この図はあくまでも概要が一目でわかるようにつくる略図なので、実際には次ページのような項目を各シーンについて設定します。

      Page Top

      設定する項目 anchor.png Edit

      課題
      用意された《課題》の中から選びます。
      制約
      用意された〈制約〉の中から選びます。
      概要
      シーンの概要を記述します。
      日にち・時刻
      決まっていれば、シーン発生の季節・日にち・時刻を記述します。
      登場するNPC
      シーンに登場する可能性が高いNPCの設定とその役割(敵、情報提供者、援助者など)、セリフなどを記述します。
      シーンのポイント
      シーンにおいて、ゲーム的なポイントとなる点を記述します。ゲームのポイントとなる点は、《課題》に記載されていますので、それを元に考えます。
      シーンの詳細
      シーンの舞台となる地図、NPCのいる場所、手に入る情報、状況の描写、達成のために必要な判定、《課題》、〈制約〉の具体的な内容などを記述します。特に設定しなければならない点は、《課題》に記載されています。
  44. goodscenario (2107d)
    • 2011-07-24 (日) 23:19:06 by kilica 差分
      ページ内コンテンツ
      • 「良いシナリオ」
        • TRPGの「シナリオ」とはなにか
        • ボードゲームとTRPG
        • 「良いシナリオ」とは何か?
          • 面白いシナリオ
          • 誰でも作れるシナリオ
          • 素早く作れるシナリオ

      _ 「良いシナリオ」 anchor.png Edit

      Page Top

      TRPGの「シナリオ」とはなにか anchor.png Edit

      TRPGを遊ぶとき、「システム(ルールブック)」「シナリオ」「キャラクタ」「プレイヤ(マスタを含む)」がなど必要になります。本書ではこのうち「シナリオ」の作り方について解説していますが、そもそもシナリオってなんでしょう? どんな役割を持っているのでしょうか。
      ざっと書きだしてみますと、シナリオに期待される要素には、以下のようなものがあります。

      • ゲーム性
      • ストーリー
      • ドラマチックな展開
      • 背景世界の設定を活かした設定
      • 魅力的なキャラクタ
      • 興味をひく謎
        これらのうち、どの要素を重視するかはシナリオ作成の方法論やゲームマスターによって違いがありますが、本書では「ゲーム性」を中心に据えて、シナリオの作り方を解説していきます。
      Page Top

      ボードゲームとTRPG anchor.png Edit

      みなさんは、ボードゲームの『モノポリー』をご存知でしょうか。他のボードゲームでもいいのですが、『モノポリー』にはルールがあります。「サイコロを振ってコマを進める」「まだ誰も買っていない不動産のマスに止まったらお金を払ってそこの不動産を買うことができる」「誰かが所有している不動産のマスに止まったらお金を支払わなければならない」などなど。
      同じように、TRPGにもルールがあります。キャラクタのヒットポイントが0になったら死亡、攻撃する場合はサイコロを振って攻撃値以下の値が出たら命中、攻撃が命中したら防具の値の分だけダメージを減らせる、などなど。
      さて、モノポリーはルールだけ知っていれば遊べるかというと、そうではありません。ボードが必要です。モノポリーのボードにはいくつものマスが描かれ、そこに不動産の名前が書かれています。この不動産の並びや種類・マスの数が、モノポリーというゲームを面白くするうえで重要な要素になっています。並びや種類、数を変えると、ゲームバランスやプレイヤたちの取るべき戦術が変ります。
      そして、下手にボードを変更してしまうと、とたんにゲームはつまらなくなってしまいます。つまり、こう言うことです。
      TRPGのルールブックを買っても、ボードは付いていません。ではTRPGにとってこのボードに当たるものはないのでしょうか? そんなことはありません。
      察しのいい読者の方は気づいたかもしれませんが、ボードゲームのボードに当たるものこそが「シナリオ」です。
      TRPGのセッションでは、シナリオに従って敵が出てきたり、罠が仕掛けられていたり、情報を集めたりします。敵の種類や数を変えたり、罠を出したり出さなかったり、情報の入手方法を変えたりすることで、やっぱりTRPGも面白くなったりつまらなくなったりします。
      さて、ボードゲームを何回も繰り返し遊んでいるうちにバランス的な問題点が見えてきて「ここのマスがこうだったらもっと面白くなるのに」と思ったことはありませんか? 面白いTRPGのシナリオを作るというのは、これと同じことなのです。「序盤で雑魚敵を出してパーティの戦力を削っておくと、ちょうどバランスが良くなるんじゃないか」「うまく情報収集を成功させれば敵の弱点がわかってのちのちの戦いが楽になるようにしよう」というように「どうしたら面白いゲームになるか」を突き詰めていくのが、シナリオ作りなのです。

      Page Top

      「良いシナリオ」とは何か? anchor.png Edit

      では「良いシナリオ」とはなんでしょうか。「良いシナリオ」の条件はなんでしょうか。
      答えは、「色々ある」です。本書では扱いませんが、ストーリーやプロットを中心にしたシナリオも、キャラクタたちが縦横無尽に世界を駆け巡りヒロイックに活躍するシナリオも、「良いシナリオ」たりえます。
      しかし「TRPGシナリオ作成の道具箱」では、次の条件を満たすシナリオを「良いシナリオ」として定義します。

      • 面白いシナリオ
      • 誰でも作れるシナリオ
      • 素早く作れるシナリオ
        本書では、この三つの条件を備えたシナリオの作り方をご紹介します。
      Page Top

      面白いシナリオ anchor.png Edit

      「面白いシナリオ」というのは言うまでもないでしょう。しかし、「面白い」というのは、もう少し具体的に言うとどういう事でしょうか?
      世界最初のTRPG、ダンジョンズアンドドラゴンズ最新版(第4版)のサプリメント『ダンジョンマスターズガイド II』では、プレイヤの嗜好は「演技重視」「異世界体験」「強さ重視」「物語重視」などいくつかのタイプに分かれ、何を面白いと感じるかも変わってくることを指摘しています。
      本書では特に、TRPGのゲームとしての面白さを引き出すようなシナリオを目指します。

      Page Top

      誰でも作れるシナリオ anchor.png Edit

      第二に、「誰でも作れるシナリオ」を目指します。シナリオを作ったことのない人でも、本書のやり方ならゲームとして一定水準のシナリオを作ることができます。
      ただし、ゲームの水準の中でも、ゲームバランスについては本書では指南できません。敵の強さや解決の難易度については全く触れておりません。これはゲームシステムにもよりますし、遊ぶ仲間の嗜好にもよります(難しいくらいが好きなプレイヤも、楽にのびのび遊ぶのが好きなプレイヤも、様々に存在しています)。

      Page Top

      素早く作れるシナリオ anchor.png Edit

      第三に、「素早く作れるシナリオ」を目指します。なぜなら、本書で解説するのは、コンテスト出品用のシナリオの作り方ではなく、毎月あるいは毎週、経験が浅いかもしれないマスタが用意しなければならない、そんなシナリオの作り方だからです。

      さてところでそんな都合のいい話があるでしょうか? ずいぶんと欲張りな目標に見えるかもしれません。

      しかし、それに挑戦したのが「TRPGシナリオ作成の道具箱」です。

      では早速次のページでシナリオの作り方を……と行きたいところですが、その前に、さっきから度々出てくる「ゲーム」ってそもそもなんなんだ、という点についておさらいしておきましょう。

  45. decisionmaking (2107d)
    • 2011-07-24 (日) 23:16:23 by kilica 差分
      ページ内コンテンツ
      • ゲームとはなにか
        • 葛藤
        • 結果に対する責任
        • アカウンタビリティ

      _ ゲームとはなにか anchor.png Edit

      本書では、シナリオ制作の基礎にゲームを採用します。では「ゲーム」とはなんでしょうか。これにも多くの議論があるのですが、それを論じるのは本書の趣旨ではありませんので、ここでは天下り的に次のようなものをゲームとして定義します。
      要は、このゲームの定義に基づいてシナリオを作ったときに面白くなればそれでいいのです。

      そう。「ゲーム」とは、つまるところ参加者に対して強制的に“意志決定”を行わせるための仕掛けに他ならない。
      
      ゲームの参加者には、「管理資源」が与えられ、守るべき「制限」が明示される。そして、「障害」を克服して、「目標」を目指せ、と言われるのだ。目標にたどり着くための最適手は明白ではない(葛藤)が、一手一手の判断により形勢が変わることは明らかで(結果に対する責任)、不完全ながら「どのような手を打てば、どんな結果になりそうか」を判断できるだけの情報がある(アカウンタビリティ)。参加者は、このような条件下で、自分の手を選択/決断しなければならない。つまり“意志決定”が強いられる。
      
      これが「ゲーム」だ。
      
      もうお分かりのことと思う。「ゲームの魅力」とは何か。それは“意志決定”の魅力なのだ。
      
      外へ向かう言葉(後編)」--『馬場秀和のRPGコラム』
       http://www.scoopsrpg.com/contents/baba/baba_20000417.html

      最後の段に、はっきりとゲームの魅力の源泉が書かれています。

      そう、「意志決定」です。

      しかし「意志決定」と言われても、まだそれがなんなのか、判然としないかと思います。詳しくは引用元の記事をご覧いただくのが一番なのですが、ここではそのエッセンスを抜き出してご説明します。

      「意志決定」は、素朴な理解では「ある事柄について自分で決めること」です。しかしこの素朴な理解でゲームにおける意志決定の魅力を引き出せるかというと、全然足りません。そのためには、引用文の中にある三つのキーワードを理解している必要があります。すなわち、

      です。

      Page Top

      葛藤 anchor.png Edit

      複数の選択肢が、どれももっともらしく感じられ、どれが最適解かを判断することも、決まったアルゴリズムを適用して決めることも出来ない。このため心中に悩みや迷いが生ずる状態であること。

      何かを意志決定するときに、そこには葛藤がなければなりません。葛藤もなく決めることができるのでは、あるいはゲームマスターから選択が指定されているのでは、意志決定は成立しません。

      たとえば、「街には3軒の鍛冶屋があるけどオリバーの店が安くて品質がずば抜けていて納期も早い。他の店に比べて良いところばかりだ」という状況で買い物をするのであればこのオリバーさんのお店一択であり、たしかに「自分で決める」のではありますが、意志決定としては成立していません。

      仮に、「オリバーの店は安いけど品質はイマイチ」「ジェフの店は品質はいいけど高くて納期が長い」「アンジェリカの店はいずれもそこそこの水準」であれば、どれも一長一短の選択肢でそこに葛藤が生じますので、意志決定として成立し得ます。

      また、ゲームマスターから「突然崖の上から岩が落ちてきたので回避の判定をしてくれ」と言われてサイコロを振るのは、意志決定ではなく従ってゲームではありません。

      シナリオを作るときには、まずはプレイヤたちが選べる複数の選択肢を準備します。それぞれの選択肢には、メリットとデメリットを持たせます。メリット・デメリットには、選択することで消費するリソースの種類(金、時間など)と量、リスク(生命の危険、失敗可能性、将来の状況変化など)などを使うことができます。

      また、短期的(このシーンなど)に有利なもの、中期的(このシナリオなど)に有利なもの、またキャンペーンであれば長期的に有利なもの、などの選択肢を準備することもできるでしょう。

      Page Top

      結果に対する責任 anchor.png Edit

      選択/決断の結果が有為な差を生み、それが自分に跳ね返ってくる、逃れようなく責任を持たなければならない、という自覚があること。

      意志決定を実行に移したその結果がプレイヤにとって何がしか意味のあることでなければなりません。どうでもいいことについて悩んで(葛藤して)決断したとしても、それは「結果に対する責任」を持てていないため、意志決定としては成立しません。

      例えば、時間制限が存在しない状態でキャラクタが寄り道をするかどうかを決める場面を考えてみましょう。寄り道をすれば美味しい物が食べられ、しなければ素食となります。でも、プレイヤにとっては実はどちらでもいいことですね。

      また、銀貨5枚で、敵組織の名前の由来を教えてもらえるとしましょう。プレイヤの好奇心は満たせるかもしれませんが(「そんな由来があったのか!」)、シナリオにはなんの影響を与えません。これも、「結果に対する責任」が欠落する例です。

      シナリオを作る上では、意志決定の結果・影響がプレイヤたちに分かるようにします。「些細な決定が実はあとで大きく効いてくる」という展開は、意外性という点では面白いかもしれませんが、ゲームとしてはいまいちです。先程例に出した「敵組織の名前の由来」も、設定次第では実はシナリオを解決するための重要な情報に成り得ます。

      どちらを選ぶかはゲームマスターの好みですが、意外性を重視する場合は、ゲーム的にマイナスになることを自覚した上でシナリオを作りましょう。

      Page Top

      アカウンタビリティ anchor.png Edit

      複数の選択肢について、ある程度まで情報が与えられており、選択/決断した理由や根拠を自分なりにきちんと持っていること。

      アカウンタビリティは「説明責任」などと訳されますが、プレイヤの意志に関わる部分です。複数ある選択肢からなぜそれを選んだのか、その根拠を持っているかどうかが問われます。

      となりのプレイヤが推めたから、サイコロを振って適当に決めた、今日が6月だから、といった根拠はアカウンタビリティを満たしていません。

      「価格と品質と納期を考えたとき、今後、最も不足しそうなのは手持ちの資金なので、価格を重視した選択をした」「今は何より時間が惜しいので、多少の危険は覚悟の上で谷間の道を突っ切ることにした」などの例は、アカウンタビリティを満たしている例と言えましょう。

      アカウンタビリティはどちらかというとプレイヤ側の問題であり、シナリオでは準備できない部分が多いのですが、アカウンタビリティを満たせるだけの情報をプレイヤたちに十分与えておくことには注意します。全く情報がない状態で三つの道から選べ、というのであれば、プレイヤが当てずっぽうで、あるいはサイコロでも振って決めたとしても仕方ないことでしょう。

      一般に、情報は多めに与えます。例えば《制圧》の課題であれば、敵の指揮官、数、配置など、すべての情報を与えてしまってもいいくらいです。どうにも簡単すぎると思われたときに〈情報〉の制約をかけて一部の情報を分からないことにする、くらいのつもりで構いません。

  46. howtomake (2107d)
    • 2011-07-24 (日) 23:15:46 by kilica 差分
      ページ内コンテンツ
      • シナリオ作成の手順
        • シナリオ作成の手順
          • 1. シーンの概要を作る
          • 2. シナリオの骨格を考える
          • 3. [リソース]を選ぶ
          • 4. 【シーン】の詳細を決める
          • 5. シーンの成功と失敗
          • 6. シーンとシーンをつなぐ
          • 7. シナリオ全体を見て調整する

      _ シナリオ作成の手順 anchor.png Edit

      お待たせしました。本書の軸となる「ゲーム」に関する理解も深まったところで、いよいよこの章から、シナリオの作り方をご説明していきます。
      みなさんは、シナリオの作り方というと、どんなやり方を思い浮かべますか? 中には今までにシナリオを作ったことがない方もいるでしょうから、全く思い浮かばないかもしれません。あるいは、シナリオ全体の粗筋を考える、登場するNPCの設定から考える、感動のラストシーンから考える、といった方もいるでしょう。
      シナリオの作成について解説した本では、たいていまずやりたいお話の粗筋を考えるとか、キーワードを挙げるといった作業から入ることになっています。映画や小説、漫画のストーリーを参考にしたり、発想法を元に考えるよう薦めている本もあります。
      しかし「TRPGシナリオ作成の道具箱」では、全く異なる作り方をします。用意されているシナリオの「パーツ」を選んでシナリオを組み立て作っていくのです。

      先程、TRPGのシナリオとボードゲームのボードを対応させてみましたが、「TRPGシナリオ作成の道具箱」ではボード上のマス(真っ直ぐだったり分岐していたり合流したり)だとか、そこで起こるイベントなどのパーツにあたるものをふんだんに用意しています。その中から適当にいくつかを選ぶのが、シナリオ作成の最初の作業となります。

      用意されているものの中から選ぶだけですから、ここまでは本当に、誰にだってできることです。「いや、何を基準に選んだらいいのか」と悩む方もいるかも知れませんが、それこそサイコロを振って決めても構いません。

      この後の手順に従っていくつかチョイスをし、それをグネグネ並べ替えると、右図のようなシナリオの骨格ができます。これは骨格だけですので、このあと肉付けをする必要があり、まだ全然シナリオとしては完成していませんが、これを見ればだいたいどんなシナリオなのか、なんとなく分かりますよね。

      Page Top

      シナリオ作成の手順 anchor.png Edit

      左のフローチャートは、シナリオ作成の手順を表したものです。「TRPGシナリオ作成の道具箱」では、【シーン】と呼ばれるシナリオの構成要素の概略だけを先に作っておき、それを組み立ててシナリオの骨格にし、その後、シーンに肉付けをしていき、シナリオを完成させます。

      Page Top

      1. シーンの概要を作る anchor.png Edit

      最初はシーンの概要を作ります。以下の

      を、シーンの数だけ繰り返します。

      《課題》を選ぶ
      用意された《課題》の中からひとつを選びます。→ 第6章。選び方は、適当で構いません。あとで変更しても構わないのです。右の図では、《情報収集》を課題として選んだところです。
      〈制約〉を選ぶ
      【シーン】の難易度を上げたい場合や変化をつけたい場合は、〈制約〉をいくつか付けます。→ 第7章。選び方は適当で構いません。右の図では、〈お忍び〉を制約として選んだところです。
      Page Top

      2. シナリオの骨格を考える anchor.png Edit

      上の図は、「1. シーンの概要を作る」を3回繰り返し、シーンを3つ作ったところです。
      必要な数だけ【シーン】の概要を作ったら、その《課題》を眺めながらだいたいどんなシナリオなのか、大雑把なストーリーを想像してみます。思い浮かびましたか? 想像すると言っても、細かいところまで思い浮かべる必要はありません。《制圧》と《情報収集》という課題を選んでいたら「戦闘に役立つ情報を集めたあと敵の本拠地を叩くシナリオにしよう」とか、《踏破》と《捕獲・救出》と《情報収集》を選んでいたら、「敵の本拠地に行くまでの道に関する情報収集をした後、移動して敵の本拠地から人質を助けだすシナリオにしよう」とか、そんな感じでかまいません。
      考えたストーリーに従ってシーンを並べ、「シーンの骨格」のような図を作ります。
      以下の図は、先程作った3つのシーンに概略を考え追加したものです。

      Page Top

      3. [リソース]を選ぶ anchor.png Edit

      このシナリオで利用できる[リソース]を選びます。→ 第8章
      リソースは選ばなくてもかまいません。特にシーンの数が少ない場合は、リソースを使う機会が固定的になって考える余地が少ないため、リソースを選ぶ意義はあまりありません。

      Page Top

      4. 【シーン】の詳細を決める anchor.png Edit

      《課題》〈制約〉を選んでいくつかのシーンを作り、[リソース]を選んだら、シーンの具体的な内容を考えます。→ 第5章
      ここで初めて、具体的な物語っぽいものについて考えます。舞台(地形)、日付や時刻、登場人物のほか、どういう理由でキャラクタたちがこのシーンに関わるのか、などを考えます。
      シーンの詳細は、第6章の《課題》の解説に、何を決めなければならないか、何がポイントになるか、など、大切な示唆がありますので、これを参照しながら考えていきます。
      舞台や登場人物を設定する際は、システムの背景世界を活かすように考えてみるといいでしょう。背景世界に特有の風変わりな場所、有名どころ、歴史的な背景を持つ場所、有名人、特有の種族、政治的な絡みなどを組み込んで、セッションの場でプレイヤたちに背景世界の持つ魅力を伝えましょう。
      ひと通り内容が決まったら、システムに従って各行動の難易度、舞台となる地図、敵などNPCのデータを準備します。

      Page Top

      5. シーンの成功と失敗 anchor.png Edit

      キャラクタたちがシーンで用意された《課題》を達成したかどうかは、シナリオのその後の展開に影響します。《情報収集》の課題を達成できなければ、後のシーンの戦闘で不利になるかもしれません。《説得》の課題に失敗すれば《防衛》の課題で援軍の到着が遅れ長い期間守り通さなければならなくなるかもしれません。《突破》の課題に失敗したら、余計な戦闘のシーンをこなさなければならなくなるかもしれません。
      シナリオ作成者は、キャラクタたちがシーンの目標を達成した場合と達成できなかった場合それぞれについて、その結果と影響を設定します。
      シナリオ途中のシーンで目標を達成できなかった場合、そこでシナリオが終了してしまわないよう、キャラクタたちに挽回のチャンスを与えます。後のシーンが厳しいものになったり得られる報酬が減ったりするとしても、最後のシーンまでは辿りつけるように、途中のシーンで失敗した場合の結果と影響を考えます。

      Page Top

      6. シーンとシーンをつなぐ anchor.png Edit

      シーンの詳細が決まったら、シーンとシーンの間のつなぎを考えます。あるシーンが終わって、次のシーンに移る間に何が起こったのかを考えます。前後のシーンの組み合わせによって、自然に移れる場合も、なにか考えないとおかしい場合もあります。

      また、シナリオの導入部、シナリオの結末を含むイベントを挿入します。→第9章

      Page Top

      7. シナリオ全体を見て調整する anchor.png Edit

      最後に、シナリオ全体を通して見直してシナリオは完成です。

  47. opening (2107d)
    • 2011-07-24 (日) 23:09:37 by kilica 差分

      「ゲーム」 anchor.png Edit

      本書のキーコンセプトは「ゲーム」です。

      テーブルトークロールプレイング「ゲーム」なんだから当たり前じゃないか、と思われるかもしれませんが、意外にもそうではありません。

      シナリオの作り方に関するほとんどの方法論で最も重点的に語られているのは「ストーリー」あるいは「プロット」です。

      本書では、キーコンセプトである「ゲーム」に関わる部分でしかシナリオについて触れていません。それはゲームに関わる部分だけでも最低限のシナリオは作れるという理由と、ゲーム以外のストーリーやキャラクタやドラマについては語れるほどの能力も方法論も筆者が持ち合わせていないという二つの理由からです。

      しかし、ゲーム以外の要素をシナリオに組み込んでも悪いわけではありませんし、むしろ入っていて当然です。

      Page Top

      想定している読者 anchor.png Edit

      本書では、TRPGを何度か遊んだことがあり、TRPGやそのセッション、シナリオについて、基本的な概念を理解している人を対象としています。

      TRPGについて、リプレイを読んだだけ、あるいは聞いたことがあるだけですと、ちょっと難しい部分があるかもしれません。

      できれば、市販のシナリオをなにか一つ買っていただき、ひと通り目を通してください。本書では抜け落ちていることが、色々書かれていると思います。

      一方、すでにバリバリとシナリオを作っている方には今更な内容かもしれませんが、類書も見かけませんので「そんなやり方もあるのか」「そう整理できるのか」と、何がしか新しい発見もあるのではないかと思います。

  48. column編集/​​makeelements (2122d)
    • 2011-07-09 (土) 07:00:26 by kilica 差分

      思いついた《課題》や〈制約〉[リソース]がありましたら、どんどん自作してライブラリに加えていきましょう。また既存の要素でも、説明やポイントの追加など、改善点があれば修正してしまいましょう。

      そして出来れば、みなさんの考えたシナリオの要素を公開してください。
      本書の内容は Creative Commons というライセンスでオープンになっていますので、この表示を付けておいていただければ、私に断ることなく公開したり売ったりしても全くかまいません。

  49. restriction/​​incognito (2125d)
    • 2011-07-07 (木) 00:15:41 by kilica 差分
      • 敵国の偵察中なので、出自を知られてはならない。
      • 命を狙われている政治家の護衛中なので、政治家の正体に気づかれてはならない。
      • 無実の罪を着せられて逃走中なので、手配書の人物だと気付かれないよう国を出なければんらない。
  50. restriction/​​stealthy (2125d)
    • 2011-07-07 (木) 00:03:35 by kilica 差分

      制約の理由の例 anchor.png Edit

      • 誘拐犯の情報を掴まなければならないが、誘拐犯に知られると人質に危害が及ぶおそれがあるため、内密に事を運ばなければならない。
      • 敵の根城から脱出を試みているが、橋を渡るまでは敵に知られてはならない。万一橋を押さえられると脱出は不可能に近くなる。
      • 軍事行動を起こすため兵士たちの武具を調達しなければならないが、あと3日間はその準備を知られてはならない。
      • 財務大臣を味方に付けるため交渉に入るが、大臣に接触していることを政敵に知られてはならない。
  51. restriction/​​movement (2125d)
    • 2011-07-06 (水) 23:51:51 by kilica 差分

      シナリオの都合でパーティに特定のコースを取らせたい場合には、侵入を制限します。交通機関が動いていないとか、崖崩れや河川の氾濫など物理的に侵入できなくします。

      一方、パーティがどの移動手段をとるかでゲームにしたい場合は、移動にリスクが伴う状況に設定します。追いはぎや怪物が出現する、という直接的なリスクだけでなく、台風の接近で鉄道のダイヤが乱れるかもしれない、政情の悪化で入出国の手続きが厳しくなるかもしれない、というのもリスクです。

  52. column編集/​​dungeon (2128d)
    • 2011-07-03 (日) 18:42:43 by kilica 差分

      最近でも、『ソード・ワールド2.0』最初のシナリオ集で解説されているのはダンジョンシナリオであり、その次の巻で解説されているのがシティアドベンチャのシナリオでした。

  53. challenge/​​runthrough (2128d)
    • 2011-07-03 (日) 10:56:49 by kilica 差分

      設定事項 anchor.png Edit

      指揮系統
      指揮者の能力
      警備
      警備車の種類と数、警戒レベル、モラル
      場所
      突破対象の地図、警備者の配置
  54. restriction/​​time (2128d)
    • 2011-07-03 (日) 10:22:56 by kilica 差分

      _ 制約:時間 anchor.png Edit

      〈時間〉の制約は、簡単にクリアできる【シーン】を、一転、困難にしてしまう厳しい〈制約〉です。例えば、「3日間のキャンプに必要な物資を揃える」という課題は難しくありませんが、「1時間以内に」というと、簡単ではなくなります。ひとつのお店で揃わないかもしれませんし、たまたま品切れだったものが出てきた時の対処も考えておかなければなりません。予算が決まっていれば、なんでも買えばいいというわけでもありません。パーティで分担して段取りを決めてかからなければならないでしょう。
      〈時間〉の制約を課す場合、制限時間を示すのではなく、制限時間内に何回行動できるか、をはっきりと示すことが重要です。例えば、「制限時間は6時間です」と示すのではなく、「制限時間は6時間で、1回の行動あたり2時間かかります」(つまり3回の行動が許されている)とプレイヤたちに伝えます。

      同じく時間に制限を加える要素としては、[時間]のリソースがあります。こちらは、一つのシーンではなくシナリオ全体での制限時間を提示します。また〈時間〉の制約は、指定された時間内であれば達成が余裕でもギリギリでも関係ありませんが、[時間]のリソースの場合は途中のシーンでの達成が早ければ速いほど、後のシーンに時間的な余裕ができることになります。

      Page Top

      〈時間〉の制約の例 anchor.png Edit

  55. resource/​​npc (2129d)
    • 2011-07-02 (土) 11:18:22 by kilica 差分
  56. resource/​​time (2129d)
    • 2011-07-02 (土) 11:14:23 by kilica 差分
  57. resource/​​manpower (2129d)
    • 2011-07-02 (土) 11:07:46 by kilica 差分
  58. resource/​​money (2129d)
    • 2011-07-02 (土) 10:54:08 by kilica 差分
  59. scene/​​travel (2129d)
    • 2011-07-02 (土) 10:32:30 by kilica 差分
  60. scene/​​info (2129d)
    • 2011-07-02 (土) 10:01:56 by kilica 差分
by

Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/xpwiki.php line 38
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/xpwiki.php line 43
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1009
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1132
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1134
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1145
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1156
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1167
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1181
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1192
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1195
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1200
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 1736
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/pukiwiki_func.php line 4257
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/xoops_wrapper.php line 337
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/xoops_wrapper.php line 490
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/xpwiki_func.php line 55
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/func/xpwiki_func.php line 2811
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/convert_html.php line 92
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/convert_html.php line 587
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/convert_html.php line 941
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 43
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 61
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 64
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 70
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 76
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/config.php line 113
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 130
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 256
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 413
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 417
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 538
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 556
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 574
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 592
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 609
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 625
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 643
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/plugin/attach.inc.php line 664
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/attach.php line 690
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file /var/www/www.trpg-labo.com/xoops_trust_path/modules/xpwiki/class/attach.php line 850