CALENDAR
Sun Mon Tue Wed Thu Fri Sat
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
本家STORY FACTサイト
NEW ENTRIES
CATEGORIES
RECENT COMMENTS
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    hikali (05/08)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    マイケル村田 (05/04)
  • GB解析 -NG- ウィザードリィ3 ダイヤモンドの騎士 橋爪さんですね・・・
    hikali (03/29)
  • GB解析 -NG- ウィザードリィ3 ダイヤモンドの騎士 橋爪さんですね・・・
    マイケル村田 (03/25)
  • GB解析 -NG- ルパン三世/暁の第三帝国 良作なエンターテイメント
    hikali (01/09)
  • GB解析 -NG- ルパン三世/暁の第三帝国 良作なエンターテイメント
    マイケル村田 (01/06)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    hikali (11/24)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    マイケル村田 (11/21)
  • GB解析 -NG- 新・鬼ヶ島 暗黒の化身を討て! 成功した理由が良く分かりました。
    hikali (06/27)
  • GB解析 -NG- 新・鬼ヶ島 暗黒の化身を討て! 成功した理由が良く分かりました。
    マイケル村田 (06/24)
RECENT TRACKBACK
ARCHIVES
MOBILE
qrcode
LINKS
PROFILE
OTHERS
無料ブログ作成サービス JUGEM
 
管理人hikaliの開発の日々の備忘録です。
本家はこちら。
http://plaza.rakuten.co.jp/hikali/
STORY-FACT. サイトリニューアル!
 こんにちは、hikaliです。  えーと、いろいろごちゃごちゃしていて、休止中のブログがメインになっていたりと現状とあっていなかった、story-fact.のサイトをリニューアルしました!

 


 小説コーナーと、hikaliのゲーム論のコーナーを新たに設けて、堂々リニューアルです! デザイン的には、賑やかになりながら、すっきりしたのではないでしょうか(笑)。元プロから見ると、小細工なんだけれども、まあ正しい手抜きだ、という感じなんですが・・・。

  これで、ようやっと、hikaliのゲーム論を進められると思っています。
  本人も、何が何だかわからなくなっていて、ん? 整理が必要だと思っていた状況なので(注:本人がどういう理論なのかが分かっていないのではなくて、この論考が読者からどう見られているのかが分からなくなっていた、という感じ)、これでだいぶすっきりし、言及している自作品にスムーズにアクセスできるようになったと思います。

  まだまだ、十分でない部分もあるのですが、今後ともよろしくお願いします。
