1、,如何成为一个合格的程序员？,但是这是令人惊讶的稀有技能，这对软件公司有极高的价值！,成为游戏程序员的秘诀,完成产品 游戏上线,有趣,枯燥,“当你完成了第一个90%的工作，你必须完成另外的90%”,这另外的90%才是成功的关键！,BUG修复,程序编写设计,项目的完成,许多的程序员当进行到第2个90%的时候,累了、烦了、挫败、换工作、迷茫或者为延迟寻找各种借口,有一百万种方法让一个项目无法完成，但是只有一个方法可以完成项目：埋头苦干打磨，直到搞定。到这阶段，我向你保证，程序世界是属于你的。,案例：一个程序员的自述,http:/ http:/ http:/ http:/ http:/ http:/
2、 http:/ http:/ http:/ http:/ ,“Catch the Monkey（捉猴）”,从点子到通过App Store全球发行的编年史,团队介绍,美术在Sheridan学习动画,程序员自学，web/mobile软件15年经验，用的是MS的技术,Thomas,Alex,构思,1、Android是将来，iPhone是现在，我们两个都得做。2、希望在Windows平台上用熟悉的环境和工具开发。,构思,Marmalade允许用户所使用VC制作出的程序可以在各种平台运行(iOS, Android, Blackberry, Windows Phone, Bada, a
3、nd more)，模拟器很历害，包括各种性能监视器。对于个体开发者来说，价格也公道。,第一款游戏,最初的想法是：玩家用手在农夫地里抽猴子。每一关猴子越来越多，越来越快。,设计,这时候，看上去实在太简单，只有两个人，所以没有使用设计文档。,使用Xmind组织点子并保存“设计”,游戏的美术活太重，所以美术是全职负责这个项目，而我呢只在周末弄。,原型,商业软件里，一个给客户的初始原型非常关键,但没有真的原型，所以使用了一个便宜但好用的游戏制作工具(gameMaker8,$40)制作。这可以让我们把画的一堆图放在一起来看游戏性，检查游戏性是否有乐趣。这原型花了共20小时。,阅读Word文档造成的所有猜
4、测，都会被消除！,因为是在Windows屏幕上，所以没办法测试触摸/猛击的机制。只能依赖点击，每次点击模拟一次猛击。于是，大问题出来了：这游戏性好玩吗？,原型,不，不好玩。所以调整了一些变量(猴子的速度，点击，让他们笑，猴子的数量)，但是这还是太简单无趣。玩家没啥事可干。2分钟就没啥好看的了。我们可不想做个“恶搞游戏”，于是我们回到了绘图板！,原型,在设计头脑风暴会议上,产生了用各种工具来和猴子交互的点子！,原型,挠痒只是初始工具，一个羽毛。后面可以弄到其他工具，这看上去有些提升。所以我们开始想其他类型的工具。简化之后有了原型v2，版本里玩家有一包包各种工具，农夫会叫她太太来帮忙弄工具，但是太
5、太一会儿才出现。这让玩家思考，什么时候该用什么工具？,我们还让玩家可以控制农夫，可以让农夫移动到特定区域或者抓起一只猴子。最终我们加了抓星星的概念。星星会蹦出来，玩家必须去点取。星星可以用于以后升级。现在的问题是：这好玩吗？,好玩也不好玩。有核心玩法(快乐)在里面，我们得把它弄出来。但是仍然有许多事障碍着。我们知道，选择工具(策略)和抓星星是很好玩的(自发的不由自主的，不同并且有难度)。我们放弃了控制农夫(太笨重)，放弃了重装概念(太复杂武断)。我们需要一个游戏机制，让玩家制定战略并管理资源。,原型,总结,这阶段，我们坐下来开了第3次头脑风暴会议。在考虑魔法值/冷却机制之前我们遍历了大量的点子
6、。我们感觉到，如果我们建立一个公共的能量池，每个工具有不同的冷却，我们会弄到我们一直在寻找的战略平衡。通过有足够的变数来保持新鲜的并且对玩家有吸引力的事物，因此他们会被吸引住并在游戏中找到快乐。,总结,我们还决定弄个星能站，星星只是用来作为货币购买升级。当星星有两个作用的时候，玩家需要做判定，到底是要短期利益，还是长期收益，这机制很爽。这给我们作为设计者一个有趣的挑战，就是让星星真正的非常有用。聪明的玩家节约的使用所以他们可以拿到所有的升级。,随着设计阶段基本完成(实际上随时都在设计)，我们决定开始弄个游戏核心。,游戏核心-介绍,通过原型阶段提到了抓猴子，从最简单的概念到选择的技术。在原型结束
7、的时候我们大大的提升了设计，但是仍然没弄个文档。,我们知道我们有12个工具要做，10种猴子，还有模糊的商店概念用于购买升级。如何升级以及他们如何操作都没确定下来。开始编码吧！,美术是全职在做，但是我作为程序员，却只是兼职在弄。项目延迟，终于到达了一个点，就是基本没进度。,游戏核心-介绍,估算时间，估计还得6周(300小时)。6周时间里，我跑到乡下小别墅里100%专注到游戏里。到项目后期总结确认，这是搞定这个项目的正确的决定。,第一个最大的错误,如果你仔细的研究植物大战僵尸里的僵尸，你会发现有许多种僵尸，但是他们是有拆开的头，躯干，手，腿组合成的，还有其他装饰品比如头盔啥的。通过重用和稍微变化这
8、些组件，可以用最小的内存消耗弄出一大堆不同的僵尸。,我们也需要弄到这状态，我们需要各种猴子，有个各种不同的能力和弱点。,我们很痛苦的学到了这个经验。如果你想采用这种方式重用，你必须定下非常特定的规则，确定角色什么能重用什么不能。注意僵尸始终面对镜头，不管他在干啥，他们从不转身给个侧面。,在我们的原定的动画和原型里，当猴子到来的时候，他会扑下来，转背，然后开始挖，当挖到东西后他转身过来，开始吃。当我们发现问题之前，我们弄完了一个通常的猴子。,第一个最大的错误,当我们打算弄个戴帽子的猴子的时候，设想只需弄一个帽子，然后和普通猴子放在一起就完事。但当我们下手去做帽子的时候，发现帽子得跟着猴子转，比如
9、背对镜头。这需要每帧都给个附件，并且像素级对齐。这表示我们得每帧单独的去挑坐标。我们不想重画挖掘的动画，于是我们有了个妥协的决定：只复制帽子在右边的时候的普通猴子的帧。美术去弄了6种猴子出来。,我们的计算公式：1只猴子有一堆各种动作，吃了20M显存，7只猴子就140M。Iphone3GS真正可用的只有55M显存+15M内存，再多了就Crash了。Ipod Touch 2只有30M，现在只好考虑把硬件需求提升到iPod3，以及想办法减容。,第一个最大的错误,教训：在开始开发制作之前，也就是在设计阶段，就要规划内存使用，而不是在项目进行之中或者后期！,如果可以避免的话，许多的应用开发者都会避免使用
10、多线程的解决方案。为什么？测试两个分别干不同的事的线程是噩梦。太多的排列组合可能会同时发生，导致程序Crash，非常难以重现，更别提彻底的修正。当多线程到游戏里，他们总是在Update().没有 “blocking”阻塞的调用(比如在Windows forms开发中)。这只是游戏的方式，不是我想说的。,实时世界里可爱的猴子?,实时世界里可爱的猴子?,我在说的东西是，实时游戏和回合制游戏。一个回合制的游戏会等待用户输入，然后对应的做出响应。当等待用户交互的时候，可能有些事在屏幕上发生，比如很好的视觉特效。但是实际的游戏状态并未改变。在实时系统里，游戏的状态总是在发生变化，无论玩家是否交互。,对于
11、我们的第一个游戏，我们绝不会选择去弄一个实时的游戏。,在抓猴子这个持续变化的环境里，让每件事都正常的工作需要付出难以置信的努力。相对于回合制游戏来说，测试场景会多达20倍。重现场景非常困难。即使程序员制定特殊的单元测试。后面有一些地方比如在构建节点，我真的无法确认我能把Crash修复掉。我痛苦的得到了这个教训。,OOP的力量是让我们能创建小的、专注的、封装的对象然后在更高的层次使用它们。我的目的是创建一个对象继承关系，这些对象知道如何实例化、移动、渲染它们自己。,Game Object是一个在Game Scene里被用到的对象。他管理状态、动画、深度计算、缩放，点击处理器、碰撞检测。所有游戏对
12、象继承自Game Object. UIObject和Game Object类似，但是更轻量，主要用于非游戏场景，比如文本、按钮。,我的职业生涯里，有一段时间我不做建模。当我看到了UML工具Rational Rose后，我不再干这蠢事，我总是先建模。即使是个人项目，没人看的我都弄。我发现最好的方法是在开始编码前想清楚。,Object Hierarchy,设计模式,因为需要，我们使用了GoF的设计模式。比如：,我们使用工厂模式弄Level类，投入6天，做出1个格式化的关卡对象，包括必要的教学。我们使用了2个singleton模式来实现图像文件和声音文件的缓存，叫做Graphics manager和
13、Sound Manager，所以，即使每个对象都负责加载和卸载自己的东西，如果都通过这些缓存来完成，那么实际的内存消耗被最小化了。我们使用了一个Singleton来处理玩家状态(星星数量，当前进度，已经学了几个教程、已购买的升级部件)，这让保存和加载玩家状态变得非常简单。我们使用Decorator模式来增加图像特效到任意一个Game Object，比如淡入淡出、闪烁等等。,设计模式,最初，我是在尝试吧各种不同的屏幕(故事、工具选择、故事模式、标题屏、选项/菜单、游戏模式)弄到一起，组成一个结构良好的OOP返利。研究过程中，我发现了两篇不错的文章。,我知道，这个模式可能不只是用在当前这个游戏里，
14、而是以后我的所有游戏。,The Scene SystemThe GUI Stack,设计模式,这场景系统把游戏拆分成一系列的screens。在抓猴子里，最终弄了19个场景(比如标题、对话)。他们都继承了一个相同的接口，比如：Init(),Update(),Render(),Shutdown()，我创建了一个Scene manager的单例来容纳所有和创建、关闭、转换有关的逻辑。现在我的代码可以开心的到达高一点的层次。如果打算切换到一个新的场景，我就调一句话：SM-ChangeScene(new SceneShop();如果打算让一个新的场景被focus，并且在当前场景之上，我就这样子调用：SM
15、-AddScene(new SceneOptions();,这场景管理器Scene Manager知道如果当前有其他的场景设计到了，那么就把他们关闭掉，并卸载掉内存，然后做个淡入淡出转换，然后初始化，把新的场景弄出来。现在这些在一个实时的游戏里，行为很像Windows Form程序。包括可以调用对话框并且，只是让OS留意排序一下。,设计模式,第二个关键的概念是GUIStack. GuiStack在Scene manager里面，复制场景的焦点就好像Windows处理form和dialog一样。通过把状态压入和弹出堆栈，我可以控制哪个场景执行Update()和Render()，如果一个场景不接收Update()调用，那么他其实被暂停了。在纯form下，顶端的scene是唯一一个接收Update()调用。所有在堆栈里的都接收Render()调用。在后续的测试中，我去掉了调用每个场景的Render()以提高性能。对于需要背景场景的，比如游戏中的界面，我直接弄了个截图放后面。,设计模式,如前所述，我们现在就在基于VisualStudio2008的C+程序同时针对iPhone和Android系统进行开发。,2018/7/7,谢 谢 观 看,
