forum

初心者Modder向け - Moddingガイド

posted
Total Posts
11
Topic Starter
NewRulerNA
Moddingのやり方、チェックするポイントについて軽くまとめました。
広く浅くStandard対象に書いていますが、一部は他のモードに通じるところがあるかもしれません。

※あくまでもこれは私のModding(以下mod)についての持論で、以下に書いてあることが絶対的に正しいという保証はしません。
 なのでこれからmodをしていく上での参考として、軽く読んでもらえるだけでも結構です。
※一部古い知識が混ざっていることがあります。
※思いつきで書いたので、誤字脱字/説明不足な点があるかもしれません。何かあれば指摘して頂けると助かります。
※ここに書いていないことであっても、modについての質問があれば補足していきます。私がosuをやっている間に限りますが…。
※現在活動している方からの「ここの考えはおかしくね?」「こうした方がよくね?」等の突っ込みは歓迎します。この記事をModしてください。mod request!

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

Moddingとはなにか


modをする以前の根本的なお話で、「どういったことがmodに該当するのか」ということを扱います。

  1. Rankに関するルールに反している項目がないか、接触する可能性のある項目をチェックをすること
  2. 譜面をチェックし配置や音取り、音付けにおける問題点を挙げて指摘をすること
  3. 同様に譜面について、より面白くなる/完成度の高くなる提案すること
  4. タイミング(BPMとoffset)のズレを指摘/修正させること
  5. ストーリーボード(通称SB)のコーディングの提案やミスの指摘など
  6. 曲に関するデータ、あるいはヒットサウンドを始めとする音源などの提供を行うこと

以上で挙げたことがosuでの広義におけるmodになります。
しかし実際は1~5まではmodとして扱い、6単体ではmodとして扱われません。
また指摘内容次第ですが、1と6はkudosuを貰えないケースがあります。
譜面の中身のオブジェクト、あるいは譜面のプレイに直接影響を与えない場合、
もしくはAiModで指摘された内容のみの場合、kudosuを貰える条件を満たしません。

さらに補足としてkudosuが貰えないかもしれない、という部分について触れます。
kudosuを貰える条件についてはこちらも参考に。
  1. 配置の提案 ->貰えます。
  2. 音取り、音付けの提案 ->貰えます。
  3. SBの提案 ->貰えます。SBもマップの一部なので、kudosuを貰う正当な理由となります。
  4. タイミングのズレを改善案込みで指摘 ->貰えます。タイミングも譜面の質を高める明確な要因です。
  5. 指摘/提案が全て拒否された ->条件付きで貰えます。
    全てがマッパー側の個人的な理由で拒否していて、かつマッパーから見て無意味なmodでない場合のみ貰うことができます。
    しかし相手がどう感じたか次第なので、貰っていない場合であってもmodderがそれに文句を言うべきではありません。
  6. modした譜面のリチェックを頼まれ、もう一度modした ->原則として貰えません。
    既にmodしたことにより、最近kudosuを得た場合は貰えません。
    ・・・が、リマップや難易度追加があり、リチェックまでの間で"大きな変更"があった場合のみもう一度貰うことができます。
  7. AiModで拾われる内容(snapping、設定の矛盾等) ->AiModで指摘される内容のみではkudosuを貰えません。
    上記リンクで明確に貰えない条件として書かれています。
  8. メタデータ(アーティスト名、タイトル、ソース、タグ)の間違いの指摘のみ ->単体では貰えません。
    譜面のオブジェクトなどに対し具体的に何の影響も与えていないためです。
  9. 差し替え用のヒットサウンドの提出 ->貰えます…が、具体的に何故それを使うべきなのか、
    何がいけないのか等の指摘が伴っていることが前提です。
  10. 差し替え用の動画を提出 ->貰えません。まず2つ以上提出することがないため、複数指摘のルールに接触します。
    そして譜面の中身やプレイに直接影響を与えていません。
  11. SB差し替え用の画像の提出 ->貰えます。SBが譜面の一部であり、エフェクトの修正のためであるならそれはmodとして意味を成します。
  12. 指摘を一つだけ ->貰えません。"いくつかの"指摘が必要で、単独の指摘ではダメです。
基本的に譜面内容(ヒットサウンドや配置等)に関わる指摘を"いくつか"していれば貰えます。
例えばタイトルの間違いを指摘した上で、音取りの提案をいくつかしていれば貰える条件を満たします。
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

modに最低限必要なもの


この項目ではModする前の準備段階として必要な知識、ツールを記載します。
ここにある全てを揃えてからmodに臨むのが好ましいです。
  1. メモ帳 (サクラエディタや秀丸エディタのような他のテキストエディタでも可)
  2. https://s-ul.eu/
    sharex.html
    (もしくはその他の画像アップローダー)
    ※いずれか一つで大丈夫です。
  3. 英語力
  4. マッピングの知識、譜面作成の経験
  5. Ctrl+C/V
  6. Rankする上で必要なルール、具体的にそこに至るまでの知識
  7. めげない心
  8. 時間
メモ帳:
これは誰でも持っているものです。osuの鯖は時々落ちることがあります。
なのでフォーラムのpostページに書き込みながら何かをするのは避け、メモ帳にmodのための文章を書いていくのがベストです。

puush:
modする上でかなり大きな手助けとなるツールです。
選択した範囲をアップロードして、modで配置の提案に幅ができたりするだけでなく、
別のwavを使ったほうがベターだから是非渡したい等、画像以外にも効果を発揮する最強のmoddingアシストツールとなり得ます。
個人的にこれなしにmodは語れない。

英語力:
英語が苦手となるとmodをしていく上で大きな障害となることでしょう。しかしgoogle翻訳weblioのようなサイトを使って乗り越えてください。
苦手でも読まなければいけない場面は数多くあります。osu!はそもそも海外のゲームなので"英語が読めない"は甘えです。
翻訳が使えなくとも理解しようとする努力は絶対に怠らないでください。
その努力はosu以外でもいつか力になります。

マッピングの知識、譜面作成の経験:
実際のmodで重要となってくるのはここ。
「ここが変だ」と感じることもできず、指摘をして修正案を出すにも譜面作成の経験が無いと厳しい。
プレイヤーとして意見を述べる分には「ここが打ちにくい」で済ませられますが、
modderとして指摘をしていく上ではより具体的な理由と案を要求されるため、こういった経験は必須となってきます。
ただし"譜面を作るのが上手いプレイヤー=modの上手いプレイヤー"とはなりません。

Ctrl+C/V:
説明するところが他でないのでこちらでついでに説明。
editorで「00:29:357 (5,6) - 」といった文章をコピペで出すための方法。
Editorでオブジェクトを選んでCtrl+C、メモ帳を選択してCtrl+V。
コピーの際にオブジェクトを選ばなければ、「00:29:778 - 」と現在のタイムラインに表示されているタイムがコピーされ、
designタブでこれをすると「29778」とms単位でのコピーが可能となります。
Timingタブですると
1. Offset: -12ms BPM: 143.00
2. Offset: 28,519ms BPM: Inherited (0.8x)
3. Offset: 41,946ms BPM: Inherited (1x)

