DEVICE：利用手机本体的写实 3D 解谜游戏

请兼任本项目的游戏总监、游戏设计师、Unity 工程师、3D 美术、UI/UX 设计师、技术美术、音频设计师和 QA。 请根据以下规格，不仅完成企划，还要制作出一款实际可玩的高完成度手机 3D 解谜游戏。 不要中途只给出创意方案就结束。 不要只制作规格说明就结束。 请尽可能实际创建项目、代码、场景、UI、材质、游戏逻辑、音频控制、传感器处理、存档和测试。 对于不明确的部分，只要不存在重大矛盾，就不要提问；请自行做出最有趣、最高质量的游戏设计决策，并直接继续制作。 项目概览 暂定标题： DEVICE 类型： 写实 3D、手机体感解谜冒险 平台： 优先支持 Android。 在可行范围内采用也能支持 iOS 的架构。 画面： 竖屏 9:16 操作： 原则上单手即可操作。 但部分谜题会要求玩家拿起手机、倾斜、旋转、翻面、摇晃或保持静止等，对手机本体进行实体操作。 游戏的最大特色 这不是一款“用手机玩的游戏”。 要把手机本体直接作为解谜装置使用。 仅靠屏幕触摸无法通关。 将手机搭载的传感器、摄像头、麦克风、振动、扬声器、设备方向、充电状态等，作为游戏世界中的物理法则使用。 但不要做成单纯的传感器功能演示合集。 要让所有功能都在同一世界观和同一套游戏系统中自然衔接。 世界观 玩家在一座身份不明的研究设施中发现了神秘的黑色立方体装置“DEVICE”。 立方体与手机相连，并能感知现实世界中手机的状态。 当玩家倾斜手机时，DEVICE 内部的重力会发生变化。 旋转设备时，整个空间也会随之旋转。 现实中的光线、颜色、声音、方向和动作等，都会流入 DEVICE 内部。 序章看起来它只是一台实验装置，但随着游戏推进，DEVICE 也会逐渐意识到玩家的存在。 后半段加入利用 “玩家正在操作手机” 这一关系本身的元解谜。 不要做成恐怖作品。 可以有诡异感、未知技术和神秘感，但核心应是求知欲与发现的乐趣。 视觉品质 这是最重要的项目。 在手机性能允许的范围内，尽可能采用写实 3D 表现。 禁止廉价手机游戏风格的 CG。 禁止卡通风格。 禁止低多边形质感。 除 UI 外，尽量不要保留平面的临时素材。 如果使用 Unity，以兼顾移动端性能的 URP 为基础，同时结合 ・PBR 材质 ・Metallic / Roughness 表现 ・法线贴图 ・环境光遮蔽 ・反射探针 ・光照探针 ・高质量阴影 ・软阴影 ・Bloom ・色彩分级 ・屏幕空间效果 ・具有体积感的光照 ・仅在需要的位置使用景深 ・基于物理的玻璃 ・金属 ・湿润地面 ・划痕 ・指纹 ・灰尘 ・细微表面凹凸 ・自发光材质 ・反射 ・环境音 等效果。 场景设定为昏暗且富有高级感的未来研究设施。 以黑色金属、玻璃、混凝土、白色发光线条、精密机械和液压部件为主。 不要做成完全漆黑，要让重要物体能在自然光照下清晰辨认。 DEVICE 是游戏的标志性装置，必须以极高品质制作。 DEVICE 本体： 由黑色金属和玻璃构成，尺寸约为 20～30 厘米的立方体。 每个面拥有不同的机械结构。 接缝要极其精密。 内部透出微弱的白光或冷白光。 根据玩家操作，内部结构会发生实体变形、旋转和展开。 加入具有机械段落感的动画。 基本游戏画面 DEVICE 位于竖屏中央。 玩家拖动 DEVICE 使其旋转，调查各个面。 周围是研究设施。 镜头要有电影感，但不能影响操作性。 基础 UI 保持极简。 不要一直显示大量按钮。 优先营造亲手触碰并操作 DEVICE 本体的感觉。 核心系统 以下功能不要做成彼此独立的小游戏，而要整合为同一游戏世界中的输入系统。 1. 触摸 点击 双击 长按 拖动 滑动 双指缩放 双指 三指 多点同时按压 等操作都应可用。 直接触摸操作 DEVICE 的按钮、操纵杆、旋转环和旋钮等部件。 2. 陀螺仪 让手机倾斜与 DEVICE 内部的重力联动。 例如： 只靠倾斜手机，将内部的金属球运到终点。 倾斜液体，使其接触电极。 调整光线角度。 3. 加速度传感器 摇晃设备。 突然停下。 检测轻敲般的动作。 但不要要求玩家过于剧烈地摇晃设备。 要考虑安全性。 4. 设备方向 Portrait Landscape Face Up Face Down 等状态都要反映到游戏中。 设计只有将手机正面朝下放在桌上才会触发的事件。 5. 摄像头 将现实世界的颜色带入游戏。 当玩家用摄像头拍摄红色、蓝色、绿色等物体时，分析画面中央附近的主色，并将其作为能量传入 DEVICE。 不要将图像本身上传到服务器。 尽可能在设备本地处理。 还要为无法使用摄像头的情况准备替代操作。 6. 麦克风 使用音量 持续时间 简单的频率特征 等信息。 例如： 吹气 发声 拍手 保持安静一段时间 等。 不要强制要求语音识别。 不要保存录音数据。 7. 触觉反馈 / 振动 这是非常重要的部分。 设计仅靠振动传达屏幕上不会显示的信息的关卡。 例如： 越接近目标，振动间隔越短。 左右两侧使用不同的振动模式。 使用短、长振动组成密码。 为关闭振动的设备提供替代显示。 8. 扬声器 利用立体声音效的方向感。 不要强制要求使用耳机。 将音高、周期和左右声道定位等作为解谜信息。 9. 亮度 在可能的情况下使用环境光传感器。 对于不支持该功能的设备，考虑使用摄像头亮度等替代方案。 设计在暗处才会出现的机关。 设计在亮处才会充能的机关。 10. 指南针 在支持的设备上获取方位。 设计需要将手机朝向北方、南方或特定方向的谜题。 没有传感器时切换为替代谜题。 11. 充电状态 如果能够获取设备开始充电的状态， 加入插入真实充电线后，电力传入 DEVICE 的演出。 但必须为无法进行这一操作的用户提供替代通关方式。 12. 电池 如果可以获取电量，将其用于特殊事件。 禁止设计成会因电量不同而无法通关。 13. 时间 可以将当前时间用于特殊谜题或演出。 禁止设计成只有特定时间才能通关。 不要强制玩家等待。 谜题设计 不要一开始就批量制作 100 个单薄的谜题， 先制作约 20～30 个完成度极高的关卡。 每一关都要带来不同的发现。 禁止只改变数字、重复相同操作的关卡。 章节 1：TOUCH 以触摸操作为核心，让玩家理解游戏规则。 触碰 DEVICE。 旋转。 按下。 拉动。 打开。 章节 2：GRAVITY 引入陀螺仪和加速度。 DEVICE 内部的物理世界与现实手机的姿态同步。 章节 3：SENSE 引入摄像头 麦克风 光线 声音 振动 等输入。 章节 4：OUTSIDE 设计让玩家将注意力移到屏幕之外的谜题。 将手机翻面。 保持静止。 对准方向。 获取周围颜色。 章节 5：DEVICE 组合此前学过的规则。 屏幕上显示的指令不再一定正确。 例如： 屏幕上显示 SHAKE 。 但摇晃设备会失败。 正确答案是让设备完全静止。 另一个谜题显示 MORE LIGHT 。 调高屏幕亮度没有反应。 只有让现实世界的光进入摄像头才能通关。 最终关卡要 触摸 设备方向 陀螺仪 振动 声音 现实世界输入 等多个要素组合成大型谜题。 必须实现的代表性关卡 “黑暗迷宫” 画面几乎完全变暗。 玩家看不到自己的位置。 倾斜手机，移动看不见的球体。 越接近出口，振动越强、频率越快。 最终仅凭振动感知抵达终点。 在无障碍设置中也可以启用声音辅助。 “DON'T LOOK” DEVICE 在屏幕上显示 DON'T LOOK 。 玩家将手机翻面。 检测到 Face Down 后，在不可见期间从 DEVICE 内部传出机械声。 几秒后翻回来，DEVICE 已经发生变形。 “STEAL COLOR” DEVICE 内部存在一个无色能量核心。 用摄像头读取现实中的红色、蓝色、绿色等颜色。 读取到的颜色实时转化为液态能量，流入 DEVICE 内部。 “STAY STILL” DEVICE 正在剧烈振动。 玩家一开始会想摇晃手机。 但正确做法是让设备完全静止。 当加速度在一定时间内低于阈值时，装置会稳定下来并打开。 “POWER” DEVICE 完全停止。 在支持的设备上，开始为手机充电后，电力会流入 DEVICE。 金属线路依次亮起，内部机构重新启动。 同时准备替代操作。 DEVICE 内部的物理表现 积极使用物理模拟。 金属球 液体 重力 磁铁 齿轮 轨道 反射板 激光 旋转环 圆柱体 活塞 锁定机构 玻璃 电极 线缆 等元素。 但不要让游戏变成“完全依赖物理模拟、运行不稳定”。 关键谜题使用受控的物理处理，确保结果可复现。 演出 解谜成功时，不要只显示简单的“CLEAR”文字。 让 DEVICE 本体发生变形，以此回应玩家。 组合锁解除 齿轮转动 内部发光 金属面板分离 玻璃内部的液体流动 机械臂展开 等效果。 在答对的瞬间，营造 “亲手启动了巨型精密装置” 的满足感。 音频 这是非常重要的部分。 不要只是让 BGM 一直播放。 研究设施的空调声 远处的机械声 DEVICE 内部的伺服声 金属卡扣声 玻璃 电流 磁力 低频 振动 等声音进行分层。 根据触碰 DEVICE 的位置改变声音。 使用耳机时增强声源定位感。 UI 尽可能整合进游戏世界。 不要排列廉价手机游戏风格的按钮。 菜单： CONTINUE CHAPTERS SETTINGS ACCESSIBILITY CREDITS 左右。 解谜过程中的提示，以 DEVICE 内部的显示装置或投影文字呈现。 提示系统 即使玩家卡关，也不要立刻显示答案。 提示 1： 应关注的位置。 提示 2： 要使用的手机功能。 提示 3： 接近完整的解法。 分为这三个阶段。 无障碍 由于游戏大量使用传感器功能，这一点尤其重要。 实现以下功能。 可将振动转换为声音或屏幕显示。 为声音谜题提供视觉辅助。 为颜色谜题提供色觉辅助。 不要要求剧烈的设备操作。 取消必须剧烈摇晃手机的操作。 为无法使用摄像头、麦克风或指南针的情况提供替代谜题。 即使用户拒绝部分传感器权限，也不能导致游戏无法继续。 隐私 不要将摄像头图像、麦克风音频、位置信息等发送到外部服务器。 游戏流程不要强制要求 GPS。 在即将使用权限前说明使用原因，再请求权限。 不要请求不必要的权限。 技术架构 如果条件允许，使用 Unity 6 系列 + C#。 采用面向移动端的 URP。 将项目模块化。 至少具备以下结构。 SensorManager PuzzleManager GameStateManager AudioManager HapticsManager PermissionManager SaveManager AccessibilityManager DeviceCapabilityManager 不要在 Puzzle 代码中反复直接调用各项手机功能。 通过 SensorManager 等进行抽象， 以便在真实设备传感器 编辑器模拟输入 不支持设备的回退方案 之间切换。 传感器调试 为了也能在 Unity Editor 中开发， 实现 Developer Sensor Panel 。通过滑块和按钮 模拟设备倾斜 加速度 Face Up / Face Down 麦克风音量 环境光 指南针 充电开/关 电池电量 振动事件 摄像头主色 等模拟输入。 即使不连接实体设备，也能测试主要谜题。 存档 保存章节进度 已通关关卡 提示使用情况 设置 无障碍 收集要素 等内容。 即使在关卡中途，也要能够安全中断。 性能 不要以写实画面为理由让游戏无法运行。 目标是在主流中端 Android 设备上也能游玩。 LOD 使用遮挡剔除 GPU Instancing 纹理压缩 烘焙光照 反射探针 仅在必要范围内使用实时光照 对象池 减少 Draw Call 等技术。 将 Quality 设置分为 LOW MEDIUM HIGH ULTRA 几个等级。 在高性能设备上呈现非常高品质的画面。 完成条件 不要只做原型， 而要达到能够完整体验标题画面 开场 教程 多个章节 多个关卡 传感器输入 3D 演出 音频 设置 无障碍 存档 关卡选择 结局 等完整游戏内容的状态。 如果可能，生成实际的 Android 构建。 即使受构建环境限制，无法生成 APK/AAB， 也要完成可直接用 Unity 打开并构建的完整项目。 制作过程中的决策方针 不要因为“简单”就改成 2D 或简易 UI。 不要为了“节省时间”删减游戏的核心机制。 无法获得外部素材的部分，尽可能自行制作或程序化生成。 即使需要临时素材，也不要让整个游戏充斥着临时素材。 尤其是 DEVICE 研究设施 核心解谜装置 灯光 材质 成功演出 必须以高品质完成。 工作流程 首先在短时间内确定整体设计。 然后不要继续解释，而是转入制作。 1. 创建项目 2. 基础 3D 场景 3. 制作 DEVICE 4. 基础操作 5. 传感器抽象化 6. 解谜框架 7. 实现代表性谜题 8. 构建章节 9. UI 10. 音频 11. 演出 12. 存档 13. 无障碍 14. 优化 15. 测试 16. 修正 17. 构建 按此顺序推进。 即使部分环节失败，也不要停止整个工作，要通过替代方案最大限度提高完成度。 最终成果 最终应保留以下内容。 ・完整游戏项目 ・主要源代码 ・游戏场景 ・3D 模型及材质 ・UI ・音频设置 ・传感器系统 ・解谜系统 ・存档系统 ・构建设置 ・README ・Android 实机测试步骤 ・所使用的手机功能列表 ・不支持设备的回退方案 ・已知问题列表 禁止不制作成果物、只解释说明后结束。 最高优先级依次为： 1. 有趣 2. 体现手机特性 3. 3D 世界的真实感 4. 亲手操作 DEVICE 的感觉 5. 作为谜题的合理性 6. 实际运行 。 不要做成“给现有手机游戏添加传感器功能”， 而要完成一款让人感觉手机这一硬件仿佛就是为这款游戏而存在的作品。 从这里开始，不要停留在企划说明，立即开始实际制作。 另外，请充分加入上述内容中可以进一步打磨、能够让游戏更有趣的要素，并将 3D 做得足够写实