Hatena::ブログ(Diary)

土屋つかさのテクノロジーは今か無しか

2015-12-02

DXRuby Advent Calendar 2015 3日目:汎用ゲームフレームワーク(を目指す)司エンジンの紹介

 どうもラノベ作家&ゲームクリエイター土屋つかさです。DXRuby Advent Calendar 2015(http://www.adventar.org/calendars/757) 3日目の記事です。2日目はhoshi_sano さんのAndroid は DXRuby の夢を見るか(http://hoshi-sano.hatenablog.com/entry/2015/12/02/000425)でした。Androidで動くのかよすげえな!

 今回は土屋が開発を進めている汎用ゲームフレームワーク(になるといいな)「司エンジン」を紹介します。名称は「ゲームを司る」から来ています(筆名は関係ありません(ホントです(ごめんなさい)))。今年の頭から本格的に実装を開始し、年内の1stリリースを目指しています。github上で作っているのでどなたでもコードを確認できます。

tsukasa
https://github.com/t-tutiya/tsukasa

 司エンジンはRubyで実装されたゲームエンジンです。もちろんベースにDXRubyを使っています。内部DSLスクリプトでコントロールと呼ばれるパーツ群を宣言し、ゲームロジックとシナリオを記述していきます。現在はノベルゲーム制作に指向していますが、将来的には汎用ゲームエンジンになる予定です(これについては後述します)。

 最大の特徴は、Smalltalkライクなメッセージ指向言語を採用していることで、これによってゲームプログラミングに特有な「実装を進めるにつれて個々のオブジェクトが巨大かつ複雑な状態遷移機械になってしまい、幾何級数的に開発コストが上がる」という問題への対処を試みています。

 現時点で、サンプルコードを含まないコアの実装部で4500行以上あり、恐らく2015年に作られたDXRuby関連プログラムで最大のプロダクトではないかと思います(まあ、土屋のコードはコメントと空行がすごく多いんですが……)。メタプログラミングの塊みたいなソースなので、その方面のサンプルになるかも(そして初見では意味がわからないかも)。

 司エンジンは、土屋が10年以上前から延々と考えてきた「ゲームアーキテクチャとはこうあるべきで、それを記述する言語はこうあるべきだ」という仮説を立証するために開発しています。これについて話すととても長くなるので、冬コミ頒布する筈だった司エンジン解説本の該当箇所をアップしておきます。冬コミには落ちましたが。

司エンジン解説本第1部サンプル(12月2日版)
http://someiyoshino.main.jp/file/1218_tsukasa_engine_book_sample_chap1.pdf

 ちなみに、冬コミには落ちましたが(くどい)解説本は作るつもりです。現時点で100ページを超えているため大した冊数は作れませんが(かさばると在庫を持てないのです)、年明けに全文PDFでアップできないものかと考えています。あるいはどこかの出版社さんからのオファーをお待ちしています(正気か)。

土屋「それではここでリスナーからのメールを紹介しましょう。まずは西日本在住のあおいたくさん」

>UI 部分の作り方とか、ゲーム・フローの制御とか、そういう部分はアクションゲームSTGプログラミングではなかなか身につかない部分なんだけど、わりと世によくあるチュートリアルアクションゲームSTG に寄っている感じです(作ってみるとわかるんだけど STG って実装が小さくしやすいのでチュートリアル向きなんだよね。画面見てもゲーム作った感強いし)。

土屋「これ、まさにそうなんですね。作ってみると分かるのですが、STGやACTは比較的チュートリアルが作りやすいんです。これは、STGに以下のような特徴があるからかなと思っています(あくまでチュートリアルとしてのSTGの話。作り込んで行くと、逆にチュートリアルで作ったコードが役に立たなくなったりもする)」

  • コード上のオブジェクトと画面上のオブジェクトがほぼ1:1で対応している
  • 敵の出現タイミングがプレイヤーの行動に依存しないため、時間管理が楽
  • ユーザーの入力や衝突判定などを1フレームごとに独立した物として処理できる

土屋「逆に、RPG(ユーザが方向を入力した後、1キャラ分スクロールしてからユーザの入力を再度待つ)やノベルゲーム(文字列を1文字ずつ出力している間スクリプトパースが止まるが、ユーザがキーを押下したら文字列表示処理をスキップしないといけない)など、インタラクションが時間差で発生するジャンルのゲームは、実際に動く物が出来るのに時間がかかる印象があります」

土屋「逆に言えば、RPGやノベルゲームが容易に作れるゲームエンジンがあれば、それでSTG/ACTも作れるんじゃないか? と土屋は考えています。ここで次のメールに行きましょう。えー、西日本在住のあおいたくさん」

>さて、司はもともと吉里吉里ライクな Ruby 用のノベルゲームエンジンとして作られていたものがスクラップアンドビルドを重ねて汎用ゲームエンジンになったものです。
>汎用というのは、このフレームワークでゲームフローと UI の構築ができるぞということで、

土屋「できます。基本的に吉里吉里/tjsでできることは全部できる筈です(ムービーの再生とflashの実行はできませんがい)。右クリックメニューやシーン遷移もスクリプトで記述可能です。専用の命令があるわけではないので、スクリプトを作り込む必要はありますが、一度誰かが書けば再利用可能になると思います(なるといいな……)」

>たとえば画面をクリックして謎を解いていくようないわゆる脱出ゲームのようなものなんかも作れると思います(……作れますよね?)。

土屋「できます。だっていざとなったらrubyで直接書けばいいから(爆)。司エンジンでは、規約に沿って記述すればユーザーがコントロールを自作できるので、必要な機能はいくらでも追加できます。これはRubyを採用しているメリットでもありますね。自分で作るといっても、司エンジンのアーキテクチャに乗るので、実装は最小限ですみます」

土屋「現状でもクリッカブルマップとクリックによってシナリオを分岐するメカニズムはあるので、簡単な物なら作れるんじゃないかな。サンプル作ってみたいかも。年内に作れたらACで公開できればいいけど、ちょっと難しいかな。あ、でもドラッグがまだ実装してないな。どうやろうかな……」

土屋「それでは最後のメールです。西日本在住のあおいたくさん」

>UI も場合によっては JSON とか YAML で書いて読みこむだけ、とかのほうがよかったりするかもしれません

土屋「これも同感です。司エンジンではスクリプトの中途で別のスクリプトを読み込む機能があります。この読み込みは実行時に行われるため、リアルタイムでコードを接ぎ木することができます。現状では読み込むファイルの拡張子が"tks(ノベルゲームスクリプト)"か"rb(内部DSL)"かを判別し、tksであればパースしてrb形式に変換しています」

土屋「あおたくさんの記事を読んでいて、このロジックを規格化して、ユーザーがパーサーを用意すればJSONでもYAMLでも読み込めるようにできたら更に可能性が広がるかなと思いました。というか、上手い事やってDXRuby::SpriteUIを組み込めないものか。SpriteUI/Quinciteになにができるのかまだよくわかってないんですが。早くドキュメント作ってよ!」

土屋「そろそろお時間です。DXRuby Advent Calendar 2015、第4日の明日はvivit_jcさんの「じゃあ実際ゲームってどうやって作るの」です。お楽しみに。ここまでのお相手は土屋つかさでした。また来週」

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証