在游戏程式的领域中，最常听到的专有名词，可以说是非 Game Engine（游戏引擎）莫属了。听起来是个很炫很酷的名词，但其实游戏引擎一词经常被过度泛称与误用。所谓的游戏引擎架构，由低阶 (Low-Level) 至高阶 (High-Level) 可细分为以下三个层级 (Layer)：
- 绘图 API（例如：DirectX 与 OpenGL）
- 绘图引擎（例如：OGRE、Renderware 与 Gamebryo）与其他引擎
- 游戏引擎（例如：Unreal 与 Torque）
绘图 API，负责掌管程式与硬体间的沟通，将硬体层的功能与特徵抽象化，提供一组标准化的介面供程式设计者使用。目前 DirectX 与 OpenGL 已成为业界两大标准。此层级属于绘图底层的规格化与标准化，有利于引擎与游戏开发者以及整个业界的发展，使开发者可以专注在更具体与游戏相关的引擎架构上，而不会受制于各家厂商不同硬体实做内容所产生的限制。
绘图引擎，将底层的绘图 API 包装成与实做无关的介面，甚至能够提供数种不同平台的绘图 API 以供跨平台开发使用，更进一步的为程式设计者带来许多的功能性以及便利性。使用绘图引擎对于开发者来说***的益处，就是可以使用以绘图 API 建构起来的各种绘图架构与技术，例如 Scene Graph 架构、空间分割、资源管理、光影处理等等。
游戏引擎，则是一组完整的解决方案，能够在保持一定弹性的原则下，提供***程度的功能性与便利性。除了包含绘图引擎的功能之外，可能也会包含播放音乐音效的音效引擎、判断物理碰撞行为的物理引擎等其他功能面的元件。相较于单纯的绘图引擎，一个完整的游戏引擎，更需要提供许多的编辑器与工具，例如地形编辑器、人物动作编辑器等等。而游戏引擎与美术设计软体（例如 3ds Max）的整合性也相当重要；如果引擎内含强大的编辑工具与外挂输出程式，不仅能为程式开发者节省时间，为企画与美术设计者带来便利性，更能够降低人为错误的发生率，进一步加速游戏的开发流程。
除了上述的绘图 API、绘图引擎与游戏引擎层级之外，还有一个称为游戏框架 (Game Framework) 的层级。在软体开发的领域中，所谓的 Framework 是指一个在软体系统中可重复利用的设计。与游戏相关的着名框架系统有用来开发 Xbox360 游戏的 XNA Framework 与微软大力推行的 .NET Framework。框架系统需要能在提供现成实做版本的情况下，同时保留具有弹性且可扩充的介面，以期达到框架的可重复利用性。
此外，由于游戏产业的蓬勃发展，专注于开发绘图引擎与游戏引擎的公司也越来越多，于是出现了一个新兴的专有名词称之为 Middleware（中介软体）。中介软体是用来提供某特定层面的功能性元件，目的在于节省游戏开发的时程与风险，包含像是绘图引擎、物理引擎、人工智慧引擎、音效引擎等等都可以算是中介软体的一种。目前也有中介软体开发厂商，提供包含伺服器端与客户端程式在内，开发 MMO 游戏的完整解决方案。
在游戏程式开发中，最困难的关键点往往在于各层级间的桥接与沟通部分。对于各个层级，开发者需要尽可能使它们达到彼此独立不相依的情况，减少各层级之间的耦合性，在这样的设计模式之下，才有利于达到元件化、层级化的高度可再利用游戏引擎。简而言之，也就是将介面与实做分离的设计概念。在最理想的情况下，希望能够将引擎框架的泛用程式码与和特定游戏相关的程式码两部分完全分离而治，以期达到在引擎相关程式码变动最少的情况之下，能够提供给不同的游戏程式码来使用。
游戏引擎所提供的功能，就像是玩乐高玩具一样，我们可以使用积木箱里各种不同形状的基本积木，组合出梦想蓝图中的巨大模型。这些基本积木就像是游戏引擎中的各种元件，可以根据不同游戏专案的不同需求，取出合适的积木元件拼凑组合成为一个完整的游戏。而这个从积木组成模型的步骤，则需要一个规格化、标准化的程序，使得「组装」这个动作，变得很直觉易懂，无论未来积木的内容材料是否有改变，都不会对使用者造成太大的影响。积木的「组装」动作就像是程式的「介面」一样，任意变动积木的组合方法或是介面的使用方法，都会造成使用者的困扰与不便，并且大幅降低复制使用经验的可能性。
然而在真正的开发过程中，我们可能会发现，要达成各层独立、介面实做分开是非常不容易的任务。特别是在程式架构不良的情况下，会使得日渐庞大的游戏程式码层层交叠、错综盘根，就像是地基不稳却又拼命往上加盖的高楼一样摇摇欲坠。因此正如设计模式书中的设计思维所述：应该着力于将「变动」与「不变动」的部分抽离分开，分别封装「变动」与「不变动」的概念，才能够将进行变动时所需耗费的心力降至***。
