カテゴリ:開発ネタ( 3 )

[SPEC] アドベンチャーゲームのシステム

久々に開発ネタを。
といっても、自分のメモによれば 2000 年あたりから考えていたものですが、どう考えても実装する時間も気力もなさそうなので、ネタとして公開することにします。
まあいずれ作る可能性も残ってはいるわけですが、別に、これを見てパクってインスパイヤしてくれても全然構いません。

タイトルにも書いたように、このネタのコードネームは SPEC です。これは Scenario Player with Extensible Commands の略称で、何をするものかと言えば、アドベンチャーゲームのシステムとなるプログラムです。
特定のアドベンチャーゲームのプログラムではなくて、もう少し汎用的な実行環境です。
SPEC の仕事はシナリオと呼ばれるファイルを読み込んで、そこに書かれたコマンドを書かれた順に実行することです。ただし、普通、アドベンチャーゲームには選択肢というものがあるので、シナリオは分岐することがあります。大雑把に言うと、1 つ目のコマンドを実行し、次に 2 つ目のコマンドを実行し、続いて 3 つ目のコマンドを実行‥‥というように順にコマンドを実行するのですが、条件分岐があると、4 つ目のコマンドはとばして、5 つ目のコマンドを実行したりだとか、一気に 10 個目のコマンドへジャンプしたりという、シナリオの制御を行います。
簡単にコマンドという言葉を使いましたが、具体的には「メッセージを表示するコマンド」、「画像を表示するコマンド」、「音を出すコマンド」、「選択肢を表示するコマンド」、「条件に応じてシナリオの分岐(ジャンプ)を行うコマンド」‥‥etc なんてのがあります。

ここまではまあよくある(?)システムだと思うのですが、実は SPEC のウリにしたいのは、これらのコマンドの種類をシステム自身とは切り離して自由に拡張できることです。
例えば、シナリオで雪のシーンになったら、画面上にちらちらと雪の降るアニメーションを起こしたい、とかあるじゃないですか。それも常に同じ絵じゃなくて、背景とかの絵が出ている上に重ねるようにして雪がちらちらと舞うとか。他にも、画面を揺らす効果だとか、エンディングでスタッフロールを流したいだとか、ミニゲームとして 15 パズルをやらせたいとか‥‥。
システム側でいくらコマンドを用意してやっても、要望に全部応えることはできません。
それなら、そのコマンドをシステムとは別に増やせればいいじゃないかと。

もちろん、コマンドを作るのにはプログラミングの知識が必要になります。しかし、プログラミングの知識がある人がアドベンチャーゲームを作るときでも、一からプログラムを書くより、足りないコマンドだけを作る方が楽できます。それから、コマンドを作った誰かが作ったコマンドを公開すれば、プログラミングの知識を持たないアドベンチャーゲームのシナリオ作者(スクリプトだけ記述するような)でも、公開されたコマンドを使ってその恩恵に授かることができます。

以上のことをどのように実現しようかっていう、もうちょっと細かい設計もある程度進めていたわけですが、それについてはまた次回以降で。


● まとめ ●

・SPEC (Scenario Player with Extensible Commands) とはアドベンチャーゲームのシステム。
・シナリオファイルを読み込んで、そこに書かれたコマンドの通りに処理を行う。
・コマンドには「メッセージを表示するコマンド」、「画像を表示するコマンド」、「音を出すコマンド」、「選択肢を表示するコマンド」、「条件に応じてシナリオの分岐(ジャンプ)を行うコマンド」、etc などがある。
・SPEC のウリは、これらコマンドの種類をシステムと独立して自由に拡張できること。

[PR]
by hironytic | 2006-04-26 22:27 | 開発ネタ

メールデータコンバータ

今まで使っていたのと別のメーラーに乗り換えてみようかなと思っても、過去のメールデータを捨てたくないのでそのままにしてたりとかってよくあります。
ぼくは Becky! 2Shuriken Pro3 /R.2を主に使うユーザーですが、この 2 つのメーラー間でメールデータをやりとりしたいときもないわけではありません。
(2つもメーラーを使うなというつっこみもあるかもしれませんが)

そこで次のような仕組みを考えました。

・メーラー別の入力プラグインで各種メーラーのメールデータを読み込む。
・メーラー別の出力プラグインで各種メーラーにメールデータを書き出す。

要するに、各種メーラー共通のメールデータフォーマットを用意して、そのフォーマットと各種メーラーのデータを変換する部分をプラグインにするわけです。
(なぜ、プラグインにするかというと、ぼくがいろんなメーラーを解析してコンバータを作りたくないから。プラグインにすれば他の人が必要に迫られて作ってくれるかもしれないし、データ構造を知っているメーラー作者が作ってくれるかもしれないから)

問題は、各種メーラー共通のフォーマットというのが設計できるかどうかです。

ちょっと考えてみました。
例えば、Becky! には各メールにカラーラベル(16,777,216色だけ用意できるはず)を付けることができます。
Shuriken では、A ~ D の 4 種類(マークなしをいれると 5 種類)のマークを付けることができます。
これで共通のフォーマットに「カラーラベル」と「マーク」を用意するというやり方では、多くのメーラー共通にするのはムリっぽいです。
ならば、共通のフォーマットにはそれらは属性という、それだけでは意味がわからないものとして用意してやればどうでしょう。
意味はユーザが決めるのです。

例えば、Becky! 用の入力プラグインはカラーラベルを勝手に「カラーラベル」という属性に変換します。
同様に Shuriken の入力プラグインはマークを勝手に「マーク」という属性に変換します。
それだけではコンバートできないので、出力プラグイン側では、どの属性をどう変換するかをユーザに指定させます。
例を挙げると、Shuriken の入力プラグインから得たデータには「マーク」という属性がついています。
これを、Becky! の出力プラグインを使って出力しようとすると、ユーザは「カラーラベル」の項目をどうするか尋ねられます。
ユーザは「マーク」という属性が A のときにカラーラベルを赤色(#ff0000)にしろというような変換ルールを指定するわけです。

そういうルール指定が柔軟にできるシステム部分を作りたいなと、ふと思いました。
#逆にいうとプラグイン部分は作りたくないな…。
[PR]
by hironytic | 2004-12-28 17:29 | 開発ネタ

スパイ用Webメール コーポレートエディション

災いの元?--マイクロソフト裁判と電子メールの深い縁

社内メールであっても、うかうかしてられないわけですね。
「なお、このメールは自動的に消滅する」ってなメールのニーズがあるってことじゃないですか。
差出人が設定した期間を過ぎると見えなくなるメール。
社内メール向けということで、いっそ Web メールのシステムにしてしまえばサーバー側で削除できるし、各自のメールソフトには入らないし。

と思って検索したら こんなものが
実現方法は違うけど既にあるじゃん。しかも1999年の記事だし…。
[PR]
by hironytic | 2004-03-31 00:25 | 開発ネタ