Coding the "Society Model"

[Mark_Everson]

Originally posted by F_Smith
That handles the entire economy turn. I'm sure that's how you're doing it, isn't it?

Yes, that is how its done with econ at the square level. If if were at the province level the issue is you need to figure what squares the infrastructure goes in. If I have a 10-sq province where one square is mountains, we don't want to assume that if an enemy takes that worthless mountain that they get 10% of my factory capacity. So you need Apportionment algorithms for a prov-level economy that you don't need for a square-level economy. And I think there may be other things than infrastructure this needs to be done for. So I believe it is not as trivial as you think.

But that's going to have to be it for me on this discussion. One thing I've learned since you were around is to practice triage in my design discussions. As I said above, the current square-based system should work for the next several months just fine, so this isn't something I feel I should discuss in depth at this point.

[Gary Thomas]

Since both ethnic groups and social classes can only be created with an associated population, and since population can only exist at the square level (or, to be exact, in a square), the present system is entirely square oriented. In my view this gives far too much flexibility, and gives a nightmare to scenario designers, as well as probably overloading any machine for storage space and execution time.

The system I would prefer, and advocate, is something like this:

There are a fixed number of social classes, whose contribution to the five social roles is likewise fixed. By fixed, I mean unchanging in the course of a game. They can be read from a system data file at the start, but only so they can be fine-tuned for playability or accuracy, without changing the code. The only factors that each of these social classes specifies are name and the five social role factors. They do not specify population or attitudes or policies.

Each ethnic culture is defined globally, with a unique name. Each has a specific religion and culture, and a specific proportion of each of the social classes. These values do not change in the course of a game. There may be a base set of attitudes archetypical of the ethnic culture.

Each ethnic group is specific to a province, and points to an ethnic culture, and also has a set of attitudes for each social class, so these values are constant over the province.

Each square has an ethnic population for each ethnic proup represented in the square. This will consist only of a reference to an ethnic group, and a population value.

That seems to cover the data structure. It will also give a certain amount of coherency to ethnic behaviour.

Cheers

[F_Smith]

If if were at the province level the issue is you need to figure what squares the infrastructure goes in.

Well actually, this fixes any problems of that kind.

As I mentioned, the 'update' method in each mapsquare is called. That method runs the mapsquare's turn. Something like,

public void update()
{
doProduction();
doConsumption();
}

So when that 'doProduction' method is called, in there it feeds it's taxes, etc, up to whatever 'Province' it belongs to. So you never have to worry about which province it 'belongs' to, it knows and handles that itself.

This allows the entire thing to be done very easily. Without this approach, you'd have to do backflips.

[F_Smith]

Since both ethnic groups and social classes can only be created with an associated population, and since population can only exist at the square level (or, to be exact, in a square), the present system is entirely square oriented.

If you mean that there's no reason for each square to have a unique EG or SC, I'd agree completely. There absolutely should be a fixed number of SCs.

EGs, I think, I prefer being more fluid. Since we are talking ethnicity.

But that's just my opinion.

[Mark_Everson]

Hi Gary:

I agree with much of what you have to say. Exceptions and clarifications below.

Originally posted by Gary Thomas
There are a fixed number of social classes, whose contribution to the five social roles is likewise fixed. By fixed, I mean unchanging in the course of a game. They can be read from a system data file at the start, but only so they can be fine-tuned for playability or accuracy, without changing the code.

So far this is exactly as things are currently envisioned. That may not have been clear from the code structure.

Each ethnic culture is defined globally, with a unique name. Each has a specific religion and culture, and a specific proportion of each of the social classes. These values do not change in the course of a game. There may be a base set of attitudes archetypical of the ethnic culture.

I only agree with the first sentence here. I may need clarification on some other things. Are you saying an EG or part of it can never switch to a different religion? A German EG should be able to have adherents of Protestant and Catholic persuasions. As currently constructed it is allowed that Some German-named EG can be Protestant and another Catholic. In the code they are different EGs but one can aggregate by the name "German". How would this work in your proposal? If you allow only a unique flag then things will balkanize very quickly. If you are saying the proportion of social classes don't change through the game, again I disagree, but you may not have meant to say that...

Each ethnic group is specific to a province, and points to an ethnic culture, and also has a set of attitudes for each social class, so these values are constant over the province.

OK, although we may want to use districts rather than province to allow for a dichotomy between city and rural within the province. The difference between urban and rural culture is an important historical item I'd like to capture if its not too expensive. But for now I think this is ok.


F_Smith:

So when that 'doProduction' method is called, in there it feeds it's taxes, etc, up to whatever 'Province' it belongs to. So you never have to worry about which province it 'belongs' to, it knows and handles that itself.

