Discussion

ここは議論の場です。(なるべく削除はせず)自由に追加していって下さい。

システム処理

楽曲情報データベース(songinfo.db)

• 情報の拡充
  • 今のところアイデアなし
• song.dbとマージして、songinfo.db使用は必須にする
  • 動作速度的にどれくらい影響があるか(特に低スペックPC)
• zip/rarのまま楽曲ファイルとして認識
  • 圧縮ファイルへのアクセスはbmorganizerを利用
  • song.db上の圧縮ファイル定義は？
  • 動画BGAはffmpegにファイルパスを渡す関係で一度どこかに展開が必要

ゲームシステム

入力デバイス

• マルチキーアサインについては原則不可としたい
  • 各種同時押し仕込み等の不正につながりやすいため
  • 1入力を複数レーンに割り当てるのについては不正以外の用途が思いつかないので禁止するデメリットはなさそう。一方、複数キーを同一レーンに割り当てるのは一定の需要がありそう（対象固定運指風のキーボード配置や皿に3つ以上のキーを割り当てるなど）。こちらも縦連をトリルに分割するなどややインチキな用途はあり得ますが、同時押し仕込みに比べればマイルドで、不正とみなすかはきわどいところ。
    • いずれにせよ、コントローラー上の回路やキー変換等で同時押しや複数キー分割は実現できてしまうので、こちらでどこまでカバーするかという話のような気がします。もう少し想定シチュエーションを増やして議論した方が良さそう。

プレイゲージについて

プレイオプションについて

• ハイスピの1段階の変化幅が大きすぎるように感じるので、できればLR2のように指定可能にしたい。ハイスピ固定にしているとdurationがゲーム内でうまく変えられなくて困ることが多いので改善したい。選曲画面で設定できるだけでも大分使いやすくなるかも。
• 自動皿アシストはあった方がいいかと思います。特にDOUBLE BATTLEがあるので。アシストオプション画面は7個埋まってしまっていますが…
  • DB皿なしという専用オプションをダブルオプションに追加とか

判定について

• 5keyの判定システムその他
  • GOODでコンボが切れるのは他の本体でもほぼ無く（BM98の時代から主流本体は切れない仕様らしいです）、本家でも相当レガシーな仕様なためあまりメリットがないという意見が多いです。
  • また、これまでに作られた5鍵BMSも基本的に7鍵と同じ判定システムを前提に作られているため、基準が変わるのは良くないと思われます。
  • 例外的にレガシーな要素を入れるには（隠し）プレイオプションや段位の設定でサポートしたほうが良いという意見もあります。
    • 基本仕様として"GOODで切れない" で、 "GOODで切れる"は（隠し）プレイオプションに賛成
      • いわゆる難化オプションになるのでIRとかも特に考慮する必要なさそう
      • FC = パフェコンになるだけ
      • EXスコアにも影響しない
      • 他プレイ形式（7KEYS、14KEYS）にも適用しちゃってもいいかも
• 9keyのみ 某本家様が譜面によってさまざまな判定があるのでそれを参考にRANKによって妥当な判定を導入できると嬉しい
  • 全判定共通 BAD±183ms　空BAD-500ms
    • PMSプレイヤー間での議論、意識のすり合わせが必要と思います。
    • そもそもRANKで実現する話かどうか。DEFEXRANK、およびbmsonのjudgerankとの兼ね合いは？
  • ↑以上の件を踏まえてPMSプレイヤー間で投票を行いました 決定内容です
    • COOL幅は某本家様に2フレ3フレが混在していることから20msで要望 COOL±20ms GREAT±50ms GOOD±117ms BAD±183ms
    • DEFEXRANKに対応するためCOOL幅以外を係数で変動させる案で要望 COOL幅は20ms固定 EASYが基準
    • 別件ですが投票によると9keyのS乱は縦連補正無しがいいようです
    • また、「BADハマリが起きないようになっている」とのことでしたが現在の仕様だと「BADハマリが起きてしまっている」ようですので BAD後もGOOD以上で押し直し可の仕様にしていただけると助かります
    • 投票ログと数値イメージ https://docs.google.com/spreadsheets/d/e/2PACX-1vRH5i2t2nJ47chMpV3qel6TL-hzMAqZppqwWYzDVFXuTJEJTrm6LFEXiV5VQh3p1ScbLFyIn7vOn7hY/pubhtml
    • DEFEXRANK対応数値 VERYEASY 133 EASY（基準） 100 NORMAL 70 HARD 50 VERYHARD 33
    • VERYEASY VERYHARDは某本家様に参考にできる数値が無いので他のBMSプレーヤー本体を参考にしています