と現在のタイミングのデータをコピーできますが、あまり使う機会は無いと思います。

Rankする上で必要なルール、具体的にそこに至るまでの知識:
早い話がRanking Criteriaコミュニティーのルールを覚える事と、
BNに泡を付けてもらいQualifiedカテゴリで1週間過ごせばRankできる、という2つのシステムを覚えてもらうことになります。
不慣れなうちはこのページを確認しながらmodすると良いでしょう。ただしルールとガイドラインは混同して覚えないように注意。
なおwikiには日本語のページもありますが、その多くは昔に翻訳したものなので情報が古い場合があります。
なので最新の情報を調べるのであれば翻訳されたものではなく、英語の記事を参照してください。
これはそのページだけに限った話ではありません。

めげない心:
「この譜面何も突っ込むところがない…」「この譜面をどう見ればいいのか分からない…」という場面もmodをしていれば何度も遭遇します。
他にも「提案全部拒否された」「ドヤ顔で間違ったこと書いて突っ込み入れられた」等、
私もmodをして気にしていた時期もありましたが、失敗や原因を次に活かす前向きな姿勢が大事になります。
長いことやっていれば恨みを買い、憎まれること、嫌われることすら当然のようにあります。
ずっとやっていれば間違いや失敗、考えの合う合わないもある、と割り切っていきましょう。そういった経験が今後のmodding力の糧になるのです。

時間:
突っ込むところがない、逆に突っ込むところが多い、何を考えてこの配置が作られたか、
そしてどう提案をするのがいいか等、熟考することは多々あります。
なのでマップセットのボリュームなど差はありますが少なくとも1時間はmodに掛かると思ってください。
本当に悩むものになると日を跨ぐことはザラです。
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

Mapping/Modding用語集


