せっかくなのでとことんレスします。
変更するにあたって、根本的な理由を教えてください。
個人的な、と仰っているのに「変更を施してくれれば」というのは少々言葉を間違っている気がします。
つまり何がいいたいかというと、ickw_284さんの要望・チケットには明確な理由が書いてありません。
例えばこちらの案件の場合、「達成率の計算式が変わることによって1曲1曲に対してのモチベーションがあがるため」など、
言葉を探せば見つかるはずです。
とりあえずこうして欲しいからよろしく、的な要望は(最初は見逃すかもしれませんが)非常に高圧な印象を受けます。
相手がどう思うかを考えて発言したり行動していただくようにお願いしたいです。
とここまで書きましたが、達成率計算式変更には反対です。
理由はコンボが切れた瞬間にエスケープ、というような行為（リスキー的なｗ）をして欲しくないからです。
「その行為が増える」保証はありませんが、リスキーの実装を望む＝そういうこと だと思ってます。
実際途中エスケープは作曲者側からすると少々寂しい気分になります（笑
強いて言うなら、わざわざ変えるまでもないというのが自分の意見です。
from まあ、メンバの興味がわかないチケットはさっくり無視されてしまうというのもオープンソースの怖いところではあるんですけどね。
SourceForge.JP の運営自体を見てもそうですけど、チケット全部に必ずしも全レスしてないんですよね。
理由は書いてあった方が分かりよいですが、特に興味がなければ放置という選択肢をとるのも良いのでは。
プログラマがチケット発行して自分で勝手に実装を進める場合はちょっと問題ですけど。
で、達成率についてですが、今の DTXMania では、「演奏型スキル」と「ゲーム型スキル」の2種類の達成値を計算し、.score.ini に出力しています。
そして今は、「Combo なんぞスキルに関係なかろう（常にフルコンして当たり前 or 1,2回ずれるのも当たり前）」という方針で、選曲画面には「演奏型スキル」を表示するようにしています。
これは、プロの歌手がカラオケの採点機能で常に100点を出せるか否か、という議論にも似ていますね。
以上が、現在の DTXMania の、達成率に対する Combo の方針です。
よろしければ、ickw_284 さん他の方針もお聴かせ下さい。
今更「計算式が変わることによって…」を肯定しても単なるオウム返しとしかならないし…、でも「Comboなんぞスキルに関係なかろう」との方針には肯定しかねます。
現状本家プレイヤーのレベルが上がった故（常にフルコンして当たり前 or 1,2回ずれるのも当たり前）の選択と考えられ、また正確に演奏して欲しい(グレグドでボロボロになるより切れてもいいからパフェ出して欲しい)との意図も考えられます。
ただパフェが安定しない初級者層の人では繋ぐので精一杯になってしまってどうしてもパフェが低くなり、パフェ重視の現計算式ではスキル率が芳しくない結果になってしまいます。
やはりパフェ率が安定しないプレイヤー層への配慮として、スキル式にコンボを絡めるべきだと思います。(ちなみ現DTXの計算式で…P90%でバシバシ切った場合SKILL90%、P80%で繋いだ場合SKILL80%)
要するにDTXスキル計算式のコンボに対する姿勢は、「切れてもパフェが高ければそこそこの達成率、パフェ低くても繋げればそこそこの達成率」
上の意見が自分のcomboに対する方針となります。
(以下閑話)
inanickさんの厳しい言及を読む辺り、最初に比べてチケットに対する敷居が上がってきたのは確実ですね、
ただ案を出せば良いのではなく明確な理由やユーザー目線での考慮、さらには実装した後の反応まで考えない、と
当たり前すぎたのにそれすら実行出来てない自身に不甲斐なさを覚えます。
以前、特に初期辺りはチケットを気軽に発行できて、メンバーも大体は良い方向に持って行こうと善処してくれました、
ただ今回の否定意見を受けて自分はこのSFFの仕様や皆さんの意見に甘えすぎた、としか申しようがありません。
思えば自分の言動は幼稚だったと、云わば強請れば何でも買ってもらえるガキだったと、そう客観視されてたかもしれません、
だから今日のikanickさんの(有難くも痛い)意見を受けて、本当に猛省しております。
(閑話休題)
上記の反省に従った結果…
・実用性、ユーザー目線を重点的に置く
・気軽に、とは言われてるけどチケット投稿は慎重に
・場合によってはチケットageも兼ねて明確な理由を書き足してみる
以上を踏まえて今後実用的な案を登録していこうと思います。
#御本家が脚本家に空目
「パフェは低いが、つなげられる」という状況は、どうもしっくりこないのですが・・・
それはさておき。
まず、コンボに対しては、そもそもそんな概念は不要というのが私の考えだったりします。 「私個人は」これ、ゲームとしては見てないので。 大体同じ1missでも曲の真ん中の1missか最後の1missかでスコアやらスキルやらががらっと変わるというのが納得できないのです。
チケットに対しては・・・
で、「ゲーム型スキル」として現在 score.ini に記録している値の計算式は
(Level/2) * ( Perfect率 * 0.8 + コンボ率 * 0.2 )
のよう(CScoreIni.cs 1154行目)なのですが、 これを提示いただいた式に変えつつ、更にユーザーがゲーム型スキルと演奏型スキルのどちらを画面表示するかを選べるようにする、 ってあたりが落としどころでしょうかね。
おっと、この落としどころを使うなら、もう一つ、score.iniに[HiPlaySkill]？なHiSkill記録を追加しないといけないでしょうね。
PERFECT率=達成率の現状なら、いっその事SKILLは廃止した方がいいと思いましたが…
>ユーザーがゲーム型スキルと演奏型スキルのどちらを…
こうなったら両方表示するのもありかと思いました、ゲーム型スキルにグレ率を加味した"SKILL"(親記事の計算式と殆ど同じ)と
演奏型スキルからコンボ要素を一切廃止して、パフェとグレグドを重視した"EXACT"
これならコンボに拘らない人も繋ぐのに拘る人、双方から見てあまり文句は出なさそうですが…(ただリザルトを弄らないと表示出来ないが)
#選言チョイス間違ってたら言ってね(; 特にEXACT
>HiPlaySkill？なHiSkill記録
どういう意味でしょうか？
from こうなったら両方表示するのもありかと思いました、ゲーム型スキルにグレ率を加味した"SKILL"(親記事の計算式と殆ど同じ)と 演奏型スキルからコンボ要素を一切廃止して、パフェとグレグドを重視した"EXACT" これならコンボに拘らない人も繋ぐのに拘る人、双方から見てあまり文句は出なさそうですが…(ただリザルトを弄らないと表示出来ないが)
我々身内の間では、
の更新有無で上達を判断する、暗黙のルールができてしまいました。（汗
たまには Score たんのことも思い出してやって下さい……
HiPlaySkill？な HiSkill記録
どういう意味でしょうか？
とりあえず指標を確かにする為、ある程度仕様を纏めておきました。
・スキルタイプは2つ、HiPlaySkill(ゲーム型スキル)とHiSkill(演奏型スキル)
・OPTIONでリザルトのスキルタイプを変更可。大項目はCOMMON内で、項目名はSKILL TYPE
・要するにゲーム全体のスキルタイプを変えることになる。
・score.iniにはHiScore,HiPlaySkill,HiSkillの3つが記録される
・OPTIONで選んでない方のスキルも、更新されればちゃんと記録される
・HiPlaySkillの計算式→PERFECT率*0.8+GREAT率*0.3+COMBO率*0.2
・HiSkillの計算式→PERFECT率*1+GREAT率*0.4(だっけ？誰か正しい計算式教えてください；)
・スキルメーターの引用元も選択された方に順ずる
とりあえず以上です、抜けがありましたら連絡願います
大体いいと思います。以下簡単ですがコメントします。
>HiPlaySkillの計算式定義は・・・結局本家に合わせるってことですね。
恐らくその様になります。
>HiSkillの計算式は…
このタイプの計算式は上からの引用とします、要するに従来の算出方式と一緒になります。
>対応の難易度は高くないと思いますのでどなたかにお任せします。
自分はソースが全く分からないんで、ここはやぎさんにお願いします；
ickw_284さん
以前作っていたサンプルを晒しますので、動作確認していただけないでしょうか。
tp://yyagi.com/DTXMania090_Test_23624.zip
CONFIGURATION/System/SkillPointType で、演奏型とゲーム型のSP表示を切り替えます。 (score.iniファイルには常時両方のSP値を記録します。)
注意:
あれ？ 正常に切り替えられてませんよ？
{{ 例えばこのリザルトの場合 Perfect=944 Great=13 Good=1 Poor=0 Miss=0 MaxCombo=958 TotalChips=958 playskill側は98.99だが、skill側は36.07になってしまう }} やはり計算式の切り替えにミスがあるのか、それともMAXコンボとの兼ね合いが悪いのか…
一度確認お願いします。
from あくまで個人的な意見ですが、
スキル計算式からコンボを外しているのは長らくの仕様変遷の結果ですので、戻すならゲーム型スキルのほうだけにして欲しいです。
本家の計算式は、コンボをつなぐほどスキル値が高いと見なされるなど最悪のバランスです。
それでも納得いかない人のために演奏型スキルとゲーム型スキルが分かれた歴史がありますので、両者の意味を考え、混同しないようにして下さい。
と考えます。
オープンソースにしたのですから、本家にこだわる人はブランチを作って自由にやって下さい。
仕事で午前様だったもので、今日はこれだけ。
ickw_284さん
すみません。ゲーム型スキル値の計算式を変えてませんでした(表示切り替えロジックだけで手一杯でした)。コメントいただいたリザルトだと、旧ゲーム型スキル値の計算でLv=73の時にぴったり合うかと思います。
tp://yyagi.com/DTXMania090_Test_23634_2.zip
ご指定の式に変更しましたのでお試し下さい。重ね重ね、score.iniの事前バックアップをお忘れなく。
fromさん
あーすみません。ご機嫌斜めな理由が分かりました。
このチケット内では私自身PlaySkill＝ゲーム型、Skill＝演奏型と混同していました。正しくは逆ですね。
# でもscore.ini内だとHiSkill＝演奏型なので混乱するんですよ・・・。
実際には、プログラムの方ではゲーム型スキルの方しかいじってませんし、また演奏型スキルの方はいじる余地無しと理解しておりますので、ご安心下さい。
なお個人的には、ゲーム型スキル値の方は計算式をbox.defか何かで外部定義できるようにしてしまってもいいと思ってます。
申し訳ないですが、既存iniからだと正常に再計算されてないようです。
ただ新規プレイだと正常に計算出来てるみたいです。
from > このチケット内では私自身PlaySkill＝ゲーム型、Skill＝演奏型と混同していました。正しくは逆ですね。 はい、そうです。 まさか演奏型スキルのほうを修正するのか、と私も早とちりしたようですね。 ソース見ればすぐでしたね。 > # でもscore.ini内だとHiSkill＝演奏型なので混乱するんですよ・・・。 演奏型スキルが登場したころはまだゲーム型スキルが主役で、演奏型スキルは「こっそりと」score.ini に 組み込んだだけだったのですよ。 なので、先にいたほうが Skill、後から加えた方が PlaySkill となりました。 ……で、あるバージョンからそれを入れ替えて、演奏型スキルをメインにした、というわけです。 HiSkill の名前は変えるわけに行かないので、現状のままで。 安直な名前を付けたのが敗因ですね（涙 > なお個人的には、ゲーム型スキル値の方は計算式をbox.defか何かで外部定義できるようにしてしまってもいいと思ってます。 というか、ini にしか出力されないスキル値を必要とするシーンでは、これまでは、 みんな独自の ini 解析プログラムを作って、独自の計算式を定義してきましたね。 主に IR イベントで。 一時期は、計算式は「外部ファイルで Python で書いて DTXMania から直接呼び出し」 みたいなことを考えてた時期もありました… > あーすみません。ご機嫌斜めな理由が分かりました。 ご機嫌が斜めというより、なんかもやもやした心持ちです。 よく分からないので、自問自答したあとにまた mixi にでも。
ickw_284さん
すみません。修正しました。tp://yyagi.com/DTXMania090_Test_23634_3.zip
fromさん
確かにHiSkill～には歴史的な事情がありましたよね。了解です。
ソースを見ると言っても、branchの方でやってますので分かりにくいと思います。 後でここまでの修正を(同じくbranchに)コミットしておきます。
もっと綺麗に書けると思っていたのですが、演奏型とゲーム型の両方を維持しようとした結果、結構泥臭いところも・・・(_ _;;;
スキル値は確かに自分の関わったIRイベントでも外部アプリで独自計算してました(笑)
mixiのお話はあちらで改めて。
#27699の話もあるので、まずは昔のスキル計算式変更コードを、最新のDTXManiaに適用したものを作りました。
本チケットにDTXMania本体とFDK、追加画像を添付しているので、092に上書きして動作確認して下さい。 (半年前のコードを最新コードに移植した形になるので、ちゃんと動くか凄く不安です・・・)
半年以上前のネタなので、一応使い方を再度書いておきます。
まず最初に…
既存のDTXを読み込んだ後、Play→Gameと項目を変えると例外が出てしまいます。
ただし最初の一回のみで、その後は正常に切り替わりますが、
現状score.iniを書き換えるようなプレイはしていないので再発も考えられます。
また、Gameスキル表示だと"100分率ではなく{Gameスキル(%)*難易度(Lv)*0.5]"との表示になっている為
自分はかなり戸惑ってしまいました、Gameスキルでも１００分率での表示に修正願います。
今までの仕様を見ると、スキルポイント(Pt)と達成率(%)とを混合して考えてしまってるため、
せっかくなら（達成率(%)とスキルポイント(Pt)とに）分類する方がまとまって良いかもしれません。
BEST SKILLの表示も、８５[ 77.77% 33.33pt ]S
なら達成率とポイントの関係が一目瞭然ですし。
またこの場ですが、"単曲スキル"というものも定義したいと思います、
単曲スキル＝その曲の難易度(BSC,ADV等)の中で一番スキルポイントが高い曲の数値
例えばADV15.00pt、EXT12.00ptならADV15.00ptが単曲スキルに該当します。
ちょっと考えましたが、選曲画面のV3(中央真下)付近に
[SKILL:EXTREME]
[ 23.45Pt]
も付ければ利便性が向上すると思いましたが、スペース的にキツイかな…？
勿論ソート機能も上記に準して、
"SkillRate(%)" 従来のSkill Pointソート、並び順はSkillPointTypeに準拠
"SkillPoint(Pt)" 新しいタイプのソート、単曲スキルの順番に並び替え
長くなりましたが以上です。
例外修正しました。(DTXManiaGR.exeを、添付し直したものに差し替えて下さい)
他の内容については、もう少し皆様からのご意見・コメントを伺ってからの対応がよさそうなので、しばらく待ちます。
脱線する内容で恐縮です。
すでに議論されていたものかもしれませんが見当たらなかったので質問です。
ゲーム型のスキル計算に「Level」が考慮されているようにお見受けしましたが、このLevel(難易度ですよね？）の数字の決定に基準はあるのでしょうか？
私も時々譜面作成してますが、難易度の数字は適当につけているため、かなり当てになりません。
ただの「目安」として使っていたので重要視していませんでした。
ですが、今回のように計算の要素として加味されるのであれば、ある程度は統一性・正確性が必要になるのではないでしょうか？
某アレの数字は社内基準を設けて算出・決定されているとは思いますすが、
（それでも時々修正・変更されたりしてますね。演奏者によって得手不得手のリズムやパターンがあるでしょうから当然と思いますが･･･。）
DTXManiaさん等では基準があるのでしょうか？（私が知らないだけだったらごめんなさい）
'Historyに表示されるのはプレイ型で固定？
from 某アレと違って全曲修正なんて出来ませんので、もちろん基準はないですよ。
逆に、統一性・正確性を出すにはどのようにすればよいでしょうか？
これは「譜面から算出するには」非常に難しい問題です。
毎度すばやい返答ありがとうございます。
やはり譜面作成者等の判断でつけているのですね
難易度決定に統一性・正確性を出すのは私も非常に難しいだろうなと思っています。
’ゲーム型よりプレイ型を利用する側なのですが、譜面作成で考慮したほうがよいのか確認したいための質問でした。
ではどうやって数値化するか･･･
例えばですが、外部ツールを作成して、譜面パターン（速度・密集度・想定移動距離・変則性・チップ数･･･）などを分析し、大体の参考難易度を算出する・・・なんて夢を見てました。
以下即席で考えてるのでザックリです。
括弧（）の中身は難易度係数で、難しいと判定されるほど高くなる
分析イメージ：
手で入力するレーンを統合(ｼﾝﾊﾞﾙ/ﾊｲﾊｯﾄ/ｽﾈｱ/ﾀﾑ)
足で入力するレーンを統合(ﾊﾞｽ+α)
§BPM:(係数)・リズムが早いほど難
-100(1) / -150(1.5) / -200(2.2) / -250(2.8) / 250-(3)
§移動距離・移動距離が多いほど難
0.5 : 移動無し
1 : HH = ｽﾈｱ / ｽﾈｱ = HT / HT = ML ... etc.
1.2 : HH = LT / HH = FT ... etc.
1.5 : LC = RC
補足：２つの手を使って入力するわけですから、移動距離が必ず成立するわけではないですねぇ...
§密度・密度が高いほど難
4ビート : 1
8ビート : 1.5
16ビート : 2
32ビート : 3
不規則 : 2
§……
その他の要素を加味しつつ（速度難易度×移動距離難易度×密度難易度×･･･）×曲の長さ・・・のように要素を小節などのある程度の範囲毎で算出し、加算・平均化する...
例)
BPM150でスネアのみを４ビートならば
速度難易度*移動距離*密度
1.5 * (0.5*4) * 1 = 3
BPM15でスネアのみを８ビートならば
1.5 * (0.5*8) * 1.5 = 9
BPM150でハイタム・ロータムを交互に８ビートならば
1.5 * (1*8) * 1.5 = 18
数字の根拠はありませんが、算出の例として...
Gameスキル表示だと"100分率ではなく{Gameスキル(%)*難易度(Lv)*0.5]"との表示になっている為 自分はかなり戸惑ってしまいました。
Gameスキル表示も100分率のはずです。計算式は、(パフェ率x0.8 + Great率x0.3 + MaxCombo率x0.2) になってます。 なので、別の話題で出ている、Level値が計算式に絡んでいるようなことはないはずです。
'Historyに表示されるのはプレイ型で固定？
Historyには固定的に演奏型SP記録・表示していましたが、先ほど修正しました(20120311_2)。ゲーム型SPを表示している状態でクリアした曲分は、ゲーム型SP値を記録・表示します。
ハミガキプレイがあんなエロイとは思わなかった（謎
計算式は、(パフェ率x0.8 + Great率x0.3 + MaxCombo率x0.2) になってます。 なので、別の話題で出ている、Level値が計算式に絡んでいるようなことはないはずです。
ぐはぁっ（吐血
一生懸命考えたのに関係なかったとは orz... 自爆もいいところ（恥
ゲーム型SPを表示している状態でクリアした曲分は、ゲーム型SP値を記録・表示します。
早速の修正ありがとうございます
Levelの話は #62433 (http://sourceforge.jp/forum/message.php?msg_id=62433 ) で出ていましたよ。そのうちチケット化されると思いますので、一生懸命考えていただいたことは無駄にはならないかと。
なお蛇足ですが、私は私で以前、単位時間内の手の移動距離＋手足の独立性を見て、それを本家譜面のレベルに紐付けるような機械学習をさせて・・・なんてことを考えたことがありましたが、実行する暇がないのでどなたかお願いしますｗ
Levelの話は (略) 出ていましたよ。そのうちチケット化されると思いますので
了解しました
(略)・・・なんてことを考えたことがありましたが、実行する暇がないのでどなたかお願いしますｗ
え～と。
実質開発者がFROM様とやぎ。様しかいない状態で「どなたかお願いします」ということは自動でFROM様への依頼ということになるという認識でよろしいでしょうか(｀・ω・´)
...少しマジメに難易度算出アルゴリズム考えてみようかなぁ･･･99%ムリな感じがしますが（苦笑
from え～と。
実質開発者がFROM様とやぎ。様しかいない状態で「どなたかお願いします」ということは自動でFROM様への依頼ということになるという認識でよろしいでしょうか(｀・ω・´)
いえいえ。
ストレートに「どなたか C# を覚えて開発に参加してね」っていう認識でお願いします。
一般参加を募るためにオープンソース化したのですから、これから参加するかもしれない方々も含めて、誰も開発の責務は負いませんよ。
チケットの担当者になったら別ですが。
つまるところ、共同開発者募集中です。
スキル計算式のチケットでレベルの自動計算の話を続けると本論が見えなくなりますので、先ほどレベル話について代理でチケット#27833を起こさせていただいて、先の内容を転記しておきました。レベルの話はそちらでやりましょう。
開発云々については、私もfromさんと同意見です。少し補足すると、外部アプリとして作ればDTXMania本体に組み込む必要もありませんのでC#と関係無しに自由に作れます。もっと言えば、アルゴリズムだけきっちり考えてそれを他の人に作ってもらうというやりかたもあるでしょう。
もちろん共同開発者募集中なのには変わりありません。私はそもそもIR機能の追加がしたくて共同開発に手を挙げたのに、実際のところ保守とチケット消化で手一杯ですし・・・。
from 少し補足すると、外部アプリとして作ればDTXMania本体に組み込む必要もありませんのでC#と関係無しに自由に作れます。
このチケットに関して言いますと、少し昔、スキル計算式の部分だけ動的言語（DLR）にすればいいんじゃね？と本気で考えたことがあります。
そうすれば、たいそうな開発環境がなくても、テキストエディタと最小限の言語知識だけで、お好みのスキル計算式が少量のスクリプトで自由に書けます。オブジェクト指向などの概念からがっつりと学ぶ必要もなくなります。計算式の関数さえ１つ書ければ良いんですからね。
つっても当時は IronRuby と IronPhyton というマイナー（あくまで当時）な言語しかなかったのでやめましたが。
今は VB.NET や JavaScript も使えるみたいですね。
もちろん共同開発者募集中なのには変わりありません。私はそもそもIR機能の追加がしたくて共同開発に手を挙げたのに、実際のところ保守とチケット消化で手一杯ですし・・・。
まさに本末転倒。もし大変なら、本命の作業だけに注力することをお勧めしますよ。
そして、本命の IR の実装が終わったら、しばらく DTXMania の保守やチケット消化をお休みする期間を設けてもいいんじゃないでしょうか？
DLRの件はチケットを切りました(#27842)。branchでちょっと試してみましょう。
本末転倒な件は、追々。まあそろそろ仕事が忙しくなってきてこちらには手を回せなくなってきますけど・・・。
というわけで、このチケットの本筋であるところの、DLRに関わらない部分の話に戻しましょう。スキル値と達成値がどうとか、UIがどうとか、といった話でしょうか。
でも単曲スキル云々の話はこのチケットとは少し趣旨が違ってくるので、別チケットでお願いします。
Fork
現状の達成率計算は(P率=達成率)に近い仕様となっており、コンボに対する比率が一切無いため
下記のような計算式に変更を施してくれればと思います。
SKILL計算式→(Perfect％×8＋Great％×3＋トータルノートから求められるMaxCombo％×2)÷10
（個人的な意見として）本家に使われている辺り、最も比率が良いと思われるのでチケットを発行しました。