单机模拟经营游戏制作过程中如何保证作品对玩家有持续的激励?

问题的根本这个问题确实存在于很多蹩脚的经营类游戏当中,并且通常到这个阶段,也就放弃游戏了,要是觉得还有点意思就是新开一关了,没意思就关闭游戏再也不开了。光靠调数值或者硬加机制很难解决好这个问题,所以从设计之初就必须决定好一个思路。所以,设计师一开始就得明白——游戏就是制造一系列知识(性质)和问题,让玩家去解决的东西,越少的现实知识(现实知识策划应该掌握并且翻译成不需要现实知识的元素,下文会有详细提到),越是看着简单的问题,就越好玩。这个游戏设计之道是所有游戏的根,接下来才是模拟经营类SLG如何设计的关键。玩家所处的视角宏度这里引入一个概念“视角宏度”,所谓的“视角宏度”,你可以简单的理解为“当前所处的境地索要解决的问题”,如果跟现实类比,嗯……可以说是“屁股决定脑袋”。有注意到“当前所处境地”和“要解决的问题”了吗?前者是“知识”或者说是“性质”,这当中包含了玩家在这个阶段因为处境而经常会接触的一些游戏设定,以及因为当前能力可以做的事情;后者则是游戏的核心玩点。到这里,不难看出,视角宏度是一个模拟经营SLG游戏玩家阶段的分水岭,每一个阶段玩家都应该处于一个不同的视角宏度,以不同的“知识面”来应对“新的问题”。举一些简单的例子来说明视角宏度变化,他们未必是模拟经营游戏,主要是传达这样一个概念:比如在光荣的三国志系列比较RPG一点的7、8、10、13代,以及太阁都有,你一开始可能只是一介草民,一个浪人,你能做的事情非常有限,然后你入仕了开始当马前卒,这时候你可以被派遣去种田、治安,你的视角从一个无所事事但自由自在的人,变成了一个接受命令,如何努力把成果做到最高,接受表扬的上班族;然后你逐渐往上爬成了太守,这时候你的视角宏度又变大了,你要做的事情变成了治理好你的城市,不让他被敌人夺走,你还要顾及手底下每个人的状态,以及上面对你的看法,这时候你是个基层小领导的视角;再往上爬一些,你开始负责一片州的管理,你需要调度各个城市的资源把每个城市发展好,同时保证你的州地盘不缩小并且还扩大,这是一个中高管位置的都督的视角宏度……从例子中也不难看出——因为视角宏度变化了,游戏中的问题也变化了,从平民到君主要解决的问题完全不同了,但是解决问题的知识面还是没变,比如治安靠武力,你做马前卒的时候是这样,你做了都督还这样,区别在于,马前卒的时候你努力提高自己物理去治安,或者干脆武力太低不接这个买卖就好了;等到做了太守,你指派武力高的武将去干这事儿;等你做了都督,就变成你调度物理高的人给太守。你的视角宏度变了,解决问题的方式增加了,并且面临的问题也变化了——治安逐渐从对你来说100%大事儿变成了一个“我不管你怎么做的,报表漂亮就行了”的事儿。也是因为这样,所以每个阶段做的事情不一样了,就不再是重复劳动了。那光说原理没用,怎么做呢?如何设计游戏中的视角宏度值得注意的是,他并不是一件依赖于“剧情”或者“世界观”的事情——外行很容易第一时间想到:那我只要剧情设计有宏度就行了,比如足球经理,一开始做青训教练,我的目标是提拔一些牛逼孩子,到后来我升级到2队教练,目标打入职业联赛……再后来目标三冠王,管理世界顶尖球队了,虽然视角宏度变化看起来不大,但确实问题变难了——符合宏度变化的特征。但是这个想法并不好,而是要反过来,从游戏的性质出发,我玩家玩这个游戏的“一生”当中,总共能做什么事儿,然后为这些事情划个“所在视角宏度”。当然所谓“规划所在宏度”并不是说我想好了他在什么阶段,然后去凑,而是考虑一个“知识面”掌握程度,以及处理办法即可,至于在什么视角宏度,最终是玩家自己会去理解的东西。所以设计的重点落在了这些“事情”上,每个“事情”我们可以看做一个单位,比如上面举例的三国志里面去治安,就是一个事情。因为有了“事情”这个单位之后,我们随着游戏开发的过程中,就可以不断有新鲜的想法诞生,只要他们都是基于“事情”的,就能很容易的加进去,它不仅是一个设计想法的指导,而是一个设计思想。所以设计这些事情是在设计什么?这到底是什么事情?并不是一句话简单的概括“城池有治安度,派人去挂机游戏中的20天,治安就提高了,武力越高的人提高越多”——这是一句没什么价值的“人话”,每个人都能产生自己的理解,所以是人话,但因此他不具备设计意义,设计理解上的话每个人的认知是不能存在偏差的,所以你需要精确地思考(未必要描述出来给别人听):这件事情中有哪些“事情节点”或者说“细节”:比如这个治安问题,就应该是“提高城市的某个属性”什么属性?并不重要。玩家需要派遣人——谁?这就涉及到了角色的筛选规则,这时候深入思考,比如“听我话的人”,听我话的人是谁?一开始是我自己,我升官之后是我的小弟,类似这样想下去就有了一个筛选人的规则;怎样做到提高,能干些什么,干了会发生什么?“只要选他,然后就自动挂机了,数值就提高了”那提高量怎么算?哦,最终提高为f(办事人),然后平摊给每天,比如直接除以20,每天(游戏推进最小单位)+这么多。把所有带有概括性质的,人类一听就有想法的词,全部替换为一些计算机都能理解的不需要任何语文基础就能理解的说法,这就是第一步设计,这个设计产生的了一个十分严密的结果,而结果中暴露了需要依赖的参数,就可以形成一个数据结构。这件事情中的技巧(玩家智慧)何在:也可以理解为这个函数中,玩家作为参数传递之后,在函数中起到的作用,显然“治安”这件事情,玩家能起的作用几乎为0。因为完全不需要智慧,所以他不好玩,因此反复做这件事情很快就必然会腻味(这是客观的“好玩”,而不是主观的, 你总能找到猪头三说“我就喜欢这样反复点点点,你拿俺老猪怎么滴?”所以按照主观讨论,永远是浪费时间)。但比如说换成一些有操作的小游戏,就至少有了玩家操作这个环节,虽然他并不是最好的办法,但是确实无奈的办法,比如太阁系列就这么干。但实际上每件事情有智慧并不是那么好设计的,所以偶尔有些没有技巧性的事情作为内容,也是可以接受的。当然,这个玩家智慧,在不同视角宏度下也可以完全不同,甚至一开始有,后来没有也没问题,比如太阁的小游戏,后期可以不用自己去玩了,派小弟过去办事儿,智慧变成了“派谁”而不是“怎么解决”了,也是可以接受的设计。函数化看这件事情:最后把上面说的抽象为函数去看,不一定要具体实现,但你应该有一个概念在那里,比如“派谁”就有Character GetCharacterForSecurity(List candidates),从这种函数中,你就能更清晰得去看到你的玩法,需要的是什么,做了什么,到这里才是设计。这件事情需要掌握游戏的什么知识?之后就是罗列这件事情涉及的知识点,所谓的涉及,可以是引导,也可以是要求玩家先知道,但是绝对不要去定这算是引导还是利用,因为是否掌握了一个知识,或者是否能从某个行为掌握知识是因人而异的,所以是绝对主观的东西,任何设计(包含且不限于游戏设计)都无法设计主观的东西(主观的东西包括“体验”什么的,所以一听人谈设计张口就是“体验”,这人多半是个只会吹牛逼的)。还是比如“治安”这个事情,他需要的知识就是“武力值高等于效果好”,以及为什么会这样?这里就要进一步描述这个玩法如何工作的,也就是上面所说的第三步。为什么我们需要罗列知识点,这是为了我们知道他涉及的东西,以至于他大致出现在什么阶段,在设计一些数值的时候,是可能会用到这个的。举例:做一个游戏公司经营养成这里只举例游戏宏度(或者说阶段性)设计和事情的设计,不做更多具体的设计。首先可以敲定一个宏度设计因为题材确定了是游戏公司经营,或者说是一种“剧情先行”的做法,那么我们就可以直接跳入敲定宏度的时代,也就是这个游戏过程中每个阶段:2、3个人独立小团队制作人视角:这个视角下关注的是如何利用好每个人的技术专长去解决游戏开发中的技术问题,最后把游戏做出来。在这个视角下,接触到的问题更多是游戏开发中常见的一些技术问题。因为游戏设计中不应该代入任何现实知识,所以在这个环节的内容一定不能抛给玩家专业的知识,比如“如何设计一个易扩展的技能系统”,而是要把他翻译为玩家可以理解的一些问题,比如:子弹飞行轨迹出bug了,这可如何是好?第一步选择方案:A换一个算法函数,B砍掉子弹系统,C无视bug当做feature。这些选项都会影响游戏最终的成绩,但这些选项本身都不需要专业知识,凭常识就能想到结果,如果选择A,则列出3个人谁来办让玩家选择,并透露这项选择依赖的属性,比如:A猴叔(数值设计92,耐性33,正在开发任务系统) B鲁大师(数值设计87,耐性26,正在制作主界面UI) C大白马老师(数值设计67,耐性91,正在泡咖啡),玩家根据当前情况来进行选择(这里说的是视角的感觉,而非游戏真这么设计)。10-20人团队独立游戏制作人视角:这个视角会逐渐偏向于小规模工作分配,以及协力阶段,逐渐减少一些具体的内容制作工作,除非遇到恶性bug,也就是虽然会发生类似子弹bug的问题,但不会只是子弹bug这么小的事儿了,他可能是“如果采用这样的设计,就需要考虑水面要到映出角色纽扣中的水面倒影,但是我们目前技术实力不足,怎么办?”。所谓的协力问题,可以不光是指派谁谁谁去制作某一块功能,还要考虑如果这些人合作,会发生什么?比如羁绊之类的玩意儿要不要?完整团队制作人视角:完整团队的时候,制作人的视角会又一次发生变化,即更关心时间节点,因为这时候也会开始更多的关心和发行的合作、档期之类的问题。而游戏开发中的技术细枝末节等都已经委派人去解决了,人际关系也由各部门经理(组长、主策主程主美等)自行解决即可。所以视角有一次发生变化,而问题也从“如何安排好人开发出游戏”变成了“规划出更合适的产品节点,包括什么时间点、在哪儿、发布一些什么feature以至于产品成绩会更好”。多个开发团队老板视角:这时候的视角,已经从做游戏产品,变成了做公司了,如何建立生产线不断快速产出产品,抓住市场机会,以及和各个发行团队建立良好的关系是这个阶段的主视角。可以看到“如何解决某个bug”已经根本不会出现在这个阶段了。多个开发团队以及发行、运营团队老板视角:这个阶段的视角,就是要考虑如何构成完整合适的游戏产品链,直接和媒体等进行合作,来成为行业霸主了。视角已经转换成了“我如何利用资源制造档期、制造热门”而不在是“把握住机会,让产品变得更好了”。这些视角宏度的变化,是一个玩家所要经历的变化,他也是模拟了现实游戏公司的制作人的一个变化过程,这部分可以是这个模拟养成游戏的脊髓——因为每个阶段关注的焦点确实不同了,并且要解决的问题所用的技术角度也不同了,对于游戏知识也是积累的(至少我们直到最后都知道,解决bug需要靠的是开发技术高,而不是运营能力强的人),所以我们认为这个视角宏度作为切割可行,接下来就要设计游戏中能做的事情。接着是事情设计正如上面所说,“事情”其实是一个单位,所以在开发过程中可扩展,因此不需要第一时间全部完整的罗列出来,尽管事情本身关系到游戏的玩法。所以在这里我们就很简单的列个把事情做个例子:例子:开发技术选择——游戏中角色动画框架描述部分:当玩家立项要做一个动作游戏的时候(即使是开罗游戏,都有立项对吧),要且只能选择一个游戏中角色动画所用的框架,选项包括:动作状态机,Cancel机制,blablabla……。每个选项产生的结果,是后续【研发内容块】的不同,这将导致后续工作方式和成果会大有不同。进一步描述一个结构:研发内容块,是指一项研发工作转化为游戏的数据结构,它包含的主要(而非全部)数据:功能块名称:比如绑定骨骼等,是这一部分工作的名称。复杂度:int,描述这个模块开发的难度。效果算法:玩家可以安排人员去参加工作,无限个人员组成List developer。根据developer得出对于“游戏手感属性”“游戏画面流畅属性”的影响算法各一个。工作时间算法:根据developer以及复杂度属性,得出一个这个工作完成最终需要的天数(游戏最小时间单位)。可能遭遇bug算法:一个算法,得出在这个工程开发中(float 概率, BugInfo 什么类型的bug)的值,即开发中每一天都有这么高概率,碰到这么一个bug。玩家技

