学校里永远觉得事情都很简单，只要愿意，就会水到渠成，但学校归学校，现实归现实。我很乐意和你分享在写代码阶段闹出的洋相。在写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，邀请码：柳猫，欢迎大家共同讨论