用时间与创作者扩展玩法：老资历、歌曲大排序与“闪耀的 Producer”

从“猜出歌名”走向“理解曲库”#

完成曲目猜猜看和曲名填字后，网站已经能够利用曲名、STAFF、发布时间、歌姬和声库等字段进行游戏。但这两个玩法的核心仍然是“认出一首歌”。

下一阶段，我想做一些不要求玩家立刻记住答案，却能让人逐渐建立曲库印象的玩法。发布时间是最适合的切入口：它容易比较，又能自然体现中文虚拟歌声文化的发展阶段。另一方面，歌曲 STAFF 中积累的大量 P 主信息，也为另一种人物猜谜玩法提供了基础。

于是，这一阶段形成了三个模块：

• “谁是老资历？”与反向的“谁是小资历？”；
• “歌曲大排序”；
• “闪耀的 Producer”。

谁是老资历：用连续比较建立时间感#

“谁是老资历？”的规则很直接：每轮展示两首发布时间不同的歌曲，玩家选择其中发布时间更早的一首。答对加一分，答错扣除一点生命值，三点生命耗尽后结束。

页面使用两张大卡片展示歌曲。曲名位于视觉中心，同时显示 STAFF、演唱歌姬、特殊标注和演唱会／生日会次数。发布时间在作答前隐藏，选择后再以醒目的 YYYY-MM 形式揭晓。

谁是小资历：复用规则，而不是复制一套游戏#

后来，我为这一模块加入了“谁是小资历？”：页面和生命值规则不变，但玩家需要选择发布时间更新的歌曲。

实现时没有复制整个游戏服务，而是增加 older 和 newer 两种比较方向。正确答案、按钮文案、历史记录、结算说明和承接逻辑都根据方向计算。

“连续三次”的规则也随之反转：小资历模式中，如果同一首较新的歌曲连续三次成为正确答案，下一轮就改为保留较早的另一首。这样两个模式共享相同的状态机，却保持各自完整的玩法语义。

图片增强与移动端布局#

为了让卡片更有识别度，项目增加了一份独立的图片清单，通过 VCPedia 的 MediaWiki pageimages 接口批量查询页面缩略图。查询结果会被缓存，开发和生产构建不会临时访问数据网站；没有主图或远程图片加载失败时，则显示主题色占位图。

图片只是增强信息，不是游戏成立的前提。歌曲数据、图片 URL 和游戏规则彼此分离，避免外部资源失效导致玩法无法运行。

移动端是这一页面调整最多的地方之一。两张卡片需要在常见手机视口内同时出现，因此图片、留白和信息字号都要响应式变化。长曲名还需要限制行高和可用高度，避免多行标题与 STAFF 重叠。

每张卡片还会从一组具有可靠文字对比度的颜色中随机取得主题色。正确、错误和选中状态仍然使用边框、图标与文字表达，避免只依赖背景颜色。

结算与整局回顾#

玩家可以随时点击结算，确认后立即结束游戏；生命值归零也会自动结算。弹窗会展示最终得分、完成轮数、正确数、错误数和评价：

• 0—4 分：初来乍到；
• 5—9 分：小有资历；
• 10—14 分：资深听众；
• 15—24 分：曲库考古家；
• 25 分以上：活化石级资历。

结算页会保留所有出现过的题目，包括两首歌曲、实际发布时间、玩家选择与正误。尚未作答时手动结算的题目则标记为“未作答”。与单纯显示分数相比，这份回顾更适合玩家复盘自己不熟悉的年代。

歌曲大排序：从单次比较走向整体时间线#

如果老资历玩法是在两首歌之间作出判断，那么“歌曲大排序”就是一次观察整段时间线。

玩法提供两种模式：

1. 时间线排序：系统抽取 5 首或 10 首歌曲，玩家拖动卡片，将它们按照发布时间排列；
2. 年份归位：系统提供年份，将每首歌曲放到正确年份。

