面对EDT，如何管理游戏状态？

发布于 2024-07-23 06:35:32 字数 2855 浏览 10 评论 0原文

我正在 Java 平台上开发一个实时策略游戏克隆，我有一些关于放置在哪里以及如何管理游戏状态的概念性问题。游戏使用Swing/Java2D作为渲染。在当前的开发阶段，没有模拟，没有人工智能，只有用户能够改变游戏的状态（例如，建造/拆除建筑物、添加/删除生产线、组装车队和设备）。因此，游戏状态操作可以在事件分派线程中执行，而无需任何渲染查找。游戏状态还用于向用户显示各种聚合信息。

然而，由于我需要引入模拟（例如，建筑进度、人口变化、舰队移动、制造过程等），因此在计时器和 EDT 中更改游戏状态肯定会减慢渲染速度。

假设每 500 毫秒执行一次模拟/AI 操作，我使用 SwingWorker 进行大约 250 毫秒长度的计算。我如何确保模拟和可能的用户交互之间不存在关于游戏状态读取的竞争条件？

我知道模拟结果（少量数据）可以通过 SwingUtilities.invokeLater() 调用有效地移回 EDT。

游戏状态模型似乎太复杂了，无法在任何地方使用不可变的值类。

有没有相对正确的方法来消除这种读竞争条件？也许在每个计时器滴答声上进行完整/部分游戏状态克隆，或者将游戏状态的生存空间从 EDT 更改为其他线程？

更新：（来自我给出的评论）该游戏由 13 名人工智能控制的玩家和 1 名人类玩家运行，拥有约 10000 个游戏对象（行星、建筑物、设备、研究等）。例如，游戏对象具有以下属性：

World (Planets, Players, Fleets, ...)
Planet (location, owner, population, type, 
    map, buildings, taxation, allocation, ...)
Building (location, enabled, energy, worker, health, ...)

在场景中，用户在这个星球上建造一座新建筑。这是在 EDT 中执行的，因为需要更改地图和建筑物集合。与此同时，每 500 毫秒运行一次模拟，计算所有游戏星球上建筑物的能量分配，这需要遍历建筑物集合进行统计收集。如果计算出分配，则将其提交给 EDT，并分配每个建筑物的能量场。

只有人类玩家交互才具有此属性，因为 AI 计算的结果无论如何都会应用于 EDT 中的结构。

一般来说，75%的对象属性是静态的并且仅用于渲染。其余部分可以通过用户交互或模拟/人工智能决策来更改。还可以确保，在前一个步骤写回所有更改之前，不会启动新的模拟/AI 步骤。

我的目标是：

避免延迟用户交互，例如用户将建筑物放置到地球上，并且仅在 0.5 秒后才获得视觉反馈
避免通过计算、锁定等待等阻塞 EDT
避免集合遍历和修改、属性更改等并发问题

选项：

细粒度对象锁定
不可变集合
易失性字段
部分快照

所有这些对模型和游戏都有优点、缺点和原因。

更新2：我正在谈论这款游戏。我的克隆位于此处。屏幕截图可能有助于想象渲染和数据模型的交互。

更新3：

我将尝试提供一个小代码示例来澄清我的问题，因为从评论看来它被误解了：

List<GameObject> largeListOfGameObjects = ...
List<Building> preFilteredListOfBuildings = ...
// In EDT
public void onAddBuildingClicked() {
    Building b = new Building(100 /* kW */);
    largeListOfGameObjects.add(b);
    preFilteredListOfBuildings.add(b);
}
// In EDT
public void paint(Graphics g) {
    int y = 0;
    for (Building b : preFilteredListOfBuildings) {
        g.drawString(Integer.toString(b.powerAssigned), 0, y);
        y += 20;
    }
}
// In EDT
public void assignPowerTo(Building b, int amount) {
    b.powerAssigned = amount;
}
// In simulation thread
public void distributePower() {
    int sum = 0;
    for (Building b : preFilteredListOfBuildings) {
        sum += b.powerRequired;
    }
    final int alloc = sum / (preFilteredListOfBuildings.size() + 1);
    for (final Building b : preFilteredListOfBuildings) {
        SwingUtilities.invokeLater(=> assignPowerTo(b, alloc));            
    }
}

因此重叠位于onAddBuildingClicked()和distributePower()之间。现在想象一下这样的情况：游戏模型的各个部分之间有 50 个此类重叠。

原文

