游戏编程模式-简介

本系列博客是：Game Programming Patterns 的中文翻译版本。

翻译的github地址: cyh24. 如有兴趣，可联系博主共同翻译，一起造(wu)福(dao)他人。

博客虽然水分很足，但是也算是博主的苦劳了，

如需转载，请附上本文链接http://blog.csdn.net/cyh_24/article/details/46868419，不甚感激！

本系列博客 目录，可点击进入。

简介

============================

在我五年级的时候，我和我的小伙伴们有机会进入一个教室，接触一台破旧的TRS-80s机器。为了能够激发我们的兴趣，我们的一位老师为我们演示了一个BASIC写的打印小程序。
由于电脑的音频磁带驱动器坏了，所以我们只能非常小心地听着敲击的声音来输入。这就导致我们更倾向于编写机会寥寥几行的代码，如下：

10 PRINT "BOBBY IS RADICAL!!!"
20 GOTO 10

即便是这么简单的代码，这个过程对我们来说也是充满挑战。当时我们完全不会编程，所以一个小小的语法错误对我们来时都是一个大灾难。如果程序出错（十分常见的情况），我们就得从头再来。
真正可怕的怪物在后头：一个有好几张布满密密麻麻代码的纸张组成的程序。每次开工之前，我们都要鼓足勇气啊！我们完全不知道这个程序是啥，只知道它的名字是“Tunnels and Trolls”，听起来像一个游戏！还有什么比一个自己手打出来一个游戏更酷的事情吗？！
然而，我们从没有将它完成正常运行起来，过了一年之后，我们搬出了那个教室（后来，当我对BASIC有一点了解的时候，我才意识到那个怪物其实只是一个表的字符产生器）。不过那个怪物还是一直影响着我，从那以后，我们就决定成为一个游戏开发者。

在我13、4岁的时候，我家里买了一台Macintosh，装有QuickBASIC 和THINCK C.基本上，每个暑假假期，我都用它来写游戏代码。自学是一件进步缓慢并且十分痛苦的过程。随着程序的增长，开发变得越来越难。

开始阶段，挑战还只是让程序能够跑起来。然后，问题就变成了如何编写出比我脑子所能够装下理解的更大的程序。这个时候开始，我就从阅读“How to Program in C++”这样的书，转向研究如何组织程序的书籍。

过了几年之后，有个朋友拿着一本 “Design Patterns: Elements of Reusable Object-Oriented Software” 给我看。当时我就惊呆了，这不就是我从青年就开始寻找的书吗？！我坐下来，读了一遍又一遍。当时，我仍然在为我程序增大带来的问题困扰，不过看到别人也面对这样的问题，并且提出了解决方案，这真的是一种解脱了。我终于感觉我是带着一堆武器作战，而不是刺手空拳战斗的了！

在2001年，我得到了梦寐以求的工作：EA的软件工程师。我迫不及待想要看看真正的游戏是如何编写出来的？像Madden Football 这样的大型游戏到底是怎样的架构？ 不同系统间是如何交互的？他们是如何使用单一的代码库，使得游戏却能够在多平台下运行？

打开源代码的时候，是一个令人好奇兴奋而又惊讶的时刻。这里面有非常优秀的代码关于：图形，AI，动画和视觉效果。我们中有人知道如何挤压出CPU的每个周期加以利用。很多我不知道的东西，可能就是这些人在午餐之前做出来的。

然而这些极其优秀的代码背后的架构就并不是那么完美。大家都过度关注特性，却忽略了组织代码的重要性。这些代码在模块间常常都是耦合的。一些新特性出来之后，很多用到它的地方都需要重新修改代码。而我认为，很多工程师，哪怕他们曾经翻开过设计模式这本书，也绝不会违反原子性这一原则。

当然了，其实也并不是这么糟糕。我能想象，这些游戏开发工程师坐在布满白板的象牙塔上，冷静地讨论架构设计几个星期。但是，我看到的代码情况，却是很多代码都是在deadline之前赶出来的。他们已经做了他们能够做的最好的努力，然后我们意识到，他们的更好往往是非常好的。我在编写游戏代码上花的时间越多，我就发现更多隐藏在表面下的优秀的代码。

然而，不幸的是，很多人都看不到这些隐藏的优秀代码。我看着我的同事们努力想要实现一个良好的解决方案，然而其实这些解决方案已经存在代码中了。

解决以上这个问题，正是本书写作的主要目的。我在自己游戏开发的经验中，找到了一些好的设计模式，并把他们记录在这本书里。这样，我们就可以有更多的时间用在发明新东西上面，而不是用在重复造轮子了。

