【游戏客户端】实现游戏中的小地图

【游戏客户端】实现游戏中的小地图

      之前的博客中,我和大家分享了如何做:

  • 商业化的充值活动 :【商业化充值活动博客】
  • 抽卡系统:【抽奖,抽卡系统博客】
  • 装备系统:【装备系统博客】
  • 红点系统:【红点系统博客】
  • 商店&拍卖系统:【商店&拍卖系统】
  • UI环绕特效:【UI环绕特效】
  • 实现刮刮乐效果:【实现刮刮乐效果】
  • 实现卡牌翻转效果:【实现卡牌反转效果】
  • 实现剧情对话:【实现剧情对话效果】

      今天和大家分享一下如何制作游戏里的小地图的思路主流的实现方式有两种:

(一)预制作底图

      首先第一种就是预制作底图,就是把场景的整体外貌作一个缩放并提前制作成图片,程序在写代码的时候只需要简单的把图片加载到控件上就可以了

(1)预制作底图的好处

      这种做法比较简单,而且由于是美术的输出所以底图的质量是可控

(2)分块获得场景外貌

      首先就是要获得整个场景的样貌。在对场景进行航拍取景的时候,我们并不能简单的把摄像头拉到很高的地方,然后正交投影的相机以俯视的方式把整个场景渲染到一张图上,这样得到的图片会很糊

      为了地图的精度,我们可以设定采样的规则,统计整个场景有多少地图块,然后多少个地图块进行一次航拍,遍历所有的地图块,然后把拍到的图片再重新整合成一个完整的图片交给美术优化再重新打入游戏就可以了

(3)预防内存裂开

      对于一般的场景来说,(2)的做法是可以完成需求的。但是!!!如果是那些很大很大的地图,比如吃鸡,率土这些大场景来说,如果直接合成一张完整的航拍图只会有两个结果,要么美术的photoShop裂开,要么加载进游戏的时候引擎裂开

【游戏客户端】实现游戏中的小地图_第1张图片

      因此我们必须采取另外的优化手段,比如我们的小地图是一个正方形,那么我们就不直接把各小块合成一张”大“图,而是合成3*3九张”中等“的图

(4)多级分辨率设计

      当然这样子做只是减轻了美术的压力,当我们把这9张中等规模的图load到游戏中时,占用的内存是一样的,因此可以采用多级分辨率设计(其实就是利用越远越模糊,越近越清晰的思想),把地图按照清晰度进行分级

      比如还是那个九宫格,当玩家观看整体的地图时,是由九张图片进行合成的,一张一M那就是9M,当玩家想看左上角那一块地图时,则进入下一分辨率,重新加载左上角所组成的九张图片,同样是一张一M,这样玩家无论什么时候都能看到9M的图片资源而不是对1m的资源进行放大!!通过配置不同分辨率的资源来实现固定内存开销却又满足清晰度的需求

【游戏客户端】实现游戏中的小地图_第2张图片

(二)实时渲染制作小地图

      上文巴拉巴拉了一大堆,最后看似保证了清晰度且稳定了内存开销,但是想想也知道多分辨设计会很影响包体大小,而实时渲染就可以直接根据可视的UI,Capture出当前显示的地图,然后load到小地图的精灵就可以了

      其实就是时间换空间的方法

(1)实时渲染制作小地图的好处

      而实时渲染制作小地图的地图,就可以保证了每帧的小地图上的显示信息的准确性和即时性,无需预制作底图,不会增加包体和底图维护的开销,渲染的效果和表现脚本可控

 (2)降低实时渲染的开销

      当然缺点也很明显,需要用时间换空间,频繁的capture会造成性能的损耗。因此需要减少渲染所造成的开销

      比如如果原先capture的大小是目前玩家可视的场景画面,那么每帧都需要重新绘制小地图,而如果,我们把capture的大小设定为可视场景大小的四倍,然后将之加载到地图中

      那么这个时候只需要作一个简单的裁剪,同样能展现出玩家当前的小地图场景,但是好处是只要玩家没有超出”边界“,我们就只需要对地图进行位置的移动,这样子就避免了每一帧capture的开销

不知不觉已经十点半了,好啦今天就到这里
点赞,关注!!!

你可能感兴趣的:(浅谈游戏系统,cocos2dx实战项目,特效,粒子,环绕)