《基于Unity3D解密RPG游戏设计与实现.docx》由会员分享，可在线阅读，更多相关《基于Unity3D解密RPG游戏设计与实现.docx（29页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、基于Unity3D解密RPG游戏设计与实现 基于Unity3D的解密RPG嬉戏的设计与实现 Design and implementation of decryption RPG Game based on Unity3D 内容摘要 本次课题是研造一款以Unity 3D引擎的解密RPG嬉戏。嬉戏剧情是以浦岛太郎的童话故事为主题进行改编，原故事结局是浦岛太郎打开玉匣，最终变成了一个老头子，单调而且具有漏洞。而本嬉戏将会一改原故事的结局，并且添加更多不同的故事结局，使嬉戏过程更加扑所迷离，而且还会加入隐藏剧情增加嬉戏的趣味性，使得嬉戏更具有故事性。 玩家将扮演浦岛太郎进行龙宫探究，在龙宫探究期间，
2、发觉龙宫中的各种不寻常的事务，发觉最终的真相。在整个嬉戏设计的过程中，将运用到3DMax模型制作、Animator与Animation的动画制作系统、NavMeshAgent自动导航系统以及Fungus对话系统等多种技术相互结合，制作出一款可玩性高以及富有戏剧性的解密RPG嬉戏。而本嬉戏的改编将会让原故事更加广为人知，以及对原作的更深层理解，具有肯定的市场价值和考察意义。 关键词：Unity3D Fungus 解密嬉戏 角色扮演 Abstract This project is to develop a decryption RPG game with unity 3D engine. The
3、 story of the game is based on the fairy tale of “posima taro“. The original ending is that posima taro opens the jade box and turns into an old man with monotony and loopholes. This game will change the ending of the original story, and add more different ending of the story, so that the game proce
4、ss is more lost, and also add hidden plot to increase the fun of the game, so that the game has more story. Players will play the role of taro of PuDao to explore the Dragon Palace. During the exploration of the Dragon Palace, they will discover various unusual events in the Dragon Palace and find t
5、he final truth. In the whole process of game design, it will be used to make 3DMAX model, animator and animation animation animation system, navmeshagent automatic navigation system, and fungus dialogue system and other technologies to combine with each other to make a playable and dramatic decrypti
6、on RPG game. The adaptation of the game will make the original story more widely known, as well as a deeper understanding of the original, with a certain market value and inspection significance. Key words： Unity Fungus PuzzleGame role-playing 书目 第一章 绪论 1 1.1 本课题的探讨目的和意义 1 1.2 探讨现状 1 1.3 创新思路 2 1.4
7、嬉戏对比 2 1.5黑童话起源 3 1.6 Fungus对话系统介绍 3 其次章 需求分析与总体设计 8 2.1 故事向的解密嬉戏的需求分析 8 2.1.1 玩家需求分析 8 2.1.2 功能需求分析 8 2.2 嬉戏的总体方案设计 9 2.2.1嬉戏结构方案设计 9 2.2.2 总体结构方案设计 9 第三章 嬉戏具体设计与实现 11 3.1人机交互模块 11 3.1.1 起先界面 11 3.1.2 设置界面 11 3.1.3 嬉戏交互界面 12 3.2 嬉戏场景模块 13 3.2.1 海边场景 13 3.2.2 海底场景 13 3.3剧情模块 14 3.3.1开局 14 3.3.2发展 14
8、 3.3.3高潮 14 3.4 关卡模块 15 3.4.1 迷宫 15 3.4.2 密码锁 16 3.4.3 移动的平台 18 3.4.4 暗门 18 3.4.5 拼图 18 3.5 Fungus对话系统 19 3.5.1 实现原理 19 3.5.2实现结果 22 第四章 嬉戏测试 24 4.1功能测试 24 4.2 嬉戏测试结果与探讨 25 第五章 总结与展望 26 5.1总结 26 5.2 展望 26 参 考 文 献 27 第一章 绪论 1.1 本课题的探讨目的和意义 随着计算机在全球有着越来越高的地位，计算机嬉戏软件的开发正在成长为新兴行业。RPG嬉戏（角色扮演嬉戏）也跻身于当今市场上最
9、受宠爱的嬉戏类型，但是以寓言和童话故事为核心的嬉戏却为数不多，每当我问起四周的人是否知道浦岛太郎这一个故事的时候，大家的回答都是全然不知。 浦岛太郎看似只是一个珍惜时间的寓言故事，假如能够更加深化地发掘并思索的话，可以延长出更多须要人们深化思索的意义。而故事剧情作为RPG嬉戏里最重要的构成元素之一担当了相当大的责任和意义，不仅推动嬉戏情节发展，也是玩家能否具有代入感和深度体验的关键所在。一款嬉戏拥有优秀的剧情不肯定会成为胜利的作品，但一款胜利的作品肯定拥有优秀的剧情。剧情的力气可以使人产生情感的共鸣，当一款嬉戏的剧情真正打动到玩家的时候，玩家自然会出于个人的情感线索产生持续体验。剧情的另一个发
10、展就是开放式的剧情，国外许多嬉戏尤其是主机嬉戏早已采纳了这种方法，利用可写入式文本和玩家一同生产剧情，详细的操作就是在对话中会出现多重选项，不同的选项会使剧情向着不同的方向发展产生不同的结局，不得不说这是一个特殊好的策略，大大增加了嬉戏的可玩性，尤其是对于追求不同结局成就的玩家来说，多周目体验成为了必备技能。 为此，本课题是以浦岛太郎的童话故事为主题进行改编的嬉戏，以浦岛太郎作为故事内核，添加更多的故事结局和故事情节，给玩家带来不一样的体验感，也让更多的玩家了解到浦岛太郎的故事。 1.2 探讨现状 近两年来的中国RPG嬉戏市场呈现出一种“快餐经营”模式，很多嬉戏开发商们只是想着创新，却不顾整体
11、的变更，这样顾头不顾尾的做法导致嬉戏被改得四不像，玩家们也无法在嬉戏中得到深化其境的享受，再来看看逆水寒，就拿嬉戏中的NPC交互系统来说吧，有一次不当心跳到了桌子上，结果被四周的人说是一个“无理之人”，嬉戏中的细微环节随处可见。开发商都试图创建出独一无二的战斗系统，这本是好事，但问题是，他们脑子里只有战斗系统，而把其他全部的东西都忘得一尘不染了，惋惜的是，和MMORPG一样，真正独特的战斗系统少之又少，大多数嬉戏都只是在同一个系统的基础上进行调整，导致这些所谓的“创新”变得如此的非驴非马，四不像。没错，创新是好事，但代价是什么呢？假如能有浩大、具有深度的故事剧情和角色发展，那么光是“攻击”、“
12、物品”和“防卫”就够了。为此，本课题的创新方向是从故事情节动身，在原故事情节上进行大幅度修改，带领玩家体验另一个不一样的浦岛太郎 1.3 创新思路 本课题的创新方向是从故事情节动身，以浦岛太郎作为故事内核，添加更多的故事结局和故事情节，给玩家带来不一样的体验感，也让更多的玩家了解到浦岛太郎的故事，带领玩家体验另一个不一样的浦岛太郎。优化了原故事剧情，并改编成解密RPG嬉戏，增加更多人物的情感线，加固故事的情节性。添加更多不同的故事结局，使嬉戏过程更加扑所迷离，而且还会加入隐藏剧情增加嬉戏的趣味性，使得嬉戏更具有故事性。1.4 嬉戏对比 （1）玫瑰与黄昏的古城- 平台：PC/PSV 本作又名萝洁
13、与黄昏古城，嬉戏由日本一开发制作，于今年4月发行。名为萝洁的小女孩在一座失去了色调的古城中醒来，而在她记忆中，她原来是应当住在修道院才对的。于是萝洁起先一边前进，一边找寻各种线索，起先想法设法逃离这座巨大的废墟古城。嬉戏中萝洁会遇见有着螺旋一样面孔的谜一样的巨人，而这个看起来很可怕的家伙事实上却很和善。在往后的逃离之路上，巨人成为了萝洁强有力的好伙伴。（2）多克罗（骷髅王子）- 平台：PSV/Andriod/iOS 最早是于PSV推出，而后移植到安卓与苹果等移动平台的一款横版动作解谜嬉戏。嬉戏的主角原本是一名英俊的王子，被下了诅咒才变成了这幅蠢蠢的小骷髅的模样。变成骷髅的他，失去了许多力气，特
14、别的弱小，尽管这样，他还是依旧英勇的带着公主踏上了逃亡的路途。随着嬉戏推动，嬉戏里小骷髅也可以短暂的变回王子模样，王子状态下各方面状态都得到加强，还能干脆抱起公主前进。嬉戏相对来说略微老一点，但是各种谜题设计的合理又好玩，特别的值得一玩。（3）空洞骑士- 平台：PC/Switch/WiiU 人在空洞之中会看到什么？哈哈，别别想太多，并不是要探讨哲学的。这部空洞骑士在嬉戏中，采纳了黑魂和血缘一样的碎片化的叙事，把真相撒在大海汪洋里面让玩家去一点点的找回。和之前举荐过盐与避难所一样，脱胎于宫崎英高老贼那些鬼点子中的本作，也一样的有着较高的难度。举荐给魂系列爱好者和恶魔城老粉们。 （4）月圆之夜-
15、平台：PC/Andriod/iOS 是一款独立单机卡牌嬉戏，探究，冒险，随机事务，随机剧情将会导致不同的结局。七大职业，每个职业有专属的卡组，专属的流派，100种独具特色的怪物，揭秘黑森林的隐私 1.5黑童话起源 黑童话题材的嬉戏在以后会越来越多。这是由市场潜在用户群体确定的！作为最早最为广泛接触到格林童话的80后这一代，在幼儿、小学时期接触到童话故事， 而且是记忆比较深刻的。这类人群如今已经沉醉社会多年，面对社会生活的压力，这类人群正是在理解社会压力，感受社会现实的最佳时期，面对幼儿时期的美妙童话，他们都觉得那是虚拟科幻的，反而更情愿接受更具备社会现实的黑童话故事。 而接班80后的90后，9
16、5后群体，更是具备特性十足的一代，他们总能把传统的事物变得更加不一样！对于传统童话故事，他们更不会手下留情！ 说到这里，其实格林童话初始的原版并不是我们小学课本和我们同年时代的那样！林兄弟在收集民间故事的时候，本身已经做了有利于出版的修改。很多民间故事原来就带有肯定的恐惊性色调，这个状况不论是中国或是德国，都是存在的。比如在我的家乡，有关于海洋动物的恐吓小挚友的故事，但家家不尽相同，最终我的一位同学在以这个为素材创作的时候，做了改动。传统童话IP，如灰姑娘、白雪公主、青蛙王子的嬉戏早已经满大街，举不胜举，反观同样的闻名IP背景，缺失的是吸引大众的亮点，而黑童话题材无疑可以抓住这点！就像腾讯的天
17、魔幻想，本身的嬉戏IP并不出众，但是经过白洗黑的过程，却反而让人觉得可以一试，加上一些合体技之类的嬉戏创新，至少是可以让人觉得一试！ 1.6 Fungus对话系统介绍 Fungus是一款检视面板自定义工具，主要帮助标记不同角色对话在检视面板上显示的颜色，以便更好、更清楚地实现嬉戏角色之间的对话逻辑。克里斯格里根（Chris Gregan）是Fungus的主要作者和维护者，该插件须要Unity5.0及以上版本，无需编写代码。Fungus可以在与标签的对话中触发事务、条件和逻辑处理，并支持摄像机、Sprite及音乐音效的限制。它供应了一个交互界面，可以快速构建一个对话系统。Fungus可以通过直观
18、的视觉脚本系统轻松地将叙事功能添加到Unity嬉戏中，而无需编写代码。适用于制作视觉小说，RPG，隐藏对象，益智和互动小说嬉戏。基于流程图的角色对话将角色对话的国际化。轻松限制子画面，摄像机和音频以帮助讲解并描述的故事，适用于2D和3D Unity嬉戏，易于与其他Unity代码集成，并且易于扩展。强大的Lua脚本支持，适合阅历丰富的用户。（图1-1） 图 1-1 Fungus对话系统 保存菜单：保存菜单是一个简洁的用户界面，允许玩家与真菌保存系统进行交互。本节说明每个按钮的作用以及如何配置“保存菜单”属性。保存数据键：用于在Player Prefs中存储嬉戏数据的字符串键。假如在同一Unity
19、项目中定义了多个嬉戏，请为每个嬉戏运用唯一的键。启动时加载：启动时自动加载以前保存的嬉戏。自动保存：在每个保存点自动将嬉戏保存到磁盘。启用此选项后，“保存”和“加载”按钮将被禁用。保存菜单还支持一种自动保存模式，在该模式下，嬉戏会在每个保存点都保存到磁盘上。可以通过选择“保存菜单”对象并选择“自动保存”属性来启用此功能。运用自动保存时，Fungus将禁用“保存功能”和“加载功能”。可以在层次结构窗口的根书目中看到“保存菜单”对象。该对象限制播放器用来与保存系统进行交互的UI菜单。“保存”菜单是一个单例对象，可在场景加载中持续存在，因此只需在嬉戏的第一个场景中添加一次即可。重新启动删除保存：当玩
20、家重新启动嬉戏时，从磁盘上删除保存数据。这在测试嬉戏以确保从空白保存状态起先时特别有用。留意：假如嬉戏运用多个场景（例如，通过“加载场景”吩咐），请确保将全部场景添加到“构建设置”中的“构建中的场景”列表中。保存按钮：按下“保存”按钮会使当前的“保存历史记录”序列化为JSON文本，并通过PlayerPrefs类写入长久性存储。保存点：保存点是某个时间点嬉戏状态的快照。每个保存点都记录当前场景，流程图执行的当前点（即在保存点吩咐处）以及流程图变量的当前值。目前仅保存Boolean，Integer，Float和String变量。保存点吩咐：在流程图中运用“保存点”吩咐可在执行中的该点创建一个保存点
21、。每个单独的保存点吩咐应具有唯一的保存点密钥。“加载时复原”选项使加载保存点后从该点复原执行。保存点密钥：保存点密钥是单个保存点的唯一字符串标识符。默认状况下，父块的名称用于保存点密钥，但是假如须要，也可以运用自定义密钥（例如，单个块中有多个保存点吩咐）。(留意：每个关键点在每个场景中必需唯一，否则加载将无法正常进行) 保存历史：保存历史记录包含从前记录的保存点列表，按时间依次存储。执行“保存点”吩咐时，将创建一个新的“保存点”并将其附加到“保存历史记录”中。要在运行时可视化“保存历史记录”，请在层次结构中绽开“保存菜单”对象，选择“保存菜单”>“面板”>“调试视图”并启用嬉戏对象
22、。保存历史记录中的保存点摘要将显示在文本窗口中。加载按钮：按下“加载”按钮将使从前存储的JSON数据反序列化，并用于填充“保存历史记录”。然后，运用最新的保存点按以下依次复原嬉戏状态。加载存储在“保存点”中的场景（即使它是当前加载的场景）。将流程图变量复原为已保存的值：在适当的“保存点”吩咐之后，调用“保存点加载”事务处理程序并起先执行流程图。快退和快进按钮：快退和快进按钮使可以在“保存历史记录”中的“保存点”之间来回移动。每次移动都只是加载保存在“保存历史”中特定点的“保存点”。这本身不会更改“保存历史记录”或将任何内容写入长久性存储。但是，假如倒退到较早的保存点并再次起先播放，则下次执行“
23、保存点”吩咐时，它将导致时间上更远的全部保存点被永久丢弃。重新启动按钮：“重新启动”按钮清除“保存历史记录”并加载起先场景。起始场景是首次初始化“保存”菜单时处于活动状态的场景。嬉戏启动：玩家可以随时重新启动嬉戏，请遵循以下简洁规则，以确保在全部状况下都能正确处理嬉戏启动。避开运用Game Started事务处理程序。这仅在第一次玩嬉戏时正确运行，而不是在加载保存的嬉戏后才能正常运行。加载保存的嬉戏后，希望执行从保存点起先，而不是再次从流程图的开头起先。当要在加载特定保存点时执行块时，请运用“保存点加载”事务处理程序。这些事务处理程序会在“保存点”吩咐复原执行之前被调用，因此它使有机会在嬉戏玩
24、法复原之前进行设置工作。当起先一个新嬉戏时，Fungus会找寻一个启用了Is Start Point属性的Save Point吩咐并执行它。加载以前保存的嬉戏时，Fungus会从相关的“保存点”吩咐起先执行，并忽视起点。这意味着，假如的嬉戏支持保存，那么在每个场景中，都应当始终只启用一个“保存点”吩咐，并启用“起先点”属性。留意：“嬉戏启动”事务处理程序将同时针对新嬉戏和已加载的嬉戏触发，这通常不是想要的，因此请避开在支持保存的嬉戏中运用它。当保存的嬉戏加载完毕时，通常须要做一些额外的工作，以确保场景处于正确的状态。例如，可能须要将相机移动到嬉戏中此时适当的位置或播放的特定音乐曲目。一种简洁的
25、方法是通过“保存点加载”事务处理程序。图1-2 Flowchart界面 在示例场景中，在流程图中选择“播放音乐1”块，然后查看其具有保存点加载事务处理程序。当加载“保存点键”列表中的任何保存点时，这将执行“块”。在这种状况下，我们只是为嬉戏的这一部分播放正确的音乐，但是可以在此处进行任何须要的设置。当执行匹配的“保存点”吩咐时（假如启用了“火灾事务”属性），也会触发“已加载保存点”事务处理程序。这使可以将全部场景设置吩咐放置在一个共享的块中，当首次到达“保存点”吩咐或在该“保存点”加载从前保存的嬉戏时，将调用该块。保存流程图变量：每个保存点都可以在该时间点存储流程图变量的状态。可以运用保存数据
26、对象来使保存系统知道要在其中包括哪些流程图。请留意，目前仅保存Boolean，Integer，Float和String变量。在示例场景中，可以在层次结构窗口的根书目中看到“保存数据”对象。Flowcharts属性包含要在此场景中保存的Flowchart对象的列表。要将“保存数据”对象添加到场景中，请选择“工具”>“Fungus”>“创建”>“保存数据”。可以在列表中添加随意多个流程图，但请确保每个流程图都有唯一的名称（例如，流程图1，流程图2等），否则加载将无法正常进行。假如扩展保存系统以支持保存其他类型的数据（除了Flowchart变量），则可以修改SaveData组件或将
27、其子类化以实现此目的。 其次章 需求分析与总体设计 2.1 故事向的解密嬉戏的需求分析 2.1.1 玩家需求分析 解密嬉戏作为一种硬核的流行嬉戏，它根据肯定的逻辑或数学，物理，化学，甚至有着一套独特的系统规则，经过一番思索和推理来完成某些任务，考验玩家的学问和科学的综合运用逻辑推理实力。目前市场上的解密嬉戏层出不穷，大多数都是赐予既定的各种道具和场景的方式设置谜题，一成不变的解谜手段和缺乏新意的场景设置使得用户对解谜类嬉戏慢慢失去了爱好，使得该类嬉戏的开发逐步停滞。 2.1.2 功能需求分析 综合上述内容，将本文探讨研发的嬉戏功能大致划分为如下几个模块。 图2-1 功能模块图 （1）剧情设计：
28、以浦岛太郎的童话故事为主题进行改编，原故事结局是浦岛太郎打开玉匣，最终变成了一个老头子，单调而且具有漏洞。而本嬉戏将会一改原故事的结局，并且添加更多不同的故事结局，使嬉戏过程更加扑所迷离，而且还会加入隐藏剧情增加嬉戏的趣味性，使得嬉戏更具有故事性。 （2）模型动作：运用建模工具（3DS MAX）中对人物模型进行搭建或者进行修改，并导入到嬉戏之中，并在嬉戏当中添加一些人物动作和物品特效，以让玩家更加适应嬉戏特色。（3）场景设计：以海洋和陆地作为两大主场景，用3DS MAX搭建好海洋和陆地上所需的物体，然后将物体模型搭建成所须要的场景，尽可能做出一个浦岛太郎的世界观的环境，并且尽可能做到不违和、少
29、穿模的地步。（4）音乐与音效设计：通过不同的音乐和音效凸显出故事情节的改变和穿越到不同场景的效果，让玩家有特别事务和场景切换的感觉。（5）AI设计：通过设计出不同行为、不同实力的NPC，来让玩家辨别出哪一些是基础NPC，哪一些是特别NPC，然后触发特别事务。（6）UI设计：在嬉戏当中加入适当数量以及类型的UI字幕，同时给玩家制作显明的嬉戏UI，实现 UI 的交互、链接以及隐现，便利玩家探究。 （7）动画设计：在某一些情节中，运用Unity内置的TimeLine制作出相应的剧情动画，补充了嬉戏的故事，同时也达到引导玩家的目的。 2.2 嬉戏的总体方案设计 2.2.1嬉戏结构方案设计 考虑到各式玩
30、家与各类嬉戏接触的时间不尽相同，为了使玩家们都能够对本文嬉戏快速上手，嬉戏的大体结构不能太过于困难。所以该嬉戏选用了大多数电子嬉戏的结合进行设计。结构详情如下图2-2所示。 图2-2 嬉戏流程图 2.2.2 总体结构方案设计 本电子嬉戏总体模块的构架如下图2-3所示。 图2-3 总体结构模块架构图 本项目的总体结构模块主要分为三大模块。（1）人机交互模块：起先界面、设置界面以及嬉戏交互界面这三大界面作为主要的界面交互的方式，这三个界面将会运用Unity3D引擎中的UGUIUI系统模块、C#脚本编辑模块与fungus对话系统进行开发。运用C#脚本进行对玩家的操作进行监视，并运用相对应的UI界面进
31、行反馈，告知玩家所进行的操作会对嬉戏产生怎么样的改变，为此来设计这三大嬉戏界面。（2）嬉戏场景模块：此模块主要分为两大板块海边场景和海底场景。海边场景为起先部分与最终解密部分的主要场景；海底场景为发展部分的主要场景，可通过与不同人的沟通和探究场景了解一些线索。（3）剧情模块：剧情模块包括开局、发展、高潮三个部分。开局部分将会影响玩家是否前往龙宫的结局，发展部分为玩家探究海底龙宫的部分，高潮部分为玩家返回地面后进行最终解密的部分，将揭示浦岛太郎的最终结局的部分。 第三章 嬉戏具体设计与实现 3.1人机交互模块 3.1.1 起先界面 本电子嬉戏的起先界面采纳的特性出于以下三点进行考虑： （1） 简
32、约性：因为本嬉戏是一个故事向的解密嬉戏，在嬉戏起先界面不须要过于困难的界面进行表现嬉戏的趣味性，应当以通俗易懂、简洁明白的形式来创建界面。 （2） 明确性：嬉戏剧情是以海洋和陆地两大主场景中进行嬉戏，全部嬉戏起先界面，运用了海岛和海平面作为嬉戏起先界面，既展示了美观性，也表明白本嬉戏的场景有哪一部分。（3） 交互性：在起先界面插入一段音乐，提前有着良好的心态进行嬉戏，让玩家有良好的交互反馈。起先界面中的选项加入一个“嬉戏说明”，来让玩家了解浦岛太郎的原故事情节，然后将玩家误以为只是一般的浦岛太郎的故事，然后发觉故事剧情会出乎玩家的意料，然后刺激玩家的游玩冲动。 用 Unity3D 引擎自带的
33、UGUI 来进行 GUI 的制作，缘由是因为本次嬉戏的 GUI 需求量并不繁杂，运用 UGUI 足以支持这简约的 GUI 设计开发。用Audio系统中AudioSource对象里面的AudioSource组件中的AudioClip存储音乐和音效。 图3-1 起先界面 3.1.2 设置界面 本项目的设置界面目前添加了音乐与音效的功能，让玩家对嬉戏内的音乐与音效进行调整，采纳羊皮纸的材质作为设置界面的背景，突出故事的古老性，如有须要将会在后续开发中加入相对应的功能。 图3-2 设置界面 3.1.3 嬉戏交互界面 玩家通过某些按下按钮或者点击人物与嬉戏中的NPC进行交互与对话，或者查看某件道具的描述
34、与用途，从而将补充嬉戏内的剧情以及降低嬉戏的难度，增加嬉戏的可玩性与趣味性，让玩家更好的理解嬉戏剧情和合理地运用道具。 图3-3 人物对话 3.2 嬉戏场景模块 3.2.1 海边场景 浦岛太郎是一个生活在海边的一个渔夫，他生活的地点应当为一个海边的场景，身边有着渔夫所须要的生活工具，身处海边场景的时候，有时候传来一阵阵的海鸥的叫声，加强玩家的代入感，让玩家理所应当地认为自己是一个普一般通的渔夫，应当平平凡凡地度过一生，直到他救了一个被孩子们欺压的海龟，他的人生轨迹突然出现了改变。（图3-4） 图3-4 海边小屋 3.2.2 海底场景 在浦岛太郎救了海龟后的几天，海龟为了来感谢浦岛太郎，带他前往
35、海底龙宫的情节，玩家由此进入了海底龙宫的场景，他遇到了龙宫乙姬，并在受到龙宫乙姬的盛情邀请下，在海底龙宫住下了，也由此起先了玩家的主线剧情，玩家通过在龙宫的生活，发觉了各种隐私或者意外，也经验了各种奇异的事情，破解了各种谜题和机关。（图3-5） 图3-5 海底世界 3.3剧情模块 3.3.1开局 玩家的设定是一个生活在海边的一个渔夫，他的名字叫做浦岛太郎，浦岛太郎到海边去打鱼。当他走到海边的时候，发觉一只搁浅的大海龟正在被一群淘气的小孩子欺压。浦岛太郎就用钱劝走这群顽皮的孩子，救下了这只大海龟，并带他到海边，并对它说：“你赶快回海里去吧！当心不要再被别人捉到了唷！”，正是因为他这个行为，他的人
36、生轨迹突然出现了改变。3.3.2发展 在浦岛太郎救了海龟后的几天，浦岛太郎海边捕鱼的同时，那只被救的大海龟跑到了他的跟前。海龟为了来感谢浦岛太郎，带他前往漂亮的海底龙宫，以答谢他的恩情。浦岛太郎回答说“我担忧还在家中的母亲”，但是海龟说会送他回来，浦岛太郎也接受了海龟的邀请前往了海底龙宫，浦岛太郎在感叹海底的景色的同时，也到达了龙宫。再然后他遇到了龙宫的主子乙姬，她正在龙宫的门口等待着浦岛太郎，并为表感谢他救下了海龟，希望浦岛太郎在龙宫住下，浦岛太郎不好推脱在海底龙宫住下了，起先了玩家的主线剧情，玩家通过在龙宫的生活，发觉了各种隐私或者意外，也经验了各种奇异的事情，破解了各种谜题和机关。3.3
37、.3高潮 高潮一：玩家在龙宫不觉得已经过了几天，浦岛太郎起先想家了。他突然担忧起了家中的状况，浦岛太郎就对龙宫乙姬说：“乙姬公主，我想我是时候该回家了。”在龙宫乙姬的一再劝阻下，浦岛太郎决意离开龙宫，龙宫乙姬确定送个他一个玉匣，并且警告在他年老之前肯定不能打开它。浦岛太郎再次骑到海龟的背上，回到思恋已久的家乡。但是，他发觉村子的景象和来时的景象完全不同了。到处都是生疏人，没有一个熟人；而且，不管浦岛太郎再怎么找，就是找不到自己的家，和年老的母亲。浦岛太郎问一位坐在路旁的老公公：“你知道浦岛太郎的房子在哪里吗？”老公公回答“啊！我曾经听过关于浦岛太郎的传闻，不过，自从三百年前他去了龙宫之后，就再
38、也没有回到村子了。”“已经过了三百年了，那么我的母亲也早就去世了。”浦岛太郎消沉地坐在路旁的石头上。这时候，他突然想起了手上拿着龙宫乙姬送给他的王匣子。“里面究竟装了什么东西呢？”浦岛太郎遗忘了龙王公主的叮嘱，把玉匣子的盖子打开了。突然间，里面冒出了白色的烟幕。更惊奇的是，当白烟遇到浦岛太郎的时候，他一下子就变成一个满头白头发的老公公了。高潮二：浦岛太郎没有打开玉匣，他通过发觉一些不寻常的线索，发觉事情跟龙宫有着莫大的联系，然后他通过一些方法回到了龙宫，然后他发觉了事情的缘由，并且让海面上复原了原有的状态了。3.4 关卡模块 由于本项目为解密向嬉戏，可分为主线剧情和支线剧情，主线剧情须要层层相
39、扣，环环相接才能进行下去，但是由于选项的不同，可能触发的剧情会有所不同，产生的结局也会有所不同。玩家所选的选项不同，接下来走的路途就会越加困难，产生的结果也会越多。3.4.1 迷宫 迷宫的结构实现了最为经典的关卡设计与嬉戏的心理学，通过在地牢的各个地点配置不同的怪物与宝箱。玩家在绕到什么地方的时候会遇到一条死路，在到处撞壁，放弃希望之时，却发觉另一条岔路柳暗花明，得到了特别线索和道具，或是一个隐藏的储存点。这点在甚至在早期的FPS里也被用得滚蛋烂熟。Doom的关卡就是这么干的。迷宫的地形设计以3DSMax三维动画渲染和制作软件进行制作与上色，如图3-6。图3-6 迷宫设计图 3.4.2 密码锁
40、 须要玩家通过与一些NPC对话，得到密码锁和密码纸条的两个地点，然后到达地点之后，找到开启密码锁的密码纸条，通过纸条上的密码进行解锁，得到箱子或者门后的道具和开关。密码锁的解锁方式运用Fungus对话系统进行开发，可以以少量的代码进行完成，削减Bug的产生，也简化了流程。通过4个Button和Text组成密码锁的结构，并将这个四个Button和Text设置成预制体，以便利统一修改Button和Text的格式。通过绑定按钮A(Button)以获得修改按钮A的子节点数字A，并将触发事务改为ButtonClick，并设置变量“数值”，每点击一次“按钮A”，变量“数值”将增加1，“数字A”同时也增加1
41、，并加入推断语句：数值大于9，数值将会归零。（图3-7） 图3-7 密码锁的“加1”逻辑块 要让密码的四个数值发生改变，添加4个Block块，并绑定按钮ABCD，同时调用（Call）“加1”Block块，设置四个变量“数字A”、“数字B”、“数字C”、“数字D”，如当按钮B被点击时，数值获得数字B的值，执行“加1”block块，数值加1，再加以限制（Wait Until Finished）等待“加1”执行完成，才能进入下一步，否则简单出现数值未加1，但已经执行下一步的状况，导致数字没有改变的Bug。接着变量“数字B”获得“数值”的值，为了可视化变量“数字B”的值，将赋值到Text“数字B”的值
42、。（图3-8） 图3-8 密码锁Block的调用 在“检查密码”块上添加4个if语句进行推断，当4个Button上的Text数字与if语句上的数字相同时，密码锁将会被解开；通过将四个Button的Block块调用“检查密码”块上的IF语句，每一次按钮的点击事务都会进行密码检查，以检验密码是否正确。图3-9 密码锁最终流程图 3.4.3 移动的平台 玩家须要通过角色的移动和跳动通过一些移动的平台，已获得一些必要的道具和线索，有时候须要一些解密才能够完成。3.4.4 暗门 隐藏在某一个房间里面的暗门，须要通过NPC的对话或者玩家探究地形后发觉，开启的时候将会弹出对话框来告知玩家“某处的暗门已被打开
43、”，已让玩家获得良好的视觉反馈。（图3-10） 图3-10 暗门开启 3.4.5 拼图 获得某一些道具时，所须要完成的一个解密小嬉戏，主要通过C#脚本进行编写，其核心代码如下图所示，通过if语句推断点击位置的图片是否能够移动，假如能够移动，就获得空白图片的对象，然后将空白对象存储成被点击对象的图片，然后进行空白对象的实际运用图片替换，再将点击对象的存储图片清除，然后事实上的图片也清除，这样每次替换就不须要重新拿图片了，节约内存、提升性能。void OnClickEvent(Item item) if (canMovie(item) /推断点击位置的图片是否能够移动 var t = NoneIm
44、age(); /获得空白图片对象 t._sprite = item._sprite; /将空白对象存储的图片替换 t._Obj.GetComponent<Image>().sprite = item._Obj.GetComponent<Image>().sprite; /将空白对象的实际运用图片替换 item._sprite = null; /点击对象存储的图片为空 item._Obj.GetComponent<Image>().sprite = null; /点击的对象的实际运用图片为空 if (Success() /推断是否拼图胜利 Debug.Log(
45、“成功“); 3.5 Fungus对话系统 本项目由于是解密嬉戏，主要通过人物之间的对话和物品的介绍进行剧情的补充，Fungus可以通过直观的视觉脚本系统轻松地将叙事功能添加到Unity嬉戏中，而无需编写过多冗余的代码。适用于制作视觉小说，RPG，隐藏对象，益智和互动小说嬉戏。基于流程图的角色对话将角色对话的国际化。能够轻松限制子画面，摄像机和音频以帮助讲解并描述的故事，适用于2D和3D Unity嬉戏，易于与其他Unity代码集成，并且易于扩展。3.5.1 实现原理 Fungus对话框SayDialog如下图所示，由Unity自带的UI系统中一个Panel父节点，NameText、Image
46、、StoryText子节点组成。被FlowChart窗体中的Block块中Say脚本调用，以进行对话系统中的对话框的模板进行显示，开发者可通过创建一个SayDialog来更换对话框的格式、位置和图片。 图3-11 Fungus对话框原理 SayDialog对话框主要运用到Say Dialog这个脚本为主要脚本，通过FadeDuration来限制图 中CanvasGroup中的Alpha来进行对话框的显示与消逝，FadeDuration数值越大，Alpha值的增长速度就越慢，对话框的显示/消逝就越慢。所以一般选用0.25的默认值即可。 通过SayDialog脚本中的绑定NameText、Imag
47、e、StoryText子节点中的各个组件，其中NameText将会调用右图的character脚本语言中的NameText值和NameColor作为角色名字和名字颜色进行显示，头像以右图下方的Portraits的elementNum进行添加，Size为头像的数量；而每一个Character脚本又会被Block块调用，形成多角色选择的选项，以让开发者进行角色选择对话，通过Command中的Say对象脚本中进行选择Character和相对应的Portrait来显示角色名字和角色头像。（图3-12和图3-13） StoryText则是通过Block块中的Say对象脚本中的StoryText进行值传递
48、，格式与位置将会依据绑定的StoryText子节点来确定。图3-12 SayDialog对话框脚本（左）与Character脚本（右） 图3-13 Block块 3.5.2实现结果 依据3.5.1的分析出的试验原理，对Fungus默认的对话框进行修改，优化了角色名字的字体格式，更换了对话框的背景图片，添加了人物的头像以便分析，结果如图3-14所示。图3-14 对话框的修改 第四章 嬉戏测试 嬉戏质量的好坏关系不仅影响用户的体验，也影响开发商利润的凹凸，所以做好嬉戏测试是必要的，因此在嬉戏必需满意肯定的质量标准才能进行发行。本章节用于测试的计算机硬件环境以及软件环境于下表 5-1 所示。 表5-1测试环境