some tips about package android build for unreal project from source code

"unreal engine 4 with kbengine together by cnsoft "

  • clean your disk.   because compile source code need almost 50G. install vs2015 need 30G .  balabala…    the best is use SSD  disk. speed up your work.
  • important step:   setup.bat  next:   install NVPack android toolkit.    , next  GenerateProjectFiles.cmd
  • build development + x64 for build Editor.   but not include android package tools.
  • build development + android , don’t worry the failed project.  i am confused by that, just continue pack your android package.
  • choose correct source code . normally is  the  tags with  -release  instead of  the  branch  release.  e.g:   4.10.4-RELEASE
  • if you don’t change the engine source , why not use the installed version?  compile will  cost your much time.

 

Read More

程序复盘-所有问题其实就两种

1 . 有文档的 和没文档的

细分一下, 有文档之后也会有看了也没啥用的. 因为实践起来各种坑. 逻辑缺失.  语焉不详的设计文档, 细节遗漏or 写完就过时了的文档. 以及反人类的文档组织形式 这都是阻碍程序开发的.

经不起推敲的设计文档. 各种数据无来源的. 自相矛盾的.  算法不明晰的.  规则算法临时成分太大的.

没文档的不见得是坏事, 程序自己做主. 自己设定功能和实现. 不过终归还是要对接才行

2. 有源码的和没源码的.

有源码的结果源码最核心的是个lib . 有源码的结果是一个几万行的class. 各种有趣 和 反人类.    有源码的然后就是少头文件. 千万不能clean

没源码的就加个更字.

与人方便 与己方便. 挖坑就得埋一个.

3. 可以替代的和不可替代的

你的工作部分被别人替代的可能性有多大 就决定了未来你的空间.

4. 耗时间的 和 不耗时间的.

写代码的时间多还是少。越多好吗?   越少好不好?

最合理的应该是开始多 越来越少.    如果一开始就代码少的话,   表明这块时间基本没办法压缩了.  性价比很低。

 

Read More

Amazon推出Lumberyard游戏引擎,主要特点是集成了AWS和Twitch 没有VR 夹带私货是常规路数.

据Amazon介绍,Lumberyard是一个免费(如“免费啤酒”)的游戏引擎和SDK,适合创建面向Windows、 Xbox One和PS4的3A游戏,很快将支持Mac、Linux、iOS和Android平台。

Lumberyard基于CryEngineAmazon于2015年获得授权),但已经经过了扩展,包含一个新的资源管道处理器和一个新的网络层;而Lumberyard总经理Eric Schenk表示,随着时间推移,它同CryEngine的差别会越来越大。

The Verge报道,Lumberyard是“一个非常强大的引擎”。它包含用于角色创建和动画制作的工具,其自带的网络层集成了联机控制服务和Audiokinetic声音引擎的一个免费版本。

Lumberyard主要的不同在于像其大力宣传的那样集成了AWS和Twitch,后者也是一个Amazon控制下的流媒体视频平台。集成Twitch将允许开发人员复制“Twitch Plays”(一个玩家通过聊天室发送命令玩视频游戏的社会试验)的体验。此外,Lumberyard-Twitch集成还提供了“JoinIn”功能,旨在让观看者和广播者可以一起加入流媒体广播游戏。至于AWS,Lumberyard包含了面向所有Amazon主要云服务的SDK,其中包括S3、EC2、DynamobDB、Lambda函数等。有趣的是,根据Lumberyard的服务术语,AWS是其唯一支持的云平台,而竞争对手(如Azure或谷歌)的产品则被排除在外,贴上了“可选Web服务”的标签。

Amazon提供Lumberyard的免费下载,包括全部源代码,但其许可协议明确禁止任何形式的再次分发。它可以运行在Windows 7或更高版本上,需要Microsoft Visual Studio 2013环境。

查看英文原文:Amazon Launches Lumberyard Game Engine, Featuring Integration with AWS and Twitch

传统游戏示例

海滨城市资产包

Amazon Lumberyard 引擎

 

Read More

一篇BLOG拯救了一个肾.iPhone6s可以有.

2015-12-15 at 10.27 AM

结果出来了. 今天登记了领奖信息.   活动内容在此:  http://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=400854909&idx=3&sn=78d2923d138bec24faff63c9a688d1fd&scene=0#wechat_redirect   也可以看看其它同学的评测,各个角度的.应用 网站 等等.