Jul 6, 2024 - 01:00
 0  12

问题的根本

这个问题确实存在于很多蹩脚的经营类游戏当中,并且通常到这个阶段,也就放弃游戏了,要是觉得还有点意思就是新开一关了,没意思就关闭游戏再也不开了。光靠调数值或者硬加机制很难解决好这个问题,所以从设计之初就必须决定好一个思路。

所以,设计师一开始就得明白——游戏就是制造一系列知识(性质)和问题,让玩家去解决的东西,越少的现实知识(现实知识策划应该掌握并且翻译成不需要现实知识的元素,下文会有详细提到),越是看着简单的问题,就越好玩。这个游戏设计之道是所有游戏的根,接下来才是模拟经营类SLG如何设计的关键。

玩家所处的视角宏度

这里引入一个概念“视角宏度”,所谓的“视角宏度”,你可以简单的理解为“当前所处的境地索要解决的问题”,如果跟现实类比,嗯……可以说是“屁股决定脑袋”。有注意到“当前所处境地”和“要解决的问题”了吗?前者是“知识”或者说是“性质”,这当中包含了玩家在这个阶段因为处境而经常会接触的一些游戏设定,以及因为当前能力可以做的事情;后者则是游戏的核心玩点。

到这里,不难看出,视角宏度是一个模拟经营SLG游戏玩家阶段的分水岭,每一个阶段玩家都应该处于一个不同的视角宏度,以不同的“知识面”来应对“新的问题”