modに使う用語の簡易的なまとめとなります。
クリックで用語一覧を表示
  1. 単発
    サークルのこと。
  2. X/X
    白線から次の白線までの距離を基準とした、タイミングラインの目盛りの幅を指す主な表現方法です。

    スライダーの長さで表現すると左から順に2/1、1/1。

    左から順に1/1、1/2、1/4、1/8。
    やや複雑な表現方法として3/2、3/4、メロディー次第では1/3といった表現も用います。
    "1/2スライダー"など、スライダーの長さに関する指摘での使用が主となりますが、
    次のオブジェクトまでの間隔をどの程度開けるか、といった表現でも使うので、この表現は習得しなければなりません。
  3. X連
    "X連打"の略。2連と言ったら2連打。3連と言ったら3連打。
  4. tick
    下のslider tickを指す場合と、タイムラインの目盛りのことを指す場合の2つがあります。
    後者の意味で使用する場合、"white tick"や"red tick"といったように、目盛りの色を指して表現することが多くあります。
  5. slider tick
    長めのスライダーの途中で出てくる"○"のこと。
    低難易度ではここに音を付ける人がいるので、modの際にこの名前を使うことが多々あります。
  6. blanket/ブランケット
    主にスライダーで前後に出るオブジェクトを綺麗に覆う事。
    指摘の"配置"についての項目で取り扱う。
  7. stack/スタック
    主にサークルを前のオブジェクトの上に完全に重ね合わせて置くこと。
    スライダーなどでも言われることがあるが、大抵は上記のことを指す。
    2回サークルを重ねて置いた配置をしていく"ダブルスタック"といったマッピング方法がある。
    View>stackingにチェックを入れると、Editor中でもスタックによるズレが再現される。
  8. overlap/オーバーラップ
    重なりのことです…が上記のスタックとはまた意味合いが少し違います。
    スタックはサークルやスライダーの始点/終点などに綺麗に重ねて置くのに対し、
    こちらはそういった重ね置きを無視し、スライダーの下など他のオブジェクトに被せる形で、さらにオブジェクトを置いたりするパターンを指します。
    視認性に問題がある配置となることも多く、特に低難易度ではこれが起こらないように気を配る必要があります。
  9. overmap/オーバーマップ
    メロディー上の音がない所にオブジェクトを置くこと。
    こういったところで音を増やして難易度を上げる音取りは、マッピングで避けるべきポイントの一つです。
    ただしスライダーやスピナーの終わりで置く分では、問題とならないケースが大多数を占めます。
  10. reverse/リバース
    スライダーの折り返しの矢印のことで、リバースが含まれているスライダーをリバーススライダーと言う。
    これが極端に見にくいとルールに抵触するので、見やすい譜面を心がけよう。
  11. キックスライダー
    キックなどと略す人もいる。
    1/4や1/8のような短いスライダーを用い、そこに大量のリバースを入れてコンボを入れさせる配置。
    ルール上スライダーリバースは見えなければいけないが、
    高速で折り返すリバースの把握は困難なので、これに限っては2回目以降視認できなくても問題とはならない。
  12. stream/ストリーム
    連打のこと。
  13. アプローチサークル
    サークルやスライダーの叩くタイミングを示す、円の中央に向かって縮まっていく輪っかのこと。
    ブランケット云々を調節する時、ここを見て判断する人は多い。
  14. ヒットバースト
    オブジェクトを叩いた時に出る"300"や"miss"といったスキンの表記のこと。
    昔はこのヒットバーストでオブジェクトを隠してしまい、問題扱いされる場面が多かったが、
    昨今ではシステムの変更により、こういった問題が取り上げられることは少なくなった。
  15. コンボバースト
    一定のコンボを連続して繋ぎ続けると左右から出てくるキャラクターの絵のこと。
  16. ms
    時間の単位の一つ「1sec=1000ms」。要するに0.001秒が1msです。
    offsetやosuファイルの時間の記述は全てこの"ms"で行われる。
  17. HP
    HP Drain Rateのこと。この数値が高いほどミスを出した時のHPの減り幅が大きくなる。
    NewComboの割合やオブジェクトの密度により設定されることが大多数。
  18. CS
    Circle Sizeの略。この数値が小さいほどサークルとスライダーのサイズが大きくなり、数値が大きいほどサイズも小さくなる。
    Insaneでは4~5の間で設定されることが多いが、Editor内で変更する限りでは、それを直接的に制限するルールなどはない。
  19. AR
    Approach Rateの略。オブジェクトが現れてから打つまでの間を設定する。設定が高いほど見える時間が短くなる。
    高ければいいというものではなく、曲のBPMや譜面の構成から判断される。
  20. OD
    Overall Difficultyの略。
    判定の厳しさを設定し、この数値が低いほど300が出しやすく、高いほどより精確なタイミングで打たなければ100が出る。
    基本的に高BPM帯ほど高い設定にする傾向がある。
  21. NC
    NewComboの略。コンボカラーの切り替えと一時的な回復量の上昇が起こる。
  22. DS
    Distance Snapの略。一定の時間に対しての間隔を保ってオブジェクトを置かせる機能。
    Normal以下やstreamはこれを使用して作ることが多い。
  23. SV
    Slider Velocityの略。スライダーの速度の設定項目。
    同じ時間スライダーを置いた時、数値が高いほど長く早い移動をするスライダーとなる。
  24. BPM
    Beats Per Minuteの略。曲のテンポが決まる数値。
    osuで扱われる大抵の曲はこの数値が一定で、BPMが中途半端な数値になることは少ない。
    ここを間違えていると膨大な量の修正が必要となる。
  25. offset
    曲の開始地点を0とした時のBPMの測り始めのタイミングを決める数値。
    BPMが正しくても、ここがズレていると100が多く出る。
    個人環境による差があるため、ここを指摘するのは自信がある場合のみで構わない。
    一般的に許容誤差は±4ms。
  26. timeline/タイムライン
    Editorで上の方にオブジェクトの置かれているタイミングが表示される場所のこと。
  27. snap/snapping
    タイムラインからズレずに置かれること。対義語としてunsnapが存在する。
  28. unsnap
    snapの反対で、タイムラインから僅かでもズレるとこの状態となる。
    存在するとルール上の問題となり、主にAiModを使用することで発見される。
    配置をコピペ(Ctrl+C/V)して何度も置いていると、このunsnapが起こる仕様?があり、この状態が発生することは多い。
  29. 赤線
    "uninherited timing section"のこと。要するにBPMとoffsetを決めるタイムライン上に出る"あの赤線"のこと。
  30. 緑線
    "inherited timing section"のこと。スライダーの速度や音量を変える時、KIAIを入れる時にも使用する"あの緑線"。
    赤線でもほとんど同じ内容を調節できますが、こちらはBPMとoffsetに影響を与えません。
  31. downbeat/ダウンビート:upbeat/アップビート

    白線の位置によって名前があり、4/4では上記のように定められています。
  32. KIAI
    KIAI Timeとも。
    マッパーが任意で入れることができる箇所で、曲のサビや譜面の難所などでよく入れる。
    使用のしすぎや、短いタイミングで細かくKIAIをオンオフする設定はルールに接触する可能性がある。
  33. Beat Snap Divisor
    Editor右上にある、タイムラインの目盛りを調節するバー。
    多くの譜面は1/4で、白線から白線までの間を4分割した表示で作られる。
    一部特殊なリズムの曲ではここで変化させたり、より早く細かな音を拾う場合などは1/8を用いたりする。
  34. preview time/preview point
    選曲画面の流れ始めの設定ポイント。
    EditorのTiming>Set current position as preview pointを押すと、現在のタイムで流れ始めるように設定できる。
    質問スレのp/2396890も参照。
  35. SB
    Storyboardの略。背景が動画以外で動いていたらこれが有効になっています。
    osuファイル、osbファイルどちらでもこのコードは入力でき、スキルがあれば複雑な表現が可能となります。
    詳しくはwikiの該当項目にて。
  36. AiMod
    Editorで「Ctrl+Shift+A」を押すことで出る、osu内臓の簡易チェッカーです。
    ぱっと見では分からない、snapのミスやmp3のビットレートなど最低限の内容をチェックしてくれます。
    これが拾った内容を指摘してもkudosuは貰えませんが、ここから致命的な問題が拾い上がる場合があるので必ずチェックしましょう。
  37. Polygonal Circle Creation/ポリゴナルサークルクリエーション
    Editor機能の一つ。「Ctrl+Shift+D」で表示され、ここから完璧なバランスの多角形を作ることが可能。
    少し使うのに慣れがいるが、綺麗な七角形が作れたりする。
  38. Convert slider to stream
    Editor機能の一つ。
    スライダーを選択してから「Ctrl+Shift+F」で表示され、スライダーの形に沿ったstreamを置くことができる。
    その際にスペーシングの設定などもでき、使いこなすことができれば綺麗なバランスの連打を置ける。
  39. ^
    "^"この記号一つで"上記の指摘と同様"といった意味合いを持ちます。
  40. BN
    Beatmap Nominator、あるいはそれを含んだグループであるBeatmap Nomination Groupのこと。厳密には前者のことのみを指す。
    彼らはmodをして譜面に泡を付けQualifiedに移動させるのが主な役割。
    kudosuの取り消しなどは主にBN、QATが行う。
  41. BNG
    上記BNのBeatmap Nomination Groupを限定して指す略称。
    BNというワードが混同して使用しているケースが多いので、こちらで分けての記載としています。
  42. QAT
    Quality Assurance Teamのこと。
    主にQualifiedに存在している譜面をチェックし、そこで問題があればWIP/Pendingのステータスに移動させることのできるチーム。
    BN同様にmodをする人、modをせずにチェックに専念する人の2パターンがあり、原則として彼らにmodは頼むことはありません。
    ただしルール的によくわからない点を聞いたりすることはあるでしょう。
    GMTの権限を内包しています。
  43. GMT
    Global Moderation Teamのこと。
    フォーラムと各種チャットチャンネルを監視し、不適切な発言や行動があった場合に介入するモデレーター。
    QATと違い譜面にBubbleを付けることはできないが、BNと兼職している場合はそれぞれの権限を持つ。
  44. kudosu
    modをすると貰えるもので、"kds"と略して表現することもよくあります。
    "kudosu star"と呼ばれていたこともある。
    kudosuを貰うと好きな譜面で、その譜面の優先度(Current Priority)を上げるstarが1つあげられるようになります。
    一度あげるとなくなりますが、modを多くすることで溜め込むこともできます。
    なお下記のBNとQATが付けられるstarとは別物で、フォーラムのステータスを星マークにすることはできない。
  45. Current Priority
    CPとも略され、この数値が高ければPendingフォーラムで上位に上がり、ModderやBNなどの目につきやすくなるというもの。
    ただしこれが多くても譜面にBNが現れるわけではなく、目につきやすくなる以上の効果は期待できない。
    譜面のスレッドに誰かがkudosuを消費しstarを投げてくれた時、BN/QAT限定でフォーラムに対してstarアイコンを付けたときにはそれぞれ1もらえる。
    譜面をModしてもらいkudosuを与えた時も、その与えた量と同じ分だけこのCPに加算される。
    与えたkudosuが取り消されれば、その分だけ減る。
    また例外として、Bubbleの譜面がBNやQATによりPopされた時は+5される。
    BNやQATはこの数値が12以上無い譜面にBubbleアイコンを付けることはできない。
  46. Star
    BN/QATが付けることができるアイコン。
    個人差はあるが、大体譜面がRankするに値する一歩手前くらいで付けてもらえることがある。
    kudosuとは別物で、CPを1上げる効果に加えて、フォーラムのステータスに星マークを付ける。
  47. Bubble
    BN/QATが付けることができるアイコン。
    譜面がRankをする条件を満たした場合、彼ら独自の判断でこれを付けてもらえる。
    2つ集まるとQualifiedのカテゴリに移動される。
  48. Pop
    BN/QATが付けることができるアイコン。
    Bubbleを受けたが、他のスタッフにより問題が見つかった場合に付けられる。
    他にもBubbleの状態で、マッパーがマップセットをアップデートするとこの状態になる。
    BNやQATによりPopをされた場合はCPが+5される。
  49. Qualify
    BN/QATが付けることができるアイコン。
    Bubbleが2つ集まり晴れてカテゴリ移動をされた状態。
    約1週間このカテゴリあり、その間に何の問題もなければRankカテゴリに移動する。
  50. Rank
    Qualifiedで一定期間過ごすと自動的に移動される。
    この状態になると何か問題が見つかってもPendingに移動されることはほぼ無くなる。
    過去に例外的に背景画像が不適切ということで移動された例が一応ある。
  51. Flame/Approval
    BN/QATが付けることができるアイコン。
    1譜面しか無いマップセット、もしくはNormal以下を含まないマップセットのルールを無視してRankを狙う場合に付くアイコン。
    曲の長さが5分以上であることが必要で、RankのためにはBubbleが3つ必要となる。
  52. Heartpop/Disqualify/Unrank
    QATが付けることができるアイコン。
    Qualifyされた譜面に問題があった場合、もしくは作成者からのリクエストがあった場合、
    このアイコンを付けてWIPステータスに戻すことができる。
  53. Radioactive/Nuke
    旧BATが付けていたアイコン。
    CPをアビューズ行為で増やすと言った、コミュニティールールに違反するような特殊な場合のみ付いたアイコン。
    ただし現在でこれを使用することはまずなく、一部の古い譜面で見るだけである。
  54. IRC Mod
    Modの方法の一つで、ゲーム内でチャットをしながら譜面の問題点を指摘する方法。
    IRC Modをした場合、そのチャットログ、あるいは変更した部分をまとめたログを提出しなければならない。
    別項目で纏めてあるので詳しくはそちらで。
  55. #modreqs
    ゲーム内チャットチャンネルの一つ。
    毎日多くの譜面がリクエストされ、modderはここから自分の好きな譜面を拾うことができます。
    ただし大半は外国の方なので、当然英語でModやその対応をしなければいけません。
  56. modding queues
    フォーラムの一つ。
    各modderがQueue(スレッド)を建て、そこにマッパーが譜面のリクエストをしにいく、という場所です。
    多くの場合はルールを定めていて、#modreqs同様に外国の方が多いので、英語でのスレ建てやmodが前提となります。
    忙しくなる上、変な譜面がリクエストされることもあるので、不慣れな内はあまりお勧めはしません。
  57. user page
    自分のユーザーページでルールを作り、そこからmodを受け付けるという形式があります。
    自分のことを知っている人からしか来ないため、上記のフォーラムで依頼を受ける場合に比べて、依頼数が少なくて済む事が多いです。
  58. NM
    Normalの略…とは言ってもこれ自体に大きく2つ意味があり、難易度名、それに該当する難しさとしての表現としてのNormal。
    Queuesなどで用いられる、mod4modなどをしない普通のQueueとしての意味の2つがあります。
  59. M4M
    Mod for Modの略。Mod4Mod等とも呼ばれ、Modをし合う事でお互いの譜面にメリットがあるというシステムになります。
    自分にもModが来るという性質上、あまり下手なModをしてしまうのは気まずく、ある程度のスキルが備わってから挑戦すると良いでしょう。
  60. GD
    Guest Difficultyの略。マップセットの中に他のマッパーが作った譜面があれば、それが該当します。
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

