年の瀬

高校の友達と麻雀を打っていた.
みんなの近況も聞けてよかったが,牌の調子もすこぶるよかった.
3半荘全部トップの合計+100オーバー.
うち1局は東1,2で満貫2回振ったのにも関わらず最終トップだったのだから詐欺くさい話だ.
チートイも3回和了って,複合役がそれぞれホンイツ,リーチウラウラ,リーチウラ4だった.
来年もこの調子であってほしい.

それでは,よいお年を.

帰省

年末年始ということで,帰省した.
もはや実家は非日常のはずだが,帰ってくるともはや昨日も一昨日もそれよりずっと前からもここにいたとしても不自然とは思えないくらい,これもまた日常として心が受け入れている.
これが12年の重みということかもしれない.

思い出す

忘れるというのは「忘」という漢字一文字で表すことができる.
だが,思い出すには,「思って」「出さ」なければならない.
この日本語の構造は,日本人の文化的深層における何かを示唆しているのではないだろうか.

何が言いたいかというと,忘年会を経てもはや今年は忘れたはずなのに,まだ3日間の業務が残っていたということだ.
今日で1日分は消化したが・・・
なんてことだ.

シナリオの作り方 シナリオのあらすじ

以前,シナリオでやりたいことを決めた.

今回は,シナリオのあらすじを決める.
シナリオのあらすじには,PC視点とGM操る敵側NPC視点の2つの側面がある.
その両方で,「なんのために」「なにをするか」を決める.
大きな枠組みで言えば,NPC視点では「自分の目的を達成するために」「悪いことをする」し,PC視点では「悪いことを阻止するために」「NPCを倒す」ということになる.
ただ,このままだとふわっとしすぎていて使い物にならないので,シナリオのやりたいことからもっと具体的に落とし込む必要がある.

せっかくなので,以前の続きで,あらすじを決めてみる.
シナリオでやりたいことは,(1)「豚肉と大根のタイタン」をボスとして出す(2)「炊いたん」と「タイタン」を絡めることであった.
まず,(2)から,「タイタン」はきっと「炊く」ことによって量産されるのだろう.
「炊いて」量産するためには,きっとたくさん豚肉と大根が必要になるはずだ.
ということで,敵側NPCは「豚肉と大根のタイタンを量産するために」「街中の豚肉と大根を買い占めている」,それで街の人が困っているということにしよう.
じゃあなんでそもそも「豚肉と大根のタイタンを量産」してるんだっけと思った人は,勘がいいかどうでもいいことにも首を突っ込んでしまうタイプだ.
そのへんを深掘りしていくと,よりあらすじは強固なものになる.
何をいつ決めてもいいし,自由に設定したりしなかったりするのがシナリオ作成の醍醐味ともいえる.
なので,深掘りはさておいておくとしよう.
一方のPCの目的は,敵側NPCのカウンターパートとして自然に決められることが多い.
今回なら,「豚肉と大根が買い占められて困っているので」「買い占めている敵側NPCを倒す」だ.

この方法でだいたいのあらすじはカバーしているはずだが,いくつか補足.

NPC視点のあらすじは,結構まわりにある小説とか映画とかを参考にできることが多い.
「邪神を召喚する儀式のために」「少女を誘拐する」とか,「親の病気の治療のために」「金を盗む」とか,適当に思いつくだけでもいろいろある.
今回の例ではたまたまボスから決まったためNPC視点のあらすじはあまり苦労しなかったが,特に思いつかなかったらまずテンプレートをあてはめてみるといい.
しっくり来なかったらまたあとで差し替えればいいのだし.

PC同士がシナリオ中で対立するいわゆるPVPのシナリオは,このメソッドだと片手落ちになる.
自分にPVPシナリオを作った経験がないので,書き残せることもない.
でも,基本的には「何をするために」「どうする」を各PCごとに設定するというメソッドの拡張でカバーできる部分が多い・・・はず.
PVPでなくても,PCごとに目的が異なる場合も同様で,PCごとに「何をするために」「どうする」を決めればいい.

なぜ,「何をするために」「どうする」を,特に「何をするために」を決めなければならないか.
それは,TRPGのいち側面として,「納得」あるいは「合意」のゲームであるという面があるからだ.
ロールプレイングはキャラクターの戦闘や判定面でのデータ的な役割と,他のPCとの会話や行動決定のようなテクスチャ的な役割の2つで成り立っている.
だから,TRPGの説明として,「ルールのあるごっこ遊び」とよく言われるのだろう.
データ的な役割を保証するのが「ルール」で,テクスチャ的な役割を担うのが「ごっこ遊び」の部分である.
「ルール」は明文化されているが,「ごっこ遊び」はふわっとした部分で,GMによって卓によって何が保証されているかは変わってくるかもしれない.
この曖昧な部分をシナリオレベルで保証するのが,NPCやPCの「目的」なのである.
納得できる目的があることで,NPCはもちろん,PCの行動をある程度保証することができる.

ちなみに,TRPGとの対比として,CRPGならば,有限の選択肢のみをプレイヤーに提示することで,つまり制約の中でテクスチャ部分は保証することができる.
また,TRPGでも,有効な選択肢を限られた数だけ示すことでテクスチャ部分を保証することができるが,それはあらすじ以降のより具体的なシナリオ作成のときの話だ.

社宅

社宅はいいぞ
クリスマスイブに特に予定がなくても,同期で集まって鍋パをできる

