IT新手入门,零基础学IT,转行做IT,IT行业的职位选择,你我一同探讨!

IT新手入门网给你介绍IT行业的职位有哪些,让你转行做IT不发愁,IT入门有捷径

当前位置: 主页 > 技能提升 > Unity3D开发 > unity项目开发过程(第一天)

unity项目开发过程(第一天)

时间:2017-01-06 11:45来源:互联网 作者:未知 点击:
网络层:短链接+长连接 两者的数据同步可以考虑通过数据库层来处理,短连接处理业务逻辑,长连接处理数据同步以及一些后台逻辑。当然只使用短连接的情况下,可以制定一种动态

  网络层:短链接+长连接

  两者的数据同步可以考虑通过数据库层来处理,短连接处理业务逻辑,长连接处理数据同步以及一些后台逻辑。当然只使用短连接的情况下,可以制定一种动态数据的携带机制,满足随时在任何协议中携带常用的各类数据,保证数据的一致,再者建议前端尽可能少的修改自己来源于服务器的缓存数据,宁愿多定义一些中间变量,多做一些逻辑。

  服务器和客户端统一数据结构:

  通过策划定义的excel表,一键导出java c# proto文件,通过在excel表中添加标注来确定哪些参数是公用数据(传输),哪些是客户端专用哪些是服务器专用

  另外:客户端一定要尽量少的做比较重要逻辑的条件判断,尽量少的使用公式计算,如果可能的话,直接由策划提供对应公式计算后的数值,或者数据尽可能的由后端传过来。 再者不同协议尽可能使用公用的结构体,这样可以减少对缓存数据操作的地方,也就可以减少出错的地方。

  还有一点,要多做异常错误码的处理,可以在这里进行一些前端与后端数据的同步工作。

  尽量使用静态表的方式来获取各类数据,因为策划会在线上服进行一定程度的数值调整,千万不要写死在程序里面,当前我们进击的魔王走的是静态表,同时支持静态表的动态更新,这样可以满足策划对数据表的随时修改,可以将静态表都拆分成个体单独处理,每个表都有自己的版本号,减少下载量。由一个总的信息记录文件来控制(这个文件每次必须从服务器获取最新),记录当前版本,下载地址等等,当然如果整体大小很小的话,那么也可以合并成一个文件,减少更新请求次数。

  资源处理:打包成bundle是必须的,考虑是否将界面资源也打包,或者生成为场景资源,打包公用资源,打包单体界面资源,按照顺序下载资源,处理资源 (这一条根据需求,如果逻辑合理的话可以减少资源量,不过会加重逻辑工作量),同时如果使用Bundle的话一定得保证文件名的唯一性,因为WWW是使用文件名来进行区分下载的。合理拆分AssetBundle。 资源分类:场景、角色、界面、静态表、动画、特效、其他

  //文件名, 版本号(修改时间), 文件尺寸 md5(crc32) 下载地址(BaseURL+Platform+Resource)

  使用WWW.LoadFromCacheOrDownload的方法,下载完的数据将在unity3d的本地缓存目录中进行保存。Web浏览器通常允许缓存大小达到50MB,PC和MAC的本地应用,IOS和Android应用都允许缓存达到4GB大小

  在Unity4.3.3中可以使用CRC32进行文件正确性校验,CRC32为32bit的简单hash,MD5为128bit较复杂的hash算法,根据网上的资料,虽然CRC32在某些情况不是一定比MD5快,但是有Unity3D内置的接口,同时如果我们使用MD5会增加自己的工作量,那么还是建议使用CRC的校验方式。

  另外现在可以不用再考虑使用WWW.Dispose来清空进程,释放资源了,一是这东西不保险,可能会造成崩溃(在下载完成之后调用没问题,在下载中频繁调用可能会出现异常),二是Unity自己会在合适的时机清空加载进程。

  保持良好的编码:

  项目开发中一定要保证委托使用的一致性(Observer pattern),一定不要某些模块使用,另外的模块又不使用,造成代码比较散乱。 其次坚持统一的本地化语言开发机制,对于界面布局的问题在代码中尽量不要使用写死的数值来调整位置,不要因为前期偷懒造成后期修改成本的增加,毕竟在前期开发中对个人负责的功能更加清晰。

  优化托管的堆内存:尽可能早的时间将不需要的引用去除掉,置为null,这样回收机制才能正确地及时的把不需要的内存清理出来(理论上)

  优化Unity内存:避免程序内存峰值,在加载两个大场景时,中间最好穿插一个很小的场景,这样在场景切换过程中不再使用的资源将会被适当释放一部分,二是要注意脚本中对一些资源Prefab、GameObject等引用,如果一些不会被删除的脚本包含了对大量资源的引用,那么这部分资源将不会被释放。

  统一计时功能,根据需求分发到使用者,C#的话最好使用Ticks来计时,比较精确一点,不管使用Ticks或者second,一定要保证各处使用单位一致,同时保证使用Unity的Time. realtimeSinceStartup来记录程序中与真实时间挂钩的变量,而不是使用Time.deltaTime

  协议码的处理:建议使用C#的反射机制来处理,抛弃switch的编写,利用C#的partial功能将文件按模块或者功能分离代码文件。

  3D美术效果:比较合理的美术规范,适用于自身项目,适用于移动端的shader

  界面布局:坚持九宫格的布局,界面统一动画的处理,在九宫格的几个节点挂上相应的动画脚本,在Enable和Disable的时候执行正反动画,觉得我们项目对动画部分的设计还是很不错的,效果也比较统一,使用起来也比较简单。

  界面贴图的制作:NGUI的图集合并规则,按照美术风格,规定美术的图素数量,将可能的图素合并到1-2张通用大贴图上,其次按照不同的模块进行单独生成图集,这样可以方便做bundle,进行资源下载等其他功能.

  自定义一些针对性的界面操作工具,图集修改,深度统计、修改

  效率:尽量减少Instantiate的使用,在合理的情况下使用Cache机制,但同时要控制内存的使用

  ScrollList或者ScrollView一定要实现循环利用,使用尽可能少的模板进行数据循环显示

  做好界面管理功能,我们项目中没有统一的界面管理,很容易造成界面该删除的时候没有删除,再加上比较深层的委托使用,和单一事件分发,使得有的模块的逻辑看起来很复杂,很难快速定位逻辑问题。

  任务系统

  新手引导:建议以端游的制作方式去处理,在开发过程中注意处理好事件屏蔽的逻辑,可以通过遮挡、tag标签、collider等来进行事件屏蔽,总之一定要满足不能因为引导出现异常造成用户无法继续游戏。

  Shader:因为项目中使用的shader类型也不多,但是在三星的I9260上发现角色的效果不正确,经过查看发现是shader脚本中有变量没有初始化造成,v2f o = (v2f)0; I9260使用的CPU是OMAP4470搭载了PowerVR SGX544@384MHz,有可能是驱动程序或者Unity自身优化造成,但是在iPhone4S上并没有发现这个问题,所以驱动程序的可能性比较大。结论,尽量都给变量加上初始化。

  Unity自身的Shader Code不支持discard语法,我们是使用AlphaTest + Blend替换的,但是在open gles2.0上又是不支持AlphaTest的,而是通过shader的discard来实现,那么应该是Unity进行了转换,有些shader语法需要注意一下。

  其他:注意与服务器时钟同步、注意监测网络,注意游戏切入后台再切回来的流逝时间处理,前后端的数据同步尽量使用直接赋值的方式,避免加减这种操作,减少逻辑出错几率。

  自动打包:资源自动打包,安装包自动打包,减少人为操作,降低出错几率。

  工程设置:必须采用.Net2.0 Subset,尽量剥离系统库,采用micro mscorlib,在这种模式下System.Xml System.Security.Cryptography等一些库无法使用,采取较小的第三方替代

  上线:开服前一定要做一遍checkList,梳理changelog以及需要那些资源,各功能的简单测试结果单。


     

------分隔线----------------------------
栏目列表
推荐内容