我的任务系统设计方法

lihai9917

饿 感觉是第三、四步要做的东西

卡特铁角

lihai9917: Re:我的任务系统设计方法

饿 感觉是第三、四步要做的东西

我也饿啊...

你感觉的一、二步应该做什么？

storm1986

期待LZ的MMAP图，千万不要放鸽子啊～～

ЦcμpracaciΛ

脑子里先有这么个架构...

随便说说别咬我...

lihai9917

卡特铁角: Re: Re:我的任务系统设计方法


我也饿啊...

你感觉的一、二步应该做什么？

以下只是我个人的理解，欢迎拍砖！
第一步背景剧情分析、框架搭建
第二步任务分类、资源整合
你说的那些东西肯定有，但我觉得应该是辅助分析，不应该是消耗主要精力的，就像背景一样。诚然，现实中人们都喜欢有一个目标，然后不断重复的去完成，不过人们更喜欢不断遇到新的挑战，这就要求策划们把主要精力放在任务的模式、内容、完成方法和奖励设置上，而不是放在不顾一切的延长时间去赚钱上，要不很容易就画蛇添足。任务本身除了介绍背景故事以外还有很多属性，比如是除了打怪以外，升级获得装备的另一条途径，或者是接触和继续其他非主要玩法的途径等。。。总之，我觉得楼主说的这些东西一定要知道，但不能以其为主。当然，拼凑或者换皮游戏就没的说了。

[em15]

Susaro

lihai9917: Re: Re: Re:我的任务系统设计方法


以下只是我个人的理解，欢迎拍砖！
第一步背景剧情分析、框架搭建
第二步任务分类、资源整合
你说的那...

LZ所讲的是一种任务设计时的方法——将任务功能在一个所属的范围内所能做的所有事尽量全部列出来，然后按照一定组合规则进行拆分和合并同类项，最后根据已拆分和合并的内容制定实现这些功能的方法，这些方法一旦确立，即可交付程序进行开发。
此时，任务系统的功能是否完善，则取决于列举是否详细，拆分是否合理，同类项合并是不是兼顾了扩展性。
这种方法和“面向对象”的方法非常相似，且游戏也属于软件范畴，所以个人观点支持这种做法。论坛上前一阵子有一篇《“疯策”的面向对象式？？》文章，和此篇是相得益彰。
诚然，这种方法好象只考虑了游戏的“软件性质”，忽略了游戏的其他特性。其实是可以满足其他要求的——将LS的方法嵌于该方法的拆分和合并同类项阶段，即可满足。
另外，这种方法肯定会导致策划所预想的“自由丰富的任务系统”受限。但首先，“自由与丰富”本身就是相对的，相对于“软件”这个东西就只能是有限的自由；次之，这种方法其实远比“想到什么就要什么式”任务系统所付出的代价低，而获取的收益大，这个代价，涵盖了时间、人力、资金和管理等等。

PS：LZ和疯策都有程序背景。

卡特铁角

我是觉得用什么样的剧情，又怎么样让玩家不断遇到他们喜欢的“新挑战”这一类的问题（而且对于新鲜感的问题，在我的目标分解过程中也有体现），都是在设计宗旨下才成立的——都可以由你的设计宗旨来确定，毕竟这些都应该为设计宗旨服务，这样才不会出现“为了设计而设计”的情况。

只有明确了你的设计宗旨，才能明确你设计中要达到的各个子目标，才能最终确定你的系统需要哪些功能。

另外，我以前也和其他人讨论过剧情的重要性——我的结论是无论你设计什么样的剧情，最终的剧情只存在于玩家的想像中。所以，我认为不应该从剧情出发进行目标分解，因为这个东西的也只有在满足设计宗旨时才显得有意义。

卡特铁角

Susaro: Re:我的任务系统设计方法


LZ所讲的是一种任务设计时的方法——将任务功能在一个所属的范围内所能做的所有事尽量全部列出来，然后按...

面向对象设计，是由模块化设计发展而来。

其实在我看来，软件行业中的OO思想其实是一设计理念上的回归。进入工业时代以来，传统机械制造行业中的工作方式其实就是面向对象了——组成一台机器的零件，也可以看作是我们说的对象了——这些零件都具有很高的重用性，功能也都相对独立。当这些零件（对象）的规格固定下来。当我制造一台新机器时，一般就不需要再重新设计专用螺丝螺母之类的零件。

se7en

还好我们公司没有这种策划，不然我非得让Y走人。写的东西程序一点也不明白 ＝＝ 没用！

卡特铁角

se7en: Re:我的任务系统设计方法

还好我们公司没有这种策划，不然我非得让Y走人。写的东西程序一点也不明白 ＝＝ 没用！

再重申一次——这个贴不是给说怎么写给程序看的文档，而是说如何确定你所要设计的这个系统需要有哪些功能——这是设计的第一步。请勿张冠李戴！