文中提到的BLOG就是前几天写的: 基于数据方舟构建高数据安全的游戏服务器. 感谢UCLOUD.感谢斌哥,彭,Sunny,Jessie.

特别感谢 @清醒疯子 给我推.

这么多年,可以送老婆一个像样的圣诞礼物了. 我的测试机也搞定了. 皆大欢喜.  那一刻,我们两个还是挺激动的.紧紧抱在一起.

周末的分享活动也收获不小.见到了卞安,沈大海 姜赫等大牛的真身. 回来时和姜老师一起坐地铁聊了很久, 差点坐过站.

我整理了视频放在这里, http://weibo.com/2976628362/D8nv3wN1i?from=page_1005052976628362_profile&wvr=6&mod=weibotime

做事当然还是要靠自己,但是不断看到希望会更有动力.  如果你看到这篇博客, 不妨来CVP找我吧.

细节我有空再来写一篇.

Read More

Windows10开发资源链接搜集. windows store 商店注册费用(开发者帐号注册费) 19$/公司99$

正好有朋友问到, 就整理一下吧.

微软商店开发者帐号注册费用以及续费的问题.

参考这里.

https://msdn.microsoft.com/en-us/library/windows/apps/jj863494.aspx

windows store 商店注册费用(开发者帐号注册费) 19$/公司99$   14年已经不再需要续费了.花一次就行了.

如果参加过一些比赛的活动.还可以免费得到开发者帐号. 比如以前的 Marmalade WP OFFER, 今年的 cocos wp offer .

所有平时注意下这些社区活动,参加一下还是有好处的.毕竟是针对程序的福利嘛.

声明应用需要的系统的功能特性.(类似于Android的 manifest)

https://msdn.microsoft.com/en-us/library/windows/apps/mt270968.aspx

关于打包Windows10 UWP的基础文档

https://msdn.microsoft.com/en-us/library/windows/apps/mt627715.aspx

太扯了.这一篇是在Mac上配置Windows10  而且还是用虚拟机…

https://msdn.microsoft.com/zh-cn/library/windows/apps/xaml/mt465736.aspx

iOS 开发人员 UWP 入门 别以为是可以开发IOS 其实是让会ios开发的来开发UWP.

https://msdn.microsoft.com/zh-cn/library/windows/apps/xaml/mt300781.aspx

Read More

分享思路: 基于数据方舟(UCLOUD)构建高数据安全的游戏服务器(KBE+cocos2dx)

本文将和大家分享游戏服务器的时光机的体验,感受黑魔法-来自UCLOUD的数据方舟. 游戏服务器还可以这么玩。

Let me show you  how to setup 100% living game server on UCLOUD with UdataArk , enjoy the black magic in cloud world.

序.

单机手游一片汪洋, 唯有(弱) 联网还有一线生机, 一提到联网游戏那就需要个服务器啊, 而对于很多小团队, 运维注定是个头疼的事,其中数据安全尤为重要。初期可以用一些轻量的云服务, 但有些游戏类型是无法逃避开发游戏服务器的问题,比如MMO FPS, 早晚也要开发自己的游戏服务器。所以一直在关注这个服务器领域, 探索如何更合理的利用现有的资源解决实际的需求, 以便能突破现有的瓶颈 作出好的游戏产品。分身乏术啊.

11.23日有幸拿到了 UCLOUD 提供的数据方舟的内测邀请 连接。正好结合自己的需求点来跑跑看, 看看这个东东能解决实际开发中的什么需求.

正文.

2015-11-25 at 4.12 AM

 数据方舟是什么呢?  数据方舟简单说就是提供了对服务器的数据进行热备份的机制,而且是以秒为单位的,自动提供没有任何额外的开销和操作。很强大啊, 下面就来展示一下我搭建的细节.

一、首先是搭配服务器配置以及开启数据方舟功能. 如图.

ucloud_datatest_1

 基本和常规的云服务差不多. 选配置,支付就好了.

小提示:  付费方式总体上还算是很灵活的, 支持按月,按年(可以省2个月的钱), 按需( 按实际使用付费, 如果被ddos了 流量费也很肉疼吧 )

注意上面的图: 开启数据方舟是在最后确认之前那个界面选点击开启的checkbox。

