Luaの現状 †

Luaが出てきてから久しいがそういえばここ３～４年くらい触っていない。最新のLua環境ってどうなってるのか調べてみた。１９９４年に初版がリリースされてからもう２０年近く経ってることになる。触りだしたのが２００６年以降なので、ちょうどver5.1くらいか。で、そこから１０年経つけどメジャーバージョンアップなしに、ちょうど昨年5.3にバージョンアップしたらしい。

Lua 1.119941.0はリリースしていない
Lua 5.12006ガベージコレクションができたよ
Lua 5.22011gotoのサポート
Lua 5.32015intが64bitになったよ / UTF-8をサポート

大きな変更はないにしろ４年ぶりの更新なのでCライブラリ側でも最新環境にしておくことにする。

↑

Luaの使いみち †

便利そうでバグもそれなりに取れて安定してそうなLua。長年使いドコロを考えてきたけど今だに「コレだ！」っていう使い方が見つからない。
「ゲームのステージ構成を作るのに便利ですよ！」っていうのを聞いたり、あの有名タイトルでもこのタイトルでも使われてるよ！っていうのはよく聞くけど、正直言ってどこが便利かわからないところがある。プランナーがリコンパイルなしに、ステージをプログラミングできるところがいいところだという。しかし、プランナーはプログラミングしないじゃん。

結局プログラムが必要なところはプログラマが触るんだったら、きちんとしたデバッガーがあるC言語環境の方がいい。ブレークポイントに変数ウォッチ、ステップ実行、エディット＆コンティニューがあればこそ便利なことは多々あるが、それらがないLua環境で色々複雑な仕組みを作った結果「何かわからないけどバグった、プログラマーさん調べて」ってなるよね。

コンパイルしなくていいのは同意。高いコンパイラを買ったりしなくていいし、小難しい環境設定をしなくていいのも魅力。結局環境をLuaで代用できるから安く済む、っていう経営側のメリットはあれど、開発に有効なことってなんだろうな。

↑

自分でADVゲームのスクリプトエンジンをかくことを考えればLuaでかけるのは便利？ †

C言語のソースに直接シナリオデータをいれこむといった最悪の事態を考えれば、Luaを使ってLuaスクリプトでできる範囲のことでシナリオを構築するのも悪く無い。しかし、ADV専用のスクリプトエンジンはLuaよりもずっと汎用性が低い分、可読性にすぐれた書式になっていてADVに向いている気もする。スクリプトに入れ込む変数の管理や制御でバグらせてしまうのもスクリプトで複雑なことができすぎるからに他ならない。そういう意味でLuaはオーバースペックだと思う。

↑

メニューを作るのはどうか？ †

これは悪くなさそうである。プログラムで座標をエディット＆コンティニューを駆使してパーツを並べるよりは、Luaで誰かがちまちまパーツを並べながらウインドウの位置調整や文言の中身をいじるほうが効率がいい。実際仕事で使われているのを初めてみたのもメニューだった。これはメニューのプログラムを実行ファイルに含めると実行ファイルサイズが膨れ上がってメモリを圧迫するから、メニュー一般のプログラムを「データとして」外にだしとくことが目的だったが。

ただメニューっていうのは、押されたボタンや表示する内容、また遷移先がプログラムと密接に絡んでいるので、メニュー全般をLuaにすることはオススメできない。あくまでも表示位置の調整のみ、プログラムでいうとウインドウの表示位置のテーブルをCSVじゃなくてLuaで書いてもらう、といったイメージに近い。そうなるとそれはそれで、プランナーに投げられる仕事が少ないので、設計するだけプログラマが面倒な仕事を抱えることになる。
あとLuaのスクリプト中に直接テキストを入れ込むと海外版とかを作るときに、マルチランゲージ対応が難しい。やっぱり現実味がないか・・・？

↑

結局デバッガ †

結局できることがたくさんある分、立派なデバッガが必要だ。複雑なことをして効率化するのは悪いことじゃないが、それで出てきたわかりにくいバグも責任持って取ってもらえないと複雑になるのは歓迎できないし、バグらせにくくするかわりにシンプルな設計にするならLuaじゃなくて専用ADVエンジンとかCSVの方がいい。

プログラミングすると必ずバグる、それをどうやって抑えこむか、っていうところにフォーカスしてしまうと、やっぱり使いドコロに悩むなあ。