#author("2016-06-11T17:31:51+00:00","","") ***Luaの現状 [#lfaedcb6] Luaが出てきてから久しいがそういえばここ3~4年くらい触っていない。最新のLua環境ってどうなってるのか調べてみた。1994年に初版がリリースされてからもう20年近く経ってることになる。触りだしたのが2006年以降なので、ちょうどver5.1くらいか。で、そこから10年経つけどメジャーバージョンアップなしに、ちょうど昨年5.3にバージョンアップしたらしい。 |Lua 1.1|1994|1.0はリリースしていない| |Lua 5.1|2006|ガベージコレクションができたよ| |Lua 5.2|2011|gotoのサポート| |Lua 5.3|2015|intが64bitになったよ / UTF-8をサポート| 大きな変更はないにしろ4年ぶりの更新なのでCライブラリ側でも最新環境にしておくことにする。 Luaのダウンロード [[https://www.lua.org/download.html]] ***しかし、Luaの使いみちがよくわからない [#x3050d3b] 便利そうでバグもそれなりに取れて安定してそうなLua。長年使いドコロを考えてきたけど今だに「コレだ!」っていう使い方が見つからない。 「ゲームのステージ構成を作るのに便利ですよ!」っていうのを聞いたり、あの有名タイトルでもこのタイトルでも使われてるよ!っていうのはよく聞くけど、正直言ってどこが便利かわからないところがある。プランナーがリコンパイルなしに、ステージをプログラミングできるところがいいところだという。しかし、プランナーはプログラミングしないじゃん。 結局プログラムが必要なところはプログラマが触るんだったら、きちんとしたデバッガーがあるC言語環境の方がいい。ブレークポイントに変数ウォッチ、ステップ実行、エディット&コンティニューがあればこそ便利なことは多々あるが、それらがないLua環境で色々複雑な仕組みを作った結果「何かわからないけどバグった、プログラマーさん調べて」ってなるよね。 コンパイルしなくていいのは同意。高いコンパイラを買ったりしなくていいし、小難しい環境設定をしなくていいのも魅力。結局環境をLuaで代用できるから安く済む、っていう経営側のメリットはあれど、開発に有効なことってなんだろうな。 ***自分でADVゲームのスクリプトエンジンをかくことを考えればLuaでかけるのは便利? [#m7dc1f0c] C言語のソースに直接シナリオデータをいれこむといった最悪の事態を考えれば、Luaを使ってLuaスクリプトでできる範囲のことでシナリオを構築するのも悪く無い。しかし、ADV専用のスクリプトエンジンはLuaよりもずっと汎用性が低い分、可読性にすぐれた書式になっていてADVに向いている気もする。スクリプトに入れ込む変数の管理や制御でバグらせてしまうのもスクリプトで複雑なことができすぎるからに他ならない。そういう意味でLuaはオーバースペックだと思う。 ***メニューを作るのはどうか? [#s7ffed2c] これは悪くなさそうである。プログラムで座標をエディット&コンティニューを駆使してパーツを並べるよりは、Luaで誰かがちまちまパーツを並べながらウインドウの位置調整や文言の中身をいじるほうが効率がいい。実際仕事で使われているのを初めてみたのもメニューだった。これはメニューのプログラムを実行ファイルに含めると実行ファイルサイズが膨れ上がってメモリを圧迫するから、メニュー一般のプログラムを「データとして」外にだしとくことが目的だったが。 ただメニューっていうのは、押されたボタンや表示する内容、また遷移先がプログラムと密接に絡んでいるので、メニュー全般をLuaにすることはオススメできない。あくまでも表示位置の調整のみ、プログラムでいうとウインドウの表示位置のテーブルをCSVじゃなくてLuaで書いてもらう、といったイメージに近い。そうなるとそれはそれで、プランナーに投げられる仕事が少ないので、設計するだけプログラマが面倒な仕事を抱えることになる。 あとLuaのスクリプト中に直接テキストを入れ込むと海外版とかを作るときに、マルチランゲージ対応が難しい。やっぱり現実味がないか・・・? ***結局デバッガ [#a5bb22fc] 結局できることがたくさんある分、立派なデバッガが必要だ。複雑なことをして効率化するのは悪いことじゃないが、それで出てきたわかりにくいバグも責任持って取ってもらえないと複雑になるのは歓迎できないし、バグらせにくくするかわりにシンプルな設計にするならLuaじゃなくて専用ADVエンジンとかCSVの方がいい。 プログラミングすると必ずバグる、それをどうやって抑えこむか、っていうところにフォーカスしてしまうと、やっぱり使いドコロに悩むなあ。 ***構造体が使えない [#r3ed3a0f] Luaの最大の特徴がテーブルらしいんだけど、C言語でいうところの構造体のようなテーブル定義ができない。もうここまでLuaと相性悪いとどうしてこんな言語仕様にしたのか全く理解に苦しむので、これを読んで見てる。 [[Programming in Lua プログラミング言語Lua公式解説書]>https://www.amazon.co.jp/dp/4048677977] 作ったヒトの本なら何か気持ちがわかるかもしれない。 ***とりあえず、いつでも使えるようにしとく [#ia835344] で、Luaスクリプトをプログラムで読めるようにしておくわけだけど、特に難しいことはない。ダウンロードしてきたソースをVCに突っ込めば、簡単にコンパイルできる。1つ注意が必要なのはLuaはそれ自信がコマンドラインで動くアプリなのでライブラリではない。 なので、main関数が存在する。だからLua.cのmain()関数の名前を別のmain2とか適当に変えてあげないと、自分のmain関数とバッティングするのでそこだけ注意。 main() ↓ main2() ***includeファイルは? [#m2284620] そして自前のC言語プログラムから使うために「lua.hpp」をincludeすること #include "lua.hpp" 個別にincludeする場合はこっち。上と同じ。 extern "C" { #include "lua.h" #include "lualib.h" #include "lauxlib.h" } ***Luaの関数を呼び出す [#baa63390] lua_getglobal( LuaState , "Luaの関数名"); lua_pcall(LuaState, 引数の数, 戻り値の数, 0); ***Luaから関数を呼び出される [#u0c6b568] Luaの関数"dqDraw"とCの関数「dqDraw」の関連付け lua_register( LuaState , "dqDraw" , &dqDraw ); 呼び出されるCの関数のカタチはコレ int dqDraw( lua_State *L ); ***Luaファイル同士でのinclude [#n363aa61] include"dqLib.h"に相当するLuaのコードは「拡張子を書かない」ことに注意 require "dqLib" 関数形式でも使える require("dqLib")