在动态创建的菜单中避免全局状态

我正在尝试为我自己的学习编写一个游戏，并且提出了一个打破我的大脑的设计问题。这是一个非常简单的基于回合的游戏，玩家拥有自己的状态，库存和所有的状态;理想情况下，我想在世界其他地方添加一些有状态的元素。在动态创建的菜单中避免全局状态

我试图向玩家介绍他们随时可以使用的选项。我已经尝试在游戏流程控制中创建每个选项，但它变得难以管理，所以我现在尝试使用更好的设计。我的头号想法是有一个Action类，每个类都有一些状态测试编码入其中。这样我就可以在一个大的配置文件中定义可能的操作，并且在向用户提供选项时，我可以迭代Action.available测试以及返回true的测试。

#obligatory pseudopython 
class Action: 
    def __init__ (self, available_test, other_args): 
     #available is a function passed in, or perhaps some SQL query 
     self.available = available_test 

.... 
for a in action_array: 
    if a.available(): 
    #or maybe if test_handler(a.available) 
     options.append(a.option) 

gui.show_menu(options)

的问题，这似乎是行动的对象（或者处理程序），就需要以所有游戏状态的全球访问，看看他们是否可以执行。这立即引发了我头脑中的警告标志，但我无法看到它的方向。拥有一个拥有所有访问权限的处理程序听起来不会那么糟糕，但是这会引发如何指定测试的问题，除非我将所有数据都放入数据库中并将测试写入SQL中。不过，如果我这样做，我会绕过整个程序中的每个数据访问方法，这似乎也违背了良好的设计。

我在做什么错在我的想法？有没有更好的方法来做到这一点？我并不特别喜欢这种做事方式，在这个版本中我没有写太多的代码，我很乐意从头开始（已经这样做了）。我正在仔细阅读Code Complete的借阅副本，试图给我一些想法，但尽管听起来很稳固，但我仍然在摸索到做什么。

只是要清楚：我正在设计状态同时存储;我希望Action系统和状态存储协调一致地工作。在某种程度上，我想设计一个状态管理，使其可以通过Actions进行健壮但简单的访问。我正在用Python编写，但总的来说，我的目的是学习良好的软件设计技巧，所以我稍微偏好非语言特定的答案。

来源

2014-03-27 dataduck

我同意走出去并不是要走的路。此外，通过在内部添加对每个可能对象的每个可能动作来扩大播放角色的定义并不是一件好事。但是，我不认为使用Action对象是组织的正确方法。除了适用该行为的对象之外，行为通常没有意义。你可以解锁一个锁，但不是一块石头。

另外，如果您有一个角色在不同位置移动，则您可能有一种方法，即每个位置都提供有关该位置中存在的对象的信息。对于可移动物体，位置可以变成“在人身上”，并且您可能有办法为角色请求库存，这将提供对象列表。

我会建议组织行动的最简洁的方法是让每个ActionableObject知道可以对其执行哪些操作，包括了解每个操作的需求。对于本地中的每个对象或者库存中的任何对象，角色应该可以通过对对象本身的请求来获取可以在该对象上/通过该对象完成的操作。

功能WhatActionsCouldIDo

输入包括

人物发出请求（通常是玩家角色，但最终可能是一个非玩家角色，如果你有一个AI运行的NPC ）
当前位置，除非您始终保持对象本身内的当前位置信息

输出是可能对该对象执行的操作的列表。

对象在内部会考虑其可能定义的每个动作，并执行一个函数来检查该动作的要求是否满足给定（作为输入）字符和位置。通过角色论证，该功能可以调查角色的属性（例如，他足够强大并且不够负担来提升我？他是否有缺失的部分在他的库存中完成我？我是否在正确的位置是可能（这可能与尝试的动作是否会有所不同）？等等）

如果满足要求，则检查函数返回true，并将操作添加到将要执行的操作列表作为输出返回。

同样，该对象还会提供一个功能，以便执行选定的操作。

功能DoAction

输入包括

所选择的动作（从先前获得的列表）
字符发出请求（通常游戏者角色，但最终可能是一个非 - 人物角色，如果你有NPC运行与AI）
当前的位置，除非你总是已经马物体本身内的当前位置信息intain

即使进行需求检查以获取操作列表，最安全的路径是再次检查需求是否仍然满足。如果它们是，则该对象调用执行该动作的函数。

请注意，在此设计中，当请求动作时，对象将操纵角色和环境的状态，这在开始时可能看起来很奇怪。但是，这是为了响应的选择这个角色来执行动作，从而在角色或环境上产生动作的效果。对象通过提供所有必要的内部知识（包括那些不明显的）以及引起所有效果的结果的能力（包括角色可能不知道或预期的微妙效果，例如触发一些陷阱或对角色有非广告效果）。

这种布置应当允许保持角色对象本身非常干净而倾斜，只需要以暴露接口，以允许将其状态，例如期望改变补充一点，以它的存货，提高或削弱属性等

这种安排还允许很大的自由度，用于增加有可能采取的行动和效果，你没有原来预期的新对象。通常来说，这将需要添加的东西都可以放在新的对象类型本身，使用现有的接口角色和环境的位置。为了最大限度地提高这一点，我建议以通用术语表示动作列表，例如使用整数和/或文本的组合。角色类别不应该依赖于对所有可能对象或所有可能操作的意识。它只是在通用级别进行交互，为用户提供足够的信息供您选择。（另一方面，如果你想添加使用AI的NPC并需要理解不同的行为以制定策略，你可能需要修改一个修订的方法。这条路往往会导致很多更多的限制的可能性宇宙在相对于上述设计的无界的可能性。）

来源

2014-10-02 12:31:55 Eric

在动态创建的菜单中避免全局状态

回答

相关问题