作者介绍了自己早期接触电脑编程的经历,从一开始单纯的复制别人的代码,到最后用自己的想法来创作游戏程序,但是作者一直苦于如何将大型的游戏代码付诸实现。直到在青年时期,作者经过朋友的介绍,接触到了《Design Patterns: Elements of Reusable Object-Oriented Software》一书,他虽然没能在书中找到具体的解决方案,但仍然欣慰地发现他的许多困难也正是许多程序员所面对着的,他找到了一些可以为自己利用的工具,而不再只是赤手空拳。

2001年,作者开始于艺电担任软件工程师一职,而这也正是作者的梦想般的工作,因为在这里,他可以看到许多大型游戏是如何被实现起来,构筑起来的。当然,作者看到了许多精良的代码,也见识到了许多能榨干每一个CPU周期性能的人才,见识到了许多他未曾知道的天才般的实现,而这些实现对这些人来说实在是小菜一碟。

不过即使是这些天才般的程序员,其代码架构也是在事后实现的——毕竟,要一边赶工期实现特性,还要一边注重代码架构是不太现实的,作者知道,不可能让程序员活在这样的象牙塔里面:这里摆放着许多白板,让众多程序员有足够多的时间来实现足够精良的架构。事实上,程序员是在紧迫的死线之前实现出这些精良的代码的,这或许让他们无可厚非。

而让作者感到可惜的是,这些程序员编写的代码,放在代码仓库中的代码,潜藏着相当宝贵的品质,而也仅仅是潜藏着而已——因为看起来,从没有人能复用其中的代码。程序员苦于实现某些特性,却不知道别人早已在代码仓库中有着可马上利用的重复代码,这是藏有的事情。

而这正是作者要解决的事情,作者试图写一本书来教导读者如何去创造新的轮子,而不是“重造”轮子。

书店里大多的游戏编程书籍是怎样的

据作者观察,现有的游戏编程书籍主要落在两大类:

特定领域的书籍:

这些书大多聚焦于游戏开发中某个特定的方面,比如说3D图形,实时渲染,物理模拟,人工智能和音频等等,这是游戏开发者随着职业发展会特化到的特定领域的知识。

讨论整个引擎的书籍:

相比前者而言,讨论整个引擎的书籍就会将游戏引擎拿出来对其各个功能部分泛泛而谈,这些书是面向创建某个特定题材的游戏引擎的,比如说3D第一人称游戏。

这两类书作者都喜欢,但是它们还是留下了某些空白:特定领域的书籍不会告诉你如何将游戏两个部分的代码联系起来,实现它们之间的交互,你也许可以在两个部分都写出很好的代码,但你或许无法将这两部分的代码联系起来;讨论整个游戏引擎设计的书籍通常太过于庞大而单一,而且特定于某一体裁,在如今体裁多变的年代,你从这种书学到的知识也许无法很好地适用于另外一种体裁。

而作者的意图是做出一本各章内容都可以泛用的书籍,你可以将从书中学到的知识与任何你想做的游戏的代码结合起来。

本书与设计模式的关系

一切与设计模式有关的书都与“四人帮”的经典著作《Design Patterns: Elements of Reusable Object-Oriented Software》脱不了干系,作者写这本书也不是暗示该书的内容无法应用于游戏编程,相反地,本书的“再访设计模式”一节也提到了许多经典的设计模式,只是强调了各种设计模式可以如何应用于游戏编程之中。

反过来说,本书介绍地设计模式也同样可以用于非游戏编程之中,这本书也可以被称作“更多设计模式的介绍”,但讨论游戏的设计模式显然要更吸引人,应该不会有人想读一本有关职员记录或者是银行存款设计模式的书吧。

话虽如此,虽说本书介绍的设计模式对其它软件编程同样有用,实际上作者认为里面的模式会适合那些在开发过程中会面临与游戏开发过程中同样挑战的领域,如:

与时间序列有关:时序是一个游戏体系结构的核心部分,必须要在正确的时间,以正确的顺序完成正确的事情。

高度压缩的开发周期:大量的程序员要在这样高度压缩的工期中迅速开发,在大量的特性中实现迭代,还不能让不同程序员编写的代码纠缠不清,发生冲突。

