1
将物理和游戏逻辑与UI代码分开
我正在研究一个简单的基于块的益智游戏。 游戏过程由游戏区域中的许多移动块组成，因此这是一个简单的物理模拟。但是，我认为我的实现还远远不够理想，我想知道您是否可以为我提供任何有关如何更好地实现的建议。 我将代码分为两个区域：游戏逻辑和UI，就像我处理许多益智游戏一样： 游戏逻辑负责游戏的一般规则（例如国际象棋中的正式规则系统） UI显示游戏区域和棋子（例如棋盘和棋子），并负责动画（例如棋子的动画移动） 游戏逻辑将游戏状态表示为逻辑网格，其中每个单位是一个单元格在网格上的宽度/高度。因此，对于宽度为6的网格，可以将宽度为2的块移动四次，直到其与边界碰撞。 UI会获取此网格，然后通过将逻辑大小转换为像素大小（即，将其乘以一个常数）来绘制它。但是，由于游戏几乎没有任何游戏逻辑，因此我的游戏逻辑层[1]除了碰撞检测之外没有其他工作。运作方式如下： 玩家开始拖动一块 用户界面要求游戏逻辑确定该棋子的合法移动区域，并让玩家将其拖到该区域内 玩家放手 UI将样片捕捉到网格（以便它位于有效的逻辑位置） UI告诉游戏逻辑新的逻辑位置（通过mutator方法，我宁愿避免） 我对此不太满意： 我正在为我的游戏逻辑层而不是UI编写单元测试，结果所有棘手的代码都在UI中：阻止该部分与其他对象或边界碰撞并将其捕捉到网格中。 我不喜欢UI告诉游戏逻辑有关新状态的事实，我宁愿让它调用movePieceLeft()方法或类似的方法，就像我在其他游戏中一样，但是我对这种方法没有了解，因为游戏逻辑对用户界面中可能发生的拖动和捕捉一无所知。 我认为最好的办法是摆脱游戏逻辑层，改为实现物理层。我对此有一些疑问： 这样的物理层是常见的，还是让游戏逻辑层更典型地做到这一点？ 捕捉到网格和片段拖动代码是属于UI还是物理层？ 这样的物理层通常可以与像素大小或某种逻辑单位（例如我的游戏逻辑层）一起使用吗？ 我曾经在游戏的代码库中看到过基于事件的碰撞检测，即玩家只需拖动棋子，UI就会顺从地渲染并通知物理系统，物理系统将调用onCollision（）方法一旦检测到碰撞，就会在工件上撞上。更常见的是什么？这种方法还是先要求法律流通领域？ [1] 层可能不是我所要表达的正确词，但是子系统听起来有些夸大其词，而类却是错误的，因为每一层都可以包含多个类。