modをする前の注意点


modをする前にこれを意識した方がいい、という心得について先に書きます。
これを理解しているかどうかがそのmodderとしての評価を分けます。
  1. 問題だと感じた理由
  2. 修正案
  3. modする譜面の尊重
この3つはmodする際に意識して付けてください。

最初の2つ、相手に何が「原因」で具体的にどう「修正」するのかを示すことで、その指摘にどう正当性があるのか伝わりやすくなります。
一例として―
01:00:010 (4) - ここはサークルを使用して、その後に1/2スライダーを使用するとより曲に合うと思います
これだけでも相手には伝わります。ですが押しが弱く、具体的にその提案をするに至った経緯が示されていません。
よって意図を把握せずに修正されたり、意味が分からないからとりあえず現状維持といったこともよくあります。
01:00:010 (4) - リバースを使って前半は楽器を、リバース~その後にかけてはボーカルといくつかの性質の異なる音を纏めてフォローしていますが、これが私には不自然に感じました。
メロディーに対して抑揚がなく平坦な音取りなのが原因で、それぞれの一地点として聞いた場合では問題なくても、スライダーという鎹で連結されて聞いた時には違和感を生じさせます。
単発+1/2スライダーと分離させ、それぞれを分けるのがベストです。
後者はなぜ指摘をして、どう直すのが大雑把ですが説明しています。
こういった指摘をすることで相手のマッパーは何故そこを直すのか、直すことでどう変わるのかをより理解してもらうことができます。
さらに"自分はなぜそこに違和感を感じたのか"、"どうして問題だと思ったのか"といった感じたことを文章に出すことで、根拠を明確に認識することができます。
自分のmodを後で見返したりするときにも役立ちますし、今後より論理的に譜面を見ることができるようになると考えています。
もし修正されなかった場合でも、どういう考えを持って相手が修正しなかったのか教えてもらうことができるため、そこから自分の今後に活かすこともできるでしょう。

そして3つ目、これはmodをする中で忘れてはいけない事の一つです。
相手の譜面を尊重し、その譜面の中で存在していても浮かないように気をつけて提案をしてください。
そのマッパーの譜面であって、modする人の譜面ではないのです。

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

Modでチェックする主な項目


いよいよ本題となります。
どういう所に着眼するのかを大雑把にまとめたので参考に。
  1. メタデータ、マップ構成、スキン等
  2. mp3や動画でのタイミングのズレ等
  3. オブジェクトの配置/NewCombo
  4. オブジェクトの音取り
  5. オブジェクトの音付け
  6. SB
上に挙げた内容でミス、あるいは今の譜面より良くなると思った事を提案します。
なおmodをする際は原則としてデフォルトのスキン、ヒットサウンドの使用を推奨します。
自前のカスタムスキンがデフォルトとかけ離れたものである場合、正常な判断が難しくなる場合があるためです。

メタデータ、マップ構成、スキン等:
曲のタイトルやソースが間違っている、HardとInsaneの難易度のバランスが極端に悪い、
フォルダに使用していないデータがあるといった、譜面の中身以外で一発でアウトになりかねない物は大体ここに入ります。
ルールに接触しているものが大半で、譜面を見たらまずここをチェックしましょう。
もしマップセットで何か問題があれば致命的なミスなので、細々とした提案などよりも大きな貢献となります。
ちなみにosuではヘボン式ローマ字を使用してます。
2014年中盤辺りに採用されたルールなので古い譜面を参考にすると痛い目を見ます。
他にもARやODなどの設定が適当なものかどうかなど、ここで一緒に見ておくといいかもしれません。