举一些简单的例子来说明视角宏度变化,他们未必是模拟经营游戏,主要是传达这样一个概念:比如在光荣的三国志系列比较RPG一点的7、8、10、13代,以及太阁都有,你一开始可能只是一介草民,一个浪人,你能做的事情非常有限,然后你入仕了开始当马前卒,这时候你可以被派遣去种田、治安,你的视角从一个无所事事但自由自在的人,变成了一个接受命令,如何努力把成果做到最高,接受表扬的上班族;然后你逐渐往上爬成了太守,这时候你的视角宏度又变大了,你要做的事情变成了治理好你的城市,不让他被敌人夺走,你还要顾及手底下每个人的状态,以及上面对你的看法,这时候你是个基层小领导的视角;再往上爬一些,你开始负责一片州的管理,你需要调度各个城市的资源把每个城市发展好,同时保证你的州地盘不缩小并且还扩大,这是一个中高管位置的都督的视角宏度……

从例子中也不难看出——因为视角宏度变化了,游戏中的问题也变化了,从平民到君主要解决的问题完全不同了,但是解决问题的知识面还是没变,比如治安靠武力,你做马前卒的时候是这样,你做了都督还这样,区别在于,马前卒的时候你努力提高自己物理去治安,或者干脆武力太低不接这个买卖就好了;等到做了太守,你指派武力高的武将去干这事儿;等你做了都督,就变成你调度物理高的人给太守。你的视角宏度变了,解决问题的方式增加了,并且面临的问题也变化了——治安逐渐从对你来说100%大事儿变成了一个“我不管你怎么做的,报表漂亮就行了”的事儿。

