カテゴリー: プログラム

誰がその絵を撮影しているのか

ゲームのジャンルにFPS、TPSと言う物が有ります。
ご存知の方も多いとは思いますがFPSはFirst Person Shooter、TPSはThird Person Shooterの略で主にゲーム内でのカメラの位置に違いが有ります。
即ち、FPSはカメラ位置=プレーヤー自信の視点のゲームでありTPSはプレーヤー以外の第三者の視点(多くは自分が操作するキャラクタ、マイキャラの後方斜め上)のゲームという事になります。

では、カメラの位置の差はゲームにおいてどのような部分に影響を与えるのでしょうか。
一般にFPSはTPSに比べ没入感(ゲームの中に入っているかのような感覚)あるいはマイキャラとの一体感が高いと言われています。
ゆえに、FPSではゲーム画面を見つめる事により船酔いのような症状、いわゆる「3D酔い」が発生する場合が有ります。逆に言えばそれだけ没入感が高いという事かもしれません。

さて、ここまではシューティングゲームの話でしたが、これをエロコンテンツに置き換えるとどうなるでしょう。
さしずめFPSとはエロビデオで云う所の「ハメ撮り」であり、TPSは「カメラマンによるAV撮影」と言った感じでしょうか。

エロゲの場合は元々絵という事も有り「視点」よりは「構図」がより重視される傾向に有りますが、別の理由で一人称視点が採用される場合が有ります。
それは、プレーヤーの「野郎の汚いケツなんて見たくもない」あるいは絵師の「描きたくない」と言う要求です。

こう書いてしまうと、実も蓋も無いですが「汚い野郎は絵にならない」と言うのももっともな理由なのかもしれません。
しかしもう少し積極的な理由、例えば臨場感、没入感が出ると言った理由で一人称視点を採用するエロゲももっと増えても良いのではないかと思います。


ラクガキ

なんか古いラクガキが見つかったので穴埋めにあげておきますね。

あと以前のエントリーで公開しました簡易ファイルマネージャー 「File Manager UI 」がバージョンアップしたらしいですよ。こっそりtongがファイル名ソートやスライドショー機能を追加したみたい。

自分のサーバー上の画像ファイル管理にお困りの方は下からどうぞ。

「File Manager UI」のダウンロード


簡易ファイルマネージャー 「File Manager UI 」

File Manager UI分散してゲーム開発を行う場合、ファイルの共有をどのようにするかは問題になることが多い。
特にcatwhiskerでは画像、音声を扱う事が多いのだが画像の場合どうしてもサムネイルが欲しくなる。
しかし、巷のファイルマネージャーをいくつか試した結果、Ajaxで表示は凝っているのだが重かったり当方が使っているサーバーではちゃんと動かないことが判明した。

よって急きょファイルマネージャーを開発することになり出来上がったのが「File Manager UI 」だ。

「File Manager UI 」は下記のような特徴を備えている。

  1. ディレクトリ内の画像ファイルその他の一覧を自動表示
  2. ディレクトリ内のファイル操作:アップロード、リネーム、削除
  3. ディレクトリ内のディレクトリ操作:作成、リネーム、削除
  4. Ajaxなどの重くなりがちなUIの排除
  5. ディレクトリツリーの表示によるスムーズなファイルへのアクセスの提供

出来たものを公開しないのは勿体ないというmezzoの声も有りCatwhiskerとして公開することとした。
簡便なファイルアクセスのツールとして使っていただければと思う。

「File Manager UI」のダウンロード


インタラクティブなコンテンツでのストーリーボード

以前から「現代的なクリックアドベンチャー」について色々書いてきているのですが、今回はストーリーボードについてです。

ストーリーボードは物語の流れを紙芝居形式で絵と簡単な文章で表現したものですが、イメージボード、イメージスケッチなどと呼ばれる場合も有り、多くの場合「制作の初期段階で作品の大まかな像をスタッフ間で共有する」ために造られ、ここから脚本、絵コンテ等が起こされてゆきます。

広く使われるという事はコンテンツ制作のワークロードにおいて有用であることにほかなりませんが、巷で語られるストーリーボードは映像作品向けの物ばかりで、ゲーム等の「分岐の多いコンテンツ」向けのものは少ないように思います。


愚直な状態遷移機械は作るのが大変

この手のプログラムの仕組みを真剣に考えたことがある人は、恐らくこの部分ハードルの高さに開発を躊躇する、あるいは「どの様に回避するかを真剣に考える」事でしょう。
かく言う当方もその一人です。

この手のプログラムとは当方の場合コッペリウスであり、プレーヤーの操作(外部からの刺激)に応じて反応を返し、そして状態が変化してゆく機械の事を指します。
この様な機械は何か正式な名称が有るのかもしれませんが当方は知らないのでここでは、これを仮に状態遷移機械と呼ぶことにします。

人の場合外部からの刺激に対してなにがしかの反応を返しますが、その反応は(生成方法はともかく)自動的に生成されます。
しかし、状態遷移機械の場合は自動的には生成されません。故に製作者あるいは開発者が、全ての刺激に対する反応をあらかじめ用意しておく必要があります。
そしてクリックアドベンチャの場合、反応とは「絵や動画」であり「テキストや音声」に他なりません。

●初期状態
お尻をつつく 体をよじって嫌がる
胸をもむ 激しく拒否する
クリトリスをつまむ 泣きだす

上記の例ですと3つの刺激に対して3つの反応を返します。
つまり、製作者は「3つの状態を表現するために3つの反応を用意しなければならない」事になります。
では、これが初期状態だとして何度か刺激を加える事により状態が変化したとします。
ここでは仮に「刺激に慣れ受け入れた」としましょう。

●初期状態 ●刺激に慣れ受け入れた
お尻をつつく 体をよじって嫌がる お尻をつつく 息が荒くなる
胸をもむ 激しく拒否する 胸をもむ 拒否する
クリトリスをつまむ 泣きだす クリトリスをつまむ 感じるのを怖がる

この場合で注目すべきは「状態が1増えただけで用意しなければならない反応は3増える」と言う事です。
つまり「状態が増えると用意しなければならない反応は2次関数的に増えてゆく」そして、反応の数は作業量に直結すると言う事でです。
さらに、「いつも同じ反応だとつまらないので、さらにランダム性を持たせたい」とかなってくるとどうなるか・・・、言わずもがなだと思います。

これをどのように回避するか、あるいは真正直に正面突破?
プログラムと言うか制作側の問題かもしれません