论文写作模式-基于unity25d的即时战略游戏开发-CNKI知网查重网站

论文写作模式-基于unity25d的即时战略游戏开发

2021-06-10 10:59:44
作者:杭州千明

  随着我国IT技术的快速发展,中国游戏产业逐渐兴起,近年来,我国的2D及3D游戏产业在世界游戏市场上都取得了明显的进步。2.5D游戏作为近几年来提出的新的游戏概念,因其结合了3D游戏与2D游戏的玩法表现优点,使其得到了众多玩家的青睐,2.5D游戏逐渐成为下一代游戏开发的发展趋势。因此,本文基于Unity3D引擎开发了一款2.5D乐高风即时战略的独立小游戏。在游戏中玩家将扮演蓝方将领进行调兵遣,在镜像地图上完成抵御红方攻击,攻破红方堡垒等一系列操作,最终取得胜利。

  对于游戏,本文实现了RTS游戏的核心要素,重点研究了游戏框架搭建、地图搭建、小地图缩放、金币系统、角色制作动效、战斗逻辑这几个方面。在地图滚动的实现中,本文参考了2D游戏中滚动的实现,并加以扩展,应用到了本文的2.5D游戏中,实现了地图边缘的平行滚动。在战斗功能的开发中本文没有使用Unity内置的物理系统通过碰撞检测做出攻击判定,而是通过代码逻辑判断攻击目标,实现了不同角色的近战攻击和远程攻击。

  如今,中国游戏产业正呈现出繁荣之景。截至2019年,中国自主游戏研发在国内游戏市场实际销售收入2308.8亿元,同比增长7.7%;中国游戏用户规模达到6.4亿人,同比增长2.5%;中国自主研发游戏的海外市场实际销售收入达115.9亿美元,增长率21%。其中海外市场,美、日、韩市场占比更是达到了近七成,美国占比三成以上。但随着游戏版本不断推陈出新,如今的游戏越来越多,品质也良莠不齐,这些游戏已经无法满足广大消费者的需求。面临多种选择的中国玩家更倾向于选择于画面精良,玩法新颖,的高品质游戏。

  unity2.5d是下一代小型游戏开发标准,因为2.5D游戏有着3d游戏的渲染特点,使其带给了玩家2D游戏无法拥有的画质体验,而其本身镜头视角固定,部分玩家不会产生晕3D的症状。所以2.5D游戏的开发是未来10年内游戏开发的一个发展方向。我们应该紧跟技术的发展潮流,积极地占领制高点。

  中国一直以来使全世界即时战略游戏的主要游戏市场之一,目前国内自主研发的即时战略游戏很少,玩家心中留下经典印象的往往是一些国外大作如红警、星际等等。中国也曾经出现过许多有些的经典作品,如《傲世三国》、《一线生机》等,但大多在这个快节奏的时代也只是昙花一现。因此,研究即时战略游戏具有很有助于打破国外的垄断现状。

  1.2国内外相关研究及发展历程

  即时战略游戏,即RTS游戏,自其开发以来,以其相当完善的游戏设计架构、快节奏的游戏内容、以及非常浅显易懂的操作,使得RTS游戏成为了贯彻了整个电子竞技时代的关键。现今的RTS游戏则融合了其他游戏的玩法要素衍生除各种混合类型的游戏,比如今年3月发售的《骑马与砍杀2:霸主》,这款游戏就拥有RTS游戏的要素,同时也结合了其他丰富的社会化玩法,使之成为一款可玩性极高的混合类型游戏[1,9]。

  一般来说,即时战略游戏的起源可以追溯至1983年,由John Gibson开发的《Stonkers》[1],以及1984年Evryware's Dave和Barry Murry开发并发行的《The Ancient Art of War》都被普遍认为是当今RTS游戏的始祖,当然这也包括了《The Ancient Art of War》的续作:《The Ancient Art of War at Sea》(1987年)。

  在RTS游戏中,出现了注重战术的游戏,例如战火黎明6、星球大战、明日方舟等,他们不再像传统的RTS游戏那样通过资源采集来生产单位,建造建筑,而是以战略点获取的方式来控制产生资源和指挥不同类型的战斗单位[2,8]。

  另一些游戏则在传统的即时战略模式基础上并增加了其他类型游戏的元素[1]。一个例子就是IroncladGames推出的5太阳帝国的罪恶6(SinsofaSolarEmpire),混合了大规模星际帝国建设类游戏5MasterofOrion6的元素与即时战略的元素。

  1.3本章小结

  本章节介绍了该课题的研究意义以及国内外发展现状,综合以上概要,对本课题开发的即时战略游戏(RTS游戏)确定了基本开发手法,即基于unity的2.5d技术实现了斜45度视角的即时战略游戏。

  2游戏开发的相关概念

  2.1 Unity引擎

  Unity是由Unity Technologies公司开发的专业虚拟交互式引擎。相比于其他引擎,Unity最大的特点便是其多平台开发[3]。现已支持包括Windows、MacOSX、iOS、Android、PlayStation 3、Play Station 4、PlayStation Vita、Xbox 360、Xbox ONE、Wi iU,Windows Store、Windows Phone、Oculus Rft、Gear VR、Web GL和Web Palyer等在内的23个平台,用户只需进行一次开发,便可以发布至以上所提到的十流平台中。

  为了方便用户和游戏开发者,Unity引擎提供了一个网上资源商店(AssetStore)[3],在这个平台上游戏脚本代码、3DMOD、游戏音效和UI插件、材质等Unity相关资源是可以被开发者和用户购买和销售。同时Unity拥有一个资源分享与知识问答的交流平台,包括论坛、博客、在线视频等,以此帮助开发者更为便捷的了解Unity引擎。

  2.2 2D游戏

  2D游戏最显著的特征就是:以平面图片的形式制作所有图形元素,这类游戏的地图无论是整图制作还是拼接而成,其地面、建筑等都是以单张的图形元素组合在一起。而传统2D游戏的动画则是以一张一帧的形式预先设定的。最终,这些图形单元会经过脚本编写工具处理,以复杂的方式联系在一起,在游戏中进行调用从而创造除2D世界中丰富的游戏内容。

  另一方面的特征就是——2D游戏其本身的显示技术。传统的2D游戏很少需要调用显卡加速,大部分的2D图形元素都是通过CPU进行[4]。因此一款2D游戏的图形是否可以流畅运行,需要看CPU的负载能力。但这并不能说明在3D游戏纵横的现在,2D游戏就没有市场。一款画面丰富、风格独特、玩法新颖的2D游戏同样也可以得到玩家的青睐,如来自中国青年史悲和Light二人打造的《kio的人间冒险》,因其引人深思的剧情在这类小型独立游戏中赢得了不错的口碑;又如18年中国FantaBlade Network开发的2D横版ACT+META游戏《ICEY》,因为其新颖的玩法取得了成功,走向了世界。

  2.3 3D游戏

  3D游戏与2D游戏不同,3D游戏把游戏世界中的每个物体看作立体的三维对象,它们在渲染管线中是由若干个几何多边体构成。为了显示对象,在脚本文件中编写的是对对象的描述性语句,即对象由哪几个多边体组成,它们之间的空间位置关系,以及在什么部位使用什么贴图等等描述性内容[5]。在显示时,程序通过对这些语句脚本进行解释,最后实时合成一个3D物体。游戏引擎通过对若干个2维3维坐标进行实时计算,使得玩家可以在显示器平面上以任意的角度来观察3D物体。但如果组成物体的多边形越多,那么渲染合成3D物体时计算量就越大。如今市面上流行的AAA游戏(AAA指代“A lot of money(大量的金钱)”,“A lot of resources(大量的资源)”以及“A lot of time(大量的时间)”)大多都为3D游戏,如15年发售获得TGA(The Game Awards)最佳RPG游戏的《巫师3:狂猎》,18年发售引得无数人深思的《底特律:成为人类》,拯救19年法国巴黎圣母院失火重建的《刺客信条5:大革命》。这些游戏以其3D视角,还原了真实世界或者次世代世界的场景,让玩家得到极佳的视觉体验,而赢得了大多数玩家的喜爱。

  2.4 2D与3D的区别

  2D游戏与3D游戏最大的区别在于2D的平面与3D的立体上。他们的区别分为两部分:

  1.图形显示技术上的区别。这一点在前文中由提及。

  2.游戏整个过程中,所有的游戏动作是在一个平面进行的还是一个三维空间进行的。例如2001年发售的《奇迹MU》采用了3D图形显示引擎[4],但其核心玩法仍然是纯以鼠标点击地面进行的,实质上《奇迹MU》还是2D游戏;而类似《刺客信条》、《神秘海域》这样的游戏,则是标准的真正的3D游戏。

  2D平面,3D立体,是2D与3D的最基本区分点。

  2.5 2.5D游戏

  目前,对于2.5D游戏并没有一个严格的定义,现在普遍将同时具备了2D与3D游戏特点的游戏称之为2.5D游戏。例如被定义为2.5D游戏的《刺客信条编年史:中国》拥有3D的景深,2D的角色;还有拥有3D地图,3D角色,但镜头确实固定45°倾角锁定的《极乐迪斯科》。但在目前游戏场景或者地图设计制作上,还没有2.5D的地图一说,至多为伪3D。以《最终幻想VII》为例,该作中,地图制作采用了伪3D与3D技术的结合。当角色在世界地图上行动时,使用的是3D技术,所以该地图具备了3D技术的几大特点[6]:物体有空间感,视角可变,光照随视角变化而变化。而在《最终幻想VII》的场景地图中,同一场景视角是不可变的。其实《最终幻想VII》场景地图所采用的是以3D建模为基础,然后在材质上进行2D渲染整合的伪3D的技术,即“2D渲染”技术。这种伪3D渲染技术的好处在于比较容易将游戏物的质感给表现出来[3],而纯2D技术要做到这一点就非常困难。另外,《最终幻想VII》在视角不可变的场景地图中,却实现了角色的近大远小透视效果。这种效果就是指在纵伸感的游戏场景中,角色向场景的向前景或背景方向移动会随着景深而显得渐大或渐小。这种效果需要配合程序来进行实现,所以在程序技术方面会有一定的难度。

  3初步需求分析与设计

  3.1初步需求分析

  3.1.1愿景分析

  3.1.1.1业务目标

  学习RTS游戏领域的概念和技术、运用Unity5.6.3p1游戏引擎来开发游戏以及开发一个2.5D的即时战略游戏。

  3.1.1.2功能模块

  游戏的功能模块如图3-1功能所示:

  图3-1游戏功能模块图

  3.1.1.3系统特征

  游戏核心玩法包括策略指挥,角色战斗两个部分;其视角为斜固定45度视角地图x轴和z轴方向来回移动,y轴方向可以进行缩放;游戏特点包括采用面向对象思想来设计和编程、使用Unity3D引擎进行开发总的来说,本游戏具有良好可扩展性,能方便地进行二次开发。

  3.1.1.4系统上下文

  和传统的PVE玩法一样,该游戏有玩家和系统两个角色,如图3-2系统上下文所示:

  图3-2系统上下文

  3.1.2需求分析

  3.1.2.1功能需求

  本节对前文中提出的功能模块进行对应的需求介绍。

  1.地图

  a)显示背景

  如图3-3所示,游戏中背景是一个次级摄像机渲染的天空盒子,它不会随着主摄像机的移动而移动。

  图3-3游戏背景与游戏场景

  b)主体场景

  主体场景是游戏的主要场地,如图3-4所示,它是由AssetStore中下载的免费MOD搭建而成。地形设计参考了市面上大多数对称型MOBA游戏中1v1的条形镜像地图,如王者荣耀中墨家机关道(图3-5),决战平安京中的1v1斗技场地图(图3-6)。

  图3-4游戏场景模型

  图3-5《王者荣耀》墨家机关道地图

  图3-6《决战!平安京》1v1斗技场地图

  c)小地图

  如图3-7所示,小地图是由一个次级正交摄像机渲染而成,选后实时成像在游戏UI的小地图上,可以通过滚动条进行对地图缩放,以此来观察红蓝双方的对战情况。

  图3-7次级正交摄像机效果显示图

  2.角色

  游戏中分为两类,一类为玩家角色,一类为敌人角色。为了丰富游戏中北欧童话风格,本文在玩家可购买角色中加入了多样化的战斗单位:Soldier、Armor Soldier、Archer、Giant、Goblin、Transformer、Wizard、Royal Guard、Royal Cavalry、Goblin Cavalry。对于敌方角色,处于游戏平衡性的考虑,只设定了,Melee Enemy和Ranged Enemy两种敌人,每间隔4秒随机产生。

  a)显示

  地图上可以显示实体和实体的角色动画。选中角色单位实体时,会在场景上显示它们的选择框,指定移动位置时会显示定位特效,同时小地图上会实时显示每个角色在地图中所处位置。

  b)操作

  可以对除敌方的角色单位实体进行操作。玩家通过鼠标可以购买角色,调整角色在场景的位置;还可以右键框选选中己方单位,然后右击场景中任意位置,使其移动到指定地点,此时玩家指令为最高优先级。

  3.UI

  游戏风格整体采用简约卡通的风格,游戏中UI包括图片、功能页面和非功能页面三部分。图片主要包括玩家战斗单位图片,用于角色购买。

  功能页面指开始游戏后需要与玩家进行交互的页面,包括角色购买面板,炸弹CD,小地图等页面。

  非功能页面指与游戏内容不直接相关的页面,包括首页开始页面、游戏胜利页、游戏失败页面等。

  按照模块分,可分为开始界面,游戏界面,胜利界面和失败界面。

  4.金币系统

  玩家开局时会有200个初始金币,来购买资源御敌,此后每10秒会自动增加50-200不等的金币,供玩家购买角色。

  5.寻路系统

  寻路采用的是Unity自带的Navigation组件,Navigation将地图Ground部分进行烘焙,生成NavMesh(如图3-8所示),后面在脚本中进行寻路逻辑的撰写。

  图3-8 NavMesh生成图

  6.角色动作

  所有角色(除wizard外)都有Running和Attacking两种行为动作,这两种状态的动画,由Unity自带的动画控制器进行控制。

  7.玩家指令

  玩家按住鼠标右键拉动鼠标可以在画面上生成一个框选框选中角色,在地图任意位置点击鼠标右键便可完成角色强制移动指令。

  8.战斗

  游戏中实体分为敌方实体和我方实体。玩家以消耗金币的方式购买攻击单位,因为前期敌人移速快和攻击高的原因,所以要求玩家在短时间内合理分配游戏资源

  攻击单位分为远程单位和近战单位,其中弓箭手和法师为远程单位,各种士兵骑兵为近战单位。

  所有游戏单位除Giant外,都是以敌方城堡作为默认攻击目标,敌方攻击单位作为优先攻击目标。

  为了节省性能,本文以每秒单位攻击力匀速减少攻击目标血量,血量条减少为零,目标死亡。城堡血量条减少为零,则游戏胜利或游戏失败。

  9.音效

  游戏中每个界面会有自己的背景音乐,本文中所有音乐来自于《部落冲突》这款游戏,当角色走动时会有走动音效,攻击时会播放攻击音效,对于每个按钮,玩家选中会有选中音效。

  3.2初步设计

  3.2.1确定关键需求

  关键需求是指关键功能的实现。

  关键功能是游戏的核心功能,具体指地图、加入实体、移动、战斗这几个功能模块。

  3.2.2概念架构设计

  本节会从系统组成、开发环境、开发技术三个方面来阐述,并给出游戏的游戏框架结构图(GameManager)和角色结构模块。

  3.2.2.1系统组成

  因为本游戏使用Unity作为游戏引擎,C#MonoBehaviour编写脚本,以及开发基础游戏框架。

  3.2.2.2开发环境

  选择Win10作为操作系统,选择Visual Studio Community 2017作为开发IDE。对比其他同类型的IDE工具,Visual Studio Community 2017对C#的支持更强大,几乎不需要装插件,并且Visual Studio Community 2017有原生支持Unity3d游戏开发的功能组件,本文作者有该IDE相关的开发经验,掌握基本的使用方法,因此本文选用Visual Studio Community 2017作为开发工具。

  3.2.2.3开发技术

  Unity3d引擎功能强大,操作直观,并且插件丰富可以满足独立游戏开发的基本需求,其中用到了引擎里的GUI制作游戏各个界面,Animator Controller来控制角色动画播放,Navigation烘焙地形形成导航网络,结合脚本完成角色自动寻路的功能,粒子系统制作角色出生特效、死亡特效、召唤特效、爆炸特效、路标特效等,为了增强角色死亡时的真实感,还引用了布娃娃系统,让角色死亡时倒下的动作更具实体感。

  1.图形用户界面GUI

  图形用户界面(Graphical User Interface,简称GUI)是指采用图形方式显示的计算机操作用户界面。在Unity中,Unity自带的UI系统简称UGUI便是开发者制作UI的API工具。自Unity4.6版本之后,Unity中新的UGUI系统已经相当成熟,并且逐步取代了市场上的第三方插件NGUI。在Unity5.6.x版本中,UGUI已经成为主流的UI制作工具。

  2.Unity动画系统——Mecanim

  Mecanim是Unity的动画系统,它提供了以下功能:

  a)为人形角色提供的简易的工作流和动画创建能力。

  b)运动重定向功能,即把动画从一个角色模型的动作模式应用到别的角色模型上。

  c)针对动画片段以及它们之间的过渡和交互过程的预览能力,可以在编写游戏逻辑代码之前即可预览动画效果。

  d)一个用于管理间复杂交互作用的可视化编程工具。

  e)通过不同逻辑来控制不同身体部位运动的能力。

  3.导航网络(NavMesh)

  NavMesh[2]397是3D游戏世界中用于实现动态物体自动寻路的一种技术,它的功能是将3D游戏中的复杂场景的结构组织关系经过算法处理简化为带有特定信息的网格,进而AI在这些网格的基础上通过一系列的计算来实现游戏角色的自动寻路[10]。Unity编辑器提供了方便的用户操作界面,它可以根据用户所搭建的场景内容,自动生成导航网格。在工程项目中,只需要给游戏物体挂载相应的NavMeshAgent组件,游戏物体便会根据目标点来自动计算寻找到符合条件的路线,并沿着该路线前行到指定目标点。

  4.粒子系统

  粒子系统主要用来实现现实中一些如自由落体、星空、爆炸等,或某些自然效果比如烟雨、瀑布等的物理模拟[2]213。粒子系统是一些粒子的集合。以下是它属性详解:

  表3-1粒子系统参数表

  参数含义

  Duration(粒子持续时间)粒子系统发射粒子的持续时间,如果开启了粒子循环,则持续时间为粒子一整次的循环时间

  Looping(粒子循环)粒子系统是否循环播放

  Prewarm(粒子预热)若开启粒子预热,则粒子系统在游戏运行初始时就已经发射粒子,看起来就像发射了一个粒子周期一样,只有在开启粒子系统笔循环播放的情况下才能开启此项

  Start Delay(粒子初始延迟)游戏运行后延迟多少秒后才开始发射粒子。在开启粒子预热时无法使用此项

  Start Lifetime(粒子生命周期)粒子的存活时间(单位:秒),粒子从发射后至生命周期为0时消亡

  Start Speed(粒子初始速度)粒子发射时的速度

  Start Size(粒子初始大小)粒子发射时的初始大小

  Stat Rotatiln(粒子初始旋转)粒子发射时的旋转角度

  Start Cotor(粒子初始颜色)粒子发射时的初始颜色

  Cravity Modifler(重力倍增系数)修改重力值会影响粒子发射时所受重力影响的状态,数值大重力对粒子的影响越大

  Lnherit Velocity(粒子速度继承)对于运动中的粒子系统,将其移动速度应用至新生成的粒子速率上

  Simulation Space(模似坐标系)粒子系统的坐标是在世界坐标系还是自身坐标系

  Play On Awake(唤醒时播放)开启此选项,系统在游戏开始运行时会自动播放粒子,但不影响Start Delay的效果

  Max Particles(最大粒子数)粒子系统发射粒子的最大数量,当达到最大粒子数量时发射器将暂时停止发射粒子

  5.布娃娃系统

  布娃娃系统常用在动作游戏或一些大型3DRPG游戏中,通常在角色单位死亡后调用,进而营造一种丰富的动作表达与模拟现实中物体受力情况。

  开发者在合适的位置给角色安装骨骼,通过游戏引擎控制这些骨骼的移动,而角色的表层随着骨骼的移动而发生相应的变化。这样的技术让游戏中的角色有更加多变丰富的动作可以变现[12]。

  3.2.2.4游戏框架——GameManager

  游戏框架的存在意义是为了让游戏资源功能等更便于管理,使游戏开发的整体结构更加清晰,游戏会具有扩展性,开发者可以根据后续需要对游戏进行功能上的拓展,让游戏更具可玩性,方便二次开发。处于以上考虑,如图3-9所示,本文设计了一套基础框架来进行游戏功能和资源的管理。

  图3-9游戏框架

  1.GameManager

  GameManager是游戏的入口管理器,管理功能管理器,自身也可以与单方面与其他管理者进行访问,其他管理器想要相互进行访问,只能通过GameManager提供的外部接口,公共方法进行次级管理器之间的相互访问,而同事类与上下级之间是互不相识的。

  2.AudioSourceManager

  负责控制音频,背景音乐音效的播放、停止、存储以及加载当前的musicPlayer。

  3.ResourceManager

  管理所有游戏资源的加载,存放以及游戏物体的对象池。

  4.UIManager

  负责所有UI的摆放、加载和遮罩功能。

  5.ObjectPool

  负责获取游戏物体对象,实例化游戏对象,回收不用的游戏对象。

  6.ResFactory

  负责获取资源的操作,与ObjectPool一样负责游戏时资源的管理操作。

  3.2.2.5角色结构模块

  在游戏中,每个自动生成和玩家出发生成的角色都是事先做好的预制体——Prefab,它可以理解为一个游戏对象以及它的组件的集合,其目的是为了使游戏以及资源能够被重复使用。它作为一个资源可以被应用到整个项目的不同场景中。当开发者拖动一个预制体到场景中,就完成了一个实例的创建。这个实例与原来的预制体关联。对预制体进行修改,实例也会同步进行修改。这样的作法可以提高整个项目资源的利用率,还能提高开发者的开发效率。所以本次开发中,所有的角色单位(包括模型、动画、特效、布娃娃系统等)都被做成了预制体,以便反复利用。

  本次开发中,角色基本模型来自于Unity自带的AssetStore中的Mod,每个角色带有自己的动画,动画分为Attacking和Running两个基本动作,亡灵法师角色还带有一个特殊的召唤动画——Spawning,骑士类型角色分为马匹和骑士两个模型,需要自行拼接。

  本游戏中,如图3-10所示,每个角色都是由角色Mod,角色动画,角色选中框,角色血条,角色小地图标记,角色导航系统,角色特效,角色音效播放器,布娃娃系统和构成胶囊碰撞体构成。

  图3-10角色预制体结构图

  4游戏开发

  本章节将根据前三章概述的总体内容与大致框架,按照实现顺序来介绍本文游戏的开发流程。

  4.1角色与特效的制作

  4.1.1角色制作

  这一小节的角色制作主要包括角色各项属性数据,角色本身的与Animator Controller的绑定,角色特效制作,角色除本体模型外零部件的制作。整个角色预制体的结构参考第三章图3-10。

  4.1.1.1角色数据

  考虑到开发的难易程度和游戏的可玩性平衡性,在表4-1中对敌方角色的攻击力与生命值进行了适当的加强。根据其每隔4秒生成一次的特性,将敌方单位在场上的数目维持在20个。因此,在敌人产生和强度上来平衡敌我双方的战斗力,让这款游戏有一定的难度和可玩性,而不是一个单纯的割草类型的RTS游戏。考虑到部分玩家的游戏经验和操作能力,本游戏还提供了一个炸弹系统,在规定时间内生成一颗炸弹供玩家使用,该炸弹可以炸死范围内的所有敌人。

  表4-1角色属性列表

   周称价格伤害生命值攻击距离移动速度

  Soldier 30 1 10 1 2

  Armor Soldier 50 2 30 1 2

  Archer 70 2 10 6 2

  Giant 120 5 200 3 1

  Goblin 20 4 7 1 3

  Transformer 300 4 140 2 3

  Wizard 100 3 30 2 1

  Royal Guard 80 3 100 2 2

  Royal Cavalry 150 5 120 4 5

  Goblin Cavalry 180 7 120 4 5

  Skeleton召唤获得2 10 1 5

  Melee Enemy无法购买2 80 2 3

  Ranged Enemy无法购买4 40 6 4

  Bomb等待30sCD----

  4.1.1.2角色预制体制作

  1.角色Mod

  如图4-1所示角色Mod素材包括了如图所示的基本部分,它是整个角色展现的核心要素。

  图4-1角色MOD

  2.角色动画

  本游戏中,所有单位的动作状态转换基本相同,所以在此先设定一个默认动画控制器(Default Animator Controller)作为基类,如图4-2所示,在此控制器中将布尔值Attacking作为动画转换的条件。此后所有的动画都是在此结构的Animator上重写的衍生类(OverWrite Animator Controller)。

  图4-2 Default Animator Controller

  与其他角色不同的是亡灵法师(Wizard)这一角色,这类角色拥有一个特殊的技能——召唤,所以在这里,重新设定了一个Animator Controller(如图4-3所示)专门用于控制Wizard的行动状态。该控制器中有两个用于控制角色行动状态的布尔值:Attacking和Spawning。其控制条件如下表所示。

  表4-2 Wizard Animator Controller条件控制表

  状态转换Bool Attacking Bool Spawning

  Running->Attacking true false

  Attacking->Running false false

  Running->Spawning false false

  Spawning->Running false true

  Spawning->Attacking true false

  图4-3 Wizard Default Animator Controller

  3.角色选中框

  在右键框选中角色时,角色脚下会显示如图4-4所示的选中标记,角色未选中时,该预制体不显示。

  图4-4角色标记效果图

  4.角色血条

  如图4-5所示,角色血条是角色头顶的蓝色Slider属于2D组件,属于一个面片,所以在3D渲染过程中需要在脚本中设置血条看向主摄像机,以此来达到一个显示血量的功能。当人物未受到攻击且血量满的时候,血条不显示。

  图4-5

  红蓝双方有不一样的血条颜色进行区分,笔者在开发脚本时敌方的选中标记不启用。

  5.角色小地图标记

  如图4-6所示,角色头顶的红蓝圆片为角色小地图标记,该标记不在游戏场景中渲染,只在次级正交摄像机呈现的小地图中渲染。

  图4-6

  6.角色导航系统

  在每个角色预制体上为之添加NavMeshAgent组件,结合搭建游戏场景时烘焙的NavMesh,实现角色的自动寻路功能。该组件在角色脚本中自动进行调用。

  图4-7 NavMeshAgent组件参数

  7.角色特效

  如图4-8所示本游戏中设置了五种特效:出生特效、死亡特效、目标点特效、召唤特效、炸弹爆炸特效。

  图4-8特效效果图

  这些特效是使用Unity的粒子系统结合点光源生成的预制体,在后续脚本中将根据需要实时进行调用和回收。

  8.角色音效播放器

  为了让游戏更加生动,这里每个角色都有一个自己的音频播放器(AudioSource)用于播放攻击音效和跑动音效。

  9.布娃娃系统

  每个下载的模型本身自带了一个IDIE动画,但这些动画并不是最佳的选择,很难体现出人物倒地的真实感。于是这里采用了大多数游戏开发中都会去使用的布娃娃系统,来增强角色死亡倒地后的物理真实感。Unity中只要在创建的布娃娃系统界面中对每个角色的关节骨骼进行逐一绑定,就可以制作完成一个布娃娃系统。

  10.胶囊碰撞体

  除去上述各种组件外,如图4-9所示,每个角色都有一个胶囊碰撞体,专门用于对弓箭这类武器射出的箭做碰撞检测,以计算伤害。

  图4-9胶囊碰撞体

  11.物理引擎(Rigidbody)

  如图4-10所示为了更好的模拟箭被射出的物理轨迹,在箭(Arrow)的预制体上挂载了Rigidbody组件,这样箭被射出时就会和真实世界中一样,有一个弧型的运动轨迹。

  图4-10 Rigidbody参数以及Arrow预览图

  4.2 UI的制作

  如第三章中提到的UI界面有:开始页面、游戏胜利页、游戏失败页、游戏界面。这也界面共用一个游戏场景,由UIManager控制管理。整个游戏的分辨率固定为1024x768。

  4.2.1开始界面

  如图4-11所示,该界面只有一个可互动按钮BATTLE WON,点击即可开始游戏,此时主界面背景音乐停止,游戏界面音乐播放,BATTLE WON按钮禁用,开始界面渐隐,显示出游戏界面,游戏开始。

  当鼠标悬停在BATTLE WON按钮上,按钮会有一个放大特效,离开按钮范围,按钮恢复正常。按下按钮按钮缩小,并且播放按钮音效,之后实现相关功能。

  图4-11

  4.2.2游戏胜利界面和游戏失败界面

  胜利界面与失败界面是当有一方HP减为0时自动弹出,弹出时,游戏内所有实例化的角色单位回收,各项数据重置,游戏回到还未开始的状态。

  Restart按钮与开始界面的BATTLE WON按钮共享一个相同的动画,点击后游戏重新开始。

  图4-12胜利面板和失败面板

  4.2.3游戏界面

  如图4-13所示,整个游戏界面分为以下几部分:

  图4-13游戏UI设计

  敌人玩家HP显示:红蓝双方的生命值由图片进度条来显示,可以根据当前生命值的百分比实时显示HP,该部分由游戏脚本实现,先UIManager和GameManager中实时监听更新数据状态。

  小地图显示:小地图由一个次级正交摄像机进行实时渲染,在上一节中提到的角色小地图标记也会在上面显示,实时追踪红蓝双方单位的地图定位。滑动小地图右侧滚动条可以进行地图缩放,屏幕右下角的按钮可以实现小地图的显示和隐藏。

  金币显示:游戏开始时玩家拥有200的初始资金用于购买角色,金币系统的存在类似于很多战略游戏中的指令点,士气值等。每次在角色商店购买角色,将消耗角色相应价格的金币。当金币不足时,便无法购买角色,金币数不会减少。

  Tip提示框:当玩家金币不足时便会弹出,正常状态下不显示该提示框。同时游戏中每隔10秒会随机增加50到200不等的金币,每次增加金币,该窗口也会直接显示调用。

  炸弹按钮:扎按钮的显示与玩家HP显示的方式类似,按钮外圈的深蓝色部分时一个进度条,它会按照一定的速度缓缓增加,只有当进度条满时,该按钮才可调用,玩家点击并使用了炸弹后,该进度条会重新进行计时,实现了技能CD图形化的功能。

  角色商店:显示了如图4-14所示Resource/Prefabs/Characters文件夹中所有除10号Skeleton外所有可购买角色的角色按钮,当鼠标停在相印角色按钮上,右侧会显示角色相关数据信息。当游戏开始时,商店中的角色按钮根据UIManager中所编写脚本,逐一生成。按下按钮会触发游戏角色实例化、金币减少等相关事件。

  图4-14角色预制体文件夹

  4.3 UI功能实现

  游戏的UI功能主要是在UIManager中实现,部分则是由单独脚本开发。UIManager中主要做了4.2节所提到一系列逻辑功能的实现。

  此外在游戏界面坐标框选上做了数值修正。OnGUI坐标系原点在屏幕左下角而屏幕坐标系原点在右上角,若直接进行操作会出现,框选位置混乱的问题,所以此时需要对坐标系y值进行相印换算,关于摄像机移动问题也应做相应处理。

  4.4角色功能实现

  所有角色以及敌方攻击单位的逻辑基本相似,个别特殊角色的逻辑脚本则是在角色基础脚本上编写的衍生类。

  4.4.1 Character

  如图4-15所示,为Character类的主要逻辑流程图。

  图4-15角色逻辑流程图

  4.4.2 Archer

  弓箭手与其他角色不一样的地方在于,弓箭手射出的箭矢是单独作为一个游戏物体存在的。为了使游戏角色动作更加精细,在这里的处理做法为,弓箭手模型的手指持有一支专门为射箭动作做渲染的假箭,当箭矢射出时在假箭的坐标位置上生成一支带有Rigidbody的真箭即(GameObject Arrow),接着Arrow脚本会做出如图4-16所示以下逻辑判断。

  图4-16箭矢逻辑流程图图

  4.4.3 Giant

  巨人只会攻击敌方城堡,所以它的逻辑脚本只需执行目标为城堡的那条逻辑分支。

  4.4.4 Wizard

  亡灵法师相较于其他角色,多出了一个召唤骷髅兵的技能,在脚本中只添加了一个召唤的功能,即每隔10秒在亡灵法师面向的前方不远处随机位置上,生成三只骷髅兵,同时召唤时需要调用召唤特效组件。

  4.4.5 Cavalry(Knight)

  在制作预制体时,骑兵的模型分为马匹和骑士两部分,两部分模型都有自己的专属动作。所以骑士在进行状态接切换时攻击动作和跑动动作的组件不在同一个物体上,在这个脚本中,Runing动画由马匹播放,而Attacking动画由骑士本身播放,在骑士脚本上修正的就是这个问题。

  4.5音效的添加

  本小节是该游戏开发的最后一个部分,只需要在事先写好的游戏框架中调用AudioSourceManager组件播放相应音效即可。