【发布时间】：2010-09-17 10:51:02
【问题描述】：
我正在用 C# 开发一个“Zork”风格的文本冒险，它将有相当多的不同区域，包括描述和环境修饰符。理想情况下，我不想拥有数据库，除非它确实是最好的方法。
我需要有关存储/加载此数据的最佳方式的建议。
它将包括：
- 区域说明
- 环境调节剂（窗户打开/破损，门关闭）
- 默认存在的项目
【问题讨论】：
-
有些“数据库”比其他的更轻量，有没有像 sqlite 这样的东西不适合你的原因？
【发布时间】：2010-09-17 10:51:02
【问题描述】：
我会通过放弃 C# 并在 Inform7 中编写程序来解决您的问题。 Inform7 几乎是我见过的最棒的编程语言，它是专门为解决您的问题而设计的。
Inform7 的绝妙之处在于，您可以使用类似于文本冒险的语言编写文本冒险。例如，这里是一个示例冒险的源代码片段：
The iron-barred gate is a door.
"An iron-barred gate leads [gate direction]."
It is north of the Drawbridge and south of the Entrance Hall.
It is closed and openable.
Before entering the castle, try entering the gate instead.
Before going inside in the Drawbridge, try going north instead.
Understand "door" as the gate.
这给游戏增加了一个对象——这个对象是一扇门，它被称为“铁栅栏门”。一扇门被理解为位于两个房间之间，在这种情况下，是吊桥和入口大厅。如果玩家尝试“进入吊桥”，那么游戏逻辑会知道这与“北上”是一样的，然后门逻辑会判断门是否关闭。等等。它使编写文本冒险变得非常容易。
您想使用 C# 而不是像 Inform7 这样的特定领域的语言，有什么特别的原因吗？如果您的目标是学习如何编写 C# 代码或如何构建解析器或其他任何东西，那么一定要自己动手。如果您的目标是编写文本冒险，那么我会使用专为此设计的语言。
【讨论】：
-
取决于你写它的原因。如果您想了解如何构建文本冒险来自学，那么它并不真正相关。尽管如此，它仍然是一个可爱的工具。
-
我知道这是旧的，但这是我的两分钱。使用这样的工具构建文本冒险似乎既便宜又有限。你并不是真的在制作游戏，你只是在改变别人的游戏。这就提出了一个问题，如果你想做一些 Inform7 允许之外的事情，那么运气不好。我并不是说没有人应该使用这个工具，但如果你自己编写代码，你会学到更多东西，同时制作出更好的游戏。
-
@ryansworld10：你是在谈论你知道的事情，还是只是给出一个不知情的意见？如果您不了解情况，您真的应该看看 Inform7 中可实现的大量行为。这当然不是限制性的，便宜就是好东西。如果您的目标是学习如何使用 C# 编写冒险游戏，那么请务必使用 C# 构建您自己的系统。如果您的目标是编写冒险游戏，那么请使用可用的最佳工具编写冒险游戏。如果您喜欢航海，那么不要造船。帆船！
-
@ryansworld10：好吧，那很好，但是让我们采取一个魔鬼拥护者的立场：当你可以使用[在此处插入更低级别的编程语言]时，为什么还要使用[插入你使用的任何编程语言]？ 每一种高级语言都是由那些在易与难之间做出权衡的人设计的。
-
@ryansworld10。 Inform7 具有完全足够的命令式结构，如果情况变得更糟，您可以降级到 i6 并在其中编写代码。 Inform7 Extensions 页面上已经有一个 RPG 框架。 （不要误会，我认为 i7 是可怕，但绝不是无能）
将所有数据序列化到文件中。它将确保用户安装游戏时占用空间最小，没有任何真正的劣势。当您拥有大量数据时，数据库非常棒，但是您正在谈论将整个游戏内容加载到内存中的文本冒险。一个简单的文件就可以很好地解决这个问题。
注意，我说的不是 xml，而是二进制序列化。任何类型的文本序列化都将允许用户窥视您的数据，并作弊或破解游戏。您可以轻松地换入/换出序列化数据文件，无论是文本文件还是二进制文件。请记住，您的整个“文本”最多可能只有几百 KB。
【讨论】：
-
其实这个方案不错，二进制序列化。我不知道为什么我没有想到这一点。
-
不禁有点委屈在此之前提出了这个建议……嗯。
-
对不起，Rushyo，如果你先建议的话。我不太明白你在回答中所说的内容。
-
@Rushyo 公平地说，您对“如何存储数据”这个问题的回答是“好吧，我想这完全是主观的 - 这不是一个真正有效的问题。”。
-
不，我对问题的另一种解释的回答是上述。我在答案中的实际答案与此无关。请在引用我之前考虑上下文。
已经有许多交互式小说引擎。我会看看他们的数据格式，这样你就可以重用现有的内容和工具来编辑内容。
目前最流行的引擎是 Glulx http://eblong.com/zarf/glulx/ 和 Z-Machine http://en.wikipedia.org/wiki/Z-machine
这里是 Glulx 格式的技术参考：http://eblong.com/zarf/glulx/technical.txt
【讨论】：
我知道你不想要数据库，但你看过SQL Server Compact Edition 吗？它可能只是做你想做的事。
【讨论】：
-
我有办法阻止任何人实际查看数据库吗？可能是个愚蠢的问题。
-
这完全是一个不同的问题......我最终会说，不。如果它在客户端的机器上，无论你做什么来编码/加密/保护，你的应用程序都需要访问数据，因此确定的用户也可以。不过，打开它可能比 XML 序列化更棘手。
-
如果数据最终在他们的机器上，实际上是不可能阻止他们读取它的——因为如果他们的计算机可以读取它，那么他们就可以:)
我认为 C# 为您提供了正确的工具。只需将您的结构封装到类中。我们在大学的第一个 OOP 项目正是这个问题！这是 OOP 的完美案例研究。
然后，您可以使用 C# 的许多序列化方法将其永久存储（加载/保存），但您认为合适。
【讨论】：
-
[已删除 - 因为这是对另一条已删除评论的回复]
-
但问题也是“在哪里存储它”，将结构封装在 classes 中并没有说明将填充 objects 的数据的位置 i> 在 objects 被实例化之前存储。
-
好吧，我想这完全是主观的——不是一个真正有效的问题。纯文本文件？这根本不重要。这不会是一个瓶颈，没有正确的答案。只需以您认为合适的方式存储它。就我个人而言，我倾向于为我开发的每款游戏发明一种新格式，并针对问题使用适当的语义。一旦它们被创建一次，序列化和反序列化就涵盖了将来检索它。
-
@Filburt 是的一个选择 OP 正在征求意见
-
@rushye 除了因为接受的答案完全符合我的建议。解释如何序列化、使用哪种格式和存储类型并解释原因。
将您的冒险“编写”为一个大文本文件听起来如何？然后让您的应用程序解析这个文件，在类中构建冒险并从那里运行？
这意味着您可以使用简单的文本编辑器来编辑冒险。我想，当可以从单一来源做出多个决定时，可视化链接可能会变得很棘手。然而，这在没有一些专业前端的数据库中也会很棘手。
更新：
或者您是否考虑过 XML，例如...
<area id="DarkRoom1">
<description>Dark Room</description>
<item>Bucket</item>
<item>Spade</item>
</area>
然后使用它在内存中填充您的类。
【讨论】：
您可以将数据存储在文件系统（zip 文件或文件夹）中。
每个选项都可以存储为一个文件夹，而所有描述、修饰符和其他数据都可以存储为文本文件（xml？）。当用户做出决定时，您将转到相应的文件夹并按照情节进行。
例子：
你想：
- 开门（门）
- 离开（离开）
如果用户选择开门，则进入文件夹门并从该文件夹中的数据文件中读取数据。
优点：
- 简单
- 不需要数据库
- 轻松添加新冒险
缺点：
- 回滚决策问题（回到起点或情节中的某个点）
【讨论】：
就个人而言，在这种情况下，我会避免使用数据库，而是使用基于文本的文件格式（可能是两个不同的文件，一个用于初始状态（如地形等），它永远不会被修改，另一个用于在游戏过程中要修改的状态（破碎的窗户等）；或者将整个事物分成每个区域的一对静态/动态数据。
几个原因：
- 文本文件是人类可读的；因此，您可以在没有专用编辑器的情况下创建内容，而使用数据库方法，您要么必须通过查询输入数据，要么编写关卡编辑器
- 假设单人场景，并发不是问题
- 存档游戏是将修改后的状态文件复制到存档游戏文件夹中，或将它们打包到单个文件中
- 您可以轻松嵌入脚本
- 您正在处理的数据结构可能足够简单，因此数据完整性不会成为严重问题
【讨论】：