cocos2dx 3.5 移植 wp8.1 中文显示问题

移植到WP8.1上还是有一些小坑的:

比如中文. 索性换了中文ttf字体就可以了.  我分享一个是微软雅黑 1.8M 还凑活吧.

http://pan.baidu.com/s/1pJsUjEz

要想全还有个大的 21M   全就是日本字也可以显示.

然后用 LabelTTF 就可以.  参考这里 http://www.cocos2d-x.org/programmersguide/6/index.html#label

   auto ttflabel = Label::createWithTTF(“fonts/MicrosoftYaHeiGB.ttf” ,“48”);

    ttflabel->setString(“难得糊涂);

    ttflabel->setPosition(200,200);

    this->addChild(ttflabel);

而到了Wp8上还得注意. 貌似是路径问题.  还得用 FileUtils::sharedUtils->getFullPath 一下 字体路径.  包括声音播放 也是照此处理.

Read More

凡人开发游戏的未来

Unreal Engine 今年opensource了. Unity也有大动作, 提升了免费版本的功能. 少了很多束缚.  Cocos 也围绕3D做了很多工作. 至少做2.5D是没问题了.

于是, 软件开发的危机问题 又把球踢给了开发者. 画外音: 有这么好的引擎了, 你怎么不做个百万流水的天天放屁呢.

其实, 这个问题很简单, 世界上早就有了非常好的纸和笔, 但伟大的诗人以及作家们却屈指可数的.  不过要承认, 我们处于这么一个时间点上, 看似资源丰富.  尽管那却未必是适合我们的路.

那是引擎贩子们希望的路. 就是希望大家都集中于创作, 当作家就好了.  然后和他们分成。我觉得这种模式有很大的空间, 但却不是适合所有的人。比如: 程序型团队. 本来就是缺美术 缺策划的.  引擎没解决这些问题, 反而把问题变得复杂化了。因为, 很多人会有上面的想法,  门槛提高了, 玩家的期待也高了。

这种模式适合创作型团队, 美术强悍, 策划华丽, 程序也不差. 再加上引擎, 快速开发是很cool的. 再加上有大把钱推广.

而程序型团队的出路现在看是资源像素风格化, 关卡程序生成, 等等都是用程序来代替或辅助进行制作。只有将这些点发挥好, 才能有生存空间. 让产品有与众不同的点。如果能从技术上有所突破,  打造与众不同的视觉效果, 玩家的体验就会得到极大的提高, 而且有利于从那些基于引擎的同质化的产品中脱颖而出。 归根到底, 就是程序型团队的优势被人为的认为弱化了,  实际上, 从看到赚钱, 从demo到产品差距还是非常大的,   这就靠程序的捏合能力了。 程序依然是最后一道工序. 就像打包上线,加班, 永恒不变的主题。

如何让一款产品脱颖而出. 渠道是放大作用.还是得靠产品本身的品质. 只不过生物链的上游把控优势资源 选择最好的而已.  而开发团队还是要炼内功的. 好的原创美术到位的表现细节是加分, 数值平衡到玩家持续在线.老中青结合, 程序再有点绝活, 就赞了. 毕竟是驱动整体的核心一环.  真正做到自制, 自控才是最高境界.  只要产品过硬就可以有话语权. 买家市场还是卖家市场的区别还是很大的. 前期就是铺垫和各种前戏以及用牛人做背书.

凡人做游戏,未来不是梦. 是游泳. 很容易沉底。

叙事型游戏有没有呢?

其实尽管是万能的引擎, 也是要程序这个工种的. 只不过可以不用太深. 太深的让更专业的人来做, 更专业的其实也没多少人.   同理也是涉及到美术, 策划 这些工种.  引擎的作用也许只局限于可以快速做原型. 真的变成产品还得靠 资深的技术工种来加工 锻造,  除非是意会一下就得了。

通用引擎的作用在于可以让不同工种并行制作, 然后再自由发挥组合成产品. 过于理想化了.  再有一种思路就是一人全栈。从3D model 到程序 到策划 乃至后期推广接洽都一人包办。

IL2CPP  又见  Emiscripten (CPP通向WEBGL的必由之路啊)

