如何成为一个程序员(20120611184215).pptVIP

通过原型阶段提到了抓猴子，从最简单的概念到选择的技术。在原型结束的时候我们大大的提升了设计，但是仍然没弄个文档。 我们知道我们有12个工具要做，10种猴子，还有模糊的商店概念用于购买升级。如何升级以及他们如何操作都没确定下来。开始编码吧！ 美术是全职在做，但是我作为程序员，却只是兼职在弄。项目延迟，终于到达了一个点，就是基本没进度。 估算时间，估计还得6周(300小时)。6周时间里，我跑到乡下小别墅里100%专注到游戏里。到项目后期总结确认，这是搞定这个项目的正确的决定。 如果你仔细的研究植物大战僵尸里的僵尸，你会发现有许多种僵尸，但是他们是有拆开的头，躯干，手，腿组合成的，还有其他装饰品比如?头盔啥的。通过重用和稍微变化这些组件，可以用最小的内存消耗弄出一大堆不同的僵尸。 我们也需要弄到这状态，我们需要各种猴子，有个各种不同的能力和弱点。 我们很痛苦的学到了这个经验。如果你想采用这种方式重用，你必须定下非常特定的规则，确定角色什么能重用什么不能。注意僵尸始终面对镜头，不管他在干啥，他们从不转身给个侧面。 在我们的原定的动画和原型里，当猴子到来的时候，他会扑下来，转背，然后开始挖，当挖到东西后他转身过来，开始吃。当我们发现问题之前，我们弄完了一个通常的猴子。 当我们打算弄个戴帽子的猴子的时候，设想只需弄一个帽子，然后和普通猴子放在一起就完事。但当我们下手去做帽子的时候，发现帽子得跟着猴子转，比如背对镜头。这需要每帧都给个附件，并且像素级对齐。这表示我们得每帧单独的去挑坐标。我们不想重画挖掘的动画，于是我们有了个妥协的决定：只复制帽子在右边的时候的普通猴子的帧。美术去弄了6种猴子出来。 我们的计算公式： 1只猴子有一堆各种动作，吃了20M显存，7只猴子就140M。??Iphone3GS真正可用的只有?55M显存+15M内存，再多了就Crash了。Ipod Touch 2只有30M，?现在只好考虑把硬件需求提升到iPod3，以及想办法减容。  教训：在开始开发制作之前，也就是在设计阶段，就要规划内存使用，而不是在项目进行之中或者后期！ 如果可以避免的话，许多的应用开发者都会避免使用多线程的解决方案。为什么？测试两个分别干不同的事的线程是噩梦。太多的排列组合可能会同时发生，导致程序Crash，非常难以重现，更别提彻底的修正。当多线程到游戏里，他们总是在Update().没有 “blocking”阻塞的调用(比如在?Windows forms?开发中)。这只是游戏的方式，不是我想说的。 我在说的东西是，实时游戏和回合制游戏。一个回合制的游戏会等待用户输入，然后对应的做出响应。当等待用户交互的时候，可能有些事在屏幕上发生，比如很好的视觉特效。但是实际的游戏状态并未改变。在实时系统里，游戏的状态总是在发生变化，无论玩家是否交互。  对于我们的第一个游戏，我们绝不会选择去弄一个实时的游戏。 在《抓猴子》这个持续变化的环境里，让每件事都正常的工作需要付出难以置信的努力。相对于回合制游戏来说，测试场景会多达20倍。重现场景非常困难。即使程序员制定特殊的单元测试。后面有一些地方比如在构建节点，我真的无法确认我能把Crash修复掉。我痛苦的得到了这个教训。  OOP的力量是让我们能创建小的、专注的、封装的对象然后在更高的层次使用它们。我的目的是创建一个对象继承关系，这些对象知道如何实例化、移动、渲染它们自己。 Game Object是一个在Game Scene里被用到的对象。他管理状态、动画、深度计算、缩放，点击处理器、碰撞检测。所有游戏对象继承自Game Object. UIObject和Game Object类似，但是更轻量，主要用于非游戏场景，比如文本、按钮。 我的职业生涯里，有一段时间我不做建模。当我看到了UML工具Rational Rose后，我不再干这蠢事，我总是先建模。即使是个人项目，没人看的我都弄。我发现最好的方法是在开始编码前想清楚。 因为需要，我们使用了GoF的设计模式。比如： 我们使用工厂模式弄Level类，投入6天，做出1个格式化的关卡对象，包括必要的教学。 ??我们使用了2个?singleton模式来实现图像文件和声音文件的缓存，叫做Graphics manager和Sound Manager，?所以，即使每个对象都负责加载和卸载自己的东西，如果都通过这些缓存来完成，那么实际的内存消耗被最小化了。我们使用了一个Singleton来处理玩家状态(星星数量，当前进度，已经学了几个教程、已购买的升级部件)，?这让保存和加载玩家状态变得非常简单。 我们使用?Decorator模式来增加图像特效到任意一个Game Object，比如淡入淡出、闪烁等等。 最初，我是在尝试吧各种不同的屏幕(故事、工具选