I'm developing a real time strategy game clone on the Java platform and I have some conceptional questions about where to put and how to manage the game state. The game uses Swing/Java2D as rendering. In the current development phase, no simulation and no AI is present and only the user is able to change the state of the game (for example, build/demolish a building, add-remove production lines, assemble fleets and equipment). Therefore, the game state manipulation can be performed in the event dispatch thread without any rendering lookup. The game state is also used to display various aggregated information to the user.

However, as I need to introduce simulation (for example, building progress, population changes, fleet movements, manufacturing process, etc.), changing the game state in a Timer and EDT will surely slow down the rendering.

Lets say the simulation/AI operation is performed in every 500ms and I use SwingWorker for the computation of about 250ms in length. How can I ensure, that there is no race condition regarding the game state reads between the simulation and the possible user interaction?

I know that the result of the simulation (which is small amount of data) can be efficiently moved back to the EDT via the SwingUtilities.invokeLater() call.

The game state model seems to be too complex to be infeasible for just using immutable value classes everywhere.

Is there a relatively correct approach to eliminate this read race condition? Perhaps doing a full/partial game state cloning on every timer tick or change the living space of the game state from EDT into some other thread?

Update: (from the comments I gave)
The game operates with 13 AI controlled players, 1 human player and has about 10000 game objects (planets, buildings, equipment, research, etc.). A game object for example has the following attributes:

World (Planets, Players, Fleets, ...)
Planet (location, owner, population, type, 
    map, buildings, taxation, allocation, ...)
Building (location, enabled, energy, worker, health, ...)

In a scenario, the user builds a new building onto this planet. This is performed in EDT as the map and buildings collection needs to be changed. Parallel to this, a simulation is run on every 500ms to compute the energy allocation to the buildings on all game planets, which needs to traverse the buildings collection for statistics gathering. If the allocation is computed, it is submitted to the EDT and each building's energy field gets assigned.

Only human player interactions have this property, because the results of the AI computation are applied to the structures in EDT anyway.

In general, 75% of the object attributes are static and used only for rendering. The rest of it is changeable either via user interaction or simulation/AI decision. It is also ensured, that no new simulation/AI step is started until the previous one has written back all changes.

My objectives are:

Avoid delaying the user interaction, e.g. user places the building onto the planet and only after 0.5s gets the visual feedback
Avoid blocking the EDT with computation, lock wait, etc.
Avoid concurrency issues with collection traversal and modification, attribute changes

Options:

Fine grained object locking
Immutable collections
Volatile fields
Partial snapshot

All of these have advantages, disadvantages and causes to the model and the game.

Update 2: I'm talking about this game. My clone is here. The screenshots might help to imagine the rendering and data model interactions.

Update 3:

I'll try to give a small code sample for clarify my problem as it seems from the comments it is misunderstood:

List<GameObject> largeListOfGameObjects = ...
List<Building> preFilteredListOfBuildings = ...
// In EDT
public void onAddBuildingClicked() {
    Building b = new Building(100 /* kW */);
    largeListOfGameObjects.add(b);
    preFilteredListOfBuildings.add(b);
}
// In EDT
public void paint(Graphics g) {
    int y = 0;
    for (Building b : preFilteredListOfBuildings) {
        g.drawString(Integer.toString(b.powerAssigned), 0, y);
        y += 20;
    }
}
// In EDT
public void assignPowerTo(Building b, int amount) {
    b.powerAssigned = amount;
}
// In simulation thread
public void distributePower() {
    int sum = 0;
    for (Building b : preFilteredListOfBuildings) {
        sum += b.powerRequired;
    }
    final int alloc = sum / (preFilteredListOfBuildings.size() + 1);
    for (final Building b : preFilteredListOfBuildings) {
        SwingUtilities.invokeLater(=> assignPowerTo(b, alloc));            
    }
}

So the overlapping is between the onAddBuildingClicked() and distributePower(). Now imagine the case where you have 50 of these kind of overlappings between various parts of the game model.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

回心转意 2024-07-30 06:35:32

这听起来像是可以从客户端/服务器方法中受益：

玩家是客户端 - 交互和渲染发生在客户端。因此，玩家按下按钮，请求就会发送到服务器。服务器返回回复，玩家状态更新。在这些事情发生之间的任何时刻，屏幕都可以重新绘制，它反映了客户端当前所知的游戏状态。

人工智能同样是一个客户端——它相当于一个机器人。

模拟的是服务器。它在不同时间从客户端获取更新并更新世界状态，然后根据需要将这些更新发送给每个人。这就是它与您的情况相关的地方：模拟/人工智能需要一个静态的世界，并且许多事情同时发生。服务器可以简单地将更改请求排队并在将更新发送回客户端之前应用它们。因此，就服务器而言，游戏世界实际上并没有实时变化，而是只要服务器决定它就在变化。

