本文系用户投稿，不代表机核网观点
⚠️ 未经作者授权 禁止转载
大家好我是花火，今年连续参加了两届booomjam，非常幸运所有的项目都成功孵化了。这两次都是以制作人的身份参与整个项目都规划与制作，有一点点小碎碎念。我自知才疏学浅，项目成功孵化的运气成分非常大。主要还是希望本文能抛砖引玉，和大家一起学习交流，共同进步。
先浅浅打个广告，大家可以去体验一下《醒梦》与《层层坠梦》，文章中会引用部分游戏内容作为示例。并且《层层坠梦》目前正在booom投票阶段，喜欢的家人可以为我们投上宝贵的一票，感谢支持！
如何定义制作人？
制作人只是一个title，我觉更合适的称呼应该是小队队长。
它的作用只是告诉你自己：这些人都是你找来了，你已经和这个项目强绑定了，你需要对项目以及你的队友负责。
在独立游戏制作中，title不重要，重要的是你做了什么。我在队内说自己是策划和项目管理，只有对外交流时才会说自己是制作人。但同时我又承担起了制作人的权利和义务，我要为项目确定大方向，并对项目将要做的一切东西拍板。同时我需要处理好对内关系，保持团队的稳定，项目的推进。
一开始一定要确立边界，尤其是在这样一个短期的队伍里，你需要知道你要做什么。意味着你不能全凭喜好做事，要考虑每个岗位的每个诉求。
管好自己，管好团队
心态一直是个亘古不变的话题。我们玩竞技游戏，经常会遇到队内心态出了问题，又是骂人又是说丧气话，本来能赢的局都搞输了。
做游戏也是一样。既然你选择拉个队伍，就意味着：所有人都能生气，你不能生气。所有人都能急，你不能急。
不是每个人都有你那么丰富的开发经验，不是所有人都能看到整个开发流。大多数人只会基于他岗位的视角来看这个项目，这里为什么不能加新的需求，这里为什么不能加新的资源，你需要耐心的给所有人解释清楚，并且安抚好他们的情绪。
定好框架，逐级细化
先制定大的框架，一级一级往下细化。
最上层是你游戏的闪光点，即你游戏最吸引人的地方在哪里？
在考虑最上层的时候，不要被任何东西束缚，放手去想。没有实现不了的技术，只有想不到的设计。现在脑海中构思一个雏形，然后把他最吸引人的点提炼出来。
构思《醒梦》时，我想传达一种对弱势群体的人文关怀，因此他是一款叙事为主导的游戏。
构思《层层坠梦》时，我想对取景器玩法进行还原，因此是一款视觉效果为主导的游戏。
想清楚这些，下一层才是核心主题与核心玩法。
《醒梦》以人文关怀为主题，卡牌合成为玩法。《层层坠梦》则以卡夫卡梦核为主题，解密为玩法。
它们都是为了闪光点而服务，因此在某些时候你要承受他们为闪光点而让步。例如《醒梦》部分糟糕的关卡设计，是为了叙事剧本做的妥协。《层层坠梦》中有问题的难度曲线，是为展示更好的视觉效果。
再下一层则根据确定的框架落到具体的核心需求上：《醒梦》是剧本大纲与游戏关卡，而《层层坠梦》则是取景器玩法与视觉点草图
（视觉草图点，为了保证视角效果，我们决定由视觉点反推关卡）
再逐级往下则细化成各个案子。
这个根据项目类型不同差异很大，本文所思考的内容偏上层框架，下层具体的内容不展开。我自知专业能力尚不足，全当抛砖引玉，大家可以在评论区讨论。
《醒梦》在养老院探索时需要频繁的进行表里切换来解密。这为了让玩家体验阿尔兹海默症患者的思维模式，为了传达给玩家混乱这一感受，本质上是为叙事服务的。但不可否认，他的玩法上是糟糕的（或者说是没有达到预期的），因为受限于短期开发，所有的关键资源都必须要留给主线剧情，导致不少玩家都期待他有分支内容（实则并没有）。
可以看到，落到具体的设计点，都是逐级往上，为上一级的框架服务的：关卡为了玩法服务，玩法为了叙事服务。而我们也允许他带来一些问题，即我们为了解决一个大问题，允许一个小问题的存在。
框架还有一个作用是解决团队内部的设计分歧。我们个人每喜好不同，受到的教育不一样，经历的人生不一样，如果每个人都想表达自己的东西，那做出来一定是四不像。当我们的设计出现分歧的时候，如果仅凭个人喜好拍板，那必然很难做到客观。而且个人喜好很容易就发生改变，它是一个浮动的不稳定的东西。项目应该尽量讲究确定性，而我们确定的框架一定是落在纸上非常明确的。因此，当设计产生冲突时，我们应该去考虑哪个是最符合框架的，而不是考虑哪个更好看的。
例如《层层坠梦》中的钟楼场景的风格一开始是偏恐怖的，另一位老师觉得这样不符合我们所设定的卡夫卡梦核的框架，因此我们最后采用了这位老师设计的新钟楼。
预留窗口，谨慎改动
首先我认为要建立一个最基本的概念：你之前做的所有工作，如果你要进行推翻，他都有一个窗口期。如果过了窗口期，你的推翻与重新立项并无区别。
三周是一个很长的开发周期，你对你所做游戏品类的理解，会在这三周里极速加深。而三周又很短，对于项目来讲，它承受不了太大的改变。而如果你三周内又想重新立项，那基本上是完蛋了！
制作醒梦时，选题会开完之后，我们确定了游戏以叙事为主导，走的人文关怀主题。而后我们给剧本大纲预留了整整一周的时间。
于是在这一周的时间里，我们对剧本进行了数次推翻与迭代。但无论怎么迭代，人文关怀和叙事主导这两个概念从来没有改变过。
同样的，当我们将大纲细化，并制作成关卡后，我们发现了游戏中的诸多问题。例如支线缺失，合成逻辑生硬等问题。如果按照正常游戏开发流程，此时仍然是白盒验证阶段，应该对白盒进行优化然后二次验证。但对于gamejam来说，美术已经投入生产，部分卡牌已经绘制完成。
此时我选择不动剧情框架，不动大的关卡结构，略微调整几张影响特别严重的卡牌。因为如果动了大框架，必定会导致美术停工，且会增加巨大的设计成本、沟通成本。而新的设计是否会带来其他的问题，更是不得而知。
如果你的项目孵化不出来，它做的再好都没有意义。
进行项目排期，设立时间节点
如果开发周期定死了，其实排期是相对固定的。我的两部作品都是沿用同一个大排期，即第一周框架搭建，第二周内容堆量，第三周打包与添加细节。然而真实情况是，往往要第三周的周四周五才能把大的流程跑通，每次我都庆幸我在初期为项目预留了整整一周的时间。
你可以为项目设立各式各样的时间节点，同时需要为了他延期而预留时间，这个延期时间必须要在比赛时间范围内，否则它将毫无意义。
（层层坠梦的选题会时制定的排期规划）
进行风险评估，持续跟进，灵活调整
项目制作的时候务必要进行技术选型，写代码前一定要先进行规划。对于不熟悉的功能，要预留时间。例如我在制作《层层坠梦》的一开始就和程序说：取景器的那套功能，先简单摸一下，如果一个星期搞不定我们就让美术做固定视角的。
我说这句话的时候就是默认，程序实现不了我是可以接受的，并且我想好了应对策略。开发周期不长，如果短期搞不定要及时止损，与程序商量如何以最快的方式实现相对可以接受的功能。短期开发没办法十全十美，相较于无法落地，即使是用很差的效果代替也可以接受。
而且布置完任务也不是万事大吉了，必须每天去跟进任务进度。在《层层坠梦》中，我每天都会去和美术沟通，进行到哪一步了，有什么困难，会不会有延期的风险，延期多久。延期不能等着别人来告诉你，要自己一个一个去主动了解。
而当你和你的队友相处一段时间，队内队友的实力也可以摸清楚一二。毕竟一个团队，总有努力的、有摆烂的，灵活分配任务，不要去责怪别人或发脾气。你发脾气解决不了任何问题，你在短期内也无法改变任何人，你要做的就是尽量把所有的生产力都用上。
（向一位美术老师跟进进度）
制定优先级
先把大的效果传达给玩家，而不是沉醉于你的小细节。
对于项目，一定要有一个优先级。假设你的游戏明天就要上线，那你必须保证你今天做的所有东西都是它最需要的东西。不管是gamejam还是长期的游戏开发，最好有一张排期表。将的你需求往里列，而项目截止时间会是一条横线画在表格中间，你需要确保在那条线之上的东西都是最需要的。并且确保如果出现突发情况下，依然保证其是目前能做的最好状态。
不过对于短期gamejam而言，他可以非常简单，因为维护这样一张表格本身就需要一定的成本。
对于gamejam来说，玩家大多也都是开发者。因此程序有bug、美术没画完，大家其实都能理解。因此我偏向于分三个优先级：P0做不完不算游戏，P1做不完不算有获奖潜力，P2锦上添花的内容。
例如《醒梦》中美术并非按照关卡逻辑从头到尾进进行绘制，我将公鸡、鸡笼等关键内容划分到了P0，就是为了保证最关键的点一定能展现出来。至于游戏的其他小细节，收尾阶段能解决的解决，解决不了就由他去。如果你大的效果传达不到，叠再多小效果都是空谈。
（选题会时的优先级确认）
（醒梦按照优先级从上至下的美需规划）
非常感谢您看到这里，项目落地是一个复杂的过程，本文仅能概括我所在位置所看到的几个点。我这个人也比较笨，文章中有任何不对的地方，还请大家指出。若大家有什么其他不同的观点，也欢迎讨论！
评论区
共 3 条评论热门最新