市面上的书籍

有人可能会问，市面上已经存在各种各样的游戏编程类的书。为什么还要写一本？

我看过的大多数的游戏编程书籍，无非就是下面两种类型：

• 介绍特定领域的书籍：这类书的写作范围一般比较狭小，通常专注于给你在游戏开发某些特定方面的深层次的指导。他们会教你比如：3D图形，实时渲染，物理世界模拟，人工智能或者音频处理方面的知识。这些都是从事游戏开发的工程师在职业发展阶段会碰到的专业技能。
• 全引擎类的书籍：不同的是，这类书籍试着跨度整个游戏引擎的不同组成部分。他们通常是面向构建一个完整的游戏引擎，来适合于特定类型的游戏，经常举的例子是三维下的第一人称射击游戏。

对于上面的两类书，我个人都非常喜欢。不过我认为他们还是存在一些需要弥补的地方。专业型的书籍教会你如何用代码实现你游戏的功能。但是，你可能知道如何进行物理模拟和渲染，但是，你真的知道如何优雅的组织它们吗？

对于第二类书籍会覆盖上面没有提到的点，但是我经常会发现这些介绍全引擎类的书不是太片面就是太针对于特定流派的游戏。尤其是，随着移动类和休闲类的游戏越来越多的背景下，我们其实是处在一个需要开发各种流派各种类型的游戏的。我们已经不能照搬Quake这一套了。当你的游戏不适合某一个模型的时候，这类单一引擎的书对你的帮助是有限的。

相反的，我尝试介绍一些更为通用的技巧。这本书的每一个章节都是一个独立的观点，并且本书还提供源代码给你学习时使用。这样，你就可以通过混合它们或者匹配它们来达到你想要的最好的游戏效果。

如何与设计模式相关

任何编程类的书籍，只要提到了“模式”，显然都会联系到经典的设计模式书籍：Elements of Reusable Object-Oriented Software，这是由传说中的Gang of Four：Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides编写的。

虽然我的这本书叫游戏编程模式，但是，我并不是要证明Gang of Four的理论不适用于游戏开发。相反的：本文的第二章“再探设计模式”恰恰是引用了大量设计模式中观点，但是，本文的重点，还是在于如何将它们运用到游戏开发中。

并且，我认为这本书同时也适用于非游戏类的软件开发。所以，我还可以称这本书是More Design Patterns，但是我还是觉得把游戏作为例子可以更具吸引力，因为你总不会还想看到一本是是在介绍雇佣记录跟银行账户的吧？

总而言之，本书提到的设计模式同样是在其他软件开发中使用的，我只是认为他们尤其适合与解决在游戏开发中经常遇到的工程性的难题：

• 序列：时间与序列是游戏架构的一个核心任务。事件必须要在特定的时间，特定的情景下发生。
• 行为：由于开发的周期是被极大压缩的，所以一部分程序员需要快速建议并且迭代出一些列丰富的行为，并且要保证没有影响到别的程序员的开发。
• 解耦：当行为定义好后，就要开始交互了。怪兽攻击英雄，药水混合在一起，炸弹把敌人跟朋友都炸死了。这些交互行为，必须要保证不会交织在一起。
• 优化：最后，在游戏中，性能是最关键的环节。游戏开发者在不断的角逐中将会看到到底谁能够最终挤出他们的平台。提高响应性能的技巧，是一个拥有百万销量的游戏盒一个很快被删除并且满是差评的游戏的区别。

如何阅读本书

我将这本书分为3个大的章节。第一个是介绍并且组织全书。就是你现在阅读的这节跟下一节。

第二章，是“再探设计模式”，这里讲介绍一堆从Gang of Four的那本经典书中提到的理论。每一节中，我都会有自己对于这个模式的思考，并且我是如何应用到游戏开发中的。

最后一个章节是本书的重中之重。提出了13个我认为很有用的设计模式。他们被安排到4个类别：序列模式，行为模式，解耦模式和优化模式。

何去何从

模式是一个在软件开发过程中不断变化，不断扩大的部分。这本书的是从Gang of Four经典理论的分享与讨论中开始的，并且这个讨论、分享的过程还会在本书之外继续进行。

要记住，你才是这个讨论、分享过程的核心。因为当你在开发自己的模式，重定义一些书上提到的模式的时候，实际上你已经在为软件社区贡献了自己的力量。

如果你有任何建议，改进方法，或者反馈，请及时联系我们！