This works fine for a cheezy civ-type economy. This approach simply does not work for the current Clash economy. We have had this same discussion before, about a year ago in the econ thread of that time. I won't be drawn in further on this discussion, too much "been there, done that".

[Gary Thomas]

As currently constructed it is allowed that Some German-named EG can be Protestant and another Catholic. In the code they are different EGs but one can aggregate by the name "German". How would this work in your proposal?

Are they not different ethnic groups under the present system? How are they distinguished now?

If you are saying the proportion of social classes don't change through the game, again I disagree, but you may not have meant to say that...

I did not mean to say that, only that if the proportions change they change for a whole ethnic culture, but see the urban/rural comment below.

OK, although we may want to use districts rather than province to allow for a dichotomy between city and rural within the province.

This is a can of worms that I intended to attack later. However, my proposal is that cites should be squares within squares, with their own population, and so forth. I don't have any problem with city populations having a different social class structure to rural populations for the same ethnic group.

However, do I feel that the social class stucture should be constant over an ethnic group (with the variation mentioned above). The idea of this characteristic varying by square will add a huge amount of complication to the game, both in the code, and in the player's comprehension of what is going on, without, I feel, adding anything but an unnecessary level of realism.

F_Smith:

So when that 'doProduction' method is called, in there it feeds it's taxes, etc, up to whatever 'Province' it belongs to. So you never have to worry about which province it 'belongs' to, it knows and handles that itself.

Does this mean that these "taxes, etc" are remembered by the province, for later processing when all the returns are in?

Cheers

[Mark_Everson]

Gary:

Everything you said sounds fine to me, with the exception of the square-within-a-square idea. That sounds a bit odd. But that is a Long ways off, so lets just ignore it for now... ok? If you do your polygons thing then cities could just be bitty polygons!

Originally posted by Gary Thomas
Are they not different ethnic groups under the present system? How are they distinguished now?

Yes, they are different, as I said in my post above. The only thing I was worried about is that we continue to make it possible to aggregate many EGs in the code by name ("Germans") or some other parameter. That aggregation isn't in the code either yet, but its one of the things I'd planned to do. So the player can see how many Germans or whatever are in his empire. Sorry I confused you...

[roquijad]

Hi All. I'm back from vacations, so I'm ready to drop a few comments/answers:

Mark:
1) Yes, I got rid of the "Economic Planning" policy. Maybe it'll eventually come back, but for now I suspect we don't need it at all. When we get into the govt-econ interconnections we'll be sure.

2) The formula: Civil Rights=ES*((0.5*(IND-TRAD)-p)/(1-p) does not have a typo. It's just wrong! Change it to ES*((OB-0.3*TRAD)-p) where OB is EG's Obedience. While I was checking this, I found a typo in that section. IND, AGG and ASC are wrongly defined (parenthesis missing). They should be:

IND=0.5*((1-K*0.4)*Individualism + K*0.4) + 0.5*((1-E*0.3)*Individualism + E*0.3*RIndividualism)

ASC=0.5*(1-K*0.2)*Asceticism + 0.5*((1-E*0.3)*Asceticism + E*0.3*RAsceticism)

AGG=0.5*((1-W*0.3)*Aggressiveness + W*0.3) + 0.5*((1-E*0.3)*Aggressiveness + E*0.3*RAggressiveness)

The change is valid for sections IV and V of the Govt Model Technical Doc. Sorry!


3)

Because the numbers inside the Exp() vary by orders of magnitude and can swing from positive to negative there is a large chance of getting a mathematical overflow because of the exp. So something needs to be done to change this expression in the long run.
In game terms, I think an exponential dependence may be too sharp anyway. Relatively small differences in parameters for two Regimes can give quite different support levels because of the exp. Please at least think about it.

From my experiments I'm confident there won't be any problems. Your two concerns are both "solved" by the 0.08 factor at the beginning of the expression. My experiments showed a 0.08 value behaves well. Anyway, if something needs to be changed here is the magnitude of this factor. The bigger it is the bigger numbers the program will have to deal with and the sharpest decisions will be. I believe the use of an exponential is almost mandatory here because if a regime is sufficiently away from social class' desires then the support share must be, ideally, zero. The exponential does pretty well doing this, sending down the support share to a value very close to zero.

4) In some of your posts, when you list pol.blocks polpowers, you put a "Labor" pol.block (replacing my original designation of "people's pol.block"). I strongly recommend you to go back to my designation because othwerwise it'll create confusion. The people's polblock includes everybody regardless of social class. If you label it as "Labor" you restrict it to workers/peasants/etc, which is incorrect.

