DESIGN: BuildClass

[MrBaggins]

While I was working on the database code, I was reading a question regarding Park Rangers, and their enabling. The question was basically asking if they were hard coded, which they essentially are. People mentioned that you could use SLIC to solve it.

I brainstormed an idea, which went further... related to what I was working on... the data structure.

I was thinking of incorporating a universal Build Class, that could be assigned to anything and everything you can build, that can be enabled by things other than just advances (being prequisites)... like wonders enabling units, for example.

To make it flexible, you'd probably want a reasonable range of values to work with... say 1000. Anything that can be produced, build or researched would have a build class. If no Build Class was assigned to something, it would default to 0. By default every player and city could use build class 0, so the system would be completely optional in the data files.

Players and each city would have build class lists (of 1000 items)... much like flags.

If an item had a global enabling property, like, say a wonder enabling units, then it would turn the particular flag on for that player, then the particular items enabled by that build class would be possible to build.

There is another enabling class... local, which works for the city (and only that city) where the particular produced item was made. For example, if you built a foundry city improvement in your capital, then that may enable a class, which allows for cannons to be built in that capital city.

The properties would be available for SLIC to inspect, and alter, to allow for maximum flexibility, but for the most part, changes should be possible just through a few text file properties.

Essentially, the properties I'd suggest would be...

BuildClass int
optionally for Advances, City Improvements, Feats, Governments, Population, Goods/Resources, Terrain Improvements, Units and Wonders

For the Global items... that is... Advances, Civilization, Feats, Governments, Population, Units and Wonders, you could have:

EnableBuildClassGlobal int
EnableBuildClassGlobalMin int (min of the range enabled)
EnableBuildClassGlobalMax int (max of the range enabled)
DisableBuildClassGlobal int
DisableBuildClassGlobalMin int (min of the range enabled)
DisableBuildClassGlobalMax int (max of the range enabled)

You'd have Local versions (subtituting Local for the word Global in the above identifiers) for the local properties
City Improvements, Goods/Resources, Terrain Improvements and Wonders

That's nice... but what will this system allow us to do?

Some (although certainly not all) of the applications would be:

• A flexible boolean (and/or/not) tech tree
• Implementing Strategic Goods (or being a big help)
• Wonder/City Improvement units/tile improvements (or pretty much anything you can imagine)
• Civilization traits

As I've mentioned... nothing is mandatory, and it won't impact current text files, just allow them to be extended.

[Tamerlin]

The idea sounds good and I agree with you but I don't like the "Strategical resources" from Civ3, they are unbalancing the game and are introducing more micro-management when it is not needed in a game of this scale.

Once again, I would like all these changes to be optional so the player can chose whether he will use this rule or leave it for another.

[MrBaggins]

Good idea. A way we could deal with this, would be to have a couple (or perhaps a few) ranges of build classes (like 800-899, 900-999, say,) specified, where you have the option of enabling or disabling them. You'd have identifiers (in the str.txt files,) so that we, or the Mod makers could designate whatever they choose to be optional...

like.. say.. instead of having strategic resources, they might want to make religion (buildings/units/whatever) optional... and thus have an option to turn it on or off.

If this works well, then we could extend it a bit (more build classes, a build class database, more optional ranges) to allow for optional tech ranges/end games... so for instance the game could end at 2050 rather than 3000... and that would be defined by the build classes... you'd simply disable the unnecessary techs/whatever.

[tyrantpimp]

Im all for whatever makes things more flexible and i agree any new gameplay modifications should be optional so as not to alienate those that would like a more "pure" CTP2

While allthough i may vote banana my heart is with expanding the games options to the limit

[J Bytheway]

I can see the advantage of using numbers for the classes, but it woun't help readability... Wouldn't it be better to use textual identifiers - perhaps even make a whole new DB for these. That would also make it easier to categorise them (if you allocate the 700s to a certain type of object you can be sure that some modder sometime will want to have 101 of them...).

[MrBaggins]

If this works well, then we could extend it a bit (more build classes, a build class database, more optional ranges)

Essentially, yes. My intent is to get them working as numbers first, however.

[MrBaggins]

Work progresses, and...

I'm leaning towards not using TileImprovements to enable build classes.

Their tenuous connection to the city, ambiguous design considerations (guaranteed multiple TI's per city, rather than one of each build/wonder) and extra storage requirements (basically doubled,) make them seemingly more trouble than value.

Of course, since SLIC would be able to handle TI's enabling/disabling local and/or global build classes, if required.