游戏设计模式(一) 序言：架构，性能与游戏

第一次在知乎写专栏，一个全新的起头，希望列位多多看护。

一、系列文章前言

这个系列的诞生，是由于比来闲暇时一向在阅读一些之前已经列入待看书单的典范著作，并有将阅读进程中一些思考和总结写成笔墨停止记录。为了不白费这些阅读、思考与总结的进程，决议将这些零星的内容整理成文，并调集成系列，将他们系统地记录下来，也希望能对酷爱编程的列位有所帮助。

需要说明的是，虽说这些文章的原型是念书笔记，但会采用和传统念书笔记纷歧样的方式。他们不会仅仅逗留在转达作者寄义的阶段，而会是对一本书焦点内容的全新归纳，内容解刨，精炼与解读。与其说是念书笔记，无妨说是原著经过的解读后的浅显版本。

希望自己的这些文章，能对列位有所帮助。也正如文章开首所说的，第一次在知乎写专栏，新的起头，希望列位多多指教。

二、《Game Programming Patterns》其书

之前，已经在我的技术博客中解读了《Clean Code》（中译“代码整洁之道”）这本书，承接《Clean Code》的解读，《Game Programming Patterns》是我们下一个方针。

原书是英文原版，Game Programming Patterns，译为游戏编程形式，我们无妨在后文中将其简称为GPP。按照全书内容，更贴切的诠释应为游戏设想形式。所以你会发现，我们这个系列文章的称号，就叫“游戏设想形式”。

一路来看看《Game Programming Patterns》这本书的内容。正如其名，它是一本专注于游戏编程范畴的设想形式指南，它涵盖了游戏逻辑，游戏编辑器，和游戏引擎的编程中的常用技法。作者Robert Nystrom有二十年的从业经历,在EA工作8年不足。

“这本书将游戏开辟中经常触及到的编程形式拎出来，连系具体开辟中碰到的实例一步步的引出对应的形式，这比起四人帮的《设想形式》加倍具体。”

分歧于传统的出书方式，这本书是收集出书，然后Web版完全免费，其更是在Amazon上具有罕有的5星评价，可见读者对其的好评水平之高。加上书中内容活泼风趣，将各类经历之谈娓娓道来，实在是业界良知。

书籍主页：Game Programming Patterns

Web版全文阅读：Table of Contents · Game Programming Patterns

三、本文触及常识点思维导图

先放出这篇文章所触及内容常识点的一张思维导图，就起头正文。大师如果疲于阅读文章正文，间接看这张图，也是可以Get到本文的首要常识点的大要。（保举放大后检察）。

四、作甚好的软件架构

《Game Programming Patterns》一书中说到，好的设想意味着当我改了点什么， 全部法式就似乎正在等着这类修改。我们可以加入几个函数挪用完成使命，同时丝绝不改变代码安静概况下的脉动。

这听起来很酷，只是实行起来很难。“把代码写到改变不会影响其安静概况。”若真能做到，确切不错。

这样太理想化了，还是让我们浅显些吧。架构是有关于变化的，让我们拥抱变化，从变化起头动手。总有人修改代码。假如没人碰代码，不管是由于代码至善至美，还是糟糕透顶，那末它的架构设想就毫无意义。评价架构设想就是评价它应对变化有何等轻松。没有了变化，它就是永久不会分开起跑线的运带动。

轻松应对变化，这就是好的软件架构的首要优点之一。

五、一个新特征的实现进程

在你改变代码去增加新特征，去修复缝隙，大概随意什么需要利用编辑器的时辰， 你需要了解现在的代码在做些什么。固然，你不需要了解全部法式，但你需要将一切相关的工具装进你的灵长类大脑。

我们凡是疏忽了这步，但这常常是编程中最耗时的部分。 假如你以为将数据从磁盘上分页到RAM上很慢， 那末试着经过一对神经纤维将数据分页到大脑中。

一旦把一切正确的高低文都记到了你的大脑里， 想一会，然后找到处理计划。 这能够会有往返打转的时辰，凡是是比力简单。一旦你了解了题目和需要修改的代码，现实的编码工作就很轻易了。

你将一些代码加入了游戏，但不想下一小我被你留下来的小题目绊倒。 除非修改很小，否则就还需要一些工作去微调新代码，使之无缝对接到法式的其他部分。假如做对了，那末下个见到代码的人甚至没法说出哪些代码是新加入的。

简而言之，编程的流程图看起来是这样的：

PS:看起来，这是一个令很多法式员听之色变的死循环：）

六、解耦与进修阶段

