views:

191

answers:

7

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
+1  A: 

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

spender
Is there a way for me to prevent anyone from actually looking at the database? Probably a stupid question.
Liggi
That's a different question altogether... I'd say ultimately, no. If it's on the client's machine, no matter what you do to encode/encrypt/protect, your app will need to access the data, ergo so can a determined user. It would probably be trickier to open up than an XML serialization though.
spender
Alright, no worries. I'm going to give your option a try.
Liggi
If the data ends up on their machine, it's literally impossible to stop them reading it - because if their computer can read it so they can they :)
Rushyo
A: 

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.

Rushyo
[Removed - as it was a reply to another comment that was removed]
Rushyo
but the question was also "Where to store it" encapsulating the structure in _classes_ doesn't say anything about where the data that will populate the _objects_ are store before the _objects_ are instantiated.
Rune FS
Well, I suppose that's entirely subjective - not really a valid question. A flat text file? It doesn't really matter at all. It won't be a bottleneck, there's no right answer. Just store it any way you see fit. Personally I tend to invent a new format for every game I develop with appropriate semantics for the problem. Once they're created once, serialisation and deserialisation covers retrieving it in future.
Rushyo
@Rune Serialization implies that you store your instances - wether that's a Xml text file or a binary format file is just a matter of choice as Rushyo pointed out.
Filburt
@Filburt yes a choice OP is asking for advice about
Rune FS
@Rune FS If you were indeed to interpret it that way then perhaps it would be better suited to a forum - rather than a question on SO. Not that it was meant in that way, since the chosen answer was essentially the same as mine.
Rushyo
@rushye except of cause that the accepted answer does exactly what I suggested you do. Explains how to serialize, which format and storage type to use and explains why.
Rune FS
It still doesn't matter. Store it in your own custom file type using your own custom document format on your own custom file system if you like, it makes no practical difference. There's no discernable difference between the methods in this context. The structure only matters inside the program. That's the whole point of serialisation!
Rushyo
A: 

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.

El Ronnoco
A: 

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)
Simon
A: 

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
tdammers
+5  A: 

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.

Kirk Broadhurst
That's a good plan actually, binary serialization. I don't know why I didn't think of that.
Liggi
Can't help but feel a little aggrieved having suggested it before this... ah well.
Rushyo
Sorry Rushyo, if you suggested it first. I didn't really understand what you were saying in your answer.
Liggi
@Rushyo To be fair, your response to the question 'how to store the data' was "Well, I suppose that's entirely subjective - not really a valid question.".
Kirk Broadhurst
@Kirk Broadhurst No, my response to the alternative interpretation of the question, was the above. The actual answer I have in the answer bit was nothing to do with that. Please consider the context before you quote me.
Rushyo
+6  A: 

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.

Eric Lippert
Depends why you're writing it. If you're looking to learn about how to build a text adventure to teach yourself, then it's not really relevant. Still, it is a lovely tool.
Rushyo