二、开始测试.

开始之前还是想罗嗦几句, 游戏服务器的数据有多重要, 估计会出乎你的意料.

一般人都习惯了重装操作系统, 觉得系统慢了就ghost一下, 反正也没什么重要数据. 最多会有个意识 备份一下自己的文档数据什么的. 而游戏数据则是一个游戏产品的重中之重, 游戏玩家的数据是玩家最看重的, “辛辛苦苦几十年, 一夜回到解放前”  想必大家作为wow的玩家也是深有体会的. “卡卡更健康”  好容易刷个副本, 该拾取装备了, 服务器掉线了.. , 坑爹的是还有了副本进度.  要么就是被回档了, 熬了几个CD攒了很久的DKP 终于拼了好人品ROLL 到心仪的装备, 结果被回档了.  对于玩家的心灵的伤害, 感同身受啊.

而服务器宕机 停机维护, 无论主动还是被动的都需要有备份数据做保证。通常运维的同学会做好mysql数据备份 定时备份. 实际操作起来还是比较费时费力的。一不小心 drop database的有没有. 提起来都是眼泪啊。以下情况会需要备份的数据。

  1. 作为回档时使用。有多接近的有效数据就意味着可以最小化玩家的损失, 最大化玩家的满意度。
  2. 服务器升级时,需要有效的备份数据 防止升级失败, 数据错误等问题。
  3. 比对玩家异常行为也需要持续的备份数据.
  4. 快速开服,热切换服务器什么的也都需要。

1. 准备工作:先配置一下KBE的服务器环境. 了解KBE是什么点这里.  这里配置不是重点. 有空我单独写一篇

客户端就用我做的基于kbengine-cocos2dx 的一个小demo. 如图.

2015-11-26 at 12.09 AM

 

2. 安装好之后, 可以浏览查看到控制面板的备份数据,

第一行是当天的秒级别的备份数据.

后面是每天按小时的增量 以及前两日的一天的全量数据.

最下面有两个我手动备份数据. 可见数据方舟还是很强大的, 增量 全量 这些全都支持了.  我并没有配置mysql的备份机制.

ucloud_backupview_1

 

实战到了:  我开着服务器跑了3天来截取数据.  并进行了以下的测试. (视频为证)

1. 模拟宕机回档.

开服务器, 然后用客户端来连接, 创建新帐号. 此时立刻停掉服务器. 然后再尝试开机恢复到之前的时间点. 操作起来,发现时间点不好选择. 恢复之后, 刚才新建的帐号还在.  再重新恢复一次,  开机后, 帐号数据这回没有了.  真是太高级了。

03:17:33进行如下操作: 客户端登录后创建帐号, 手备份一次数据, 关机.

使用秒恢复功能,恢复到 03:16:33 的数据, 帐号数据还在 不符合要求.(目标是回档)

继续回退 03:15:33 进行恢复数据, 这回OK了, 回档成功。看视频前半部分.

注: 这里我第一次选择了1分钟为单位测试,实际上还可以更精准. 第二天我又补测了一次. 感兴趣的可以看一下:  补刀 数据方舟回档测试视频 1秒和10秒之间的故事 这里.    1秒之前帐号没了,10秒之后帐号又回来了. 


2015-11-26 at 12.12 AM2015-11-26 at 12.14 AM 2015-11-26 at 12.15 AM2015-11-26 at 12.15 2 AM

2. 破坏性操作,

模拟服务器被黑. 删掉游戏服务器的mysql数据库.   然后选择操作之前的时间点来恢复.  数据又回来了…

再直接格式化掉服务器. 开不了机了?  一样好使…

2015-11-26 at 12.16 AM

 

2015-11-26 at 12.18 AM

3. 模拟压力测试后清理数据 恢复纯净数据. 同样也能很轻松就能恢复到安装后的初始状态, 这样真的很方便做删档测试。只需要点几下鼠标,大概10分钟左右就恢复了。

最后上个视频. 看到更清晰一些.

不得不说,数据方舟真是太赞了,可以节省我们很多时间。

人和动物最大的区别是什么? 就是(思考)使用(制造)工具。就像数据方舟这种为解决实际问题而生,极大的提高了工作效率。save time, save young. 我们是时候考虑更合理的运用这些现有的轮子解决我们的实际问题了, 不应该再苦B的加来加去的加不完的班。