5)

Rodrigo never specified exactly how we determine over which range the Player/ruler can set government policies.

I did specify it, but I understand the confusion because I didn't use the same language in the technical doc that I used in the forums. Section VIII of the technical doc explains how you create the "Future Govt Profile" and the idea of range and its width calculation is "hidden" there. This profile is the one that combines social classes decisions with ruler preferences. By making the calculations explained in that sections what you get is an automatic ruler intervention. Do remember that the player isn't meant to use the govt interface every turn to pick a value for each policy within the allowed ranges. The game automatically does that for him based on the preferences he has entered in the Ruler's Govt Profile. If his desired values are within the allowed ranges, then the game automatically set policies in those values. If for some policies the ruler's preference is outside the range, then the game automatically chooses the closest value the range allows.
Using this philosphy of "automatic ruler intervention" you give the player freedom to forget about govt for several turns. The profile created is a "futuristic" one because in general terms it will not be true that changes in govt shape happen immediately (from one turn to the next). That's made so to represent a)the actual process of negotiations, which take time; and b)the process of implementing decisions and make'em a reality. The "Future Govt Profile" represents, then, the policies and pol.power structure the govt will have eventually if nothing changes along the way. The mechanism by which the Current Govt Profiles slowly becomes the Future Govt Profile is handled by section IX of the technical doc. In there you can see that the length of the game turn is explicitly considered. The CGP will become the FGP fast or slow depending on how long a game turn lasts.
If for playtesting we prefer to see the changes in govt the very next turn, then I recommend replacing what's described in section IX by the simple rule of "make the CGP equal to the FGP".
Anyway, if you want to know what's the width of the ranges the player faces, that's determined by the value of M in section VIII. M=exp(-3+3*RULERPW). That means the ruler faces a range of [X-M, X+M] for each policy, where X is the value decided by the rest of society. For example, when the ruler has 20% power, M=0.09. When he has 70%, M=0.4. When he has 100%, M=1.


-------
All:
Mark said:

One thing I Am worried about is that it seems the player can consolidate power, and get it to 100% fairly rapidly with the current system. Maybe I don't understand something Rodrigo has in to prevent this... FE the player power is, in the example 35%, but the player can negotiate it as high as 61% in one cycle (Under "Highest Values Player can select" see Ruler: 0.61). After a few round of this (that might take 30 turns) you can go peacefully from a republic to a dictatorship. Of course the riots model could take care of that all by itself as jealous nobles threaten insurrection, etc. Rodrigo, am I missing something? If not I'm sure we can come up with a fix.

LDiCesare said:

Mark, I think that all parties always want 100% power.

Mark added:

But in the interim, there's an idea I had a long time ago for how to limit power changes. It is from my old early govt model. It gives each political block a feeling for what thier power should be based on contributions to society.

