osu! 概要#

osu! 是一个由 Dean Herbert（peppy）于 2007 年创办的、社区驱动的音乐节奏游戏。玩家依赖音乐节拍、通过点击、滑动、旋转等操作完成谱面。它不只是一款“音游”，更是一个集谱面创作、实时排名、多人游戏、观战、皮肤制作、谱面分享于一体的生态。

osu! 包含四种游戏模式：

• osu!standard：点击、拖拽与滑条
• osu!taiko：太鼓达人
• osu!catch：接水果
• osu!mania：下落式键盘（4K / 7K 等）

osu!standard 和 osu!mania 4K 是最为活跃的游戏模式。

osu! 的特色#

• 强大的在线功能。osu!具备完整的全球排名系统、多人游戏、谱面共享、谱面星数计算、成绩表现分计算等在线功能。
• 海量的优质谱面。依赖强大而活跃的社区，你可以在游戏或网站内免费下载数百万张来自玩家创作的谱面。谱面数量仍在日渐增加。使用搜索功能，你总能找到自己喜欢的歌曲。
• 优秀的游戏体验。相较于其他音乐游戏，甚至是大多数应用，osu! 的游戏内交互体验都十分出色。无论是界面设计、用户体验、输入延迟处理、还是画面渲染等其他功能，在市面上都属于独一档的存在。
• 长期活跃的社区。长期以来，osu!的社区非常活跃。社区成员们制作谱面、审核谱面、维护 osu! 的部分运营与开发、举办 osu! 比赛…为游戏的运转灌注持续动力。

如果要谈 osu! 最核心、与其他产品相比最突出的特质，那必然是开放。不同于普通的商业项目，osu! 是一个社区化项目。osu! 的方方面面都围绕社区运转：谱面创作、游戏排名竞争、比赛举办、视觉设计、项目开发……作为一名玩家，你将有很多机会与 osu! 的核心管理层交流。他们会看网站评论、会看社交平台、会了解社区内发生的各种事件，并做出针对性地改进……玩家们并不实际从社区活动中获取收益，却仍然不断参与其中，仅仅是出于热爱——这是社区化项目最大的魅力所在。osu! 将这一魅力演绎到了极致，让我深深为之所迷。

osu! 是一款音乐游戏，而不是其他#

你应当把 osu! 当做一款音游，而不是其他。在游戏内使用鼠标在屏幕上瞄准，常被认为是一款有助于训练 3D 瞄准的练枪游戏。然而，osu! 并非为练枪而设计。他考验对节奏的掌控和谱面歌曲的理解。你应该寻求专业的练枪软件，而不是玩一款音游。

即刻加入 osu!#

打开游戏官网 osu.ppy.sh，点击按钮选择对应版本下载osu!。下载好后，在游戏内注册账户。

要注意的是，账户名在创建账户后不能随意修改。自账户创建完成后，账户名的修改需要付出代价（拥有 osu!supporter）。即使修改成功，也会在新名字旁显示你的旧名字。

杂谈#

2016 年的 peppy：

osu! 一直以开放为核心特色，因此我们选择将新客户端 osu!lazer 在 github 上开源。

2026 年的 peppy：

开源是个错误的决定。

由于近来有大量使用 AI 创作代码的 pr 出现，peppy 以及其他核心开发成员开始抗拒新成员的加入，甚至在一段时间内禁止非协作者参与评论、发布 issues 和 pull request。他们认为，新成员不可能对项目架构有较深的理解。

osu!lazer 是 stable 的重构版本，两者之间有较大的差别，包括动画、界面设计、渲染、输入延迟等。作为老玩家，从 stable 客户端切换到 lazer 客户端会产生较大的割裂感。

lazer 的手感十分差劲。
lazer 的击打判定很怪。
lazer 帧数锁在了 1000 帧，这和我在 stable 里面能跑到的帧数相差很远（或者说是回报率）。
lazer 的性能和兼容性非常差劲。
lazer 加了各种奇葩没用的模组。
…

由于偏好 stable 的 “老顽固” 的存在，peppy 感到十分头疼。在 osu!lazer 项目设立之初，peppy 有言：“我们将一直支持 stable 客户端，直到所有玩家都愿意迁移到新版 lazer 客户端。”

之前你询问过世界杯玩家，调查他们是否愿意将比赛客户端切换到 lazer 端。

是的，但我想，把调查结果放到这里并不合适。

——来自某次日志更新视频

显而易见，许多老玩家并不希望迁移到新客户端。

客观而言，lazer 其实比 stable 优秀得多。stable 的各种设计已过时，且不符合现代应用开发规范。

老玩家总是在为停留在旧版本客户端寻找借口，实际上是对 stable 版本的执念。当在一个地方待太久时，我们总是偏好停留在这个地方，而不愿切换到新地方，或者说接受新的事物。

为了让老玩家切换到新客户端，peppy 费劲了心思。现在，peppy 正尽可能还原 stable 中的体验，让客户端切换尽可能地不那么 “割裂”。

某个在 stable 中已有的设计，我们不会再进行过多的讨论，而是直接搬到 lazer 中。

某些在 stable 中的设计，即使是应当修复的 BUG，为了还原体验，也要搬进 lazer 中。