DESIGN: Random ideas for improving SLIC/Modding

[MrBaggins]

Allowing "overloading" of various game data... city improvements, terrain improvements, units, wonders, pop, advances by government

Concept:

Allow for "overloaded" data files, for city improvements, units, terrain improvements, wonders and so on.

You'd optionally specify altered data for that specific whatever under that specific government.

You'd implement this by having some linked list or other data structure, with the extended data in. They get referenced by the original structure, and if there is appropriate data (for the "owners" government,) then its passed back.

Issue: We'd have to ensure that all data was referenced as it related to an owner (like a specific unit or TI,) and then subsequently to the DB, and not directly to a default db value.

Benefit: A lot of modding flexibility. It would be very simple to make costs different for a specific group of units and buildings, say, under a particular government type. You could do tech tree divergence... and a whole bunch of tricks, without SLIC. Would allow for more personality in governments in general.

[Martin Gühmann]

Alternativly you cold put into the government.txt modiferers, like a Building modifer and you could also use lists like the terrain effect list for the tile improvements, this way there would be less textfiles do deal with.

-Martin

[MrBaggins]

Well.. I think that the better solution is to put them in the original file. E.G. for a City improvements... you'd still have just one buildings.txt

If you wished to change say, the effect of the Courthouse in a city under Monarchy (due to a brutal, though effective regime of punishment, for terms of this discussion) you might do the following:

This is the original, and would be kept in the file.

IMPROVE_COURTHOUSE {
   DefaultIcon ICON_IMPROVE_COURTHOUSE
   Description DESCRIPTION_IMPROVE_COURTHOUSE
   EnableAdvance ADVANCE_JURISPRUDENCE
   ProductionCost 330
   Upkeep 1
   LowerCrime -0.1
}

This would be an addition to the file:

IMPROVE_COURTHOUSE::GOVERNMENT_MONARCHY {
   DefaultIcon ICON_IMPROVE_COURTHOUSE
   Description DESCRIPTION_IMPROVE_COURTHOUSE
   EnableAdvance ADVANCE_JURISPRUDENCE
   ProductionCost 300
   Upkeep 1
   LowerCrime -0.3
   HappyInc -1 
}

Which would be parsed as an 'extention' to the building record, and referenced, where appropriate.

Notice I've added a happiness penalty, increased the crime reduction and lowered the production cost.

I'm suggesting that you'd only include these where you wished to change the behavior for a specific government. Nothing is mandatory.

[Martin Gühmann]

I rather prefer such a format:

IMPROVE_COURTHOUSE {
   DefaultIcon ICON_IMPROVE_COURTHOUSE
   Description DESCRIPTION_IMPROVE_COURTHOUSE
   EnableAdvance ADVANCE_JURISPRUDENCE
   ProductionCost 330
   Upkeep 1
   LowerCrime -0.1
   GovernmentEffects {
      Government GOVERNMENT_MONARCHY
      Government GOVERNMENT_COMMUNISM
      Government GOVERNMENT_CORPORATE_REPUBLIC

      ProductionCost 430
      Upkeep 3
      LowerCrime -0.3

   }
}

This way you just have one entry per building and you can modify here very easily. For instace if you don't use one government listed in the government effect struct then the default block outside the struct is used, otherwise the values inside the struct are used, this way it would also be backwards compartible (you don't need to change anything if you want to add it to the *.exe in the text files) and it would alos be very easy to implent, as it is just a change in the database generation script file. Your sollution would be adding more buildings and we are already short of slots for buildings.

-Martin

[MrBaggins]

Yep... we're limited to 64 buildings.... but thats because of the flag used to store them in the city record. Subtypes wouldn't be limited this way...

We're limited, because a uint64 is used to store the flags. We should develop a small extensible flag class, that uses a bit array, perhaps.

This would allow us to extend building.txt as we wished, and just serialize the class instead of the uint64.

As for my example, it will essentially use the exact same parser behavior, with a modification to notice and redirect the data for the different governments.

Also, I think we should include all the record of the data in the GovernmentEffect... thus you can remove effects (by their absence) and change, say the icon, description or advance, in the case of a building.

[Immortal Wombat]

I like the idea. From a modding point of view, I think Martin's method is easier, and cetainly more similar to the current way the textfiles handle things.

[MrBaggins]

I just took a closer look at this. (the newdb stuff.) As I've recalled, there were no structs within structs which would be the issue with doing it the second way. Thats not to say it won't work that way, and indeed, it would be preferable to do so. I'll do a test to check.

I also noticed the ready prepared bitarray class, that we should use instead of a uint64, for buildings and wonders...

[MrBaggins]

Update. What Martin has suggested isn't allowed by the parser at present... There seems to be a problem with having some array type dataclasses within a structure, in certain circumstances.

I'm working on the problem.

[J Bytheway]

If possible a syntax more like Martin's is better because it removes redundancy - e.g. in the first syntax you would have to alter two entries if you changed the name of the icon, but in the latter you need only change a single entry.

[MrBaggins]

Only for required elements.

If you have a non-required element, you wouldn't know if its absence means it should be removed or unchanged.

Even so... its becoming increasingly clear from the stuff I've been looking at that its exponentially more difficult to alter the db parser in that manner.

The strategy that I think we should persue is...

* Generate a link list datatyperecord class member variable, and an array to hold the list of governments in the class def for the datatype
* Use an alternate custom token in the generated parser code, that checks for the token (I.E. a colon) specified for the modified specification, or the opening brace, rather than just the opening brace
* Use a custom token seperator (I.E. a comma) to seperate a list of the governments that the modified specification applies to.
* In parsing, follow the linked list, until the pointer to the governmentmodifier member object is null, then create a new object, populate the list of governments and parse the actual data into it.
* Overload the base accessor function to include an int (?) in addition to the regular arguments, for the index of the government that you wish to access data for.
* That accessor would find the data, then traverse the linked list looking for a matching government, and if it found it, replace the data as appropriate.

[Martin Gühmann]

Well alternativly you could include in the government.txt for each government a list of buildings that are replaced by other buildings, we could store it in two lists. Provided we have the more then 64 Buildings support.

-Martin