也是因为这样,所以每个阶段做的事情不一样了,就不再是重复劳动了。那光说原理没用,怎么做呢?

如何设计游戏中的视角宏度

值得注意的是,他并不是一件依赖于“剧情”或者“世界观”的事情——外行很容易第一时间想到:那我只要剧情设计有宏度就行了,比如足球经理,一开始做青训教练,我的目标是提拔一些牛逼孩子,到后来我升级到2队教练,目标打入职业联赛……再后来目标三冠王,管理世界顶尖球队了,虽然视角宏度变化看起来不大,但确实问题变难了——符合宏度变化的特征。

但是这个想法并不好,而是要反过来,从游戏的性质出发,我玩家玩这个游戏的“一生”当中,总共能做什么事儿,然后为这些事情划个“所在视角宏度”。当然所谓“规划所在宏度”并不是说我想好了他在什么阶段,然后去凑,而是考虑一个“知识面”掌握程度,以及处理办法即可,至于在什么视角宏度,最终是玩家自己会去理解的东西。

所以设计的重点落在了这些“事情”上,每个“事情”我们可以看做一个单位,比如上面举例的三国志里面去治安,就是一个事情。因为有了“事情”这个单位之后,我们随着游戏开发的过程中,就可以不断有新鲜的想法诞生,只要他们都是基于“事情”的,就能很容易的加进去,它不仅是一个设计想法的指导,而是一个设计思想。所以设计这些事情是在设计什么?

