cocostudio 2.0版本爬坑手记

最近才开始接触cocostudio,主要是用来做UI。不想过多吐槽了,只想说一点,备受推崇、重金研发的一个编辑器还比不上Unity中的一个插件。之前我感觉NGUI很难用,但那是跟DF GUI相比,现在感觉NGUI实在是太方便、太强大了。


1、基础使用:

在CocoStudio中编辑界面,然后导出资源,导出后会有资源目录和csb文件。我们使用时直接加载这个csb文件就可以了。它是protobuffer序列化的,CocoStudio2.0版本暂不支持json格式。

lua加载代码:

    local node = cc.CSLoader:createNode(file)       -- TODO 貌似是全屏的
    local panel = node:getChildByName(panel)        -- 对话框panel
    scene:addChild(node)

2、多分辨率处理:

cc.Director:getInstance():getOpenGLView():setDesignResolutionSize(1280,720,cc.ResolutionPolicy.FIXED_HEIGHT)

通过这个来设置设计分辨率,设计分辨率就是在制作UI和游戏内容时的默认分辨率,这个一旦决定下来就不会轻易动了。最后一个参数决定了实际屏幕分辨率不同时窗口的缩放。具体是SHOW_ALL还是NO_BORDER还是FIXED_HEIGHT看实际需求。事实上哪个都不能完美的解决我的实际问题。

一般来说,非全屏的UI可以不用关心多分辨率,里面的控件也不需要关心锚点,相对位置什么的,因为界面大小是固定的(无论是960x640还是1024x768界面都是那么大)。而一些需要全屏处理的UI内容就要特殊处理了,比如主界面。一般来说主界面的需求是左上角显示头像相关内容,右下角是一系列按钮,右上角也会有一系列按钮。这个时候在cocostudio中只用一个界面就显得力不从心了。 我的处理方法是把这些内容划分成三个panel,分别加载这三个panel,然后再根据对应的锚点关系把panel放置在争取的位置(比如锚点在右上角的,就把对应panel的anchor point设置成1,1,然后把它的坐标设置成winSize.width winSize.height)。

全屏拉伸的背景图片也需要特殊处理下,一般来说我们的需求是背景图片不变形的拉伸(保持高宽比),并铺满整个屏幕,不留黑边。

总结一下,感觉是这样子的,无法使用cocostudio完成整个ui系统的控制,界面的显示位置还是需要上层逻辑代码来控制。虽然不是非常麻烦,但是总归感觉是比较low的。当然,也可能是我没有掌握好对应技巧,欢迎批评指正。


3、Node:getChildByName是非递归的:

直接通过getChildByName是非递归的,无法直接通过一个rootNode来获取子控件。cocos2d-x v3.2提供了这样一个函数来解决这个问题:enumerateChildren。使用方法如下:

function util.ui.getControl(root,name)
    local control;
    root:enumerateChildren('//' .. name,function(ret)
        control = ret;
        return false;
    end);

    return control;
end
这个函数使用方式略显怪异,但是功能还是比较强大的,可以指定路径,也可以模糊查找,具体可以参考源代码中函数的注释


4、Panel默认是颜色填充的,而cocos2d-x v3.3版本貌似还是有bug,panel里面直接选择Fill为None,在实际游戏中依然会有填充色,必须要手动把Opacity的值设置为0才行。而CocoStudio和其自带的程序是没有这个问题的。


5、坐标设置可以是像素也可以是相对于父窗口的百分比

这个不算坑,估计原本他们也想用这套系统来替代锚点的布局系统。不过略显鸡肋,因为大多数对话框只需要配置好绝对的像素坐标就足够了,而当需要自动布局适应多分辨率的时候,这套百分比相对布局依然无法正常适配。也就是说正常的时候怎么都正常,不正常的时候怎么都不正常。


6、不提供打包功能了,导入资源的时候就需要打包好

这个也不算坑,本来统一化的打包就存在一些恶心的问题,比如背景图或一些比较大的图片不应该打包,但是也一并打包进来了。现在的方式更加自由。 我还没有尝试texture packer打包的兼容性,我猜想会存在这样的问题,我使用原始图片配置好的界面,当我换成plist后,所有的界面图片都要重新指定。 如果真是这样的话,也无法过于苛责,只不过显得不够人性化。


7、控件不够全,并且功能比较弱

比如三态Button,单选Button组,Tab标签等等功能都没有,而我想直接通过设置Button状态来控制其图片样式也做不到。

当然,这些并不是说真的做不到,只不过需要额外写一些代码来处理。相比起来NGUI和DF GUI乃至Unity新推出的uGUI都比它强多了。


8、导入图片资源比较混乱

导入的图片资源一开始会散列在编辑器资源窗口中(资源可能来自不同的文件夹),然后可以拖动资源到我们编辑器中创建好的目标文件夹。这个操作会移动实际的文件。而如果我们一开始就把资源放在目标文件夹中就麻烦了。 与其这样,还不如像eclipse一样,按F5直接刷新资源,更近一步就是像Unity一样,自动检测文件变化。

导入图片资源时无法直接把图片拖到目标文件夹,必须要两步操作。

删除资源会重置控件中的图片属性到默认值,如果一不留神删了资源文件夹就over了,所有的控件都要重新指定一下图片内容。


9、拖动控件,改变其父节点的时候,坐标没有重新计算,导致一旦改变控件的父节点,控件就不知道飞哪里去了,必须要重新调整坐标。 据说Flash也这样,但是至少Unity不是这样,而且Unity操作起来非常方便。


10、点选控件很让人恼火,如果控件的遮挡关系一复杂,就很容易让人点到错误的控件。 Unity的NGUI虽然有的时候也不是很方便,但感觉还是方便一点点,而且它的属性值是可以通过拖动操作来微调的,这个要比只能填数值要方便多了。


11、精灵对应的是cc.Sprite,图片对应的是ccui.ImageView。ImageView维护的是一个九宫格图片(如果不勾选这个选项,图片可以正常显示,但是使用的依然是这个类)。理论上cc.Sprite效率要高一些。但是由于Sprite不是Widget,不支持addTouchEventListener方法。所以想要处理点击的话,就必须使用图片控件,并且要设置setTouchEnabled为true。


12、偶尔会因为某些bug,导致csd文件被清空。所以最好建立个svn或者git仓库,时常保存一下。否则万一中招就悲剧了。


13、UI动画的使用方式:

self.buttonPanelAnimation = cc.CSLoader:createTimeline("GUI.csb"); 
self.buttonPanel:runAction(self.buttonPanelAnimation); 
self.buttonPanelAnimation:gotoFrameAndPlay(0,25,false);
传入的文件就是GUI文件,动画制作的关键帧信息是保存在一起的。所以如果有多段动画的话,要分开帧段单独制作。比如菜单的收缩和展开就需要分两段动画来制作,播放的时候通过帧来控制播放哪段动画

相关文章

    本文实践自 RayWenderlich、Ali Hafizji 的文章《...
Cocos-code-ide使用入门学习地点:杭州滨江邮箱:appdevzw@1...
第一次開始用手游引擎挺激动!!!进入正题。下载资源1:从C...
    Cocos2d-x是一款强大的基于OpenGLES的跨平台游戏开发...
1.  来源 QuickV3sample项目中的2048样例游戏,以及最近《...
   Cocos2d-x3.x已经支持使用CMake来进行构建了,这里尝试...