在过去的7个月里，我完全独自一人开发了一款2D增量六边形拼图肉鸽游戏。在超过10,000名玩家通过不同WebGL平台进行试玩后，我最近不得不对底层游戏系统进行了一些相当重大的修改。
我想分享一些在Unity方面遇到的问题以及我是如何应对的。
构建六边形网格
核心玩法围绕一个六边形网格展开，原子可以在其中合并成更高级的元素。挑战之一是如何让网格足够灵活，以支持不同的棋盘大小和环形配置，而无需硬编码每个位置。
我没有将棋盘视为一组互不相关的游戏对象，而是将逻辑网格状态与视觉表现分离开来。
这使得在其上构建多个系统变得更加容易：
- 查找相邻六边形
- 验证瓷砖是否可以放置
- 检测可能的合并
- 解决连锁反应
- 管理不同的环形尺寸
- 添加与特定瓷砖交互的工具
这也使得在不重写游戏逻辑的情况下更改棋盘配置变得更加容易。
处理连锁反应
其中一个更有趣的部分是实现大型合并链。
一次普通的合并可能触发另一次合并，进而再触发一次合并，因此我需要一个能够解决这些交互的系统，而无需依赖大量嵌套调用。
我最终将合并过程更多地视为一系列游戏状态的变化：
- 识别有效的合并。
- 更新逻辑网格。
- 创建/更新生成的原子。
- 检查受影响的相邻单元格。
- 将任何新的合并加入队列。
- 继续解析，直到没有更多的有效反应。
一旦连锁组合涉及许多瓷砖，这一点就变得尤为重要。
工具与玩家状态
游戏还有几种修改常规规则的工具，包括移除、交换或修改原子的工具。
我遇到的一个问题是，我最初将解锁的工具视为自动可用。经过试玩，这使游戏策略性大打折扣，因为玩家可能会一下子拥有太多选项。
我更改了系统，使已解锁的工具和已装备的工具成为两种独立的状态。
玩家可以永久解锁一个工具，但可以选择当前是否装备它。
这听起来像是UI上的一个小改动，但它需要将工具的进度状态与其活跃的游戏状态分离开来。
修复随机数生成（RNG）而不移除RNG
试玩中最大的反馈之一就是，某些局游戏可能因为糟糕的随机数生成而变得令人沮丧。
我不想完全移除随机性，因为不确定性是肉鸽游戏结构的重要组成部分。
相反，我添加了暂存槽位，玩家可以暂时储存原子或工具。
有趣的是，这还必须与现有的资源和棋盘系统协同工作。被持有的物品不仅仅是棋盘上的另一个瓷砖，所以我必须确保游戏在其被储存、使用或丢弃时正确处理其生命周期。
这给了玩家更多控制权，同时没有完全消除随机性。
为什么我将游戏逻辑与视觉分离
独自工作使得这一点尤为重要。
当游戏系统与游戏对象紧密耦合时，改变一个机制很快会变成同时修改UI代码、动画、输入处理和网格逻辑。
将逻辑状态与表现分离使我能够更快地迭代。
例如，在视觉动画实际完成之前，游戏就可以确定一个原子从一个逻辑六边形移动到了另一个逻辑六边形。
随着我添加工具、连锁反应、教程、升级和不同的游戏模式，这种分离变得越来越有用。
我从10,000多次试玩中学到的
最大的教训实际上并不是Unity特有的。
一个我在作为开发者测试时感觉完美运作的机制，对于第一次看到它的人来说可能感觉完全不同。
最近很多工作并不是添加新内容。而是减少摩擦：
- 更好的教程
- 更好的升级界面
- 对工具更强的控制
- 不那么令人沮丧的随机性
- 更好处理玩家意外操作
- 修复通过试玩发现的边缘情况
完全独自完成这个项目也迫使我去构建易于修改的系统，而不仅仅是能运行一次的系统。
我仍在迭代中，所以我很想听听其他Unity开发者是如何处理类似问题的。
该项目使用Unity构建，目前提供免费Steam试玩版，如果有人想看看这些系统的实际运行效果，可以访问：
https://store.steampowered.com/app/4692090/Unstable_Nuclear_Reactor_Demo/
评论 (0)