ID:154571
 
The next DDT game will save multiple turns per game on the server.

I am debating whether to put all these turns into one huge savefile or break them up into the filesystem. If I used the filesystem, I'd store them in directories based on the creating player's name, like:

/d/e/deadron/[game_id]/current_turn_state.sav
/d/e/deadron/[game_id]/ player_starting_turn_states/[player_number]/turn.sav

Etc.

I know savefiles are supposed to be robust for large sizes, but if the game were to get successful at all, there could be thousands of files and I worry...any advice from Dantom?
On 4/24/01 10:35 pm Deadron wrote:

I know savefiles are supposed to be robust for large sizes, but if the game were to get successful at all, there could be thousands of files and I worry...any advice from Dantom?

I have asked a question quite sometime ago: Should there be some form of sql support for byond?
In response to sunzoner
On 4/25/01 5:31 am sunzoner wrote:
On 4/24/01 10:35 pm Deadron wrote:

I know savefiles are supposed to be robust for large sizes, but if the game were to get successful at all, there could be thousands of files and I worry...any advice from Dantom?

I have asked a question quite sometime ago: Should there be some form of sql support for byond?

Yes that would be great, and I have a request in for that (supporting Perl bindings would probably be another way to do that).

But in the meantime, since that isn't happening for this version of BYOND...
On 4/24/01 10:35 pm Deadron wrote:

I know savefiles are supposed to be robust for large sizes, but if the game were to get successful at all, there could be thousands of files and I worry...any advice from Dantom?

I recommend using a single savefile. Since the server is single-threaded there's never a necessity to access different entries simultaneously, and the internal file seeking should be roughly as efficient as the equivalent setup when you let the OS do the work by having multiple files. A single savefile is more portable and easier to use, IMHO.

Just back it up as it starts to get big! And if there turn out to be problems with this setup, you can always have a simple routine convert one file into multiple ones.

We have been discussing the Perl, SQL, and generic third-party runtime library access. I do think these things would add a lot of functionality to the language. We just need to pick and choose our battles right now!
In response to Tom
On 4/25/01 9:50 am Tom wrote:
I recommend using a single savefile.

Here's some additional musing about this in favor of filesystem...

It's easier to implement it as separate files in the filesystem. I don't have to write any additional code to take the data out of an imported/exported savefile to put it into a larger savefile...in fact I realized that it would be quite convenient to just have clients request files from the server without the server having to know anything else about them. Now if I can save a safefile inside a savefile, this might change the picture. Can I?

It's easier to admin things when they aren't in one big file, and if the big file is corrupted, it's more destructive than a single small file getting corrupted.

However if I can save a savefile inside a savefile, I'm much more likely to consider it...