这些都不是游戏特有的，但这是游戏中经常出现的问题，因为有太多不同的子系统，我们尚未开发出标准方法。如果你进行 Web 开发，那么实际上只有一小部分已建立的范例：PHP 之类的“每个 URI 一个模板/代码文件”，或者可能是 RoR、Django 的“模型/视图模板/控制器”方法，加上其他几个。但对于游戏，每个人都在推出自己的游戏。
Ah, if only there were a good answer to your question. Then game development wouldn't be nearly as difficult, risky, and time-consuming.
I attempt to keep the connections to a minimum and reduce coupling however many of these systems need to talk in one way or another that doesn't require holding your entire code-base in your head at one time.
They do, but often they don't need to talk in quite as direct a way as people first believe. For example, it's common to have the game state push values into its GUI whenever something changes. If instead you can just store values and let the GUI query them (perhaps via an observer pattern), you have then removed all GUI references from the game state. Often it's enough to simply ask whether a subsystem can pull the information it needs from a simple interface instead of having to push the data in.
How do objects communicate with each other?
Where should the code that handles specific subsystems go?
How much of my code base should I have to think about at one time?
How can I reduce coupling between game entities?
None of this is really specific to games, but it's a problem that arises often with games because there are so many disparate subsystems that we've not yet developed standard approaches to. If you take web development then there are really just a small number of established paradigms: the "one template/code file per URI" of something like PHP, or maybe the "model/view-template/controller" approach of RoR, Django, plus a couple of others. But for games, everybody is rolling their own.
But one thing is clear: you can't solve the problem by asking 'How do objects communicate'. There are many different types of object and they require different approaches. Don't try and find one global solution to fit every part of your game - input, networking, audio, physics, artificial intelligence, rendering, serialisation - it's not going to happen. If you try to write any application by trying to come up with a perfect IObject interface that will suit every purpose then you'll fail. Solve individual problems first and then look for the commonality, refactoring as you go. Your code must first be usable before it can be even considered to be reusable.
Game subsystems live at whatever level they need to, no higher. Typically I have a top level App, which owns the Graphics, Sound, Input, and Game objects (among others). The Game object owns the Map or World, the Players, the non-players, the things that define those objects, etc.
Distinct game states can be a bit tricky but they're actually not as important as people assume they are. Pause can be coded as a boolean which, when set, simply disables AI/physics updates. Menus can be coded as simple GUI overlays. So your 'menu state' merely becomes a case of pausing the game and showing the menu, and unpausing the game when the menu is closed - no explicit state management required.
Reducing coupling between game entities is pretty easy, again as long as you don't have an amorphous idea of what a game entity is that leads to everything needing to potentially talk to everything. Game characters typically live within a Map or a World, which is essentially a spatial database (among other things) and can ask the World to tell it about nearby characters and objects, without ever needing to hold direct references to them.
Overall though you just have to use good software development rules for your code. The main thing is to keep interfaces small, simple, and focused on one and only one aspect. Loose coupling and the ability to focus on smaller areas of the code flows naturally from that.
发布评论
评论（1）
啊，如果你的问题有一个好的答案就好了。那么游戏开发就不会那么困难、风险和耗时。
他们确实这样做，但通常他们不需要像人们最初认为的那样直接地交谈。例如，每当发生变化时，游戏状态都会将值推送到其 GUI 中，这是很常见的。相反，如果您可以只存储值并让 GUI 查询它们（可能通过观察者模式），那么您就已经从游戏状态中删除了所有 GUI 引用。通常，只需询问子系统是否可以从简单的接口中提取所需的信息就足够了，而不必将数据推入。
这些都不是游戏特有的，但这是游戏中经常出现的问题，因为有太多不同的子系统，我们尚未开发出标准方法。如果你进行 Web 开发，那么实际上只有一小部分已建立的范例：PHP 之类的“每个 URI 一个模板/代码文件”，或者可能是 RoR、Django 的“模型/视图模板/控制器”方法，加上其他几个。但对于游戏，每个人都在推出自己的游戏。
但有一件事是明确的：你不能通过询问“对象如何通信”来解决问题。有许多不同类型的对象，它们需要不同的方法。不要试图找到一种全局解决方案来适应游戏的每个部分——输入、网络、音频、物理、人工智能、渲染、序列化——这是不可能的。如果您尝试通过尝试提出一个适合各种目的的完美 IObject 接口来编写任何应用程序，那么您将会失败。首先解决个别问题，然后寻找共性，边重构边重构。您的代码必须首先可用，然后才能被视为可重用。
游戏子系统处于它们需要的任何级别，不能更高。通常我有一个顶级应用程序，它拥有图形、声音、输入和游戏对象（等等）。游戏对象拥有地图或世界、玩家、非玩家、定义这些对象的事物等。
不同的游戏状态可能有点棘手，但它们实际上并不像人们想象的那么重要。暂停可以编码为布尔值，设置后，只需禁用人工智能/物理更新。菜单可以编码为简单的 GUI 覆盖层。因此，您的“菜单状态”只是暂停游戏并显示菜单，并在菜单关闭时取消暂停游戏 - 不需要显式的状态管理。
减少游戏实体之间的耦合非常容易，只要您对游戏实体是什么没有一个模糊的概念，而这会导致一切都需要潜在地与一切进行对话。游戏角色通常生活在地图或世界中，地图或世界本质上是一个空间数据库（除其他外），可以要求世界告诉它附近的角色和物体，而无需直接引用它们。
总的来说，您只需要为您的代码使用良好的软件开发规则即可。最重要的是保持界面小、简单，并且只专注于一个方面。松散耦合和专注于较小代码区域的能力自然而然地由此产生。
Ah, if only there were a good answer to your question. Then game development wouldn't be nearly as difficult, risky, and time-consuming.
They do, but often they don't need to talk in quite as direct a way as people first believe. For example, it's common to have the game state push values into its GUI whenever something changes. If instead you can just store values and let the GUI query them (perhaps via an observer pattern), you have then removed all GUI references from the game state. Often it's enough to simply ask whether a subsystem can pull the information it needs from a simple interface instead of having to push the data in.
None of this is really specific to games, but it's a problem that arises often with games because there are so many disparate subsystems that we've not yet developed standard approaches to. If you take web development then there are really just a small number of established paradigms: the "one template/code file per URI" of something like PHP, or maybe the "model/view-template/controller" approach of RoR, Django, plus a couple of others. But for games, everybody is rolling their own.
But one thing is clear: you can't solve the problem by asking 'How do objects communicate'. There are many different types of object and they require different approaches. Don't try and find one global solution to fit every part of your game - input, networking, audio, physics, artificial intelligence, rendering, serialisation - it's not going to happen. If you try to write any application by trying to come up with a perfect IObject interface that will suit every purpose then you'll fail. Solve individual problems first and then look for the commonality, refactoring as you go. Your code must first be usable before it can be even considered to be reusable.
Game subsystems live at whatever level they need to, no higher. Typically I have a top level App, which owns the Graphics, Sound, Input, and Game objects (among others). The Game object owns the Map or World, the Players, the non-players, the things that define those objects, etc.
Distinct game states can be a bit tricky but they're actually not as important as people assume they are. Pause can be coded as a boolean which, when set, simply disables AI/physics updates. Menus can be coded as simple GUI overlays. So your 'menu state' merely becomes a case of pausing the game and showing the menu, and unpausing the game when the menu is closed - no explicit state management required.
Reducing coupling between game entities is pretty easy, again as long as you don't have an amorphous idea of what a game entity is that leads to everything needing to potentially talk to everything. Game characters typically live within a Map or a World, which is essentially a spatial database (among other things) and can ask the World to tell it about nearby characters and objects, without ever needing to hold direct references to them.
Overall though you just have to use good software development rules for your code. The main thing is to keep interfaces small, simple, and focused on one and only one aspect. Loose coupling and the ability to focus on smaller areas of the code flows naturally from that.