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

(2013/01/27)

Qtドキュメント

Qtのドキュメントはオンラインでも読めるけど
ローカルにあった方がQtCreatorで語句にカーソル合わせてF1押すだけで瞬時にヘルプが読めて楽だ。
という事でヘルプのビルドや設定などした。
「5.0.0だったらビルド済みあるだろ」というのは気にしちゃいけない。

情報の断片の管理

Qtではnewを当たり前のように使うので気軽にnewする方向で組んでいるがそれは良いとして
案の定ツイートやユーザー情報を取得＆管理する部分で苦戦している。
只今のTwitterはAPIの呼び出し回数が一時間辺り150回と限られていて
ユーザーから要求がある度にポンポンとクエリを投げていたのではあっという間に消費し尽くしてしまう関係上
既にある情報はそのまま使い、そうでないものに関しても向こうで用意されたAPI群を駆使して
なるべく呼び出し回数を少なく済ませたいと思うのは極自然な流れだ。

ここで悩みの種となるのが同じ情報を取得するにも複数のAPIがある事。
例えばツイートを検索するsearchを呼ぶと確かユーザーアイコンのURLも一緒に取得出来たと思うのだが
自分のフォローしているユーザーのTL(HomeTL)では引数によってIDだけしか取れなかったりする。
個別にユーザー情報を引き出すAPIは勿論あるけどそれだって複数ユーザー分を同時に取るなんてのもある。
あとは他のクエリをしたらついでに含まれるような変数とかね。

この辺を真面目に考えだしたらどうも考えが纏まらなくて困る。
まぁ、2日程悩んだお陰でアイデアが固まってきたからそろそろ次に進めそうではある・・
基本的なUIとかクラス構造は前回からのほぼコピペだからその辺は楽っちゃあ楽。

(2013/01/22)

ゲームの前に

やはりTwitterクライアントを片付ける事にした。
ゲームを作る意欲は戻ってきているが、ここで本腰をいれる前に心残りは出来るだけ排除しておきたい。

手始めにQtの使い方を忘れてしまっていたのでソース見ながらそれの復習と
テキスト解析の前処理で使う形態素解析(MeCab)のコンパイル & インストール & 動作確認を行った。
Qt5移行に従う改変とかはほぼ無いものの元々仕様がアレだった事もあり
一から作り直す方針。最初からオープンソースで行く。
それとQt5からJSONクラスが(やっと)サポートされるので、今まで自作クラス使ってたのを標準クラスに移行する。

まずはTLの受信その他ひと通りの機能が使える状態まで持っていき、後にフィルタリング機能を追加という順番にしたい。
そこまで出来ればこの件に関しては満足かな。

(2013/01/21)

一区切り

定期的にGitHubにコミット出来るとローカルでアレコレやってるのと違って外部にも進んでる感が示せていいね。
という訳で自作拍手の改良版とアンケートモジュールの公開をした。
内部では自前拍手のクラス化やログイン情報の分離など色々。

前回のコミットでうっかりパスワードを埋め込んだままコミットしてしまうポカをしたものの
ローカルのテストDB用だった為にセーフ。でも、怖いね。
思い残していたweb関連はこれで一区切りとしたい。

次の一手

数日前は「そのままの勢いでTwitterクライアントへ！(Qt版)」と思っていたが
そもそもの目的がゲーム(のベース)ばかり作っていて飽きたから、またゲームが作りたくなるまでの気分転換だった為、
どうしようか迷う。
Qt4からQt5への移行となる訳だが1〜2日ですぐ済む程度なら、さっさとやってしまいたい所ではある。

(2013/01/17)

自前拍手

ゲームのほうは一旦休憩で、今週いっぱいはこれまでにやり残した事の片付け週間としている。
第一弾はweb拍手。まだまだ機能が足らないけど稼働まで漕ぎ着けた。
実を言うとatwikiによるURL改変などを巧みに回避し
半ば無理やり外部サーバーのphpやsqlにアクセスしているので管理者に良い顔はされないだろうな。
文句が来たらさっさと撤収して別のサーバーに行くかも。

