普通小游戏接入指南

一、了解小游戏

小游戏是一种基于字节跳动产品生态开发且无需下载安装即可使用的全新游戏应用,实现了客户端“点开即玩”的优质用户体验。小游戏拥有开发轻便快捷,发布流程简单的特点,同时依托字节跳动生态优势,让小游戏天然具备较强的内容分发能力,支持小游戏开发者快速推广与变现。

开发者可以通过小游戏内的广告能力和内购功能来获取收益。通过下面的介绍,你将快速了解如何创建一个属于自己的小游戏。

二、注册与认证

2.1 注册登录账号

1.在开发者平台中点击右上角的「快捷登录」进行帐号注册。

2.当前小游戏平台仍采取申请开发制,故开发者在登陆后需要通过【申请创建】提示完成申请流程。

小游戏申请发出后,字节小游戏将在两个工作日内通过您注册时的手机号或邮箱给予您答复。若您收到邀请信息,说明您的开发权限已获批,可通过平台接入。

注意事项:

1.审批通过后,该账号方有创建小游戏的权限。

2.手机号等信息请如实填写。

3.企业主体开发者请填写企业全称,个人主体开发者请填写个人姓名。

4.小游戏体验路径为必填项目 。请填写提交可体验的测试链接 url 链接,无法体验的游戏申请将一律驳回。

2.2 主体认证

主体认证包含主体资质提交和对公打款验证,开发者需要先完成主体资质提交,再完成对公打款验证,认证成功后才能进行小游戏管理操作。

目前支持的主体身份类型:

  • 企业开发者:适用于企业,个体工商户,政府组织,海外机构等其他机构。每个企业主体可以创建 50 个小游戏。
  • 个人开发者:个人主体验证适用于由个人运营的小游戏,每个个人主体可以创建 25 个小游戏。

特别提醒:

1.企业主体开发者请勿选择“个人开发者”,否则未来将产生无法结算等问题。

2.平台暂不支持主体变更,只支持工商更名

(1)资质提交:

请根据主体类型提交对应资质:

主体类型

所需信息

注意事项

个人主体

包括但不限于个人身份证、手机号等

验证类型支持【手机号实名认证】或【银行账户实名认证】,认证方式二选一即可:

  • 手机号实名认证:校验用户的姓名、身份证号、手机号。手机三要素实名认证指的是通过三网手机实名认证数据接口,来检验个人的姓名、身份证、手机号码是否一致,支持支持移动、电信、联通号码。
  • 银行账户实名认证:校验银行卡持卡人的姓名、 银行卡号、 预留手机号、 身份证号的真实性,是对银行卡用户资料真实性进行的验证审核,以便建立完善可靠的互联网信用基础。

企业主体

包括但不限于企业营业执照、经营者信息等

  • 证件类型:优先选择填写“营业执照统一社会信用代码”,若无则按照实际证件的真实情况进行填写。
  • 证件照片:营业执照上加盖的公章需清晰可见,营业执照请勿带有不相关的水印(如有需求可带有“仅供申请巨量引擎数字证书使用”的水印), 若为营业执照复印件,需标注“与原件一致”并加盖公司公章,营业执照资质需清晰可见。

(2)对公验证:

对公验证共有 4 种方式:

验证方式

须知

填报指引

银行账户实名认证

(无需等待打款)

1.仅限个体工商户,且营业执照证件类型为“统一社会信用代码”的账户。

  • 验证类型、公司名称、资质编号、经营者姓名默认拉取资质提交页面的信息;
  • 申请人需填写经营者的身份证号码、个人银行卡号、银行卡预留手机号,短信验证码

平台向客户打款验证

1.平台向客户打款验证有两次打款机会,若平台向客户两次打款失败,请选择其他方式进行对公验证(系统打款失败不占用机会)

