我正在Kotlin编写一款Android游戏,其中棋盘会根据特定模式进行更改 - 这种模式取决于用户当前播放的级别。
我需要一种方法在我的代码中使用许多不同的模式(最多20个,30个),决定在运行时使用哪个模式。
我想过将每个模式编码为一个字符串,将所有这些字符串放在一个文件中,并在运行时加载它并解析所需的字符串。但是,模式并不那么简单,因此解析将是一个复杂的过程。它似乎也过于复杂。
我现在最好的想法是为每个不同的模式编写一个类(以及一个由调用实体使用的公共父抽象类)。每个类都有一个“apply”方法,可以在板上应用该特定模式。
但是,它意味着几十个类(我可以将它们放在不同的文件夹中,这样它们就不会使主代码文件夹太拥挤),以及一个映射模式id的大开关案例(从级别管理器接收)具体实施。我很确定我不希望这样。
有更好的想法吗?提前谢谢。
答案 0 :(得分:0)
这取决于将来会发生什么。会有更多的模式吗?它们是否具有常见的部件?是否会有其他规则,比如你是否使用过模式1,那么你下次不能再去模式1等等?
无论哪种方式,你都会有十几种模式。将它们存储为字符串,对象,文件,模型或其他任何东西完全取决于您,但您不会逃避拥有它们。我的意思是,拥有20个模式的1个文件与拥有1个模式的20个文件没有太大区别。所以不,在这种情况下,拥有许多课程并不是错误的。
将它们放在一个文件夹中并创建一个外观。这样你需要做的就是调用外观并根据一些标准获得apply方法(模式id):
外观本身可以将id映射到行为,也可以直接检查文件夹中是否存在以该方式命名的文件(类)。如果有一个,它将获得它的实例并因此调用apply方法。您可以存储实例:
<强>的优点:强>
可以随时更改,行为也会改变
只有一种方式呈现模式(没有选项可以获得两种模式来尝试绘制自己的模式)
<强>缺点:强>
这样你就不需要切换了,如果出现新模式就没有必要更改外观本身 - 只需用自己的实现创建新文件就可以了。
答案 1 :(得分:0)
这个问题对于SO来说不是那么理想,但是,我发现它真的很有趣。因此,如果我必须设计这样的游戏,我会提出一些想法。
这是一款基于关卡的游戏,会在不同级别产生不同的棋盘模式。因此,如何设计要转换为电路板的模式非常重要。您的模式可能包含一些通用关键字,可以将其转换为程序,以逐个部分创建电路板。让我们看一个例子,让这个想法更清晰。
假设您正在构建一系列管道。每个部件都与已经构造的管道连接。手中可能有很多不同形状的管道。因此,在构建模式时,您只需为每个形状命名。例如,左圆垂直向上,右圆垂直向上,直水平,直垂直等。您有一个Factory
类,它知道每个形状的实现。现在将整个模式存储在本地数据库表中非常简单。根据您的Factory
类具有的逻辑,它将在运行时转换为您的电路板。
数据库表中的示例行可能如下所示。
id level_number level_passed pattern_desc
-- ------------ ------------ ------------
1 1 1 left-round-vertical-up, straight-horizontal, straight-vertical, right-round-vertical-up
2 1 0 straight-horizontal, straight-vertical, right-round-vertical-up
因此,当您在数据库中拥有上述结构中的数据并且您知道要在您的电路板中翻译管段的所有关键字时,您可以更轻松地维护代码并通过API调用添加新模式。
在您当前的结构中,很难在没有任何应用程序更新的情况下更新您的模式。但是,在提议的体系结构中,您可以使用服务器上的简单API调用轻松地在不同级别添加新模式。应用程序知道如何解析模式并相应地显示它们。然后,您的工作是调用API以从服务器获取新引入的模式,并将它们插入到表中,以存储具有适当值的模式。
factory implementation可能需要许多类,表示管段的每个形状。但是,您没有为每个模式编写类,这些模式非常多,难以进一步管理。
希望有所帮助!