本篇对当今电脑游戏层次结构特点进行一个总结。
如今的游戏种类丰富多样，以一种层次结构显然无法全面概况，不过这个总结可以为游戏的共性提供参考以便指导今后的编程过程。
那么，按照层次关系自下而上，一个游戏应当包含如下的结构：
最底层：绘图API
中间层：游戏引擎
上层：游戏服务程序
最上层：游戏实例
以上各个层次直接构成依赖关系。
简单的解释一下：
底层的绘图API，它们承担着最重要的图形绘制任务，它的任务非常简单而明确：把内存里表示图形的数据高效的绘制到屏幕上（或者说扔到显存里），业内比较出名的就是微软的 DIRECTX 和开源的OPENGL 了，如同N卡与A卡之争、它们谁比较好这个问题不断地引发着网络上的各种战争。还有一些人认为学好它们就可以制作游戏而去误导新人，想要快速的进行游戏开发，直接去选取一款合适的游戏引擎就可以了，不必要蹚绘图API这个浑水，更没有必要去开发游戏引擎。
与凤毛麟角的绘图API不同，游戏引擎可是一个大家族，除了大型的游戏公司会考虑针对游戏来开发独立引擎外，大部分的游戏开发都依赖于现有的游戏引擎，当然，也能够很好地满足开发需求。例如面向大型游戏的寒霜、虚幻；面向物理现实模拟的havok、physX；以及面向掌机轻量游戏开发的Cocso 2D、Box2D等等。
到了上层，才是游戏开发人员应该关注的层次，我们把大部分经历用在游戏的设定而非实现上，之后使用引擎提供的API便可很好地实现，在这个层次上，游戏设计人员也往往分开，一部分是游戏的策划，他们设计各种游戏的流程与细节，设定各种矛盾以及收费需求，他们往往不用亲自编写代码但却拿到了大部分的收益；另一部分是程序员与美工，由美工提供各种游戏素材，再由程序员引入这些素材，并根据游戏引擎提供的API编写逻辑，最终一个游戏便新鲜出炉了，这里可能有一个幻觉：认为美工相比于程序员的工作较为淡薄，其实不然，这一点将会在后面讨论。
一般而言，我们玩游戏的体验也大部分来源于上层结构，既然上层是如此重要，离我们如此之进，所以我必须不惜篇幅的说说上层的这点事。
首先是游戏服务程序，这个词初见可能觉得有点生硬，这的确是我自己造出的词；它的作用很宽泛，一般而言，是进行一些游戏的前置准备工作，根据用户的设定来实例化一个对应的游戏程序。回想一下我们玩游戏的过程，就拿红警来说，我们首先运行游戏程序，之后点击菜单中对应的游戏类型、选择地图、电脑的部署（位置、国籍、同盟关系和难度）之后开始游戏，读条结束后我们就开始真正的游戏体验过程。那么前置的这些种种选择都是游戏服务程序来提供和记录的，直到你点击开始游戏后，游戏服务程序会根据刚才的种种选择来实例化一个游戏实体，并将控制权转交给游戏实体。游戏服务程序可大可小、可集成可分离，这都取决于游戏本身的大小和特性，例如FC上的打坦克，它的游戏服务程序只提供了P1\P2\construct这三个选项，我不认为它会独立于游戏而单独编制；而较大点的游戏，比如时下流行的LOL，它的游戏服务程序和游戏实体确是分离的两部分，首先运行的是游戏服务程序，选择房间、英雄及佩戴符文（有些界面甚至还是用的是WEB接口），待大家都设定好后，游戏服务程序会将消息同步给服务器，并运行一个游戏实例，我们会观察到一个退出再打开的过程，当然，新打开的就是我们的游戏实例了，我们还能看见它开始运行的LOGO。
关于游戏实例，这才是我们通常意义上游戏的本体，它多种多样，将我们的IO请求反应在界面上，我们时而化为英雄驰骋于虚幻的战场、时而化为装甲部队突袭敌人的防线、时而遨游太空探索宇宙的奥秘、亦或是简简单单地一次次突破扫雷的时间极限……这便是大家所追求的乐趣，是游戏的乐趣所在。