服务器存储的游戏数据是对游戏世界的一种描述，是对游戏状态的一种持久化，而且数据越多，对这个世界的描述便越详细。那么，游戏数据是以何种格式存储起来的呢？它们之间是否存在有价值的相关关系？
《取悦的工序：如何理解游戏》这本书由十个短篇组成，每篇围绕着不同的主题，介绍游戏开发的原理和过程，试图解答一款制作精良的游戏到底是怎么做出来的。它并不是为专业的游戏制作者们写的，相反，它是以科普为主要目的，更加强调易读性，而不是细致性，旨在给非行业内的读者们一个大概的介绍。看完这个系列的文章后，当你再次进入一款游戏的时候，你或许会有不同的感受。
本文是《取悦的工序：如何理解游戏》中的第六章。
查看前文：
在《排行榜是怎么算出来的？》一文里，我们把服务器想象成了一面很大的墙，墙上有很多抽屉。当你在某一局游戏里玩了567分后，游戏会把你的名字和分数一起，寄送给服务器。服务器收到之后，会打开一个空抽屉，把567这个数据放进去，并在抽屉上贴一个标签，上面写下你的名字。
这篇文章我们继续讨论一下这个抽屉具体是怎么回事，以便尽早摆脱这个比喻。
想象一下你走进FBI的档案室，这时候你看到了一个满是抽屉的柜子，每个柜子上贴着一个通缉犯的ID，你打开一个贴着“通缉犯_007”标签的抽屉，在里面发现了一张表格，这张表格是这位通缉犯的简历：
昵称：Jack爱放盐
性别：男
籍贯：德克萨斯州
政治面貌：清白
追捕原因：走私、贩卖咸豆腐脑
这张简历里，排在左边的昵称、性别、籍贯叫做键（Key），排在右边的Jack爱放盐、男、德克萨斯州这些叫做这个键所对应的值（Value）。这张由许多键值对构成的简历叫做一个文档（Document）。每份文档都贴着一个标签（例如“通缉犯_007”），以便索引，每个柜子像是一个数据集（Collection），而整个档案室就像是一个面向文档的数据库。
昵称：Jack爱放盐
国家：美国
签名档：咸还是甜，这是一个问题
使用设备：iPhone7
所以，整个游戏的数据就是这么存储的：数据库里有很多个数据集，每个数据集里有很多个文档，而一个文档就是以某种格式（比如上面的键值对格式）来封装、组织数据的这么一个东西。
当然，这种面向文档的数据库并非存储数据的唯一方式，我们还有更传统的关系型数据库，还有基于节点和边的网络型数据库等等，我们甚至可以用自己定义的格式，把数据存储在各种文件里；这些数据有可能是保存在你的iPhone上（单机游戏），也可能是保存在某台服务器上（多人游戏）；但不管以何种方式存在哪里，这些数据都是对游戏世界的一种描述，是对游戏状态的一种持久化。
透过这些数据，我们可以看到它们所描述的世界，数据越多，关于这个世界的信息就越详细。当数据多到一定程度后，我们就拥有了一个传说中的“大数据”。这些数据是如此之庞杂，以至于其中许多变量之间的相关关系是无法一眼看出来的。这个时候，我们需要把这些有价值的相关关系挖掘出来。
等等，什么是相关关系，为什么我需要把相关关系挖出来？挖出来后能吃吗？
先说说什么是相关关系。数学上的定义太枯燥，所以请各位再次容忍一下我的不严谨。设想你在刚才的FBI数据库里取出了很多文档，并逐个观察每个文档里一个叫做“地域”的键和另一个叫做“豆腐脑喜好”的键，假设你发现“地域”值为“北方”的文档，“豆腐脑喜好”的值都是“咸”，而“地域”为“南方”的，“豆腐脑喜好”的值都是“甜”，那么我们就说这两个变量是有相关关系的，下次再看到一个文档地域为南，我们就能猜测它的豆腐脑喜好为甜。再比如游戏角色的级别越高，杀伤力也越高；一条微博的转发量越多，被阅读次数也多；一个物体受力越大，加速度就越大，等等。
尽管相关关系并不意味着因果关系，但它可以让你去猜测变量之间可能存在的因果关系，此外，对相关关系本身的理解也有助于我们对周围的世界获得更加准确的判断，但这一切都有个前提，就是你的数据库是没问题的。
遗憾的是，我们常常有意无意地在自己的数据库里做着数据挖掘：知乎用户太装逼，豆瓣用户小清新，处女室友太纠结，天蝎前任复仇心。地图炮这个群攻型的拉仇恨主动技，正是以此为理论基础的。如果你把我们的世界想象成一款游戏，那么每个人所掌握的数据都只是服务器上所有数据的一部分而已，由此得出的结论，难免有失偏颇。
