零
前言
麒麟子在开发中搞出来的框架,都是遵守“大道至简,实用至上”这两个基本原则。
接触一个引擎的第一件事,就是搞出一个实用的框架,方便在此基础上做开发。
由于目前的引擎已经是对象 组件模式,所以在场景对象管理上,不需要花太多功夫了。我们主要集中在界面管理这块。
1
常见的几种游戏类型
既然我们的框架想要满足日常开发,就不得不满足星辰大海般的需求。从客户端的角度,我们可以把游戏分为三类。
1.1、纯界面玩法
像一些SLG、卡牌、象棋等可以视作纯界面玩法。(也有某些大作要求3D表现效果的,我们不作讨论),比如下面的这类游戏。
动物餐厅
1.2、某些纯界面&战场场景
王者荣耀
1.3、从头到尾都是3D场景
魔兽世界
1.4、小结
仔细分析以后我们可以发现,假如我们的框架始终支持 2D/3D场景 界面 这样的能力。就可以了。
2
单场景 vs 多场景
单场景 Prefab 和 多场景从 Cocos 2d-x 提供了 replaceScene 函数开始,就一直有人在争论这个话题。只要引擎提供了“场景”这个定义的,都会遇上决策问题。
麒麟子看得很明白,所谓的引擎场景管理,就是给了你一次无脑销毁所有结点的机会。
如果你是在两个截然不同的逻辑之间切换,那其实是可以使用引擎的场景切换功能的。 如果逻辑相差不大,我建议依然采用单场景方式。
而麒麟子更推荐的是单场景 Prefab方式,这样会迫使你自己更注重场景节点和资源的管理。
3
框架内容
3.1、程序启动入口
程序启动入口包含两个部分。
3.1.1、最小场景
最小场景如果不出意外,我们只需要一个Canvas节点,一个MainCamera节点,一个MainLight节点就好了。
3.1.2、App.ts
麒麟子喜欢以 App.ts 作为程序入口,将这个App.ts挂在Canvas节点上即可。App.ts的内容并不多,如下所示
代码语言:javascript复制import { _decorator, Component, Node } from 'cc';
import { UIMgr, UILayer } from './UIMgr';
import { HUD } from './HUD';
const { ccclass, property } = _decorator;
@ccclass('AppTs')
export class AppTs extends Component {
start () {
UIMgr.inst.setup(UILayer.NUM);
UIMgr.inst.showUI(HUD);
}
}
我们可以清晰地看到,在这里,麒麟子只启动了 UIMgr,如果还有其他游戏管理器需要一开始就初始化,那么把它们放在这里就好了。
3.2、界面管理器
- 界面管理器至少要包含几个功能
- 动态加载和销毁界面
- 界面层级管理
- 界面事件自动管理机制
- 界面与游戏业务逻辑通信机制
上面说的这些,框架里都自带了。
4
分辨率自适应
很多小伙伴一定还在纠结是用 fitWidth 还是 fitHeight 吧。
如果使用 fitWidth 遇上更细长的设备,界面上面部分可能被裁剪。
如果使用 fitHeight 遇上更短的设备,界面左右部分可能被裁剪。
其实我们想要的只有一句话:任何时候,都不要裁剪。
基于这个目标,我们制定出的策略就是。
- 在比设计分辨率更细长的设备上,我们使用 fitHeight,这样一来,他长由他长,我们只需要保证背景左右能够填充就行。 在比设计分辨率更短的设备上,我们使用 fitWidth这样一来,他高由他高,我们只需要保证背景上下能够填充就行。上面的适配机制,已经被麒麟子写成了一个函数。 public resize() { //根据屏幕大小决定适配策略 let dr = view.getDesignResolutionSize(); var s = cc.view.getFrameSize(); var rw = s.width; var rh = s.height; var finalW = rw; var finalH = rh; if ((rw / rh) > (dr.width / dr.height)) { //!#zh: 是否优先将设计分辨率高度撑满视图高度。 //cvs.fitHeight = true; //如果更长,则用定高 finalH = dr.height; finalW = finalH * rw / rh; } else { /*!#zh: 是否优先将设计分辨率宽度撑满视图宽度。*/ //cvs.fitWidth = true; //如果更短,则用定宽 finalW = dr.width; finalH = rh / rw * finalW; } view.setDesignResolutionSize(finalW, finalH, ResolutionPolicy.UNKNOWN); let cvs = find('Canvas').getComponent(UITransformComponent); cvs.node.width = finalW; cvs.node.height = finalH; }
关于这个函数,有两个地方要注意:
- 在设置面板里面,fitWidth和fitHeight都得去掉,一个都不要勾,否则可能出现设置失效。
- 麒麟子在调用 view.setDesignResolutionSize 函数的时候,最后一个参数传的是ResolutionPolicy.UNKNOWN。
这样一来,这个函数是可以重复调用且生效的。当我们处于微信浏览器的时候,横竖屏旋转会导致宽高比不一致,这就需要再次调用这个函数来重新调整布局。
5
游戏逻辑与界面通信机制
麒麟子这里没有MVC,也没有MVVM,只有以下几个套路
- 数据、数据更新方法由逻辑管理器提供
- 数据变更,想让界面产生改变,则通过事件传递
- 界面可以直接调用逻辑管理器
- 两个界面之间,只能通过事件传递(需要两个界面联动的情况非常少,一般情况下界面之间的逻辑都是互不干扰的)
也就是说,逻辑管理器不知道界面的存在,但界面是知道逻辑管理器的存在的。
我举一个关于个人信息的例子。在这个例子中,我们会涉及到三个文件 MyInfoMgr.ts(用户信息逻辑管理器 M) 、UIMyInfoController.ts(用户信息界面控制器 C) 、MyInfo.prefab(用户信息界面布局 V)。
如果非要用MVC来对应的话,就按我后面标记的字母来对应吧。
当用户点击个人按钮时,UIMgr会实例化UIMyInfoController类,UIMyInfoController类会加载MyInfo.prefab。
当加载成功后,UIMyInfoController会有一个onCreated回调,我们可以在回调里初始化我们的显示信息。
UIMyInfoController需要监听用户信息改变相关的事件,当收到事件的时候,需要对应地做显示更新
MyInfoMgr持有用户数据并提供访问接口以及数据修改接口,当数据产生修改时,会抛出修改事件。它不关心这个事件是否有人要用。无脑抛出就行。
6
总结
与其说是框架,不如说是麒麟子的惯用套路。这个套路没有出色的地方,也不满足很多学术性的依赖解耦标准。但这个套路陪着我走过了大大小小很多项目。
如果要给它下一个定义的话,我觉得就是两个词:“简单、实用”。
哦对了,只能用Cocos Creator 3D 1.1.1打开。
源码地址:
https://gitee.com/qilinzi/creator3ddemos