独立游戏《面包女神》开发日志-2-任务系统与佣兵大厅

前言

    任务系统可以帮助玩家更快了解游戏玩法，并指引玩家对游戏进行探索。一般来说，如果游戏本身核心玩法足够丰富，是不需要任务系统去帮助玩家的。当然，如果开发者想要讲一些深入的故事或者哲理，那就另当别论了。

（有任务还是无任务？）

    回到本游戏，我需不需要用任务系统来帮助玩家理解和探索游戏呢，答案我觉得是需要的。对于一款类骑砍的游戏来说，领主基于自身利益会发布各种进攻、破坏和掠夺任务，城镇里的各种商铺会不定时地需要各种物资，假如村庄周边出现了野兽、魔物或者强盗，村民们会希望有人前去清缴等等，这些任务可以生动地表现一个充满魔幻和史诗色彩的世界，这对我来说是很有吸引力的。

（骑砍的经典任务-《送信》和《抓逃犯》）

基础规则

    本游戏的任务除了主线任务之外，主要分为两种方式，人物任务和佣兵大厅任务。其中人物任务类似于骑砍的任务系统，主要是从NPC那里接取和提交，完成后可以获得物品以及对方的好感，能够发布任务的npc包括各个势力的君主，领主，以及酒馆里面的英雄和世界地图上的冒险队等等。

（任务类型）

    另一种接取方式主要是通过类似中世纪佣兵工会的建筑里领取。这里的任务每周都会刷新，默认情况下会刷新一些为城镇其他建筑提供物资的任务，当城镇周围出现怪物时，这里也会刷新一些狩猎任务，委托玩家前去消灭怪物。

遇到的难点

    基于以上设计思路，由于除了主线会需要固定地道具，或者击败的部队之外，大部分任务的任务目标或者任务奖励都是不固定的，所以我用了一个专门的数据结构来存储任务的这些信息，在生成任务的时候对任务的进行随机化处理。

（任务种类）

    接着就是一个问题，任务的数据放哪儿？一开始我将任务放在了部队身上，因为玩家的基本实体就是一支部队，但这会带来一个问题，因为建筑的数据是没有特征化的，即建筑存储的数据是最基础的整型数据，那么佣兵大厅中刷新的任务怎么存储？因为不想在建筑数据类里添加任务的存储结构（那样会变成打补丁式的开发），最初我打算在建筑每周更新时，基于佣兵大厅的建筑种类对其整型存储数据进行更新，但这样一来用于存储的数据的编译会更复杂，还搞一套部队的任务实例和建筑存储数据的转化，惹出一大堆麻烦的东西。

    最终，我采用了一种扁平化的思路，将任务数据从部队中摘出来，放到世界中（世界表示债多不压身了），所有任务在创建时会生成一个唯一索引，而部队和佣兵大厅只存储该任务的索引，在方便了任务查询的同时，也不用去考虑任务在各个对象之间转化的关系（例如部队从佣兵大厅接取了任务，只需要将其索引转移即可）。

（世界数据中加入了任务数据）

（任务存储结构）

任务表现

    实现的方法处理好了，剩下就是表现层面的东西，限于篇幅，这里就直接放一些实机截图：

    任务列表和佣兵大厅，用了类似的布局，其实最好的做法是将佣兵大厅用一张原画描绘出大厅的背景，像日式游戏那样，但是因为我们没原画，所以先暂时用类似布局简单处理，后面有了足够预算了再去优化。

    满足条件的目标会高亮显示，这些都是很常规的任务系统的设计，而且项目开发阶段，这里的做法更加简化，连图标都省了。

    需要提交到城镇建筑的任务，会在对应建筑信息处显示，这个按钮还做了一个呼吸动画。

    有一个专门的任务提交界面，同样也是常规做法。