生身FPS

先週末にサバゲーしてきました。
人生初サバゲー。

平林にそれ専用の場所を提供してくれるお店があって、
貸し切りで夜中から明け方まで遊んでました。

お店は場所を貸して終わりって訳ではなくて、
「ロビーでは弾(玉？)を装てんしちゃイカん」とか
「ゲームスペースから完全に出るまで保護マスクを
絶対取っちゃダメ」とか、安全面に関してかなり神経質に
指導してました。

レンタルの拳銃でやってたんですが、こっちの弾は全然
当たらんくて、バシバシ撃たれました。

使ってよい銃の制限があり強すぎるのは持ち込み禁止なん
ですが(レンタル銃も当然制限内)、当たると服の上からでも
地味に痛え。

最初は徹夜とか無理だろと思ったんですが、実際やると
あっという間に時間が過ぎてしまいました。

いやー、楽しかった。

久しぶりに運動しました

某社のフットサルクラブに参加してきました。
ジムもさっぱり行ってなかったし、そもそもボールを
蹴るなんて何年ぶり？みたいな感じです。

どうなることかとドキドキしましたが、まあそれなりに
動けたようなそうでないような…。

楽しかったので今度のためにちゃんとした靴を
買おうかなとか思っています。ちなみに今、ふとももが
パンパンに張って痛いです。

ブレイブルーのロケテを見た。

かなり前なのに今頃感想。

ギルティーにおいても感じたのだが、キャラが何をしているのか
よくわからない。今作ではそれよりも解像度・アニメーションの
枚数が増えているにもかかわらず。

少なくとも自分の動体視力では、絵が切り替わったなーという
くらいしか分からない。攻撃判定がどういう軌道で出現するか、
とか、体重が乗っているかどうか（→隙の大きい技か）が情報
として得られない。

でも、ゲームデザイン的にそんな細かいことどうでもいいという
スタンスかもしれない。もしくは直感で技の性能を感じるのでは
なくて、絵そのもの（≠ 挙動・モーション）と性能を結びつけて
暗記しましょう…ということかもしれない。

--------------------------------------------

あとひとつ、技コマンドにも気になる点がある。

あのゲームは [弱・中・強・特殊] というボタン配置になって
いる。そして必殺技は例えば [何かレバーコマンド＋弱中強] に
よって、段階（より速いとか、遠くに届くとか）が変化するのを
直感的には期待するのだが、実際は [＋弱のみ] [＋中のみ] …
という感じにボタンが違うと何も技が出ないというのが多い。

そんなの覚えればよしというのは確かだが、まず基本となる
コマンドの法則みたいなものを覚えたら他のまだ知らない技の
出し方も大体想像がつくようにしておいた方が、導入としては
親切な気がする。

初めて格ゲーをやるようなひとにとっては、技が出ないとき
レバーコマンドが違ったのか、またはボタン違いなのかという
ふたつの失敗原因を探すのは大変だろう。

そういった点を踏まえると、このゲームは新規のプレイヤーや
他の格ゲータイトルからの乗り換えをあまり意識していないの
かもしれない。

ビジュアルのキャッチーさなどはかなりあるように思えるので
今回挙げたようなゲーム文法に反する点がすごく勿体無い。

Battlefield Bad Company

フライングゲッツしました。
しかし、たしか Halo3 か何かで発売日前のゲーム起動を
察知すると Live! のアカウントがバンされたとか言う話を
どっかで見たことあるので遊ぶのは躊躇してしまう。

それにしても洋ゲーは戦争ものゲームばっかりですな。
あまりにも神経質に「暴力ゲームは諸悪の根源！」とばかり
言うのは思考停止だとは思いますが、ゲームという媒体を
考えるとき、もっと幅があってもいいと思うのです。

いやゲームプレイとしての FPS は大変楽しいのですが。
もっとジャンル判定不能なゲームがじゃんじゃん出ないと
尻すぼみになってしまいそうで恐怖を感じます。

* 判定不能っても「世界を救う RPG」とかじゃないよ

Gamefest 資料のメモ

DirectX SDK の新しいのが出ていたので落としに行ったら
Developer Center に Gamefest のプレゼン資料があったので
気になる部分をメモしておく。

気になるところを抜き出しただけ AND 誤りもあるかも…
なので直接資料を観るのがベター。
[ Sublime C++ For Games ]

-----------------------------------------------

o VC 2005 は可変長引数マクロが使用可 (知らんかった)

o RAIIを使え(例外を利用するかどうかによる)
  * RAII = リソース獲得は初期化である [参考リンク]

o 例外の性能ペナルティーは 1-5%
    o コンソールでは無効にすることを考える
    o デバッグモードだけで利用することを考える

o unordered_set/map は set/map より早い
    o 最悪のケースにおいてだけ遅い

o node-based なコンテナ(list,map,set,multi_xx)はやめよう
    o unordered_xx の方がマシ

o 関数の引数に、コンテナでなくてイタレータをとる
o インデックスの代わりにイタレータ
o shared_ptr の利用を考える

o ポインタのエイリアシング

void Add( float* dst, const float* p )
  for ( int i=0; i < n; ++i ) dst = *p + 1.0;

o 上記のような関数はコンパイラの最適化を阻害する
o "p" が "dst" を指すかも → ループ毎にリロード → :-(

o 仮想関数は便利だが、コストはかかる(360では特に)
    o いかついコード内では使わない
    o プラットフォームの区別に利用しない

o アロケーションはコスト高
o 経験則: ゲームループ内でアロケート禁止
o カスタムアロケータ導入を考えてみる

o ベクトルを struct vec { float x,y,z,w; }; ってするのはダメ
o ネイティブな型を使え
    o Xbox 360 : __vector4 / XMVECTOR
    o Windows : __m128 (D3DVECTOR をコアなコードに使うな)

Lua 再び、その後 or 続き

昨日のやつ解決しました。

Lua を実行したとき、その Lua から逆に呼び出し元にあたるクラスの
メンバ関数をコールしているところでこけていたようです。

Lua からコールされる関数は、アクセッサみたいなものなんですが
Lua にアタッチするために static になっていて、当然メンバ変数に
アクセスできません。

そこで "C++ → Lua" でコールするとき this を渡し、"Lua → C++"
でコールすときにはさっきの this を渡すようにしています。ただし
Lua はクラスの型なんか感知しないので void* に変換されます。

なので、static なアクセッサはキャストを行います。

MyObj::func_for_lua( void* sender)
{
    MyObj* self = (MyObj*)sender;
    return m_Number;
}

…で、ながーい前置きのあと話を昨日に戻すと

子オブジェクトは機能的にはサブセットになっていて、
生成元のスーパークラスです。けど共有する Lua ステートには、既に
サブクラスのメンバ関数がアタッチされている訳です。

そりゃまあ、何が起きてもおかしくありません。
という訳でクラス設計がまずかったようです。
そんな大げさに手を入れずに綺麗に収まりそうなのを確認して
今日は帰ってきました。

Lua 再び

世間じゃ連休だっていうのに仕事しています。

あるキャラクターに従属する子オブジェクトを生成するとき
ステートを司る Lua スクリプトを共有するようにしました。

…が、その子オブジェクトを破棄するときに落ちます。
エラーメッセージは「ヒープが壊れている」云々という無愛想な
もので原因を探すのに手間取っています。

ちゃんと "lua_newthread"でスタック(Luaが独自に提供するもので
一般的な C のスタックではない)を確保しているんですけどねえ。

全く同じキャラクターが同じ場面に登場したときも、同じ仕組みで
リソース共有してるんですがこちらは問題なし。謎だ。