タイミングのズレ等:
プレイヤーの環境に依存するところはありますが、Timingタブを開いてメトロノームの音を聞いて判断します。
遅かったり早かったりした場合、具体的なoffsetがいくつになるのかに加え、元のoffsetからいくつズレるのかを書くと相手に伝わりやすくなります。
さらに動画がついている場合は、動画が音楽に対してしっかりと合っているのかを確認もします。
確認の際は公式の動画配信やYoutubeなどを参考にし、同様に動画のoffsetがいくつなのか提案をします。
またルールで掘り下げて記載されていない指摘内容として、ダウンビート/アップビートのズレを修正することもあります。

4/4でタイミングは合っていても、ドラムがアップビートに来るべきところでズレが生じていたり、
途中からズレ込むタイプの曲だったり、はたまた途中から3/4になったりと様々な曲があります。
あまりうまく説明できませんが、こういったズレは日頃から多くマッピングをしていると気付いたりするもので、
普段のmodでも多少意識していないと気付きにくい点かもしれません。
不安な場合は「~かもしれない」と逃げ道を作っておきましょう。
またAiModでそれぞれの譜面でオブジェクトのスナップについて確認しましょう。もしスナップしていないものが存在していれば問題となります。

オブジェクトの配置/NewCombo:
譜面の流れを見ていくmodの特に大きなウェイトを占める部分。
指摘をすることそのものは簡単ですが、相手に気に入ってもらい採用させるとなると難易度が跳ね上がります。
  1. 見やすさ
  2. 打ちやすさ
  3. 緩急のバランス
  4. NewCombo
見るのはこの4箇所。
マッパーであるなら誰しも配置は悩むポイントで、提案するこっちが悩むこともちらほら…
  1. 見やすさ
    言わずもがな、見やすさや美しさなどの表面的な部分。
    「こうした方が見た目よくね??」と思ったら指摘するだけの非常にシンプルな内容。
    初心者はまずここから始めよう。

    指摘としてよく見るのは、上記画像の(8)のスライダーのカーブを他のオブジェクトのアプローチサークルに合わせたりする通称ブランケット系。
    他のオブジェクトにスタック(ぴったり重ねるアレ)をさせるスタック系が多く見られます。
    特に前者は「とりあえずアプローチサークルに沿ってスライダーを置けば綺麗に見える」というもので、粗い配置が多いマッパーに有効です。
    代表的なものは上記の2つで、他にもオブジェクトの重なりで見にくい場合などはoverlapとして指摘をしていきます。
    ただ熟練したmodderがこれしか指摘していないと、その知識量や指摘能力に疑問が出てくるため、
    これだけをメインで指摘していくのは避けたほうがいいかもしれません。
    もう何も書くことがなくて詰んだ、そう思った時に使う最後の防衛線です。
  2. 打ちやすさ
    フロー(flow)、流れのことを主に指していて、打ちやすい流れの代表格として滑らかな円運動などが挙げられます。
    こうした方が打ちやすいんじゃないか?という理由から提案することになると思いますが、
    大体の譜面はそれなりの流れはできているので、以下の緩急の部分に大体取られます。

    なおここでの円運動とは上記画像のような緩やかなカーブを連続で描き、次のオブジェクトへ繋がっていく一連の流れのことを指しています。
  3. 緩急のバランス
    曲調が激しいところで難しい配置をして、穏やかなところでは簡単な配置をする…というのを突き詰めて見ていくのがここです。
    譜面全体のバランスを見た上で、声や楽器の強さにある程度比例させて面白い、あるいは楽しいと思う配置を提案をします。
    ただし緩急のバランスは「配置で取るタイプ」と「音で取るタイプ」がいるので、一概に上記の提案をすれば良いというわけでもなかったり。
  4. NewCombo
    略称"NC"。コンボが長引いた時に区切るアレです。
    コンボをどう区切るのかはマッパーによるところが大きいですが、音取りからNCを付けるタイプと配置からNCを付けるタイプの2種類があり、
    前者はボーカルや楽器の切れ目で長くなりすぎないように、後者は視認性を向上するためにNCを入れます。
    例外的にNCを入れるとHP回復量が増えるので、意図的に多く入れている場合もありますが、
    現代は音取りからNCを付けるタイプが主流で、1~2小節で区切られパターン付けされていることが多い印象です。
    実際は以下の画像のように、NCの位置が音取り比較でどちらのほうがしっくり来るか等で指摘をします。


    この例だと1/1のロングスライダーが手前のボーカル歌い始めを拾っているため、ボーカルに合わせてNCを入れ替えの提案をしています。
オブジェクトの音取り:
moddingの大部分その2。
どの音を拾っているのか理解さえできればお手軽に指摘ができるポイントです。
ただし譜面の良し悪しを決める最も大きなポイント。そこにこだわりのある人の譜面は中々難しい。

  1. リズムのわかり易さ
  2. 拾っている音とのズレ/一貫性をチェック
  3. overmap
  4. サークル/スライダー比率と曲調のバランス
ここでチェックするのはこの4箇所。
譜面作りで様々な音取りを試しているとここが楽しくなってきます(体験談)
  1. わかり易さ
    楽器の音を拾いすぎてしまいどれを拾っているのか分からなかったり、複雑すぎて目押しになるような音取りを改善させるのがこちらです。
    問題を見つけても具体的な解決案を出すほうが難しいこともあり、マッピングスキルもこの指摘では特に求められます。
  2. ズレ/一貫性について
    例えば「ボーカルを曲中で片っ端から拾っているのに、このパートだけ拾っていないのはおかしい」
    「バスドラムをメインで拾っているのに、スライダーの置き始めの位置がズレている」というような初歩的なミス/矛盾を指摘していきます。
    ただし切り替えのバランスの兼ね合いから拾う音を意図的に変えている場合があるので、
    一概にこの"一貫性"が無いからといって即問題とはなりません。
  3. overmap
    時々曲にない音を拾って、独自のよく分からない連打などの音取りをしている譜面があります。
    そういった点を指摘していくのがこの項目になります。

    こういったアップビートで終わる3連打で、かつ回りに連打が存在していないというケースに限っての個人的な考えですが。
  4. 曲調のバランスについて
    配置の緩急のバランスと同じようなもので、曲が激しいところではサークルを多めに採用して密度を上げたり、
    静かなところではスライダーを多用したり拾う音を絞るといった、
    難易度のバランスを配置ではなく、オブジェクト密度でする点に着眼するのがここです。
    似たメロディーでもサビ(あるいはKIAIパート)のところのみ鳴っている楽器が増えている等の理由から密度を上げるケースもあり、
    一貫性が全てにおいて等しくは通じないという典型的なポイントとなります。
    他にもプレイ寄りの指摘として、強調したい音はサークルやスライダーの開始で拾い、叩かせることなどもこちらで指摘します。
オブジェクトの音付け:
比較的提案をしやすい部分。音量、パターンの抜け、楽器に合わせたヒットサウンド等を指摘/提案します。
大きく分けて曲に合わせて鳴っている音に近いものを入れるタイプ、曲にヒットサウンドが加わることで別の音楽として完成させるタイプの2種類があります。
  1. 音量
  2. 音付け
チェックするのは上記の2つのみ。

