游戏架构哲学理论
游戏架构哲学理论
架构在开发中其实是一个很重要的东西，一个好的架构有助于整个项目的健康成长和推进。一个差的架构除了难以扩展以外更是伴随着无数的bug，随便改动一个小的地方便会产生一系列连锁反应。
一方面要针对需求进行合适的架构，另一方面要架构具有强大的扩展性。不可否认的是，一个游戏的游戏性结构，绝大部分来自于架构的体系结构。正如Conway’s law所阐述的
Quote
而在游戏中，这种架构不仅仅反映组织交流的结构，更是决定了游戏的变化和扩展性，进而决定了游戏的游戏性。
这些文章很多都只是我一些个人的思考，结合了我的经验，理解，以及很多数学的观点。其中很多内容看起来非常抽象，用了很多数理逻辑的思想，甚至语言不通。在我看来这些可能都是一些架构哲学的理论思考，很可能不具有任何实践意义。但我觉得这种形而上学的思想，其实对整个开发架构很具有指导性。有这么一些想法会在处理需求的时候，处理成一个代码更精简，但功能更强大，更易于扩展的结构。
在此主要记录我个人研究并深入理解的一些架构思路，非常浅薄，希望能对大家产生新的想法，抛砖引玉，构思出更强大的结构。
一些个人的想法
在看了这么多书籍，资料以及结合自己编程经验之后，我觉得其实架构最本质的还是在于对图灵机的理解，或者说对于计算理论的应用。具体来说，可以说是根据需求情况来建立合适的数据结构以及算法。所以最后落到的本质还是那些再熟悉不过的数据结构以及算法。
但是能将这些东西跟实际结合起来是需要理解和想法的。目前对于国内的开发环境来说，我认为普遍还是追求者面向对象以及遵从设计模式的架构开发方式。然而这种架构开发方式时常会失效，针对某些需求问题会写出非常难以适应，甚至Bug百出的结构。我觉得这是有多方面原因。
- 一是因为，面向对象的方式易于理解，大部分人都能快速上手。
- 二是建立在一的基础上，大家已经形成了一套交流语言，通过这个语言大家可以快速沟通。
- 三是因为四人帮写的设计模式流传甚广且可以解决大部分问题。
- 四是模式这个东西本身确实具有一定的可复用特性，与不变性。这东西实与数据结构预算法相关联。
- 五是对比一些复杂如编译原理的理论，这些东西实现更快。
总之种种原因，导致似乎还是设计模式更为通用，好用一些。
然而对于我个人来说，感觉对于这些模式的应用犹如死记硬背，硬搬硬套总欠缺灵魂。再加之我可能更喜欢刨根问底式的数学，所我其实更多的是以一种非常底层的方式来看待问题。实际上我后面看了很多之后就发现，面向对象，以及设计模式本身都只是一种需求分析的手段。继承也可以理解为一种，定义数据结构与伴随方法的组合方式。所以这也是这些奇怪的文章诞生的原因。
可以看到，文章基本上关联起来其一些非常底层的想法，把整个架构刨解为无数个核心idea。而相应的可以看到里面充满了诸如，计算理论，算法设计，数理逻辑，高等数学，编程语言设计，软件架构等各种想法。
但同时也不可否认的是这里面存在着面向需求的部分，即业务内容，实际上这一部分在四人帮之后就升华为领域驱动架构的抽象概念了。对于这些领域内的对象，我们也不得不承认的是，其需求的结构，会影响着我们数据结构的定义方式，进而要架构的时候还要考虑需求的变动。
另一方面来说，这些想法一定有用么？其实
总之这些文章出发点并不算是一种设计模式，而更多的是一种我对于结构特点的理解吧。如果有时间，可以尝试阅读下面的参考文献。有些文章还是很有意思的。如果想看一些架构想法也可以去看架构实现部分。
文章目录
01容器化理论
主要是介绍容器的特点，说明容器是架构中扩展性的来源，结构体现的承载体。容器本质其实是序，图等数理逻辑概念的抽象。从后面来看，放在这里可能太前了。
02状态与纯函数
主要说明状态与纯函数的不一样，介绍图灵机与lambda演算的异同。最后落实在状态与函数的差异，以及相互影响上面。
03Timeline结构
主要关注游戏中随时间变化的特性，讲述时间轴上逻辑的各种概念。
04类型系统
从类型角度出发说明代码中类型概念的体现，说明，类型与约定数据结构上的各种关系，最后讨论到类型的结构概念与泛型编程。
05Lambda演算与不动点
讨论Lambda演算的在语言中的体现。最后说明在程序中存在不动点的结构体现。
06领域概念
讨论领域驱动架构的一些思路。说明对于架构来说，目标领域需求的重要性。例如游戏中涉及的概念术语，要建立对应的数据结构封装化。
07再论静态与容器
08等价结构
讨论结构上的等价性。讨论代码的书写方式，对于功能实现，与扩展具有相同的能力。
参考资料
这里文献就大致列出书名以及作者了，并不严格按照一些文献参考格式。