【译】闯入游戏开发 #2:游戏开发的常见陷阱(以及如何避免它们)

作者:凌岚
2020-10-09
17 5 1

编者注

凌岚对免费书籍 Breaking into Gamedev(闯入游戏开发)进行了授权中文翻译,并将译文转交给 indienova 代为发布,分享给希望接触游戏开发却无从入手的爱好者们进行学习交流。indienova 会将译文分节成多篇文章更新,对整书感兴趣的朋友可以直接到下方的链接下载整书。同时,任何排版问题、翻译错误等意见建议,欢迎直接评论留言。

这本指南的作者 Steven Harmon 是一名至今(2020 年)有着八年开发经验的 USC 游戏设计本科在读学生,可以在 Steam 找到他开发的两款免费游戏:Awkward Dimensions ReduxGriptape Backbone

整书下载

*中文版有部分视频链接失效,建议中英都下载

#2:游戏开发的常见陷阱(以及如何避免它们)

我的大设计文档

有些人很有想法,但他们并不是游戏开发者。那些真正去制作游戏的人才是游戏开发者。游戏开发者可以很有想法,有想法的人也可以制作游戏,但无论你在纸上计划了多少,设计文档永远都不等于一款可游玩的游戏。不过这并不是说设计文档是毫无用处的,他们可以促进团队达成一致;并且游戏本身也是一个最重要的、活生生呼吸着的、持续发展进化的设计文档。


我自制的游戏引擎

你不需要深入了解游戏引擎的内部如何运作,便能在其中做出一款游戏。我见过一些有天赋、有抱负的游戏开发者在尝试编写他们自己的引擎后,在没有完成游戏 demo 的情况下就放弃了游戏开发。现在已经不是 90 年代了,如无必要,我们不需要去使用自己的技术。有大量第三方开源或免费的工具供我们使用,所以并没有什么理由让我们自己去造轮子。


原型设计!

为了成为一个游戏开发者,你需要去制作并完成一款游戏。不仅是完成一个 demo 或概念演示,而是做出一个可以供人游玩的成品(商业或非商业)。将你所有的游戏点子原型化是很好的一件事,但将这些点子留到你下一个游戏中去吧。在日志里写下它们,然后在着手开发下一部游戏前,先完成你手头上的游戏。同时开发多个项目当然是可行的,但前提是你在此前已经成功完成过几部游戏的开发。练习做完游戏,因为这是能够区分业余爱好者和专业人士的重要技能。


功能蔓延(Feature Creep)

一旦你有能力做出来任何你所想的东西,你就一定会想把他们全部都做出来,这样的念头永远不会停止。所以,把它们留到你的下一部游戏里去创作吧!始终考虑你的游戏范围界限。如果一部游戏在其最纯粹的形态下都不是很好,那么就算增加场景布置或打磨润色也是徒劳无功的,并不会解决它固有的潜在问题。完美很少来自在某件事上添加更多的东西。


我学到了很多,是时候重做了!

你的代码或美术永远不会至臻完美。如果你在做项目中得到了成长,那么你就是在做正确的事情。持续多年的长期项目是难以置信地倾向于重启,但你要抵制这种冲动。如果你的游戏太过复杂或无序,导致它的制作速度慢如蜗牛,那么就重构你的代码并继续前进——但千万不要完全重启!相信我,我也经历过,也做过同样的事情……太多次了。用“强力胶带”修修补补你的代码,它就又能运行了!这很好,真的。


人多反误事

每个人在开始时都充满热情,但热情是会被消耗的。你需要的是队友的勇气,是一个即使事情变得艰难,也要坚持到底的人。找到一位好的团队成员就像找到一位灵魂伴侣。你想要一个和你一样努力工作,和你一样投入,对你诚实,而且有与你相匹的技能的人。你想要的是那些有持续完成游戏制作经验的合作伙伴,但同样地,专业人士也不会想要与从未完成过任何游戏的人合作。制作一款游戏并不需要一个团队,而组装一个团队也不能保证一定能完成一款游戏。

通常的建议是找到 T 型人才,这些人拥有广博的知识并专精于开发的某一方面。不过对于较小的团队来说,最重要的成员还是那些能够身兼数职并能围绕手头的任务进行职能切换的人。

我的建议是,一开始你要有独立完成一款游戏的能力,再去寻找那些你信任并愿意合作的团队成员。如果你是一个项目的负责人,那就自己写代码吧!这样的话,就算你的成员离开了团队,项目依旧可以继续进行。如果你必须组建一个团队,你要在一开始就进行一场关于 IP(知识产权)所有权,资金分配(别抱太大希望)等游戏开发中所有不愉快的内容的谈话,因为你肯定不想要一场一团糟的散伙,结果就是你们的游戏由于法律原因永远发布不出来。


碰壁

游戏开发中碰到的“壁”可以是个 BUG,某个没有详尽文档描述的引擎特定的 API,或者是你需要发布的满是法律术语的合同,却没有解释和参考文件。无论如何,你需要去解决它,你将这些问题拖得越久,你就越会讨厌这个项目和你自己。所以去做吧!别让你的梦想仅仅只是个梦。

其他的解决方案包括:稍微休息一下,以获得一个全新的视角;和一只小黄鸭谈谈你的问题;(如果可能的话)仔细观察并删除一些麻烦的功能。