0

我正在用 Cocos2D-x 编写游戏，但我一直在挣扎，感觉我的 OO 很草率。我无法摆脱这种感觉，我可以说出原因。

游戏场景类

  • 在此创建了一个图层

图层类

  • 负责创造自己
  • 需要时也调用 HUDS
  • 包含层上对象的 std::vectors

项目等级

  • 把握自己的一切
  • 有一个在图层上的精灵成员变量

HUD1

  • 当用户点击图层并且触摸甚至发生在对象中时调用
  • 是您可以对对象执行的操作的菜单
  • 当您单击菜单项时，它需要更改 Object 中的值
  • 当您单击菜单项时，它实际上会在 Object (object::doSomething()) 中运行代码

我认为感觉草率的是对这些类有很多依赖。

我觉得我应该将其抽象出来并创建一个控制所有这些发生的类，而不是对象、层、HUD 等中的一些代码。

谁能和我谈谈这是如何布局的以及我是否犯了 OO 错误？

4

2 回答 2

2

事实证明，图形和游戏并不能很好地融入 OO 设计，尽管它是许多 OO 文本中的示例。在将控制与数据分离方面，您的直觉是正确的。当今流行的游戏设计模式是拥有组件、实体和系统，而不是严格的 OO 层次结构。

这个想法是你有实体或游戏对象，它们只是组件的集合，可能还有一些消息传递基础设施。组件存储有关它们附加到的实体的数据，例如，您可能有一个变换组件和一个速度组件。现在一种方法是拥有一个消息传递系统，组件可以连接并使用它来更新它们的数据。例如，Velocity 组件可能会挂接到 Update 消息中，并且在 Update 处理程序中它可以获取对象的转换并移动它。通过将消息用于组件之间的所有通信，您可以在很大程度上将它们解耦。

系统是处理更新组件数据的不同方式。Systems 的想法是，您有一个可以说“我使用这些组件对实体进行操作”的流程，然后它在运行时获取所有相关实体的列表。这进一步将数据与功能分离，并且可以更轻松地管理线程和依赖关系

本质上，面向对象的设计是关于捕捉现实世界中的“事物是什么”，但是对于您并不真正想要的游戏，您只关心事物的外观，并且您希望能够改变各个方面没有痛苦的事情的行为。

实体组件系统的好资源：

http://piemaster.net/2011/07/entity-component-primer/
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

于 2013-07-26T01:04:13.577 回答
0

在尝试编写代码之前，请考虑一下您要实现的目标（即使这样做的冲动非常强烈！）

尝试使用依赖注入来解耦你的类。现在这可能涉及添加一堆额外的类和复杂性，但相信我，当你不可避免地需要重构游戏的某些部分时，它会让你的生活变得更加轻松。避免使用“口香糖和胶带”解决方案，因为这样做会招致技术债务，以后会回来咬你！

于 2013-07-25T23:32:59.920 回答