FPSを作ってみる@wiki
08)
最終更新:
slice
-
view
(2009/08/14)
突然こんなマジ話されても困るとは思いますが。
このゲーム製作、本当にやり遂げられるのか?最近ちょっと自信ないです。
下らんエラーでずっと躓いてたり、資料を見ても理解の遅い自分に対して苛立ちを覚えるわけです・・
このゲーム製作、本当にやり遂げられるのか?最近ちょっと自信ないです。
下らんエラーでずっと躓いてたり、資料を見ても理解の遅い自分に対して苛立ちを覚えるわけです・・
(2009/08/12)
とりあえず前回からの作業
- 視点の揺れ方の調整
- 銃が壁にめり込んでしまう問題の修正
- 自前リストボックスのマウスホイール対応
ちょっと前から薬莢、薬莢と連呼してる気がしますが
実装が完了するまでこれからも連呼しますよ。
確認したら質量等初期パラメタはちゃんと計算できてそうだ。
そしたら撃力の計算がどこか間違ってるとしか考えられないので今夜はそれを重点的に調べるか。
havokとかのライブラリに頼らず一度やってみたいのでそういう事でひとつ。
実装が完了するまでこれからも連呼しますよ。
確認したら質量等初期パラメタはちゃんと計算できてそうだ。
そしたら撃力の計算がどこか間違ってるとしか考えられないので今夜はそれを重点的に調べるか。
havokとかのライブラリに頼らず一度やってみたいのでそういう事でひとつ。
(2009/08/10)
デバッグが思うように進まないので、えいやっとばかりに当たり判定を可視化してみた。
今の所対応しているのは球と線分とカプセル判定だけだが
近いうちにボックスとシリンダも追加したい
Z判定で隠れてしまう部分は3フレームに1回の間隔で表示したり隠したりすると
壁の向こうに隠れているのかどうか判別がつくし隠れてても見えるしで一石二鳥だ。
このアイデアはグラディウスVをやっている時に閃いた。
というかオプションが壁にめり込んでいる時の表示処理まんまである。
今の所対応しているのは球と線分とカプセル判定だけだが
近いうちにボックスとシリンダも追加したい
Z判定で隠れてしまう部分は3フレームに1回の間隔で表示したり隠したりすると
壁の向こうに隠れているのかどうか判別がつくし隠れてても見えるしで一石二鳥だ。
このアイデアはグラディウスVをやっている時に閃いた。
というかオプションが壁にめり込んでいる時の表示処理まんまである。
で、色々動かしていると一瞬しか出ない当たり判定は暫くその場に表示されるようにしたいな、
判定の移動した軌跡が出ると便利だな~とか機能を増やしたくなるわけですね。
これら実装予定なんですが。
判定の移動した軌跡が出ると便利だな~とか機能を増やしたくなるわけですね。
これら実装予定なんですが。
(2009/08/05)
当然というか何と言うか弾丸の着弾地点が正確に分からないとデバッグに支障をきたすので
予定には無かったレーザーポインタを追加した。
あとは・・マウスカーソルを自前のグラフィックに変更するのに手間取った。
カーソル表示と非表示の切り替えが上手くいかなくてねー
Win32APIとDirect3DがShowCursor()という同名の関数を備えているんだけど、どっち使っても反応なしで。
どうやら原因はメインウィンドウを作成したスレッドで呼ばないと効果が無いという事だった。
MSDNを検索しても書いてなかった気がするが・・・?もしや常識なのか。
(ちなみにWin32APIとDirect3Dの関数はどちらでも効果は同じ様だ)
予定には無かったレーザーポインタを追加した。
あとは・・マウスカーソルを自前のグラフィックに変更するのに手間取った。
カーソル表示と非表示の切り替えが上手くいかなくてねー
Win32APIとDirect3DがShowCursor()という同名の関数を備えているんだけど、どっち使っても反応なしで。
どうやら原因はメインウィンドウを作成したスレッドで呼ばないと効果が無いという事だった。
MSDNを検索しても書いてなかった気がするが・・・?もしや常識なのか。
(ちなみにWin32APIとDirect3Dの関数はどちらでも効果は同じ様だ)
カーソルのグラフィック、これも良くわからん仕様だ。
サイズは32x32でほぼ固定みたいだがαチャンネルを滑らかにグラデーションさせても
DirectX側では2値化されてしまうし。
条件がわからないがαチャンネルの状態によってはカーソルが16x16(もしくは16x32とか変なサイズ)
勝手にリサイズされて潰れて表示されたり。試したフォーマットはTGAとPNG。
とりあえずカーソルのαは2値にしとけば不具合は起こらないので、そうしておいた。
サイズは32x32でほぼ固定みたいだがαチャンネルを滑らかにグラデーションさせても
DirectX側では2値化されてしまうし。
条件がわからないがαチャンネルの状態によってはカーソルが16x16(もしくは16x32とか変なサイズ)
勝手にリサイズされて潰れて表示されたり。試したフォーマットはTGAとPNG。
とりあえずカーソルのαは2値にしとけば不具合は起こらないので、そうしておいた。
そんな感じで時間食ったな。
次にやる事は薬莢が転がる処理。
なるべくリアルにしたいが剛体シミュレーションをやるのは大げさだ(技術も無いし)
かといって床をすり抜けてそのまま落ちてくのも芸が無い。
そう思いそれらの中間とったような適度に跳ねるアルゴリズムを考えてみたのでこれから実装する所存。
なるべくリアルにしたいが剛体シミュレーションをやるのは大げさだ(技術も無いし)
かといって床をすり抜けてそのまま落ちてくのも芸が無い。
そう思いそれらの中間とったような適度に跳ねるアルゴリズムを考えてみたのでこれから実装する所存。
(2009/08/01)
主人公の挙動を全然作ってなかったので色々と補強している
今は斜面を歩くときはY座標を足元のポリゴンの高さにあわせるだけの実装なのだが
これだと急な斜面を登る時に速度がグアァッと上がる
具体的には斜面の角度を45度とすると横に1進んだら上にも1進む事になるので速度は√2≒(1.41421356...)になり
いくらゲームとは言えこれは変だ
今は斜面を歩くときはY座標を足元のポリゴンの高さにあわせるだけの実装なのだが
これだと急な斜面を登る時に速度がグアァッと上がる
具体的には斜面の角度を45度とすると横に1進んだら上にも1進む事になるので速度は√2≒(1.41421356...)になり
いくらゲームとは言えこれは変だ
というわけで斜面上の移動距離が1になるような倍率を掛ける処理を追加。
やる事は単純だが加えてある程度の段差、主に階段では視点を上下にガクガクせずに移動できるようにすると
それなりの行数になりそうだ。
他にもやる事が沢山あるので地道に実装していきますか・・
やる事は単純だが加えてある程度の段差、主に階段では視点を上下にガクガクせずに移動できるようにすると
それなりの行数になりそうだ。
他にもやる事が沢山あるので地道に実装していきますか・・