其实是有个小段子的, 曾经有一次做封测, 新来的运维就那么一下子把数据库给咔嚓了, 结果数据只能恢复到上周的备份, 一大群玩家数据回档啊….测试数据也没了, 让很嚣张的运营团队低调了好一阵子。如果当初有数据方舟这么厉害的工具, 也就很轻松的恢复数据了.

不是每个人都擅长服务器的运维工作,对于小团队开发者, 时间变得更加昂贵, 所以如果有合适的方案解决问题, 换来更多的时间专心搞好游戏产品本身, 是最好不过的了。做自己擅长的事才能让自己创造的价值最大化, 而未来一定会呈现这种格局, 更加精细的专业化分工和协作。

强大归强大, 还是要再吐槽一下, 期望UCLOUD能再接再厉 让数据方舟(们 ,游戏服务器一揽子方案有没有? ) 更强大.  

1. 正确的时间的选择真是头疼…

        不像Mac的 TimeMachine 可以有浏览方式, 可以根据查看哪些文件修改来决定进行数据恢复. 停机恢复开机验证 不对再关 再开 也挺费时间的是吧。如果各位有好的方法还请告知. 

2. 数据恢复必须要关机..

一关机服务器的现场环境就破坏了.  如果像VMware那种可以建快照就好了. 直接可以启动恢复成一模一样的现场。期待啊. 这样可以很方便的排查一些棘手的BUG. 反复的测试和验证 而又不会破坏测试环境.

3. 不会停止的数据方舟.

如果可以手动暂停就好了, 可以保留足够的历史数据, 不用担心折腾完发现需要使用的历史数据已经没有了(方舟保存的备份记录是有限的 如果一直开着 老数据会不断被丢弃).

4. 更复杂的场景期待解决方案,

尽管大部分情况下, 只要恢复最近的数据既可以了.  但是游戏数据比较复杂, 比如玩家充值, 然后购买消费了 需要对账何时.  有未落地的临时数据等等.   还不光是备份能解决的问题,有时是发现了游戏数据错误, 需要回滚部分数据 而不是全部.  所以除了使用这种云技术, 还得考虑合理的数据处理的机制。

最后,  如果觉得还算有点收获,就给俺点个赞啥的. 顺便有没有搞游戏的或者对开源项目感兴趣以及想学KBE的 cocos unity  unreal的 来CVP找我, 一起搞啊。 如果对UCLOUD感兴趣了, 可以注册个帐号试用一下, 这有个代金券兑换码送上 ( 1e55bfcc5aa78a 100元.适合开发App或游戏产品的小团队以及个人) 

本文出自 “小糊涂的超级BLOG” 博客,请务必保留此出处 http://www.chenlong.me/?p=1584460

延展阅读:

补刀回档测试: 1秒和10秒的故事.

UCLOUD 数据方舟官网.   文档地址

KBEngine-cocos2dx 项目地址1 . demo地址2

CVP是什么:  http://cvp.cocos.com/

cocos引擎. http://www.cocos.com/

Read More

CVP接单有感:一定要和有理想的人谈理想和靠谱的人做靠谱的事.

前序:

和有理想的人谈理想, 会认为那是理想。同样的话说出来, 即便你再真诚, 也会有人觉得空洞. 觉得空高大. 因为不真诚的人也可以这么说. 但是时间久了.就能区分了. 因为还要做事的。如何避免重复造轮子,如何扬长避短, 如何协作,  程序员这个群体不能一味的善良的做资本的炮灰, 陪着烧钱烧脑细胞, 加班是万能的法宝吗? 如果可以有一种方式, 技术,时间,金钱互换,然后节省更多时间做擅长的事, 应该是最低碳环保的。

简单说一下这次接到CVP任务的感受.

这次接到这个任务也是机缘巧合, 也算是天时地利人和了。先是和cocos有缘. 因为一直以来, 去浏览 cocoachina 论坛已经是我生活的一个习惯了.  也许还有人记得 2008年时我曾经做过ccgamebox的项目模版. 当时其实是准备做IOS游戏的了. 不过后来转去搞3D MMO RPG了. 2012年开始关注点再次回到移动平台.

