Hatena::ブログ(Diary)

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

2016-12-23

メッセージ指向ゲーム開発言語「司エンジン」v2.1をリリースしました

Ruby Game Developing Advent Calendar 2016(http://www.adventar.org/calendars/1647)の22日目です。15日目はあおいたくさんの「DXRuby アクションゲームフレームワーク」でした(でした!)。

v2.1リリース


v2.1リリース(github
https://github.com/t-tutiya/tsukasa/releases/tag/v2.1

スターターキット
http://someiyoshino.main.jp/file/tsukasa/tsukasa_v2_1.zip

クリスマス直前ということで、司エンジンのv2.1をリリースします。大幅な機能追加は(多分)ないのですが、直交性の無い機能を徹底的に修正していまして、随分と使いやすくなった&今後の改修が楽になったと考えています。

・v2.0の時点で「もう大幅な仕様の更新は終わりにしよう。ドキュメント作るのが大変すぎるから」と心に決めたのですが、下記更新履歴でお分かりの通りむっちゃ変わってます。なのですみません。ドキュメントが間に合いませんでした(ごめんなさいごめんなさいごめんなさい)。サンプルコードは修正済みなのでそちらを参考にしてください。

・ちなみにですが、年明けにv2.2をリリースする予定で、ここでもまた大幅な仕様更新を予定しています(ごめんなさいごめんなさいごめんなさい)。v2.2の作業予定については記事の最後をお読みください。

v.2.1更新履歴


■main.rb処理
・初期設定をmain.rb上で構築するように変更
・Dataコントロール:_TEMP_/:_LOCAL_/:_SYSTEM_追加

■ファイル構成
・requireの依存関係を整理
・ファイルインクルードを統合するTsukasa.rbを作成
・ppを司エンジンの必須ライブラリから外した
・削除
 ・bootstrap_script.rb
 ・config.rb
・text_layer_script.rbを新設しtksパーサー関連スクリプトを整理

■テスト
・テストコード構築中

■司スクリプト
・インラインデータ記法を廃止(パーサーには残っている)

■default_script.rb
・requested_closeコントロールを廃止
・_CHECK_INPUT_ユーザー定義コマンドをControlから移動
・_CHECK_MOUSE_ユーザー定義コマンドをClickableLayoutから移動
・追加
 ・_SYSTEM_SAVE_
 ・_SYSTEM_LOAD_
 ・_LOCAL_SAVE_
 ・_LOCAL_LOAD_
 ・_QUICK_SAVE_
 ・_QUICK_LOAD_
・削除
 ・_MOUSE_ENABLE_
 ・_CHECK_REQUESTED_CLOSE_

■_SYSTEM_環境変数
環境変数を仕様から廃止したため、以下の全環境変数を廃止
 ・_PAD_NUMBER_
 ・_SAVE_DATA_PATH_
 ・_SYSTEM_FILENAME_
 ・_LOCAL_FILENAME_
 ・_QUICK_DATA_FILENAME_
 ・_MOUSE_OFFSET_X_
 ・_MOUSE_OFFSET_Y_
 ・_MOUSE_POS_X_
 ・_MOUSE_POS_Y_
 ・_PLUGIN_PATH_
 ・_CURSOR_VISIBLE_
 ・_PAD_NUMBER_

■Controlコントロール
・_CHECK_のdatastoreプロパティ廃止
・_GET_の各要素の取得先コントロール名と格納名を指定できるようにした
・単体でルートコントロールになれるように実装を更新
・_SCRIPT_PARSER_/_LOAD_NATIVE_をWindowからControlに移動
・_SERIALIZE_追加
・_CHECK_INPUT_をユーザー定義コマンドに移動
・_INCLUDE_コマンドの簡易記法を廃止
・SET/CHECKの第1引数をコントロールパスに変更
・_RESIZE_をClickableLayoutに移動
・_PUTS_の仕様を更新
・_INCLUDE_コマンドのforceオプションを廃止。これに伴い_TEMP_環境変数で保持していた_LOADED_FEATURES_を廃止。

■Windowコントロール
・Window#mouse_x/mouse_yプロパティを読み出し可能に変更(暫定処置)
・派生元をClickableLayoutクラスに変更
・ファイル名をTsukasa.rbからWindow.rbに変更
・Window#mouse_enableプロパティ追加
・_RESIZE_コマンドで実ウィンドウのサイズが変わるように修正
・終了判定をrootコントロールのexitプロパティを見て判定する形式に変更
・close/close?メソッドを廃止
・auto_closeプロパティ追加
・_CHECK_REQUESTED_CLOSE_をユーザー定義コマンドから移動
・廃止
 ・_SAVE_
 ・_LOAD_
 ・_QUICK_SAVE_
 ・_QUICK_LOAD_

■ClickableLayoutコントロール
・_CHECK_MOUSE_での安定を汎用_CHECK_での判定に変更
・_CHECK_MOUSE_をユーザー定義コマンドに移動
・_RESIZE_をControlから移動

■TextPageコントロール
・_TEXT_コマンドの簡易記法を廃止

■Dataコントロール
・新規追加

■Inputコントロール
・新規追加
・第1引数でパッド番号を指定出来る様にした

v2.2の予定


・v2.1では司エンジンの言語機能の完成を目指し、ほとんどの目標を達成することができました。そのため、コア機能についてはそろそろ作業がなくなりつつあるのですが、とはいえ次も大幅に互換性が無くなる予定です(ごめんなさい)。以下だいたいの予定です。

ウィンドウ周りの制御

・v2.0では「DXRubyに依存する箇所は全部ユーザー定義コマンドに切り出す」というポリシーで進めていたのですが、これがあまり上手くないことに気付き、v2.1ではキー入力周りはInputコントロール、ウィンドウ制御周りはWindowコントロールにまとめる形にしています。

・まだWindowに移行できていないプロパティ(タイトルバーの文字列とか)についての移行も進めます。また、現状ではマウス座標をWindow.mouse_x/yから提供しているのですが、これをInputに移すべきかを考え中です。

GC制御

ガベージコレクションはメモリ管理の手間からプログラマを解放してくれる救世主なのですが、ゲームではエンジニア作業負荷よりもFPSが安定することが優先されるため、不定期にGCが走ってしまうと困ります。

rubyにはGCを一時的に停止する機能がありまして、これを司エンジンから制御したり、デバッグ時に現在のメモリ状況を出力する手段を用意したいと思っています。これ以前からやるつもりだったのですが、土屋がGCの知識が薄くて後まわしになってます(ごめん)。

余談1:GCの無い言語での場合の話(メモリフラグメンテーション

・C++のようにGCがない環境の場合、GCによってゲームの実行が不定期に停止するということはないのですが、今度はメモリフラグメンテーションの問題が発生します。ゲームでは大量のオブジェクトの生成と廃棄が繰り返され、かつ長時間にわたってプログラムが実行され続けるので、メモリフラグメンテーションによる速度低下の問題が顕在化します。
コンシューマーゲームでの開発では(恐らくmallocの性能が低いために)、そのゲーム専用のメモリアロケータを独自に実装しシーンの切れ目ごとに大量のメモリを確保・解放し、それを分割して使用したりもします。

余談2:Unityでの話

UnityC#Monoベース上で動作しているため、GCを明示的に停止させられないっぽいです(間違えてたらすみません)。おそらく商業ゲームでは、途中でGCが走らないように、シーンの切れ目などでまとめてメモリを確保してしまってるんじゃないかと思います。

シェーダ

シェーダーのインターフェイスはまだ仮々でして、この辺でルールを作りたい所です。

ユニットテストコード

・v2.1では長年の懸案だったユニットテストを行えるようになりました。今の所は本当にお試しで実装しただけで、テストコードを量産する形にできていません。こちらのコードを整理して、よりテストをしやすくしたいと考えています。rakeとか(rakeがなんなのか未だによくわかってないけど)使うかも。
・またCI環境を構築できるようにしたいと思っています。

レンダリング済みフォントのドキュメント

吉里吉里にあるレンダリング済みフォントについて、ツールも機能も実装済みなのですが、ドキュメントがないので用意します。

カスタムコントロールの実装方法

・そろそろControlのインターフェイスが安定しつつあるので、カスタムコントロールの実装方法をドキュメント化したいです。
・本当はyield_stackをインターフェイスから取り除いてからにしたかったのだけど、どうもこれは外す方法がないっぽいので……。いや、でも本当に無いのかな……?

・_END_FRAME_を_RESUME_に改名するか悩み中です(組み込みのコマンドはALIASできない)
・float_x/yの処理がこのままで良いのか(この処理を諦めてしまえばもっとコア実装が

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


画像認証

トラックバック - http://d.hatena.ne.jp/t_tutiya/20161223/1482459313