 |
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
Sorry, Gary. Here are a few answers for you:
On demographics: using fix shares is more than enough for the moment.
On initial values: the document I made defines values for regimes and for social classes. As for religions and EG's cultural values, random values will do for now. But your "scenario-builder" sounds pretty useful!
On ruler power: there's nothing simult. in the model, but the order of "procedures" I put in the doc isn't the best seq. order... For your particular question the answer is "compute real power distribution first, then nominal (for the next turn)". In general, the order of procedures should be:
*X. Handling Religions Grand Scheme
*I. Computing discrimination factors for an EG.
*V. Creating govt's Code of Law
XIX. Determining Govt's Official Religion.
XI. Determining Knowledge and Development levels for a Regime.
X. Determining the demographic share for a social class.
XII. Determining the Govt-Regime Distance and the Ruler-Regime Distance for a Regime.
XIII. Determining Social Class' Historical PCI
XIV. Updating Empire's Stability
XV. Determining Optimum Institutional Infrastructure (OII) needed in a province.
XVI. Determining the Number of Administrators Needed (NAN) in a province.
XVII. Determining Administration Effectiveness Level (AEL) for a province.
XVIII. Determining the Maximum Number of Feudal Units (MNFU) in a province.
I. Computing Real Power Distribution
II. Creating the Conservative Govt Profile
III. Computing the 5 Political Powers shares for a social class.
IV. Computing preferences for DNPs for a social class.
V. Creating the Support Regimes Shares for a social class.
VI. Creating the 5 Political Block Profiles.
VII. Creating the Society's Govt Profile.
VIII. Creating the Future Govt Profile.
*II. Computing Govt Nationality's Force for a province.
*III. Computing Tendency Values for an EG
*IV. Changing current EG's attributes (cultural evolution)
*VI. Computing Faith Points for a religion in a province.
*VII. Changing EG's populations in a province via religion (in-the-province religion spreading)
*VIII. Updating the list of present religions in a province because of trade (province-to-province religion spreading).
*IX. Changing EG's populations in a province via nationality (nationality shift)
IX. Creating the Current Govt Profile.
Note1: procedures with asterisk are from Social Model. Without asterisk is from Govt Model.
Note2: The last procedure listed should be, ideally, made at the very end of the game turn because that's where the next turn's current govt profile is created.
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
I am (very) slowly assembling all the parts of the Social/Government/Riots model.
So far I have (in addition to a great many pages copied from the forum discussions):
1. The Social model, version 3, dated October 2001 (though the last update listed for it is 6/22/00, which I assume means 2000/6/22). This came from the web site. It is a general discussion of the model, without equations.
2. The Government model, version 3.2, dated October 2001. This also came from the web site, and is likewise a general discussion of the model, without equations.
3. Government Model version 3.1, Technical Document (equations), dated December 2001 (version 3.1 is later than version 3.2?). This has the equations for the government model.
4. The Riots model, version 2, dated October 2001 (also with the 2000/6/22 update value). A general discussion, without equations.
What I am lacking is a clear notion of the current version numbers, and which is the latest version, and, particularly, the equations for the Social and Riots models.
Social coding (which means, in this case, xml coding) is on hold until I find out where to get the missing equations.
Cheers
Last edited by Gary Thomas on 10-03-2002 at 08:10
|
|
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
Hi Gary.
Current (latest) versions for technical and descriptive documents are:
Social: 3.0
Govt: 3.1
Riots: 2.0
There has never been a version 3.2 of the govt model. One of the documents had that number in the title, but that was a typo. A similar problem may have ocurred with riots model. Probably somewhere there's a version 3 of that model, but latest really is version 2. Sorry for the mess.
Anyway, to put away any doubt, I just sent you via email (to thomasg@acc.co.nz) all documents available for latest versions. That is:
Govt Model -description (version 3.1)
Govt Model -technical (version 3.1)
Social Model -description (version 3)
Social Model -technical (version 3)
Riots Model -description (version 2)
Coding the Society Model (version 2)
(a technical version of the Riots Model isn't available yet)
Note: a couple of errors in equations of govt model are described in my post dated 12-02-2002 02:45 in this thread. Take a look at that. (second page of the thread)
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
Thanks. Mark sent me the mssing equations one, so I have a full set now.
I have a question about nationalities. It is quite unclear whether "nationality" is synonymous with "civilization".
Is it possible for two civilizations to have the same nationality? It is clear that an ethnic group can have a nationality which is not represented by a civilization - if the ethnic group becomes independent, a new civilizations is formed, according to the model. Presumably a ruler will need to be randomly generated, and the various government parameters somehow generated from the characteristics of the ethnic group.
Currently the nationality is merely recorded as a string, that is, the name of the nationality. This is no good, since I can envisage situations in which a civilization's name is changed (from Wessex to England, perhaps?). This would leave the nationality names out of whack.
If I understand the intent of nationality, then I feel the best way to deal with it is replace nationality with civilization, creating any, in the scenario xml, which are required. This enables all the data to be set at the time the scenario is input.
Some civilizations which exist purely to provide a home for a possible nationality will have the government structure in place, but control no provinces.
Cheers
|
|
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
Gary, all procedures I listed ("Handling Religions Grand Shceme", etc) refer to the technical docs of the govt and social models. It's the descriptive version of the social model that goes up to VII, so there's your confusion.
Note numbering of procedures and numbering of different model topics do [b]not[/n] match. In other words, numbering in descriptive doc has nothing to do with numbering in technical doc.
About nationalities: Nationality represents the nation/tribe the EG feels it belongs to. (Mark proposed a better name was NationalAffinity). That nation or tribe may or may not exist as a civ/empire. FE, after Hernan Cortes' conquest of aztec empire, there'd be no aztec "civ", but there'd be EG's with aztec nationality, i.e. people who still called themselves aztecs.
It's important to avoid "connecting" an EG with a civ. Things like a "pointer" from the EG to a civ should not exist. You only need to know in what civ the EG lives. The model was built with that in mind. Only in very specific, infrequent situations (actually described in the social model descriptive doc, IIRC) you need to see if for a given EG there's somewhere in the world a civ with matching nationality.
There shouldn't be two civs (govts) with the same nationality. But that's something that should be controlled when a new civ is created and when the player wants to change the civ's nationality. In general, if the civ's nationality changes, there's no need to change also EG's nationality.
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
The equation for religious discrimination (Social Equations I) is:
RD * (1 - (1 - sign(FVE - FVG)) * 0.5)
which I interpret to mean:
if (fve < fvg) return 0
if (fve = fvg) return rd / 2
if (fve > fvg) return rd
Is this correct? I cannot see it providing useful results.
I don't see that family values is being treated correctly. If the state religion and the ethnic group's religion are the same, zero discrimination is returned.
Family values are only compared for different religions, so I cannot see that the expressed intention of providing a treatment for similar religions, withing a larger religious grouping (Catholic versus Protestant is your example) is going to work.
[edit]
I thought about it a bit more, and assume that the intent was for related religions to halve the discrimination factor. Is that the case?
Cheers
Last edited by Gary Thomas on 11-03-2002 at 04:13
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
quote: Gary, all procedures I listed ("Handling Religions Grand Shceme", etc) refer to the technical docs of the govt and social models. It's the descriptive version of the social model that goes up to VII, so there's your confusion. | Nevertheless my social technical document only goes as far as "VII Changing EG's populations in a province via religion". Am I missing some pages?
quote: About nationalities: Nationality represents the nation/tribe the EG feels it belongs to. (Mark proposed a better name was NationalAffinity). That nation or tribe may or may not exist as a civ/empire. FE, after Hernan Cortes' conquest of aztec empire, there'd be no aztec "civ", but there'd be EG's with aztec nationality, i.e. people who still called themselves aztecs. | I do understand that. What I have difficulty accepting is that "nationality" exists as just a string. A nationality must have more characteristics than merely a string, a name in a single language. In any case, as long as there are people who can consider themselves aztecs, there is an aztec civilization, even if it has no political control of anything, the concept exists.
quote: It's important to avoid "connecting" an EG with a civ. Things like a "pointer" from the EG to a civ should not exist. | Why is this? It seems to me that this is just what is needed.
Essentially, my problem is that if nationality is required, I have to attempt to match it to a civilization. One way I can see of doing that is to attempt to match the nationality string to a civilization name. If a match occurs, then that is the civilizatoion that matches. So, if the aztecs are restless, Cortez should change the name of his civilization from "Spanish" to "Aztec" which would have the nice effect of calming the natives, though it might upset some people in Madrid.
If, on the other hand, the civilization itself has a nationality, which cannot be changed by the player, then the match should be to that nationality (rather than the name of the civilization). It seems to me to be completely irrelevant whether the match is done at the start or when needed. In particular, when a scenario is input from an xml file is the time to do it.
Cheers
|
|
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
quote: I thought about it a bit more, and assume that the intent was for related religions to halve the discrimination factor. Is that the case? |
That's the case. And clearly there's something bad in the equation. It should be:
RD*(1-(1-Abs(Sign(FVE-FVG)))*0.5)
quote:
My question is, how can the central government have a "province's Administrative Effectiveness Level"? |
The central govt has not an AEL. Each province has an AEL. The central govt controls provinces through its control over "local govts". Some effects of the central govt over the provinces are "felt" by EGs through the local govts. Models, then, make reference to characteristics of those local govts. In particular, AEL.
quote:
Nevertheless my social technical document only goes as far as "VII Changing EG's populations in a province via religion". Am I missing some pages? |
It seems so... Give me your email and I'll send you the docs (the adress I used, that I mentioned in the other post, failed).
quote: In any case, as long as there are people who can consider themselves aztecs, there is an aztec civilization, even if it has no political control of anything, the concept exists. |
Well, yes, but I don't think we need to encapsulate EGs in a "thing" called civilization. The question is why would you want to do that. What game experiences can derive from such encapsulation we aren't covering now?
This is beyond my competence, but I don't see any reason to model "civilizations" as groups of people with certain common characteristics. Even more, I think that's a bad idea. I think we need govts and EGs. Nothing more. The "civ" the player controls is, really, a govt that, in time, contains people of different ethnicities. The word "civilization" is actually very deceiving. In terms of a game like this, it's IMO useless because players control empires (political instances). They don't control civilizations (that is, they can't control the customs, religions and other social characteristics people have). If we agree players are constrained to affect the game only from the position of the ruler of one govt, then the "thing" called civilization isn't needed.
Unfortunately this is the type of topic that easily "booms" to abstract dicussions stopping coding progress... I firmly believe all relevant social behaviors/effects are well modeled w/o the need to unite EGs to an abstract thing called civilization.
Nationality is needed mostly to model rebellions. For that purpose, the only info I need is what nationality an EG has and what nationality the govt under which control the EG lives, has. Simply put, a mismatch implies unrest.
There's no need to describe a nationality in more detail: quote: A nationality must have more characteristics than merely a string, a name in a single language | You're thinking EGs here. The EG is described in detail, socially. In particular, the people of the EG call themselves parts of a tribe called [nationality].
quote: Essentially, my problem is that if nationality is required, I have to attempt to match it to a civilization. |
Why you "have" to attempt that? What happens if you don't?
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
quote: It seems so... Give me your email and I'll send you the docs (the adress I used, that I mentioned in the other post, failed). | I have located the missing two pages, thanks.
quote: Nationality is needed mostly to model rebellions. For that purpose, the only info I need is what nationality an EG has and what nationality the govt under which control the EG lives, has. Simply put, a mismatch implies unrest. | So it is only used to determine whether the owning civilization is the "right" one and for no other purpose?
quote: You're thinking EGs here. The EG is described in detail, socially. In particular, the people of the EG call themselves parts of a tribe called [nationality]. | I am actually thinking object-oriented code, where objects are better than strings.
quote: Why you "have" to attempt that? What happens if you don't? | I perhaps haven't had the time to go over all parts of the model as thoroughly as I would like, but I was going from the statement at the start of section IV of the Riots Model, Pro-Action Feelings, under NRF where it states that a rebellious ethnic group might want to "join the civ of the same nationality if it exists". This means that I have to identify that civilization. The best way to do that is to have a pointer to it, or a null if it doesn't exist. Clearly, if the ethnic group has a null nationality, it will not match any civilization, which presumably is what is intended if there is no civilization matching the nationality.
Hence, by saving a pointer to the appropriate civilization, or null if no such exists, I do not need to do a search later. There doesn't appear to be anything in the game that can change this nationality or this mapping.
Cheers
|
|
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
Gary, if the discussion is about defining the thing as a string or as a pointer, then it's your call. I can't do nothing but confuse you with decisions like that.
But since I agree with your last post, I wonder how a pointer would do in those situations.... If the aztec and the inca civs (govts) disappeared, all aztec and inca EGs would have null pointers. If a "neo-aztec" empire comes to life, how can you identify aztec EGs from inca EGs?
If the above question sounds strange to you, that should be a sign that we're not working with the same idea of what a civilization is...
Anyway, all I'm saying is don't connect EGs to a thing call "civilization", where civilization here means a thing with a govt, provinces, techs, etc. If you do that there'll be trouble. (sound like a threat, but I just mean we're gonna face some problems! )
|
|
|  |
 |
|
ogj20
|
|
Right, another one of my excessively long posts trying to revive a discussion.
First of, would it be possible to see a copy of the equations documents that are mentioned above by Gary.
Secondly, it seems that some clarification/rationalisation of the method of handling ethnic groups is required, partly because having read this thread I'm really not sure exactly how things are supposed to work, and partly because I suspect that the model is in danger of either requiring huge storage and processing, or failing to provide for ethnic diversity and cultural evolution, in which case it seems to lose much of the benefits which make it worthwhile to implement.
So, to put the cat among the pidgeons, restate other peoples ideas, go over ground that has already been discussed and agreed, and generally make a nuisance of myself, I'd like to have a recap of the issues and suggest an idea.
I would suggest the following are the essential points.
* Ethnic groups essentially have a population, religion and cultural background, and need to be located in a map square, in order to allow populations to change hands by conquest.
* Ethnicity is the combination of religion and something which is almost but not quite as simple as nationality (call it culture?).
* It should be tracked at province level to limit storage and processing requirements, and processes should exist to allow evolution of preferences, creation of new ethnic groups and probably the disapperance of old ones.
I suggest the following model would allow this:
level object / class
World culture religion
(nationality name + prototype attributes) (religion name + ideal attributes)
| \ /
Province Ethnicity (cultural attributes stored at this level)
| |
Square EthnicGroup (actually, only really when moved about,
normally just part of the populationData ethnic distribution)
The key to this is that ethnicity objects would be created at province level that hold cultural attributes. Two ethnicity objects would represent people that are nominally from the same ethnicity if they had the same nationality and religion, though two such ethnicity objects from different provinces could have markedly different cultural attributes, since they would evolve independently. The interesting things would go on when people from one ethnicity meet other people from a supposedly equivalent ethnicity.
Putting an Ethnic group into a province
If you placed an ethnic group from one province into another (by migration, conquest, colonization or redrawing of province borders etc.):
Attempt to find an equivalent ethnicity (culture + religion combo) which is already present in this province
1) If none is present you would add it, simple. (e.g. add Roman pagans where there are none, get roman pagans)
2) If one is present you would check to see how different the cultural profiles are (e.g. by sum of absolute or square differences between the factors). Decide if they are too different to be compatible, either based on a cut-off level, or by a random check based on the level of difference and the number of ethnicities in the game, with aim of keeping this to a managable level.
a) if compatible: merge the profiles by weighted average.
(e.g. add 1000 Roman pagans who are fairly traditional
to 2000 Roman pagans who are a bit more traditional,
get 3000 Roman pagans who are somewhere in between)
b) if incompatible: an ethnic schism would occur:
(e.g. add 1000 Roman pagans to 2000 Roman pagans
they can't stand to be in the same room with and all hell breaks loose)
Ethnic schism:
If there become two incompatible ethnic groups with the same ethnicity in a province (i.e. an incompatible ethnic group has just been added to a province) then the people of one of the two groups would be forced into breaking from their culture, and finding a new way of viewing themselves.
To accomplish this we would change the ethnic group which is furthest from the (shared) cultural prototype profile. Their ethnicity would be changed to
either:
An existing ethnicity with a different culture but the same religion that already exisits in the province if that will reduce the misfit with the cultural prototype profile -- a mechanism for eliminating cultures, representing the outcasts being driven to join a different social group whose views better fit their own.
(e.g. add 20 roman pagans who are very capitalist to
10 RP who are very socialist, and the 20RP merge with the Italian Pagans,
who are just like the 20RP, but Italian)
or else:
We would create a new culture with a prototype profile formed from the ethnic groups's profile, ensuring this is (much) closer to the ethnic groups profile than the incompatible one was. This should have a new name, ideas would be
The civ name of the civ they find themselves in
A geographic modifier (East Germans)
A meaningless modifier (White Russians)
A generic name list... etc.
In roughly descending order of preference, if they are not already taken.
This represents the outcasts, finding no support in society, creating a new identity for themselves.
(e.g. add 20RP capitalist to 10RP socialists, they becomee 20RP Northern Roman Pagans)
Revolution/independace
In addition new cultures could be created when revolutions occur, or when provinces try to become independant, e.g. if the gauls revolt against rome, they create a new civ called Gaul, but if some romans revolt against rome, they'll need a new cultural name.
These new cultures could either choose names as above, or from a list provided with the original culture (Celts -> welsh, irish, scottish etc.) if we want to add this detail.
Result of a schism
Other ethnicities with the same culture in the province could decide which side they are on in the argument, by moving them to the new culture if it makes the fit with their cultural attributes better than with the existing cultural profile (e.g. if some Roman pagans become Italian Pagans, then the Roman Christians should decide if they want to be Roman or Italian).
I think it would make sense to update the original cultural prototype to be the weighted average of the (local)ethnicities which are still part of that culture after a schism occurs, this would represent the members of the original culture taking stock and really considering what it means to be part of their culture after all.
Optionally, it could also make some kind of sense to have ethnicities of the same culture in SURROUNDING provinces also decide which way they want to jump, though this might not be a good idea.
Result
This way we limit the number of sets of preferences we have to store to at worst the number of cultures*religions*provinces, which should be more manageable than by square. In addition the number of ethnicities the player sees is at most cultures*religions which the player should be able to cope with, and we provide a fairly intuitive mechanism for ethnicites to be created, evolve and disappear.
Comments and complaints please.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:15
|
|
I think province vs. square is OK.
About revolution/independance, I'd rather have the province ethnicity change before they revolt. That way, you can have Americans and English in the colonies before the American revolution, thus allowing to have units which will become American or English, and not all of them turning American.
So I think every turn, if a province ethnicity is becoming too far from its cultural protoype, it would change into a new ethnicity (maybe drawing some other ehtnicities along with them, creating a new prototype). The condition for the change would be distance from cultural prototype, based on a set margin or random factor.
Thus I suggest checking every ethnicity against its cultural prototype every turn, and changing to the preferred culture or switching to a new culture if the old one no longer fits the needs. This should IMO trigger revolution (though it may not occur immediately) rather than be a consequence of it.
Also, when joining a square, number of individuals should be important. A small number of people will more likely be assimilated than a big number.
I don't know how the model handles inter-EG marriages, though that may not be important early in the game.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
quote: Originally posted by ogj20
Right, another one of my excessively long posts trying to revive a discussion. |
You fit in very well! We tend to be a long-winded bunch . Thanks for pushing this foreword!
quote: First of, would it be possible to see a copy of the equations documents that are mentioned above by Gary. |
I just sent it, along with other documentation that may be of value.
I basically agree with many of the things you say, and the most difference is in the revolution/independence stuff. I'm primarily in agreement with the continuously-evolving view presented by Laurent. For example, before the American Civil War the American ethnicity would probably already have split into three overall ethnicities represented by those in the north, those in the South, and those in the pioneer Western Territories. I think just because there is a revolution is no reason to change the ethnicities of people. If there are ethnic fall lines upon which a revolution is based, they most likely appeared long before the said revolution actually occurred.
I think we have discussed this issue before, and the basic idea was to use a clustering algorithm to determine if something that is nominally a single culture is bifurcating. This wouldn't be much of a load on the system seeing as it would only has to be done occasionally.
Your schism stuff sounds reasonable to me, although I think it might be fairly rare. I hope Rodrigo makes it back, and we can hear what his opinions are on your proposals. BTW, I just e-mailed him letting him know about our new discussions.
quote: Originally posted by LDiCesare
Also, when joining a square, number of individuals should be important. A small number of people will more likely be assimilated than a big number.
I don't know how the model handles inter-EG marriages, though that may not be important early in the game. |
I agree with pretty much everything you said Laurent 
edit to fix quoted text. Did you know that if you mix an opening "quote" tag with a closing "q" tag it doesn't consider the quote ended. I didn't!
Last edited by Mark_Everson on 13-02-2003 at 16:38
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I think that army units should have a listed ethnicity. That way the game knows who to add to a square when they disband. It would also be good for the militia calculations; the people can use the unit ethnicities to decide if they want to fight. Also, units should only be able to get reinforcements of the square they are in contains their ethnicity.
One thing that bugs me in the scenarios we have now is that armies can be raised right after conquering enemy territory. As Attila grabs Roman territory, he can use that territory to start cranking out more Hun units. I believe that the best way to fix this is to say that a civ can only raise units from their preferred ethnicity, so it becomes impossible to churn out units from newly conquered squares. A civ that raises a lot of units should start having problems with population depletion, like the Germans in World War 2. They could use the economic resources of the captured lands, but only Germans could (usually) be trusted to be soldiers, and they soon started to run out of Germans even though they ruled over a much larger population than before.
Of course, civs with high ethnic tolerance may get around this, but that comes a lot later in the game.
|
|
|  |
 |
|
ogj20
|
|
I agree entirely that units are going to need ethnicity for a whole host of game mechanics to work properly. That's why I snuck it into one of the fixes I sent Mark.
quote: Mark,
I found myself annoyed by the way that units disbanded in unoccupied squares would just evaporate, so I developed some changes that mean they will colonise the square instead, thought they bring nothing of use with them as I have it at the moment (I thought it would be best left to you to decide on an appropriate amount of capital(mostly in the form of tools, I'd have thought) that the members of a disbanded army should have).
That unfortunately led me into making some small changes to quite a few areas of the code, since I quickly discovered that though populations are supposed to ethnic groups, armies don't have.
...
I have it at the moment armies that are built get the same ethnic profile as the square they are built in (should this be province?, since I think the recruits come from the entire province). Armies that disband return their troops in ethnic groups based on the ethnic distribution. I've also had to change the code that handles building armies for scenarios, to include a new property that can be given to units, of unitEthnicity, so that units can start out with an ethnic distribution (though as it stands they can only have a 'distribution' of one option, but I didn't want to complicate this too much.)
I think this feels nicer than it did, and should provide opportunities to feed into other game mechanics, e.g. we could have armies that can rebel or defect because they could now have opinions based on their ethnic makeup, or other similar possibilities.
The down side is that it will require a little work to alter the scenario files, since wherever there was a unit creation tag there will now need to be information about that units ethnicity. I thought this might be improved by having a default ethnicity for the army high command, which would limit this to one change per civ per scenario |
I'm don't think those changes are incorporated into the testbed yet, but when they are you will be able to take advantage of this by e.g. changing
Warriors to WarriorsThe People
If these changes aren't made then the units simply have a null ethnicity, and nothing breaks, (but it's a bit weird when you disband them in empty squares, because the resulting population also has no ethnicity, and as a (rather strange) result cannot be picked up by a taskforce.
|
|
|  |
 |
|
ogj20
|
|
Damn, I take it that you can't post xml tags as straight text, is there a good way to do this..
anyway, let's try a cludge to get round this, please read square brackets as tag style angle brackets..
change [unit]Warriors[/unit] to [unit][name]Warriors[/name][unitEthnicity]Warriors[/unitEthnicity][/unit]
fingers crossed this works....
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
Yeah, posting html is a pain. BTW I had to re-format my post of last night. I ended up with a long quote that was actually new comments from me interspersed with a few quotes looking like one big quote. It came from mixing a "quote" tag with a "q" tag, which is apparently not read by the parser right.
Richard:
quote: One thing that bugs me in the scenarios we have now is that armies can be raised right after conquering enemy territory. As Attila grabs Roman territory, he can use that territory to start cranking out more Hun units. I believe that the best way to fix this is to say that a civ can only raise units from their preferred ethnicity, so it becomes impossible to churn out units from newly conquered squares. A civ that raises a lot of units should start having problems with population depletion, like the Germans in World War 2. They could use the economic resources of the captured lands, but only Germans could (usually) be trusted to be soldiers, and they soon started to run out of Germans even though they ruled over a much larger population than before.
Of course, civs with high ethnic tolerance may get around this, but that comes a lot later in the game. |
I don't know how to fix the Romans fighting for Carthaginians problem. Long-term I think we can have a fix, but it will be a bit complicated.
In the scenario as it exists, it is mostly at first Romanized Gauls fighting for Carthaginians in the case you object to, which may have worked just fine in reality. When you get to Latins signing up for the Carthaginians, that is a bit more of a stretch.
One idea is to give troops a reliability based on the units ethnic composition. If that ethnicity is treated poorly in the civ it would be:
1. More likely to break in a morale check, and more likely to undergo manpower attrition when/if we have that
2. Less combat-effective overall
3. More likely to join a revolt or switch sides to another civ.
I'm not sure this is urgent enough to require a temporary fix. What do others think? I guess each square could have a "when conquered" flag and you could only build units with ethnicities different from the civ ethnicity something like 20 turns after conquest.
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
Sounds good. How do you code for a mix of ethnicities in the unit?
You have to use the html escape sequences to get any code to work properly:
< gives <
> gives >
What I do is write posts in a word processor and then go through them with the find-replace command. An added benefit is that I don´t lose them if something goes wrong with the forum.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:15
|
|
Unit ethnicity has been coded by Owen, but is right now single-ethnicity when built from xml files.
I don't think units should be restricted from ruler's ethnicity. Legions were mostly made of non-Romans for instance, and colonial armies have been full of non-core ethnicity fighters.
I can probbaly check a unit behaviour during a fight the same way I check for militia: If the unit's preferred civ is not its current civ, then I can give it a chance to revolt and switch sides, if they believe switching sides can make them victorious. That means I need to show ethnicity details in the army details popup so the player be not surprised.
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
Mark´s plan sounds good. Allowing other ethnicities to be recruited, but only after a certain amount of time, is good. Roman legions of the late Empire may have had a lot on non-Latins, but that was only after they had held the areas for quite some time. IMO you should have to hold an area for at least one generation before you can recruit soldiers into the core army.
|
|
|  |
 |
|
ogj20
|
|
As LDiCesare says, right now you can only assign a single ethnicity to each unit in XML, I did that to keep things simple, but units that get built during the game can have a mix of ethnicities in a single unit. If you'd like I could add the ability to have a mix for XML units farly simply, it's just a case of yet more tags, and more work for scenario designers.
As to limiting the ethnicities you can recruit...
I suggest this could most easily be implemented by having individual ethinc groups (... or whatever level we hold this on... see above) having a civilisation loyalty value, which increases slowly over time,at a rate and to an equilibirium level based on e.g. how well treated that ethnicity is, how secure the civ is, how many of your troops are knocking around the area, how close to strong opposing civ's you are.
If you conquered a square, the loyalty to you would become (1 - the loyalty to the previous owner) and you'd only be able to raise troops from ethnic groups with greater than a certain loyalty value. (plus it could affect the chances of militia appearing or rebellions occuring etc.)
That way newly taken territory won't supply you with troops (though it can be forced to help pay for them).
If you'd like I could put some outline code in that simply has the loyalty increasing at a constant rate over time up to 1, ignoring the complication of working out an appropriate rate and target level, and only lets you recruit when it's over say 0.5.
If I set it so that it increases by 0.3 a turn, then you'd have to wait three turns to recruit from newly captured territory, but of course less from territory that's been swapping hands regularly, which will oscillate around 0.5
I think modifying this to account for all the complexities of which side the people WANT to support will have to wait until we get the social and government models really sorted out, but this should let us playtest the key effects of the mechanism easily.
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:15. Apolyton Time is 00:15. |
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
|
|
|
|
|
|