| タイトル | ： Re^3: 新機能要望 |
| 投稿日 | ： 2014/09/18(Thu) 04:03:28 |
| 投稿者 | ： 管理人 |
| 参照先 | ： |
いろいろ細かくありがとうございます。
フローティングに関してはスキン実装までお待ちください。
※以下の実装より先に行う予定です
空POORについてですが、まず現状のプログラムの詳細を説明しますと、
オブジェクトの判定は以下の通り、オブジェの時間を中心に叩いたときの時間の差がどのくらいかで判定されます。
http://www.charatsoft.com/develop/otogema/page/08main/img/hitarea4.gif
（実際にはカウント値の範囲で判定しているのではなく、テンポにより判定範囲はリアルタイムに変化します）
現在のプログラムはこの画像のBADのさらに外側に空POOR領域というのがあり、
その間に叩いてしまうと空POORが発生するようになっています。
現状この空POOR領域は極端に狭くなっており、およそ3フレーム(50ms)しかありませんので、
実は空POORを出す方が難しいかもしれません。
さて、例えば1つ目と2つ目がものすごく近い位置にあったとして、1つ目を見逃して2つ目を叩こうとした時に、
1つ目と2つ目の判定領域が重なっている場合は先に1つ目が判定されてしまうため、
結果的にBADなりPOORになってしまいます。
こちらのゲームではBADならば判定済みとなりますが、POORでは判定済みにはならない設定になっており、
もしPOOR範囲が広かったとすると、さらに次の3つ目や4つ目などの連続したオブジェがあって、
その3つ目や4つ目を叩いたつもりでも、まだ判定が残っている1つ目のオブジェが判定されてしまうため、
結局は1つ目のオブジェでBADが出るまでPOORが発生することになります。
その後ようやく1つ目がBADにより判定が終了して、次の2つ目の判定が始まりますが、
やはりこれもズレているため同じくBADが出るまでPOORが出ます。
そして3つ目や4つ目以降のオブジェも同じく前のオブジェを判定してしまうため、
結果的に連続オブジェが終了するまでPOORやBADが続き、いくら頑張ってもGOOD以上の判定になることはありません。
AC版では恐らくこれがBAD嵌りに繋がる仕様なのではないかと思います。
現状はこの空POOR範囲を狭くすることで、連続オブジェで前の判定が残っているオブジェがあったとしても、
すぐに範囲外になるため連続ミスにならないようになっています。
ちなみにAC版の空POORについては、これとはまた別な処理を行っているような感じがします。
例えば1つのオブジェが降ってくるとして、これを判定が入る少し手前から連打してみると、
そこからずっとPOORが連続で発生すると思います。
まだ判定バーより手前(上にある状態)であれば、こちらのゲームと同じくPOORなりBADが発生しますので挙動は似ていると思いますが、
違いはオブジェが過ぎたあと既にオブジェは存在していないはずなのに、ある一定時間POORが出る時間が存在することです。
これはボタン押下1回目でGREATを出した場合でも同じで、そこからすぐに連続でボタンを連打すると
その後は空POORが何度も発生するのが確認できます。
（もっと簡単な例では、1つのオブジェに2回パチパチっとボタンを押してみればPKGREAT→POORが見れます）
これはつまり、POOR判定だけはオブジェの判定が終わった後も続いているということだと思いますが、
同じ挙動を実装するとなると現状は難しいかと思います。
この辺りも含め、もしAC版の内部仕様をご存知でしたら詳しく教えていただければ助かります。
そこで代案ですが、密集地帯をとりあえず全部押せば突破出来るというのは、
恐らくGREATなりGOODの範囲が広いからではないかと思われます。
ですのでGOOD以上のトータル判定時間を減らし、その分BADやPOORを増やすことで調整出来るのではないかと思います。
○現状の設定は以下の通り（PKGREATの真ん中を判定の中心とする）
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
←未判定｜POOR｜BAD｜GOOD｜GREAT｜<PKGREAT>｜GREAT｜GOOD｜BAD｜POOR｜未判定→
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
判定範囲の時間
PKGREAT : 約38ms
GREAT : 約48ms
GOOD : 約83ms
BAD : 約33ms
POOR : 約50ms
※現在はPC遅延を考慮して若干ゆるい設定にしています
(例えば30fpsしか出ないPCでは1フレームが33msとなりPKGREATを出しにくいため)
次に#LNOBJですが、認識に間違い無いということで安心しました。
いろいろ調べていただいたようでお疲れ様です。
まとめますと以下のような感じでしょうか。
①10、20番チャンネルでは終端として使用（本来の#LNOBJの仕様通り）
②50、60番チャンネルでは#LNOBJは無視され、常に2つの組で開始と終端を定義(50、60番チャンネルの仕様通り)
③それ以外は基本的に記述ミスとしてエラー扱い
・10、20番と50、60番チャンネルで開始と終端が混在した場合
・10、20番で#LNOBJのオブジェを開始位置に配置した場合(そもそも#LNOBJは「終端」のはず)
④10、20番で定義したロングと50、60番で定義したロングがかぶっている場合は自動補正(ワーニング出力)
・最終的にデータを整理する時に、ロング内にオブジェがあったりすると現状自動的に削除されるが、
同じくロング内にロングがあった場合も削除して整合性を取る（本来はエラーだが既に機能があるので）
ひとまずこれなら実装は出来るかと思います。
なおcharatbeatHDXの独自機能として開始と終端のオブジェIDが異なる場合は、終端成功時にその音が鳴るという仕様がありますが、
これは10、20番チャンネルには適用しないという形にしたいと思います。
あと50、60番チャンネルで#LNOBJのオブジェが指定されている場合は鳴らしてもよい気がしますが、
#LNOBJは#WAVのIDを特殊な用途に変化させるというというイメージなので、
いっそのこと#LNOBJのIDの音は常に鳴らさないと統一した方が分かりやすくてよいかなと思います。
（例えば10番台チャンネルで#LNOBJを使ってロングを定義したとして、
これをそのまま50番台チャンネルに移動しても#LNOBJにより終端の音は出なくなるため、
結果的に10番だろうが50番だろうが同じ動作になるという利点がある）
このような仕様で問題が無いか、精査していただければと思います。
- WebForum -