忘年会

会社の忘年会があった.
もう今年のことは忘れた.

シナリオの作り方 シナリオを作る前に

自分が考えていることは残しておこうということで,気が向いたときにシナリオの作り方を書いていこうと思う.

今回はシナリオの作り方と言いつつ,シナリオを作る前段階の話.
どうしてシナリオを作るか.
それは,シナリオを回したくて,やりたいことがあるからだ.
っぽくいえば,「シナリオを作る目的」.
これを明確にしておくと,その後シナリオに要素を足したり引いたりするときの基準ができる.

やりたいことは,完全に自分本位でよいと思う.
卑近な例を挙げると,「炊いたん」と「タイタン(Titan)」がシャレになっているので,「かぼちゃのタイタン」や「豚肉と大根のタイタン」をボスとして出したいなあと思っている.
くっそしょーもない例で恐縮だが,それでもこれを決めておけば(そして意識していれば),シナリオをこねくり回しているうちにボスが豚肉と大根のドラゴンになったりはしないはずだ.

釣り

同期2人と,勝浦へ釣り小旅行に行ってきた.
発起人いわく,「釣りは仕事帰りの趣味」とのことで,金曜の仕事終わりから車を借りて移動すること数時間,勝浦へ着いたのは深夜の3時であった.
釣りに関しては全くの門外漢であるが,やはり曰く深夜は釣り時らしい.
めぼしいスポットに糸を垂らすが全然釣れない.
釣れるときは入れ食いだが釣れないときはとことん釣れないようだ.
以降,17時まで釣り場の移動や小休止をはさみながらも,17時すぎまで延々釣りを楽しんでいた.
結局の釣果は小さな鰯が数匹であった.
しかし,それでも釣ったり旅行したりということは楽しかった.
今度があればアジを釣りたい.

釣果はすべて同期にあげた.

🍆

ついこの間まで学生だった身としては,ボーナスの額にも驚いたし,控除額にも驚いた.
たぶん,このボーナス額相当が控除されてしまう人もいるんだろうし,税金を目の敵にする人がいることも,それだけの税金があればこそ公的機関が回るのであろうことも,ひとつの実感として得られた.

ゲームマーケット

ゲームマーケットに行ってきた.
関西では何度か行っていたが,関東は初めてだ.
ブースをいろいろと眺めていると,ボドゲ創作界隈(?)の世相がなんとなく伝わってくる.
労働系と,人狼系が結構な人気だった.
かくいう自分も「この過労死がすごい!」と「名刺じゃんけん」を買ったので人のことは言えない.
TRPGも盛況だったようで,自分が憂慮したところでどうなるものでもないが,それでも少し安心したのであった.

クリーン

業務でもAndroidアプリを書いているが,そちらはもともとあったプロダクトにジョインしたのもあって,設計とかはままならないことも多い.
新しいことを試すような場でもないし.
そういうことをやるために,個人的な手習いでもAndroidアプリを書いている.
まあまだほんのちょっとだけど.

クリーンアーキテクチャのおかげで思考もコードもめちゃくちゃ整理されて本当に最高.
外部との操作を入力と出力で分割,さらに2段階で抽象化して,抽象レイヤーで入出力を結合する.
現状はこんな感じ.

- view
- presenter (viewからのイベント・入力を提供する)
- controller (viewへの操作・出力を提供する)
- repository (外部記憶への入出力を提供する.本当はここもpresenter/controllerにわけるとよいかもだがまだ小さいので)
- service (サーバーとかセンサーへの入出力を提供する.本当はここも以下同文)
- domain (controllerとかrepositoryとかを束ねるところ)
- input (入力を抽象化する層)
- output (出力を抽象化する層)
- interaction (入力と出力を結合する)

流れ的には,例えばユーザーからの入力をもとにほにゃほにゃして画面に出力だったら

view -> presenter -> domain/input -> domain/interaction -> domain/output -> controller -> view

とか,センサーの値を画面に出力だったら

センサー類 -> service (-> domain/input) -> domain/interaction -> domain/output -> controller -> view

とか,センサーの値を保存だったら

センサー類 -> service (-> domain/input) -> domain/interaction (-> domain/output) -> repository -> 外部記憶

みたいな感じ.
すごくわかりやすい.

serviceとかrepositoryはちょっとどれくらいの抽象度が必要かわかっていないので,domain/input,outputは保留中.
viewは必要だと思う.
view の入出力を切り分けるのがpresenterとcontrollerの役目.
切り分けた入出力を(viewではなく)ビジネスロジックとしての入出力に変換するのがdomain/input,outputの役目.

こうしてきれいにかけるとモチベーションがあがってくる.
なんとか形にしたい.

失態

まさかよりによって今日寝坊するとは.
昨晩洗濯して,飯作って,掃除して,コード書いていたとはいえ,直接的には遅くまでカプブルルを厳選していたからだ.
猛省したい.

ヒーロー

洗濯をしたらヒーロー.
買い物に行ったらヒーロー.
部屋の掃除をしたらヒーロー.
明日3,4日のために作り置きするメシを作ったらヒーロー.

日々の中にヒーローがいて,その連続が明日の俺を作っている.
プロフィール

みやどはつか

Author:みやどはつか
【座右の銘】
明日は明日の風が吹く/明日やろうはばかやろう


カウンター

最新コメント
月別アーカイブ
カテゴリ