游戏任务剧情布局系统分析

游戏任务剧情布局系统分析：

　　任务系统分主线任务、日常任务和悬赏任务：

主线任务的特点：“所有任务分成N条主线，每条主线上一个任务完成了，即使不领奖也可以完成下一个任务，每条线没有尽头”；

日常任务的特点：“每天0点重置，共有N个任务，完成一个则可领奖，领奖后此任务消失”；

悬赏任务的特点：比较复杂“每天有3次刷新机会，每次刷新出5个任务，任务完成领奖后消失。任务分1-5星，生星规则根据主角等级和星级概率动态生成。”；

刚开始做的时候打算用一个统一的类包装所有的任务，对外提供生成任务和任务领奖的接口就行了，结果做完之后发现这三种任务的不同点多于共同点，放在一个类里面用三种结构处理，还是得用类型区分的，倒不如分开处理更直接。

实际上这三类任务除了“生成任务”和“更新任务状态”、“完成任务领奖”这三个共同接口，其他操作完全没有关系。如果继承也只能继承自一个抽象类，而这个抽象类不能覆盖对外的全部接口（比如“刷新任务”只有悬赏任务才有），所以我决定把这三个类完全独立开，包括协议、存储、实现。他们共有的逻辑是任务完成的条件，以及对完成条件的检查。

　　“任务完成条件”是譬如“杀死n只独角兽”、“收集n个x物品”、“通关第x关卡”之类的判定条件。稍作总结就发现其本质就是对某种特定事件的计数，像“等级到达20级”就是对级别的计数，或者是“等级到达20级1次”这个事件的计数，由于等级、关卡这种主要计数都是已经存在的，就不必单独计数了，直接拿过来判断即可。当时对任务完成条件的计数如何存储如何更新有过激烈的思想斗争，我大概想过这些方案：

a)方案一：每个任务完成条件是一个对象，这个对象接收输入（玩家的指针或数据），输出完成结果。在配表的时候把所有任务的完成条件都预先初始化完毕，运行时传入玩家指针判断是否完成此任务。这样做有2个缺点，1任务完成条件不是按任务完成条件类型分的，而是按实现一一初始化的，导致内存浪费。2由于无法预先知道有多少对象，需要动态分配内存。

b)方案二：每个任务完成条件是一个函数，这个函数是按任务完成条件的类型分的，所以函数个数是固定的。还有一个分配器，负责运行时根据任务ID去配置表取完成条件，从完成条件里面取出类型，再根据类型找处理函数，把配置的参数和玩家指针传入，输出完成结果。优点是节省了内存，简化了实现。缺点是每次要去配表找完成条件的参数。

c)方案三：任务完成条件按照类型分为N个函数，每日任务记录5个计数值，悬赏任务记录5个计数值，主线任务记录10个计数值。任务完成领奖的时候，判断是否完成，比较计数值和配表值。

d)方案四：目前的做法。任务完成条件是用于判定的数据，作为任务的一个属性。在所有任务完成动作的地方触发计数，客户端请求任务状态的时候，服务器遍历任务完成条件，设置完成状态判定是否完成。

　　最后一个方案就是目前的做法，相当于把任务完成条件作为每个任务的一个附加数据项（一个任务可能有多个完成条件），任务完成条件作为一个结构存在：{完成类型，参数1，参数2，...}。一旦生成了一个任务（生成了就等于接收了任务），这个任务就按照配表初始化自己的任务完成条件。

　　剩下的问题就是：每个任务的计数在哪里更新？我曾想过既然某个任务完成条件存在，必然要依赖其他逻辑模块计数，如果其他模块把我要计数的值都给我记着，我拿过来用不就行了？但是我想到了一个坑，悬赏任务的坑：不能在每个逻辑模块对要计数的变量计数，比如两个悬赏任务都是强化武器，一个30次一个40次，就有两个计数，逻辑模块不知道有几个计数。So，计数只能放在每个任务单元中，其他逻辑模块引用计数变量的地址计数。

