永远缅怀开始从事游戏开发的日子

学校里永远觉得事情都很简单,只要愿意,就会水到渠成,但学校归学校,现实归现实。我很乐意和你分享在写代码阶段闹出的洋相。在写iOS游戏的过程中,我发现有些事情和我想的不一样。

10) “快完成”和“完成”之间的距离比你想的更远

不知道你有没有见过这个游戏,它是一个很古老的记忆游戏,你需要翻开一张牌,然后,还要再找到另一张和它匹配的牌。不一样的地方是,你只会在某张牌的上下左右找到与之匹配的牌。意思就是你匹配的两张牌一定紧靠在一起。这就增加了一点难度,我必须保持所有牌的匹配牌都紧邻着它们自己。

我花了几个下午弄出了原型,期末考试快到了,挤出这点时间不容易。这游戏现在看起来像这样:

永远缅怀开始从事游戏开发的日子

所有组件都在这了,想必不要几天就能完成了。

仅就时间而言,游戏内容本身只需要5-10%的时间就能做好。然而,对于游戏的软件架构和具体实现有相当多的内容需要做,纹理,动画,保存系统,成就,音效,计分系统,web结构,还有许多其他琐碎的东西都等着编码。你在学校做的大部分项目都是教学demo,而大部分的教学demo都不是一个完整的产品。

09) 简单并不意味着它不消耗时间

在开发阶段,我安排了整个周末来完成这个应用,当时我打算花一小时来完成一个牛逼的计分系统。但最后,那花了我一天。

这个高档的计分系统要针对游戏做各个方面的计算,给每个有需要的地方打分并赋值给变量,并把它添加到结果里。但是,首先你必须先得到你要打分的设备,校准设备,保证它不会产生错误的分数,确保分数能存储并且在有新的高分时替换之前的高分。噢,你还必须完整的测试它。

核心功能所花费的时间最好不要超过总时间的十分之一,想知道为什么吗?因为花费在应用上的50%的时间都是花在了你玩游戏的时候不曾预料到的事情上。滚动GUI不难,我第一次写图形界面的时候就做了它,但是现在却要常常维护它。

我之前做过更复杂的项目。这个春天,我写了一个比这个游戏复杂的多的游戏引擎。它只是把很多小片段组合在了一起,最后它变成了一个很长的项目。

永远缅怀开始从事游戏开发的日子

08) 细节也会绊倒你

回想你以前的编程经历,当你的代码编译完,但是却无法工作,你一遍又一遍的检查源文件,最后你发现:

if( var = THAT )
{
}

这种小而气人的bug不会因为你在做一个大项目而消失。他们往往会蹦出一大堆怪异的API错误提示,说这些造成了你的程序出错,而不是真正错误的那行代码

所以,如果你想要一个人完成RPG游戏作为你的第一个项目,请记住类里的这种单行bug有多让人厌烦。被烦多了,你就知道要如何避免这种类型的bug,不管项目是大是小。

07)了解和理解是不一样的

项目的早期,我用OpenAL给iOS做了一个音乐播放器。我再windows上做过相似的东西,完全没难度。流程就是你读取音乐采样,然后放到音乐队列里,播放它们,如果采样播放完了,你可以加载更多的音乐文件。

看起来没啥问题,iOS SDK有一个解码器刚好有所有我需要的功能,但是不知道什么原因导致了音乐不能循环。在调试运行后,我发现音乐播放完后应用会读取0采样,但是我明确的告诉过它要读44100采样。几次重编译和Google一下以后,发现是读取采样的函数结构有问题,这个结构有一个可变的采样尺寸。当音乐播放完时,他就会读取0采样并把相同的结构回送,造成了这个函数读取0采样。

当你坐一个项目时,你可能会想“我知道怎么做”。然而,除非你之前做过,否则你仅仅是有怎么做的想法。“我知道”和“我有一个如何做的想法”是不同的,它们的区别可能会让你头疼好几个小时。

06) 理论不能代替经验

有一个观点是:患病的计算机科学界真的需要酒精来消消毒了。在你上Java数据结构课的时候,他们总会大言不惭地跟你说:“(数据结构跟语言无关),无论你用什么语言来写都是一样的。”不对!妈蛋的,完全不是这样!

记住,你是在用计算机工作。如果拼写错误,就算同一台电脑也无法编译你的代码。那些最鸡零狗碎的细节会造成你的程序无法运行,包括那些与你使用的编程语言或操作系统相关的怪异细节。

在这个项目之前,我曾做过GUI,图形学,多线程,音效,C++和游戏编程。这个项目也和我以前用其他工具做过的项目在概念上类似。我想说的是,编译器无法靠理论来编程,它要靠代码工作并且会在遇到许多小错误时抛出异常。这就是软件工程师不害怕机器人启示录的原因。谁会害怕一个因为引号错位了就会崩溃的东西呢。

毋庸置疑,理论很重要,但我的目标不是像教授一样教理论(或者获得终身职位,我就可以中途退休了)。我要得到软件必须动手去做。理论理解和动手实践是不一样的,动手实践意味着电脑前的无数个不眠夜。