实在，很多软件架构都和进修阶段（learning phase）息息相关。 将代码载入到神经元过分缓慢，找些战略削减载入的总量是很值得做的事。GPP一书中有整整一章是关于解耦形式（decoupling patterns）， 还有很多常规的设想形式也牵扯到领会耦。

可以用多种方式界说“解耦”，这边是其中之一的了解方式：

倘使有两块代码是耦合的， 那就意味着没法仅仅只了解了其中一个，而对另一个丝绝不领会。假如解耦了他俩，便可以单独的了解其中之一，底子无需牵扯到另一个。

GPP一书中说道，我所了解的软件架构的关键方针，就是最小化在处置前需要进入大脑的常识。这也是一种很好的了解方式。

固然，也可以从前期阶段来看。 那末，另一种解耦的界说则是：当一块代码有变化时，没需要点窜别的的代码。 必定需要点窜一些工具，但耦合水平越小，变化会涉及的范围就越小。

七、过度设想的价格

首先，我们需要这样一个设想：在一个系统中，解耦掉任何内容，然后，风烟俱净，天山共色，从流飘零，肆意工具，便可以像风一样写代码。每个变化都只点窜一两个特定方式，万花丛中过，片叶不沾身，这是何等的舒服，是吧？

这大要就是人们对笼统，模块化，设想形式和软件架构兴奋的缘由。在有好架构的法式上工作是很好的体验，每小我都希望能更有用力地工作。好架构能形成生产力上庞大的分歧。很难再夸大它那强力的影响。

可是，就像生活中的任何事物一样，没有免费的午饭。好的设想需要汗水和纪律。 每次做出修改或是实现特征，你都需要将它文雅的集成到法式的其他部分。需要花费大量的尽力去治理代码， 在开辟进程中面临数千次变化仍然连结它的治理结构。

我们会看到无数法式有个文雅的起头，然后死于法式员一遍又一遍增加的“细小黑魔法”。就像园艺，仅仅增加新动物是不够的，还需要除草和修剪。你得斟酌法式的哪部分需要解耦，然后再引入笼统。一样，你需要决议哪部分要设想得支持插件来方便未来的变化。（所谓的面向未来编程）。

人们对这点变得狂热。他们设想今后的开辟者（大概只是未来的他们自己）进入代码库，并发现它极为开放，功用强大，极具扩大性，他们会赞叹道“有此游戏引擎，夫复何求”。当过度关注这点时，你会获得失控的代码库。 接口和笼统无处不在。插件系统，笼统基类，虚方式，还有各类百般的扩大点。当需求变更时，有能够某个接口能帮上忙，但能不能找到就只能祝你好运了。 理论上，解耦意味着在点窜代码之前需方法会的代码更少，但实在你需要对笼统层有很多的领会。

还是那句话，理想很饱满，现实很骨感。 每当你增加了一层笼统大概支持扩大的部分，实在就是在赌这部分功用今后能否用得上。 增加代码和复杂性到游戏中，这都需要时候来开辟，调试和保护。假如你猜对了，后来利用了这些代码，那末功夫不负故意人。 但猜测未来很难，假如模块化终极无益，那就有害。 究竟，你得花时候去实现这些代码。

有些人喜好简写为术语“YAGNI”——You aren't gonna need it（你不需要阿谁）——来匹敌猜测未来需求的激烈愿望。

过度去关注设想形式和软件架构，会让一批人很轻易地沉醉在代码中，而疏忽要自己的终极目标是要公布游戏。无数的开辟者听着增强可扩大性的“警世名言”，花费多年时候建造“引擎”， 却没有搞清楚做引擎是为了什么。

八、性能与速度

软件架构和笼统偶然会被批评，特别是在游戏开辟中: 它危险了游戏的性能。 很多让代码更灵活的形式依靠虚拟调剂、 接口、 指针、 消息，和其他机制， 而这些城市消耗运转时本钱。

一个风趣的背面例子是C++中的模板。模板编程偶然可以给你笼统接口而无需运转时开销。

这是灵活性的两极。当写代码挪用类中的具体方式时，你已经硬编码了挪用的是哪个类：但经过虚方式或接口，直到运转时才晓得挪用的类。虽然这样加倍灵活，但增加了运转时开销。

而模板编程是在两者之间——在编译时初始化模板，决议挪用哪些类。

还有一个缘由。很多软件架构的目标是使法式加倍灵活。 这让改变它需要较少的尽力。编码时对法式有更少的假定。你可以利用接口，让代码可与任何实现它的类交互，而不但仅是现在写的类。灵活性可以让我们快速改良游戏。

让你的法式加倍灵活，在损失一点点性能的条件下更快地做出原型。 但需要留意，优化现有的代码能够会让代码损失原本的灵活性。

