一个人做完整套游戏UI，他把设计系统开源了 摘要

文档概览

这篇文章围绕独立开发者 Sinan Ata 的一项实际工程产出展开：他在独自开发多人平台格斗游戏 Leap of Legends 时，发现游戏 UI 存在一个典型但高频的隐形成本——每个项目、甚至同一项目内的不同界面，都会不断从零重写按钮、输入框和布局，而且实现方式往往并不完全一致。为了解决这种重复劳动和风格不统一问题，他不是重新发明一套独立框架，而是在 Unity 6 的 UI Toolkit 之上搭建了一层设计系统，并将其开源。

原文介绍的系统名称为 Unity UI Toolkit Design System。文章强调它覆盖的不只是几个零散控件，而是一整套可复用的 UI 基础设施，包括 设计令牌、UI 组件、图标集、移动端支持以及 Runtime Helper。其默认视觉方案统一走深色主题；整体视觉风格由一张主 stylesheet 统一控制，而换主题主要通过修改 Token 文件完成。作者在自己的测试中验证了主题切换效率：四套配色方案，每套都只需要一个 git diff 级别的改动。

文章还给出若干工程化落地信息：接入方式很直接，只需把对应文件夹拖入项目的 Assets 目录，再把主 stylesheet 挂到 UI 屏幕上，就能把全局风格统一起来；官方还提供一个网页 Demo，支持通过悬停或点击组件查看其背后的 selector 链，以帮助开发者理解组件结构和样式组织方式。

关键事实

1. 主角与问题背景

• 文章主角是独立开发者 Sinan Ata。
• 他当时正在独自开发一款多人平台格斗游戏：Leap of Legends。
• 他遇到的问题不是单个界面难做，而是 UI 在长期项目中的重复建设成本过高：按钮、输入框、布局等基础元素会被反复重写，而且每次实现“都不太一样”。
• 这说明系统建设的直接动因是“降低重复开发成本 + 减少视觉与结构不一致”，而不是单纯为了展示某种新 UI 技术。

2. 系统名称与定位

• 系统名称：Unity UI Toolkit Design System。
• 定位上，它是“设计系统”，不是完全独立于 Unity 的新 UI 框架。
• 技术基础非常明确：它建立在 Unity 6 的 UI Toolkit 之上。
• 因此，这套系统更适合作为 Unity 原生 UI Toolkit 的规范层、复用层与主题层，而不是替代 Unity UI 渲染与交互机制本身。

3. 系统覆盖范围

原文明确点出这套系统至少覆盖以下几个部分：

• 设计令牌（Design Token）；
• UI 组件；
• 图标集；
• 移动端支持；
• Runtime Helper。

这意味着它不是只提供样式表或控件皮肤，而是把视觉变量、组件复用、图标资产、终端适配和运行时辅助能力打包成了一套可落地的工程方案。

4. 视觉机制与主题机制

• 默认统一走深色主题。
• 整体视觉风格由一张主 stylesheet 控制。
• 替换主题时，主要通过修改 Token 文件完成。
• 作者自己测试了四套配色方案，而每套只需要“一个 git diff 的时间/级别的改动”。

这里的重要含义是：主题切换不是分散到大量组件里逐个改色，而是通过 token 化的参数集中驱动。这与 设计令牌 的典型目标一致，即把颜色、间距、字号等视觉决策抽离成统一变量，从而减少大范围样式修改时的维护成本。

5. 输入与终端适配

• 原文明确提到这套系统同时适配键盘与触控交互。
• 这表示其交互设计没有只针对 PC 菜单导航，也没有只考虑移动端触屏，而是兼顾至少两类主要输入方式。
• 原文还给出一个移动端适配细节：加一个 .mobile 类即可完成移动端适配。

这一点说明系统在响应不同终端时，并不是要求完全分叉一套独立 UI，而是试图通过类名或样式分层，在同一设计体系下完成适配。

6. 接入方式

原文把接入流程描述得很直接：

1. 把文件夹拖进项目的 Assets 目录。
2. 把主 stylesheet 挂到 UI 屏幕上。
3. 全局风格即可统一。

这说明它的接入门槛被刻意压低，更像是一套可直接并入现有 Unity 项目的资源与规范包，而非需要复杂初始化流程的重型框架。

7. 配套演示与学习方式

• 官方提供网页 Demo。
• 在 Demo 中，开发者可以悬停或点击组件。
• 这样可以查看每个元素背后的 selector 链。
• 其主要作用是帮助理解组件结构与样式关系。

