Saving and restoring games

[LDiCesare]

I don't really understand why several files is a bad thing. Given the current code, where each file is read in a separate thread, I understand it can cause problems, but it's just an ordering problem. I'd much rather have a #include-like directive than have a single file, because I like to edit things by hand. Now having bigger files won't prevent me from doing this, and I can always start with the scenario editor if needs be. I also don't get why having several files from the start hurts. You can always merge them together into a single 'scenario' file? But hey, now that I've ranted a bit, I must confess that Gary has the very bad habit of being right when it comes to coding, so I think that's probably the thing to do.
Now the next question is: Do we wait for this to be completed to get a demo 8 out or not?

[Gary Thomas]

The problem is that we are making the game play the part of a scenario editor. The present program reads in a great deal of scattered information and discards most of it. Under that system, when I write the save file it will be quite different from the scenario file. If someone starts a game and immediately saves it, for a great many reasons, mostly concerned with debugging and code safety, I would like the saved file to be, as nearly as possible, exactly like the scenario file.

What I am really aiming for is a system that is simple.

The argument that the game should be structured to make it easy to hand edit scenario files is not a good one. You are, I think, viewing scenario files as a kind of programming code. For the real purposes of a scenario file, an include statement is very wrong, and leads, inevitably, to dependencies. I believe that I have expressed my opinion of the deeply evil nature of dependencies in the past, though, it seems, not sufficiently eloquently.

I am not interested in making it easier for people who want to hand edit things, at a cost of making it more difficult for the people who play the game.

When I devise a brilliant new scenario, I want to be able to send someone a scenario file and have it run, without having to also send a military file, a social file, a religion file, a technology file, a riots file, a weather file, and whatever else. Once the scenario is set, it does not need any of these things. They should be incorporated when the scenario itself is built. For practical reasons, and only in the short run, I will accept a separate map file. However, because the map file and the scenario file are indissolubly connected, I would prefer that they be incorporated in a single file.

The fact that I went a lot of trouble to make the data files human readable and modifiable, in the form of XML files, should not be considered as meaning that that is the way scenarios should be designed and built. It is, essentially, a debugging tool only.

Because, in recent years, a scenario editor, in most strategy games, has become almost as important as the game itself, I think that such an editor should be provided (and I have started doing it). And it should be to the same standard as the game itself. People who want to hand edit the result can, of course do so, but using cut and paste. It has fewer dependencies.

And I think, with some regret, that the next version should be issued without waiting for the save/restore.

Cheers

[LDiCesare]

Don't worry, Gary, I know the evil of dependencies. But I also know the evil of copy paste (when you change a bit of code and find that is has been copied in ten files by different people who could have reused your service...).
How will you go for the scenario editor? How will you say when you create a new scenario that you reuse the tech tree, etc.? Will you keep resource files to build the scenario file from? I mean resource files are just used to speed up the scneario editor to lead to a single scenario file, but never used by the game itself.

[Gary Thomas]

In one sense the scenario editor will do what the game itself does. The fileinput class reads a considerable number of files and, essentially, combines them into one file. What I propose to do (amongst other things!) is to move that functionality to the scenario editor.

I would hope that it will be easier to make minor changes in the scenario editor, rather than by cutting and pasting.

As to general functionality, the scenario editor will work on two levels. It will enable editing of the standard data - changing global values, or editing what I call the reference files, that is, the files which contain lists of unit archetypes, civilizations and so forth.

Those reference files will be read in every time the scenario editor is run.

The person using the editor will have the option when designing a scenario of selecting any of these components from menus, and modifiying them if desired, or of creating new objects specific to that scenario.

Because the save/restore and scenario editor will be closely related, it will also be possible to edit a saved game, as though it were a scenario. This adds the feature that I have always wanted, of changing the player civilization during the game.

Cheers

[Gary Thomas]

There are a couple of matters I overlooked in my earlier post.

Because much of my interest is in the simulation aspect of the game, rather than the competitive aspect, I like the idea of running a game and switching among the civilizations to get a better grasp of their problems and challenges at various points in the game. That possibility really interests me.

The other thing is that the non-map parts of the scenario editor are very much easier to code than the map part. I will address them first. The first version of the editor will not have map editing included.

Cheers