在业余时间我编写游戏程序作为一种业余爱好，不同的各种各样的事情，目前没有什么很复杂的。事情喜欢2D射手，基于瓦片的游戏，益智游戏等......技术来降低复杂性在游戏编程
但是随着这些游戏的发展，我发现很难管理游戏中不同子系统的复杂性，比如Interface，世界视图/模型，事件处理，状态（菜单，暂停等），特殊效果等。
我试图保持到最低限度的连接和降低耦合然而，许多这些系统都需要在这种或那种方式，不需要一次抱着你的整个代码库在你的头上谈话。
目前，我试图委派不同的子系统和子系统的功能被集中在一起，但是我还没有发现，就足够了解耦通信策略不同的对象。
我可以使用什么样的技术来帮我忙里忙外的所有这些不同的子系统和处理不断增加的系统，它需要足够模块化，方便快速需求变更的复杂性？
我经常发现自己在问同一个问题：
啊，只要有是一个很好的回答你的问题。然后，游戏开发不会像现在一样困难，风险和耗时。
我试图保持到最低限度 的连接，降低耦合然而 许多这样的系统需要在 一种方式说话或另一台未 需要保持你的整个代码库 在你的头上一次。
他们会这样做，但他们通常不需要像人们首先相信的那样直接说话。例如，只要有些事情发生变化，游戏状态通常会将值推入GUI。相反，如果您只需存储值并让GUI查询它们（可能通过观察者模式），则可以从游戏状态中删除所有GUI引用。通常，这是不够的，只是问一个子系统是否可以把它从一个简单的界面，而不必推入数据所需要的信息。
- 如何对象相互沟通？
- 处理特定子系统的代码应该放在哪里？
- 我需要多少代码库才能同时考虑？
- 如何减少游戏实体之间的耦合？
无的，这是真的具体到比赛，但是那是因为有一些我们还没有制定标准的方法来这么多不同的子系统，随着游戏经常出现的问题。如果你进行web开发，那么实际上只有少数已建立的范例：像PHP这样的“每个URI一个模板/代码文件”，或者RoR，Django的“模型/视图模板/控制器”方法，再加上其他几个。但是对于游戏，每个人都在自己推出。
但有一点很清楚：你不能通过询问'物体如何通信'来解决问题。有许多不同类型的对象，他们需要不同的方法。不要试图找到适合游戏各个部分的全局解决方案 - 输入，网络，音频，物理，人工智能，渲染，序列化 - 这不会发生。如果您尝试编写任何应用程序，试图提出一个适合各种用途的完美IObject接口，那么您将失败。首先解决个人问题，然后寻找共同点，随时重构。您的代码必须先可用，然后才能被视为可重用。
游戏子系统生活在他们需要的任何级别，不高于。通常我有一个顶级应用程序，它拥有图形，声音，输入和游戏对象等等。游戏对象拥有地图或世界，玩家，非玩家，定义这些对象的东西等。
不同的游戏状态可能有点棘手，但实际上它们并不像人们假设的那样重要是。暂停可以被编码为布尔值，当设置时，只需禁用AI /物理更新。菜单可以编码为简单的GUI覆盖图。因此，您的“菜单状态”仅仅是暂停游戏并显示菜单的情况，并且在菜单关闭时解除游戏暂停状态 - 不需要明确的状态管理。
减少游戏实体之间的耦合非常容易，只要你不知道游戏实体是什么，导致所有事情都需要潜在地与所有事物对话。游戏角色通常生活在地图或世界中，实际上它是一个空间数据库（等等），并可以要求世界告诉它关于附近的角色和对象，而不需要直接引用它们。
总体而言，尽管您只需为您的代码使用良好的软件开发规则。最主要的是保持界面小巧，简单，并且只关注一个方面。松散的耦合以及专注于代码较小区域的能力自然而然地从此流向。
优秀的答案，就是我在找的东西。看来我目前的设计一直在努力做出完美的“IObject”。再次感谢。 – 2010-01-27 13:43:35
+1“*首先解决个人问题......随时重构。”* – 2010-01-27 15:18:29