Kind of an old thread... I got into the govt model the first time because IMO the original model by Hrnakfell (I don't remember the correct spelling) had serious problems due to its emphasis in contribution and its strategy of "I want all the power I can get". Both strategies are IMO unrealistic. Bringing back to life an argument I gave years ago, considering today's massive US military force, it would lead in the game, in terms of the contribution-based strategy, to an amazingly unstable democracy, with the military demanding a huge piece of power. The US would go from one military govt to another. But we don't see that in RL. The same is true for economy. With the huge econ power companies have in the States and their gigantic contribution in terms of taxes, employment, etc, what you'd get via the contributions modeling is the US should be some sort of oligarchic rule. Although we know these companies have more influence in govt that the average man through lobbies, campaign endorsement and stuff like that, the US is not an oligarchy.
The "I want all the power I can get" strategy doesn't IMO seem realistic either. Churches and the military, just to name a couple of social classes, would be extremely pissed off today in the US if they compare the polpower they have and the 100% they supposedly want. But I don't see that.
That's why I introduced back then the concept of ideology (now called regime). My strategy was that people (social classes) have a complete image of what the govt structure should be. You don't restrict your view to how much you get, but how much each is getting. If you're very religious then you want the Church to have a big piece of power, even if you're not part of the Church yourself. In the past common people actually believed the clergy should be part of the "ruling class". A military can be a democrat and believe the military leaders shouldn't interfere in politics.
That said, I think my approach is better. I think, Mark, that you got confused when you said "It gives each political block a feeling for what thier power should be". In the current model social classes know how much power their own polblock should have and, furthermore, they know how much the rest polblock should have and how much the ruler should have. What you (almost) proposed to solve via contributions is already solved via regimes and the support each social class shows for them. What you don't like is social classes letting the ruler get away with it.

In the current system it is in fact, as Mark says, possible for a republic to become a dictatorship peacefully, but inprobable. But the fact that it's possible is not, IMO, a flaw. There's a "hidden" assumption if you consider it a flaw: you think people don't want the dictatorship. Although we agree that's probably the most common case, we shouldn't force social classes to dislike despotism per se. If you have enough supporters, the transition to a dictatorship should be possible, as partly was Hitler's case and has been also the case in some latinamerican countries. Historically, in several ocassions societies have given up power to empower a ruler under situations like war. The old roman republic is a good example.
Now, if we take the case of a ruler trying to go despotic while most of people not wanting it, then in that case maybe you're underestimating the power of the riots model and ignoring the speed of changes.
First, it's important to remember that in the riots model people get upset by an undesired govt structure and by a ruler with "bad" preferences. That means the people react to what the player enters in the Ruler's Govt Profile. If he wants to get more power via negotations, then he has to enter it in his interface (representing the expression of that desire to the social classes for negotiation purposes). The social classes can then react to his desires via the riots model, before the ruler gets despotic. If he's able to survive, as time passes and gets more power, people will get even more angry because now despotism becomes a reality (riots models looking at the new Current Govt Profile values). This is a whole process over the years, so the player'd have to be lucky to become a despotic ruler peacefully and live to tell it.

Players usually won't like to wait years to get a despotism. The process is also unattractive if you know you're risking the civ's stability and your neck. It's better to play dirty with a sudden shift.

However, I agree social classes should be able to stop this guy "legally" w/o the need for riots and coups. Specially if the ruler still has low power and is openly expressing he wants more. That's why I initially, in the first version of the riots model, considered an event called "Legally Replacing the Ruler" which was activated when ruler's preferences mismatched deeply people's desires and when social classes had enough power of their own. As a result, the player's interface is adjusted to match people's desires (as an aggregate) and the ruler becomes unallowed to change it for a few turns, representing the change of ruler to a more "tamable" one. Somewhere along the versions I eliminated that event (I don't remember now why) but we could reintroduce it. If that still doesn't satisfy you, we could analyze other options.

----------
Gary said:

The first is that every map square currently has a "MapSquareEconomy". Should it also have an Administration? The more I think about it, the more I think it should.

For social/riot/govt modeling, I'm satisfied handling it at the province level. What do you think would be the gain in having it a lower level? I see almost no use at least for the "society model".

-----------
EGs at squares vs provinces: Because of how the social model works, two EGs with same religion and nationality living in the same province but in different squares would evolve exactly the same, so I think the only reason to store things at the square level is military conquest.

------------
Mark said:

The most recent stuff is near the bottom of the screen dump.

where is this? do I have to download something?


Cya!

[Mark_Everson]

Welcome back Rodrigo!

Hi, I hope your vacation was a lot of fun. I have read fairly quickly through your post, but am too sleepy to respond in detail...

So just a few points for now.

The "screen dump" means the stuff on the first page that comes from the program diagnostics. Like the post 02-02-2002 20:09 .

Soon I will set you up so you can run the early D7 code with the govt model in it, and test how some things evolve yourself. You can see from the "screen dumps" roughly where I got before I turned it over to Gary to do the xml file stuff.

The exponential expression in (3) that I said could lead to overflows actually Does lead to overflows. The floating point values IIRC overflow somewhere around 10^10. We can figure this out later...

Cya,

Mark

[roquijad]

ouch! I wrote my post off-line in the afternoon and now the conversation is going elsewhere...

Gary's post left kind of shaky...
I'd like to see along the game varying numbers of EGs...
varying numbers of religions....
changes in their characteristics and preferences...
changes in the demog. structure of social classes...

In short, I'd like to see what's already design. That's my opinion. Is it a nightmare? why you didn't tell me before!

