[xcl] いつものビョーキ(笑)を改めて考える。

MGSuite をモジュール化することを考える……予防線を張りながら。

また投げ出したらゴメンナサイ

簡易版 (T)RPG コアルール生成ツールとして、改めて MGSuite を作ろうと考える。

MGSuite ってのは、もしかするとまだ覚えてる方もいるかもしれない、以前「箱庭世界Kit」とかそんな感じの名前で話したことのあるアレ*1コアルール生成が「箱庭世界」で、シナリオ生成が「箱庭物語」だった。だ。基本的にはコアルールに必要となる変数を代入し、ルールテキストを自動生成してくれる SRS みたいなモノ、と考えればイイ。*2ちなみに数式化などの発想は『RPGキャラクターブック』に由来する。

最近は同人 (T)RPG 界隈も再び賑わってきてて*3それどころかアナログゲーム界隈全体で同人/インディーズが賑わってる印象。ベリーハッピーなのだけど、発表されるタイトルのレベルが上がるにつれて、再び敷居が高くなっちゃったらご新規さんが減ってしまうのでは? とか考えたのだ。実際そこに至るまでに生産される量などを鑑みれば、そうして頭打ちになる頃というのは、そもそも新規参入の余地(ネタ)がほとんど無くなっている頃だろうから、そう心配することでもないとは思うのだけど。

そんなわけで、ウェブ上なりアプリなりの形で簡単にソレっぽいものを生成して、足がかりになりそうなモノが有ったら、あるいは息吹を残せるんじゃないか? なんてことを考えた。自分だけのコアルールが PDF で読めたりしたら、テンション上がって「よっしゃ俺も」と勢いづくお調子者もきっといるに違いない(笑)

つまりだ。

皆もっと気軽に「ぼくのかんがえたげーむしすてむ」を作ろう!(笑)

とかそんな脳内お花畑がどこまでも広がっていった結果、目的こそ違えど*4最初期の目的は「オンセ用に無料でパッと遊べる汎用ルールを生成することで、未経験者を誘いやすくする」だった。、結果としては最初期の構想に立ち戻ったわけだ。

いつも立ちはだかる技能その他の壁

けど、そこで延々「やっぱ CakePHP でやらにゃイカンかなー」ともにょってたりした。

そこでロクにプログラミングも出来んくせに「ユーザと紐付けしたいなー」とか「ウィザード形式要るよなー」とか「再編集できるようにせんとなー」、「バージョン管理したいしなー」とか、でも「ユーザ管理は XCL と連動させたいなー」とか「ウィザードの数式練り直さねーとなー」とか「まー再編集は edit でもいいとして」、「バージョン管理ってそもそもやり方わかんねー」とかグルグルしてて。

あと単純に XCL で CakePHP 使おうとしたときのフレームワーク CubeCake が、開発版のまんま止まっててしかも CakePHP のバージョン 1.2RC2 じゃんかコレ、というアレだったので、せめて 2.x にアプデするためにはどうすれば……なんてことも延々探したりしてて、これまた無駄な時間を取られまくっていた。

んでまあ最終的に「今更こんなん誰も使わんでしょ」という口実で投げ出すのだった。

↑までワンセット

ただ今回「自分なりの編纂活動の一環」って腹をくくったもんだから、「今更」とかそういうのはナシになった。使う使わないではないのだ。*5ただし現段階では他の編纂活動(読本や博物小誌等)の方が優先度は高い。なにしろそれらは実現可能であるのに対し、こちら(MGSuite)は実現可能性がまだ未知数であるからだ。

となると、ホンキで考えなければイカンなということになる。

ホンキで考えて、もう一回これまでと同じルートをたどって数日を過ごした。成長の色がまるで見られない。

ところが今さっき、ふと気がついた。これまで CakePHP に拘ってたのって*6最大の理由は前に一度、ユーザの紐付けも無ければ DB の利用もない、ペラいαテストが動くところまで作れた、という実績が有るからなのだけど、その辺を除けば、これ「ウィザード形式で」っていう部分なのだ。そこんところだけ妥協してしまえば実は xCCK で作れるんじゃね? ということだった。

xCCK で作るために必要なこと

そこで xCCK で作るために必要なことを考える。

どこまで実装するか

そもそもどのレベルで作るかを考える。ぶっちゃけると自分の脳内にある MGSuite は初心者対応のために既存のタイトルへのインストを兼ねたモノになっているので、(実際に使ってるのは実際にオーダーの有った、テンプレート作った分に限られてるんだけど)それなりの数のルールをモジュール化してる。もしコレ全部やろうとするとえらい騒ぎになる。

まあその辺が有ったからウィザード形式に拘ったんだけど、そこを取っ払って考えるなら、そこまで多様にフォークさせる必要は無い、というか最初のコアフレーム分岐のあたりは別個のモジュールとして分けちゃった方が良い気もする。

拡張性を残したい

ただ、将来的なことまで考えると拡張性は欲しい。それを毎度モジュールのテンプレートの書き換えで対応するのはいかにも苦しい。できればテンプレートテキスト自体をデータベース化し、後から増補できるようにしておきたい。これ自体を xCCK で作って、二つの xCCK が連動するようにできれば諸々の手間も減って良さそう。

入力フォームを考えなおす

また初期の入力についても考えなおす必要がある。前述のとおり、ウィザード形式は諦めた方がよいだろう。使用する能力値や技能の名称などについては、後から編集できるようにしておく必要があり、これは xCCK のモデルを考えるとウィザード形式とは相性が悪い。なので素っ気ない剥き出しのフォームが必要になる。この工程は今まで脳内補完していた部分なので、洗い出してみなければならない。

PDF 出力はやりたい

あとは PDF 出力についてだが、これはどうやら TCPDF でいけそうである。生憎と判型にB判は無いようだが、A5判にしておけばセブンイレブンのマルチコピー機で小冊子プリントも出来る*7別にA4判でも縮小コピーすりゃできるんだけど、文字がかすれるので。やはり本の形になる、というのは訴求力が段違いだと思うので(笑)

とはいえ

形になっていない構想なぞ、全て妄想にすぎない。

なので誰かさっさと形にしてくれちゃっていいですよ(笑)

References

References
1 コアルール生成が「箱庭世界」で、シナリオ生成が「箱庭物語」だった。
2 ちなみに数式化などの発想は『RPGキャラクターブック』に由来する。
3 それどころかアナログゲーム界隈全体で同人/インディーズが賑わってる印象。
4 最初期の目的は「オンセ用に無料でパッと遊べる汎用ルールを生成することで、未経験者を誘いやすくする」だった。
5 ただし現段階では他の編纂活動(読本や博物小誌等)の方が優先度は高い。なにしろそれらは実現可能であるのに対し、こちら(MGSuite)は実現可能性がまだ未知数であるからだ。
6 最大の理由は前に一度、ユーザの紐付けも無ければ DB の利用もない、ペラいαテストが動くところまで作れた、という実績が有るからなのだけど、その辺を除けば
7 別にA4判でも縮小コピーすりゃできるんだけど、文字がかすれるので