とりあえず動くようなので気が向いたらコメントのページめくりや設置場所毎にカウンタ分けたりしたい。
ソースをもうちょっと整理したらGitHubにも上げたいとこだが
細々したプロジェクトを1つ1つのリポジトリに置くと無駄にリポジトリ数が増えて微妙な感じが。
submoduleとかいうので何とかなるの？

次の一手

折角javascript, php, sqlを復習したのでこの勢いで次へ。
ラジオボタンによるアンケートモジュールが、同じく作りかけなので改修して公開・・・と。

自前拍手は一応GitHubにも上げておいた。WebMiscというのがそれ。
clapフォルダの他にreputationっていうのもあるがこれはサイトの感想や評価をスライダーで設定して
色々やろうとしてた奴の作りかけ。アンケートモジュールはこれとは別で、もっとシンプル。

(2013/01/15)

ときに

ワンダと巨像のような広大なフィールドであたり判定を管理したいって場合はどうすんだろう？
全体を1つのツリー構造にっていうのは幾ら何もない空間を省いたとしても、無いだろう。
浮動小数点数の精度問題もありそうだし。

そうなると順当に考えて主人公の位置を中心に適度な範囲で・・・
(遥か遠く離れた場所の当たり判定など要らないだろう)
となる訳だが、木構造が対象とするの中心座標を切り替える際は全部のオブジェクトは登録しなおすのか？
否、4分木ならスライドさせればなんとか行けるかもなぁ。
どちらにせよ実装はまだ止めとくけど。

(2013/01/15)

配信通知ウィンドウ

トップの配信通知ウィンドウはIFrame使って無理やり実現してるせいか、
最近のChromeのスパムブロック機能に引っかかって非表示になるようなんで省こうかね。
去年ちょこっとphp,mysql,javascriptを触っていた事もあって頑張れば自作出来そうな気もしないでもない。
問い合わせが来たらustreamにアクセスして配信中か調べるってphpで多分できるよね。
んで、10分間隔でキャッシュしておくとか。

8分木とか

8分木(又は4分木)の改良を行った。
ベースに使ったのはマルペケさんの記事http://marupeke296.com/COL_2D_No8_QuadTree.html

で、今回加えたのは
ルート空間や親空間にあるオブジェクトが木を巡回する時に全てのオブジェクトを衝突候補としてしまうのを抑えるため
巡回時、枝を通過するたびに手持ちのオブジェクトリストをその枝が担当する領域に合わせて刈って行くという物。
当然その為のオーバーヘッドが入るので、判定したいオブジェクトが球形状で
判定処理自体が速い場合はもしかしたら遅くなるかもしれない・・・と
自分でも悩んだんだけど、こればっかりは悩んだところでケースバイケースなんでえいやっと実装してみた。
勿論再帰を使わずにループで済ませた。

それともう一つ、マップを構成する凸包も8分木に登録したいと考えていたので
「マップ形状同士の判定は必要ない」という事で
通常のオブジェクト(Obj)とは別にマップオブジェクト(Map)の登録をし、
ObjとObj、ObjとMapは判定するがMapとMapはしないタイプの8分木を上のクラスを元に作った。

更にこれら変数(2D or 3D)、(通常のTree or Map付きのTree)、(分割数)、(固定配列エントリ or ハッシュエントリ)を自在に組み合わせられるようテンプレートにより分離。
この為パラメータがコンパイル時固定となってしまうが
それについてはゲームのリリース前に調整するかもしくは
予め2，3パターン用意しといて適時切り替えればいいだろうとの判断。

後になってバグを出すのは嫌なので自動チェックルーチンも追加。
総当たりで判定した結果と8分木の結果をひたすら比較する。

デモに向けて

• 凹包分割ルーチン実装は後回し。モデラで予め分割しておく
• 早速8分木をエンジンに組み込む。FPS用のコリジョンクラスとして無駄な汎用性は考慮せず専用に作る
• シーン管理クラスは現状維持とし、改良版の組み込みは次回に持ち越し

(2013/01/11)

ぐだぐだ

クラス実装が込み入ってきて同じところで何時間も悩むようだったらいっそ書き直した方が速いのに気づいた。