| 開発日誌 | 17:15 | comments(0) | trackbacks(0) |
無事退院できました!

 えーと、みなさま、お元気でしたでしょうか。
 管理人のhikaliです。

 たいへんお騒がせして申し訳なかったのですが(^_^; 管理人生まれて初めての入院騒動、のべ十五日にわたる病魔との闘争が終結しましたので(<ちょ、大げさ(笑))、ご報告致します。
 端的に言いますと、

 鎖骨骨折→遠異端骨折で手術必要→プレートを入れる手術(全身麻酔)→手術中に病原菌に感染発覚
 →抗生剤投与治療(3回点滴/日)→病魔去らず、というか活性化→傷口から膿が出てきてピンチ
(ここで、主治医に脅される。病原菌が血液に入ったら、敗血症になり命に関わります!)
 →プレートを抜かないと駄目と言うことで、除去施術(全身麻酔)→その後、抗生剤投与治療
 →治ってくるが、どうも傷口がふさがらない→しばらく安静→血が出なくなってきたね
 →入院解除、以後外来で診ることに<イマココ

 という経過をたどっておりまして、大変に複雑なのですが、まあ、この辺はどうでもいいことですので、さらっとながしましょう。

 この入院期間中、とてもたくさんのゲームブック「幽霊船」への選択肢の投稿を頂きました。なにか、入院後にすべきことをどっさりと頂いた気がして、もりもりと元気が出てきます!
 ほんとうにありがとうございます。

 ■現状のグラフ構造と選択肢を頂いたところ(クリックすると拡大します)
 

 ■選択肢のある位置だけ拡大したもの
 

 けっこう、腕が鳴ると言いますか、わくわくしております(^_^;

 今後、この「幽霊船」を実験的であり、管理人hikaliのスキル上昇用の練習ゲームブックとしつつ、次期の本リリースであります、作品を仕上げていきたいと思います。

 おっと、そういえば、次作のアナウンスをしていませんでした。
 次作と言いますか、次作以降の展望なのですが、これはアナウンスしておきたいと思います。

 次作は、シャビという商業都市を舞台にした、短編作品を4作、4部作としてお届けするつもりです。
 しょっぱなとなる短編第一作は、「桃の知らせ」。
 いろいろいじっているうちに、どうも、じつは短編のくせに800枚ぐらい行きそうで、かなりがっくりというかうんざりしていたのですが、「幽霊船」やっているうちに、なんかその辺はどうでもよくなってきたというか、単純に根性が足りないだけじゃないの? という認識に変わってきたと言いますか、まあ、よい、とりあえず完成させよ!という気分になってきました(^_^;

 なんかとてもきまぐれな管理人で申し訳ないのですが、まあ、ぼちぼちエンジン掛けていきますので、遠くの軒先から生暖かく見守って頂けると嬉しいです。

 というわけで、気合い入れていきましょう!







| 開発日誌 | 21:14 | comments(2) | trackbacks(0) |
 ミニゲームブック『幽霊船』の告知です!

 えーと、大変ご無沙汰しております、管理人のhikaliです。
 個人的にどたばたした五月が過ぎ去りました・・・。

 表題にもありますとおり、ひさしぶりにリリースの告知です。
 ミニゲームブックと表しまして、これまでのFLASHゲームブックとは違ったグレードで、実験的なゲームブックをリリースしたいと思っています。
 五月末のリリースを予定していたのですが、一週程度ずれ込みそうな感じです。
 お楽しみにして頂ければ幸いです。


 ■以前ちょろっと出したバナー…。


 ■ラボ相当のリリース

 『幽霊船』は正規のリリースとしてではなく、STORY-FACT Labs相当のゲームブックとして登場します。そのために、かなり実験的な試みを幾つかします。とてもわたしの興味の方向が出ていて、そんなの上手く行くのか? とわたし自身も思ってしまうのですが、マッドサイエンティスト気質のわたしが主催するSTORY-FACTらしいと言えばらしい、そっち方面に充分マッドならばかなり刺激的な内容ではないかと思い、個人的にはわくわくしています。
 正規のFLASHゲームブックを楽しみたいと思われる方にはたいへん申し訳ない!
 こういう、実験の積み重ねが、よりよい正規版に繋がるのです!
 と、言い訳をしておきまして(^_^; その魅惑的にマッドな『幽霊船』の話をしましょう。


 ■『幽霊船』はもとからTRPG用のシナリオだった

 このゲームブックの元になっているのは、TRPGで何度かしたことのあるシナリオです。TRPGのシナリオというとピンとこないかも知れないですが、ひとことでいえば、わたしの周りにいたプレイヤーたちに挑ませるために作ったシナリオです。
 とても個性的で、ユニークな考えをするプレイヤーたちを相手に回してのセッションを前提にしていましたので、プレイヤーがどのような行動をとろうとも絶対に破綻しない(ただしプレイヤーの破滅は有り得る)構造になっています。圧倒的に自由度が高く、どんな行動でも許容しうるという部分がウリなのです。


 ■しかし、誰一人としてこの難題を解くことができなかった

 ただ、その置かれた状況があまりにも過酷すぎるために、挑んだプレイヤーに敗北の山を築かせることになりました。いまだにこのシナリオを解けた人はなく、どちらかというとあまりに過酷すぎる状況に絶望してしまい、さじを投げてしまうと言うか、プレイが荒くなってしまうのです。
 ハリウッド映画ってこんぐらい過酷だけどなあと思いつつ、その解けたときの、苦難の先にあるカタルシスを演出するには、このレベルでなくてはなあとため息をついたものなのです。


 ■ゲームブックの世界はこんぐらいの難度だった!

 しかし、ゲームブックの世界に視線を転じてみると、この『幽霊船』ぐらいの難度は序の口。ばしばしゲームオーバーになりますし、ほんとうにクリア可能なのか? と思うような作品も多々あります。というわけで、じつはこの『幽霊船』はゲームブックにむいているのではと思うようになりました。
 そこで、ちょっと『幽霊船』を投じてみたくなったのです(笑)


 ■TRPGの仕組みをゲームブックに取り入れるために

 TRPGは基本的に、プレイヤーの行動に制限はあまりありません。少なくともマスターがシナリオの致命的な部分を突かれたために、あー、それはなし、それは待った、という
ことがありません。マスターとは、プレイヤーの自由を優先しなければなりませんし、どのようなプレイヤーの行動でも受け入れなければなりません。
 ゲームブックというと、どうしても用意された選択肢を選ぶだけの意志決定という部分があり、それは構造上否定することができません。紙の本であればしかたありません。だけど、Webベースだったら?
 ユーザが選択肢を新たに書き込むことができるのでは?
 それに、書き手がその結果を書き連ねて、次々と新しいページができていくことができるのでは?


 ■そんな妄想で、新しいリリースは作られています。

 いろいろ書きたいことがありますが、このプロジェクトはあんまり固定したくないので、この辺で。ラボはラボらしく、自由闊達で。流動的で、約束しない方向で(笑)。もっとマッドな提案があれば嬉しいです。

JUGEMテーマ:ゲーム


| 開発日誌 | 22:58 | comments(0) | trackbacks(0) |
「幽霊船」のバナー作った。
凄まじく、告知なしでいきなりなにやってんのってかんじだけど、まあもうちっとしたら、80項目ぐらいのかなり実験的なものが出てくるので、



このシナリオはいいシナリオなので、大切に行きたい。




| 開発日誌 | 01:06 | comments(2) | trackbacks(0) | 昨年の記事
ゲームブック技術のスタックのつぶやき。

 えーと、絶賛放置中になっております…(^_^;
 管理人のhikaliです。

 これは書いていいのだろうかと思いつつも、現在新作ゲームブックを開発中です。
 そうなると、極端に無口になるのはよくない! と思いつつ、どうも無口になります。

 そこで、Twitterでぶつぶつつぶやいているモノの中で、多少は関係ありそうなモノは、こっちにも転載してしまおうと思うようになりました。Twitterで書いているモノはほとんど思いつきだし、あんまり親切に説明もしていないのですが(^_^; このブログを更新しなくなるよりはいいだろうと、そんな感覚です。

 Twitterのログですので、途中で茶々が入って、それで思考の流れが変わってしまって、なんか物凄い飛躍をしているところもあります。そういうのは、Twitterログなので、しゃーないと思っていただけると嬉しいです。なんか意味不明なところがありましたら、お気軽に聞いていただけると嬉しいです。

GDCも結構変わった・・・。大資本主義から、少数精鋭タイプが中心になってきたというか・・・。■天才クリエーター、ウィル・ライト氏がゲームデザインの“いま”を語る http://www.famitsu.com/game/news/1233393_1124.html


もともとゲームブックの研究もソーシャル的な方向に発展できないかと思いながら、研究していたのだけど、それ以前にゲームブックの技術自体の吸収だけでも結構たいへんで、そんなところまでは、まだまだ道遠きであるのだよなあ・・・。


技術的に難しい事をしたい! → やってみる → できない! → 基礎的なレベルがぜんぜん足りないことに気付く → 基礎的な所を勉強する → ある程度吸収できた → 高いところをやってみる → できない! → 足りない部分が見えてくる みたいな感じで・・・。


アイデアはいくらでも夢想することができるのだけど、結局の所たいせつなのは、実装できるか、実装に掛かる工数はどの程度か、完成させられるか、であって、実装力を手当てしていないアイデアは単なる妄想でしかない、ということに気付かされる。そのたびに、あー、実装力を磨かねばと思う。


で、実装をし始めてみると、実はアイデアの核だと思われていたものが、全く通用しない面白くも何ともないものであると言うことに気付いて、そのすぐ側に金鉱が眠っていたり、単なる徒労に終わったりする。


アイデアの事を発明の世界では、発明の根本思想(もしくは技術的思想)というのだけど、そもそも正しい根本思想にたどり着くことが≒発明をするなので、発明の過程というのは、正しいアイデアを探す、ということになるのであって、そのアイデアは実装してみないと正しいか分からない物だったりする。


結局の所、実装なき発明はほとんどあり得ないし、実装なき思辨は、そもそも発明の世界には馴染まないものだし、そういうところは、つべこべいわずに動くコードを書け、ぺらぺらしゃべるなという思想は、発明の世界の思考方法を、物凄くストイックに突き詰めた物だと思う。


で、そういう思想に染まると、極端な実装主義になり、とりあえずできてから解説するか、まずは実装するか、で、実装力のなさにたどり着いて、うわー、勉強しなきゃとなり、ますます無口になる、というスパイラルを辿るのだなあ・・・、たぶん・・・。


これまで元気に話していた人がgoogleに入ったとたんしゃべらなくなると言うのは、この実装至上主義の社風にさらされて、自分の実装力のなさに気付かされて、たんたんと実装力を磨くフェイズに入ってしまうからではないかと思ってしまう。


これはたとえばディーゼルエンジンの発明がしたいとすると、これまでのディーゼルエンジンの技術的思想を学ばなければならず、ディーゼルエンジンの最先端にたどり着くまでにとても大量の時間が掛かる、というのと同じかも知れない。そこまで行かないと、正しい技術的思想の勘所が分からない。


これはたとえばディーゼルエンジンの発明がしたいとすると、これまでのディーゼルエンジンの技術的思想を学ばなければならず、ディーゼルエンジンの最先端にたどり着くまでにとても大量の時間が掛かる、というのと同じかも知れない。そこまで行かないと、正しい技術的思想の勘所が分からない。


iPadはジョブスによれば、ネットブックキラーとなる物だけど、あれは明らかにネットブックとは違うもの、でも、利用ケースは同じであると考えられる。それ、これでもできるしこっちの方が安いし便利だよ、とiPod→iPhone→iPadと築き上げたスタックに競争を移動させようとしている。


技術のスタックは、競合となる奪うべき市場が誕生する事を想定せずに、自律的に発展するのではないか、と思う。iPadは明らかにiPodが築いた技術スタック上にある(iTunes的な物を前提にした機器という意味)のだけど、そのスタックが生まれる上でiPadを想定していなかった気がする。


iPodの音楽データをPCで管理するという根本思想が生まれ、そこにオンラインショップを繋げるという根本思想が生まれる。で、何らかの方法でネット上のコンテンツ群にアクセすることを前提とする機器って、スマートフォンでもいけるんじゃない? から、iPhoneが生まれる。


で、iPhoneのソフトの売り上げにゲームが占め始めると、というかiPhoneってゲーム機じゃん、とPSPと競合する戦略を採り始める。<これすごいふしぎな転換だ・・・。なにもしていないのに、ゲーム機として発見されてしまうという経緯を辿っているのか・・・。


ん・・・。何が言いたかったのだろうか・・・。ああ、そうか。ゲームブックを研究して、ゲームブックの根本思想を延ばしていくと言う行為は、もう枯れきってしまった技術は、まず再生することができるだろうという読みがまずあって、それを発展させていくと、面白いスタックになると。


で、その過程で、インターネット上にある事を利用した新しい根本思想が生まれるかも知れないし、何らかの方法で発展するだろうとは思うけど、いまはせこせこiPodの設計をしているようなもので、iTunes的な展開は思いついていないし、まずは快適なデジタルプレイヤーを作ると。


だけど、まだ、快適なゲームブックという時点も達成していないので、まずはそこに注力して、これまでにあった技術を吸収して、実装力をつけるところにもっていかないといけないと。


おお、GDCの所からの説明が思いっきり長かった・・・。つまりゲームブックスタックって、どっかでどこかに殴り込めるんじゃないの? という気はしているのだけど、そんな夢想しているよりも、とりあえず実装力をつけないと話にならんという話を延々としていた訳か・・・。


 以上。
 ん・・・。10枚近く書いてたのか・・・。
 ちょっとびっくりしました・・・。

JUGEMテーマ:ゲーム


| 開発日誌 | 21:29 | comments(0) | trackbacks(0) |
単語ジェネレータのコードを公開します。
 えーと、みなさまお元気でしょうか、管理人のhikaliです。
 本日は、単語ジェネレータのActionScriptのコードを公開したいと思います。

 実のところ先日、コードを公開して下さいとの依頼を頂きまして、わかりにくいコードなのですが、まあ、こんなのでもお役にたつのであればと思い、公開します。


 ■単語ジェネレータについてはこちら
 ・わたし以外にはほんとにどうでもいいアプリケーションを思いついた…。
 http://blog.story-fact.com/?eid=1025733

 ・gogle app engine版の単語ジェネレータ
 http://story-fact.appspot.com/randstr/

 ・単語ジェネレータのFLASH版できたよ〜!
 http://blog.story-fact.com/?eid=1077361


 ↓猛威をふるっているようす。
 ・起承転結問題集 -初級編- 見せてもらおうか、単語ジェネレータの実力とやらを!
 http://blog.story-fact.com/?eid=1029836




 まずアプリケーションの構成から。

 1.構成
  ・randstr.swf これが本体
  ・randstr.txt これが単語リストです。カンマ区切りになっています。

 2.アプリケーション内での動作
  立ち上げると同時に、ローダーがrandstr.txtを読み込む。
  読み込みが完了したら、split(",")でカンマを区切り文字にして配列に格納。
    → この状態で、全単語が配列として、メモリー内に保持されている。
  単語の発生。strNum.text(単語数の入っているテキストフィールド)を読み、
    その回数分、単語を連結して、最終結果を、randstr_txt.text(単語が表示
    されている部分)に表示。
  以後、ボタンを押されるたびに、鵝砲鮗孫圓垢襦

  こんな手順になっています。
  ちょっと癖があって、わかりにくいのは、一番始めにすべての単語を配列に格納
 してしまって、それをメモリー上に保持しているという部分でしょうか。ミリーの天
 気予報を始めとする、FLASHゲームブックのシステムも、これと同様に一番始めの
 時点で、全テキストをメモリー上に読み込んでしまって、それを疑似データベースの
 ように使用する仕様になっています。

  ミリーの天気予報はぶっちゃけテキストファイル自体で、800KB以上あるのですが、
 これをずっと常にメモリー上に持ち続ける仕様になっているのですね(^_^; この辺
 全く省力しないぶんまわすような豪快な仕様ですので、ちょっとわかりにくいかもと
 思いました。


 3.実際のコード


//配列を準備
var strArray:Array = ["",""];
var arrayLength:Number = 0;

//ローダーを設定。randstr.txtを読み込む。
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE,completeHandler);
loader.load(new URLRequest("randstr.txt"));

//読み込みが完了したら、カンマ区切りで配列に格納。
function completeHandler(event:Event):void {
var vars:String = event.target.data;
strArray = vars.split(",");
arrayLength = strArray.length;
makeStr();
}

//ボタンを押したときに、makeStr()を実行する。
bt_make.addEventListener(MouseEvent.CLICK,btCL);
function btCL(event:MouseEvent):void{
makeStr();
}

//ここで単語を発生させている。
function makeStr():void {
var randomI:Number = 0;
var strText:String = "";
for(var i:int=0;i < int(strNum.text);i++){
randomI = Math.floor(Math.random() * arrayLength);
strText += strArray[randomI] + "  ";
}
randstr_txt.text = strText;
}



 4.謝辞

 えーと、おかげさまをもちまして、拙作ミリーの天気予報では、たくさんの嬉しいご感想を頂いております。実際アンケート形式で頂いているものですので、表に出すことが出来ない、そしてそれに対してお返事する方法がないのがとても残念なのですが、管理人はとても嬉しく読ませていただいております。

 お礼をいう場がなかなかないので、この場を借りまして、感謝いたします。
 本当に嬉しいです!
 もうみなさんの励ましだけが原動力です(^_^;


 ■関連エントリー
 ・ 膠着状態(デッドロック)解消型ゲーム
 http://blog.story-fact.com/?eid=1177436

 ・ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[前編]
 http://blog.story-fact.com/?eid=1179473

 ・ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[後編]
 http://blog.story-fact.com/?eid=1180167

 ・ 【ミリーの天気予報】セーブ機能搭載版投入しました!&作品の概要
 http://blog.story-fact.com/?eid=1177436






| 開発日誌 | 17:25 | comments(2) | trackbacks(0) | 昨年の記事
ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[後編]

 こんばんわ!
 管理人のhikaliです。

 前回お送りした[前編]に引き続き、本日は[後編]をお送りしたいと思います。
 なんのことか分からない、もしくは、なにかいてあっただっけ? という方はもう一度[前編]をお読みになることをオススメします。なんといっても、本日はブリーフィングモードではなく、容赦のない本番モードですので、手加減というものがありません(<そうでないととてもではないけれど説明しきれない)。
 そのあたりは、諒解の上お読み頂ければ幸いです。

 ■前編はこちら
 ・ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[前編]
 http://blog.story-fact.com/?eid=1179473



 ■「サイボーグを倒せ」のクラスター≒モジュール構造

 さて、前編においてわたしは「サイボーグを倒せ」は画期的な構造を取っていると書きました。それはいったいどういう構造なのでしょうか? これがなかなかに作り手からしてみると、かなりフリーダムな構造なのです。

 「サイボーグを倒せ」は、いわゆるアメリカンヒーローものに分類される物語です。
 超能力を使えるスーパーヒーローになって、悪の秘密結社と戦うといえば大変分かりやすいと思いますが、最終的にはこの悪の秘密結社の秘密会議の場面を暴き、その陰謀を止めよという内容になっています。
 しかし、この「サイボーグに倒せ」、明確な図太いストーリーがズドンとあるという構造を取っているのではなく、30〜40の小さな事件の連なりによって構成されています。詳しくは詳細解析の方が詳しいですので、こちらをご覧ください。

 ・詳細GB解析 サイボーグを倒せ [前編] スティーブ・ジャクソン・マジックを完全解析
 http://blog.story-fact.com/?eid=1143535


 これを読むと分かるのですが、ちょっと引用してみましょう。
 【6】などと【】で表記されているのはクラスターを意味しています。
 つまり【6】はクラスター6、【G】はクラスターGを意味します。


 【6】

 この飛行場では、ハイジャックが起こっている。
 あらゆる方法で、ハイジャック犯を説得できるのだけど、中には乗客死亡という選択肢もある。あとゲームオーバーもある。
 うまくやると、会議についての情報が入る。
 そして全部10へいく。
 10で事件が分岐する。



 【7】

 ここはスターカーズ・ビーチでのサメ事件。
 うーん、ここは純粋に戦闘シーンですね。
 11項目も使っている・・・。
 ただ使い方はなんとなく分かった。



 【E】

 ウィズニーランドでの出来事。
 ここはびっくりハウスがメインなので、他のアトラクションはあっさりとこの遊園地を出ることになる。以下びっくりハウスの顛末。

 ここではふざけ魔と戦って勝つと、会議の情報が手に入る。
 二通りふざけ魔を見つける方法があるのだけど、結局情報に従って発見しないと情報が手に入らないよう。


 このように小さな(?)事件をつぎつぎと解決していくうちに次第に、いろいろな情報を手に入れていくのですが、ふと気付かないでしょうか?
 これってどうやって整合性を取っているの? と。

 実のところ、この「サイボーグを倒せ」の各クラスターは、

 1.どこから来ても整合がつくように、
 2.どこへ分岐しても整合がつくように、

 作られているのです。
 なんといいますか30ぐらいのあんまり因果関係のない事件が連なっているのです。
 たとえば、引用しますが、

【A】

 ここは煙男との対決。
 しかしどうやっても煙男が宇宙科学者の家から重要な情報を電送するのを防げず。
 煙男がつかまる項目もあるので、どうするんだろう。
 つかまえても逃げ出したことにするのか、もう出さないつもりなのか。


 この答えは、もう出さないから関係ない、です。
 つまり、ちなみに大統領の暗殺のシーンもあります。
 引用してみましょう。

 【K】

 ここは、敵であるサイボーグと出会うシーンがある。

 また、大統領暗殺事件がある。もし大統領が暗殺されても関係なく物語が進んでいくのがすごいのですが、この辺の組み方はかなり参考になる。
 この組み方をすると、かなり自由にクラスター組みができるんですよね。
 分散型の設計で、これをモノにするためにこれをわざわざ解析しているのですが、物語解析と親和性がとても高い、かなり柔軟な構成を再現できる。因果に一切問われない、物語解析が持っているストーリーの放棄、という最大のテーゼを実現できるすごい構成なのです。



 と、ここでは若干興奮気味に書いていますが、要はこの「サイボーグを倒せ」では、因果関係をクラスター内のみにとどめ、その入口と出口を規格化しているのです。
 自作PCを思い起こして頂ければ、分かりやすいでしょうか。
 たとえばグラフィックボードであれば、その入口と出口の規格を定めているおかげで、windowsPCであれば、自由にグラフィックボードをユーザが選ぶことができます。
 このPCで起こっていることをモジュール化といいますが、このサイボーグを倒せでは、クラスターのモジュール化がされていて、ぶっちゃけ、どのようなルートを通ってきても問題がないように作られているのです。

 では、どのようにクラスターをモジュール化しているのでしょうか?
 これは、わたしが完全に把握しており、「サイボーグを倒せ」を参考にモジュール化した「ミリーの天気予報」のクラスターのひとつを完全にさらして、説明しましょう。


 ■ミリーの天気予報中盤クラスター2の構成

 ミリーの天気予報の中盤は、ヒロインであるミリーに元気になって貰おうと、その希薄な感情に生気を与えるシーンです。元気になったミリーが大暴れするのですが、その過程で主人公のイコウたちは、自然とミリー周辺の人間関係を知っていくことになります。

 中盤の前半はミリーに喜怒哀楽を与え、館の中を暴れ回らせます。後半は一転してサディスという港町までその混乱を広げるのですが、このクラスター2は中盤前半のしょっぱな、ミリーに喜の感情を与えるシーンです。

 このシーンは海鳥のテラスへ飛び出してはしゃぐミリーをよそに、ディシュというミリーの肖像画を描いている画家とイコウが話すシーンです。グラフを見てみましょう。



 36〜43までの、7つの項目でこのクラスターが構成されていることが分かります。
 40〜43までの選択肢の番号を見てください。
 見ると、51と52へ分岐していることが分かります。

 少なくともこのクラスターは、36から入って、結果の如何を問わずに、51か52へ出て行くクラスターになっています。このクラスター内で起こったことは、実際には出口には影響がまったくないのです。分かるでしょうか?
 ちなみに、51は「怒らせてみる」、52は「哀しませてみる」です。
 このクラスターの内容とは一切関係がなさそうです。
 では、このクラスター内で起こったことは、まったく意味がないのでしょうか?
 いえ、とんでもない(笑)。
 このクラスターは、とてつもなく重要で、それでここに出てきているのです。
 このクラスターでは、イコウはディシュと雑談をしながら、この物語の根幹に迫る情報を聞き出すことになります。つまり、ディシュがなぜ絵を描いているのかが分かる重要なヒントが出てくるのです。
 しかも2箇所も。(そしてこの2つはどちらかしか回収できない)

 グラフを模式化した物を見てみましょう。



 このように会話が分岐しています。
 しかし、40〜43が合流しているのはなぜでしょうか?

 (40)

 イコウは、そのディシュの戸惑うような表情を意外そうにみるが、シャリーの声でそれも中断させられてしまう。
「やめて、ミリーちゃん! やめて、お願い、ミリーちゃん」
 振り返ると、ミリーが手すりの上に立ち、両腕を広げて走っている。
「大丈夫、シャリー! わたし、チャムに飛び方教わったから!」
 イコウが高飛びの石を握るのと、ディシュの顔が青ざめたのは同時だった。


 この40〜43は、ディシュとイコウの会話が、ミリーが鳥のように飛べると思ってテラスから飛び降りることによって中断させられてしまうのです。
 他も見てみましょう。

 (41)

「あ、あの」
 イコウの言葉は、シャリーの声で中断させられてしまう。

 (42)

「ご名答。これは秘密ですよ」
 ディシュはにこっと笑うが、シャリーの声で中断させられてしまう。

 (43)

 ディシュの言葉は、シャリーの声で中断させられてしまう。


 同じようにざっくりと中断させられてしまいます。
 この後はまったく同じ文章が続きます。
 つまり、選択肢を受けてのその結果+4項目共通のこのクラスターの顛末によって、この40〜43は構成されています。

 ミリーの身体はそのまま一階の土の上に叩き付けられ、はねるところをイコウが抱き留める。シャリーが悲鳴を上げながら、階下へ駆け下りてくる。ディシュは、目の前で起こったことにぼうぜんとした。
 シャリーがミリーの元にたどり着いても、ミリーはまだ嬉々としていた。
「シャリー、飛んだでしょ、わたし」
「ミリーちゃん、血、血、血が出てるのよ、こんなに」
「あはは、ほんとだ、血が出てる。こんなのはじめて!」
 さすがにイコウも気持ち悪くなってくる。
 シャリーがイコウをすがるように見ている。
 イコウは手早く処置を施し、言う。

 このイベントで問答無用にこの喜のクラスターは終了となります。
 ここでミリーに怒の感情か、哀の感情を与えることになりますが、そうするとまたミリーはその感情に乗せて、新たに暴れはじめますので、このクラスターとの因果が完全に切れてしまいます。

 分かるでしょうか?
 これがクラスターのモジュール化なのです。

 ここで得た情報は、まったく関係なくなるかというとそうではありません。
 ここで情報得たことによりフラグが立ち、中盤のあとにはじまる推理フェイズで大いに活用されることになります。

 同じように、この館の主人であるディアマンテと家令のジョゼフのところへ怒鳴り込むクラスター、老いた商人に若かりし頃のディアマンテの話を聞くクラスター、兄がいないことを哀しむクラスターといくつもクラスターが、まったく因果関係を持たずに存在しています。

 実のところ「サイボーグを倒せ」も同じような構成をしています。
 (というかミリーの天気予報がサイボーグを倒せをまねているのですが)

 また、大統領暗殺事件がある。もし大統領が暗殺されても関係なく物語が進んでいくのがすごいのですが、この辺の組み方はかなり参考になる。
 この組み方をすると、かなり自由にクラスター組みができるんですよね。


 とこの辺で言っているように、実のところ大統領の暗殺が成功したか失敗したかさえ、この物語の因果とは関係なく、ヒーローと秘密結社の戦いが進むのです。この徹底したクラスターのモジュール化をすることにより、作り手はどのような事件でも因果に関係なくつなぎ合わせることができるのです。
 ミリーの天気予報を実際に触ってみると、この構成法はどのような形で応用することができるかが如実に分かるかと思います。
 実のところ、館モノと呼ばれるシナリオは、舞台ドリブンの構成から、イベントドリブンの構成へ書き換えてしまうことができるのです。ちょっと分かる人であれば、この効果の絶大さは震撼できるのではないでしょうか。


 ■「サイボーグを倒せ」に見る、クラスター構造

 さて、クラスターのモジュール化により、なにやらいろいろなことができるような気がしてきたでしょうか(^_^;
 ミリーの天気予報はサイボーグを倒せの劣化コピーで、クラスター内の項目数が多くて7ぐらい、少ないところは1つのところもあるぐらいなのですが、しっかり作り込めば、30クラスター×20項目=全600項目などという超本格型ゲームブックも問題なく作り込める(つまり容易にスケールする)、柔軟性の高い製作法なのです。
 しかし、そんなに大きくしたら、矛盾とかしないの? と疑問に思わないでしょうか。
 そーですね……、たしかに30クラスターとかあると混乱しそうです。
 しかし、大丈夫。
 この辺りが、スティーブ・ジャクソンの真骨頂。
 実は、この無秩序にすることもできるモジュール化クラスターを、どうつなぎ合わせるかという技術も、この「サイボーグを倒せ」では実現しています。

 まずはこれをご覧ください。
 「サイボーグを倒せ」のクラスター間の関係を示したものです。
 恐ろしく複雑です。

 ■サイボーグを倒せ − クラスター関係図(全貌)
 (クリックすると実寸表示になります)



 さすがとうなっていても仕方のですが(^_^; 実はこの関係線、5つほどのイレギュラーな線を取り除くとこうなります。


 ■サイボーグを倒せ − クラスター関係図(イレギュラー抜き)
 (クリックすると実寸表示になります)



 こうすると鮮明ですね。
 第一列、第二列、第三列と物語の進展に従って、次の列のどれかへ行くという構造を取っているのです。これだけではシンプルすぎるので、イレギュラー的に、同じ列内で移動する線を作ったり、前の列に戻る線を作っているのです。

 つまり、まず、矛盾しようがないハニカム状の構造を作ってしまい、そこにイレギュラー的な移動の仕方を付け加えているのです。これであれば、矛盾なく複雑な物語内のエコシステムを構築することができます。
 なるほどと、わたしが感心したのはこの作り方で、いろいろ弄りながら、

「およ? これハニカム状になってね? 複雑に見えるけど結構単純かも」

 と発見したのですが、これは大変論理的で、作業効率のよい作成方法です。
 スティーブ・ジャクソンの作成方法を見ていると、このようなパターンが見えてきます。

 1.正攻法ルートの整備 → この正攻法ルートはけっこう難関ルート
 2.イレギュラーの整備 → ここをとにかく多彩にする

 と、ずぶとい正攻法ルートを整備し、そこに網の目のようにイレギュラーを張り巡らせていく。もし、スティーブ・ジャクソン作品に何らかの秘密があるのだとすれば、これがそのひとつとなのではないでしょうか。
 まあ、その辺はよい。


 ■ミリーの天気予報の中盤の構成

 さて、ミリーの天気予報の中盤ですが、こちらも劣化版で申し訳ないのですが、同じような構成をしています。

 
 ■ミリーの天気予報中盤 − クラスター関係図(全貌)
 (クリックすると実寸表示になりますが、完全にネタバレになるので取扱注意です!




 分かったでしょうか。

 以上で、駆け足でしたが、ミリーの天気予報の構造を解説してみました。
 本当のところは解決編も解説したかったのですが、これをはじめてしまうとかなりのネタバレになってしまいますので、ちょっと断念します……。
 スミマセン……。

 というわけで、大変にボリュームのあるFLASHゲームブックになってしまった、ミリーの天気予報ですが、かわいがって頂ければ幸いです。


 追記:

 おわった……。
 やっと、ミリー関連が全部終わった……。
 つかれた……。

 ■関連エントリー
 ・ 膠着状態(デッドロック)解消型ゲーム
 http://blog.story-fact.com/?eid=1177436

 ・ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[前編]
 http://blog.story-fact.com/?eid=1179473

 ・ 【ミリーの天気予報】セーブ機能搭載版投入しました!&作品の概要
 http://blog.story-fact.com/?eid=1177436








| 開発日誌 | 22:27 | comments(0) | trackbacks(0) |
ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[前編]
 こんばんわ!
 管理人のhikaliです!

 えーと、以前より本ブログではスティーブ・ジャクソン謹製「サイボーグを倒せ」の詳細ゲームブック解析の後編を行うと約束してきました。ただし、「ミリーの天気予報」がその技術を使って制作されたFLASHゲームブックになるので、実機が完成するまで、それを待って欲しいと。
 というわけで、ようやっとそれができる状況になってきました。
 ただ、内容的には「ミリーの天気予報」の内部構造の話がほとんどになるかと思いますので、扱い的にはそちらを優先させて頂きます。

 また、大変長いものになるかと思いますので、都合[前編][後編]の二回に分けさせていただきます。


 ■スティーブ・ジャクソン謹製「サイボーグを倒せ」とはなにか

 えーと、ミリーの天気予報の解説ですので、まずは、この「サイボーグを倒せ」というゲームブックとはなにかということから説明します。

 ・詳細GB解析 サイボーグを倒せ [前編] スティーブ・ジャクソン・マジックを完全解析
 http://blog.story-fact.com/?eid=1143535


 こちらのエントリーでもふれているのですが、分かりやすく説明し、それがなぜ技術的に大切なのかを説明したいと思います。

 スティーブ・ジャクソンは、ソーサリーや火吹き山の魔法使いで著名なゲームブック界の第一人者です。これまでこのブログではかなりの数のゲームブックを解析してきましたが、それを通じても、やはりスティーブ・ジャクソンの作品の質は高いと断言してよいと思います。

 スティーブ・ジャクソンの作品ではソーサリー四部作が著名ですが、その執筆直後に書かれたと思われるのがこの「サイボーグを倒せ」です。ここで、スティーブ・ジャクソンは新機軸と言えるさまざまな試みがされています。

 STORY-FACT.は、

 ・hikaliの持っている、デッドロック解消型ゲームの技術
  → これは主に物語解析あたりで解説している技術

 を、

 ・ゲームブック形式の中に積み上げられた、分岐型ストーリーゲームの実装技術
  → これは主にGB解析でせっせと解析している技術

 を使って実装しよう! そうしよう!
 というのが主眼のサイトです。
 つまり、この両者を融合しようというのが目的のサイトなのです。

 で、これからお話しするのは、実装技術の方でして、この「サイボーグを倒せ」でスティーブ・ジャクソンが見せている実装技術はすばらしいの一言なのです。しかし、この画期的な実装技術を踏襲しているゲームブックは皆無と行ってよく、いわば幻と消えた、オアシスの古代都市、悠久の敦煌といったところでしょうか。
 それが、我らが発掘隊の不休不眠の探索行の結果、砂漠の中から忽然と現れた、その大伽藍!
 すごいぞ!ラピュタは本当にあったんだ!
 という、感じであるのです(<大げさすぎ…)。


 ■ゲームブック関係でhikaliが勝手に使っている言葉の説明

 ゲームブックがらみの話はこれが実装技術であるため、若干の専門用語が出てきます。
 しかも、hikaliがゲームブックが華やかだった頃とは隔絶された時代から掘り起こしていますので、もはや自分で言葉を作らなければならない状況になっています。
 まあ、たとえていえば、データベースの話をするときに、
「あー、やっぱそのSQLおかしくね? SELECTかけてからLEFT JOINでUPDATEとかかけたら危険でしょ? そのフィールドのデータ型ってなに? インデックス化されてんの?」
 と、専門用語を使わないと、説明がめちゃくちゃ複雑になるという状況なのです。
 というわけで、ちゃっちゃと説明してしまいましょう。


 ・項目、パラグラフ、項番

 これはゲームブックに昔からある言葉です。
 ゲームブックは、
 「いま1番にいて、こういう状況。こうするなら2番へ。ああするなら3番へ」
 という構成をしていて、この番号とそれに付随する内容のことを指す言葉として、いろいろな呼び名があります。
 一番有名なのが「パラグラフ」ですが、「項目」もよく使われています。
 hikaliは「項番」をよく使っています。
 なので、hikaliが「項番」といったら、「パラグラフ」or「項目」のことを言っていると思ってください。hikaliはデータベース脳な人なので、ゲームブックで言うところの「パラグラフ」を、データベースでいうところのレコードとしてイメージしているのです。なので、項番17というと管理番号17のついたレコード、という意味で言っています。


 ・グラフ

 これはhikaliが勝手に使っている言葉です。
 このグラフは、円グラフとかのグラフではなくグラフ理論の方のグラフです。
 グラフ理論は点と枝の連なりを扱う理論ですが、hikaliは、パラグラフのつながり方をグラフと呼んでいます。なので、用例として、グラフを書くというと、分岐図を作っているような状況を想像してください。


 ・グラフ構造

 これは先ほどのグラフの構造自体のことを言っています。
 用例としては、ここのグラフ構造は四本のルートが錯綜する形で、といったら4本のルートがある部分のグラフの全貌の話をしています。


 ・クラスター

 これは、hikaliが独自で使っている言葉です。
 いくつかのパラグラフの塊のことを指しています。
 たとえばあるシティーアドヴェンチャーのゲームブック(盗賊都市あたりを念頭に書いています)における、ある酒場での事件がたとえば、20のパラグラフにより構成されているとします。
 そのつながり方(つまりグラフ構造)はともかく、そのパラグラフの塊のことをクラスターと呼んでいます。たとえて言えば、クラスターAが酒場の事件で、クラスターCは神殿での事件、といった具合です。


 といったところでしょうか。


 ■ミリーの天気予報の構造

 ミリーの天気予報は、大きく分けて四つのパートに別れています。
 詳しくはこちらを見てほしいのですが、軽く解説します。

 ・【ミリーの天気予報】セーブ機能搭載版投入しました!&作品の概要
 http://blog.story-fact.com/?eid=1177436


 1.序盤(1番〜34番)
 2.中盤(35番〜115番)
 3.推理(200番〜245番)
 4.解決(116番〜174番)

 1.の序盤は、導入&初期情報の提示。
 2.の中盤は、後ほど説明します。
 3.の推理は、情報を整理するパート。
 4.の解決で、一気に解決に向かいます。

 個別に見ていきましょう。

 ■グラフ図の読み方はこちら。
 ・GB解析 FFシリーズのみhtmlを見れるようにしました
 http://blog.story-fact.com/?eid=501930



 ■1.序盤

 左にあるのが、この序盤のグラフ図ですが非常にシンプルな構成であることが分かります。この序盤は、判断に必要な事前に知っておくべき情報を消化するために、かなり縦長になっています。
 その代わりに分岐は、とりあえず分岐してますという感じで、まったくやる気が感じられません(^_^; このあたりは、導入&初期情報の提示段階なので、そのあたりは割り切って作られているのですが、あー、こんなもんなんだ、へー、ぐらいで割り切って頂けると嬉しいところです。


 ■2.中盤

 中盤は非常に複雑です。
 実際に「サイボーグを倒せ」の技術を使っているのはこの部分です。
 これはのちほど説明します。
 とりあえず、グラフ図だけ貼っておきます。





 ■3.推理

 ここは特別な技術で作っている訳ではなく、完全にスクラッチ(つまり、ひとつひとつ分岐図を作って構成した)で作っています。実際の作業としては、手元にメモをちりばめて、テキストエディターに向かって、各項番のプロットを書き殴っていったのです。
 目の前のメモに数字と分岐線、テキストエディターにその内容、といった感じです。
 このプロット自体は2日で作った気がします…。
 ここで、情報を整理し、どういう方針にしていくかを相談をします。
 このパートは完全に力業で、わたくしhikaliの情報整理能力のみが頼りでした…。
 グラフ図貼っておきます。




 ■4.解決

 解決編は結構シンプルです。
 その代わり、中盤・推理の豊穣さを受けて、かなり幅広く分岐させています。




 以上で、各パートの構造の簡単な説明を終わりまして、前編を終わりとさせていただきます。後編では、主に「2.中盤」「4.解決」を中心に、使用されているスティーブ・ジャクソンの技術を解説へと移らせていただきます。

 以上、お疲れ様でした(^_^;
 しかし、事前にサクッとブリーフィングしておかなければならない情報が多すぎる……。



 ■関連エントリー
 ・ 膠着状態(デッドロック)解消型ゲーム
 http://blog.story-fact.com/?eid=1177436

 ・ミリーの天気予報にみるゲームブックの作り方。「サイボーグを倒せ」をヒントに。[後編]
 http://blog.story-fact.com/?eid=1180167

 ・ 【ミリーの天気予報】セーブ機能搭載版投入しました!&作品の概要
 http://blog.story-fact.com/?eid=1177436








| 開発日誌 | 22:05 | comments(0) | trackbacks(0) | 昨年の記事
【ミリーの天気予報】原稿完了【FLASHゲームブック】


 えっと、管理人のhikaliです。
 長らくお待たせしてしまった方もあるかと思いますが、新作のFLASHゲームブック「ミリーの天気予報」の原稿が完了しましたので、ご報告です。

 やったーーーーー!!!!! 終わった!!!!

 いやー、おもいっきり長かった……。
 総枚数が1250枚強、850KBと、お前それ戦艦ティルピッツじゃなくて、戦艦大和だろうと突っ込みたくなるんですが(^_^; いや、終わりましたね。いまでも信じられないぐらいです。
 とりあえず、終わった、終わった、終わったと、なんか壊れたレコードみたいに、管理人も壊れ果てているのですが、とりあえず、出ます!

 半年かかりましたか……。
 長い戦いだった……。

 さて、というわけで、こわれっぷりが激しい管理人の感想はおいておきまして、今後のスケジュールなど。

 リリース・スケジュールとしましては、今後システム周りを整備して、連休中or連休明けに予定通りリリース。幅があるのは、システム周りで問題が発生した場合を想定しての事です。できれば、連休最終日の朝にはリリースができているようにしたい。ただ、システムの方でトラブルがあるかもと、そちらも想定して、連休明けもあるかも、というアナウンスになっています。

 ただ、基本的なシステムは「ジャングルの要塞」の頃と変わらず、あの頃に使い切れていなかった、ver3仕様をフルに使うのでどれだけの問題が発生するだろうねえ、という感じで、若干楽観的な感じではあります。また、テストに長い時間がかかりそうな予感もします。

 個人的にはたいへんめまぐるしい連休になりそうですが、なんとか間に合いました。
 クリスマス・キャロルの季節にぴったりの、ハートウォーミングな戦艦大和。
 「ミリーの天気予報」、原稿完了です!





 待ちきれないという奇特な方は、ジャングルの要塞も一応好評稼働中ですので、こちらもかわいがって見てください。



 ■FLASHゲームブックの紹介ページ。
 http://story-fact.com/flash_gamebook.php

 ■「ジャングルの要塞」のページ
 http://story-fact.com/gamebook_dt2.php






| 開発日誌 | 01:17 | comments(2) | trackbacks(0) |
 【表紙&告知】新作「ミリーの天気予報」は連休明けぐらいになります【FLASHゲームブック】
 えーと、こんばんわ。
 管理人のhikaliです。

 一部の方々にはやきもきさせてしまった方もあったかと思いますが(<す、すみません)、ようやっとめどが立ってきましたので、告知いたします!

 新作となりますFLASHゲームブック「ミリーの天気予報」のリリースを11月終盤の連休中もしくは連休明けとさせて頂きます!

 おそらく総枚数が原稿用紙1000枚近くなる、なんとも巨艦巨砲主義の、戦艦ティルピッツかおまえは! とつっこみたくもなる作品ですが、なんだかよく分からないうちに、あれよあれよとビスマルク級になってしまいました・・・。
 前作「ジャングルの要塞」が450枚ぐらいですから、一気に倍増と大変な事になっているのですが、たしか、300枚で納めると決意して書き始めた話だった気が・・・。

 まあ、ともかく、めどが立ってきました。
 出ます!

 というわけで、本日は告知を兼ねまして、表紙を公開させて頂きます。
 ぜひとも、リリースまでお楽しみにして頂ければ嬉しいです。
 わたしはこれから追い込みだ(笑)。





 本作は、「ジャングルの要塞」でも登場した、イコウ、シャリー、ロット、リオネの四人組が引き続いて登場、- 浮遊船パオペラ冒険譚 - の第2作となります。第1作を遊んでいなくても、もちろん分かるようには作っていますが、前作を知っていれば、楽しさは倍増! 復習もかねて、こちらもかわいがって頂けると幸いです。


 ■FLASHゲームブックの紹介ページ。
 http://story-fact.com/flash_gamebook.php

 ■「ジャングルの要塞」のページ
 http://story-fact.com/gamebook_dt2.php






| 開発日誌 | 20:05 | comments(0) | trackbacks(0) |