 |
|  |
 |
|
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.
|
|
|  |
 |
|
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.
|
|
|  |
 |
|
MrBaggins
|
|
quote: 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.
|
|
|  |
All times are GMT. The time now is 05:33. Apolyton Time is 00:33. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|