進捗状況(2013/03) - FPSを作ってみる@wiki

(2013/03/20)

やはりここらで報告。って事はまだ出来てないのか！しかしalmost thereな感じではある。
前回書いた「避けるだけゲーム」の、半分くらい。自作フレームワークの使い方が板についてきた。
もうちょっと調子が乗ればローグライクとか作れそうだなあと思ったり。

早合点

Androidに本来備わっているGUIとゲームスレッドとの連携に、主に自分の理解不足のせいで手こずった。
GUI関連のメソッドをメインスレッドからしか呼べないのはWinAPIの時と同じかぁ※1という感じで知っていたのだが
例えばゲームスレッドから「GUI部品をクリアしたい」となった場合にメインスレッドのメッセージハンドラへメッセージを送って非同期にやるのは簡単だ。
しかしゲームスレッドからしてみれば「場面を切り替えたい時」等、ゲームの処理と同期したい場合が多い。
何も対策をしなければメニュー画面を開いてちょっと遅れてボタンが表示されたり、メニューを抜ける時にその逆という事態が起こりうる。
これではゲームとして格好悪い。
そこでメインスレッドがGUIの更新を終えるまで待機する処理を入れる。

ちなみにGUIの構造は

FrameLayout - LinearLayout
           - TableLayout
           - SurfaceView

のように重ねている（SurfaceViewがゲーム描画）
LinearとTableを用意しているのは、片方だけ使う想定。
メインスレッドからGUIをクリアするのは特に問題はなく、そのままLinearLayoutやTableLayoutのremoveAllViews()を呼べばいい。

当初はGUIを削除するのにどこで勘違いしたのかわからないがLayoutのChildrenは取得、操作できない物と思い込み
一旦根本のFrameLayoutを削除してからまたツリーを構築しなおしていた。
こうするとSurfaceViewがどこにも接続されてない瞬間があって、ちょうどその時ゲームスレッドが描画中だったりするとクラッシュする。
なのでメインからGUIクリアメソッドが呼ばれた際はゲームスレッドに「描画が終わった時に改めてGUIクリアメソッド呼んで」とメッセージを送って、
ゲームスレッドが暇になりGUIクリアを呼んだ際の処理も考慮して・・随分無駄なことをしていたもんだ。

※1
と、書いておいて何か違和感を感じ確認してみたら別にメインスレッドじゃなくてもいい様だ。
要はウィンドウを作成するとそれが作られたスレッドのメッセージキューに関連付けられるので
ウィンドウを作ったスレッドでメッセージループをちゃんと回しさえしておけば正常に処理されるのだが
Twilve(not Qt版)を作った当時はそんな事に気づかず「ウィンドウ作る時はメインじゃないとダメなんだ！」と思ってた気がする。
詳しい話はhttp://eternalwindows.jp/index.htmlの、
http://eternalwindows.jp/windevelop/message/message00.htmlとか見てもらえば。

予定

• 引き続き「避けるだけゲーム」の作成
• OpenGLを忘れかけているので復習

こんなとこかね

何番煎じかわからんけどOpenGLのヘッダから関数定義を抽出するプログラムを作ってみたり
(コメントにあるロード関数定義の例はWindows用だけど)
https://gist.github.com/degarashi/5203986
なんかさ、こまごました補助ライブラリ無しだと格好いいじゃないですか。
ぶっちゃけhttp://wlog.flatlib.jp/archive/1/2009-9-1のスクリプトを
C++で書いただけですが。

(2013/03/15)

ここらで一旦報告。
やった事

• Debianパッケージ作成
• フレームワーク（Java パッケージ化）
• フレームワーク（C++ リソースハンドル周り）

今更ながらtwitterクライアントのlinux版をDebianパッケージにてアップロードしておいた。
Qt5のラインタイムはまだ出回ってない様なのでこれも別にパッケージ化。
ライセンス記述とか全然してないが、まぁno warrantyで。ソースはgithubにあるから読みたい人はどうぞ。

Javaのフレームワークはパッケージ化が完了して外部からインポートして云々までは確認。
でもゲーム作ってナンボだよな・・従ってシンプルなゲームもどきを作成予定。
画面内をバウンドするボールを、主人公が避けるだけのアプリとか。メニュー画面やポーズなど場面遷移テストを兼ねて。

C++の方のフレームワークはリソースハンドルとの連携周りが上手く行ってなかったので少し修正。
不味いね。永遠ベータ病にかかっている。

---

前々から自作の物理シミュレーションがどうにも安定性に欠く事がずっと気になっていて、
時折既存のシミュレータをいじりながらどうするか考えていたのだが・・
思ったのは
「別にVerlet法で動かさなくてもよくね？」
という事。Verlet法なら安定して動きも軽いし位置の変更で速度が補正されるから便利だよね、という売り文句で導入はしてみたものの
結局摩擦や反発などの計算で速度は必要なのだ。位置と同時に速度を一緒に計算するVelocity Verletにしても・・
基本的には一定フレーム間隔でしか更新できないのが難点。
物体が衝突する際は精度が欲しいので一時的に更新レートを上げたいとか、
スローモーションでゲームを動かす時は時間刻みを小さくしたいなぁと思っても難しい。
いや、勉強不足で本当に一時的にレートを上げるアルゴリズムを実装できるのかは別として。

http://www.richardlord.net/presentations/physics-for-flash-games
ここのスライドをずっと進めて見ていくと各アルゴリズム（オイラー法やVerletはもちろんルンゲ・クッタも）で
ある加速度を加えた時の質点の動きを並列で動かして比較してるページがあるのだけど
これなんか見てると特別Verletが優れている訳でもないみたいだ。
とかいいつつ改めて上のスライドを見返すとTime Adjusted Verletとある・・後で調べないと。