而一种折衷的法子是连结代码灵活直到设想定下来，再抽出笼统层来进步性能。

九、烂代码在原型阶段的上风

全国武功，唯快不攻。

野百合也有春季，之前在《Clean Code》中被我们吐槽的烂代码，实在也有它们的上风——快。

我们晓得，编写杰出架构的代码需要仔细地思考，这会转为时候上的价格。 在项目标全部周期中连结杰出的架构需要花费大量的尽力。 你需要像露营者处置营地一样谨慎处置代码库：总是连结其优于你刚刚打仗它的时辰。就像我们之前《Clean Code》系列文章第一篇中说到的：让代码比你来时更清洁。

当你要在项目上花费很久时候的话，连结编写杰出架构的代码的习惯，是很是值得推重的。但你晓得，游戏开辟需要很多尝试、摸索与试错。 出格是在早期，写一些你晓得要抛弃的代码是很普遍的工作。

而假如只想试试游戏的某些主张能否是正确的， 杰出的设想意味着在屏幕上看到和获得反应之前要消耗很长时候。假如最初证实这点子差池，那末删除代码时，你花费的那些为了让代码加倍文雅的额外时候，就白费了。

但你得让人们清楚，可抛弃的代码即使看上去能工作，也不能被保护，必须重写。倘使有能够要保护这段代码，就得防御性好好编写它。

一个保证原型代码不会酿成真正利用的代码的技能是利用和正式游戏分歧的编程说话。这样，在现实利用于正式游戏中之前必须重写。

在原型开辟阶段，能尽快让你做出原型产物，终极让产物成功上线的最初的元勋，也许就是设想糟糕的烂代码。由于他们实现想法够快，不需要周密的设想与架构。只是这些烂代码在履历了原型设想阶段以后，一定要被重写大概重构。

10、开辟周期中身分的静态平衡

在全部开辟周期中，以下三大要素一向在相互角力：

1. 为了在项目标全部生命周期连结其可读性，我们需要好的架构。
   
2. 需要更好的运转时性能。
   
3. 需要让现在的特征更快的实现。

风趣的是，这三点都是速度：持久开辟的速度，游戏运转的速度，和短期开辟的速度。

这些方针最少是部分对峙的。 好架构持久来看进步了生产力， 也意味着保护每个变化都需要更多尽力让代码连结整洁。

实现起来最快的代码很少是运转时最快的。 相反，提升性能需要很多的编程时候。而且一旦完成，它就会净化代码库：高度优化的代码不灵活，很难修改。

总有本日事本日毕的压力。可是假如尽能够快地实现特征，代码库就会布满黑魔法，缝隙和紊乱，障碍未来的产出。

对于这个三者的权衡，没有简单了然的处理计划，只要具体题目具体分析，按现实的项目状态去去权衡，让三者连结友爱的静态平衡，让全部项目连结杰出的状态。

十一、本文触及常识点提炼整理

本文触及常识点提炼整理，一些关于游戏架构与性能的心得总结：

1. 笼统息争耦会让代码的扩大性和灵活性加倍强，但会花费额外的实现时候。除非你感觉这样的灵活性有需要，否则没需要过度的去追求。
   
2. 性能优化很重要，可是要留意机会。在全部开辟周期中，最好先专注于实现根基需求，把那些能够限制到项目进度的性能优化只管延后。
   
3. 在全部开辟周期中，灵活性和高性能常常不能兼得。我们可以连结代码的灵活性直到设想定下来，再抽出笼统层来进步性能。
   
4. 在原型开辟阶段，能尽快让你做出原型产物，终极让产物成功上线的最初的元勋，也许就是设想糟糕的烂代码。由于他们实现想法够快，不需要周密的设想与架构。只是这些烂代码在履历了原型设想阶段以后，一定要被重写大概重构。
   
5. 假如筹算抛弃这段代码，就不要尝试将其写完善。“摇滚明星将酒店房间弄得一团糟，由于他们晓得明天会有人来扫除清洁。”
   
6. 提倡去写出最简单，最间接的整洁代码。你读过这类代码后，完全了解了它在做什么，想不出其他完成的方式。“完善是可到达的，不是没有工具可以增加的时辰，而是没有工具可以删除的时辰。”
   
7. 但最重要的是，假如你想要做出让人享用的工具，那就享用完成它的进程。
   

十二、参考文献

[1] Architecture, Performance, and Games · Introduction · Game Programming Patterns.

[2] Game Programming Patterns书评

[3] 【《代码整洁之道》精读与归纳】之一 让代码比你来时更清洁

本文就此竣事，系列文章未完待续。

With Best Wishes.