05) 编写软件不是部分的简单叠加

即使你会图形学,媒体编程,GUI编程,但这并不是说你一定知道如何把他们整合到同一个应用里。你不仅要编程其中某一部分,还必须要把它们组装在一起并且流畅的运行。噢,说比做简单多了。

你设计/实现/测试A部分,然后又设计/实现/测试B部分。直到你意识到它们需要重构才能一起工作之前,一切看起来都很完美。由于时间不够了(你总是时间不够),你想着用非常规的方法来组装它们实现功能,这样反反复复,噢,像滚雪球一样越滚越大(越来越糟)。随着其他人加入到你的开发团队,你就会要面对设计上的挑战了。

设计不是一项能在课堂上就教会你的技能。需要通过经验,尝试,试错,以及遭受过几次意大利面条式的代码,你才能学会设计的诀窍。

04) 游戏开发不仅是编程

为了让这个站点的设计能引起读者的注意,我已经艺术得能够七十二变了。对于游戏编码来说,我认为必须要有艺术设计规范。我特别了解艺术规范的必要性。因为每一次(和美工)的理解误差都会导致美工设计人员不得不去画板面前再解释一遍,这么做又费时又费力,公司管理层对这种事情可是很不爽的。(作为美工设计人员,)你不能仅仅就是说“我需要一个按钮”,因为程序员和美工之间关于“这个按钮”的想法很可能是千差万别的。

当你为游戏公司工作时,你还需要记住一件事,你是在为游戏公司工作。他们是来挣钱的,你得和这些生意人有交流。你可能要接触市场,还要处理他们搞出来的臭狗屁。他们在经历了New Coke(译者注:可口可乐失败的营销案例)一样彻头彻尾的失败之后,名声尽失也是可以理解的。但他们也带来了美味的Betty Crocker的蛋糕粉(我依然留着)在20世纪50年代,Betty Crocker的蛋糕粉虽然看的人很多,但是买的人很少。后来被雇来营销的销售公司想出了一个提高销售量的办法。他们发现如果家庭主妇的饭做的不是很好,她们会觉得内疚。销售公司为了解决这个问题,开始指导用户如何添加鸡蛋和蛋糕粉。这带来的成果就是这种蛋糕今天依然在卖。你可能只是希望你的游戏能运行就好了,因为游戏好不好卖和游戏开发者不挂钩。

在游戏行业中,你必须和那些不懂循环(编程)的人打交道。这些人说着稀奇古怪的需求,理解他们说的是什么,很重要。

03) 专业的测试人员很重要

游戏快完工时,需要为游戏在AppStore的上架审核做准备。你听到的所有关于游戏测试很乏味的消息都是真的。一旦你开发并发布了自己的游戏,你就知道为什么了。

如果你是一个程序员,并且你读到这了,你就知道要如何精确的编码了。在不熟悉的领域里,大多数琐事都会让你焦头烂额。有一个团队来帮你解决这些事可以节约你编码的时间。

作为程序员,你要学会说“我的已经做完了”。使用其他的团队来寻找、记录bug,你可以与它们发起一个(针对游戏bug)的比赛,它们破坏,而你修复。最后,你就能获得一个强劲的,流畅的,bug很少的游戏。

02) 最后期限是你的头号敌人

所有问题看起来似乎都只是小事。就他们单个而言,可能是这样。但是当他们放到一个app里时,这些问题就会迅速积累。时间是有限的资源,知道如何准确的预判时间(项目周期)是很有价值的。

学习估算项目周期是一项软件工程课不会教给你的技能。以前,我和同伴有过一个新项目,我没有跟踪进度,项目团队一个夏天都耗在了RPG的讨论里。

有句商业名言“所测即所得”。在做项目时,保持每件事的进度跟踪很重要,甚至可以画一张简单的对照表:

永远缅怀开始从事游戏开发的日子

这会锻炼你(自我管理)的能力,尤其是管理你最重要的资源:时间。

01) 学校的学习是最起码的

我们都听过比尔盖茨辍学的故事。并且总是忽视一个事实:他十三岁就接触了电脑,并且开始日日夜夜的学编程了。比尔盖茨辍学的故事之所以有那么大的吸引力,是因为人们总是想要不经过努力就成功。

但是不要只是努力学习,要聪明地学习。教学Demo不够。你想要开发一个100%完成,并且能被用户使用的软件。也许不会大受欢迎,但它应该是一个完成品。你会知道学校学习和真实的软件开发之间的微妙的差别。如果你是在学校做的游戏开发的培训,你是无法获得一些真正的游戏开发中需要的知识的。随着游戏行业的发展,需要你每一方面都有所了解。

牢骚到此为止,还请持续关注更新,更多干货和资料请直接联系我,也可以加群710520381,邀请码:柳猫,欢迎大家共同讨论

永远缅怀开始从事游戏开发的日子

上一篇:初入职软件工程师的血泪——C语言内存优化


下一篇:如何快速搭建一个简单的塔防小游戏