On the subject of scenarios

[Gary Thomas]

That, Laurent, is exactly what I have in mind. Because of the way the save/restore system works, I see it as a way of having detailed maps of areas of interest, without having to look at a huge map, most of whose areas are not used at a particular time.

Cheers

[alms66]

From the Demo 8 near to completion? thread, moved per Laurent's suggestion there.

...

-(In conjunction with following comment)
Need to remove the need for the scenario index file and simply have the game recognize each folder in the scenario directory as a runnable scenario. Also have each scenario have it's own resource folder (mimicking the standard's structure - see next comment), even if it's empty. So you would have the following for scenario file locations:

...Clash\Scenarios\Scenario1Folder\Scenario1.xml
...Clash\Scenarios\Scenario2Folder\Scenario2.xml
...Clash\Scenarios\Scenario3Folder\Scenario3.xml
...etc.
And the following for resources locations:
...Clash\Scenarios\Scenario1Folder\Resources
...Clash\Scenarios\Scenario2Folder\Resources
...Clash\Scenarios\Scenario3Folder\Resources
...etc.

I see this as the best way to handle this at the moment, though if someone has a better idea, speak up. This allows all maps, mods and scenarios (including the standard game) to be treated equally. If any given scenario doesn't define some element of the scenario (religions, ethnic groups, techs, map, artwork, sounds, etc.), it is simply loaded from the standard game.



-(In conjunction with previous comment)
Since the standard Clash game will simply be a scenario of many possible scenarios, I believe we need to reorganize the Clash directory somewhat.

A simple Clash Directory Proposal:
...Clash\Docs (lists all documentation, readme's and such)
...Clash\Game (program code - won't go into further detail on this one)
...Clash\Help (in game help system - i.e. Civlopedia - no details since it doesn't exist)
...Clash\Saves (save games - once coded, won't go into detail here either)
...Clash\Scenarios (a folder for all scenarios, including the standard one-see next for option)
...Clash\StandardGame (standard scenario, moved up from scenario folder as an option if people prefer to see it here rather than lumped with other scenarios)

Leaving us with a single folder (per scenario) in the actual Scenario folder of the following:
...ScenarioName\ScenarioName.xml (scenario file)
...ScenarioName\Resources (resource folder)

And the following in the Resources Folder:
...Resources\Art
...Resources\Sounds
...Resources\XMLorText (if any extras are even needed)

The following for the Art Folder:
...Art\Terrain
...Art\Misc.
...Art\Units
...Art\Cities
...Art\Interface
...Art\AnyOthersImMissing

The sound folder would have the same basic internal structure as the art folder, so I won't list it. And the xml/text folder would have any additional xml or text files needed, though I don't think there currently are any.

Also, the code to recognize the folder in the scenario directory as a scenario could be rehashed and reused to recognize a folder under Terrain as a terrain type, ditto for units, cities, etc.

[alms66]

Laurent replied:

About the scenarios folders, I guess Gary's editor will make the point moot. There will be resource files that the editor will compile into a single scenario file. Better discussed in the scenarios thread.

To my understanding, this scenario file will only be the xml resourses compiled into a single zip file (essentially), not the artwork and sounds. I haven't talked to Gary about his plans/current musings on it though. If I'm correct here, then that makes loading the standard xml resourses left undefined in a scenario just that much easier to code. And even if the artwork and sounds are zipped with everything else, the directory structure could still work as intended in my post, it will just be zipped.

[Gary Thomas]

Need to remove the need for the scenario index file and simply have the game recognize each folder in the scenario directory as a runnable scenario.

That is the way it used to work. For good reasons that, regrettably, I cannot at this moment remember, I changed it. I will try and remember.

And the following for resources locations:
...Clash\Scenarios\Scenario1Folder\Resources
...Clash\Scenarios\Scenario2Folder\Resources
...Clash\Scenarios\Scenario3Folder\Resources
...etc.

The problem with this is that the resources are essentially the same for all the scenarios.

...Clash\StandardGame (standard scenario, moved up from scenario folder as an option if people prefer to see it here rather than lumped with other scenarios)

What is the point of this? What makes you think there will be only one standard game?

The following for the Art Folder:
...Art\Terrain
...Art\Misc.
...Art\Units
...Art\Cities
...Art\Interface
...Art\AnyOthersImMissing

What is the advantage of doing this? It merely seems to add complications.

Cheers

[alms66]

Originally posted by Gary Thomas
That is the way it used to work. For good reasons that, regrettably, I cannot at this moment remember, I changed it. I will try and remember.

I'm interested to know exactly what that reason was.

Originally posted by Gary Thomas
The problem with this is that the resources are essentially the same for all the scenarios.

Exactly the reason for the standard resource directory, which I assumed would fall under a standard scenario. If there truly is no standard scenario, then we can just have a plain resource directory instead of loading the resources from the standard scenario's resource directory. My main point here is that you don't want to have to duplicate any files on the hard drive, because they are mostly the same from scenario to scenario. The resource file directories for each individual scenario would, then, only contain files that DIFFER (f.e., if I changed the tech tree around for my scenario) from those in the standard resource directory or DO NOT EXIST (f.e., the image files for a new unit I added to my scenario) in the standard folder.

Originally posted by Gary Thomas
What is the point of this? What makes you think there will be only one standard game?

I assumed there would be a "standard" game, as has always been the case for every game of this type previously, even if the "standard" was nothing but a scenario in and of itself.

See point above, this should be replaced with:
...Clash\StandardResources
All resources will be loaded from this directory, unless there is an over-riding file in the ....Scenario\Resources directory.

Originally posted by Gary Thomas
What is the advantage of doing this? It merely seems to add complications.

Mostly, it's an organizational thing, which you must not underestimate considering we may end up with hundreds of unit images, terrains, etc. But also, from my previous post:

Originally posted by alms66
Also, the code to recognize the folder in the scenario directory as a scenario could be rehashed and reused to recognize a folder under Terrain as a terrain type, ditto for units, cities, etc.

The point of this, was to reduce redundant information. Though, thinking back on it now, it's useless for resources due to the fact that (if a standard resource folder is used) a unit, for example, may exist in the standard resource folder, but not in a particular scenario so the information is actually not redundant.

[Gary Thomas]

I'm interested to know exactly what that reason was.

I am pretty sure that it was to do with testing, so half-baked (and half-written) scenarios would not automatically appear in the list until, as it were, officially added. This still seems to be an adequate reason, unless a corresponding reason is advanced for the other way of doing it. The claim that it is simpler (and it is) isn't enough.

Cheers

[LDiCesare]

It may have to do with testing, but also with the grouping together of certain scenarios, like the random scenarios (random maps actually).

[alms66]

Originally posted by Martin the Dane
Garry, is the document you are refering to the dataformat.html, included in the testbed. It does have some description on the variouse tags used in the scenarioes.

I'd just like to add that in my own attempt at creating a scenario, this document has proved useful, though it is severely out of date. Is there an updated doc or at least a list of updates made floating around?

[Mark_Everson]

I just sent you files that should allow you to build your own relatively current testbed. It has the most up to date version of dataformat (although it may still be not current with the code).

[LDiCesare]

Mark's document should be the most uptodate available. I forgot to add it in the jar I sent you, but I didn't touch it so it should still be valid. alms, if you didn't get my mail 'since that happened twice), ask Mark for a new testbed.