对初次接触 UI Toolkit 样式层级的人来说，selector 链可视化尤其有价值，因为它把“组件是如何被样式选中和组织的”直接暴露出来，降低了阅读和二次定制成本。

8. 作者给出的实际收益数据

文章不是只停留在概念层，还引用了 Sinan 在自己项目中的实际数字与应用范围：

• 菜单屏从设计稿到上线，原本需要一两天；
• 使用这套系统后，被压缩到一两小时；
• 移动端适配通过加一个 .mobile 类完成；
• 设置界面、大厅、商店、赛后结算、游戏内 HUD，全部运行在同一套 Token 和组件上；
• 在审查时，没有需要处理的视觉不一致问题。

这些信息表明，这套系统已经在一个真实项目中覆盖了多种典型游戏 UI 场景，而不是停留在展示按钮、面板、表单等孤立 demo 的阶段。

9. 适用边界与例外

原文也给出适用性判断，而不是无条件推荐：

• 适合独立开发者或小团队。
• 尤其适合需要快速搭建多个 UI 屏幕、又不想每次从头定义视觉规范的场景。
• 但如果项目已经有一套成熟的自定义设计语言，那么这套系统默认的深色主题和现有 Token 结构，可能需要一定改造才能融入。

这段提醒很重要，因为它说明该系统虽然可商用、可复用，但并非“零改造适配所有项目”。对已有成熟品牌规范或既有设计语言的大项目来说，接入成本可能主要落在 token 重映射与主题体系改造上。

10. 开源许可与使用条件

• 项目托管在 GitHub。
• 许可证为 MIT。
• 原文明确指出：可以直接用于商业项目。

这意味着从许可层面看，独立开发者或小团队采用该系统的法律障碍较低。

重要细节

设计系统并非脱离 Unity 原生能力

文章特别值得保留的一点，是它没有把这套系统描述成“替代 Unity UI 的新发明”。相反，原文强调 Sinan Ata 是“在 Unity 6 UI Toolkit 的基础上搭了一层设计系统”。这一定义很关键，因为它说明：

• 底层技术能力仍来自 Unity UI Toolkit；
• 设计系统负责的是视觉一致性、组件规范化、主题切换、复用效率与适配策略；
• 因此它与 Unity 原生生态并不冲突，反而是站在原生能力上做工程化封装。

深色主题是默认，不等于唯一

原文说系统“统一走深色主题”，这反映的是默认视觉策略，而不是唯一可行方案。因为后文同时给出主题切换机制：整体风格由主 stylesheet 控制，换主题主要改 Token 文件即可，且作者测试过四套配色。也就是说：

• 深色主题是默认交付形态；
• 但主题层具备可替换性；
• 真正的可变部分被抽到了 Token 文件；
• stylesheet 更像是结构与规则承载层，而不是把所有颜色硬编码到各个组件中。

git diff 级改动反映的是主题切换的粒度控制

“四套配色方案各只花了一个 git diff 的时间”这句话虽然带有一定传播表述，但其核心事实是：主题切换所需改动的范围被压缩得非常小。对工程实践来说，这通常意味着：

• 主题参数集中；
• 改动可审阅；
• 版本对比清晰；
• 不容易在多个组件文件里漏改。

即使原文没有展开 token 文件的字段结构，这一描述已经足以说明其主题系统具备较强的集中配置特征。

统一 Token 与组件的价值已经在多个界面类型中验证

原文列出的界面不是单一菜单，而是一串典型游戏产品功能面：

• 设置；
• 大厅；
• 商店；
• 赛后结算；
• 游戏内 HUD。

这几个场景的交互形态差别很大。设置偏表单与选项控制，大厅偏信息汇总与导航，商店偏列表和售卖展示，赛后结算偏结果反馈，HUD 则要求游戏内实时叠加。原文称这些都跑在同一套 Token 和组件上，并在审查时没有视觉不一致问题，说明这套系统至少在“跨场景一致性”上经过了实战验证。

输入适配不是附带说明，而是系统目标之一

文章把“键盘和触控都做了适配”与系统覆盖项并列提出，说明这不是后来补上的边缘能力，而是设计系统一开始就考虑的输入维度。对游戏 UI 来说，这一点很重要，因为很多系统若只面向鼠标点击或只面向移动触控，迁移到其他平台时会迅速暴露导航、焦点、点击区、交互反馈等问题。原文虽然没有展开具体规则，但至少确认这套系统在输入方式上不是单平台思路。

相关条目

• 游戏 UI 设计系统
• 设计令牌
• Unity UI Toolkit Design System
• Unity 6
• UI Toolkit
• Sinan Ata
• Leap of Legends

小结