最后，在客户端，您可以通过执行一些快速近似计算并显示结果（因此满足即时需求）来防止按下按钮和查看结果之间的延迟，然后在服务器绕过时显示更正确的结果和你说话。

请注意，这实际上不必以 TCP/IP 互联网上的方式实现，只是有助于以这些术语来思考它。

或者，您可以将在模拟过程中保持数据一致性的责任放在数据库上，因为它们在构建时已经考虑了锁定和一致性。像 sqlite 这样的东西可以作为非网络解决方案的一部分。

回复收藏 0 原文

深居我梦 2024-07-30 06:35:32

不确定我完全理解您正在寻找的行为，但听起来您需要诸如状态更改线程/队列之类的东西，以便所有状态更改都由单个线程处理。

为状态更改队列创建一个 api，例如 SwingUtilities.invokeLater() 和/或 SwingUtilities.invokeAndWait() 来处理状态更改请求。

我认为这如何反映在 GUI 中取决于您正在寻找的行为。即无法取款，因为当前状态为 0 美元，或者在处理取款请求时向用户弹回帐户为空的信息。（可能不使用该术语；-））

回复收藏 0 原文

平定天下 2024-07-30 06:35:32

最简单的方法是使模拟足够快以在 EDT 中运行。更喜欢有效的程序！

对于双线程模型，我建议将领域模型与渲染模型同步。渲染模型应该保留来自域模型的数据。

更新：在模拟线程中锁定渲染模型。遍历渲染模型更新，其中与预期更新渲染模型的内容不同。完成遍历后，解锁渲染模型并安排重新绘制。请注意，在这种方法中，您不需要无数的听众。

渲染模型可以有不同的深度。在一个极端情况下，它可能是一个图像，而更新操作只是用新的图像对象替换单个引用（例如，这不能很好地处理调整大小或其他表面交互）。您可能不会费心检查某个项目是否已更改，而只是更新所有内容。

回复收藏 0 原文

暖风昔人 2024-07-30 06:35:32

如果更改游戏状态的速度很快（一旦您知道将其更改为什么），您可以像其他 Swing 模型一样对待游戏状态，并且仅更改或查看 EDT 中的状态。如果更改游戏状态并不快，那么您可以同步状态更改并在 Swing Worker/Timer（但不是 EDT）中执行此操作，或者您可以在与 EDT 类似的单独线程中执行此操作（此时您可以看看使用 BlockingQueue 来处理更改请求）。如果 UI 不需要从游戏状态检索信息，而是通过侦听器或观察者发送渲染更改，则最后一个更有用。

回复收藏 0 原文

就像说晚安 2024-07-30 06:35:32

是否有可能增量更新游戏状态并仍然拥有一致的模型？例如，在渲染/用户更新之间重新计算行星/玩家/舰队对象的子集。

如果是这样，您可以在 EDT 中运行增量更新，在允许 EDT 处理用户输入和渲染之前仅计算一小部分状态。

在 EDT 中的每次增量更新之后，您需要记住还有多少模型需要更新，并在 EDT 上安排一个新的 SwingWorker 以在执行任何挂起的用户输入和渲染后继续此处理。

这应该允许您避免复制或锁定游戏模型，同时仍然保持用户交互响应。

回复收藏 0 原文

寂寞花火° 2024-07-30 06:35:32

我认为你不应该让世界存储任何数据或对任何对象本身进行更改，它应该只用于维护对对象的引用，并且当需要更改该对象时，让玩家直接更改它。在这种情况下，您唯一需要做的就是同步游戏世界中的每个对象，以便当玩家进行更改时，其他玩家无法执行此操作。这是我的想法的一个例子：

玩家 A 需要了解一个星球，因此它向 World 询问该星球（如何取决于您的实现）。 World 返回玩家 A 请求的 Planet 对象的引用。玩家 A 决定做出改变，所以它就这么做了。假设它增加了一座建筑物。将建筑物添加到星球的方法是同步的，因此一次只有一个玩家可以这样做。该建筑将跟踪其自身的建造时间（如果有），因此星球的添加建筑方法将几乎立即被释放。这样，多个玩家可以同时询问同一星球上的信息，而不会互相影响，并且玩家可以几乎同时添加建筑物，而不会出现太大的延迟。如果两个玩家正在寻找放置建筑物的地方（如果这是游戏的一部分），那么检查位置的适用性将是一个查询而不是更改。

如果这不能回答您的问题，我很抱歉，我不确定我是否理解正确。

回复收藏 0 原文