存储文本冒险区域数据的最佳方法是什么?

时间:2010-09-17 10:51:02

标签: c# .net

我正在用C#开发一个“Zork”风格的文本冒险,并且它将有相当多的不同区域,包括描述和环境修饰符。理想情况下,我不想拥有一个数据库,除非它确实是最好的方法。

我需要有关存储/加载此数据的最佳方法的建议。

它将包括:

  • 区域描述
  • 环境改良剂(窗户打开/折断,门关闭)
  • 默认显示的项目

8 个答案:

答案 0 :(得分:13)

我会通过放弃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#代码或如何构建解析器或其他什么,那么一定要自己动手。如果您的目标是撰写文本冒险,那么我将使用专为此设计的语言。

答案 1 :(得分:7)

将所有数据序列化为文件。当用户安装游戏时,它将确保最小的占地面积,没有任何真正的缺点。当您拥有大量数据时,数据库非常棒,但您正在谈论文本冒险,您可以在其中将整个游戏内容加载到内存中。一个简单的文件可以很好地工作。

注意,我不是在讨论xml而是二进制序列化。任何类型的文本序列化都将允许用户查看您的数据,并欺骗或破解游戏。您可以轻松地交换/输出序列化数据文件,无论是文本还是二进制文件。请记住,您的整个“文本”最多可能只有几百千字节。

答案 2 :(得分:2)

已经有很多互动小说引擎。我会看看他们的数据格式,这样你就可以重复使用现有的内容和工具来编辑内容。

目前最受欢迎的引擎是Glulx http://eblong.com/zarf/glulx/和Z-Machine http://en.wikipedia.org/wiki/Z-machine

以下是Glulx格式的技术参考:http://eblong.com/zarf/glulx/technical.txt

答案 3 :(得分:1)

我知道你不想要数据库,但是你看过SQL Server Compact Edition吗?它可能就是你想要的。

答案 4 :(得分:0)

我认为C#为您提供了恰当的工具。只需将结构封装到类中。我们在大学的第一个OOP项目就是这个问题!这是OOP的完美案例研究。

然后,您可以使用C#的许多序列化方法来持久存储它(加载/保存),但是您认为合适。

答案 5 :(得分:0)

如何将您的冒险作为一个大型文本文件声音编写?然后让你的应用程序解析这个文件,在类中构建冒险并从那里运行?

这意味着您可以使用简单的文本编辑器编辑冒险。我可以想象,当可以从单一来源做出多个决策时,可能会变得难以想象链接。然而,在没有专业前端的数据库中,这也很棘手。

更新:

或者你考虑过XML,例如......

<area id="DarkRoom1">
  <description>Dark Room</description>
  <item>Bucket</item>
  <item>Spade</item>
</area>

然后使用它来填充内存中的类。

答案 6 :(得分:0)

您可以将数据存储在文件系统(zip文件或文件夹)中。

每个选项都可以存储为文件夹,而所有描述,修饰符和其他数据都可以存储为文本文件(xml?)。当用户做出决定时,您将转到相应的文件夹并按照图表进行操作。

示例:

你想:

  • 打开门(门)
  • 离开(离开)

如果用户选择打开门,则转到文件夹门,并从此文件夹中的数据文件中读取数据。

优点:

  • 简单
  • 不需要数据库
  • 轻松添加新冒险

缺点:

  • 回滚决定的问题(回到开始或在情节中的某个点)

答案 7 :(得分:0)

就个人而言,在这种情况下,我会避免使用数据库,并采用基于文本的文件格式(可能是两个不同的文件,一个用于初始状态(如地形等),永远不会被修改,一个用于在游戏过程中要修改的状态(破碎的窗口等);或者将每个区域分成一对静态/动态数据。

有几个原因:

  • 文本文件是人类可读的;因此,您可以在没有专用编辑器的情况下创建内容,而使用数据库方法,您必须通过查询输入数据,或者编写级别编辑器
  • 假设单人游戏场景,并发性不是问题
  • Savegames是将修改后的状态文件复制到savegame文件夹或将它们打包成单个文件的问题
  • 您可以轻松嵌入脚本
  • 您正在处理的数据结构可能非常简单,数据完整性不是一个严重的问题
相关问题