ちなみに私はこの項目をチェックする際の音楽の音量は40%、エフェクト音量50%でやっています。
音楽10%、エフェクト100%のような極端な設定ではなく、音量バランスは1:1に近い設定がより一般的であり、
最終調整はプレイヤーに任せるというスタンスで。
この辺は好みによるところがありますが、最低限1:1でヒットサウンドは適当に流しても聞き取れるというのが最低条件です。
  1. 音量
    上記の1:1の音量バランスで聞き取れない部分を指摘したり、音楽の変化に対して音量バランスが悪い場合等に指摘します。
    ただここで指摘をするのはよっぽどな場合のみで、多くの場合は環境に左右されるのでスルーすることも多いと思います。
    強いて指摘するのは、特定の音を拾うときだけ音量を下げたり、曲のフェードアウトに合わせて調整するくらいでしょうか。
    またwavファイルを編集してヒットサウンドの音量調節をすることもあります。
  2. 音付け
    個人的にmod始めたばかりの人はここが苦手な人が多い印象。まずパターンを理解するところから始まります。
    そして曲に合わせた音付けなのか、曲に足していく音付けなのかは理解した上で音付けの抜けを基本的に指摘していきます。
    ただ曲に合わせるタイプと一言で言っても、ダウンビートのドラム/タムにのみ基本付け、シンバルにfinishといったシンプルなものから、
    曲中のピアノ音を完全にヒットサウンドで再現するようなレベルの高いものまで幅広くあります。
    1. 「ドラムはずっとclapを入れて拾っていたのに、ここで拾っていないのは変だよね?」と言った具合で抜けを指摘。
    2. この音も拾ってみたらいいんじゃないか?といったものがあれば、それを拾う提案。
    3. こっちのカスタムサウンドを使ったほうが曲に合うかも?と思えばどのヒットサウンドを採用するか、
      場合によってはwavファイルをpuushなどで出して提案することもあるでしょう。
    以上の3つが音付けでチェックする主な内容となります。
    しかしレベルの高いものは大抵抜けがなく、指摘しにくいことはよくあることなので、無理やり捻り出すようなmodはここではしません。
    またこの辺りの提案は音取り同様に好みによるところが強いので、ある程度の拒否はほぼ前提となります。
SB:
ある程度SBについての知識がないのであればスキップしても構いません。
コーディングがある程度できることがここでは求められます…が、実際は完成度が高いものが多くmodの必要がない場合も多々あります。
  1. SBを見て”こう表現したほうがいいんじゃないか?”というものがあれば自分でコード作って試してもらう、というのが基本となります。
    言葉でしっかり説明できるのであればコードを作る能力は必要ではないかもしれませんが、
    コードを直接渡したほうが思い通りのものを相手に提供でき、負担を減らしてあげることもできるので、
    コードが作れるのであれば率先して作るのが良いでしょう。
  2. 画像の切れ端のような見えてはいけないものが見えていたり、
    画像の粗などが気になった場合はそれを高画質なものに差し替えてあげたり、指摘した上で修正コードを渡すことになります。
  3. 使っていない画像がある、画像のサイズがルールで定められた物以上といった深刻な問題を指摘し、
    ミスがなければ大体それでSBのmodは終了です。
センスに依存する部分が他以上に大きいので、何も問題やミスがなければスルーして良いと思います。
しかしosuのコミュニティーでSBを見れる人は多くないので、深く見れると重宝される…かもしれない…?
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

コードの抜き出し方


コードを抽出方法を記載します。
特にSBはこの辺りの知識はあることが大前提となっています。

modの際に提案をし、こんな形の配置をしてみたら?と提案するはいいものの、その提案が複雑だったり、わかりにくい表現を含んでいる場合など、
自分でその配置をした譜面を作って直接コードを渡したほうがいいケースがあります。
以下を参考に抜き出してみてください。

  1. オブジェクトの配置コードの抽出方法
    コードはその難易度に対応したosuファイルから、抜き出したいオブジェクトについて書かれたコードを直接探し出し、
    それらをコピペで貼り付けることになります。
    しかし見つけるとは言っても、どのコードがどのオブジェクトに対応しているのか分からなければ、抜き出しをすることはできません。
    256,272,44410,1,8,0:3:0:0:
    256,112,44602,1,0,0:0:0:0:
    上記のものは例として実際に抜き出したコードになります。
    osuファイルではオブジェクト一つ記述する毎に改行されるので、上記の例では2つのオブジェクトについて記載されたコード、ということになります。
    ここでは上のコードが何を示しているのかを簡単に解説します。
    256,272,44410,1,8,0:3:0:0:
    (X座標),(Y座標),(タイム),(NC),(ヒットサウンド),(Sampleset):(Additions):(不明):(volume):
    X座標/Y座標:composeで見たときのオブジェクトの位置を示しています。ここで配置が決まっているのです。
    タイム:オブジェクトが現れる時間がここに記されています。単位は(ms)です。ここを見て基本的に探し出します。
    ヒットサウンド:whistleだけで2、finishだけで4、clapで8、finish+whistleの2つで6、finish+whistle+clapで14と加算方式で記されています。
    Sampleset/Additions:0~3までの間で変動し、NormalやDrumを割り当てることで変化します。
    不明:私も長くosuをやってきましたが、ここは何を記載する場所なのか分かりません。
    volume:sample import機能を使用して、主にosu!mania向けの設定方法を使用した場合のみ変化します。
    standardでもその機能を一部使えるので、時々ここが0ではない譜面を見ます。
    volumeの後の文末に、上記のsample import機能を使った場合のみwavファイルについての記述が追加されます。

    スライダーやスピナーだと記述が異なってきますが、X座標Y座標、タイム辺りは共通なのでタイムから検索を掛けて探し出してください。
  2. 上記のSBのコードを抽出する場合
    ある程度SBに関する知識を有している事を前提として話を進めます。

    Editorで画像を選ぶと上のように画像に関する詳細が少しだけ表示されます。
    例として出したこの画像の場合、osuファイルもしくはosbファイルのどちらか、
    SBについて記述がなされている方の"4921行目辺り"にこの画像について記載されたコードが存在していることになります。
    しかし他の画像も合わさって出てきて、どれがどれだか分からなかったり、
    何故かその画像詳細に関する白い文字での記載が出ないことがあります。
    その場合は配置の時同様にmsから探し出したり、フォルダ内の画像一覧から画像を見つけて、画像名の検索から探すことになります。

    タイムから探し出す場合は、上記のタイムラインから、オブジェクトのなにかエフェクトの開始/終了タイミングを見つけ、
    現在のタイムをコピーし、それを用いて検索をかけて見つけます。
抜き出したコードはフォーラムで直接貼ると、一部のコードが適切に表示されない場合があります。
なので、"code"コマンドを使用することを強く推奨します。詳細はコマンド項目にて。
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

IRC Mod


modと聞くとフォーラムで指摘を並べてpostするというのが一般的ですが、
それ以外にも主要なものとしてIRC経由でmodをする方法があります。

modに不慣れな内はあまり利用することは無いかもしれません。
しかし慣れてくるとこれを利用する場面が出てきます。

先にこの方法でmodするメリット/デメリットについて

