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

Question

I'm developing a "Zork" style text adventure in C#, and it's going to have a fairly large number of different areas with descriptions and environmental modifiers. I don't want to have a database, ideally, unless it really is the best way of doing it.

I need advice on the best way to store/load this data.

It will include:

• Area description
• Environmental modifiers (windows open/broken, door closed)
• Items present by default

Answer 1

I would solve your problem by abandoning C# and writing your program in Inform7 . Inform7 is just about the most awesome programming language I have ever seen and it is specifically designed to solve your problem.

The awesome thing about Inform7 is that you write your text adventure in a language that resembles text adventures. For example, here's a fragment of one of the sample adventures' source code:

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.

This adds an object to the game - the object is a door, it is called "the iron-barred gate". A door is understood to be between two rooms, in this case, the drawbridge and the entrance hall. If the player tries to "enter the drawbridge" then the game logic will know that this is the same as "go north", and then the door logic will determine whether the door is closed or not. And so on. It makes writing text adventures extremely easy.

Is there some particular reason why you want to use C# instead of a domain-specific language like Inform7? If your goal is to learn how to write C# code or how to build a parser or whatever, then by all means do it yourself. If your goal is to write a text adventure, then I'd use a language designed for that.

Answer 2

Serialize all the data to file. It will ensure the smallest footprint when the user installs the game, without any real disadvantage. A database is great when you have a lot of data, but you are talking about a text adventure in which you will load the entire game contents into memory. A simple file will work for this very nicely.

Note, I'm not talking about xml but binary serialization. Any kind of text serialization will allow users to peek at your data, and either cheat or hack up the game. And you can just as easily swap in/out the serialized data file whether it's text or binary. Remember, your whole 'text' is likely to be just a few hundred kilobytes at most.

Answer 3

There are many interactive fiction engines already. I would take a look at their data formats, that way you can re-use existing content and tools for editing the content.

The most popular engines currently are Glulx http://eblong.com/zarf/glulx/ and Z-Machine http://en.wikipedia.org/wiki/Z-machine

Here is a technical reference for the Glulx format: http://eblong.com/zarf/glulx/technical.txt

Answer 4

I know you didn't want a DB, but have you looked at SQL Server Compact Edition ? It might just do what you want.

Answer 5

I'd argue C# offers you precisely the right tools for this. Just encapsulate your structures into classes. Our first OOP project at university was exactly this problem! It is the perfect case study for OOP.

You can then use C#'s many serialization methods to store it persistently (load/save) however you see fit.

Answer 6

How would 'scripting' your adventure as one large text file sound? Then have your application parse this file, build the adventure in classes and run from there?

This would mean you could edit the adventure using a simple text editor. I would imagine that when multiple decisions can be made from a single source it may become tricky visualising the links. However this would also be tricky in a DB without some specialist front-end.

UPDATE:

Or have you considered XML eg...

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

Then use this to populate your classes in memory.

Answer 7

You could store the data in a file system (a zip file or a folder).

Each choice could be stored as a folder, while all descriptions, modifiers and other data could be stored as a text file (xml?). When user makes a decision you go to the appropriate folder and follow the plot.

Example:

Do you want to:

• open the door (door)
• leave (leave)

If user choses to open the door you go the folder door and reads data from data file in this folder.

Pros:

• simple
• do not require database
• easy to add new adventures

Cons:

• problem with rollback decision (getting back to start or to certain point in plot)

Answer 8

Personally, I'd avoid a database in this case, and go with a text-based file format (probably two distinct files, one for the initial state (like terrain and such), which never gets modified, and one for state that is to be modified during the course of the game (the broken windows etc.); or split the entire thing up into one pair of static/dynamic data per area.

A few reasons:

• A text file is human-readable; hence, you can create content without a dedicated editor, while with a database approach, you'd either have to enter data through queries, or code a level editor
• Assuming a single-player scenario, concurrency is not an issue
• Savegames are a matter of copying the modified-state files into a savegame folder, or packing them into a single file
• You can easily embed scripts
• The data structures you're dealing with are probably simple enough for data integrity not to be a serious issue