这到底是什么事情?

并不是一句话简单的概括“城池有治安度,派人去挂机游戏中的20天,治安就提高了,武力越高的人提高越多”——这是一句没什么价值的“人话”,每个人都能产生自己的理解,所以是人话,但因此他不具备设计意义,设计理解上的话每个人的认知是不能存在偏差的,所以你需要精确地思考(未必要描述出来给别人听):

  • 这件事情中有哪些“事情节点”或者说“细节”:比如这个治安问题,就应该是“提高城市的某个属性”什么属性?并不重要。玩家需要派遣人——谁?这就涉及到了角色的筛选规则,这时候深入思考,比如“听我话的人”,听我话的人是谁?一开始是我自己,我升官之后是我的小弟,类似这样想下去就有了一个筛选人的规则;怎样做到提高,能干些什么,干了会发生什么?“只要选他,然后就自动挂机了,数值就提高了”那提高量怎么算?哦,最终提高为f(办事人),然后平摊给每天,比如直接除以20,每天(游戏推进最小单位)+这么多。把所有带有概括性质的,人类一听就有想法的词,全部替换为一些计算机都能理解的不需要任何语文基础就能理解的说法,这就是第一步设计,这个设计产生的了一个十分严密的结果,而结果中暴露了需要依赖的参数,就可以形成一个数据结构。
  • 这件事情中的技巧(玩家智慧)何在:也可以理解为这个函数中,玩家作为参数传递之后,在函数中起到的作用,显然“治安”这件事情,玩家能起的作用几乎为0。因为完全不需要智慧,所以他不好玩,因此反复做这件事情很快就必然会腻味(这是客观的“好玩”,而不是主观的, 你总能找到猪头三说“我就喜欢这样反复点点点,你拿俺老猪怎么滴?”所以按照主观讨论,永远是浪费时间)。但比如说换成一些有操作的小游戏,就至少有了玩家操作这个环节,虽然他并不是最好的办法,但是确实无奈的办法,比如太阁系列就这么干。但实际上每件事情有智慧并不是那么好设计的,所以偶尔有些没有技巧性的事情作为内容,也是可以接受的。当然,这个玩家智慧,在不同视角宏度下也可以完全不同,甚至一开始有,后来没有也没问题,比如太阁的小游戏,后期可以不用自己去玩了,派小弟过去办事儿,智慧变成了“派谁”而不是“怎么解决”了,也是可以接受的设计。
  • 函数化看这件事情:最后把上面说的抽象为函数去看,不一定要具体实现,但你应该有一个概念在那里,比如“派谁”就有Character GetCharacterForSecurity(List candidates),从这种函数中,你就能更清晰得去看到你的玩法,需要的是什么,做了什么,到这里才是设计。

这件事情需要掌握游戏的什么知识?

之后就是罗列这件事情涉及的知识点,所谓的涉及,可以是引导,也可以是要求玩家先知道,但是绝对不要去定这算是引导还是利用,因为是否掌握了一个知识,或者是否能从某个行为掌握知识是因人而异的,所以是绝对主观的东西,任何设计(包含且不限于游戏设计)都无法设计主观的东西(主观的东西包括“体验”什么的,所以一听人谈设计张口就是“体验”,这人多半是个只会吹牛逼的)。还是比如“治安”这个事情,他需要的知识就是“武力值高等于效果好”,以及为什么会这样?这里就要进一步描述这个玩法如何工作的,也就是上面所说的第三步。

为什么我们需要罗列知识点,这是为了我们知道他涉及的东西,以至于他大致出现在什么阶段,在设计一些数值的时候,是可能会用到这个的。