メリット
  1. 提案に対してすぐに反応を知ることができ、modの方向性をその場で決められる
  2. 疑問があればその場で聞いて、それに合わせたmodに対応させることができる
  3. メモ帳と睨み合いにならず、比較的楽な気持ちでできる
デメリット
  1. modderとmapper両方のログイン時間帯が合わなければいけない
  2. 相手のマッパーはmodを受けながら修正することになるので負担が大きい
  3. 上記のこともありチャットが長引くことも多く、状況次第では数時間拘束することになる
  4. 即時判断が必要になるので、経験が少ない人や考える時間を長めに取りたい人には向かない
  5. 連続で否定され続けるとお互いにかなり気まずくなる
  6. 指摘を書いている最中に、いくつか前に指摘した内容に対しての返事が来たりする
  7. 考えている最中にチャットが飛んで来ると集中が途切れる(個人差あり)
メリット/デメリットを比較してどう感じるでしょうか。

私はIRCに関しては「その場で相手のmodへの反応を見て柔軟な対応ができる」という点が非常に大きなメリットだと感じています。
メモ帳でmodをするとグダグダになってしまう…という方にもお勧めしたい方法です。
しかし相手との関係性だったり、譜面との相性で変わってくる場合も多くあるため、
その時の状況に応じ、この方法を選ぶかどうかを決めていく形になると思います。

では実際にどういった手順でしていくのか、その説明をしていきます。
IRC modを実際にする前に、自動でPMを保存する機能をオプションで予め有効にしておきます。

保存したいチャット枠を開いた状態で"/savelog"をすることでも保存はされますが、
クライアントクラッシュなど不慮の事故に備え、こちらを有効にすることを強く勧めます。

IRCでもmodという意味ではやることは同じです。
何か譜面を見ていて問題や提案があれば、理由や改善案をどうするかある程度考えた上で話を切り出していきます。
特にこういったケースで即画像を撮り、貼ることができるpusshが力を発揮するので、是非採用を。

modが終わった後は
osu!\Chat\(プレイヤー名).txt
に保存されているので、modした部分のテキストをコピーし、modした譜面のフォーラムにチャットログをpostします。
この際codeのコマンドを使ってpostすることを個人的にお勧めします。
Beatmap系のフォーラムで"[]"で囲った文字を打つと、特殊な表示になる仕様があり、そこからフォーラムで意図しない表示になるケースがあります。
なので、とりあえずcodeコマンドで囲うと崩れることが無くなるので良いでしょう。
メモ帳でmodを書くのとなんら変わりはありません。
特に難しいことでもないので、気楽にやりましょう。

modする側からマッパーにIRCで頼みに行く機会はあまりないかもしれませんが、
逆に相手からチャットでリクエストされた場合など、この方法でmodをする機会は時々あります。

こういったmod方法もあるんだ、と頭の片隅に入れておいてもらえれば役立つ機会があるでしょう。

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

コマンド


ここまでで基本的な内容は記載しましたが、modのpostをするにあたり覚えておくと便利なコマンドをまとめました。

code例と実際にどう見えるか記述します。