10-15号那天刚好看到CVP的任务在论坛发布,  我打趣的回了贴,  包食宿不, 没想到负责CVP的cocopeng同学很热情的和我交流.  很敬业的说. 其实当时还没决定要做。

处于好奇就多看了一下, 结果就发现个有趣的点,我一直都是比较喜欢捕捉这种新的技术点,觉得很好玩。微软正在做UWP的整合和过渡. 而cocos2dx引擎v3.5开始出现universal的模版工程了. 但是显然从某个版本干掉了老的 XAML C#结构的工程模版. 于是目前就出现了一个空档期. 就是新的基于UWP的架构的内购支持并没有人实现,至少没有人公开过. 搜索一下千篇一律都是老的结构模式.  所以我就打消了原本有些狐疑, 看来这的确是个技术问题, 估计谁要做都得折腾一下了.  看要求也只是说支持WP8就行了, B计划就是用XAML C#的那套方式吧。

不过内心里没有放弃过使用C++的方式来实现.  毕竟UWP是大势所趋. 用C++写岂不是很舒服. 也不用去看C#那些劳什子. 然后我做了个决定, 就是先做一下技术测试. 看看模拟器上是否可行.  然后就是各种问题. 都是细节, 有时间我会整理出来。一开始也没有什么头绪. 能解决也有点偶然。不过很多看似偶然也是必然的吧.  如果我也和其他人一样略做尝试一下就放弃了,也就没有这次接单了, 我想该坚持一下的时候,人还是得坚持一下。 而且还有个意外的收获, 就是同时还解决了Win10版本的商店接入问题。毕竟API接口都很相近,流程又一样。但如果只是偷懒去弄那个老的 XAML C#的话, 也就只能凑活着完成这次的任务了。

另外刚好4月份因为微软比赛的事, 已经配置好了开发环境. 所以这次就很顺手, 直接开始了. 之前安装环境其实还有些折腾.有点小坑的. 文档 开发环境  cocos引擎.  一切都是准备就绪的.这也节省了时间.很快我就可以开始动手了。

先从文档开始. 了解. 跑一下SDK的例子. 然后跑模拟器. 然后整理了一下流程图.  开始动手用3.5版本的引擎配置环境.  看文档之后.写了个最简化的版本的WPStore Helper  并很快可以run了. 当然直接就崩溃了.  这是第一个点. 估计很多人都卡在这里了.  我理解起来就是信息的不对称. 因为用cocos引擎的同学大多不太关心平台相关的部分. 而这部分cocos做的比较好可以无缝升级. 所以对于Windows平台很多同学并不是很熟悉.  而因为开发时间要求的比较紧张, 可能就有了这次任务发布。

另外选择可信的项目合作方是外包项目常见的问题,搞不好就会陷到项目里。这次任务从前到后都有专人负责接洽 负责督促 协助解决所需的 软硬件资源, 环环相扣, 如果不是各位同学专业的合作精神, 也不会这么顺利。这次任务基于 cocos 引擎可以把需求很好的独立出来, 可见未来基于 cocos 引擎 进行远程Remote协作也是可行的。

 

 

这个任务中遇到了那些技术难题, 是如何解决的?

技术难题我觉得其实就是一个. 如何在 cocos 里面调用系统的内购接口,而又不会导致系统崩溃。直接调用会崩溃是一个错误代码.   参考这个: https://social.msdn.microsoft.com/Forums/windowsapps/en-US/6efb19e6-579d-4bb4-9e7b-d7e394f1ae45/crash-when-inovde-currentapprequestproductpurchaseasync?forum=wpdevelop  大致就是不要在后台线程里面调用UI的操作请求. 解决办法就是找到UI线程. 然后把请求转移到这个线程. 原理是一样的。 解决方法参考这里: http://social.msdn.microsoft.com/Forums/en/winappswithnativecode/thread/e36f84be-db95-4764-951e-bfa662cdd11d

还有个点 :就像做手术要微创一样, 要选择一个最合适的地方嵌入代码. 我的思路就是做成模块, 只提供接口和捕鱼代码交互。尽量少的改动上层代码, 而集中于平台相关的底层部分,这样不会带来破坏性 引入bug。

其它的就是常规的内购流程实现和调试了. 这个基本按文档来就行了. 这里的难点不是技术上的, 而是环节比较多, 而且微软商店刚刚合并过一次. 实践起来细节有一些变化,多实验几次就好了。同时也得合理的设计一下代码结构,能在模拟和真机购买之间切换。

