设计要求

本部分介绍了游戏大本营与 YouTube 用户体验之间的互动。

1 宽高比和方向

  • 游戏必须遵循自适应设计:可在所有宽高比下畅玩,并在视口更改时自动调整。示例(并非详尽无遗):9:32、9:21、9:16、3:4、1:1、4:3、16:9、21:9、32:9。
  • 游戏填充可用的视口。如果游戏未填满可用的视口,则游戏必须居中,并包含竖条框(左右两侧的空白边衬)或信箱模式(顶部和底部的空白边衬)。
  • 游戏不得锁定设备屏幕方向或设备姿态。
  • 当窗口大小调整时,游戏必须保持游戏状态或进度。我们建议不要重新启动或刷新游戏,除非用户可以快速从之前的状态恢复。

以下是这些要求的可视化示例:

展示了满足可玩广告大小要求的各种方法


2 种互动方式

  • 游戏必须支持所有互动的触控输入。
  • 游戏必须支持鼠标输入以进行所有互动。
  • 游戏不得无意中延迟或忽略任何用户输入。
  • 游戏不得在任何界面组件中出现任何错误或意外行为。
  • 游戏支持键盘输入,以进行方向输入或文字输入。
  • 游戏允许用户使用 Esc 键关闭模态框或对话框。
  • 游戏不得针对 Esc 事件调用 preventDefault()
  • 游戏可以在适当情况下使用触感反馈。如果游戏包含触感反馈功能,游戏必须提供一种用于开启和关闭触感反馈的切换方式。

3 游戏界面 (UI)

本部分介绍了游戏界面 (UI) 要求。

3.1 渲染

  • 游戏必须在所有屏幕分辨率、宽高比和密度下清晰呈现所有文字和图形(不得模糊、像素化或拉伸)。

4 元数据

开发者使用开发者门户发布游戏时,必须提供所有必需的元数据字段。如需详细了解元数据要求,请访问开发者门户

开发者不得在缩略图、说明或标题中包含任何品牌信息或徽标。

以下是所需元数据类型的部分示例:

  • 采用多种不同宽高比的图片缩略图
  • 游戏说明
  • 游戏名称
  • 游戏类型
  • 发布商 / 开发者信息

5 完成内容处理

  • 游戏必须告知用户没有更多可互动的内容,例如在最后一关之后或游戏进程结束时。

6 个不允许使用的元素

本部分介绍了在可玩广告中不允许使用的元素。

6.1 游戏内分享

  • 游戏不得显示游戏内分享提示。

  • 游戏不得显示将用户引导至外部内容(例如其他网站或游戏)的界面或链接。

6.3 其他用户协议

6.4 让人感到困惑的元素

  • 游戏不得将与可畅玩游戏操作相同的图标放置在实际可畅玩游戏操作附近,例如关闭、静音或菜单按钮。
  • 游戏不得包含用于在游戏内离开或退出的按钮。

屏幕视图:显示了另一组与游戏大本营操作按钮类似的按钮