1、自己组技术团队自己开发,需要的人员有产品经理、框架工程师、JAVA、PHP、前端、后端、测试工程师,开发周期在1-2个月。人员成本5-8万,后期维护成本没算。(不推荐)
2、购买别人的小程序源码,用自己的服务器,找个技术人员专职维护。源码费用一般8000-10000,服务器一年3000,维护成本每月6000。(不推荐)
3、使用第三方小程序,购买第三方小程序使用账号,每年约1600元,不用担心技术维护、不用建服务器,拿过来就可以使用,还可以根据自己的搭建要求设计店铺和绑定公众号。
减少客户端对Cocos2d-x引擎的依赖程度和降低耦合度,将引擎必要的初始化、逻辑更新、渲染、资源管理等交给底层处理,是客户端逻辑开发不需要过于依赖引擎层,同时,为了避免客户端代码中频繁、直接的调用平台相关诸多功能,我们将平台相关的功能封装在引擎封装模块内。这部分我们可以叫做BaseCore部分。
*Cocos2d-xAPI的封装整合,绑定到Lua。关掉3D模块,另外不再使用扩展库。
*必要的时候,可以将脚本层换成js绑定,然后将逻辑代码修改成Lua的,就可以支持H5了
*UI的一些基类,例如弹出框可以将如下属性封装成一个Dialog对象,派新类自然拥有这些属性了。可设置大小并且带有关闭按钮的一个基本视图,另外子类不再需要去设置dismiss了。
*还有类似于Toast的创建,以及一些基本控件完全可以架构一个工厂对象,从而省略很多的基本控件的构造代码。当然也可以在Lua中通过配置文件来配置基本UI。
*健全的纹理管理规则及清理规则,纹理缓存在场景切换后不会移除。可以考虑逐帧加载,将纹理分级,公共资源可以不remove,先删除可能不再使用的帧动画资源等。
*特别设计有限状态机管理纹理内存,动态控制空间。以及利用状态机的事件特性来控制动态跳转。
*Socket采用TCP/IP协议,封装伯克利套接字接口,设计接受和发送队列,通过互斥信号锁来处理队列共享问题。因为join函数调用的地方会阻塞主线程,我们可以考虑用detach方式,完全是交给系统处理,另外可以考虑第三个线程来开辟世界聊天或活动的这种比较频繁的协议(视情况),并且将协议解析及Lua的table序列化放在C++层。暴露基本接口给Lua脚本层,在脚本层处理网络心跳、断网重连相关的逻辑。顺便我们要支持IPv6的处理,这里只需要将地址解析、Socket初始化函数做兼容。接受子线程跟UI线d-x提供的事件来处理,然后C++将这个数据POP到Lua层,Lua这边根据协议头回调函数,或者是通过事件的方式派发到具体的业务。
*对于一些通用的协议,Lua层设计成抢占方式,或者是添加一个tag来标记目前这条协议是处于模块。
*设计模式上考虑使用生产-消费模式,尽量让协议的读写跟业务内容解耦。协议层的封拆包全部用python脚本生成的lua文件自动化处理,发送跟接受都是接受一个table,省去客户端的部分工作。
*Http,我们可以封装,上传下载,以及我们日志上传相关的模块等。如果使用3.11以下版本,需要替换libcurl,针对苹果IPv6问题。
*模块下载,大厅可以选择部分模块进行热更,下载完后,即可重新启动虚拟机,或resetPackage。达到真正热更意义。
通常我们会在游戏中会出现一些小Bug或者需要更换部分图片素材,或者部分配置文件。来适应运营策略的部分小版本更新。
大厅合集中,下载相应的模块,然后再点击就可以玩相应的模块了。技术设计上,可以将资源热更下来,即刻resetLua的Package。或者将下载的模块添加到搜索路径。
1、trunk维护一个BaseCore版本,有改动,其它所有包体都要考虑更新版本。作为一个大版本处理。后期项目多了,有改动可必须拉分支进行修改,然后同步到trunk。
2、业务模块在BaseCore没有改动的情况下,完全可以不用更新程序包,直接热更新即可。作为一个小版本。小版本可以在一个新迭代后拉一个脚本Tag版本。
*可以区分平台自动匹配资源名称,如android自动将后缀改成.ogg。iOS改成mp3等
考虑到框架总体的拓展性,我们完全使用事件驱动模型(Event-driven)来设计和开发,将客户端中事件的触发时机和具体处理逻辑彻底分隔开。游戏的各个模块,仅需要注册、监听和实现其关心的消息事件,而无须关心事件何时被触发,降低了总体耦合度。游戏中所有UI面板的隐藏/显示、事件响应、音效的播放/停止、游戏流程的切换、游戏角色状态迁移等,完全通过事件驱动方式开发;同时这种基于事件的处理方式,为项目使用动态脚本拓展提供了支持:脚本层省去对逻辑代码的大量直接调用,通过消息事件完成脚本层和逻辑层的交互调度,大大简化了开发的复杂度。
*提供简单的测试脚本支持。如重复进行某一个操作,所以每一个核心业务都需要预留测试接口,然后结合我们的行为日志,充分利用休息的时间,让其自动测试。
*Oriented日志。主要用来追踪用户操作行为,方便测试路径重现,只用在测试阶段。
*脚本Crash后台,脚本测试比较难以Debug,将xpcall捕捉到的日志提交后台,目前情况是有一个简单的JavaWeb日志追踪页面。所以只是作为内测用。
开发过程中,从严控制纹理,按照相应的Block合并大图,适当情况下,可以降低清晰度。另外场景管理包含资源的管理,例如某个动画在特定的场景中出现,我们可以直接将着部分资源在缓存中移除。
如果对包体要求更严格,可以适当考虑将图片压缩成pvr格式(一种显卡可以直接识别的格式,目前市面上的刀塔传奇采用的这种方案),但是这种情况是没有alpha通道的,也就是说透明度设置有问题,只能是作为一种备用方案。
2、将一些耗时的操作放在C++层,如读取配置文件,异步加载音频文件等等。
分两部分,第一部分是底层代码,健壮、高效,并且是讨论过、并切实可行。第二部分脚本代码需要从代码风格上进行管理上的强制要求。
客户端代码除了底层代码用C++以外,其它基本使用Lua脚本来开,所以脚本需要加密。以防止二次打包及非法行为。目前可以使用Cocos2d-x提供的xxtea加密策略。
是一个最小资源包,只有一个登录到大厅的UI展示。可以不包括逻辑业务部分,然后再去热更新部想要玩的部分,一些公用部分完全可以设计放在这个版本内部。大体包括如下内容:
最理想化是可以如下操作,出某版本,后期想给这个版本加某个游戏,可以通过热更新的方式去更新。
通过事件方式来注册游戏,通过配置来定好游戏中包含哪些模块,进行事件注册,然后再大厅打开模块后发送相应的事件去打开模块。
综合选择Cocos2d-x3.11.1版本,更新了ipv6及openssl等相关内容。BaseCore版本我们用C++完成基本功能(暂时命名为theway),然后具体业务项目将theway引用作为依赖,并且业务开发使用Lua脚本开发。这样将底层跟业务解耦。另外为整合多个游戏带来最基本的技术上的支持。
可以做成依赖项目,作为其他项目的底层,随着项目不断优化和集成可以衍生成一个拥有我们自己知识产权的引擎项目。这样底层修改或升级,只需要做兼容即可,大不必让业务开发受限。同时可以整合各项目的开发资源,提高开发效率,产品质量。
作为商业开发,开发工具的完善也是一项必不可少的环节,目的是为了提高产品开发的效率。例如我们利用工具提高开发效率的一个实际例子。用Python生成协议Bean来直接序列化消息内容,通过委托模式,业务模块只需要关注发送,返回协议回调函数收到一个Table,十分的方便好用。后面可以将一些重复工作用工具去做。返回搜狐,查看更多