从数据到游戏：曲目猜猜看与曲名填字的玩法实现

第一个核心玩法：曲目猜猜看#

当曲库终于能够稳定生成后，第一个要完成的玩法自然是项目最初设想的“猜歌版弗一把”。

每局游戏会从玩家选择的曲库中随机抽取一首歌曲作为答案。玩家在输入框中搜索并提交猜测，猜错的歌曲会加入记录表，与答案逐项比较；猜中则揭晓答案并结束本局。

为了让输入体验尽量顺畅，搜索支持：

• 中文曲名；
• 英文大小写差异；
• 去除空格和标点后的匹配；
• 曲名拼音文件名；
• 联想列表点击提交；
• 精确或唯一匹配时按回车提交。

不存在的歌曲和已经猜过的歌曲不会加入表格，而是显示轻量提示。

答案行为什么固定在最上方#

游戏表格最上方始终显示答案行，但在答对之前，答案内容会被模糊隐藏。猜测记录位于其下，并按照“最新猜测在最前”的顺序排列。

这样设计有两个好处：

1. 玩家始终知道自己正在追踪哪些字段；
2. 提示系统可以直接揭开答案行中的某个单元格，不需要额外弹出说明。

目前表格包含七类线索：

• 曲名；
• STAFF；
• 发布时间；
• 演唱歌姬；
• 使用声库；
• 演唱会／生日会次数；
• 特殊标注。

曲名本身不提供高亮或字数方向，否则容易过快缩小范围。其余字段则根据类型使用不同判定方式。

不同字段不能用同一套比较规则#

1
答案：UP主：ilem；作曲：ilem；作词：ilem
2
猜测：UP主：另一位作者；作词：ilem

提示、自动歌词与投降#

曲目猜猜看提供三次提示，依次揭示：

1. 演唱歌姬与发布时间；
2. 完整 STAFF；
3. 歌词提示。

另外还有一个自动歌词机制：如果某次猜测已经在 STAFF、歌姬、声库、发布时间年份和特殊标注上与答案完全一致，却仍然没有猜中，说明现有结构化线索已经很难继续区分，系统会自动显示歌词。

玩家也可以随时投降。答对或投降后都会出现结算卡片，展示答案、猜测次数，并提供 Bilibili 原视频和 VCPedia 页面入口。如果某首歌曲没有 Bilibili 地址，对应按钮会自动隐藏，不影响游戏。

从“简单／困难”到完整曲库筛选#

早期版本只有简单和困难模式。随着歌姬与歌曲数量不断增加，这种划分很快不够用了，于是模式页被改造成曲库范围选择器。

玩家可以筛选：

• 主要曲库与演唱歌姬；
• 使用声库；
• 特殊标注；
• 发布时间范围；
• 是否只包含登上过演唱会／生日会的曲目。

同时提供快速预设，如全曲库、洛天依入门曲库、洛天依经典曲目、乐正绫经典曲目、言和经典曲目、禾念系、五维介质系、忘川风华录和黄金时代。

预设本身使用 Markdown 维护，构建时会检查缺失曲名、重复曲名和空曲库。自定义筛选则写入 URL 查询参数，使刷新后仍能恢复相同范围。

第二个玩法：把歌名拼成一张棋盘#

曲目猜猜看之后，我想做一个不依赖 STAFF 或发布时间的玩法。最终形成的方案是“曲名填字”：随机选择六首歌，把相同汉字放到同一个格子，让歌曲横向和纵向交叉。

首版只允许完全由汉字组成的曲名参与。像《普通DISCO》《66CCFF》《滚！》这类包含英文、数字或标点的标题会整体排除，而不是清洗后强行加入。

原因很简单：棋盘中的每个格子必须对应原曲名中的一个真实字符，不能让显示规则和正确答案发生偏差。

棋盘生成不是简单的字符串拼接#

程序首先建立曲名之间的连接关系：只要两首歌共享至少一个汉字，就可能在棋盘中交叉。

生成一局时，服务会随机选择候选，并通过回溯依次放置六首歌曲：

1. 第一首横向放置；
2. 后续歌曲必须通过相同汉字垂直交叉；
3. 所有歌曲必须属于同一个连通棋盘；
4. 交叉位置的文字必须一致；
5. 不允许字符冲突；
6. 不允许非预期的并排相贴或首尾相接；
7. 多个合法布局中优先选择面积更小、交叉更多的方案。

如果多轮回溯仍然无法生成完整的六首棋盘，页面会明确提示本局生成失败，而不会把残缺布局交给玩家。

“显示所有交叉字”带来的意外问题#

最初规则是：所有交叉格在开局时直接显示，其余格挖空。但实际游玩后发现，一字歌或交叉较多的短歌可能在开局时已经全部填完整，失去了挑战意义。

后来规则改为：每盘只固定两个非交叉字符，分别来自两首不同歌曲的第一个字。交叉关系仍然决定棋盘结构，但交叉格不再全部免费显示。

这个调整说明，算法上“合法”的谜题不一定在体验上“好玩”。生成器除了保证无冲突，还需要控制开局信息量。

填字交互的细节#

每个空格都是单汉字输入框：

• 输入一个汉字后自动前进；
• 退格可以删除并回到上一个可编辑格；
• 粘贴一段纯汉字文本时会按当前歌曲顺序填入；
• 点击格子会高亮它所属的整条歌曲；
• 交叉格属于两首歌时，可以切换当前方向；
• 已经答对的歌曲会锁定，避免误改。

六首歌曲分别提交。未填完整不会计入提交次数；错误提交会保留内容并标红错误格；正确后整条标绿并显示完整曲名。

歌词提示可以无限展开和收起，不计入成绩。页面还提供“重置全部”和“投降”：投降后自动填入所有答案、停止计时并锁定操作，但不会伪装成正常通关。

曲库范围与连通性#

填字页面提供精简的曲库选择：全曲库、禾念系和五维介质系。

但一个预设能否用于填字，不能只看它有多少首歌，还要看纯汉字曲名之间是否形成足够大的连通分量。如果某个范围虽然歌曲很多，却只能分成大量互不相连的小组，就难以稳定生成六首棋盘。

因此，填字服务会先筛选纯汉字曲名，再分析共享字符连接关系，只从可组成六首连通棋盘的候选中选题。

响应式设计与可访问反馈#

曲目猜猜看在桌面端使用横向表格，移动端转换为纵向数据卡片；曲名填字在桌面端使用“棋盘＋曲目列表”双栏，移动端则将棋盘放在上方、曲目列表放在下方。

正确、接近、错误、选中和固定格不仅依赖颜色，还同时使用边框、文字或图标表达。这既改善可访问性，也避免随机主题色或屏幕差异导致反馈不清楚。

本阶段总结#

这两个玩法共用同一套曲库，却使用了完全不同的数据视角：

• 曲目猜猜看把歌曲资料转化为逻辑推理线索；
• 曲名填字只使用曲名字符与歌词，把数据库变成一张文字棋盘。

它们让我开始确定“洛一把”后续扩展的方向：不是给同一个猜歌页面不断叠加功能，而是让同一批歌曲数据产生不同类型的小游戏。

下一篇将继续介绍两类扩展：围绕发布时间设计的“谁是老资历／小资历”和“歌曲大排序”，以及从歌曲转向创作者的“闪耀的 Producer”。

项目地址：https://github.com/LonakoBc/luo-yi-ba
在线试玩：https://luo-yi-ba.pages.dev/