所有特性完成后,程序各部分便开始交互,怪物攻击游戏中的英雄,药水开始发挥功用……而且不能让代码仓库像一团毛发一样纠缠不清。

最后,性能在游戏中相当关键,游戏开发者是站在平等的赛道上,比试谁能榨干平台资源的一分一毫的。细节决定成败,是否能削减不必要成本,决定了一款游戏是能得到A+级的评价,还是面临掉帧问题,以至于其评论区充斥着大量不满的评论。

要怎么读这本书?

这本书被分成三大部分:

1.本书介绍及其框架,也就是你现在读的这一章以及接下来的一章;

2.再访设计模式:涉及一些”四人帮“书籍的设计模式,每一节作者都会给出他对于这些模式的利用,以及他对于这些模式与游戏编程的联系的想法。

3.游戏设计模式:本书的主要部分,介绍了作者觉得有用的十三个设计模式,它们被分为四类:序列模式行为模式解耦模式以及优化模式

本书的每一个模式都沿用同一种结构去描述,因此你可以把这本书当成一本参考书,并迅速找到你需要的:

  • 目的部分:根据能解决何种问题,给出该模式的大体介绍。这是每个模式的第一个部分,因此你可以通过翻阅本书,很快地找到你正苦于解决的问题的模式。
  • 动机部分:给出一个能运用该模式的场景,也就是给出一个要解决的问题的实例。不像算法,设计模式除非应用于具体问题,否则就会显得相当虚无缥缈。教授设计模式而不提出实际问题就像教授烘焙而不提到面团一般,而这一节正是提供了我们要用于”烘焙“的面团。
  • 模式部分:这部分萃取了上一部分例子的精华,如果你需要一个对于该模式的教科书式的描述,那这部分就是你想要的。如果你已经对此模式烂熟于心而想检查自己是不是漏掉了什么,那么这部分可以给到一个提醒的作用。
  • 目前为止只是给出了这个模式可以如何被用来解决我们的示例问题,但是我怎么知道这个模式对的问题适不适合?对此,何时去用部分给出了模式何时有用而何时应避免使用。时刻留意部分指出了采用该模式面临的后果和风险。
  • 如果你想得到一段实际的代码,那么示例代码会提供给你这个模式的逐步完整实现,以便你可以看到代码如何运作。
  • 设计模式不像算法,它没有明确的实现目标,每次利用设计模式,你都会以不同的方式去实现它,设计决策部分则给出了应用该模式你应该考虑的一些实现该模式的选项。
  • 参阅部分比较短小,给出了应用该模式的现实世界的开源代码。

有关示例代码

本书采用C++编写示例代码,这不是说C++是唯一能采用该书设计模式的语言,也不是说C++比其它语言要好(话虽如此,某些模式确实要求你的语言有着对象和类的概念),选择它的理由是,第一,C++是游戏工业的通用语言,是行业中最受欢迎的语言;第二,C++的语法基础也正是众多语言采用的语法基础,也许你不知道C++,但花费少许努力能读懂这些代码的可能性是很大的。

本书的目的并不是教会你C++这门语言,示例代码是怎么精简怎么写的,可能不会有太良好的代码风格,代码是为了表达其思想,而不是为了表达代码本身。

尤其要指出,这里的C++代码没有用到现代写法——C++11或者更新的标准,既没有用到标准库,也几乎没有用到模板,这也许对C++本身来说是坏事情,但是也没关系,这使得代码本身对别的语言的用户更加友好。

为了节省空间,于模式无关的代码会被省略掉,并在相应部分采用…省略号替换,某些实现特定功能的函数也仅关心其返回值,而不关心其具体实现,因此,代码看起来是这样的:bool update() { // Do work... return isDone(); }

读完本书后,何去何从

设计模式是在不断发展的,从四人帮的设计模式,到本书的设计模式,本书完成后会有更多的模式被提出,而你可以成为设计模式发展过程的重要部分,如果你有更多的设计模式,或是有想提出的建议,校正或是反馈,不妨在讨论社区作出一份贡献!