2.从发起验证之时起,48 小时内未输入验证金额的,会显示超时,本次打款验证失效,需重新验证

  • 验证类型、公司名称默认填写资质页面信息
  • 开户行:通过关键字搜索,准确填写开户行信息。如“中国工商银行北京海淀支行”,尝试搜索“海淀支行”或“工商 海淀”即可;
  • 银行卡号:请认真填写,保证信息准确。若验证类型为个体工商户,银行卡号应根据所选的银行卡类型(对公银行卡或个人银行卡)进行填写,且个体工商户营业执照资质类型不是“统一社会信用代码”的,只能使用对公银行卡

客户向平台打款验证

1.若客户向头条打款验证失败,可重新验证,无次数限制

2.从发起验证之时起,48 小时内平台没有收到打款,本次验证失效,需要客户重新验证

  • 验证类型、公司名称默认填写资质页面信息;
  • 银行卡号:请认真填写,确保信息准确(若个体工商户营业执照资质类型是非“统一社会信用代码”,只能使用对公银行卡。)

申请验证授权

1.相同营业执照的公司若已开通巨量引擎的商业化账号,并完成对公验证,可向该账号发起验证授权。

2.如果在 B 游戏中申请 A 游戏进行验证授权,请在 1 小时内登陆 A 游戏“认证中心-对公打款验证”中,进行授权确认,否则授权申请将失败。 (A 游戏“认证中心-对公打款验证”地址如下,请将“appid”替换成实际appid:https://microapp.bytedance.com/app/appid/crt_mmm

  • 授权账户必须是已完成对公验证,待授权账户必须是待对公验证状态;
  • 授权账户与待授权账户公司名称、验证类型必须一致,如个体工商户,经营者姓名也必须一致
  • 如果您在可授权列表里没有找到特定的账户,可能有以下原因:

(1)该账户还未通过对公验证

(2)该账户不是正常打款通过的对公验证,不能给别的账户授权

(3)该账户离有效期只有不到 30 天,不允许给别的账户授权

三、开发小游戏

3.1 下载安装开发者工具

开发者可以在 开发者工具下载,根据所使用的操作系统选择相应的版本下载安装。安装完成后即可打开小程序开发者工具,目前支持手机登录和邮箱登录。

3.2 开发小游戏

在开发者工具登录平台账号后,点击“创建一个小程序”,即可新建工程。根据提示设置项目类型、 工程目录、工程名称、appID(查看“开发者平台—开发管理—开发设置”)。点击“确认”,进入编译主界面。

注意:

目前字节小游戏支持主流游戏引擎,Cocos,Laya 以及 Egret。开发者在游戏引擎中开发完成后,发布时选择发布到字节跳动小游戏,即可在字节跳动平台运行。

此外,如果开发者不依赖游戏引擎,只需要将工程文件打包成小游戏 ,包的目录结构要求与平台保持一致,目录下要有 project.config.json , game.json 即可运行。

目前支持两种编译预览方式:

1.IDE 预览:当小游戏代码发生变动后会自动触发编译,可以在左侧的游戏界面看到最新的效果。另外开发者也可以手动点击编译按钮,触发编译。

2.真机预览:点击开发者工具菜单中的【预览】按钮,生成预览二维码后,可以用抖音、今日头条、火山等客户端的扫一扫功能,在手机上体验。

3.3 上传小游戏

在开发者工具中开发调试完成后,可以点击左上角【上传】按钮,按流程填写相关信息将游戏内容上传至开发者后台提交审核、发布小游戏。

四、提审指引

上传游戏包

开发者在完成当前版本小游戏的开发与调试后,可以使用 IDE 工具编译上传游戏包。

目前字节跳动针对小游戏分为三个版本:

版本阶段

说明

线上版本

面向全部用户的正式版本

审核版本

开发版本的提审阶段,通过之后可以进入灰度测试,否则需要根据驳回原因退回修改,此版本请谨慎对外分享

测试版本

开发版本的测试阶段,开发完成上传之后可以扫码进入测试体验,此版本请谨慎对外分享

提审小游戏

1.完成上传后,可以在后台的版本管理中查看上传的测试版本,提审前可以点击右侧二维码进行扫码体验。

2.点击【提交审核】,自行选择希望上架的字节系 APP,审核将会在 1-2 个工作日完成。

注意: 在上传时系统将提示上传三张图,图片必须包含如下内容:一张游戏标题、一张游戏内主要游戏画面。(若游戏内没有含有游戏标题的页面,亦可使用加载页面、海报图等含有游戏标题的页面)

3.另外,可以在「审核版本」中看到正在审核的小游戏版本及审核状态: 若审核不通过,会显示未通过原因,请点击【查看详情】按照指引进行修改后再次提审。

相关审核标准具体可参考:小游戏审核标准

待审核通过方可点击发布上线。

注意事项:

  • 小游戏在提审前,为了保证通过率,请开发者提审前可自测环节进行自查:开发者自审自查
  • 小游戏首次上线前的审核都需进行 QA 回归,预计在 1-2 个工作日;
  • 如果使用了网络相关功能,务必于后台配置 " 安全域名 " 的白名单,否则将影响游戏上线和正常功能。安全域名必须为 https:// 及 wss://协议,非加密传输的请修改伺服器域名。

(1)request 合法域名

(2)socket 合法域名

(3)uploadFile 合法域名

(4)downloadFile 合法域名

五、发布小游戏

5.1 发布小游戏

版本审核通过后,开发者点击“发布”,小游戏即可发布上线。

5.2 注意事项

设置搜索关键词与分享

1.当发布未配置搜索关键词与分享内容版本时,会弹出提示与跳转地址,点击【前往配置】,建议上线前完成该配置。

2.如果已有搜索关键词和分享内容,想要查看或进行修改:

可以在后台【设置】中的【基础设置】进行分享设置:分享标题、分享文案、分享图案

可以在后台【流量配置】中的【搜索】进行搜索标签配置,另提交的搜索关键词应符合 小游戏关键词搜索

选择开通虚拟支付/广告能力

1.开通内购能力:在开发者后台的功能管理-支付(注意通过主体认证,且资质提交完全,例如版号必须提交),按流程操作申请。

2.开通广告服务:开发者在完成相关主体资质认证和对公验证后,即可在后台的广告中心-流量主对已上架的小游戏进行申请开通操作。

六、运营指引

6.1 用户获取

同一小游戏可以同步上线多个宿主端(宿主:即小游戏可上线的字节 APP),为开发者节省大量的人力和时间。目前已经逐步开放今日头条、抖音、火山、西瓜视频、头条极速版,更多字节系产品在陆续接入中。新游上线,字节小游戏平台均会给到冷启动量,后期会根据产品数据,转化率等数据,通过去中心化算法模块精准匹配、直接触达用户,为游戏持续给量,更多内容可见《用户获取》

6.2 日常管理

平台同时为开发者提供了大量自运营工具用于拉新和留存,并为达到条件的小游戏提供支持。关于小游戏运营效果的数据分析,可以通过平台提供的数据分析看板进行查看,更多内容可见《数据基础介绍》

6.3 买量推广

对于有推广需求的开发者,平台也开放了相应的买量机制,详情可见《小游戏发行人计划》《小游戏微端 X 巨量引擎信息流投放 操作指南》

6.4 终止运营

如需停止对外运营小游戏,可进入开发后台基础设置管理页面点击下架。 注意:内购小游戏下架需提前 60 天。

七、性能优化

7.1 图片资源使用注意事项

不规范的资源管理方式,容易导致游戏加载速度慢、运行内存大,影响游戏的体验和性能。下面列出一些需要注意的地方:

优先 png 格式

UI 输出资源时,应该优先使用 png 格式而不是 jpg 格式。png 格式采用无损压缩算法,jpg 使用的是有损压缩算法,用 png 格式输出资源,获得的图片质量是好于使用 jpg 格式的。

如果图片的大小比较大,可以使用 tinypng、pngquant 这类的工具提高压缩率(有损压缩)或者使用 ect2 等格式的压缩纹理。但是最好使用初始的 png 图片而不是用 tiny 等工具压缩后的 png 图片生成压缩纹理,因为压缩纹理也是采用有损压缩算法。多次对图片使用有损压缩算法进行压缩,会进一步降低图片质量,导致资源效果差。

控制尺寸

在保证外观效果的情况下,尽可能地减小图片尺寸。例如下图中的海水这类重复纹理,应尽可能减少尺寸。

控制尺寸的效果有多大?我们来举个例子,假设图片最初尺寸为 512x512,80 张该尺寸的 RGB888 png 图片,需要占用 80x512x512x3byte = 60M 内存,若将尺寸优化成 128x128,则仅需要 80128128*3byte = 3.75M 内存。占用内存可减少 93.75%。

修剪透明部分

下面左边的图片,一半的面积,都是透明部分,浪费大量的空间,在 UI 输出资源时应该尽量避免,或者用工具修剪掉透明部分。右边是修剪后的图片。尺寸由 750375 变为 466284,占用内存减小 50%。

合并图片

合并图片的目的是为了减少引擎读取文件的次数,加快加载速度。合图的关键问题是,合出的大图, 空间利用率是否足够高 ,较低的空间利用率,会造成游戏运行内存的增大。合图要注意的几个问题如下:

1.应该尽量只对尺寸比较小的图,进行合图操作。尺寸大于 256x256 的图片,要考虑下。

2.合出的整张大图,尺寸不要太大,一般不大于 1024x1024,最好不要超过 2048x2048。

3.尽量保证合图的利用率,不要低于 75%(越高越好)。实际上 1 和 2 也是可以提高合图利用率的。合图时,记得打开允许旋转选项,这也能够提升利用率。导出格式选用 RGBA8888。

4.尽量保证关联性大的图片合并在一起。比如同一界面的资源,应该优先合在一张图上,而不是放在多张图里,这样子保证可以一次操作就可以读取或者传送整个界面需要的资源。

资源复用

对尺寸比较大的资源,尽量进行复用。像界面背景图片这样的资源,应该抽取出,单独出资源。

九宫格拉伸

当界面资源要显示的图片尺寸比较大,且中间部分是由连续有规则的像素组成时,通常使用九宫格拉伸的办法,大幅度减小图片尺寸的大小。对于可以进行拉伸的图片,划分成以下 9 个部分:

拉伸规则如下:

  • 四个边角 1、3、7、9 不做任何拉伸;
  • 2、4、6、8 做单向拉伸,2、8 做横向拉伸,4、6 做纵向拉伸
  • 5 做双向拉伸

下面的图片尺寸是 612946,格式是 RGBA8888,如果使用九宫格拉伸的办法,那么尺寸可以做到小于 300300,占用内存减小 80%以上。

压缩纹理

像场景贴图、界面背景图等资源,占用内存比较大,但为了保证效果,不能去减小尺寸,这种情况下可以考虑使用压缩纹理。压缩纹理采用的是有损的压缩算法,一般效果都是可以接受的。下面是两张对比图:左边是 s3tc 格式的压缩纹理资源,右图是未压缩的图片资源。对比下两张资源图,大部分地方肉眼不容易识别出差别,左边图片在边缘细节上,要差一些(可以双击放大看)。

7.2 纹理内存优化

内存过大导致的问题

游戏运行时占用的内存大小,是衡量游戏性能的一个非常重要的指标。游戏如果占用的内存过大,会导致以下的问题:

  • 发热,发烫。过多的内存数据传输,是导致游戏发热的主要原因之一。
  • 延迟、卡顿。像纹理的加载、传输都需要耗费时间,另外内存资源占用的越多,系统也更加容易触发 gc 操作,导致游戏非预期卡顿。
  • 闪退。游戏超过一定的内存上限,操作系统会强制杀死进程。

而纹理占用的内存占整个运行内存的比重非常大,并且容易做优化,所以纹理内存占用的大小是需要重点关注的。

纹理加载流程

下面是一张图片加载的整个流程。

可以看出读取非压缩纹理与压缩纹理的主要区别是: 压缩纹理不需要解码 ,数据是可以直接被 gpu 读取;png 等格式图片,不能直接被 gpu 读取,需要解码成未压缩的位数据。不过实际运行中, 并不是所有阶段的数据都需要保存 。非压缩纹理在 cpu 内存里的编码数据(蓝色区域),在解码后,是不需要再保存的。

纹理管理方式

下面列举几种小游戏开发可以使用的纹理管理方案:

管理方式

优点

缺点

将所有资源都加载进 gpu 内存,那么对于非压缩纹理,只需要在 gpu 内存保存一份解码数据,压缩纹理只需要在 gpu 内存保存一份压缩纹理数据。也就是只需要红色区域的部分。

运行性能最好,适合使用 three.js 这种不自动回收 gpu 资源的引擎,并且整个游戏纹理内存占用不大的情况

存在一定门槛,要求开发者对 webgl 和所使用的引擎有一定的了解,保证 gpu 内的纹理数据,没有被引擎或者自己释放。

将所有资源都加载进 cpu 内存,然后在运行时,将所需要绘制的资源,加载进 gpu 内存,不需要绘制时,可以释放掉。

运行性能较好。

如果引擎未能自动在绘制纹理时,将纹理数据从 cpu 内存 copy 进 gpu 内存,需人工干预。

将部分资源加载进 cpu 内存,然后在运行时,再将所需要绘制的资源,加载进 gpu 内存。根据需要将资源加载、释放。

占用的内存小,适合做多关卡、多场景游戏。

需要主动管理好资源的加载与释放问题。一般在加载关卡进度的时候,完成资源的加载。

纹理大小如何计算

要想优化纹理占用的内存,就要知道如何计算每张纹理的大小。下面用一个例子进行说明。

上面是脸萌的主场景图片,jpg 格式,尺寸为 512512,颜色空间为 RGB888,大小 100kb。解码后占用的内存大小计算公式为:长 通道个数 通道位数,如果解码成 RGB888 格式,那么占用的内存大小为 51251238bit = 0.75M。而对应的 etc2 RGB888 格式的压缩纹理占用的内存大小为 512512*0.5byte = 0.125M(实际大小为 135kb,因为还包含纹理描述信息)。下面的表格列举出几种常用的压缩纹理格式每像素占用的字节数。

减小纹理占用内存的方法

那么减少单张图片占用的内存,有以下几个方案:

1.减小图片的尺寸,在满足视觉要求的情况下,尽可能地缩小图片尺寸,比如将一张 256256 图片缩小成 128128 尺寸,就减少了 75%的内存占用。

2.降低通道位数,比如 RGB888 格式的图片转换为 RGB565 格式。但是这也依赖于具体的解码方法,现在小游戏引擎,会把图片资源都解码成 RGBA8888 格式,那么即使将 RGB888 格式转换为 RGB565 格式,也不会降低解码后纹理数据占用的内存。

3.使用压缩纹理,但是有几个限制点:首先压缩纹理是有损压缩,会降低一些图片质量(一般不明显);其次各个平台、不同图形 api 支持的压缩纹理格式,也不尽相同。比如浏览器上可以支持 s3tc 纹理,手机端支持 etc2 纹理(需要支持 opengles3.0),ios 系统支持 pvrtc 纹理。

像 pngquant、tinypng 等采用 color reduction 方法压缩图片的工具,能够减小文件大小,加快加载速度,编码数据占用的内存也更小。但是在解码方式不变的情况下,并不能减小解码后的图片内存占用大小。

点击纠错
该文档是否对你的开发有所帮助?
有帮助
没帮助
该文档是否对你的开发有所帮助?
有帮助
没帮助