My question to Gary: would you still consider it a nightmare if EGs (as designed so far, with all its current possibilities of change) exist at the province level (i.e. assumed to be equal in all the squares they're supposed to be living within the province)?

[Gary Thomas]

My question to Gary: would you still consider it a nightmare if EGs (as designed so far, with all its current possibilities of change) exist at the province level (i.e. assumed to be equal in all the squares they're supposed to be living within the province)?

My big problem was with social classes, rather than EGs. If the number of social classes, over all EGs, is reasonably small and unchanging, I really don't have much of a problem. What I do not like is the idea of 100,000 independent social classes, which is about what is likely to happen with the present coding. Adding them all up, possibly several times, for every decision, when there is no consolidated list, was the nightmare I referred to.

By mentioning a small number of social classes, I mean that less than a dozen should cover it. If you start adding more, game comprehension starts to slip, with a player wondering what on earth a social class called an "Uzbekistani high plateau with forest wandering gypsy style itinerant worker who nevertheless has a stake in some tribal land and is a Muslim with heretical views" means.

Cheers

Gary

[Mark_Everson]

Don't get too concerned Rodrigo. The things I've seen in Gary's comments that I though were against the current model approach... I've already talked about with Gary, and he didn't mean them that way. And besides, we won't make any big decisions without you

The issue started because I began with F_Smith's old Beast code (See, we did use it finally 'F') that had every EG object at the square level. If his didn't, and I honestly can't remember for sure, when I was integrating it into the current code structure it Became so. I added Social Classes for every EG in the same way, just to get things going with PoliticalBlocks. It was never intended to be permanent.

Gary noted the problem that, left this way, things wouldn't work long-term, which we knew anyway from long ago. We are just returning to the original concept. I honestly don't think we're losing anything from your model had at this point. And if we did, it is usually a trivial change to put it back.

But its a good idea to keep an eye on us, just because we're not as familiar with the model as you are .

[Gary Thomas]

I am not familiar with the model at all, I just got frightened by the code. I am still not at all sure how decisions are aggregated. At first sight it appears to go over every social class of every ethinic group in every square and make a calculation which leads to a weighting for each power block. Presumably for every decision that is to be made. If that is the way it works, then I feel that it is unlikely that the players will be willing to wait around for the computer to chug through the calculations.

Again, I have not delved into the system deeply enough to be sure of what is going on. However, it does seem that no "opinion value" is stored for these social fragements. If it is possible within the model framework, it would be a lot more efficient if only changes were recorded or calculated. In the normal course of events, in a single turn, only a relatively small proportion could be expected to change. If the ones that change notified the system of the change, and the aggreated total was then modified we would enormously reduce the computation load. However, as I said, I am not sure exactly what happens.

Cheers

[Mark_Everson]

Gary:

First of all these are all optimization issues, and ones that if unaddressed will not cause any problem whatsoever for several demos into the future. I feel it is Much more important to get the social/govt framework to the point where players can experience it and see if its Fun. That is where I have been putting my efforts. We should perform any tradeoffs for clocks and memory footprint much later.

Some of your issues are due to lack of simple things that can reduce calculations easily by an order of magnitude or more. For instance all the updateXXX methods that set prefered GovernmentPolicies are now run every turn simply for my convenience. It is very straightforward to change these so they are called Just when a negotiation is about to take place. But for now I'm trying just to get things working in the most straighforward manner I can... no bells, no whistles.

However, it does seem that no "opinion value" is stored for these social fragements. If it is possible within the model framework, it would be a lot more efficient if only changes were recorded or calculated.

The opinion values are stored now in a GovernmentPolicies object for each relevant political entity.

Cya,

Mark

[Plutarck]

I figured I'd give moo3 a look and see how it was progressing, and look at this: http://moo3.quicksilver.com/official/religion01.html

Simply put, their dealing with about the same thing.

But I believe they're handling it in a superior way, in one key respect: The groups are being handled in a more abstracted way, where attributes, tendencys, beliefs, and desires are handled all together in a kind of personality "trait".

Their Ethos is like a Clash Ethnic Group. Their Ethos is comprised of a set of Ideals. So a group could have the traits of Honor, Militarism, and Isolationism (Japan, anyone?), or perhaps Tolerance, Natural Order, Comtemplative (Taoists), and on and on and on.

With just 16 attributes I doubt there is any belief system that couldn't be simulated! And if there way, you could just add another attribute!


This whole system just Feels right. Ripping it off isn't even at all neccessary, just perhaps moving in that same vein of Trait orientation.

It would accomplish all the goals of the society model, limit the amount of complexity, reduce memory/storage/computation costs, and make modding and evolutionary modelling Way Way Way easier. It seems to have so many things going for it that it seems it almost must be adopted.


But of course ultimately, Traits are just groups of numbers assigned to names. But to go with the idea of Simple To Complex rather than Complex To Simple, you could always add complexity as you go along.

So in the begining you might only have 3 preset EGs (btw, is it decided that they must be Ethnic, or is that just a word to refer to them rather than how they'll really be decided/coded? That is, someone can be convinced to join another Ethos, for instance, but you can't exactly join another Ethnic Group if it's based upon race.), and just work towards greater complexity.

So with, perhaps, 5 "Slots" to fill, each with 2-3 possibilitys (one for each slot), you'd have an easy starting point that still has a huge amount of gameplay value, but that can be easily scaled to "unlimited" amounts of variability and complexity.


Am I making any sense?