举例:做一个游戏公司经营养成

这里只举例游戏宏度(或者说阶段性)设计和事情的设计,不做更多具体的设计。

首先可以敲定一个宏度设计

因为题材确定了是游戏公司经营,或者说是一种“剧情先行”的做法,那么我们就可以直接跳入敲定宏度的时代,也就是这个游戏过程中每个阶段:

  • 2、3个人独立小团队制作人视角:这个视角下关注的是如何利用好每个人的技术专长去解决游戏开发中的技术问题,最后把游戏做出来。在这个视角下,接触到的问题更多是游戏开发中常见的一些技术问题。因为游戏设计中不应该代入任何现实知识,所以在这个环节的内容一定不能抛给玩家专业的知识,比如“如何设计一个易扩展的技能系统”,而是要把他翻译为玩家可以理解的一些问题,比如:子弹飞行轨迹出bug了,这可如何是好?第一步选择方案:A换一个算法函数,B砍掉子弹系统,C无视bug当做feature。这些选项都会影响游戏最终的成绩,但这些选项本身都不需要专业知识,凭常识就能想到结果,如果选择A,则列出3个人谁来办让玩家选择,并透露这项选择依赖的属性,比如:A猴叔(数值设计92,耐性33,正在开发任务系统) B鲁大师(数值设计87,耐性26,正在制作主界面UI) C大白马老师(数值设计67,耐性91,正在泡咖啡),玩家根据当前情况来进行选择(这里说的是视角的感觉,而非游戏真这么设计)。
  • 10-20人团队独立游戏制作人视角:这个视角会逐渐偏向于小规模工作分配,以及协力阶段,逐渐减少一些具体的内容制作工作,除非遇到恶性bug,也就是虽然会发生类似子弹bug的问题,但不会只是子弹bug这么小的事儿了,他可能是“如果采用这样的设计,就需要考虑水面要到映出角色纽扣中的水面倒影,但是我们目前技术实力不足,怎么办?”。所谓的协力问题,可以不光是指派谁谁谁去制作某一块功能,还要考虑如果这些人合作,会发生什么?比如羁绊之类的玩意儿要不要?
  • 完整团队制作人视角:完整团队的时候,制作人的视角会又一次发生变化,即更关心时间节点,因为这时候也会开始更多的关心和发行的合作、档期之类的问题。而游戏开发中的技术细枝末节等都已经委派人去解决了,人际关系也由各部门经理(组长、主策主程主美等)自行解决即可。所以视角有一次发生变化,而问题也从“如何安排好人开发出游戏”变成了“规划出更合适的产品节点,包括什么时间点、在哪儿、发布一些什么feature以至于产品成绩会更好”。
  • 多个开发团队老板视角:这时候的视角,已经从做游戏产品,变成了做公司了,如何建立生产线不断快速产出产品,抓住市场机会,以及和各个发行团队建立良好的关系是这个阶段的主视角。可以看到“如何解决某个bug”已经根本不会出现在这个阶段了。
  • 多个开发团队以及发行、运营团队老板视角:这个阶段的视角,就是要考虑如何构成完整合适的游戏产品链,直接和媒体等进行合作,来成为行业霸主了。视角已经转换成了“我如何利用资源制造档期、制造热门”而不在是“把握住机会,让产品变得更好了”。

这些视角宏度的变化,是一个玩家所要经历的变化,他也是模拟了现实游戏公司的制作人的一个变化过程,这部分可以是这个模拟养成游戏的脊髓——因为每个阶段关注的焦点确实不同了,并且要解决的问题所用的技术角度也不同了,对于游戏知识也是积累的(至少我们直到最后都知道,解决bug需要靠的是开发技术高,而不是运营能力强的人),所以我们认为这个视角宏度作为切割可行,接下来就要设计游戏中能做的事情。

接着是事情设计

正如上面所说,“事情”其实是一个单位,所以在开发过程中可扩展,因此不需要第一时间全部完整的罗列出来,尽管事情本身关系到游戏的玩法。所以在这里我们就很简单的列个把事情做个例子:

例子:开发技术选择——游戏中角色动画框架