ともかくVerletでなくたって位置をむりやり変更した後の速度の再計算はできる（よね？）
そんな事をうだうだと。

予定

• フレームワーク (Java　簡単なゲームを作成）

・フレームワーク（C++　スクリプトとの連携）
要するに続きをやると。物理シミュの改良もしたいけどそこまで手が回らないだろう。

#追記

スクリプトとの連携を含め既存エンジンと組み合わせるのは難しそう。
メモリアロケーションやリソースハンドルマネージャ周辺を入れ替える必要があって、だったら組み直した方が早い。
なので予定変更。
まずはJavaフレームワークのテストを公開まで持ってく。
その傍ら、物理エンジンを改良（更新レート変化やらルンゲ・クッタやら）できたらして動画を撮る。

その後はエンジン組み直しの悪寒・・（次で6代目）
でも現状のままだとゲームを動かす処理を記述するのが手間すぎるし
下手に自作のメモリ管理入れちゃってるから無意味にアロケータが3つくらい走ってて非常に気持ち悪い・・
今度はゲームエンジン以外にもQtやJavascript+php+sql関係やAndroidという手段があるから何も成果物出せない事態は避けられる筈。

(2013/03/10)

残念ながら今回も経過報告。相変わらず何処に向けて走ってるのかわからんが・・

やった事

• タスクシステムの移植(C++　とりあえずバージョン)
• Variantクラスの実装(C++)
• 外部サーバーにsvnリポジトリの設置とsvn+sshプロトコルによる接続テスト

取り組み中

• Debianパッケージ作成方法の調査
• フレームワーク(Java)

タスクシステム(C++)は仕組みを作ったというだけなのでゲームとして動かすには不十分。
リソース管理ハンドルとかも仕様を練り直し、リソースマネージャ内部に実際にリソース用メモリを確保するのではなく
単にnewしたポインタとの仲介をするだけに留める方向とした。こちらも書くだけ書いた状態。

Variantクラスについては前回書いた通りで、まだ詳細な動作確認をしていない
内部構造については特に凝ったことしてないなぁ・・多分そのうちgistに上げるけど。
数値型、配列、連想配列、文字列が一緒くたに扱えてムーブコンストラクタも使えて無駄がないね、みたいなクラス。
オブジェクト間通信に使用予定。

svn云々の項は例の釣りゲーで使う共同作業場所を勉強を兼ねて外部レンタルサーバに置く事にしたので
sshの設定やら何やら、である。

Debianパッケージ構築は一ヶ月前に触れておきながら放置してたのを思い出したように（実際そうだが）再開。
とりあえずdpkg-debを使ってバイナリパッケージを作れたが依存関係やライセンス記述とか知らんわー　みたいなレベル。
dpkg-deb? dpkg-buildpackage? debuild? 何がどう違うんだか・・
でもこれで一旦リリースしちゃうかも。正式なパッケージとかってなると奥が深そうだし。

そしてJavaのフレームワーク。もうちょいでパッケージ化できそう。
面倒くさいので当たり判定は基本的に総当りで形状は矩形と円。
流石に「相互判定するオブジェクト」と「弾丸の様なそれら同士は判定しない」種類分けくらいはするが。

予定

• フレームワーク (Java　パッケージ化の続きと動作確認）
• フレームワーク（C++　スクリプトとの連携）

(2013/03/04)

やった事

• android_native_app_glueの読解
• タスクシステムのC++への移植

native_app_glueについては前回書いた通り。ひと通り読んで流れはつかめたか。
結論として大筋は変えずそのまま自分のアプリで使えそうだが、如何せんC++ではなくCなのでその辺が自分にとって扱いづらかったり。
クラスに纏めるくらいはしたいかなと。

タスクシステムは紆余曲折あって
最初C++で書いていた物にを改良を加えつつJavaで書き直し、再度C++に逆移植という形になった。
そしてJavaバージョンは文法を覚えながらだったので下手にWeakReferenceを使っていたり無駄が気になるからもう一度書きなおす。
今度は描画やサウンド含めた自前フレームワークとしてPackage化したい。
更に言えばC++の方も「とりあえず」という事でオブジェクトを全てnewで確保するタイプとして実装したものの、これは
本筋のゲームエンジンで扱っているリソースハンドルで管理する方式とは違う為そのままでは組み込めない。
スクリプトとの連携も含めエンジンの書き直しをしたい誘惑に駆られるがどうなることやら・・

予定

まず、上にJavaバージョンを書き直すと書いてピンと来た人も1％くらいは居るかもしれないが
Androidでゲーム作るの再開。これまた諸処の事情で。
どんなゲームにするかも決めてあって2Dの釣りゲームになる予定（前に作ってた紐シミュレータはこれの布石）
期間はそれ程長くならないと思われる。追って報告したい。

NativeActivity & OpenGLは3Dのゲームを作る時用。
テクスチャを用意するのが面倒なので生ポリゴンの奥スクロールシューティングを考えているけど、これは何時になるかわからん。

あとC++のフレームワークでオブジェクト間メッセージのやり取りをする場合に「なんでも値が入る万能型 = Variant」が必要と感じたので
これも実装する。JavaだとObjectにキャストして後はinstanceofとかで何とでもなるんだが。

これからやる事

• フレームワークの整備 (Javaの方: パッケージ化)
• Variantクラスの実装
• フレームワークの整備 (C++の方: 動作確認を十分に行った後リソースハンドル形式とスクリプト対応)

多分、C++のフレームワークは次回更新までに間に合わない