两个模式都可以使用与曲目猜猜看相同的曲库范围和快速预设。

闪耀的 Producer：从歌曲 STAFF 中看见创作者#

曲库越来越大后，歌曲背后的创作者也逐渐形成了另一套值得整理的数据。项目目录中的 P 主统计表最终成为“闪耀的 Producer”的事实来源。

首版收录 104 位 P 主，其中 44 位被标记为“名 P”。每条记录包含：

• P 主名称和别名；
• 初投稿日期与年份；
• 出道曲；
• 五首代表曲 A—E；
• 殿堂及以上、传说、神话曲数量；
• 名 P 标记。

生成脚本会在开发、测试和构建前读取 Excel，并输出独立的 producers.generated.json。P 主数据不会混入歌曲 JSON，歌曲数据库与人物数据库只在界面层并列展示。

导入时还处理了实际表格中的数据问题，例如把泠鸢yousa的异常日期统一为 2013-02-05，并将 Suya 重复出现的代表曲替换为另一首不同作品。名称唯一性、日期、非负数量、五首代表曲和名 P 标记都会在构建前校验。

两种 P 主范围#

玩家可以选择：

• 名 P 模式：精选更具代表性、曲目更加出圈的 44 位 P 主，也是优先推荐的范围；
• 全 P 主模式：使用全部 104 位 P 主。

游戏支持名称、英文大小写、标点差异和括号内别名搜索。不存在或已经猜过的名字不会进入记录。

P 主线索如何比较#

猜测表格包含 P 主、初投稿年份、出道曲、殿堂及以上、传说、神话和代表曲七列。

• P 主名称只有猜中时标绿；
• 初投稿年份相同标绿，相差不超过两年标黄，并用箭头表示答案更早或更晚；
• 三类数量分别比较，相同标绿，接近时标黄；“接近”的阈值为 max(2, ceil(答案数量 × 20%))；
• 出道曲只有完全相同才标绿；
• 五首代表曲拆成标签，与答案重合的具体曲目单独标绿。

如果一次猜测与答案的初投稿年份完全相同，答案行会自动揭示初投稿年份和出道曲，但不会消耗提示次数。

三次递进提示#

目前提示顺序为：

1. 揭示初投稿年份、出道曲和代表曲 E；
2. 揭示殿堂及以上、传说、神话数量和代表曲 D；
3. 揭示代表曲 A、B、C，使五首代表曲全部可见。

答案名称会一直保持隐藏，直到玩家猜中或投降。开发环境还保留了指定答案工具，便于对特定 P 主的线索和结算流程进行测试。

答对或投降后，结算弹窗会展示完整日期、出道曲、三类数量、五首代表曲、模式、猜测次数和提示次数。P 主统计表也被接入数据库模块，方便不游玩时直接检索资料。

三个玩法背后的共通结构#

这三个模块看起来差异很大，但都依赖几项共同设计：

• 题库先由构建脚本规范化，UI 不直接读取 Excel 或 Markdown；
• 游戏规则放入独立服务层，React 页面负责展示状态和发送操作；
• 随机选题可以注入固定随机源，便于编写可重复测试；
• 结算结果保存完整历史，而不仅是一个总分；
• 桌面拖拽始终提供移动端或键盘替代操作。

当底层曲库持续增加时，这种分层能让同一份数据服务于完全不同的玩法，也让规则调整不必反复改动页面组件。

小结#

“谁是老资历？”把发布时间变成连续的相对判断；“歌曲大排序”把相对判断扩展为完整时间线；“闪耀的 Producer”则把关注点从作品转向创作者。

它们没有要求玩家一次记住大量资料，而是在选择、反馈和复盘中逐渐建立认知。对一个以资料库为基础的小游戏合集来说，这也是数据真正转化为玩法的过程。

项目仓库：LonakoBc/luo-yi-ba
在线试玩：luo-yi-ba.pages.dev