描述部分:当玩家立项要做一个动作游戏的时候(即使是开罗游戏,都有立项对吧),要且只能选择一个游戏中角色动画所用的框架,选项包括:动作状态机,Cancel机制,blablabla……。每个选项产生的结果,是后续【研发内容块】的不同,这将导致后续工作方式和成果会大有不同。

进一步描述一个结构:研发内容块,是指一项研发工作转化为游戏的数据结构,它包含的主要(而非全部)数据:

  • 功能块名称:比如绑定骨骼等,是这一部分工作的名称。
  • 复杂度:int,描述这个模块开发的难度。
  • 效果算法:玩家可以安排人员去参加工作,无限个人员组成List developer。根据developer得出对于“游戏手感属性”“游戏画面流畅属性”的影响算法各一个。
  • 工作时间算法:根据developer以及复杂度属性,得出一个这个工作完成最终需要的天数(游戏最小时间单位)。
  • 可能遭遇bug算法:一个算法,得出在这个工程开发中(float 概率, BugInfo 什么类型的bug)的值,即开发中每一天都有这么高概率,碰到这么一个bug。

玩家技巧部分:上面我们大致描述了这个“事情”,之后就要开始看这个“事情”中的玩家技巧了,这得根据视角宏度去看:

  • “2、3人小团队视角”到“10-20人团队视角”:这里的技巧是选择一个适合团队开发人员属性发挥的方案,最大化人员属性转化为游戏成绩属性,10-20人视角还可以考虑哪些人之间的build带来的更高效益。同时玩家还要考虑解决bug的小游戏自己游玩的技巧水平等,做出最终决策, 这些都是智慧。
  • “完整团队”和“多个团队”视角:这里的技巧就是评估团队的实力,看哪个框架更省时(成本)以及得到什么程度的游戏成果(不一定分数越高越好,毕竟还有营销部分),算出最佳开发性价比,然后做出决策。这个技巧已经与小团队时候“追求最高成绩”所不同了。
  • “大老板”视角:已经不关心这个玩法了,这只是“还存在于游戏中的一个设定”,只需要委任小弟去办就行了,所以已经没有技巧,也不好玩,因为不需要去玩这个了。

最后函数化描述之:会涉及到这样一些细节(并没有列全面,甚至在这里没有列表格):

  • 选择“解决方案”就是在选择后续工作,List workflows。
  • 每一个Workflow中包含了多个工序,即上文所说“研发工作块”List devs。
  • 每个研发工作块……(略)
  • 可以安排任意团队中可以支配的角色去参与工作List Develop.developer可以选择PlayerInfo.TeamDeveloper。
  • 做这件事情会经历一段时间,整个团队中参与这个事情的developer将进入一个“working”状态,working状态下无法执行其他工作。

就按照这样不断的想事情

就这样的方式,去做每一个“游戏中的事情”,堆积起来就是游戏的内容了,这个过程中,需要注意,是否每个阶段玩法总是一样,或者无法突出这个阶段的核心玩法,如果是就要做出相应的调整(对“事情”进行调整)。

总结

所以设计一个经营游戏,根本是在设计“可以做的事情”,这些事情被规划到不同的视角宏度,每个视角宏度也是游戏的一个阶段。正因为阶段不同,视角宏度不同,所以可以做的事情不同,所以面临的问题也会不同,需要使用的解决方法和思路都不同,所每一个阶段都是一个“不一样的游戏”,但是因为建立在一样的知识面和性质(都是同一个游戏的)之上,并且玩法(操作)和ui保持同样的调性,就不会产生割裂感。当一个经营游戏每一个阶段(尤其是每一个阶段都是玩家自己行为打开的,比如经营游戏公司的时候不是有钱了立即变成10人团队,而是我愿意,并且有钱的时候才会变成10人团队)都是不同的玩法的时候,他就会一直有新鲜的内容可以提供给玩家,到这里客观的“好玩”就做到了,至于玩家会不会有期待感和新鲜感,这是主观的,无法设计。

来源:知乎 www.zhihu.com
作者:猴与花果山

【知乎日报】千万用户的选择,做朋友圈里的新鲜事分享大牛。 点击下载

此问题还有 5 个回答,查看全部。
延伸阅读:
一个单机游戏经营建造模拟类的?
一个经营公司的模拟游戏?

like

dislike

love

funny

angry

sad

wow

李芷晴 https://tszching.uk