企业官网建设流程全解析

• 前端
• 开发工具

本文以本仓库.agent/skills/game-development/pc-games/SKILL.md技能文档为核心骨架，系统讲解 PC 与主机（Console）游戏开发的关键原则：从引擎选型决策、Steam 平台集成与主机认证要求，到手柄输入抽象、性能剖析与优化，再到三大引擎的专项实践与常见反模式。读完本文，你将掌握一套"不依赖具体引擎"的 PC/Console 游戏开发方法论，能够依据项目需求而非行业热度做出工程决策，并知道如何在 Unity 6、Godot 4、Unreal 5 之间做出选择与落地优化。

1. 引擎选型：从决策树到横向对比

PC/Console 开发的第一步是选引擎。选错引擎的代价远超后期任何一次重构，因此该技能文档首先给出了一个结构化的决策树，让选择由"项目需求"驱动，而非"技术热度"。

1.1 引擎选择决策树

What are you building? │ ├── 2D Game │ ├── Open source important? → Godot │ └── Large team/assets? → Unity │ ├── 3D Game │ ├── AAA visual quality? → Unreal │ ├── Cross-platform priority? → Unity │ └── Indie/open source? → Godot 4 │ └── Specific Needs ├── DOTS performance? → Unity ├── Nanite/Lumen? → Unreal └── Lightweight? → Godot

使用要点：

• 2D 赛道：如果开源与授权成本是硬约束，直接选择 Godot；如果是大型团队、需要成熟的资源管线（Sprite Atlas、Tilemap、Animator 等），Unity 更稳妥。
• 3D 赛道：追求 AAA 级画面表现选 Unreal；需要同时覆盖 PC、主机、移动等多平台选 Unity；独立开发者或偏好开源生态选 Godot 4。
• 专项需求：需要 DOTS 数据导向架构的高性能实体系统选 Unity；需要 Nanite 虚拟化几何体与 Lumen 动态全局光照选 Unreal；追求轻量、快速迭代选 Godot。

1.2 三大引擎横向对比

解读关键差异：

• 2D 能力：Godot 4 在 2D 编辑器、光照与骨骼动画上体验最佳；Unreal 的 2D 支持相对有限。
• 学习曲线：Godot 4 门槛最低（配合 GDScript 可快速上手），Unreal 5 因为庞大的工具链与 C++/Blueprint 双轨体系，学习成本最高。
• 成本模型：Unity 采用营收分成模式；Godot 完全免费；Unreal 为"首个 100 万美元营收后收取 5% 分成"模式。需要说明的是，具体授权条款应以各引擎官方最新政策为准。

本仓库中与之呼应的 game-developer agent 定义 进一步提炼了五条选型提问：目标平台是什么？2D 还是 3D？团队规模与经验？预算约束？要求的画面质量？——这五个问题可以视为决策树的"参数化版本"，在项目立项阶段逐条回答，即可收敛到唯一合理的引擎选项。

2. 平台特性：Steam 集成与主机认证

PC/Console 开发与纯 Web、移动开发最大的区别在于平台准入：PC 上要对接发行平台（Steam），主机上要通过厂商认证。技能文档将这两类"平台特性"拆成了两张表。

2.1 Steam 集成功能清单

工程实践建议：

• Achievements / Leaderboards建议在游戏核心循环稳定后再接入，避免数值频繁调整导致成就条件反复返工；
• Cloud Saves的字段设计要与本地存档解耦，尽量序列化"进度快照"而非运行时对象，防止版本升级导致旧存档不兼容；
• Workshop需要提前设计模组加载沙箱与内容校验策略；
• Rich Presence只暴露必要的游戏状态，注意避免泄露未公开的游戏内容。

2.2 主机平台认证要求

三家主机厂商都有各自的技术认证要求（Technical Requirements Checklist），本质上是厂商对游戏在平台上的稳定性、可用性、安全性与合规性的强制检查清单：

