如果你在 B 站刷到「CJC 1st 决赛Cytus II 自制谱《覆写者》CHAOS 15 谱面演示」这样的标题第一反应多半是“这个玩家手速真快”“这谱面好密”。但如果你切换成创作者视角会发现更值得关注的问题这一整屏飞速移动的 note到底是怎么被设计出来、验证无误并最终展示给观众的 我个人的判断是一张高质量自制谱面本质上是一个带时间轴的交互事件系统它同时涉及音频分析、关卡策划、动效设计和工程质量控制。只看“难不难”会错过真正有价值的技术部分。本文不打算评价《覆写者》这个谱面本身的好坏因为通过标题能够确认的信息有限我不会假装亲手玩过或读过它的工程文件。我想做的事情是通过“CJC 1st 决赛 / CHAOS 15 自制谱”这个引子把 Cytus II 自制谱面背后的完整工程链路讲清楚。读完你会明白BPM 标定、note 类型、扫描线动线、难度曲线、谱面校验、评审维度都不是玄学而是可以被拆成数据和代码的内容。即使你不是音游玩家也能从这套链路里看到交互设计与软件开发高度重叠的地方。这篇文章按 CSDN 读者的习惯来组织先建立核心概念再拆制作流程然后给一个简化谱面结构和一个可运行的 Python 校验脚本最后整理常见问题与工程建议。涉及具体工具和赛事规则时我会采用稳妥表达不写死版本号因为不同工具、不同赛事规则本来就有差异。下面直接进入正文。1. 自制谱面不是“画音符”而是一次编排工程很多刚接触音游自制谱的人会默认做谱就是把音符按照节拍摆上去。这个理解只对了一小半。真正开始做之后你会发现制谱人同时承担着四种角色音频标注工程师、关卡策划、动效导演和 QA 测试。第一个角色负责找到音乐中的重音、段落和情绪转折点第二个角色决定玩家在哪个时间点承受多少压力第三个角色决定 note 出现在屏幕什么位置、扫描线怎么运动第四个角色则要反复试玩把手感问题一个接一个找出来。这四件事放在软件开发里对应的是需求分析、系统设计、UI 动效和测试回归。为什么说 CHAOS 15 不等于“无脑密”因为高难度谱面真正的难点不是单位时间内的 note 数量而是“密度差”的设计。一段 15 级谱如果从头密到尾玩家的读谱系统很快会疲劳甚至会失去对音乐重音的感知。好的高难谱会像写作一样有起承转合密集段、停顿段、长按喘息段交叉出现。密度曲线不只是用来“炫技”它本身就是一种表达节奏的手段。从这个角度理解做谱和写代码非常像。你要先定目标体验再拆功能模块再做实现最后通过测试和反馈迭代。那些看起来很“神”的决赛作品背后大概率经历过几十次版本修改。所谓“手感好”其实就是经过充分调试后玩家操作与音乐反馈之间的误差被压缩到了一个可接受范围内。2. Cytus II 谱面核心概念与基本原理在拆流程之前需要先把 Cytus II 的基础玩法讲清楚。Cytus II 的画面中有一条动态扫描线它会在屏幕中上下移动note 则分布在扫描线附近的轨道上。玩家需要在扫描线到达 note 判定位置的时候完成对应的点击、长按或拖动操作。这种设计与其他音游不同很多音游的 note 是沿着固定轨道下落而 Cytus II 的 note 是“等待扫描线来扫过它”。自制谱面的最小单位是音符事件也就是 note。Cytus II 中最常见的几类 note 包括 Tap、Hold、Drag。Tap 是到达判定点时点按一下Hold 是按住直到结束时间Drag 则是沿着一定轨迹滑动。三类 note 在谱面数据里的表达方式不同设计用途也不同。社区工具导出的谱面文件核心内容通常就是一个带时间戳的 note 数组这个数组本身就是一份“事件流”。为了直观理解可以把三类 note 和常见的交互设计对比一下note 类型玩家操作设计用途常见误用Tap扫描线到达时点击表达鼓点、重音、旋律强调在低音鼓上连续堆叠读谱困难Hold到达起点后按住到结束长音、持续音、留出呼吸空间结束点与音乐重音不对齐Drag按轨迹滑动旋律滑音、视觉引导、段落过渡轨迹跨度过大导致手臂位移突兀Cytus II 官方谱面有 Easy、Hard、Chaos 等难度。自制谱社区里常见的 CHAOS 15可以理解为社区自行评估后的一个高难等级不代表官方标准。CHAOS 15 通常意味着高密度、快速切分和复杂动线但它并不只是一个“更难的标签”而是制谱者对玩家能力边界的一种假设。请特别注意不同社区的难度标准不完全一致所以看谱面演示时更值得关注的是“这张谱如何用密度变化制造情绪”而不是纠结“15 级到底对不对”。如果从数据结构的角度看谱面它并不神秘。一个 Tap 至少需要三个信息触发时间、横向坐标、纵向坐标。一个 Hold 需要额外记录结束时间。一个 Drag 需要记录整条轨迹的关键点。这些字段组合起来的数组就是游戏端渲染和判定的输入。换句话说做谱就是在编辑一份“时间 坐标 类型”的 JSON 数据。3. 从 CJC 决赛作品看自制谱评审视角CJC 是社区中常见的自制谱赛事缩写不同届次、不同赛区的规则并不完全一样。CJC 1st 决赛这个表述说明参赛谱面是从多轮筛选中走过来的通常已经过初选、复评和决赛答辩等环节。赛事的意义不只是排一个名次而是通过评审反馈倒逼制谱者提升对音乐、手感与视觉设计的理解。社区评审通常围绕几个核心维度展开音乐同步度、难度合理性、可读性、视觉表现、创新性。其中音乐同步度是基础note 是否压在重音上、是否跟随旋律线条这是可以量化检查的。难度合理性指的是难度曲线是否自然有没有“开头就把玩家榨干、后面反而没东西”的问题。可读性则是指玩家在高速移动中能否看懂下一个 note 在哪里刷出来。视觉表现和动线相关扫描线和 note 位置的移动本身就能形成节奏感。用工程思维去看评审你会发现这些维度其实都有对应的数据指标。音乐同步度可以通过计算 note 时间与音频节拍点的误差来捕捉难度合理性可以绘制密度曲线和重音分布曲线来判断可读性虽然偏主观但至少可以检查 note 重叠率、相邻 note 的横向间距、扫描线移动方向突变频率。就是说评审经验中相当一部分可以被自动化脚本辅助量化。CJC 决赛作品之所以值得拆解并不是因为它“看起来很难”。而是因为走到决赛的谱面经过了反馈循环制谱、试玩、评审、修改。这个过程和代码走查很像你写出一版别人指出问题你再改改完继续验证。最终呈现出来的“爽感”其实是很多次“不满足”之后的产物。4. 自制谱面制作完整流程拆解接下来进入核心流程。整个制谱过程可以拆成六个阶段每个阶段都对应一套可执行的任务。这里先给一个整体认知不要跳过任何一步。很多人做第一张谱时直接从“摆 note”开始结果做到一半发现 BPM 标错了全部返工。先做音乐分析再做事件设计最后统一验证才是效率最高的路径。4.1 选曲与音乐结构分析做谱的第一步不是打开编辑器而是反复听歌。选曲决定了很多后续工作尤其是 BPM 和拍号。拿到一首歌后先找出它的 BPM 范围、拍号、主歌副歌段落、有没有变速段。如果有乐谱或标注工具会更容易没有的话只能手动听。这一步的技术要点是任意两拍之间的时间间隔决定了 note 的最小时间单位。比如 180 BPM 下四分音符一拍约等于 333 毫秒八分音符约 166 毫秒十六分音符约 83 毫秒。高难度谱面的密集段通常会把 note 排布到十六分音符甚至三十二分音符级别。如果你的时间轴标定误差超过几十毫秒连最基础的 Tap 都会听起来“不在拍上”。4.2 BPM 与 offset 标定听歌确定了 BPM 之后还需要确定 offset也就是音乐文件中第一拍相对于时间轴起点的偏移量。这一步最容易出错。因为很多曲子不是第一个采样点就是重音可能有一段空白或引子。标定时可以先把整个音频波形导入编辑软件找到第一个明显的底鼓或拍点再确认这个拍点相对时间轴的位置。BPM 和 offset 是谱面的地基。地基一旦错误后续所有 note 的时间都会系统性偏移。常见现象就是谱面里的 note 一个个看都排得整齐但游戏内试玩时全都不准。这时候不要再逐个调整 note应该回到整体 offset 设置去修正。所有制谱工具通常都支持整体平移时间轴这比手动改几百个 note 高效得多。4.3 分层设计与音轨拆分音乐不是一整块。一首歌里通常有主旋律、底鼓、军鼓、贝斯、人声采样、合成器音色等多个层次。做谱时比较好的做法是先把音乐拆成多个层再决定每一层用什么 note 来表现。比如底鼓重音适合用 Tap 表现长音或持续和弦适合用 Hold旋律滑音适合用 Drag。你可以先创建三个空层分别命名为 melody、beat、bass然后在每个层内填充对应的事件。分层的好处是当你觉得某一层的密度过高时可以单独调整这一层而不是在密密麻麻的总 note 列表里找。这里真正容易踩坑的地方是层与层之间的 note 时间如果靠得太近会在渲染时重叠。玩家在屏幕上看到两个 note 叠在一起就会不知道该点哪一个。所以分层设计之后一定要做一次“冲突检测”找出时间差小于某个阈值且位置接近的 note。4.4 难度曲线铺设难度曲线是决定一张谱是“爽”还是“恶心”的关键。你可以先把整首歌按段落切分比如前奏、主歌 A、副歌、间奏、主歌 B、尾奏然后为每一段设计一个目标密度。不要试图让每一段都一样难而是要有起伏。CHAOS 15 这种高难级谱面通常会设置几个明显的“爆发点”。在爆发点之前可能会刻意降低密度让玩家有时间调整手位在爆发点之后可能会出现一段 Hold 或 Drag 组成的缓冲段。这是一种节奏管理手段和激烈运动后的整理放松很像。做难度曲线时可以把每个段落的 note 数量除以时长得到平均密度然后画成一张折线图查漏补缺。4.5 扫描线动线与视觉层级设计Cytus II 的特殊之处在于扫描线本身就是视觉引导工具。扫描线的移动方向、快慢和停顿会影响玩家对下一个 note 的预判。如果扫描线突然反向而 note 也出现在反向路径上玩家很可能反应不过来。因此动线设计要和 note 出现位置配合好不能各做各的。一个常见的视觉层级原则是重要 note 放在扫描线优先扫过的路径上非重要装饰 note 放在次要位置。高难谱里尤其要注意“读谱引导”。你可以用颜色或大小区分 note 类型但要避免在一个视线区域内同时出现过多强烈信号。如果一张谱面在回放视频里显得“乱”那通常不是玩家的问题而是制谱阶段没有做视觉分层。4.6 测试、修改与回归做完一版谱面后第一件事是导出文件用模拟器或游戏内置模式试玩。第一次试玩不要直接挑战最高速度建议把谱面速度调慢一点先看时间轴是否准确再看手位转换是否自然。试玩时最好录屏回放时能发现很多“当时觉得没问题”的细节比如某个 note 总是 miss、某段 Drag 扫起来很别扭。修改完成后不要立刻认为结束了。新增修改有很大概率引入新的问题比如把某个 Tap 的时间往前移了 10 毫秒导致和后面的 Hold 起点冲突。所以每轮修改后都要重新跑一遍校验脚本和一次完整试玩这就是回归测试。一套稳定的自测流程比“灵感爆发”更能保证谱面质量。5. 完整示例谱面 JSON 结构与校验脚本为了让前面的概念落地我们用一个简化示例演示谱面事件结构和校验方法。注意社区工具的实际格式各有差异我这里给出的是一个示意结构重点是讲清楚“时间、坐标、类型”如何组合成一份可解析的谱面数据。5.1 一种常见的谱面事件结构假设有一个 JSON 文件overwritter_demo.json内容如下。它包含元信息、BPM、offset 和 notes 数组。每个 note 至少包含 type、start_ms、坐标Hold 额外带 end_msDrag 额外带 points 数组。{ title: Overwritter_ Chart Demo, version: 0.1.0, bpm: 180, offset_ms: 20, notes: [ { type: tap, start_ms: 1000, x: 0.25, y: 0.50 }, { type: hold, start_ms: 1166, end_ms: 1500, x: 0.50, y: 0.50 }, { type: drag, start_ms: 1350, points: [ { x: 0.50, y: 0.50 }, { x: 0.80, y: 0.50 } ]} ] }字段含义可以这样理解start_ms是 note 开始的时间单位毫秒x和y是屏幕坐标0 到 1 表示相对位置end_ms是 Hold 结束时间points是 Drag 轨迹的关键点。实际工具中可能还有更多字段比如宽度、长度、扫描线移动路径等但核心思路是一样的。5.2 Python 校验脚本下面这段 Python 脚本用于检查谱面文件的基础合法性包括时间是否按顺序排列、坐标是否越界、Hold 结束时间是否大于开始时间、Drag 是否包含足够的轨迹点以及一个简单的密度统计。脚本可以直接保存为chart_validator.py使用。import json import sys def validate_chart(path): with open(path, r, encodingutf-8) as f: data json.load(f) notes data.get(notes, []) errors [] last_time -1 for idx, note in enumerate(notes): n idx 1 ntype note.get(type) start note.get(start_ms) if not isinstance(start, (int, float)): errors.append(fnote {n}: start_ms 缺失或不是数字) continue if start last_time: errors.append( fnote {n}: start_ms{start} 小于上一个 note 的时间时间轴未排序 ) last_time max(last_time, start) x note.get(x, -1) y note.get(y, -1) if not (0 x 1 and 0 y 1): errors.append(fnote {n}: 坐标越界 x{x}, y{y}应在 0~1 之间) if ntype hold: end note.get(end_ms) if not isinstance(end, (int, float)) or end start: errors.append(fnote {n}: hold 的 end_ms 必须大于 start_ms) elif ntype drag: points note.get(points, []) if len(points) 2: errors.append(fnote {n}: drag 至少需要两个轨迹点) if errors: print(fchart validation failed: {len(errors)} error(s)) for err in errors[:50]: print( -, err) return 1 max_density compute_max_density(notes) print(chart validation passed) print(ftotal notes: {len(notes)}) print(fmax density (per 1000ms window): {max_density}) return 0 def compute_max_density(notes, window_ms1000): times sorted(n[start_ms] for n in notes) max_count 0 left 0 for right in range(len(times)): while times[right] - times[left] window_ms: left 1 max_count max(max_count, right - left 1) return max_count if __name__ __main__: sys.exit(validate_chart(sys.argv[1]))这段脚本做的是最基础的校验对应制谱过程中“数据是否合法”这一层。拿到一份谱面后先跑一遍这个脚本比直接导入游戏后反复试玩更能快速定位问题。真正进入游戏内验证时还会用到手感、视觉层级、跟手度这些无法完全自动化的维度。5.3 运行命令与预期输出把上面的 JSON 文件保存为overwritter_demo.json然后在命令行执行python chart_validator.py overwritter_demo.json预期输出如下chart validation passed total notes: 3 max density (per 1000ms window): 2这里展示的是最简示例所以 note 数量只有 3 个。实际自制谱通常有几百到上千个 note校验脚本的价值会明显放大几毫秒的时间错位、某个 Hold 的结束点比开始点还早这类问题如果靠肉眼在海量日志里找会非常痛苦而脚本能在几秒内定位。如果你把这段逻辑接入 Git 的 pre-commit hook每次提交谱面文件前都会自动检查一次。6. 运行结果与效果验证脚本校验通过只是表示事件数据结构合法不代表谱面“好玩”。真正的效果验证需要分两步走。第一步是在模拟器或游戏内置编辑器中加载谱面文件确认 note 能被正确读取和渲染第二步是录制一段试玩视频对照音乐逐段核对手感与同步度。验证成功最直观的判断标准是在正常游戏速度下玩家不需要刻意记谱也能看出 note 的移动方向并且点击反馈与音乐重音基本重合。如果试玩时频繁出现“明明点了却 miss”或“节奏是对的但手感很奇怪”多半要回到时间轴或判定区域设置上去检查。最好打开录屏把画面和音频放在一起逐帧看观察 note 是否真的压在重音上。如果导入失败第一步应该先看日志。常见原因是 JSON 字段名不匹配、坐标超过游戏画面边界、或某类 note 缺少必要字段。这时可以用我们前面写的校验脚本先跑一遍如果校验已经通过再检查工具的导入版本和编码问题。记住一个原则不要直接改 note 位置来“补偿”时间轴错误先把 BPM 和 offset 调对。7. 常见问题与排查思路下面整理自制谱面过程中最常遇到的几类问题。这些问题大部分都能通过“先看时间轴、再看数据结构、最后看手感”的顺序解决。问题现象可能原因排查方式解决方案所有 note 都感觉慢半拍BPM 或 offset 标定不准确回到波形找第一个重音位置重新标定 BPM/offset整体平移时间轴只有某些 note 对不上拍切分音细分没有对齐检查有没有三连音、十六分按拍号细化时间格逐段修正Hold 总在中间断掉手位转换和扫描线方向冲突回放录屏看手是否被后续 note 带离调整后续 note 的位置留出 Hold 持续窗口Drag 轨迹几乎划不到轨迹跨度过大或方向突变使用模拟器显示轨迹辅助线增加中间关键点平滑轨迹note 密集段看起来像一团乱码视觉层级混乱检查 note 重叠率和相邻间距分层调整减少同屏强信号数量文件能打开但进入歌曲后闪退数据中有非法字段查看崩溃日志和 schema 校验用标准字段替换自定义字段确认双端兼容导入后全部 note 位置偏移画布比例和坐标基准不同计算 x/y 是否被重新映射用工具的标准坐标范围重新导出这里特别想提醒的是不要在一张 1000 note 的谱面上逐个人工排查。先把问题归类属于时间轴的整体问题要全局修属于单个 note 的局部问题再单独处理。很多制谱新手会把大量时间花在“改那一个看起来不对的 note”上结果越改越乱最后发现是整体 offset 错了。8. 最佳实践与工程建议如果你准备认真做一张自制谱我建议把它当成一个小型软件项目来管理。目录结构可以按照“原曲文件、工程文件、导出文件、测试录像、文档”来划分每个版本保留可回溯的副本。不要直接在原始工程文件上反复修改而不备份否则一次误操作就可能让几天的成果消失。谱面文件建议统一使用 UTF-8 编码、无 BOM并尽量保持字段命名一致。做多张谱时可以维护一份自己的 schema 模板减少格式错误。Git 是管理谱面版本的好工具每一次大修改对应一个 commit提交信息可以写“调整副歌段密度”“修正第 220 毫秒处 Hold 结束点”“整体偏移 15ms”这样几个月后回看还能知道当时的思路。校验脚本可以进一步扩展。除了排序和坐标检查之外还可以加入最小 note 间隔检查、指定时间窗内密度统计、拖动轨迹与扫描线重叠检测。有条件的话把校验脚本集成到 CI 或 Git pre-commit 中提交谱面文件时自动运行。这样能防止“改一个 note 又引入两个新问题”的回归。谱面做出来后发布前要确认音乐版权与社区规则。自制谱通常用于学习交流和个人展示公开发布时尽量确认曲目授权状态、标注曲目来源并遵守赛事或平台的投稿规则。不要在他人的商业内容上直接叠加自制数据并以官方名义发布。性能方面高难度谱面动辄上千个 note在编辑器或预览器里如果每一帧都遍历全部 note会出现明显掉帧。更好的做法是把 note 按 start_ms 排序然后用二分查找只处理当前时间窗口内的事件。这一个优化思路也可以用在自制谱工具链的开发中是典型的“数据有序化带来性能收益”的案例。团队协作时统一 schema 比统一编辑器更重要。不同制谱者可能使用不同工具但导出后的 JSON/文本结构可以尽量规范。评审别人谱面时尽量给出一手数据、一手主观反馈数据指密度、时间误差、重叠率主观反馈指手感、读谱舒适度、情绪曲线。把客观数据与主观体验分开评审才能真正帮助人改进。9. 总结与后续可以做的三件事回到标题中的《覆写者》CHAOS 15 谱面。我们无法只看标题就判断它的设计质量但我们可以确定任何能进入 CJC 决赛的谱面背后都有一套完整的创作与验证流程。从音乐分析到事件数据设计从难度曲线到视觉动线再到多轮试玩和评审反馈整个链路和软件项目迭代几乎同构。如果你看完这篇文章后想动手我建议从三件事开始。第一选一首你非常熟悉的歌手动标出 BPM 和段落结构这一步不碰编辑器只训练音乐分析能力。第二用本文的校验脚本做一个最小谱面 JSON模拟一个 8 小节的 Tap Hold 序列体会时间轴和坐标的关系。第三去拆解一个你喜欢的公开谱面视频记录它每 10 秒的密度变化和扫描线方向尝试画出一张难度曲线草图。等你能画出清晰的曲线时再打开编辑器正式做谱效率会高很多。制谱这件事表面上是“音游玩家炫技”实际上是交互设计、数据分析、工程验证的综合练习。如果你只收藏不实践那它只是一个知识点真正动手做一张谱后你才会理解什么叫“把音乐编译成可交互的事件流”。建议收藏备用等你有想做的曲子时再回来对照这篇文章的流程。