MGL週報 #53 - MGL 1.1.12 リリース
このエントリはゲーム開発用フレームワーク「MGL」の開発記録です。MGLはzlibライセンスの下に無償で提供されています。
ドキュメントはこちら
進捗状況の確認と問い合わせはこちら
MGL 1.1.12リリース
連休頭に公開予定とか言っておきながら、結局こんな時期になってしまいました。まあその……察してください。
そんな訳で、先ほどMGLの1.1.12をリリースしました。更新履歴はこちらになります。
今まで何度も述べていた通り、主なアップデート内容はシステムアクセスまわりの整理とドキュメント化になります。これらはゲーム内容とは直接関わることが少ないため地味に思われるかもしれませんが、ゲームもアプリケーションの一種である以上は軽視できない重要な機能です。同時に、ゼロから実装しようとするとそれなりに面倒な内容になります。
ゲーム内容に直接関わらない、地味で面倒な実装対応……私はこういった作業も嫌いではないですが、純粋にゲームを作りたい人からすれば避けて通りたい事でしょう。MGLのようなフレームワークを導入するメリットの一つは、このような作業を省けることにあるのです。
もちろん、MGLの他の機能と同様に、システムアクセスまわりもカスタマイズ可能な作りになっています。もし既存の実装内容に満足できない場合でも、MGLのソースコードに手を加える必要なく自前の実装に置き換えることができます。その辺のドキュメント化はまだ間に合っていませんが、最悪の場合の抜け道もちゃんと用意されているのでご安心ください。
……おや、何だか広告じみたお知らせになってしまった。
今回の更新でシステムアクセスまわりの必要最低限はカバーしていると思いますが、今後追加したい機能はまだいくつか存在しています。その辺も追々対応していく予定です。
次期バージョンでやりたい事
どこまで可能かは分かりませんが、次の1.1.13でやろうとしている事をざっくりとお知らせしておきます。
clang-format と clang-tidy の導入
なにそれ？ という方にざっくりと説明すると、clang-formatはコード整形ツール、clang-tidyは静的解析ツールです。どちらも広く利用されているコンパイラであるclangの（より正確にはLLVMの？）サブツール的なソフトウェアと言えば大きく間違ってはいないでしょう。
clang-formatはあらかじめ定義しておいたコーディングスタイルを元に、既存のソースコードを整えてくれるツールです。千差万別なスペースの入れ方や括弧の位置、改行の入れ方など、clang-formatを通すことである程度統一してくれるというものです。
MGLのスタイルは大まかに言えば古いBSDスタイルに近い記法＋命名にキャメルケースとパスカルケースといった感じです。これは一時期はごく無難で無個性なスタイルだった気がするのですが、ある時期にこれとは真逆に近いGoogleのコーディング規約が爆発的に流行し、以来は猫も杓子もGoogleスタイルとなっています。
今までの当たり前がある日突然非常識になる事は珍しい事ではなく、品質の優劣に繋がるとも考えていないため、今のところは特に変更する予定はありません。しかし、主流から外れてしまった以上、どのようなスタイルを用いているかを明示して、それに従う事は重要であると考えています。
……と、私が言っても説得力に欠けるような気がするので、かの有名な「プログラミング言語C」から引用しておきましょう。
大カッコの位置に凝る人もいるが，これはそれほど重要ではない。ここでは，好まれているスタイルのうち一つを選んだ。自分に合ったスタイルを選び，それを一貫して使うのがよい。
この本が最初に書かれたのは半世紀近く前であり、今もこのルールが通じるかどうかは分かりません。GoやRustなどを見ると、この常識も過去のものになっている気がしなくもありません。さらに興味深い事に、この本の著者とGoの開発者はそれぞれ同じベル研究所でUNIXの開発に携わった人たちだったりもします。
結局のところ、何が正しいのでしょう？ 答えは多分考えても出ませんが、確実なのは今日の常識が明日も常識である保証など無いという事です。
clang-formatを導入する事は、整形そのものよりも「私はこのルールに従っていますよ」を明示できるという点にあると思います。これは本来は最初の公開と共に行うべき事だったのですが、何だかんだで後回しになって今に至っている状態です。
さて、もう1つのclang-tidyはというと、こちらはソースコードを解析して問題になりそうな部分を指摘してくれるツールです。
静的解析そのものは現在でも2通りの方法で行っていて、同じclangの静的解析機能(Clang Static Analyzer)、そしてVisualStudio付属の静的解析ツール(メニューバーの「分析」→「コード分析の実行」から実行できるもの)を既に使用しています。これは処理の流れを様々なパターンで検証し、問題が発生し得るフローがあればそれを指摘するという感じのものです。一方、clang-tidyはソースコードを読み取って不具合のリスクやパフォーマンスの問題、より推奨される書き方などの指摘に特化しているようです。
実のところ先日初めて使ったくらいであまり詳しく調査できていませんが、これは残念な不具合を減らすのに効果的な気がします。
さてさて、両者のうちclang-formatは比較的導入が簡単なのですが、clang-tidyはちょっと厄介です。これを使用するには、対象ソースのコンパイルを通すのに必要な情報が一通り必要になります。MGLは現時点ではプロジェクト管理をIDEに頼りきっているので、この辺があまり柔軟ではないのです。
意外な事に、VisualStudioはclang-tidyの実行に対応しているのですが、Xcodeは対応している様子が無いのですよね。ちなみに、VisualStudioの標準コンパイラはMSVC、Xcodeはclang。……逆じゃない？
セーブデータまわりのドキュメント化
早いうちにドキュメント化しておきたい機能の一つ、セーブデータ関連をそろそろやっつけたいと考えています。
セーブデータって要するに、ファイルの読み書きじゃない？ と思うかもしれません。それはその通りなのですが、実際のところゲームのセーブデータは結構奥が深いのです。
でたらめなデータを読み込んでゲームを進行不能にしてはいけないのは当然として、ゲームのアップデートでフォーマットが変わっても古いデータは正常に読めるよう保たなければなりません。これはリリース後はもちろん、開発期間中も極力互換性を保たないとデバッグ作業に支障が生じます。
また、主にコンソール環境ではセーブデータのアクセス前後に必要な処理を挟む必要があったりもします。この辺はMGLのファイルシステムの機能を活用すれば解決できなくもないですが、セーブデータの特殊性を考慮すると特別扱いに値するものです。
これらの処理は基本的にバックグラウンドで非同期に行われなければなりません。もしそれがゲーム中にリアルタイムに行われるオートセーブだった場合、ゲームの進行と保存が同時に行われる事になります。そうなると、セーブ中に保存すべき値が変更されたら？ といった問題も考慮する必要があります。これは単純な同期機構だけでは解決できません。
MGLのセーブデータ実装補助機能をざっくりと表現すると、これらの問題を吸収して簡単に扱えるようにするための仕組みです。セーブデータの性質上ゲーム毎に定義しなければならない部分もありますが、大まかには「データを突っ込む処理」と「データを引っ張る処理」の2つがアプリケーション側のメインになります。
より細かい仕様はドキュメントで語るとして、ゲームを作るならそういう機能は早めに欲しいよね、と言うところです。
その他
MGLのような裏方にとって、地味で目立たない部分のメンテナンスはとても重要……なのですが、あんまり長く続くと退屈なプロジェクトになってしまいそう。むしろ、私がちょっと変わったことをやりたくなってきました。
やはり早めにPCを新調して……
この記事が気に入ったらサポートをしてみませんか？