• PlayStation（TRC）：涵盖崩溃、存档、奖杯、认证弹窗、手柄适配、网络连接等硬性条目；
• Xbox（XR）：类似的要求清单，另需关注成就、多人配对、云存档等 Xbox 特有能力；
• Nintendo（Lotcheck）：任天堂的提交审核流程，重点检查功能、内容与政策合规。

务实的做法是：项目立项时就索取并研读目标平台的认证文档，把认证要求纳入排期，而不是在提交前突击修补。"Ignore platform guidelines" 正是技能文档反模式表中的头号禁区之一。

3. 手柄支持：输入抽象与触觉反馈

PC 上玩家可能使用键鼠、Xbox 手柄、PS 手柄或第三方手柄；主机上各家手柄按键布局还不一致。如果代码里直接硬编码按键，跨平台适配会变成噩梦。技能文档给出的答案是输入抽象（Input Abstraction）。

3.1 映射"行为"，而不是映射"按钮"

Map ACTIONS, not buttons: - "confirm" → A (Xbox), Cross (PS), B (Nintendo) - "cancel" → B (Xbox), Circle (PS), A (Nintendo)

同一行为 "confirm" 在三家手柄上的物理按键完全不同：Xbox 是 A、PlayStation 是 ✕（Cross）、任天堂是 B。因此正确做法是让游戏逻辑只感知"确认 / 取消"这类动作（Action），由输入层在运行时根据当前设备完成动作到物理按键的映射。这样做的好处：

• 跨平台一致：一套游戏逻辑同时支持键鼠、手柄、触屏；
• 可重绑定：玩家自定义按键只需修改映射表；
• 设备热切换：玩家中途换手柄（或从键鼠切到手柄）时，提示与操作不受影响。

该原则在仓库的 game-development 编排技能 中被泛化为全局规律："jump" → Space, Gamepad A, Touch tap、"move" → WASD, Left stick, Virtual joystick——即每个动作都对应多套输入方案的抽象层。

3.2 触觉反馈强度分级

实践原则：触觉反馈同样要按强度分级使用，避免全程高频震动造成玩家疲劳；配合手柄厂商的 API（如 DualSense 自适应扳机、HD 震动）时，仍然以"强度分级"为设计基准，把硬件特性当作渲染层而非逻辑层。

4. 性能优化：先剖析，再优化

PC 硬件差异巨大（从入门核显到高端独显），主机则有严格的帧预算与内存预算。技能文档反复强调的核心方法论是Profiling First（先剖析，后优化）——不测量就优化，等于盲人摸象。

4.1 各引擎的剖析工具

• Unity：内置 Profiler Window，可逐帧查看 CPU/GPU/内存/渲染统计，定位热点函数；
• Godot：Debugger 面板内置 Profiler，可查看脚本耗时与性能计数；
• Unreal：Unreal Insights 提供跨帧的时序与统计分析，适合定位帧率波动与加载瓶颈。

配合仓库中 game-development 编排技能 给出的 60FPS 帧预算（每帧 16.67ms：输入 1ms、物理 3ms、AI 2ms、游戏逻辑 4ms、渲染 5ms、缓冲 1.67ms），可以建立"预算驱动"的优化工作流：先在剖析器中找出超预算的系统，再针对性地优化，而不是凭感觉动代码。

4.2 常见瓶颈与对策

优化优先级建议（同样源自仓库编排技能的通用原则）：先修算法复杂度（如 O(n²)→O(n log n)），再做合批、对象池、LOD、剔除——资产压缩类优化放在最后。技能文档的 2D/3D 子技能还补充了更多细节：如 3D 游戏技能 中的视锥剔除（Frustum culling）、遮挡剔除（Occlusion culling）与距离分级 LOD 策略；2D 游戏技能 中的 Sprite Atlas 合并贴图以减少 draw call。这些与 PC/Console 场景高度相关，可在实践中组合使用。

5. 引擎专项原则：Unity 6 / Godot 4 / Unreal 5

选型之后，每个引擎都有自己"用得好"的姿势。技能文档为三大引擎分别给出了专项原则。

