URL
status
type
date
slug
summary
tag
category
password
icon
五一期间与四名同学一起线上做游戏,我负责策划,最终的结果从标题中就可以看到,虽然有努力在干,但最终的完成质量很低,我认为这与我是脱不开干系的,最应该反思的人是我。浅谈我从这次经历中吸取了哪些教训。
立项
在开发过程中,每个人都是游戏的设计者,虽然策划在立项部分的工作量最多,但大家的和想法意见对于游戏来说都至关重要。大厂的不同部门间可能会有割裂,但在小团队中,每个人都可能身兼数职,会直接影响到开发的具体方向。所以需要吸纳众人的观点,对游戏的内容进行取舍。
切实的群策群力
道理容易明白,但有很多细节容易被忽略。一开始,我便提出需要去参考每一个人的观点,但大家对表达”我想要做什么样的游戏“、”游戏中应该有什么“的欲望似乎并不强烈,似乎就认为这部分可能的确是策划做的更多,所以让我放开思维去想,从这里我就忽视了一点,我没有刻意去激发他们的表达欲望,也没有很明确地表达出我的创作倾向,整个团队的方向都很模糊。
因为每个人的喜好各异,策划的设计是很难做到众人皆称道的,比如说,一个程序特别喜欢玩魂系的动作游戏,那么他就希望游戏中能出现一些战斗的元素。一个美术较喜欢偏可爱精致的画风,战斗元素就可能与之产生冲突,身为策划就应该考虑到这一点。否则,就会像我一样,即便是理解集体参与创意的重要性,但众人的所思所想没有真正地落地、诉诸文字的话,那到头来,策划就依然缺失一个具有现实意义的、能够描摹游戏设计基本走向的蓝图,就还是只能靠自己的想法去创作,最终的立项很可能会被推倒重来。
提升知识储备,提供自信
我还缺失一些带头指挥团队方向的勇气,这大概是因为理解的游戏类型有限,对于游戏品类的涉猎不广,如果是一个经典的RPG或FPS游戏,我可能会表现得很积极。面对只是玩过、喜欢玩但并不熟稔的游戏类型时,就会缺失自信,很难放开手脚去做。
分工协作
策划从头走到尾
团队中有策划,美术,程序,音乐等工种,分工是否协调就十分重要。而团队分工应该是透明的,至少对于策划是如此。直到后期,策划才拿到游戏的项目文件,一看文件目录,人都傻了,十几二十个文件夹几乎无序地堆叠在一起,谁看了都要爆炸,这就是项目开发的过程中。策划没有好好地追踪进程,组织管理(不是在给程序和美术打工就是在摸鱼)。
可视化并行协作
一开始我想要不要用Unity的PlasticSCM进行版本管理,但没有执行下去。最终变成了单向的互传项目文件压缩包,不仅低效,而且十分容易出现项目版本不一致的问题,就比如,你拿到的是𝜶版本,他拿到的是𝜷版本,虽然就只经过一次更新,但对齐的过程还是很消耗时间的,需要做的就有修改,增加和删除等工作。这是导致这次项目失败的根本原因之一。
之前有段时间自学过如何写策划文档,因为没有人和我一起做游戏,所以就没有特别注意更新日志和修改记录的这部分内容。然后这次我就忘了把更新日志和修改记录加进去。虽然写了需求列表,但是也没有严格要求大家去填,最后就只有我去填表,功能也就都是我设计的。由于集体的参与度不高,而且我又不是甲方,所以需求列表对于整个团队的参考价值就不高,更别提去落地实现了。于是就程序们就各自实现各自的功能,也没有标明谁具体负责什么工作,更不知道功能实现的具体情况。最终就出现了很多功能无法实现,于是砍了一个又一个,策划的心在滴血😭。
沟通交流
作为开发的管理人员,表达清楚自己的想法对策划来说尤为重要,和程序沟通时,策划应该把程序应该实现的功能定好,什么程序负责什么功能,而且要严格定死,即便是无法实现这个功能,也不能多了一个立项初期不存在的功能,因为这很可能不是策划想看到的,这就导致程序犯了一个逾越职权的错误。
对于美术的话,就需要明确其美术风格、内容和资产类型,尺寸比例需要经过后期处理,并确定产能。以保证在引擎中正常使用。否则就会出现,在引擎中用美术资产时,程序问策划:“这个图片的尺寸有问题,我没法用啊,你赶快拿去改改。“
确认美术与策划的工作次序,是策划依照美术输出的资产去设计,还是美术依照策划的设计去输出资产,游戏美术也应该能够使用引擎,至少能够将美术资产准确无误地导入到引擎中,否则这部分工作就可能揽到策划身上,策划就成了工具人。
- 作者:Cloud
- 链接:https://cloud09.xyz/article/1b90da63-2e74-43dd-868f-b1c1f9276370
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。