これはカラー系コマンドで何か重要なことを書いたり強調したい時に使用します
色は自由に変えられるのでお好みの色をチョイスして下さい
[color=#FF0000]これはカラー系コマンドで何か重要なことを書いたり強調したい時に使用します[/color]
[color=#0000FF]色は自由に変えられるのでお好みの色をチョイスして下さい[/color]
文字を強調表示させます
[b]文字を強調表示させます[/b]
下線を入れます
[u]下線を入れます[/u]
斜体になります
[i]斜体になります[/i]
https://osu.ppy.sh/wiki/Ranking_Criteria
Ranking Criteria
任意のURLにリンクします。osu以外のリンクも有効で、外部リンクを使用するときなどに使用してください。
[url]https://osu.ppy.sh/wiki/Ranking_Criteria[/url]
[url=https://osu.ppy.sh/wiki/Ranking_Criteria]Ranking Criteria[/url]

画像をフォーラムに貼るコードで、puushやimgurのような外部リンクも利用可能です。
配置の提案をするときなどに特に有用です。
[img]http://w.ppy.sh/a/a9/Kudosu_Durp.png[/img]
例1
123456
クリックすると開くようにさせます。画像が場所を取ったりする際にimgと組み合わせると良いでしょう。
[box=例1]123456[/box]
[box=例2][img]http://w.ppy.sh/a/a9/Kudosu_Durp.png[/img][/box]
  1. 箇条書きに役立ちます
  2. listと/listで囲まなければ効果がないので注意
[list]
[*]箇条書きに役立ちます
[*]listと/listで囲まなければ効果がないので注意
[/list]
  1. listに=1や=aと加えることで文頭に数字や英字を出すことができます
  2. 提案の際の選択肢を提示するときに私は使っていました
  3. 地味に便利なので覚えておくと良いでしょう
[list=1]
[*]listに=1や=aと加えることで文頭に数字や英字を出すことができます
[*]提案の際の選択肢を提示するときに私は使っていました
[*]地味に便利なので覚えておくと良いでしょう
[/list]

このコードの例を出す際に使用しています。
コードが文章に含まれている場合や、少し強調して譜面のコードを書きたい場合などはこれを利用してください
[code]このコードの例を出す際に使用しています。
コードが文章に含まれている場合や、少し強調して譜面のコードを書きたい場合などはこれを利用してください
[/code]

[notice]見た目を整える時にでもどうぞ[/notice]
見た目を整える時にでもどうぞ

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

テンプレート


modをpostする際、相手にとって見やすい書き方というのがあります。
自分用のテンプレは持っておくとフォーラムで見た時綺麗になり便利です。

以下の物は実際に現役の時、私が使っていたテンプレになります。
必要ならば使用してください。
Modding テンプレート
[color=#FF0000]赤字[/color]: [color=#FF0000][b]ルール上問題のある内容です[/b][/color]
[color=#0000FF]青字[/color]: [color=#0000FF][b]ルール上問題となり得る内容です[/b][/color]
[b]太字[/b]: 問題/指摘
[u]下線[/u]: 理由
[i]斜字[/i]: 解決策

[General]
[list]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[/list]

[難易度1]
[list]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[/list]


[難易度2]
[list]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[/list]


[難易度3]
[list]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[*]
[b][/b]
[u][/u]
[i][/i]
[/list]

gl
実際の表示例
赤字: ルール上問題のある内容です
青字: ルール上問題となり得る内容です
太字: 問題/指摘
下線: 理由
斜字: 解決策

[General]
  1. offsetがズレているように感じます。
    offset: 782 (+45)を試してみてください
  2. soft-hitclap8.wavは使用されていません。
    [quote="Ranking Criteria":1337]There must not be any unused files in the map's folder except for the map's .osb file (since they sometimes get added even if the map doesn't have a storyboard) and storyboard .thumb files (since they are automatically created in image directories). Unused files add extra file size which is unnecessary.上記のルールに従って削除をする必要があります。
[Insane]
  1. 00:08:576 (1,2,3) - 1/2スライダーと3連打で分けたほうが聞こえが良いように感じます。
    前のパートである00:07:765 (1,2,3,4) - がそれをしていて、見ていて気になる一貫性上の理由からくる違和感とInsaneとしての難易度バランスの2つを理由にこれを強く推奨します。
  2. 00:18:508 (4) - 00:18:711 のボーカルを無視したのはなぜ?
    "つ"の音は音として弱くはなく、それを無視することはボーカルをフォローしておいているこの譜面全体と反する音つけになります。
  3. 00:23:170 - ここのstreamから拾う音が明確にかわります。
    よって小さな音量を維持させる必要性は全くなく、むしろそこを強調するために少しだけ大きめの音量設定をした方がベターであるように感じられました。
    カスタム1で50%に変更させる緑線を入れてみるのはどうでしょうか?
  4. 01:03:103 (1,2,3,4,1,2,3,4) - clapを外しsoftでwhistleだけを入れてみるのはどうでしょう。
    ここではそのupbeatのリズムを無視したリズムになっているので、clapを入れる必要性は殆ど無いと思います。
    さらに音量を50-60-70という感じでstream中で段階的に上げると曲とより合うはずです。
この難易度を見ていて、ヒットサウンドがあまりパターン化されておらず、矛盾を多く抱えているように思えました。
特に気になった点を今回は挙げましたが、それについてはより多くmodを受けたほうが良いでしょう。
と言った具合で、単純に文字を並べるよりも少し見栄えがよくなります。
余力があれば是非、自己流のテンプレを作って活用してみると良いでしょう。

ちなみに私は入力が面倒なので、マクロキーの付いたキーボードを用いてmodを行っています。

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

modをする時の最低限のマナー

  1. 煽らない、煽られてもそれに乗って争わない
  2. 他の人に助けてもらったら感謝の気持ちは伝える
  3. 何かトラブルを起こしてしまったら謝る
これらはふざけて書いているわけではありません。
小学生の喧嘩のようなpostをしてしまう方が少なからずいるため、こうして記載しています。

modをしていても考え方の違いから、様々なトラブルが起きることはあります。
しかし我々は子供ではありません。冷静に社会人としての対応をもって乗り越えてください。
これは日本人同士のやり取り、さらに言えばosu!に限ったことではありませんね。
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

Mod上達のために


既に書いた内容も含まれていますが、上達のためにどういった意識を持って臨むかという心構えについてです。
  1. 指摘をしなければいけない理由を自分の中ではっきりさせる。
  2. 相手の譜面を尊重し、その譜面を壊さない提案を意識する。
  3. 細々とした指摘を100するより、本質を突いた1つの指摘のほうがマッパーに喜ばれることを早い段階で理解する。
    長々とした指摘の多いmodは一見すごいように見えますが、時間を掛ければ誰でもできることです。
    "多く書くこと≠良いこと"です。
  4. modへの返事が来た場合、どの提案が通り、どれが通らなかったのかを把握し、拒否された理由から学習し次に繋げる努力をする。
    また他の人の指摘をチェックし、どんなことを指摘していたのかを学ぶことで今後の指摘のバリエーションを増やす。
  5. 自分の譜面への優れたmodは何よりの成長剤となります。受けて嬉しい指摘がどんなものなのか、その身で体験してください。
  6. 継続は力なり。ただしkudosuをたくさん持っていても、向上心がなければ能力の低いmodder止まりです。
より上達するためには"研究"が必要となります。
現役のBNやQATがどんなことに注目しているのか等もチェックすると良いでしょう。元BNでも一部は除きますが高いmod能力を持っています。
一朝一夕で上達するものでもないので気長に頑張ってください。上記のことを意識して1年も継続すれば一人前のmodderになれます。

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

Modする際に有用なリンク集


wiki:osuコミュニティールール
wiki:Ranking Criteria: StandardTaikoCatch the Beatosu!mania
wiki:スキンセット standardのスキンセット
wiki:AIBat
wiki:SB Editorについて
wiki:Storyboard Scripting General Rules (各種コードはページ下から)
wiki:Modding
wiki:Music Theory
wiki:kudosu

Ranking Criteriaについての議論一覧
[Guide] Becoming a BN
Beatmapping/Modding: Guide Compendium
Modding assistant

日本語フォーラム:日本人BNG/QAT/GMT/Alumniリスト (ここから現在、過去のスタッフ情報を見てmodの参考に)
日本語フォーラム:初心者Mapper向け - Storyboardガイド

wikipedia: ヘボン式ローマ字

puush (スクリーンショットをお手軽に撮れ、あらゆるファイルが上げられますが、登録が必要でフリーだとトータル200MBまでしか上げられません)
audacity (wavファイルの簡単な編集、音のピッチ変更、遅延チェック等osuで必要とされる編集はこれ一つである程度いけます)
xrecode II (様々なファイル形式にビットレート変更含め変換できるので、個人的に使用しています)
GIMP (画像の簡易的な編集ができ、osu用途では一通り必要なことができます)
waifu2x (劣化を抑えて画像を拡大してくれるサイト)
サクラエディタ (テキストエディタ、メモ帳だとできないあれこれができるので入れておくと何かと便利です)

―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

最後に


2016年という年で日本のマッピング界の勢いの衰えを感じ、少しでも支援できればと思いこのスレッドを建てました。
moddingがどういったもので、どういった点を見ればいいのかといった初歩的で簡潔な内容ですが、
これからmodを始めようと考える人への助けとなれば幸いです。
またこのスレッドを見て、modderになろうという方が一人でも日本のコミュニティーの中から出てくれれば嬉しく思います。


Special Thanks
alacat, Gamu, KSHR, Satellite, thzz

以上のosuスタッフ、元スタッフ、modderの助言を受け一部構成をさせて頂きました。
思いつきでの行動にも関わらず快く協力してくださり、ガイド作成において非常に大きな助けとなりました。
改めてお礼申し上げます。
Topic Starter
NewRulerNA
changelogs
  1. 17/01/18 : 幾つかの表現を修正
  2. 17/01/30 : 誤った表記の修正
  3. 17/01/31 : 用語をいくつか追加
  4. 17/04/06 : BNのTier1/Tier2について追加
  5. 17/09/17 : BNの記述とRankに必要な泡に関しての記述を変更
Satellite
good job XD
Kashimaria
this thread is so helpful, nice work :D
alacat
作成お疲れ様です!

現在日本人のBN/QATは私しかいないので、何か質問があればPMで受け付けます。
Gamu
nice :3
お疲れ様です。

少しでも日本語フォーラムが充実するように、私も何かやる予定です(必ずやるとは言っていない)
Guy
もうmodやる機会なんてないだろうけど思わず見入ってしまいました…
お疲れ様です ;)
S o h
凄く詳しく書いてあるので参考になります、お疲れ様です。
Muya
お疲れ様でした
この様な日本語版ガイドは今までにありそうでありませんでしたね :oops:
rrtyui
やはりるーらーさんの解説は最高やな!お疲れ様です~
terametis
:) :) :)
Please sign in to reply.

New reply