使用 Unity 3D 开发游戏的架构设计难点

Unity 3D 引擎对于开发者来说,入手非常快,因为它采用的是 C# 作为开发语言,这也大大降低了开发者的门槛。但凡只要懂一门编程语言的人都能使用 Unity 3D 引擎开发,另外 Unity 3D 的内部架构设计非常好,采用的是组件开发,开发者能快速通过组件堆积出一个游戏。既然使用 Unity 3D 引擎开发游戏这么简单,那它有没有坑呢?答案是肯定的,比如开发游戏经常遇到的坑:被很多开发者吐槽的包体过大、游戏架构设计,热更新,包防破解问题等等,下面笔者分享在游戏开发中的坑及解决方案,为大家的学习之路提供一定的参考。
 包体过大问题

  Unity 引擎最突出的问题是包体比较大,尤其现在随着硬件的提升,游戏品质要求越来越高,游戏品质的提升主要是从两方面体现的:一是通过图片的精细和模型的面数,二是利用 GPU 提升模型材质的渲染。模型面数和材质图片会增加包体的容量,尤其对于大型游戏来说,一个包体至少 100M 以上,这对于用户来说很难接受。程序开发者使用了很多招数都无法减少包体大小,笔者也遇到类似问题,通常的做法是将大部分资源放到资源服务器上,程序启动时,将其下载到手机本地,这么做是解决了包体过大问题,但是前期的资源下载也会影响到用户体验。

  现在问题聚焦在解决资源下载问题,笔者使用了另一种解决方案:利用多线程断点续传解决资源下载问题,程序要事先打包一到两个关卡在包体中,保证玩家在断网的情况下或者是刚启动游戏时能够顺利的进入游戏。玩家在玩第一关卡的时间策划要计算好,这样可以保证在有 WiFi 网络的情况下,启动多线程在后台下载,可以同时启动两到三个线程,在玩家把关卡打完后其他关卡也会陆续保存在本地,这样可以保证游戏不会中断。当然如果出现断网的情况可以弹出提示让玩家打开 WiFi。再介绍一下断点续传功能,在下载资源的过程中防止网络中断导致下载的资源废掉,一旦网络检测不到,它会保存并记录已下载的资源字节位置,如果再检测到网络,线程自动继续下载,这跟我们使用的迅雷下载很类似。资源的下载是在用户不知情的情况下进行的,这样就不会妨碍用户体验
多线程下载方案解决了包体大小问题,当然考虑到 WiFi 的带宽,对场景资源要求大小控制在 10M 左右,如果超过 10M 可以对其进行分包处理。另外需要注意的是对游戏图片的压缩,在这里推荐工具是:PhotoZoomPortable.exe。再推荐在线的图片压缩网址:https://www.tinypng.com/,二者都可以对图片进行压缩,另外对于图集的使用,推荐图集工具:Texturepacker,相比 UI 自身的图集,Texturepacker 打出的图集更节省空间。
 架构设计问题

  关于架构设计,很多人对此褒贬不一,笔者认为架构设计还是非常重要的。Unity 提供了各种开发组件,导致很多开发者遇到问题不是想着如何解决而是先在网上搜索看看有没有别人实现的组件,这种做法不能说是错误的,至少你在使用别人组件时是否能够完全掌握它,能否看明白人家写的东西,开发游戏不难,难在游戏后期的版本更新维护。记得我朋友公司做了一个游戏项目,即将上线运营,但是遇到了各类问题,其中最严重的问题是版本迭代时,各个模块功能耦合性太紧,很难进行功能扩展,牵一发而动全身,导致项目迟迟上不了线。他特意邀请我过去帮他解决这个问题,我去他公司看了一下他们的项目程序,各个模块之间逻辑互相交叉,耦合性特别强,在某个模块增加一个功能会涉及到其他模块的修改,一不留神就出 Bug,程序每天为这样的事情闹的焦头烂额,疲于应付。我根据他们的项目分析了一下出现的问题,首先是它们在 UI 这块逻辑太乱,UI 上挂接了各种逻辑脚本,我们首先拿 UI 这块开刀,去掉挂接在 UI 上的各种脚本,换句话说,UI 不挂任何逻辑脚本。我选择的架构模式是 MVC,它是架构 UI 的不二选择,将 UI 的逻辑放到了对应的各个 View 脚本中,每个 UI 面板都有自己的 View 类,Controller 主要实现的是控制 View 的切换显示,每个 View 对应自己的 Controller 模块,Model 模块处理的是 UI 面板上的数据更新。

更多unity2018的功能介绍请到paws3d学习中心查找。链接https://www.paws3d.com/learn/,也可以加入unity学习讨论群935714213

猜你喜欢

转载自blog.csdn.net/qq_38456196/article/details/87792086