01 · 开发目标
借助 AI 辅助，一个人能否搭起接近完整游戏的系统框架。
过去做 Game Jam 和课程项目时，我做过战斗、敌人、任务、库存等独立模块，但没有独立搭建过一个包含长期库存、经济、任务、Raid、存档和关卡内容的完整游戏。
AI 辅助编程让我觉得可以尝试更大的规模，因此完整游戏框架包括：
- 基地与 Raid 场景循环；
- 网格库存、仓库与装备；
- 武器、弹药、护甲和消耗品；
- 商店与经济；
- 任务与对话；
- 敌人和掉落；
- 搜刮与撤离；
- 死亡损失；
- 角色长期状态；
- 存档与继续游戏。
开发下来，大部分基础框架确实能够建立起来。真正限制个人项目规模的，逐渐变成了内容生产。
系统做出来以后，还需要足够多的地图、建筑、室内空间、敌人、物品、任务和剧情，才能让这些系统真正被反复使用。AI 可以明显加快程序开发，也能辅助美术和文本生产，但它的直接美术产出不符合我的标准。我选择了接近 HD-2D 的表现方式，生成素材通常还要继续拆分、裁剪、抠图、手动修补和重新组合，才能进入游戏。具体的美术生产流程和当时 AI 能力带来的限制，会在后面的美术工作流章节单独说明。
三个月不足以完成最初设想的内容规模，因此项目后期转向优先完成一个可以从头到尾游玩的版本。
02 · 核心循环
玩家基地管理长期资源，探险地图承担搜刮、战斗和撤离，两部分通过结算持续连接。
项目最终形成了 BaseHub 与 NorthCity 两个主要阶段。
BaseHub
玩家在基地可以：
- 接取和提交任务；
- 整理库存与仓库；
- 购买和出售物品；
- 调整武器与携带装备；
- 处理 Raid 后留下的角色状态；
- 为下一次行动做准备。
NorthCity
进入 Raid 后，玩家需要：
- 探索场景；
- 搜刮世界容器和敌人；
- 处理战斗与资源消耗；
- 完成任务目标；
- 根据当前收益和状态决定继续探索或撤离。
成功撤离后，获得的物品会带回基地，并继续参与仓库、任务和经济循环。
Raid 失败则会产生物品损失等惩罚，使玩家在行动过程中需要持续权衡风险和收益。
最终主循环为：基地整备 → 进入 Raid → 搜刮 / 战斗 / 任务 → 撤离或失败 → 结算 → 再次整备
这一结构也是后续库存、任务、经济和角色状态等系统共同围绕的主线。
03 · 库存系统
我先使用成熟插件避免重复造轮子，但它限制了设计，再围绕实际玩法需求重做。
项目早期我没有打算从零制作网格库存。我先使用了一个现成的第三方库存插件，希望把时间留给玩法本身。
实际熟悉并扩展之后，我逐渐发现它的结构无法满足后面的设计需求。例如：
- 无法很好地处理物品内部继续容纳其他物品，例如枪械安装配件；
- 背包内部空间难以按照具体设计自由划分；
- 不容易制作不同形状和不同布局的容器空间；
- 随着装备、仓库、商店和搜刮系统加入，继续修改原插件的成本越来越高。
因此我后来让 AI 参考原有库存项目的成熟部分，重新设计了一套更适合当前游戏的库存系统。
我的重点不是自己编写底层代码，而是确定它需要支持哪些游戏规则、编辑方式和模块关系。
面向策划的可视化编辑
新系统增加了专门的编辑工具。我可以直接配置：
- 物品尺寸；
- 是否能够旋转；
- 堆叠规则；
- 不同类型的容器；
- 背包内部可用区域；
- 装备槽；
- 武器、弹药、配件等玩法属性。
这样在增加新物品时，不需要重复修改程序逻辑。
例如背包可以拥有特定方向和形状的内部空间，玩家拖入物品时也可以根据可用位置自动旋转适配。这类规则后来可以直接用于背包选择和物品取舍。
与其他玩法系统连接
为了让项目后续更容易维护，我也尽量避免把所有逻辑继续堆进库存控制器。
虽然我的程序架构经验有限，但我会先定义每个系统应该负责什么，再让 AI 参考成熟项目的组织方式完成实现。库存负责物品和容器操作，武器、商店、任务、治疗等功能尽量由各自模块处理，再通过统一接口交换数据。
这使库存能够继续与仓库、装备、商店、任务、世界搜刮和敌人掉落连接，而不需要每增加一个功能就重新修改整个系统。
存档部分基于 Easy Save 等现成工具完成，没有重新制作底层存档方案。
04 · 搜刮、容量与风险收益
价值、占格、安全箱和死亡损失共同影响玩家如何整理背包，以及什么时候选择撤离。
我希望搜刮过程本身就能不断要求玩家做选择。
物品除了售价之外，还有尺寸、占用空间以及携带条件。玩家可能遇到价值更高的物品，但背包已经接近装满。这时需要判断：
- 丢掉哪些低价值物品；
- 是否值得重新整理背包空间；
- 哪些物品应该放入安全箱；
- 是否继续探索寻找更好的收益；
- 当前装备和获得的物资是否已经值得撤离。
背包空间因此也参与风险收益判断。
失败时，大部分携带物品会损失，安全箱可以保留有限的重要物资。游戏中还有额外的虚弱状态作为死亡惩罚，让玩家更真实地体验到撤离失败的后果。
这些规则共同作用，让玩家在 Raid 中自己判断当前收益是否值得继续承担下一段风险。
05 · 内容制作与范围调整
系统框架可以很快扩展，真正把它铺成一个完整游戏时，系统对接、美术和关卡内容才成为主要成本。
这是我第一次独立制作这种规模的项目。前期我低估了两件事。
第一是系统之间的对接成本。
单独完成库存、商店、任务或者敌人并不意味着游戏已经完成。当它们真正接入同一套流程以后，还需要处理大量状态同步、UI、存档、异常情况和测试。
第二是内容和美术制作需要的时间远高于我的预期。
一个搜打撤游戏即使系统已经存在，也需要足够大的场景和足够多的内容，才能让这些系统发挥作用。建筑、室内空间、街道、道具、人物、UI、敌人、任务和剧情都需要实际生产。
因此开发后期，我缩小了 NorthCity 的实际内容规模，也暂停继续加入更多 NPC、敌人和剧情，把剩余时间用于完成正式版本的完整流程。
最终要求是玩家能够从 New Game 开始，不依赖 Inspector 或调试跳转完成：
New Game → First Arrival → Recon → Collector → Area Clearing → Raid → 撤离 / 失败 → 返回基地
这保证了正式版本至少能够完整展示已经完成的主要系统。
06 · AI 辅助美术工作流
AI 能缩短“得到素材”的时间，但在这个项目里，把素材变成稳定可用的 HD-2D 游戏资产仍然需要大量人工处理。
这里讨论的是我在 2026 年实际开发项目时使用到的生成式工具能力。AI 工具仍在快速变化，这些限制并不代表之后的模型一定相同。
我选择的是接近 HD-2D 的画面方向。场景需要由可拆分、可重复组合的 2D 素材构成，再进入 Unity 进行层级、空间和光照处理。因此生成图片通常无法直接作为最终场景使用。
实际流程更接近：
确定场景需求和参考 → 分别生成基础素材 → 筛选 → 裁剪 / 抠图 → 手动修补 → 统一风格和像素表现 → 拆成可复用资产 → Unity 中重新搭建与调整
这意味着即使 AI 已经生成了视觉上接近的素材，我仍需要处理边缘、遮挡、透视、光影、透明区域和细节一致性，再决定哪些部分可以进入游戏。
另一个问题是风格稳定性。
这个项目的题材和画面要求相对小众。生成式模型对某些常见奇幻、科幻或概念插画风格比较容易保持一致，但我需要的是特定视角、特定时代和地域环境下的横版场景与拆分素材。开发期间经常出现单张图片看起来不错，但和已有资产风格不一致，或者构图、结构和细节无法达到预期的情况。
这会带来额外的反复生成、筛选和人工修补，也限制了 AI 对整体生产效率的提升。
因为本科阶段有美术和视觉制作经验，我没有把生成式工具当成最终美术的替代，而是把它放进一个更接近传统资产生产的流程中：先利用 AI 提高参考和基础素材的产出速度，再通过 Photoshop 等工具进行人工处理，最后进入 Unity 重新组合。
如果按照商业项目标准继续制作，我仍然会对最终美术进行系统性的人工重绘、修整和统一。生成式素材更适合作为参考、原型和生产辅助。
这次项目也让我意识到，如果继续做大规模个人项目，我会更早开发建筑生成、环境模块配置等辅助工具，减少重复性的素材整理和场景摆放工作。
07 · 玩家测试
玩家能够理解搜刮和价值判断，但地图、战斗反馈与新手引导还没有把现有系统的潜力完全发挥出来。
最终阶段进行了 4 次定性玩家测试，测试者拥有不同程度的搜打撤游戏经验，其中包括长期游玩这一类型的玩家。
测试主要观察：
- 玩家是否能够理解任务和基础目标；
- 是否会主动搜刮并判断物品价值；
- 背包空间是否会影响物品选择；
- 获得较高价值物品以后是否会改变行动；
- 玩家什么时候开始考虑撤离；
- 库存和商店是否容易理解；
- 战斗和地图是否能够提供足够压力。
测试中，玩家很容易理解：搜刮 → 判断价值 → 带回基地 → 出售或保留 这条基础循环。随机掉落和高价值物品也能够影响部分玩家的行动。
目前版本的问题主要集中在内容量和最终体验打磨上。
地图规模与路线
NorthCity 当前开放区域较短，整体路线也比较明确。因此即使玩家已经获得高价值物品，返程距离和可能遭遇的威胁仍然有限，风险收益系统没有足够的空间发挥。
敌人与战斗
当前敌人种类、数量以及行为变化较少。
战斗系统的目标和后续需要增加的反馈我已经比较清楚，但开发周期内优先完成了整体循环，因此枪感、受击反馈、低生命状态提示和敌人变化没有获得足够的 polish 时间。
库存与新手流程
部分测试者第一次使用库存时，对旋转、装备槽和拖拽规则不够熟悉。
其中一个原因是拖拽判定还有继续优化的空间。另一个很直接的原因是，我给测试者发送独立 Build 时没有附带正式的新手教程。本来计划在访谈时进行引导，但部分玩家依靠同类游戏经验直接开始游玩，也因此暴露了第一次接触时的信息问题。
如果继续制作，我不会单纯增加文字说明，而会把这些规则放进真正的新手流程。例如让玩家第一次拿到特定背包时，通过背包空间方向和物品形状，自然发现拖入物品后的自动旋转和空间适配，而不是先弹出一整页教程。
08 · 项目复盘
这个项目让我更清楚自己的方向：我更喜欢系统、玩法和工具设计，而不是把主要时间消耗在重复性的资产生产上。
这个项目最终没有达到我最初设想的内容规模，但让我更清楚地看到了个人开发中不同工作的实际成本。
AI 辅助编程对于系统开发的帮助比我一开始预计的更明显。只要我能够明确描述规则、交互和验收条件，很多过去需要大量编程时间的基础系统现在可以快速搭建，再通过测试逐步修改。
但这种效率提升没有等比例延伸到整个游戏制作过程。地图、美术、任务内容和剧情仍然需要大量人工判断和重复劳动。
特别是场景制作。我有能力处理这些资产，也知道应该如何继续提高质量，但长时间进行抠图、整理素材和场景摆放并不是我最希望投入精力的工作。
这反而让我更清楚自己的方向。相比单纯制作大量美术内容，我更喜欢定义规则、搭建系统、设计玩法关系，再通过工具和流程让内容生产变得更高效。
如果重新开始这个项目，我会更早处理三个问题：
- 提前开发内容生产工具
在地图规模扩大之前，就开始制作建筑、环境模块和关卡配置方面的辅助工具，减少重复性的场景工作。 - 更早安排新手流程
把库存、商店、任务和撤离规则逐步放进实际游玩过程，而不是等系统完成以后再集中解释。 - 更早进行完整流程测试
每个开发阶段都让没有接触过项目的玩家从 New Game 开始体验，尽早发现系统之间的衔接和信息传达问题。
开发说明
这是我的个人硕士毕业项目。
我负责玩法与系统设计、任务和关卡流程、玩家测试、项目管理、美术制作流程以及 Unity 集成。
项目使用第三方插件、生成式工具与 AI 辅助编程。AI 主要用于代码实现辅助、素材生产和部分工作流提效；具体玩法规则、功能需求、内容取舍、资产筛选、集成和最终测试由我负责。