以OO方式进行游戏设计 [英] Game design in an OO manner

问题描述

我正在设计一款使用Java 2D和牛顿物理的简单游戏。目前我的主要游戏循环看起来像：

  do {
 for（GameEntity entity：entities）{
 entity.update（gameContext）; 
} 
 
 for（Drawable drawable：drawables）{
 drawable.draw（graphics2d）; 
} 
} while（gameRunning）; 
  

当指示实体自我更新时，它将根据当前施加的力调整其速度和位置它。但是，我需要实体展示其他行为;例如如果玩家射杀了坏人，那么该实体应该被摧毁并从游戏世界中删除。

我的问题：什么是以面向对象的方式实现这一目标的最佳方法是什么？到目前为止我见过的所有例子都将游戏循环合并到一个名为 Game 之类的God类中，它执行以下步骤：检测碰撞，检查是否错误-guy-killed，check-if-player-killed，repaint 等，并封装所有游戏状态（剩下的生命等）。换句话说，它非常程序，所有逻辑都在Game类中。任何人都可以推荐更好的方法吗？

以下是我到目前为止所考虑的选项：

• 将 GameContext 传递给每个实体，如果需要，实体可以从中移除自身或更新游戏状态（例如，如果玩家是


• 将每个 GameEntity 注册为中央游戏的监听器上课并采取以事件为导向的方法;例如碰撞会导致向碰撞中的两个参与者发射 CollisionEvent 。

解决方案

我与两个商业游戏引擎密切合作，他们遵循类似的模式： / p>

• 对象代表游戏实体的组件或方面（如物理，可渲染，等等），而不是整个实体。对于每种类型的组件，都有一个巨大的组件列表，每个实体实例都有一个组件。




• 游戏实体类型本身就是一个唯一的ID。每个巨大的组件列表都有一个映射，用于查找与实体ID对应的组件（如果存在）。




• 如果组件需要更新它由服务或系统对象调用。每个服务都直接从游戏循环更新。或者，您可以从调度程序对象调用服务，该对象从依赖关系图确定更新顺序。

以下是优点这种方法：

• 您可以自由组合功能
  而无需为每个
  组合编写新类或使用复杂继承
  树。




• 几乎没有功能可以假设
  你所有游戏
  实体你可以投入游戏
  实体基类（轻型
  与赛车或
  天空盒有什么共同点？）




• ID到组件的查找可能看起来很贵，但是服务正在进行
  大部分密集工作
  迭代所有组件$ b $特定类型的b。在这些情况下，
  它可以更好地将您需要的所有数据
  存储在一个整洁的列表中。

I'm designing a simple game, which uses Java 2D and Newtonian physics. Currently my main "game loop" looks something like:

do {
  for (GameEntity entity : entities) {
    entity.update(gameContext);
  }

  for (Drawable drawable : drawables) {
    drawable.draw(graphics2d);
  }
} while (gameRunning);

When an entity is instructed to update itself it will adjust its velocity and position based on the current forces applied to it. However, I need entities to exhibit other behaviour; e.g. if a "bad guy" is shot by a player the entity should be destroyed and removed from the game world.

My question: What is the best way to achieve this in an object oriented manner? All examples I've seen so far incorporate the game loop into a God class called something like Game, which performs the steps: detect collisions, check-if-bad-guy-killed, check-if-player-killed, repaint, etc and encapsulates all the game state (lives remaining, etc). In other words, it's very procedural and all the logic is in the Game class. Can anyone recommend a better approach?

Here are the options I've thought of so far:

• Pass a GameContext to each entity from which the entity can remove itself if required or update the game state (e.g. to "not running" if the player is killed).
• Register each GameEntity as a listener to the central Game class and take an event oriented approach; e.g. a collision would result in a CollisionEvent being fired to the two participants in the collision.

解决方案

I have worked closely with two commercial game engines and they follow a similar pattern:

• Objects represent components or aspects of a game entity (like physical, renderable, whatever), rather than the whole entity. For each type of component there is a giant list of components, one for each entity instance that has the component.

• The 'game entity' type itself is just a unique ID. Each giant list of components has a map to look up the component (if any exists) that corresponds to an entity ID.

• If a component requires an update it is called by a service or system object. Each service is updated directly from the game loop. Alternatively, you could call services from a scheduler object which determines update order from a dependency graph.

Here are the advantages of this approach:

• You can freely combine functionality without writing new classes for every combination or using complex inheritance trees.

• There is almost no functionality that you can assume about all game entities that you could put in a game entity base class (what does a light have in common with a race car or a sky-box?)

• The ID-to-component look-ups might seem expensive, but services are doing most of the intensive work by iterating through all the components of a particular type. In these cases, it works better to store all the data you need in a single tidy list.

这篇关于以OO方式进行游戏设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！