这个问题很难解释，因为我没有看到任何这样制作的游戏的例子，这正是我问这个的原因。
示例： 假设我们已经为井字游戏制作了后端，该后端使用您计算机上的端口（在本例中，还有其他方法可以做到这一点）来公开 api，并且该 api 可以为您（玩家）提供棋盘状态/可用说明/现在播放哪种音乐（？）等。现在，对于游戏的后端实例，潜在的游戏开发人员可以制作基于文本/2D/3D/体素 3D 的客户端应用程序，基本上任何类型的前端，这将还创建任何玩家都可以开发应用程序的前端部分的环境，通过添加或删除功能而不实际影响核心游戏，这将极大地扩展您（开发人员）游戏的可玩性。
这个例子听起来有点微不足道且无用，但如果我以这种方式介绍像Dwarf Fortress这样的游戏，我可以看到这种方法的明显好处，开发人员将专注于通过仅开发来使他们的游戏达到最佳状态这个后端游戏部分和 lats 说基于文本的前端，而粉丝可以创建 3D 粉丝制作的游戏客户端，这将极大地扩展玩家基础，或者只有开发人员可以在稍后投入生产时创建这个 2D 客户端，同时他们有空闲的劳动力，而不会受到复杂更改的影响进入代码的后端部分，努力使整个游戏从基于文本到 2D。
我希望你们都能看到这种游戏制作方法的潜在好处，但我从未见过任何游戏使用这种架构，所以它背后应该有某种原因。这就是我真正在寻找的，这个原因。
另外，我不相信带有服务器的多人游戏都使用这种方法。大多数客户端创建自己的游戏状态，并且为了确认玩家不会作弊，服务器运行自己的状态，但无头确认客户端的游戏状态，同时用其他玩家的状态更新所述客户端。我说的是单人游戏和客户端，它们不会“思考”，而只会向玩家显示信息，并充当向游戏后端部分提供关键输入的界面。
我不是游戏开发者（如果我们不计算一些为了好玩/与朋友一起构建的小型宠物项目），但这是我对此事的明显不专业的看法：
有人可能会说它们实际上是这样开发的，游戏引擎是服务器，UI+脚本是前端。
并非所有游戏都需要/可以有如此完全的分离，例如（IMO）射击游戏应该与物理引擎过于紧密地耦合。
上市时间/价格/受众。具有基于文本的 UI 的游戏（如最初的 DF）很少能够获得足够广泛的受众，以至于有人费心去创建一个粉丝制作的 UI。如果您是专业的游戏开发人员/工作室，您将希望尽快瞄准尽可能广泛的受众，因此您将需要有一个像样的图形，并且开发客户端服务器协议是额外的努力（这不仅可以有时间/金钱，但会影响性能）。