　　问题又来了，我想要的计数，其他模块未必直接提供给我了。比如通过第3关2次，显然我既不能要求关卡模块给我这个接口，也不能要求他在第三关的时候调用我的接口，只能是在通过每一关的时候调用我的一个“和通关有关”的接口，然后把第3关作为参数传给我。另外，我可能同时有多个任务都和通关有关，于是我的任务系统和关卡系统之间需要一个适配器来协调，适配器知道我哪些任务和通关有关，然后提供一个统一的接口给关卡系统调用，当通关的时候，适配器把所有和通关有关的任务计数更新。那么，任务系统和任务完成适配器之间要怎么配合呢？显然，生成任务的时候，要把任务通知给适配器，适配器给我按完成条件归类；完成任务的时候，要通知适配器检查是否已经完成任务，如果完成就删除这个任务的计数。

　　我画了一个示意图，用来表示这个静态结构关系：

第一层是任务id和任务单元的一个map表，

第二层是每个任务单元的实体list，

第三层是任务完成条件的管理器，也就是那个和其他模块配合的适配器，里面维护着多个链表，每个链表代表一种完成条件A，每个链表存储着某个任务的id和这个任务的完成条件(属于A类型的完成条件)，存id是为了删除的时候方便。

途中的每个方块代表一个任务完成条件的结构，每个任务单元有多个完成条件，每种完成条件类型对应一种颜色。

　　如此，就解决了整个任务的生成-计数-完成-删除的生命周期管理。

目前的方案不足的地方就是：如果要增加一种完成条件，就要在适配器中增加对应的代码。

理想的情况是无论完成条件是什么，也只不过是一种类型和参数的组合，我只需要根据类型给他指定计数方案（就是在任务完成条件适配器中的位置），无需增加代码就能被归类管理起来。当然，前提是适配器与其他模块的接口稳定且健全，新增的功能是必然要增加接口的。

游戏任务剧情布局系统分析相关推荐

游戏官网的HTML布局,游戏网站页面布局关键
现在,越来越多的人想要建立自己的网站.这无疑是一件好事,但是,很多设计师,尤其是新手设计师或者压根儿就不是设计师的小白,都在网页设计上走过不少弯路. 网页制作中网页布局相当重要,先布局,后细节,只有在 ...
5g云游戏的战略布局
5g和云计算作为与电力一样的生产力要素,正在与各行业融合,成为重构产业价值链的重要因素. 随着5g的逐渐成熟和商业化应用,云游戏的最后一块技术基石已经被填满.云游戏也有望成为首个在5g应用中脱颖而出的 ...
从莉莉丝游戏的战略布局与设计角度，探究《剑与远征》的火爆原因
莉莉丝游戏:"全球化"的蜕变之路相信每一个曾经沉迷于<刀塔传奇>(后更名为<小冰冰传奇>)的玩家,对"莉莉丝游戏"(以下简称莉莉丝)这 ...
Flex游戏学习Flex布局
本文为游玩Play Flex时顺手写的,目的为省去以后想回顾下再玩游戏的时间. 游戏地址:Games | Coding Fantasy 目录故事背景: 概念引入: 游戏介绍: 关卡 Justify- ...
【Pygame小游戏】剧情流推荐：什么样的游戏剧情能获得大家的喜爱？（决战紫禁之巅）
前言哈喽!大家好,我是栗子同学. 剧情是游戏的核心要素,也是游戏沉浸感的主要来源之一. 不论是何种类型游戏,不论其是否以剧情为主要玩点,优秀的剧情总能让一款游戏大放异彩. 我发现
了解RPG游戏中剧情播放器的制作原理及流程
http://www.iamsevent.com/post/44.html 本章源码下载:http://www.iamsevent.com/zb_users/UPLOAD/dramaPlayer/My ...
【Pygame小游戏】剧情流推荐：什么样的游戏才能获得大家的喜欢呢？（魔鬼恋人、霸总娇妻版）
前言
游戏剧情哪家强？日式RPG与欧美沙盒的优劣
来自GameRes:http://www.gameres.com/692729.html 文/无垢之黑冢此前,笔者曾对"日式RPG(角色扮演游戏)现状"进行过一番并不成熟的评析, ...
浅谈2D游戏设计模式--游戏剧情设计（1）
博主不才,人生有2大爱好,写程序和玩游戏,本人玩的又是一款2D的在旁人看来弱智的网络游戏. 这款游戏在中国的名称叫做冒险岛,不知道园子里有没有人玩过. 我打算有空的话,就把我玩游戏中的心得和程序结合起 ...

游戏任务剧情布局系统分析

游戏任务剧情布局系统分析相关推荐

最新文章

热门文章