なかなか、思うように進まない。いつもの事だけど。
Qt5がいつの間にかリリースされてたからそっちに移行してみたり
androidのAPI弄ってみたり寄り道が多いのも変わらず。

そういえばマップの凸包同士の判定は要らないよな？とか
銃弾のような単純な動きしかしないものをわざわざオブジェクトハンドル割り当ててたら遅いじゃん。銃弾管理クラスなんか用意してそこで一括管理したらいいじゃん。とか
当たり判定の通知法は？今まで意味もなく全部Luaに転送してたけどこの辺ちょっと整理してみるか・・
当たり判定の手順をLuaで記述するのも止め止め。確かに柔軟だけど
一個判定したいだけなのに一々フォーマット記述なんてやってられるか！

などなど考えて仕様決めや改良してたらあっという間に日が経ってしまった。
本当、こんなんばっか。1歩進んで3歩下がる状態。
今までこの部分で悩むほどプログラムが出来てなかった訳でもあるんだが、喜んでいいものか・・

(2013/01/02)

抱負

明けまして～とやる気はとうに無くなったので通常運行。
新年の抱負は「結果で示す」「御託を並べる暇があったら物を出す」という事だけど、これ去年にブログかなんかで書いた気がする・・
とにかく去年以上に真面目になる。get serious!

課題

さしあたっての目標は動的影と物理シミュデモのアップロード。
課題はマップとの当たり判定をどうするか？
前に触れたとおりBVHを構築し、詳細はポリゴンで一枚一枚やるのもいいが
折角剛体シミュでGJKを使うのだからマップも凸包に分割できれば
剛体 <-> マップ　間の判定アルゴリズムはGJKだけで済むことになる。
部屋を構成するポリゴンと家具などを別に扱わなくて良いのも大きい。

そんな訳でマップの当たり判定を凸包で統一できないか考えている。

2つの方式

Quake式の（古い例えで申し訳ないが）室内マップだろうが何だろうが長方形のブロックを組み合わせて壁を作っておく物とすれば
各壁は比較的単純な形状になり、凹包の分割方法はさておきそれらを直接コンバートしてやればOKだろうか。
マップエディタがまだ無く現状ではマップはモデラで直接作るしかないのだがquake式だと
壁の外側も少し手を加える関係でちょっと面倒ではある。
剛体の抗力や摩擦力は重なった体積で求めるからブロックを重ねるのも宜しくない。
逆に言えば欠点らしい欠点はそれだけとも言える。

DoomやUnrealのように、本当に内側のポリゴンだけ定義する方式ではどうか？
確かにモデラで作るのは楽になる。無駄なデータも減る。
しかし結局壁を全部凸包にするんだから当然壁の外側へ向けて何らかの方法でエッジを伸ばす感じになり
これも少しアルゴリズムを検討してはみたものの、エッジを伸ばしたすぐ先が部屋だったら？とかの細かいケアが面倒。
だったら最初からマップの作成に制限を課した方が時間的、精神的にも楽だ。

Quake式で行こうか・・

凸包への分割

マップ形式が決まったとなれば残るは凹包を凸包に分割する手段。しかしこれはNP困難らしい。
試しにググッてみたけど探し方が悪いのか、コレといったアルゴリズムが見当たらない。
分割の品質がどうだというつもりは毛頭ないし大体でいいから無いものかねぇ・・
とかボヤいてても進まないので
モデラでポリゴン回しながら昨日考えたアルゴリズムをこれから実装してみる所存。

#追記

凹包を凸包に分割するとポリゴンの具合によって本来は平らな床が複数の凸包で構成される事が十分考えられる。
言い換えれば仮にタイル状に直方体を敷き詰めて床を表現した場合、タイルの境目において抗力や摩擦力の計算で気になる点が。
真上から物が落ちてくる分には全く問題ないが
箱が横滑りしてきてタイルの境目を通過したら個々のタイルにとっては箱が横から衝突した扱いとなり
つっかえるのではないか、と。

暫く考えた後に自分の力量じゃスマートな解決は無理と判断し、放置する事にした。