这里就像看到很多引擎. 然后又都看到box2d, spine, bullet 一样的感觉, 还如同 看到各种  xxVM (LLVM HHVM)  引擎结构细分.核心引擎模块独立. 所以以后必然还会有很专的引擎模块出现. AI 什么的

live2D 也挺有意思.  Recast & Detour 被用在寻路系统上. 开源自然是首选.

开源社区化生存. 以此为基础可以创造很多。

很期待,未来有一天从blender 社区下载需要的model 直接放入我们写的代码里 变成了模块. 再出售给别人 组装成他们自己想要的产品.

参照学习: 对着一种正确的参照系统来学习.比如 在Unity里面摆放场景 镜头 然后在cocos里同样操作 进行验证. 有问题就能发现为什么了.

困惑的其实是来自于那些未知的部分.

去掉浮华看本质, 细分工是趋势. PU专门做粒子都可以成为一个专职. 这种需求是刚性的. 就如同设计人物, 当然是靠设计的. 从纯体力转向脑力。

回到程序,写代码最终还是个苦差. 一个人写, 很多人写. merge 各种review. 保持非扩散性伤害的代码纯洁性就变得很重要了.

(但好像这些和引擎啊 代码啥的没关系是吧)

画外音: 小二, 来二两BOSS ,带狂暴的那种.   客官 您要什么口味的, C++  C# JS 还是 Lua  Python  即便是 Haskell 也没问题.

Read More

How to create game ui which can adapt screen resolution automatic using CocosStudio and Cocos2dx 3.x part2/2

这是个前文的更新版本.

目前可以正常工作的版本组合. cocos 2.2.1  + cocos2dx 3.5 .

流程依然是 cocos studio 制作UI. 导出后 供 cocos2dx 使用.  自动读取csb文件  ,  我们要做的是绑点事件处理.

而自适应的事就不用担心了。

要点是   UIHelper::doLayout( your ui node )

另外一个变化是设置的方式变了.  不是再来选那个自适应分辨率的 checkbox 了. 改成了 图钉和 伸缩线.

 

简单的说, 就是那个方向的距离固定就是激活哪个方向的.  比如左上角的图标,  选中左和上激活.

整体Ui的构建仍然按老的思路.

1. 先来一个Panel 命名为 UIRoot 设置成居中 ( 4个固定图钉都选中 而且还点亮横竖的伸缩线 ) 这样这个Panel 会随着屏幕尺寸变化而自动拉伸.

( 如果不想用背景图, 就可以设置这个panel的背景颜色.  就有了一个适配不同分辨率的背景了.  )

2. 然后第二层仍然是那9个占位panel. 具体根据需要来建就可以.   注意一点: 这些占位panel不开启伸缩线.  我们选得是960*640作为设计分辨率. 就都够用了.

3.  第三层就是要显示的Ui元素了.  血条啊 头像啊  按钮啊 之类的.. 只要摆好 同时开启固定. 不开启伸缩线.

至此: 编辑器部分的工作就结束了.

 

尽管细节有些不同, 但大思路是没变的. 所以只要掌握了这个思想, 以后再怎么变, 也无所谓.

下面演示一下,  第二步.  代码部分.

加载UI文件. 添加处理事件的函数.  1. 按编辑器里的层次关系找到Ui组件.  Button, Text啊 Sprite Sprite3D 等.  都是  cocos2d::ui 这个 namespace下的类名.

很简单吧.  抱歉这么久才更新,  一切还是本着自己验证 再分享的原则. 得严谨一些 对吧.

虽然这些都是零零碎碎的, 也没什么技术含量, 但却是上线必须要做的. 在此分享, 也许能节省大家一些时间呢.  每半年一次 WWDC 就要开了, 注定还会有新的问题出现. 细节一直在变化. 即便琐碎 没有技术含量. 每次还是得花点时间才能理通.

其它的还有广告嵌入, 内购, social 啊什么的 时不时的就出点问题。大多是因为更新。

如果你有什么好的想法 欢迎骚扰.  如果像 Prime31 那种 貌似cocos 这块还没有.  不过有AnySDK .

 

Read More