Unity 6

• DOTS for performance-critical systems：对性能敏感的系统（大量实体、群集、寻路）采用 DOTS（Data-Oriented Tech Stack）数据导向架构；
• Burst compiler for hot paths：热点路径（热循环）用 Burst 编译器将 C# 编译为高效原生代码；
• Addressables for asset streaming：用 Addressables 做资源流式加载，控制内存峰值与首屏加载时间。

Godot 4

• GDScript for rapid iteration：原型期用 GDScript 快速迭代，缩短"改代码 → 跑起来"的反馈环；
• C# for complex logic：复杂逻辑（算法密集型、需要强类型与工具链）切换到 C#；
• Signals for decoupling：用信号（Signal）解耦节点间通信，避免深层次的节点引用耦合。

Unreal 5

• Blueprint for designers：让策划/关卡设计师用蓝图搭建玩法逻辑；
• C++ for performance：性能关键路径用 C++ 实现，蓝图只做胶水层；
• Nanite for high-poly environments：用 Nanite 虚拟化几何体承载高模环境，无需手工 LOD；
• Lumen for dynamic lighting：用 Lumen 实现动态全局光照，减少烘焙流程。

三者的共同哲学是："引擎是工具"——原则归原则，最终要落到项目需求上。例如团队以设计师为主的项目，即使选了 Unity，也应尽量用可视化工具减少程序负担；而性能至上的项目，无论哪个引擎都要为热点路径保留原生代码通道。

6. 反模式清单：PC/Console 开发的避坑指南

技能文档最后给出了一张"不要做什么 / 应该做什么"的反模式对照表，可以当作提交代码前的自查清单：

逐一展开：

• 勿跟风选引擎：社区热度、招聘行情不等于项目适配度，回到第 1 节的决策树与五问；
• 勿无视平台规范：TRC/XR/Lotcheck 是硬门槛，越早研读越省返工成本；
• 勿硬编码按键：坚持动作抽象，让手柄/键鼠/触屏共用一套逻辑；
• 勿跳过剖析：性能问题靠数据定位，靠直觉"优化"往往南辕北辙。

这与仓库中 game-developer agent 的核心理念一致："Measure, don't guess"（先测量，别猜测）、"Profile before optimize"（先剖析再优化）。

7. 如何在仓库中使用该技能

在本文所在仓库中，PC/Console 游戏开发能力以Agent 技能的形式组织：.agent/skills/game-development/pc-games/SKILL.md是平台专项技能，其 frontmatter 声明了name: pc-games、能力描述与允许工具（Read、Write、Edit、Glob、Grep）。使用方式为：

1. 由 game-development 编排技能 根据目标平台路由：目标是 PC（Steam、桌面）时进入pc-games，Web 浏览器进入 web-games，移动端进入 mobile-games，VR/AR 进入 vr-ar；
2. 再按维度选择：2D 项目配合 2d-games，3D 项目配合 3d-games；
3. 按专项需求补充 game-design（GDD 与数值平衡）、multiplayer（网络）、game-art（美术管线）、game-audio（音频）等技能；
4. 需要专职执行时，可交由 game-developer agent 统一调度——该 agent 声明了完整的技能依赖链（clean-code、game-development 及其全部平台子技能），并内置了评审清单（核心循环是否定义、引擎选型理由、性能目标、输入抽象、存档与音频系统规划等）。

结语

Remember:Engine is a tool. Master the principles, then adapt to any engine.

这是技能文档的收尾箴言，也是全文的方法论核心：引擎只是工具，掌握原则才是竞争力。PC/Console 开发中的引擎选型、Steam/主机平台适配、手柄输入抽象、性能剖析优化——这些原则不绑定任何特定引擎，掌握它们之后，无论未来出现什么新引擎，都能快速迁移与适应。先按需求选型，再按平台合规，坚持输入抽象，始终先剖析后优化，这四件事做好，PC/Console 项目的技术地基就稳了。

• 前端
• 开发工具