CEDEC2008 小さな王様と約束の国
CEDEC2008でのSquirrelの講演を見ました。
スクリプタだけではなく、プログラマもSquirrelで一緒に開発。
３割がC++コードで7割りがスクリプト。プログラマも後半はほとんどSquirrelで作業しつつたまにC++実装してバインディング。途中で面倒になってきたので自動バインディング環境を作った。Squirrelによる処理負荷オーバーヘッドは約１０％程度。Squirrelでの文字列操作はreallocが大量に発生するので代替手法を用意。
Include
話を聞いた感じだと、キャッシュ付きのdofileだと思います。同じファイルでかつ更新の必要がなければキャッシュのclosureを実行する感じなのかな？これは面白いトリックなのでshive's codeにも入れたいですね。
shive's codeのC++クラスバインディングがSqPlusに似てる？
いや、別にSqPlusをパクったつもりはなかったんですが、使い方の見た目はまったく同じ(^^;
templateで引数、戻り値は型から取得。引数は７つまで対応らしい。ちなみにうちは５つまでしか対応してないすな。５つも引数使う関数ってどうよ？って思って定義してないけど増やすのは３分でできる。
ついでなのでRegisterGlobalとBindConstantもパクることにします。もちろん実装は自分で書きますけど。
（やっぱり）動的型言語は開発しづらい
諸所で同じような話は聞きますが、やっぱり動的型言語はコンパイル時にエラーにならない分バグを発見しづらいようで。
僕の場合、内製ツール開発でしかスクリプト(ちなみにLuaとPython)を使ったことがなく、ほとんど作業がひとりで完結してるのでこういった問題に遭遇しないんです。１回ゲーム開発で担当してやってみたいところですね。
スクエニの人はsq.exeを使って一応確認はしたみたいですけど、結局コメントをちゃんと書こうってオチになってました。
やっぱし非プログラマにSquirrelを直接書いてもらうのは危険な気がしています。超簡易言語やエクセルを用意してそこから定型処理的に.nutを起こす方が現実的なのかな？それでも結局プログラマの書くコードでエラーが出るかもしれないのでそこはUnitTest書くしかないんすかね？でもやっぱりUnitTestでは使う側のテストが難しいので微妙か。型チェックモッククラスを自動生成してインプットもアウトプットもモックにしてテストすれば。。。