能和大家分享的其实就是善用搜索和梯子.

WP8支付的SDK怎么样, 有哪些坑是需要和大家分享的. 

文档过时: 现在这个时间点上.很多文档都是旧架构的. 没有UWP方式的. 而cocos2dx 3.5是最后一个支持 C# XAML架构的WP8工程的版本. 之后就被UWP替换掉了。目前可以搜索到的大部分信息都是这个老架构的。而我的目标是UWP架构,参考资料就少了很多. B计划是沿用 C# XAML的工程模版. 可见这个技术点其实很有市场的, 很多用cocos引擎的同学并不擅长做这些平台相关的工作。

异常崩溃问题的干扰: 因为代码会有崩溃问题. 只是需要处理异常捕获就可以了, 而不是彻底消除掉. 一开始也很困扰我, 后来确认并不会导致闪退之类的问题. 系统会抛出Platform::ComException^.  加上官方例子是 createtask 一层套一层… 头大啊。不像C#版本那样写的好看. 大家可以对比一下.

C++版本.

create_task(CURRENT_APP::LoadListingInformationAsync()).then([this](task<ListingInformation^> currentTask)
{
try{
auto listing = currentTask.get();

auto licenseInfo = CURRENT_APP::LicenseInformation;
//TODO: notify cocos after list products.
#ifdef _DEBUG
int count = listing->ProductListings->Size;
cocos2d::log(“total %d products”, count);
if (listing->ProductListings->HasKey(“goldcoin”))
{
cocos2d::log(“find product1”);
}
#endif
//clear cache first.
m_cacheProducts.clear();

for (auto pair : listing->ProductListings)
{
// do stuff
auto key = pair->Key;
cocos2d::log(“product key %s”,pstos( key).c_str() );// ProductListing(pair->Value).Name);
//Name,Price,Description
addStoreProduct(pair->Value);

}

}
catch (Platform::Exception ^exception){}

});
///////////////end core function.

 

C#版本.

