从游戏功能拆解资源需求
“帮我做一个好看的角色”无法告诉 AI 你需要什么工程结果。资源需求至少包含使用场景、观察方式、交互方式和交付约束。
先选择资源路线
| 游戏中的观察与交互 | 候选交付 | 必须提前明确 |
|---|---|---|
| 固定图标或头像 | 透明 PNG | 分辨率、留白、可读尺寸 |
| 固定视角的短循环 | PNG 序列帧／图集 | 帧数、播放速度、排版与透明边界 |
| 视角固定，但需要动作复用 | 2D 骨骼或 3D 转 2D 等方案 | 引擎动画方案、骨骼工具、资源预算 |
| 可绕物体观察、动态光照 | 实时 3D 模型 | 坐标、比例、材质与纹理规范 |
| 可变形角色与动作切换 | 蒙皮模型＋动作片段 | 骨架、权重、动作名、循环与位移约定 |
Blender 能生产 3D 转 2D 资源，但这并不意味着它会自动交付 Spine 工程。交付协议不同，应单独规划。
写一份最小资源合同
以下数值是炮塔教学案例的约定，用于学习如何表达规格；真实项目应依据实际屏幕与性能测试调整。
asset: turret_basic
use: 俯视角塔防中的可旋转炮塔
style: 低多边形、色块清晰、无外部素材
unit: 1 Blender 单位按 1 米建模
origin: 底座中心的地面位置
hierarchy: TurretRoot / Base / Yaw / Barrel
behavior: 游戏脚本控制 Yaw 转向，Barrel 保留独立节点
material: 基础 PBR 参数，优先不依赖外部图片
delivery: .blend、.glb、生成脚本、规格与验证记录
acceptance: 比例正确、地面贴合、层级保留、材质可读
还可以加入三角形数、材质数、纹理尺寸和骨骼数预算。不要用“必须低于 1000 面”代替完整验收：不同资产在屏幕上的占比、同时出现数量和着色成本不同。
把“效果”与“行为”分开描述
需求：“金币飞向右上角计数器，并增加余额。”
- 美术资源：金币的外观和旋转帧。
- 展示行为：起终点、路径、时长、缩放、播放帧率。
- 业务行为：余额何时确认，动画是否影响记账，失败如何恢复。
Blender 解决第一项；第二项主要在引擎；第三项仍是游戏和后端的职责。把它们拆开，可以避免让动画播放完成成为业务一致性的唯一触发条件。
补充视觉信息
风格参考应具体到可观察特征，例如“低多边形、柔和暖色、俯视 45°、轮廓粗壮、在 48px 下能识别”。参考图应说明哪些特征要学习，哪些不能照搬。没有参考图时，可以先让 AI 提供两三种低成本方向，再选一个。
验收必须能够复查
用“炮口朝向局部前轴，转动 Yaw 后炮口跟随，底座位置不变”替代“层级合理”。用“连续播放三个循环，首尾姿态无跳变”替代“动画流畅”。
把验收分为结构、外观、接入和运行四部分。结构可以脚本检查，外观需要观察，接入需要目标引擎，运行性能需要代表性设备。这些证据不能相互替代。