|
|
之前我写过一篇给新手独立游戏开发者的入门级建议，经过三年的开发，对于独立游戏制作这件事我有了一些新的理解和看法，所以是时候补充一篇进阶级的建议了。如果你希望成为一个独立游戏制作人或者希望了解相关行业的部分知识，也许这篇文章会给你一些有用的帮助。
特别的，本文的内容更多的偏向于独立游戏制作人和小型团队，并不适用于所有的情况，所以在阅读时请注意保持个人的独立思考，对所有内容应仅当参考。
一、发展方向篇
需要探索的第一个问题是独游发展方向的问题，本篇的核心主题其实只有一个，那就是独游和商业手游的区别。
1.1 独立游戏和商业手游的区别
这里有一个很大的误导在于，对商业手游的解释，毕竟独立游戏也是需要赚钱的，部分独立游戏的商业收益甚至是非常可观的。所以它们之间最核心的区别并不在于营收能力，而是两者在立项时的指导策略或驱动要素。
一般来说，独立游戏的是以玩法、内容、创意为驱动要素的产品，其主导的做法就是，游戏怎么好玩怎么做。而商业手游则一般以市场调查、用户群规模、吸量、APRU值等数据分析为驱动要素，其主导做法就是，游戏怎么赚钱怎么做。
特别要注意的是，商业手游不以玩法为核心并不是在说这些手游不注重玩法或者玩法要素不会成为衡量一个手游品质的维度，而是它的重要性不足以左右产品的立项。这在一定程度上导致了产品在立项时依赖良好的市场验证，而在缺乏足够的市场数据导向时，很难有人愿意投入太多资金进行玩法探索，这样的策略偏保守，优势在于可以通过现有数据对产品的结果进行相对准确的预测，劣势在于会因为步调落后而无法抢占市场先机。
1.2 社交价值公式
两者驱动要素的不同导致了游戏整体的制程和制度规范有较大的差异，尤其是其成本投入的偏重点，为了说明手游的偏重点，我们先引入一个简单的公式，我称之为社交价值公式：
社交价值=社交信用×稀有度
不同的产品总归会为我们提供不同的价值，手游相比于提供娱乐价值，其提供的社交价值更大一些，特别要注意的是，这里的社交价值是一个狭义的社交价值，严格来说，它是一种炫耀价值，或者讲的通俗一点，叫装逼价值。
社交价值最核心的一个点在于构建社交信用，信用是一种关于认可人群规模的描述，举个例子，如果你尝试使用津巴布韦币在国内购买商品大概率是行不通的，因为这里没有人认可津巴布韦币，同样的，一个游戏里的道具要产生社交的信用，前提条件是有很多人认可这个道具，说白了就是大家知道这个道具的价值，这就是社交信用。如果你玩了一款非常冷门的手游，你在里面抽到了一张SSR卡片（可以理解为一种稀有道具），你把抽到的卡片截图发到群里，你期望得到的是羡慕的眼神，但是由于该手游太冷门了，大家都不屑一顾，这样的手游我们可以认为它的社交信用太低了。如果把一款游戏的社交信用拉到极限，全球所有的人都认可这款作品里的道具，那我们甚至可以用这款手游里的金币作为交易货币，只是这种情况有可能只出现于《头号玩家》这样的科幻电影里。
认可的、知道的、熟悉的人越多，说明这个圈子越大，说明这个对象的社交信用越高，这就是品牌溢价的来源，铺天盖地的广告和营销主要就是为了提高它的社交信用，类似于茅台酒或者其他奢侈品，必须要营造出我买了它我就是最有面子的那个人的群体印象。
社交价值的第二点源自于稀有度，因为人都存在一种潜意识心理效应叫稀缺心理。但是和社交信用不同，稀缺性是可以人为营造的，比如奢侈品可以通过打造限量版的产品，手游可以降低SSR的爆率来提高稀有性。
稀缺性的降低对产品的价值的影响不是线性的，举个简单的案例，在我还是初中生的时候，就看过一个新闻，在2009年《地下城 与勇士》最火的时候，一把魔剑·阿波菲斯甚至可以卖到10w人民币的价格，但前提是整个服务器只有一把， 如果整个服务器有两把，那么每把的价格也许就会降到3w块，如果有三把，那么每把可能只值1w块了。
这就是社交价值公式，社交价值与使用价值不同，附带极高社交价值的物品的使用价值可能很低，比如再贵的表也只是用来看时间。光刻机和梅赛德斯奔驰AMG-Project-One都很贵，但是两者贵的点却完全不同。社交价值可以穿越时空应用于所有存在社交概念的物种，从石器时代到现代，从动物到人类，同样它也是大佬愿意在手游中充钱的核心理由。
1.3 对内容和营销的理解
手游的运营本质上就是在维持自身的社交信用，不过随着时代的发展，各类手游产品会越来越多，所产生的圈层也会不断地增多，一方面是开发门槛降低，一方面是内容开始偏向于短平快，碎片化。所以一款现象级、全民级的手游在未来出现的概率会越来越低，这也给提升手游的社交信用带来了更多的困难。
维持社交信用是一个抽象的概念，它可以等价的转换为让更多的人知道以及认可这款作品，一方面要提高现有用户的粘性，不由于内容的迭代而产生太多的用户流失，一方面要提高广告对潜在客户的精准投放。无论如何，这注定了手游的大部分预算可能不是用在开发上的，其营销成本与开发成本有可能是分庭抗礼甚至对于部分微信小游戏来说营销成本远超开发成本。
正如有人问，手游的品质重要吗？这个问题其实是对手游方向的总结，手游的品质固然重要，但是它并不是一级属性，而是一个次级属性，也就是它是用来影响其他一级要素的，如果我们建构一张图表，对手游投入的开发成本与用户群规模进行一个单一维度的研究，会发现手游的品质对用户群规模的影响是有限且不稳定的，因为一旦来到了内容领域，就会带有很强的主观性，其维度就会受到用户群的制约，假设我们要做一款解密向手游，那么就得考虑，喜欢解密游戏的圈子本来就不是很大，这个用户群的规模上限就在那，即便是品质拉满，宣发拉满，所产生的提升也是十分有限的。但是手游开发商仍然会选择那些更加稳妥的选择，比如加入更多的擦边要素来吸引男性用户，典型案例就是2022年的《NIKKE：胜利女神》在欧美市场的优异表现。
（当然，投入成本无法精确的锚定到手游品质，一方面是各厂商的生产线和美术成本投入不同，一方面是部分手游存在开发上的各类矛盾而导致工期的蔓延，所以两者之间无法完全等价，只能作为一种投影参数）
不过这并不是说独立游戏不存在运营的概念，只是独立游戏更偏重于内容，所以独游的开发成本更多是用在内容的制作上的。
1.4 独立游戏的生存之道
手游的生存靠的是对一款特定作品的运营，而独游靠的是工作室的产品矩阵，往往是系列作品自带的流量。典型案例比如恐怖生存类《森林》成功之后，其开发商推出了作品的二代《森林之子》，而如果你是接触了森林之子去了解这个系列作品，那么你大概率也会去了解一下森林，正如其他的系列作品一样，无论是小型独游还是大型的3A级作品。
所以本质上来说独立游戏运维的是自身的工作室或者作坊，靠的是作品IP，靠的是工作室的粉丝群对系列作品的热爱。当然，将作品IP的粉丝群转换为手游的天然流量也是现代化手游常用的做法之一，其实早点在2016年的时候就有腾讯出品的《MHOL》，这是一款相对较为成功的单机IP流量转网游的案例。
以上是第一篇的内容，当然我觉得个人对手游的理解可能还比较浅层，对我的观点，仅为一家之言，大家应该理性的分析和判断。总的来说，当我们开始独立游戏的制作时，应该将重心放在内容领域上。部分以营销为核心的独立游戏也很成功，但是这样的成功带有一丝投机主义，能积累下来的东西不多，成功难以复盘，更难以复现。
二、内容制作篇
无论是手游还是独立游戏，最核心的工作都是产品的具体研发，降低开发成本、提升开发效率一直是永恒的主题。所以本篇中，我会提到个人对于内容制作的部分理解。
2.1 制作人是否一定是多面手
制作人之所以是制作人，是因为他统筹整个作品的开发，也就是说，他要负责多项工作，或者与多个负责对应工作的人打交道。这里就牵扯到关于制作人是不是一定是一个多面手，或者通俗的来说，他是不是必须是一个六边形战士。
2.1.1 策划是否需要玩过很多同类型的作品
这个问题的答案其实和策划是否需要玩过很多类似的作品一样，我的答案很简单，策划需要玩很多的目标类型的游戏作品。但和一般理解的点不同的在于，很多人以为策划需要玩过很多作品的目的是在于寻求更多的可借鉴的方案，正如同写文章需要有宽泛的阅读履历和人生履历一样。但是我认为，寻求可参考、可借鉴、甚至是可抄袭的案例是次要的，更主要的是提高沟通的效率，降低沟通成本。
我们无法以一己之力去对抗历史，如果你从事创作行业，你大概率可以感受到这点，就是无论你进行怎样的创作，你的作品的局部或整体都可以在漫长的历史的长河里找到类似的作品，有的时候你甚至完全不了解过另外一款作品，两者之间也断不可能存在连接关系。但是这两款作品却可以产生碰撞，有类似甚至非常相似的设计在其中。任何设计目前都无法再算是新颖，游戏设计逐渐从大体量的创新转向了子系统的融合。比如《幻兽帕鲁》，采用了《方舟生存进化》的玩法缝合宝可梦的皮，恰好又与国内的部分主流媒体文化链接，就产生了非常神奇的化学反应。
（题外话：任何设计目前都无法算是新颖需要划分不同的层级来判断，正如你把大逃杀类型的第一人称或者第三射击游戏拿给零几年的老玩家去看，抛开画质的问题，他们大概率会说这个游戏和CS很像，因为两者都具有第一或第三人称射击要素，这个案例也可以很形象的证明，以前的创新是创作出一种新的游戏类型，而现在的创新会变得越来越细节，越来越无法被非圈内的人所识别，正如对于老一辈的父母来说，他们可能也无法Get到街机游戏和早期网游的区别在哪，对于你的男朋友来说，口红色号是一个难以辨别的东西，对你的女朋友来说，佐菲奥特曼和杰克奥特曼就是不太容易分得清楚）
简而言之，策划可以利用案例而非直接叙述的形式来表达自身对某项设计的理解或者描述。这就好像是一种引据经典，如同部分成语一般，简短但是十分贴切。在策划沟通过程中，如果一个策划多款经典游戏都没有玩过，与之沟通的成功就会不断地提升。当然，前提是我们将策划锚定在一个系统和玩法设计层面的策划，而非数值或者文案策划等，这点我后面还会继续强调。
了解了这个点，再回到关于制作人是否一定是多面手的课题下，我们大概也有了一定的认知，如果整个制作组只有制作人一个人，那么他肯定得是一个多面手，而如果整个制作组有其他开发者，那么制作人又需要在一定程度上了解其他领域的内容用以降低沟通成本，只是当开发组有其他人来负责具体的任务，制作人只需要统筹和部署开发任务时，对制作人在该领域的要求会下降很多。
以我个人浅薄的经验来看，独立游戏铁三角（程序、策划、美术），制作人必须至少占据两个方面才能成为一个制作人，否则开发所产生的沟通成本会无限的变大以至于这种本来是隐性成本的东西却可以在团队建立之初就产生较大的障碍。
2.1.2 消除游戏的短板
一般会说扬长避短，这是两件事，扬长是发挥自身的长处，避短则是一个反义的概念，两者往往的对等的，也就是除了扬长，还要避短。但是在游戏开发中，避短的重要性要高于扬长。
简单来说，游戏有着比较严重的短板效应，但是游戏对综合技术力的要求又会因为游戏品类的不同而产生差异，举个简单的例子，galgame类型的游戏对立绘、剧情、音乐更加重要，好的作品肯定是三项都拉满，稍微劣势一点的作品应该也是某两项做到高分，某一项是及格。但是如果三项里有任何一项是不及格，那么整款作品就会因为这个短板而被认为是渣作。
当然，针对独立游戏会谈到这个点往往是因为很多独游没有太过丰富的资源，钱不是问题，问题是没钱。所以在进行项目选型时，你无法选择一个包含了团队严重短板的项目，比如某个项目需要高品质的逐帧动画，而你的团队里并不具有相关人才，那这个作品就不应该在你的考虑范围内。美术问题往往是独立游戏开发者最头疼的问题，不仅是针对国内，即便是游戏工业相对成熟的国外也是一样的。所以采用各类方法来消除美术成本就是一个值得参考的事情。
什么叫消除美术成本，或者什么叫消除问题？消除问题和解决问题不一样，举个简单的例子，假设某古人在旅行并途径一个村庄里，村民告诉你，前方的小路路径很短、但是有一伙强盗会拦路抢劫。解决问题就是，你雇佣一组保镖，为你保驾护航，去打击这帮强盗或者只是避免被抢劫。消除问题就是，不要走这条路，换另一条路走，本质上强盗的问题没有被解决，但是你不会再遇到这个问题了。
其实很多开发者都在尝试用各种各样的方法去减少美术成本，比如完全用文字来代替美术素材的表达。以下是典型的美术要求不高但相对比较成功的作品案例：如果你的技术力比较强，能够独立的完成比较庞大的工厂类模拟经营游戏，可以了解一下《浮岛物语》，而如果剧情和音乐能力很强，《UnderTale》也是一个值得参考的案例，如果你对程序动画或插值动画了解的比较多，可以看看SokPop出品的《StackLands》和《Yard》他们非常擅长使用非具象化的游戏要素比如卡片，图标等来制作游戏，使用线性动画来构建动态视觉要素。而如果你的特效能力很强，也可以看看8bit工作室出品的《BleakSword/荒绝之剑》这款作品的美术压力相对较低，但是对特效的要求更高。同样的作品还有《城市叠叠乐》《纪念碑谷》等
图为荒绝之剑/Bleak Sword
当然，这也是一个有趣的话题，即很多人觉得特效和美术素材是一样的，都属于美术的范畴，宽泛的来说的确如此，但是个人认为特效和画面其实是一个偏向于技术美术的工作，也是更偏向于程序进行转型的部分，毕竟技术转技术美术相比于美术转技术美术的难度要小很多，我的美术能力并不强，但是完全可以实现荒绝之剑中所有的特效需求，做出与之对等的画面和风格。不过如果坚持认为TA是一个更加困难的职业，那么也从选项中移除该项即可。
而如果只擅长一个固定的领域，就只能将这个领域的能力发挥到极致，亦或者开始去学习不同的领域，两者所需的时间没有本质上的差异，无非是广度和深度的区别，这是独游制作人无法避免的一个问题。如果压根没有任何选项可以选择，那么不妨反思一下自己是否还需要经过一段时间的学习和历练。
所以回顾上述的游戏，会发现，这些游戏没有一个明显的短板，没有足够的资金去外包美术或者招到对应的人才，就消除美术成本，利用其他方法维持游戏的及格线，而不是强行保留一个生硬的短板。
2.2 分层处理问题的思想
分层处理的思想简单来说就是将大的问题拆分为彼此关联又互不干涉的结构，这有点类似于编程领域时常说到的组件编程，举个简单的案例，知乎上有一个热门的问题是为什么人类没有进化出攻击性的器官？这个问题其实问到了一个人类和其他动物比较大的区别，就是人类有一双灵活的双手，手和臂的组合让人可以使用各种武技，让人可以持握各类武器，让人可以投掷重物，如果人类的手是专门为攻击而设计的，那么它大概率会被攻击性这个组件限制住，因为生活所做的不全是需要我们去攻击的行为。手可以让人类的身体和各类武器进行解耦，形成两个不同的组件。
所以分层处理问题的思想简单来说就是，战斗时我不需要知道武器的原理是什么，只提升自己使用武器的技巧即可，毕竟剑士有可能是不知道剑是怎么炼制的，研究武器时也可以专注于威力和易用性，研究完了告诉别人怎么用就完事了。这个简单的思想其实非常好用，很多时候一个问题讨论不清楚只是它捆绑了多个不同的问题，紧密的连接在一起。但是真正的矛盾在于很难找到一个合适的分割技巧将问题分割为所谓的彼此关联但又互不干涉的多个部分。为此需要学习很多思维技巧。
2.2.1 内容和结构上的分层处理
假设要做一个简单的走迷宫的游戏，重点就是要设计一个巨大的迷宫，这就是一个庞杂的问题，严格来说它可以被抽象为一个线性游戏，与解密类游戏很相似，比如《黑羊》《烟火》《隐秘的角落》等作品，也与部分银河恶魔城类型游戏很相似比如《空洞骑士》《RustedMoss》等。
这些游戏的设计绝不是通过设计一个巨大的迷宫然后让玩家从头走到尾来制作的。这样的风险太大了，因为当其中的部分关卡进行调整时，前后关卡都会产生较大的矛盾从而必须要调整前后关卡，为此我们必须要将游戏的设计分割为数个互不干涉的多个完整流程，比如分为多个章节，第一个章节的结局是固定的，无论玩家如何游玩，它都会把玩家导向第一个章节的结局，这是线性游戏的特点，也是将第一关的制作风险和改动成本控制在一个关卡的内部。也就是说，我们把一个巨大的迷宫分割为了几个部分，有几个关键性的节点，比如玩家一定是沿着A、B、C、D、E五个节点最终走到迷宫的终点，A和B之间是一个被分割的小迷宫，B和C之间也是，我们只要保证前一个迷宫的重点与下一个迷宫的起点彼此连接，就可以确保整个迷宫是连在一起的，这样即便过程中我觉得BC迷宫做的很烂，不太行，要重构，也不会影响到AB迷宫和CD迷宫，哪怕我们觉得BC迷宫应当删除也只是需要关联AB迷宫和CD迷宫的终点和起点罢了，这就是线性游戏的特点，也是为什么我们一定会分章节和关卡去处理这些问题。
这就是内容和结构上的分层，关于线性游戏的这一特点，下面的游戏构型一节中会继续探讨。
2.2.2 系统和机制上的分层处理
系统和机制上的分层更偏重于前面所提到的解耦合的思想，严格来说这也是最能体现策划也依赖程序知识的点，举个简单的案例，假设要设计的游戏有科技树系统。首先应该思考的是，科技树完成的任务到底是什么？是帮助我们解锁科技吗？从玩家的角度来说是的，但是从策划和程序的角度来说，科技树看起来更像是一个回收素材或者点数的系统。
在开发科技树的过程中，它的系统逻辑应该是玩家满足了某些点数条件之后，可以打开对科技树某个节点的开关，某个节点被点了之后，科技树负责通知其他系统来帮助解锁某些科技或者打开什么开关，具体会解锁什么科技树是不清楚的，说白了科技树只是一个用于回收点数的形式性系统，而如果我们真的把解锁的行为耦合到科技树，策划在配置数据、程序在开发时都会遇到更多的麻烦，因为它同时解决了两个问题，对接解锁点数和具体解锁的功能。
但是科技树只能解锁科技吗？它为什么不能是让民兵的发展路线，它为什么不能是建筑的等级提升，功能追加，科技树会解锁什么，达成什么条件应该是一个独立的系统，但是消耗素材、回收点数是科技树固有的特点，这也是为什么我们说，从策划和程序的角度来看，科技树更像是一个回收素材或者点数的系统。
在拆分系统的时候，我们需要对系统之间的连接关系有相对完善的判断，科技树是一个比较经典也比较简单的的设计，但是真正的开发过程中，我们所遇到的问题可能更为复杂和繁复。
2.2.3 分层处理思想的总结
分层处理的思想是一个底层的思维逻辑，它可以是分化问题的思想，它可以是将大目标拆分为小目标从而引发目标梯度效应的学习技巧，它也可以是程序里解耦合和组件编程的思想，它可能有不同的名称，不同的叫法，但我认为是一个比较重要的思想，当然，不仅要有这个思想，更要明白如何分层，如何拆解，这是需要长时间的学习总结和体悟感受的。
2.3 理解成本惯性
惯性其实是一个物理性质，也就是牛顿第一定律所描述的：
任意具有质量的物体具有维持其运动状态不发生改变的性质，称之为惯性。
但是惯性在本文中的概念更为宽泛一些，它指代任意具有来拒去留性质的对象或者概念，小到个人的生活习惯，大到互联网的生态。对于个人来说，习惯是很难养成又很难移除的，而互联网生态同样如此，比如有人一直疑问为什么Python编程语言可以这么流行，很简单，Python简单好学，吸引了很多人来学习和使用，既然有了很多用户，就会有人为其构建更多的工具，有了更多的工具就会有更多人学习和使用，这就是生态的良性循环，久而久之，Python就形成了庞大且活跃的生态，这既难以形成，也难以消亡。
所以，惯性在本文中指代的是这些具有来拒去留性质的对象或概念，只是我个人更喜欢用惯性去描述此类性质，简约又直观，所以成本惯性描述的就是当我们已经制作了大量的美术素材、或者代码资源的时候，整个游戏逐渐成型，就无法再轻易的变更现有风格，亦或者 大规模的修改玩法。否则部分代码系统就需要重构，部分美术素材就要重绘，这里面产生的成本浪费是很大的。
这个点其实是一个显而易见的问题，然而我们提到了这个点，更多的还是因为独立游戏确实经常需要好的创意或者遇到各类天马行空的想法。但是在此之前我们应该对成本惯性有深刻的认知，并在开始推进美术计划和程序计划之前，将玩法彻彻底底的捋清楚，通过纸面玩法模型去推演玩法的可行性，即便要构建最简单的demo，也应该尽量降低对美术的需求，使用白模或者色块以代替各类游戏中的元素。直到策划团队或者制作人对玩法毫无疑问时，才应当展开后续的美术和程序开发计划。
一个典型的失败者案例就是，如果一个新手制作人不清楚自己要做什么，本身有很多想法但又觉得不够完美，追求完美却又没有太多开发经验，来回调整目标，重构玩法，这个过程中成本惯性所产生打击是毁灭性的，以目前游戏人才市场价格来计算的话，投入百万资金打水漂是常有的事。
当然这并不是说一旦开始了计划就完全无法再回头了，只是变化时肯定会有部分成本惯性的对冲，我们将其统称为美术成本或者程序成本，但其中肯定不乏各类细节成本，只要成本在可控范围内，变化和调整就是可接受的。所以成熟的制作人会在动手之前会经过非常彻底的思索和考量，去磨策划案，通过纸面模型或者简易的程序原型来进行测试，这个程序原型甚至可以是一个控制台程序，只要可以表达玩法即可。不过此类概念更适合运用于以玩法为核心的游戏，如果游戏本身的玩法偏固定，只是题材和表层内容的切换，那么我觉得甚至可以美术先行以免浪费开发周期。
2.4 提高自身的审美
审美在此处是一个广义的概念，审美能力是对产品好坏的一种判断能力，正如对一个厨师来说，味觉失灵是一种毁灭性的打击。
2.4.1 洞察缺陷比如何优化更重要
在讲这个节点之前，可以先引入一个经典的认知偏差效应，叫邓宁·克鲁格效应，该效应指的是当一个人的能力比较低时，他对自身实力反而会产生一种误判，以为自己很强，从而变得傲慢，这也是我们通常所说的愚者山峰，这类人经常容易和别人争吵，道德经中也有类似的描述：
知者不言，言者不知。——《道德经·第五十六章》
所以想要让作品变得更好的前提就是，要了解作品是不好的，或者说，要承认自己的作品是不好的。然后才能进一步的改进它，如果不承认或者无法洞察到作品的缺陷在哪，优化就无从谈起了。
所以如何深刻的了解作品问题在哪，本质上就是提高审美，而且是各方面的审美。尤其是作为制作人对作品玩法和体验的审美。用打击感来说，经常有人说打击感不行，那么能不能详细的把打击感不行这样一个具体的外层表现转换为具体的问题，转换为本质的可以去优化的点？
于是就要分析不同的作品，多玩、多看、多体验，比如希望学习快节奏战斗系统，可以偏重于研究《鬼泣》《真三国无双》《讨鬼传》《噬神者》《哈迪斯》等，慢节奏的游戏则可以研究《怪物猎人：世界》《只狼》等，如果没有了解过这些游戏，当打击感出现问题的时候，也很难搞清楚到底是哪里出了问题。
这也是为什么说：洞察缺陷比如何优化更重要。
2.4.2 有时需要的不是答案，而是佐证
利用分层处理问题的思想，如果已经洞察到问题的缺陷，来到了一个次级问题，即如何优化时，就可以抛出这个节点，即解决问题的方法比问题的答案更重要。简单来说，如果要提升自身游戏的打击感，作为一个身经百战的制作人，问题的答案几乎是脱口而出的。打击感源自于五个点
- 击中目标对象时的动画及时反馈（敌人的动作变化）
- 击中目标对象时的物理反馈（敌人的后退或者浮空等物理行为）
- 击中目标对象时的特效变化（敌人的血迹粒子、闪白或屏震效果等）
- 击中目标对象时的时间流速变化（角色的卡顿/时停等）
- 击中目标对象时的音效反馈（金属碰撞或者受伤的音效等）
如果尝试通过某个视频来学习如何强化打击感，大概率也会找到类似的分析和总结，但是问题就在于，不同的作品对其细节的要求是不一样的，比如怪物猎人中，敌人是一个巨大的对象，它的物理反馈效果就不可能是后退之类的，于是物理效果的反馈就会是IK物理效果，也就是反向动力学。而如果敌人是一个和主角一样大小的人形角色，那么IK就不适用了。
如果要做的游戏是类似于真三、暖雪或者武士刀零这样的割草游戏，倾向于快节奏，那么像怪物猎人一样砍中怪物之后刀的动画播放速率变慢所产生的卡肉感就不应该出现，因为后者是目标作品希望表达武器的力量感而设计的。
所以应该自己分析一套对应的优化方案，尝试用自己的方法进行优化，得到对应的结果，然后对该结果进行验证。如果效果不好，则回头继续分析和提出方案进行优化，每次提出新的方案，综合能力都会得到一定的提升和积累。而如果只是得到了一个答案，且不说这个答案能不能帮助优化作品，关键的是分析的过程本质上是需要积累足量的经验从而应对后续的开发的。
更不要说这里提到的只是最常见的一类问题：打击感，而实际上游戏开发中所面临的真正问题往往是找不到答案的，能直接搜到答案的问题往往也不是什么大的问题。
这也是为什么说：解决问题的方法比问题的答案更重要，或者有时需要的不是答案， 而是佐证。
2.5 对游戏构型的理解
游戏构型，一个相对较为抽象的概念，但是我们在该节关注的点比较简单，就是游戏的构型是否可被量化，也就是有没有办法把游戏拆分为相对比较独立的几个结构同步进行开发。那么这和之前提到的线性游戏就产生了很大的关联，一般来说，线性游戏更容易被量化，被预估和统筹。
2.5.1 游戏是否可被量化
用经典的跳台游戏《蔚蓝》来举例，蔚蓝初代里包含了三个章节，又分AB面形成六个大型的关卡，每个大型关卡又分为数十个小型的关卡，严格来说，并不需要六个大型关卡全部设计完成之后这个游戏才可以体验，而是做了一组关卡之后就可以开始测试了和游玩了。
如同其他的线性游戏，诸如解密类游戏、ARPG、银河恶魔城等都具有这样的特点，即它们整体玩法体验除了装备和数值的提升带来了节奏感的变化之外，整体体验可以在最初的关卡里打磨和完善，扩展游戏的时候也可以轻松的增加更多的关卡和流程，每个关卡的制作流程和管线是相对比较类似的。
不过虽然一直提到的都是线性游戏，但是不代表其他非线性游戏是不可量化的。比如赛车类游戏并不属于线性游戏，但是它的关卡也可被量化。这些可以被量化的游戏，它们的制作更加的偏重于某个关卡的研发和制作，核心的体验打磨完毕，后续的扩展即便会遇到问题和矛盾，也相对来说比较容易解决。但是部分游戏是不可量化的，比如我正在制作的模拟经营类型，这类游戏的特点就是，它的短板效应非常严重，必须把所有的系统都制作出来，它的demo才足以成型，才能开始体验效果到底好不好。
2.5.2 可表达玩法的最小原型
对于那些不可量化的游戏，我们也试图寻找一个最小的可体验demo结构设计以提升策划迭代的速度，但问题的关键是这样的最小原型是如何设计的？
最小原型的设计指的就是，能够完整的让玩家体验到游戏核心玩法的最小demo，其他不必要的就不用去加，这也是一种奥卡姆剃刀原则，即如无必要，勿增实体，这种原型demo的设计技巧是可以练习的，可以找到一个现有的游戏案例，然后对它的系统进行剪枝，也就是只要移除该系统不会对核心玩法造成致命影响，或者可用其他现有代替的，都可以移除掉的。经过系统剪枝后所保留下来的原型，就是不可量化游戏的可表达玩法的最小原型。
这种练习也可以帮助新手策划理解如何编写一份策划案，如何设计一款游戏，如何最快速的表达游戏的核心玩法是什么？我以前写过一篇文章，即《模拟经营类游戏玩法综述》，在该文章中，为了描述模拟经营玩法循环的量变和质变升级，我提出了一个极微型的模型，叫葡萄树模型。
在葡萄树模型中，玩家会经营一片农场，系统提供了一个商店，商店中任何的道具都可以买入或者卖出，商店中的道具现在包含了葡萄树和葡萄。葡萄树每个100金币，葡萄每个10金币，玩家初始会有200金币。玩家可以消耗1000个金币来升级商店，商店升级后可以购买或者销售两种新的道具，即榨汁机和葡萄汁。榨汁机的价格为300金币，葡萄汁的价格为50金币。玩家可以消耗10000个金币来升级商店，商店在升级之后可以提供两种新的道具，酿酒桶和葡萄酒，价格分别为1000金币和100金币。
葡萄树模型是一个非常微型的模拟经营类游戏原型，它甚至比开罗游戏更加微型，只满足最基础的游戏循环，但是它足够直观而且可以立刻用一个Python脚本来实现成为具体的可运行原型，甚至花不了一两个小时的时间。
葡萄树模型只是单纯的在描述这个游戏的结构是怎样的，虽然部分地方有所简洁比如没说农场的地块数量或者葡萄树的生成公式或者计算模型等，但是大概我们可以知道它的运作逻辑。但是这样一个模型是如何得到的？是经历了怎样的探索取得的？它也许是通过对别的游戏进行系统剪枝得到的，亦或者对模拟经营类游戏的本质进行抽象后总结出来的，它就是作为策划或者作为制作人应该要去提炼和总结的内容，而在此之上又会增加怎样的细节设计，生长出何种“枝丫”，则是根据题材或者契合度来进行判断。
2.5.3 对游戏构型的总结
无论是可量化的游戏，还是在游戏不可量化时构建最小的可表达玩法的原型，都是在尝试以最小的代价或者成本去进行玩法的测试和打磨，在开启真正的大规模美术和程序任务的推进时，这样的测试可以有效的保证游戏结构的稳定，这与前面说到的成本惯性是一个目标。
2.6 带有战略或阶段目标的产品立项
先做出一些失败的作品，个人认为是有意义的，大部分优秀的作品都经过漫长的迭代和技术的积累才能做出来，一款庞大的游戏作品，它的开发团队需要经历多个阶段项目的历练。于是在团队建立之初，将目标设为一个庞大的项目也许并不合适，将其拆分为几个独立且完整的项目更好。
举个简单的案例，B站UP主Gamker曾经做过一款游戏叫《宅物空间》，这款作品并没有太多的玩法，就是单纯的给定一个方形的空间，玩家可以选用各种家具来布置这个空间，通过截图的方式来分享自己的房间设计，与其说是一款游戏，更像是一款软件。
不清楚Gamker做这款作品的初衷，但是从发展的视角来看，通过制作这款作品，必然会积累一定的经验和技术。我们很难在一款作品里成功或者做出多么亮眼的成绩，所以不妨将设立几个战略级的目标，比如要做一款作品，通过这款作品，我们要积累怎样的技术、达到一个怎样的阶段目标，从而为下面的目标做准备。
这其实与为什么要登月类似，研究登月的过程中所积累的各项技术和成就不是孤立的，它们可以被运用于各方各面比如核磁共振技术，而更早的导弹技术也可运用于航天，大疆无人机的航拍技术也可运用于军事技术，军事工业技术也可运用于民事工业生产，比如二战时期虎P坦克的电驱系统研发者费迪南德·保时捷后开创了大众车品牌保时捷。
如果要做一款多人在线对战的枪战竞技游戏比如CSOL的话，这个目标对于独立团队来说就未免太过于庞大了。相比之下，于是先制作一款FPS单机作品就显得更为容易，也更适合作为一个更好的阶段目标，通过制作这款单机作品去积累各类研发技术、团队管理等方面的经验是更好的，对于独游的开发来说更是如此，比如《星露谷物语》和《饥荒》最一开始都不支持联机，星露谷物语在爆火之后也才在1.1版本中引入了官方的联机系统，此前只有个人开发者为其做了联机Mod，饥荒也是一样，只是饥荒并没有将联机作为一个独立的功能，而是作为了一个独立的版本，叫饥荒联机版。
也就是说，在维持团队生存的前提下，应尽可能将一个大的目标分割为几个战略级目标从各个阶段目标中吸取足够的经验和正向反馈。如果上来就完美主义，反复修改也害怕失败，害怕自己的作品被抨击和评论，那么永远也无法生长出丰满的羽翼和蓬勃的肌肉。只有挣扎着生存下去，才有更可能制作出优秀的作品。
三、工作制度篇
在内容推进的过程中，漫长的开发周期和松散的目标结构会使工作室的进度变得很慢，摸鱼划水的问题也会很严重，思考和探讨的流程也可能会变得很浪费时间，所以如何构建简明扼要的制度体系是非常重要的。
3.1 独游工作室和大型游戏公司的区别
我曾提出过一个简单的问题，去大型游戏公司工作，是否可以学到更多知识和技能？如果这件事不经思考的话，其实大家的答案都是会的，但是我习惯于把问题分拆的更仔细一些，因为这个问题有一个很简单且直观的反思，即如果个人没有足够多的知识和经验，那为什么能够去到大型游戏公司工作呢？
这里就是问题的关键了，其实能不能学到东西，是一个可以进行推断的思维训练。大型公司的运作，依赖的不是个人的主观能动性，而是制度。公司不会因为员工偷偷地摸了一天的鱼而直接倒闭，但这是一个结果，即公司需要将个人对公司的影响力降到最低以维持自身的韧性和稳定性。不至于某个人离职就导致公司运转不下去了。如果你是公司的老总，你打算如何提高公司的韧性呢？
深入思考这个问题，如果一个员工离职公司就运转不下去了，其实代表着这个员工肩负着非常重要的职责或者承担了很多核心工作，当然，员工离职导致公司运转不下去这个案例过于夸张了，可以举个更加正常的案例，一个员工离职，导致某个业务部门停摆了，或者某个业务部门的工作效率大大降低了还是有可能的。这都代表着工作部署上，这个人被部署了太多工作导致的。
所以，解决问题的方法很简单，就是分割这个人承担的职责，分割他的职责本质上也是在分割他的权力，正如明朝朱元璋采用三省六部的内阁制罢黜宰相一样。举个简单的案例，在手游或网游公司，策划部门往往是多个职位构成的，比如文案策划、数值策划、系统策划等。分割的更细一方面是提升职业的专业程度，一方面也是在提高公司的韧性，如果整个公司只有一个策划，那么这个策划离职了，从离职开始到设立新的招募需求再到面试、选拔、任务交接所产生的摩擦性时间成本是非常大的，关键是此时公司的策划工作完全处于停摆状态。
但是如果将策划的工作分割的更细，如果文案策划离职了，至少不影响其他策划工作的展开，如果希望进一步提高韧性，还可以将文案策划岗位的数量设为多人，只是这样也提升的公司运营的成本。但总的来说，可以推断的是，公司为了降低自身运转的风险往往会将个人的职责分拆的很细，招募基础岗位只是为了完成相对基础的工作，很难进入到这个公司的高层，但是换而言之，如果是作为执行岗位，进入该公司就直接来到了管理层或者接近管理层，那这个所谓大型公司可能规模并不大。
所以去到大公司是可以学习很多东西的，但是可以学到的内容偏向于经验性内容、例如管理模式、交互体系（文件交换系统和版本控制等）、技术栈（比如黑神话悟空团队采用MotionMarching构建3D角色的动画系统）、生产管线（比如米哈游公司在疫情期间、在线上工作的基础上仍然保持高频率更新，其工作管线体系必然十分优秀）等内容。所以个人感觉在公司可以开阔自身的眼界，但对个人专业方向的技能提升有限。
3.1.1 对制度的解释
说明独游团队和大型公司的区别，主要是建立起一个意识，即独游团队靠的是个人的主观能动性而非制度，也就是很多人做独立游戏偏向于我想要做独立游戏或者我喜欢做独立游戏而聚集在一起的，于是独游团队无法建立起完善的制度体系，这是在探讨工作制度时首先要有的基础认知。而我们在此处所涉及的制度，更多的其实是一个关于内容制作的广义概念，可以将其理解为一种粗糙的生产管线，一种大概的探讨规范或者协定等。
举个例子，现在团队假设有几个人，关于游戏怎么做，大家都有想法，于是可以建立起一个简易的规划机制：
- 在设计某系统之前，由所有人准备多份设计预案
- 开会进行预案的介绍和探讨、所有设计案探讨完毕后进行投票选择
- 如果没有投出一个既定的结果，就根据现有投票结果改进现有预案继续投票
- 重复2-3步直到方案确定为止。
当然，实际情况其实更为复杂，采用投票机制其实是一种很不靠谱的表现，只是我个人最初的队伍协议就是这么设计的。这就是一种工作制度，或者一种所谓的协议或探讨规范等。而前面谈到的公司的制度，更多的是惩罚制度或者审核制度比如早晚都要打卡，或者公司只招收工科专业的人等。以上，就是我想说明的一件事，即制度在本文中的含义。
3.1.2 加强团队的韧性
理论上来说，将职务分割的比较细节一方面是可以降低风险，另外一方面也是减少由于人员变动造成的摩擦性成本，举个简单的案例，在一个三人的独游团队，如果策划离开了，再招一个新的策划，那么整个游戏之前的所有内容都需要跟他详细的讲一遍，所以分割职务的另外一个好处就是前面说到的提高团队韧性。
在一人兼职多项工作的情况下，一个人的离开会对队伍产生很大的打击，包括职务停摆、心理压力、其他摩擦性时间成本等。所以提高团队韧性地两方面，一方面团队要有完善的文档体系，一方面是尽量减少实习和兼职需求。
3.1.3 如何看待制度
制度本质上是一种对某些执行或者决策进行标准化地处理，而标准化可以帮助团队反思制度或者结构问题。举个简单案例，为了每周都总结和反思一下游戏地制作进度，团队应该建立一个周会制度，每周大家不仅要展示这周地工作进度，另外需额外发表一下个人对于当前制作进度地看法，也许最一开始部分人有部分看法想提出来，但是事实上大部分人都是多一事不如少一事，也就是他们倾向于不发表任何观点，于是每周地这个周会的个人意见发表环节就慢慢变成了个人周报地汇报环节，因为大家都不再发表观点了。
特别要注意的是，这个过程中，没有任何人对制度提出疑问，也没有人觉得制度不合理，但是这个原本是个人意见发表的周会环节自然而然地坍缩为了工作周报。没有人刻意提到它，于是可以说，这个制度并不合理，以后可以改为：
每周所有人进行工作周报的汇报，并如果有任何额外的想法和意见都可以发表。
一般来说，某个强制执行的决策会帮助我们逐渐认识到原先设计的不合理的点并进而产生良好的改进，因为正如穿着不舒服的衣服始终会让你意识到这个衣服是不是有些不合身。但是这个任务无法继续把工作周报简化，因为这里留有了太多摸鱼和划水的空间。这就是制度的另外一个优势，即它本身其实是一个备忘机制，或者一种标准化机制，每当开始执行这样一个环节时，就像是填写一个既定的简历表格一样，一定要写姓名、民族、年龄等参数。设计这个简历表格的时候，它就形成了一种标准。
3.2 设立开发计划和会议制度
制作游戏是一个开发周期非常长的活动，我们很容易迷失在漫长的开发或者学习的道路上，尤其是没有上级监管对象的时候，所以此时就需要先指定一个开发计划，将开发计划视为一种监察制度，当然，很多时候一款独立游戏毕竟是自己设立的开发项目，如果开发周期逾期了也没有惩罚制度，但是如果制作人不能将其视为一种错误或者问题进而批判或者反思自身的话，那我认为这样的制作人是非常失职的。
3.2.1 开发计划
指定开发计划往往分类型来进行处理，但是如何设立一个良好的开发计划呢？还是分层处理问题的思想，即找到合适的点对现有问题进行分割，首先注意设立开发计划并没有一个严格的模板，因为目标到底是怎样的游戏我们是不清楚的。
但是无论什么游戏，总会分为开发阶段和QA阶段，所以是否可以将开发计划分为开发阶段和测试反馈打磨两个阶段？如果来到开发阶段，那么问题会变得更简单一点，虽然不知道是什么游戏，但总的来说肯定会分为内容填充阶段和Demo开发阶段。如果来到Demo开发阶段呢？即便不知道要做什么游戏，它也肯定肯定会分为预研阶段和原型测试阶段。如果继续来到预研阶段，它又可能分为立项调研阶段和纸面原型测试阶段。
围绕目标设立开发计划
当然，每个节点都会继续的细化和分割，至于分割的多细，有没有节点是不必要的，则根据具体的游戏来选择。这就是一种制定开发计划的方法，即根据游戏的阶段找到一个合适的节点对目标进行二分。这是一种围绕制作节点而设计的计划展开办法。当然也有不同的开发计划设立办法，比如根据开发周期来设立开发计划，如果打算利用12个月的时间来构建一款作品，那么可以将游戏分割为6个版本代号，当然不一定是6个版本，具体分为多少个版本可以根据内容来计算。相比于围绕目标展开的开发计划，以开发周期为主的开发计划以时间为核心驱动因素，如下图所示：
围绕周期设立开发计划
当然还有更多的描述计划的方法，而且很多时候这些计划表的构型是相互混合的模式，比如内容填充计划里会以时间为主要因素，但是整体的开发计划以目标为主。
3.2.2 建立沟通制度
一个抽象的行为比如对游戏进行立项往往由于其过于抽象而无法被有效的探讨，就好像马上就要开始探讨立项的问题，我们应该如何进行有效的沟通，说白了，沟通过程中太需要一个有效的沟通模板了。
举个简单的案例，假设某游戏工作室是某个公司的子工作室，作为一个项目的负责人，需要周期性的汇报现有的开发进度，就应该设计一个完善的汇报模板，如果每月汇报一次，它就相当于属于月会汇报。说白了就是通过一个简单的会议说明这个月干了什么。
这就是一个模板，或者一个表格，而每个月或者每周需要填写一份这样的表格以展示最近的开发进度。但是母公司也许存在各类其他的工作室，对于上级对象来说，这样的一份汇报是缺少上下文的，即为什么会有这样的一个开发计划？所以相比于某月的开发计划进度，它更像是某月在某个版本计划下的进度展示：
而且大概率版本计划不会即刻在1个月内完成，所以大概率还有部分内容是没有完成的。
这样就构成一个相对完善的月会汇报的会议模板，但是情况往往可能会更复杂一点，比如开发计划中，部分人比如玩家甚至是领导认为0.x版本中某些计划是不合理的（虽然这样的不合理应该消除在开发计划设立之前），从而导致了开发计划的调整：
这样也许完善了，也许还不完善，也许太复杂了需要简化，也许我们压根没有汇报的需求，但是它构成了一个沟通制度，因为汇报或者对开发计划进行总结这件事只是日常开发计划中一个可能存在的一个需求，而这样的一个模板，就是沟通模板，我个人喜欢将其称之为会议制度或者沟通模板。针对不同的事件或者目标完全可以建立不同的沟通模板以简化思考成本。
3.2.3 建立评估模板
评估或者评价，往往是针对满足同一需求的两个或多个选项而展开的，比如零几年的时候，学校旁边的诸多小卖部有很多小零食卖，而你手里的钱可能不多，你需要对有限的资金购买什么样的零食进行评估，如果购买棒棒糖这样的食品，一根就比较贵但是美味且足够吃很长时间。但是如果购买类似于话梅这样的食品，你可以把话梅分给其他小伙伴从而换取他们手中的小零食从而品尝更多的滋味。
简而言之，评估大体分为两个方面，一方面是建立针对单个对象的维度画像，一方面是针对多个对象进行评选。维度画像是根据需求建立的，我们需要设计不同的评估维度来应对不同的问题，举个简单的案例，如果要实现游戏中的某个系统玩法，大体的做法有两种，两种都可以，而且比较难抉择，这个时候就产生了评估需求了，因为如果一种方案存在致命缺陷或者被另外的方案全线碾压，那么压根就不会存在争议。
针对一个系统的实现方案的评估，大体是针对它的两个方向的维度展开的，一者所消耗的成本，一者是所产生的结果。成本侧最基础的就是美术成本和程序成本，当然还会有策划成本但是一般来说程序和美术是核心要考虑的，结果侧则有两种类型，一种是所产生的优势、一种是所产生的副作用，因为很多时候，很多系统设计方案是会附带一定的副作用的，正如延迟渲染对透明渲染的支持较差一样。于是我们设立四个维度：
对于对于策划组来说，每个人都可以根据现有的维度提案对目标方案进行个人视角的评估，满分为10分，由策划独立打分。
- 美术成本（A方案：7.0）/（B方案：10.0）
- 程序成本（A方案：5.0）/（B方案：10.0）
- 额外优势（A方案：10.0）/（B方案：1.0）
- 新增劣势（A方案：10.0）/（B方案：10.0）
注意这里的10分指的是这个维度表现较好，美术成本10分指的就是美术成本很低，收集评分可以建立其对维度的更准确的画像，从而进行更好的分析。
评估画像的雷达图
其实在经历较多议题的分析后，我们发现，本质上问题的维度都是在利用较少的成本换取更多的优势，也就是在追求方案的性价比，所以大概可以得到以下的公式：
但是特别要注意的是，最后所计算得到的性价比参数只是一个参考值，因为真正的设计方案非常复杂，而将其量化为一个简单的数字本质上就是一种对信息的阉割。但是有了该参考参数，总的来说整体的评估还是会更加稳妥一些。
但是这个维度信息也是简化过的，因为在讲到评估维度的时候，我们压根不知道议题是什么，如果我们追求的是对一个老旧系统的替换或优化方案，那么就得到了一个新的维度，即优化程度，如果需要对成本进行更完善的描述也许我们会将成本拆分为开发成本、维护成本、外包成本等多项成本因素。于是我们会得到不同的评价公式：
但是无论如何，还是那句话，这个计算结果只是一个帮助你进行判断的评估参数，它既不是最终的答案，也不值得过分的依赖。
3.2.4 建立评估流程
评估是一个比较复杂的行为，我们往往也会担心评估对象的单一致使评估结果的失信，于是也许我们需要建立多轮评估形成完整的评估流程，比如你可以在设立方案之初进行自我评估，如果你的评估出现误差，不妨再让小组进行评估，如果组内也没有好的意见，也可以交给其他更具权威的人士进行专家评估，比如交给主策或者其他更有经验的策划进行评估。如果仍然存在争议，最后可以交给用户进行评估。
但是特别要注意的是，如果走到了专家评估这个流程仍然存在疑点，那么这件事本质上就说明了两者的优势和缺陷是比较难以抉择，这个时候我们可以启用简易策略：
评估流程
任何争议较大的问题在短时间内无法甄别或者决断的，可以直接选择成本更低或更易完成的那个，这样的决策策略称之为简易策略。
简易策略是一个题外话，在日常的开发过程中是非常有效的一种解决问题的方案。当然，这是最后的决策手段，通过建立评估流程以评估的方式精确的找到方案之间的问题是最佳手段，因为往往两个方案之间的区别有的时候很模糊或者难以描述的的，于是我们必须建立相对完善的评估维度来加以描述和完善的评估流程去强化评估的准确性。
3.3 建立工作调度模型
大型公司为了简化管理结构，一般会将一个大型公司划分为多个部门，由部门负责人来统一负责一个方面的工作，但是对于由一个制作人来统筹所有开发工作的独游工作室来说，过分扁平化是一个常态，也是一个巨大的问题，制作人的压力会比较大一些。在部署任务的时候，我们其实遇到过一种特殊的任务部署的阻塞问题，这种阻塞问题是由于部分工作由于存在其前置任务没有完成而无法展开的情况。将其称之为阻塞很形象，因为编写程序的时候就存在着非常多的同步代码结构导致的阻塞问题。
什么叫同步结构呢？就是严格按照顺序执行，如果B完成他的任务依赖A的任务先完成，那么B就会等待A的任务，直到A的任务完成为止，B都处于阻塞状态，也就是空闲状态，这样的情况或者问题就是同步阻塞。
任务依赖
现实中更为复杂的点在于，B往往不知道自己要干嘛，也不知道自己有哪些其他的任务要处理，B被A阻塞只是你在思考任务部署过程中的一种假想，你需要将B的其他工作放到前面来让他完成，于是你需要安排一张错位的工作计划表，设计这样一张表，我会将其立即为一种工作调度模式的设计。
阻塞问题不仅出现于这种依赖问题中，其实很多组织结构中都会存在各种各样的阻塞问题，比如拍电影的时候就不会一个片段一个片段的顺序拍，我完全没有拍过电影，也没有学过任何相关理论，但是如果我是导演的话，最能直观的感受到的就是拍摄成本问题，于是我会将拍摄成本作为最优先考虑的点来进行拍摄任务的制定。
假设我们的电影要在三个场景A、B、C中拍摄， A在大型城市，B在乡村，C在某景点。那么为了运载所有剧组人员和食宿所产生的成本就很大，于是我们不得不将拍摄计划围绕在三个场景中展开，整个电影的所有分镜脚本制作完毕，就从中筛选出在三个场景中拍摄的脚本，然后去到不同的场景中进行拍摄，也许电影的开头和结尾都在A场景，但是过程中在B，局部在C，那么也许我们是先拍完了电影的开头和结尾然后带着所有剧组人员去到B中进行剩余部分的拍摄，最后将所有的片段剪辑为一部完整的电影。
这个过程中也会产生额外的成本，比如造型成本，如果一个角色的造型非常复杂，那么化完妆就应该优先拍摄与之相关的片段，于是拍摄计划会逐渐形成一个树形结构，再扁平化为日程表方便排期。当然现实可能会更复杂一点，因为某些电影会启用某些明星而产生更多的演员成本，但是无论如何，围绕的永远都是那些成本最高的部分。
和拍摄电影类似，制作游戏也有相关的编排逻辑，虽然游戏制作过程中不存在和电影完全类似的结构，但是通过编排任务解决同步阻塞的问题的起因是完全一致的，称他为同步阻塞问题是因为我第一次认识到阻塞问题是在代码中，所以说不定真的可以通过程序的手段来解决它，为此我们可以引入一种叫生产者&消费者模型的结构。
生产者&消费者模型建立的核心是引入一个中间队列，这个队列是一个等待处理的任务队列，所有的对应工作者（此处可以将其称为消费者）从队列中取出任务来完成，而策划则负责向其中加入新的任务（此处可以将策划称为生产者），这样构建一个错位的工作序列。
生产者&消费者工作模型
图中的场景美术工作池就是一个工作计划队列，这个工作池的深浅也会影响到策划的工作排期，策划在部署计划时应当考虑各个部门工作池的深浅以免产生其余工作单位的工作阻塞问题，这就是生产者&消费者模型
当然，这个工作调度模型只是一个非常简单的示例，而且现实中并不一定会采用这样的工作模型，关键是我们应该尝试学会自己设计调度模型去完成各类繁复的组织性工作计划。这就是本节的核心启发，即设计工作调度模型。
总结
以上三篇内容就是所有我想说的部分了，当然还有很多课题和想法由于各类原因没有写入这篇文章。
怎么说呢，成为一个制作人是一条相当艰苦的道路，和产品经理不同，制作人除了统筹开发计划之外，可能还得亲自上阵干活，这个过程中很多事情都需要自己来决断和决策，以上每个细节点都是一个曾经踩过的坑，没有资金、缺乏完善的惩罚制度是一切问题的核心矛盾。所以独游制作人需要在有限的资源中做出更好的作品，就需要关注一切成本问题，从而为团队保留足够的实力以应对不期的结果。
希望以上内容对你有一定的价值，感谢阅读，同时再次感谢@ComfyFinn提供的封面图。
文/王子饼干
原文：https://zhuanlan.zhihu.com/p/690749704
|
|
发表于 2024-4-17 09:39:07