private async void btnStoreLoad(object sender, System.Windows.Input.GestureEventArgs e)
        {
            try
            {
                var ProdList = await CurrentApp.LoadListingInformationAsync();
                lbProductsList.Items.Clear();
                string t = "";

                foreach (var item in ProdList.ProductListings)
                {
.......
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show("Error: " + ex.Message);
            }
        }

 

测试设备解锁:  8.0版本的设备已经不能解锁成测试开发机了.  解锁时会有一些问题, 比如时间设置什么的. 另外屏幕锁定真是很烦人, 一不小心就会导致部署失败,习惯了就好了。 一般人看到红色错误就很紧张的。

注册第二个设备的问题. 需要改一下名字. 就是把资源管理器里面识别的 Windows Phone 改个名字就行了. 不然会提示错误.

真机购买提示商店状态不可用: 就是真机上不能真购买. 只能模拟测试购买. 直到提交审核上线以后 才可以. 无论是下载的,还是调试方式部署到真机的。

会遇到开发者账号登陆异常提示:  每次打包时不时的就会让你登陆一下开发者的账号。还有可能会弹出安全异常验证。 然后要绑定的手机号或者邮件接收验证码.  建议千万不要做这个联系人, 不然会半夜有人给你打电话要验证码的.

在这里任务中 C++和C#是如何互调的. 哪些经验是可以分享的. 

这次任务其实我并没有用常规的那种XAML C#  呼叫 C++ Runtime Component的架构 , 我选择的技术方案是基于流行的 UWP的项目结构. 是纯 C++的方式. 调用C++版本的Windows Store的接口。

能解决这个问题是基于 A+B+C的的拆解思路.

首先:  我对cocos2dx引擎一只保持关注, 所以清楚每一次版本变更的大部分细节, 进而会有一些结论和判断. 我想每个人做事都是有自己的选择, 而选择的前提就是基于自己的视角作出的判断. 比如上面提到的砍掉C#方式的工程模版, 我的结论是UWP会大行其道。那么IAP内购这事肯定UWP也是支持的.

然后我就去查了一下C++的IAP接口. 发现只有 Windows 的.  前面说是 加法模式起效果了,  UWP这个概念其实就是Windows所有平台一套代码. B就是UWP的概念告诉我们 Windows Phone 也是支持的.  当然了支持到什么程度还是有些差别的。

最后一点就是C了. 需要抛开cocos2dx来看这个需求. 然后再去寻找相关的资源. 哪怕是一句话, 就会引导我们沿着正确的方向前进了。 大部分文档都忽略了一些细节, 也就导致短时间想读懂读通比较困难。我刚好有些积累. 找到官方的一个例子是给DirectX Game添加内购的.

这是准备工作阶段了, 理论上没问题了, 就确保方案可行了。

简单的说 就是没有现成的白面包,但是会有面和烤箱之类的. 能让你得到一个白面包。很多问题都是可以通过拆解成一些小的点得到解决的。

是否愿意把这次的任务编成WP支付教程.并分享到CVP平台上.

大家都知道cocos2dx引擎是开源的, 所有我就有了一个测试沙盒, 可以和捕鱼达人一样的运行基础. 我只要在HelloCpp里面跑通了, 那么捕鱼达人项目一样也可以实现。如果不是这样的话, 就很难有这么轻松了。所以首先得感谢cocos引擎提供这样的协作方式。我其实一直有写BLOG的习惯. 也愿意和大家分享一些心得体会. 苦于知音难觅. 我尽快整理一下细节, 写成WP支付接入教程, . 甚至整理好开放源代码 加到 Cocos PluginX 里面. 现在代码还是比较暴力了一点。

支付教程整理打赏模式?

如果有人打赏当然更开心了。

谈谈对于CVP这种平台的看法和期望.

因为有cocos引擎,才使得这种解决问题的方式变得可行. 我可以先测试, 然后再一起合并代码. 延伸开来,岂不是会将很多事情变成可能, 我甚至能想象如果有一天我们每个产品都变得非常的模块化,  远程协作 以及基于模块级别的代码复用 进而可以极大提高生产效率,还能解决技术短板. 希望CVP平台能够完成这个使命, 实现双赢的未来。也许不久的将来, 不再有公司, 不再有无谓的加班, 我们只要做好自己擅长的部分, 集中在想法和创意环节。 时间是最宝贵的成本. 一个人能有几个10年呢。

开源的魅力不仅于此, 如果功能欠缺, 就可以自己动手添加, 调试等各方面的难度都会降低很多.  反观如果是Unity那种引擎, 是通过il2cpp转换的, 时不时的真机就会黑屏, 崩溃掉. 很是捉急。项目开发的时间和规模越久 出问题的几率越高. 如果刚好赶到上线阶段, 不光是要加班不可避免, 还要面临一些不确定性。时间紧任务急啊. 长此以往把程序员兄弟们的身体都搞坏了。而且明知道有一些bug,也没有办法自己修复.  Unity做个编辑工具应该很好用,负责美术资源的制作, 然后cocos作为Runtime. 是我心目中的理想组合。

CVP这个平台太好了, 希望能认识更多的朋友, 一起加速跑, 告别单枪匹马, 开启集体围猎模式。

我还得啰嗦几句, 就是开发人员得注意平时的积累, 多与人交流。一句话可能就会节省很多脑细胞, 希望大家都能来加入CVP这个平台, 做自己的主人。如果有技术问题欢迎交流。

 

Read More

It is time to use Flatbuffers in some case.

Sure, with time past, more and more new stuff coming.

maybe you haven’t  try google protobuffer, Flatbuffers coming.  it is named better than protobuffer. no need serialize and un serialize,  the reason maybe is :  it is binary .

  • msgpack: has very minimal forwards/backwards compatability support when used with the typed C++ interface. Also lacks VS2010 support.
  • Thrift: very similar to Protocol Buffers, but appears to be less efficient, and have more dependencies.
  • YAML: a superset of JSON and otherwise very similar. Used by e.g. Unity.
  • C# comes with built-in serialization functionality, as used by Unity also. Being tied to the language, and having no automatic versioning support limits its applicability.
  • Project Anarchy (the free mobile engine by Havok) comes with a serialization system, that however does no automatic versioning (have to code around new fields manually), is very much tied to the rest of the engine, and works without a schema to generate code (tied to your C++ class definition).

check more info here : http://google.github.io/flatbuffers/md__benchmarks.html

 

Read More