迷宫球Devlog：操控的自由度和现实世界的模拟

本文系用户投稿，不代表机核网观点
设计元素
游戏玩法设计的早期原型阶段，最关键的往往是几个核心元素，我从Richard的《妙趣横生的游戏制作之旅》中得到了不少启发。Richard提到在原型阶段，游戏设计的关键在于三个“C”：Camera（镜头）、Control（操控）和 Character（角色）。我也在开发中对这三点有了深刻的思考：

Camera（镜头）：镜头在游戏中起到至关重要的作用。它不仅仅是视角的展示，更是玩家与游戏世界互动的桥梁。实际上，很多游戏甚至可以不需要操作角色，但镜头永远是必不可少的。如果没有镜头，那可能就是一个纯粹基于触觉或其他交互方式的游戏，那绝对是极简但极具创新的设计了。
Control（操控）：控制是游戏与其他艺术形式最大的区别。虽然有一些游戏可以没有明显的操控系统，比如互动电影类型的游戏，但我一直坚信这句话：“如果你可以用其他艺术形式传达内容，那么就不需要做成一个游戏。”游戏的核心在于交互，它赋予了玩家主动参与、掌控体验的机会，这也是其他形式难以替代的地方。
Character（角色）：角色通常是指玩家直接控制的虚拟角色，但在不同类型的游戏中，这个定义是可以被拓展的。比如在RTS游戏中，玩家的角色既可以是指个体单位，也可以指代整个场景中的镜头。对于我的游戏来说，角色其实非常简单，就是迷宫和球。虽然表面上角色系统看起来很基础，但它依然是游戏设计中不可或缺的一部分。
在我的项目中，这三个元素的难度和重要性是不同的：  
镜头：比较简单，始终看着迷宫即可；  
角色：也同样简化，迷宫和球构成了游戏的主体；  
真正的挑战在于操控：它决定了游戏的手感和深度。
这里岔开一句：其实相对于大制作，独立游戏、尤其是gamejam作品对于3C的取舍显得更为重要。且不说3A游戏逐年同质化，大部分3A游戏对于3C功能几乎无法取舍：你能想象没有敌人的《荒野大镖客》续作，或者没有输入控制的《塞尔达传说》续作吗？
但独立游戏、尤其是gamejam作品，是有这个自由的：平台跳跃相比横版过关，可以删去除了玩家角色以外的character；固定关卡的平台跳跃相比卷轴式的，又可以简化镜头的运动（不运动）。
在我之前的gamejam项目里很多时候就是犯了这个错误：把3C中的每一个元素视作理所应当，导致最终游戏在一个非常庞大的基础上发展，注定导致项目过于冗杂。事实上反过来说，如果3C里的元素不进行精简，游戏也很难精简到一个合适的体量。
迷宫球操作的复杂性：探索自由度的极限 
出人意料的是，迷宫球的操控自由度（DoF，Degrees of Freedom）比一般3D 3A游戏要多得多，甚至可以达到13个之多，我们先来看看3A游戏通常有多少操作自由度：
镜头：通常有2个自由度，分别是pitch（俯仰）和yaw（水平旋转），大多数游戏并不会让玩家控制roll（翻滚）方向。镜头通常跟随玩家角色，并通过类似Spring Arm + Camera碰撞的方式调整远近，这一部分也没有太多自由度变化。
角色：一般是4个自由度，即XY轴的平移和Z轴的跳跃（或动作）再加上Z轴的yaw。很多游戏虽然存在跳跃功能，但其实是将二维的操作映射到三维空间中，真正的三维操控并不多。
所以，一个3D 3A游戏通常只有5个控制自由度。  而迷宫球的情况要复杂得多（尤其是考虑到它是这么精简的一款游戏）。经过我对迷宫球在现实世界的分析：
镜头：有4个自由度，分别是pitch、yaw、roll，以及SpringArm的变焦功能。镜头的变换是相对于世界坐标系进行的，这意味着镜头不会移动，只是进行旋转和拉近拉远的调整。
迷宫：有9个自由度，分别在相对坐标系、世界坐标系和镜头坐标系下的pitch、yaw和roll。虽然迷宫不会在世界坐标系下进行平移，但它在不同坐标系下的旋转操作带来了相当复杂的操控。
简化操作：如何找到玩家的操控平衡？ 
显然，玩家不可能同时处理这么多复杂的自由度（可能是我们不够鱿型）。在我的观察中，即使是经验丰富的玩家，操作的同时也只会使用少数几个控制输入。
我还专门观察了我的对象玩游戏时的操作习惯，她在使用键盘时，通常每次只会按下1～2个按键，和我差异还挺大（进一步说明了游戏设计师不能以自己的操作习惯带入玩家）。
于是，我开始对自由度进行精简。经过一轮深入观察和思考，我决定去掉以下几个自由度：
镜头自己的roll：体验不佳，玩家几乎不会通过左右摇摆头部来观察迷宫。
镜头自己的yaw：很少有玩家会围绕迷宫球绕圈观察，这与现实操作习惯不符。
迷宫的local pitch和roll：当迷宫发生旋转时，局部坐标系下的操作会显得非常不直观，反馈很差。
迷宫的世界yaw和pitch：玩家并不会习惯性地围绕世界坐标旋转迷宫，这种操作方式几乎没有实际应用。
迷宫的世界roll：这种反馈非常奇怪，尤其是在和镜头交互时，体验极差。
最后保留下的自由度有：
镜头：世界坐标系下的pitch（通过鼠标Y轴平移控制）、SpringArm变焦（鼠标滚轮控制，待开发），以及可能会加入的Y、Z轴平移功能（尚未完成）。
迷宫：镜头坐标系下的pitch（W/S键控制）和roll（A/D键控制），本地坐标系下的yaw（Q/E键或者鼠标X轴平移控制）。
比例尺、力矩和重力的优化：如何让操作更跟手？ 
在确定了基本的操作框架后，我开始对操作感进行优化。起初，迷宫球的手感显得非常沉重，尤其是在旋转迷宫时，球的惯性显得不自然。为了改善这一问题，我尝试调整物理参数，例如降低加速度和调整扭矩，但依然无法彻底解决问题。
直到某天，我对象提出了一个非常有趣的问题：  “你的游戏里的迷宫是什么尺寸的？”  说真的我愣了一下，才意识到自己游戏中的迷宫和球的尺寸过大（1米的球和1.2米宽的迷宫，倒也不是故意的，只是UE默认的球体就是1米直径）。而现实世界玩的迷宫球玩具，小球的直径只有0.5厘米左右。
受到启发，我将迷宫和球的比例缩小到了1/10，即10厘米的球体。结果让我非常惊喜：球体的运动变得更加自然，迷宫旋转时的响应也更加灵敏。经过进一步分析，我发现这是因为球体变小后，质量和力矩也相应减小，导致球受到的力变小，重力效果更为显著。这样一来，球的反应就更加贴合预期。
接下来计划和面临的挑战 
随着操作系统的优化，我接下来的重点将是完善以下几个方面：
控制：计划还是要把迷宫改为扭矩控制，现在的控制操作在迷宫尺寸大范围变化时会带来明显的手感变化。
机制：我计划加入三种不同的游戏机制，包括双人合作、多人竞速、迷宫创建挑战。
关卡：计划增加4个普通玩法下、有着不同迷宫机制的世界，以及上述其他模式的额外关卡世界。
音效：音效是非常重要的部分，并且**总是**被独立游戏开发者（比如我自己）忽视。事实上，音效不仅仅是最后加的装饰，而是从原型阶段就应该融入的核心要素。
场景：计划将场景和模型优化为类似于围攻（besiege）风格、玩具般质感的风格。
风格化：优化tone shade和描边（在跃入迷城工程中已经有所进展）。
UI：目前系统已经集成了UMG，但可能后续还要改成CommonUI。
最后，期待迷宫球的更新吧～ 