その他

• 過去のLunatic Raveにあったオンライン対戦機能の復活

スキン

スキン仕様について

• 機能の拡充(JSONスキン)
  • ノーツの高さが一様でない場合も必ず下端が揃うように降ってきますが、ノート画像ごとに中心点のようなものを指定してそれを基準に揃えるようにしたいです。（例：キーボードのホイール、ドラムのフットペダルなどをいい感じに表示したい）
    • 現状の仕様のままでも、空白を入れて無理やりノーツの高さを揃えたうえで判定ラインを下げるというハックは可能ですが…
• LR2との互換性
  • 判定カウント数値がPOORとMISSで別れており、空プアを出してもLR2スキンではPOORが増えないように見えるので、いい感じに見えるようにしたいです。（例えばLR2互換のPOOR値はPOOR+MISSとし、見逃しPOORのみの数値は別にするなど）
• 9KEYS関連
  • 0.5.4現在、実装済みPMS関連定義
    • 3列判定
      • LR2スキン:NOWJUDGE NOWCOMBO 1P 2P 3Pがそれぞれ左から順に対応 NOWJUDGEではindex:6でゲージMAX時の虹色COOLの定義
    • TIMER
      • コンボ用TIMER(1列のみ表示するため) 446:左 447:中央 448:右 (LR2スキンではNOWJUDGE_3Pまで記述した時のみ正しく動作)
    • DST_OPTION
      • 各判定の数が1以上(ジャッジカウンター,パーフェクト演出分岐用) PG:2241 GR:2242 GD:2243 BD:2244 PR:2245 MS:2246
      • ゲージがボーダー以上 1240
      • EARLY 左:1242 中央:1262 右:1362
      • LATE 左:1243 中央:1263 右:1363
    • GOOD用のボムタイマー
      • LR2スキン:「#JUDGETIMER,(判定しきい値)」を記述することでボムタイマー(50-69)が発動する判定を変更。指定した判定以上で動作 0:PG 1:GR 2:GD 3:BD 4:PR 5:MS
      • JSONスキン:"judgetimer":(判定しきい値)
    • 見逃しBADの時ポップ君が落ちる演出
      • LR2スキン:#DST_NOTE2,(ノートが消える位置のy座標)
      • JSONスキン:"note":{dst2:(ノートが消える位置のy座標)}
    • LN時キービームオフ
      • 透明な画像を用意し、VALUE_JUCGE_xxx(501～509)で設定
      • VALUE_JUCGE_xxxの値対応 0:判定無しor未設定 1:PG 2:E GR 3:L GR 4:E GD 5:L GD 6:E BD 7:L BD 8:LN時 9:欠番 10:E MS 11:L MS (E=EARLY L=LATE)
    • リズムに合わせて(4分のタイミングで)ノートが大きくなる演出 w,hをそれぞれ幅、高さの最大拡大率(%)として
      • LR2スキン:#DST_NOTE_EXPANSION_RATE,w,h
      • JSONスキン:"note":{"expansionrate":[w,h]}
    • 曲終了後からフェードアウトを開始するまでの時間指定
      • LR2スキン:#FINISHMARGIN,(時間ms)
      • JSONスキン:"finishmargin":(時間ms)
    • ゲージの現在粒が明滅する演出
      • LR2スキン:「#SRC_GROOVEGAUGE_EX,index,gr,x,y,w,h,div_x,div_y,cycle,timer,add_x,add_y,parts,animation_type,animation_range,animation_cycle」を用いてanimation_typeを3にし、表赤、表緑、裏赤、裏緑、EX表赤、EX表緑、EX裏赤、EX裏緑、発光表赤、発光表緑、発光EX表赤、発光EX表緑の順にsrc分割する。partsはゲージの粒数、animation_cycleは明滅の1周期の時間(ms)
      • JSONスキン:"type":3、"cycle":(1周期の時間)とし、上記の順番で"nodes"を指定
    • ぽみゅキャラ(*.chp)
      • LR2スキン:
        • #DST_PM_CHARA_1P,x,y,w,h,color,offset,folderpath : プレイ用キャラ定義(判定連動) colorは1で1Pカラー、2で2Pカラーがあれば2Pカラーなければ1Pカラー
        • #DST_PM_CHARA_2P,x,y,w,h,color,offset,folderpath
        • #DST_PM_CHARA_ANIMATION,x,y,w,h,color,animationtype,timer,op1,op2,op3,offset,folderpath : プレイ以外用キャラ定義(判定非連動) typeは0:NEUTRAL 1:FEVER 2:GREAT 3:GOOD 4:BAD 5:FEVERWIN 6:WIN 7:LOSE 8:OJAMA 9:DANCE
        • #SRC_PM_CHARA_IMAGE,color,type,folderpath : キャラの各種画像 SRC_IMAGEのように使う typeは0:キャラ背景 1:名前画像 2:ハリアイ画像(上半身のみ) 3:ハリアイ画像(全体) 4:キャラアイコン
        • #DST_PM_CHARA_IMAGE : DST_IMAGEと同様の書式
      • JSONスキン:
        • "pmchara":[{"id": , "src": , "color": , "type": , "side": }]
        • typeの値対応 0:プレイ 1:キャラ背景 2:名前画像 3:ハリアイ画像(上半身のみ) 4:ハリアイ画像(全体) 5:キャラアイコン 6:NEUTRAL 7:FEVER 8:GREAT 9:GOOD 10:BAD 11:FEVERWIN 12:WIN 13:LOSE 14:OJAMA 15:DANCE
        • sideはtypeが0の時のみ有効 1:1P 2:2P
        • dstの複数time指定はtypeが1～5の時のみ有効
      • #CUSTOMFILEにおいて、ファイルパスに「*|識別文字|」とすることで同一フォルダをソースに1P、2P別々に定義可能(defaultスキン参照)
      • フォーマット説明1:https://web.archive.org/web/20150219203833/http://storyof.namidaame.com:80/yy_pce.htm
      • フォーマット説明2:https://web.archive.org/web/20140219123749/http://storyof.namidaame.com/yy_tec.htm
      • フォーマット説明3:https://web.archive.org/web/20090502223140/http://storyof.namidaame.com:80/yy_tec'.htm
      • ぽみゅキャラファイル内の新設定義
        • 位置・サイズの定義番号で36進数を使用可能
        • 「#SelectCG2P」追加
        • 「#CharFaceUpperSize x y w h」「#CharFaceAllSize x y w h」を記述することでハリアイ絵の切り取り位置・サイズを指定可能(256×256、320×480より大きい解像度を使用したい場合用)
  • 0.5.5実装予定(masterには実装済み)
    • プレイ画面におけるリアルタイムでのノートチャート表示
    • BARGRAPH版マイベスト/ターゲットEXスコアとの差分
      • LR2スキン:NUMBER値参照版BARGRAPHを用いる「#SRC_BARGRAPH_REFNUMBER,(NULL),gr,x,y,w,h,div_x,div_y,cycle,timer,type,muki,min_value,max_value」
      • JSONスキン:"graph"に"isRefNum":true,"min":(最小値),"max":(最大値)を追加で記述することでNUMBER値を参照可能

その他

実装済

• ユーザー指定によるスキンイメージのオフセット定義
• 判定幅補正オプション-JUDGE WINDOW RATEの追加(EX JUDGEは廃止)
• LR2ゲージの段位(コースのconstraintに"gauge_lr2"を指定することで可能)
• 複数デバイスを跨いだキーアサイン(これに伴い、選曲時に使用したデバイス以外を無効化する仕様は廃止)
• JSONスキンでの読み込み時条件分岐・includeコマンド