Anyway I was thinking about something....something which F_Smith said and got me thinking...

The core idea comes from many of the fantasy books/games i read/play. In many cases the wizards and whatnot are seperate entities like religions, not beholden to any civ in general. I was thinking we could do a variation on this idea for the tech model.

Of course over time, if a civ can develope its own technology, this entity's power will erode or even disappear unless it to innovates. Right now, all tech is handled via the civ. I'm just saying this as a possinbility to add depth. I mean you have this groip who sell items to you for profit for them to develope better weapons and items. They also would have great sway in tech developements of every civ to make sure no one threated their superiority.

Might I suggest that the dueling systems here seem to differ in only one regard, the span of geography over which technology is considered the same. I propose that both models can be coded simultaneously. At least as far as I can tell the same methods would be used, it just depends how much you aggregate things before calculating RPs, and the hunk' o' geography to which you ascribe a Tech object. When the basics are coded, it would only be the matter of a few hours to put in the switches necessary to handle the technology system at any of the civilization, province, or map square level. Can we agree that that's a smart way to start out?

My personal guesses that we will then find out that anything lower than the province level for handling tech is prohibitively expensive in terms of clock cycles and memory usage. But, F. Smith, if you want to spend the time modifying the code, it's only potentially your wasted time.

LGJ:

So, the current system already models differences in the technology available in a province. And if the economy is run at the square level like Mark proposes, these differences will also appear in the mapsquares. It is the economic model, not the technology model, that currently determines how good the actual systems in the province are. Making a new tech model that handles square diffrences will probably only confuse things and make problems for the economy model.

Your system is fine.

And yes, we're modelling the same things. Just using different methodologies. As with all things, the difference is in the details.

I am afraid that your system will take a long time to code unless it is broken down into components. I'm not sure I can explain the reasons why without resorting to technical mumbo-jumbo, so I'll just leave it at that.

But it can be coded. And it will probably be fun. When ya'lls programmer has it ready, I'd love to play with it.

It seems to me that I have already programmed the core of the tech system by making the spreadsheet. If someone turned my spreadsheet into Java code and added an interface, it would be done. We would still need to code the RP generation and the effects of the tech levels, but I believe that will be easy compared to what we have already done.

Squares in a single province can now be radically different, so we cannot use average province infrastructure as a basis for RP calculations. However, the biggest problem is that if players can shift province borders, they can manipualate teh diminishing returns system to their advantage.

It will be easy enough to calculate RP's by square, although the CPU might not like it. Each square will now generate tagged RP's for every technology tag we include in the game. The number of RP's produced will depend on the activities and infrastructure in the square.

The biggest problem is creating a new diminishing returns system. The former province based diminishing returns plan gave very good results, but I believe it would be impractical to apply it to the squares. The computational load would be immense, and a very small variation in the diminishing returns number would have a huge impact on RP production. We must find a new plan for diminishing returns or RP production that ensures that a small civ with good infrastructure will do better than a large, underdeveloped civ.

Hey, don't worry, I don't take this as criticism at all. You can probably tell by now I'm one of those fiery types that loves a good, heated debate and I try never to take anything personally.

We're just hashing out ideas, here.

1) This thing about changing province borders is a good example of what I've been trying to say.

Upon analysis of the entire proposed game, there are a dozen things that will have to be done at the mapsquare level. Therefore all other systems will have to follow this pattern, for the sake of organization. Changing province borders is not the only one, or even the most important one.

2) Re: Spreadsheet prototyping . . .

Okay, this is a massively huge topic (what goes into programming a game?) but I'll try and be concise.

The single most important task in writing a program is to organize *all* the data the program will use.

Consider keeping data at your office. Without some sort of system (alphabetized files by company name, say) that data is going to be hard to use. You can just keep piles on your desk, which will work fine for you under many circumstances, as long as it isn't too much data, too many files. But that will not 'scale', so to speak -- there is no way you can expect someone else from another department (model, in our case) to efficiently use that raw data.

So when designing a program system like a tech system, the very first goal has got to be organizing that data. And this organization must fit into the organization system of the larger program (your files should be stored with the rest of the company files, so everyone can use them).

Now we have all that data availabe to all parts of the program.

Next we must make some decisions on when and where the data changes will take place, when changes are called for. In our game, this will happen in 'TurnHandler' classes. The structure of those classes is not yet set. I know of three ways to do them, and I'm not sure which will best suit our needs. Only testing all three will answer that question.

So after organizing the data and laying out the tech turnhandlers, *then* we come to the part of the design you're working on with your spreadsheet -- the 'business rules' (or, in our case, the 'game rules'). The specific calculations in that turnhandler code.

That's where your spreadsheet comes in.

But there's one small problem -- without doin the data organization first, you might make some major mistakes in assumptions of what data would be available. You might use data that won't be available, and you might fail to use data that *is* available because you didn't know it was there.

Which is what has happened, I believe.

As I've said before in another thread -- unless you've designed steps one and two (the 'data model' and the 'controller/middle-tier'), modelling with a spreadsheet is almost always going to lead you astray, and cause more harm than good.

So to sum up:

OOD is a 'filing' system for program objects. Ya'll were trying to build a massive data-driven system without ever 'filing' the data. In my experience, that is a doomed excersize.

3) What I try to do is analyze the data structure and then allow a system to develop from that, instead of the other way around. That always produces the cleanest, fastest system possible. I would indeed have mapsquares handle their own tech calculations.

There are many tricks we can use to get around the 'clock cycles' problem, so I wouldn't even worry about that. The rule is that "don't make changes in your design for performance purposes unless everything else fails".

In our case, with a turn-based system, there will be tons of time between turns to 'preprocess' the next turn's results. We save the game state at the beginning of a turn, then when a player issues orders like pouring money into research, or whatever, during his turn, we pre-compute the results *IMMEDIATELY*. While the player is taking the rest of his turn. In the background.

This trick, and others, should allow us to get as complex as we need to. If testing proves it's too slow, we can easily make changes at that point. More easily than we can now.

4) I'll go more into my specific ideas for a tech system, and go thru my OO analysis and design of that system, in a few weeks. I'm almost done with the social and govt code, so I'd like to put that out tonight or the next and have ya'll debug/flesh out the system. Economic class info, job info ('Social Classes' like 'Military Class' and 'Religious Class' are, in fact, profession data), and 'power structure' are now in the code. It doesn't save or load yet, that will be another night or two.

I can now control (actually, 'negotiate') a govt's policies. Ya'll should enjoy playing with this.

In essence I only need "ideologies", which are nothing but "govt types" (monarchy, democracy, etc). The exact list of ideologies is unimportant for the moment and you should imagine there will be around 20 of them. I've some ideas to determine how RP's are procuded to feed ideology-techs, but let's leave that discussion for some time in the future.

The government type techs can be done, but they might require a bit of tweaking. I'll outline the way they would be done under the current plan, so you will know if the procedure needs to be altered.

The tech level associated with a government would describe how well that government runs the country. So, a Level 60 Despotism might be better than a Level 30 Democracy. The tech level would increase as you gain more experience with that government type. Like any other tech you don't use, you would lose tech levels in government types you are not using. Helper techs would be things like Philosophy and Management.

This means that there could be big problems if you switched government types, even if the new type was "better." Your inexperience with the new government type (lower tech level) would offset the advantages of that new type. If your country was Communist with a tech level of 90 and you switched to Democracy with a tech level of 50, you would have some serious problems as the low level Democracy will not do as good as the high level Communism. This is exactly what happened in Russia.

The CTL you request is already a feature in the system. The Communication technology tag should work for what you need. We will also have technology tags for every other major civilization function.

The OTL should not be a problem to implement. I think we would have done it anyway for scoring purposes.

Thanks for putting up with my ravings, but I just can't help myself. I was born without a brain.

Actually, the beauty of this approach is that you don't have to change a thing. The more efficient 'behind the scenes' storage system should not affect how you analyze and model things.

The only suggestion I'd make to ease coding is to try and think in terms of designing 'components' -- low-level pieces that quickly and easily recalculate themselves when and only when necessary. Single-minded 'widgets'. Because that is by far the fastest, easiest way to code.

However, regarding govt types, I believe it's a model lead decision what the effect of the tech will be in the corresponding model. I really didn't expect to take the tech-model's definition for "govt type" and adapt the govt model to that. It goes IMO the other way around. I need govt types as techs the people can develop, but I have my own modeling for what the tech level means. I think your Russia example is good and so is the idea that having more experience with a govt type increases its effectiveness, but I don't want that to be something imposed I have to deal with like it or not.

I also hope the way RP's are produced to feed these techs is not fixed and "given".

roquijad:

I just noticed one of your posts in another thread asking me a question about why the tech system needs to be changed. I don't usually have time to read all of the threads, so I didn't see the question until now.

The main problem is the diminishing returns system fro RP generation. Everyone seemed to agree that we needed a diminishing returns system to prevent large civs from automatically developing much faster than small civs. The diminishing returns system I outlined is based on provinces.

This means that the player can alter RP generation simply by changing province borders. This gives a large incentive to micromanage those borders if they have the ability to do so. I had assumed that players would not normally have that ability.

A result of the square based economic system is that province borders can be changed more easily. This is fine for the economic model because the square based economic model cannot be manipulated by such border changes. This resistance to manipulation is a good thing. The technology model also needs that attribute.

-----

You appear to prefer the approach you used for the tech model, which has had a simple datamodel builder in development (a weekend's worth of coding) for what, 6 months now? Not debugged, no feedback from others yet to determine if it's even what everyone wants. No 'implementation'/controller code. Just a simple data model, being done completely behind closed doors. Not 'open' dev at all. NO teamwork. That is *not* the kind of dev group I want to work with.

Man, am I mistaken?

Because I thought I *had* proved my point in code. I gave you results. The builder gui needs work, but the game code is there. It works. It's smaller than what you had. It's fast. If I haven't proven it to you, then what will it take? You saw me disagree with the tech builder approach. Then you saw me do a model much more complex in a week, instead of their 6+ months (and counting). That didn't prove anything?

I feel about hopeless, and ready to give up coding for ya'll again, Mark. I did so on the tech model, quietly. This time I'm trying to mention specifically what and why.

-----

In the interests of open communication, I would like to discuss this issue and hopefully resolve it before it causes any more problems.

It seems that there are several criticisms of our work:

Design Speed: Yes, we did take a long time. Most of that time was spent deciding upon the guiding principles and high level plans for the tech model. A lot of disagreements had to be resolved because we were working as a team and not unilaterally deciding things. It took a lot of time to get input from the entire Clash team and then incorporate into later versions of the model.

It is true that the result of our work can be coded in a few days. It only took me a few days to make the technology spreadsheets that model the tech system. Perhaps that is because we spent so much time making sure that the system relied on simple mathematical equations that would be easy to code.

Is it a general consensus that I have been too slow or lazy?

Project Cooperation: I don't understand why our design work was characterized as secret and uncooperative. Everything since the first draft has been posted on the forum. We have spent months incorporating suggestions from other Clash team members until we had a system that satisfied almost everybody. Almost everyone involved with the Clash project reviewed the tech system and posted comments on the forum.

F_Smith, I understand why you thought you were being ignored. You wanted a return to the Civ 2 tech system and we did not take that route. Although I now understand that your OO programming criticisms were legitimate, at the time I thought they were simply excuses to go back to the Civ 2 tech system. I apologise for the miscommunication.

Is there anything else I have done that makes people think I have been too secretive?

Coding: I did not know that F_Smith ever offered to code the tech model. I thought that the coder was Garth Blore. Maybe this explains why Garth hasn't coded the system yet even though we sent him the final coding plans over four months ago.

I don't understand the comments about the tech builder. I was the one who proposed the use of such a utility, and I don't remember anyone opposing that plan.

First, let me back off the shrill tone I struck in those posts. The difficulties in getting modern OO programming adopted was creating serious tension, and I wasn't as careful with my words as I should have been. This has been a clash of cultures, with my emphasis on a 'modern' (what has been come to be called 'Extreme Programming' or 'Rapid Software Development') approach -- the 'Bazarre' approach -- with the old 'Queen Bee/Worker Bee' corporate approach -- the 'Cathedral' approach.

However, I do still feel the substance of my comments were correct. I'd like to (politely) discuss them, if ya'll are interested.

1) Design Speed -- OO programming relies in large part on a concept called 'prototyping'. The biggest mistake a project can make is building a huge design doc after a long, drawn-out analysis phase. The preferred approach now is to give your coders a basic idea of the core features a system will have, then have them build a prototype. Then the analysis phase begins, as the 'clients' (ya'll) look at the prototype and critique it. The approach is analagous to sculpting a statue out of stone -- you hammer out a rough shape first, then slowly begin to fill in details. There are many benefits to this, but most imporant are accuracy and speed. It can take 6+ months to do the analysis/design phase. I can code a prototype in a week. A critique iteration takes about a week. In a month or two, we can be fully designed, coded and debugged.

The lengthy design/analysis phase only gets you a 'theory' doc that will have to be actually still have to have an OO design done before coding can begin. As I said, your approach can *not* be coded in a short period of time, because any OO design will have to change significant portions of what your design doc specified, which will mean more meetings, and more decisions, etc. In my experience, this design doc is actually 6+ months of wasted time.

2) Slow or lazy? NO. Absolutely not. You're the victim of a bad system. Is the craftsman trying to sell hand-carved pencils slow, or lazy? No. You just need to modernize your system.

3) Project Cooperation -- The problem I have here is that the model leads are actually writing the models themselves behind closed doors, and then after the model is done showing it to people for feedback.

I feel that the model leads should have been 'secretaries', who gather all the suggestions into 'requirements' lists for the prototype programmers. That the model 'designers' should instead work hand-in-fist with the programmers from day one.

Because I see a large amount of 'ownership' here, preventing model improvement. One of the biggest innovation killers is people's 'ownership' of ideas/proposals. When new innovations are discovered, the 'owners' reject the innovation because it would change 'their baby'. One of the basic design principles is 'plan to throw (at least) one away'. The models should stay very flexible, changing this, tweaking that, even down to the very core of the design. A programmer naturally works this way, we don't have a choice. Requirements *always* change. Designers have to be the same.

4) That, I think, is why ya'll misunderstood my arguments that the techs had to be in an object hierarchy (otherwise known as a 'tech tree'). I personally am still pretty certain that they will end up that way, even if only behind the scenes -- because all those techs must be filed. From what I understand, you still have 'prerequisite' and 'derived' techs (a 'tech tree'), even tho you don't actually call them that (you call them 'levels' and 'helper techs', I believe). I could be wrong, tho. I will wait and see what ya'll come up with, when you begin to do the actual design for the tech system for the first prototype.

5) I offered to help with coding, about a year and a half ago. Then I tried, over a long period of time, to help do the real code design for several models. I was repeatedly told to cut it out, as the model 'owners' repeatedly rejected any changes to their 'theoretical' designs.

So I doubt that had anything to do with Garth.

One strong possibility is that he is having to do the actual (code) design from scratch, and is running into places where your model doesn't easily translate into good coding practices. Maybe not, but having tried to code from 'design' docs before, that is what happened to me every time.

6) And the only comment I have about a tech builder is that if the 'design' is well done, the builder should take about a week to complete. If it takes longer than that, it's probably because the design was not done correctly. As I said elsewhere, doing things in a spreadsheet actually can be a major detriment to design -- since the spreadsheet is so self-contained and does not need any type of object model.

I could write ya'll a tech builder in a weekend, if you'd like, but first I'd have to do the design (see the threads on the OO design for the social and govt models for examples of what I'm talking about). In doing so, I'd have to change a few of the core assumptions you have made (we've already had that discussion, you know -- you disagree strongly with my OO analysis of your tech system).

Anyway, I am sorry if I sounded too rude in that other post. It was just that I felt like non-programmers were over-riding me on how to design a software engine, and their advice went contrary to all my experience.

You are making a serious mistake, and that is your ridiculous habit of referring to "programmer" in the plural As far as I can tell, we only have three programmers for the whole project. Each model only has one programmer, if that.

Thus the problem with the bazaar model: we don't have the programmers. LGJ and I knew that, so we thought we were doing everyone a favor by making a detailed design doc ourselves. We assumed that if our system was coherent, functional, and well documented then it would be easy to program. Obviously that was a mistake.

I understand your views on "owners" supressing innovation, but you have to believe me when I say that the model leads usually have a good idea of what can fit in and what will not. Sometimes those innovations would have the effect of destroying the entire system and forcing everyone to go back to square one. If someone changes the foundation of the model, they can easily destroy the entire thing and force the thing to be rebuilt form scratch. This would waste time and could ultimately prevent the project from going anywhere. Some things just have to be set in stone, for better or for worse.

I have started reading "Thinking in Java" and now have a rudimentary understanding of the program structure. I will try to design object oriented models from now on; I have been designing blindly for too long now and that has to change.

From what I have read so far, it seems like technology as we have defined it is a perfectly valid object class. Each technology is a discrete object that stores data about itself and operates on itself and other things. You can add and subtract them from the system more or less at will and they all use the same handles. The basic tech structure is a Base Class, and the Tiers and specialized techs are Derived Classes.

The techs work with the rest of the game using the Technology Tag class of objects. The tech objects operate on the tech tag objects, and the tech tag objects operate on the objects in the other game models. I can see how there could be a bit of trouble defining some of the equations as object interactions, but we should be able to get it to work.

First to Richard, I don't think you did anything wrong, quite to the contrary. You've worked very hard on Clash and lots of people appreciate it! The issue with the lack of technology coding was not our methodology, it simply because Garth had several real-life events that shut down his coding completely. F. Smith, you are exactly right that it is a relatively small programming job to do the technology builder. It is only because Garth had previously done significant amounts of work in rearranging the existing code, and kept assuring me that he would return to programming relatively shortly, that things happened in the way they did. If anyone screwed up there, it was me, who made a poor judgment call.

I second Richard's statement. In the Absence of programmers, I believe they made serious progress! Y. M. M. V. And at least to my level of understanding of programming, I also agree with Richard that his model is completely suitable to object oriented programming. Will it have been designed perfectly? Probably not. I'm sure we'll find defects when it's coded up. As it goes for all the models.

F. Smith:

When you offered to do the code design for several models, it did not come attached to an offer to actually code them. Therefore, you were in effect just trying to draw up yet another design document that some other coder would have had to cope with when they actually did the work! That is why I wasn't particularly interested in hearing what you had to say about it. I'm not saying that in retrospect I did the right thing, only that those were my motivations at the time. As an example , let's take the tech model. You made suggestions, but at that point I was firmly convinced that Garth, who had done probably 40 or 50 hours of coding over the previous two months for the project, was going to program the whole model shortly. I thought it was Garth's call to make the decisions on how to properly assign classes in the model.

I would also like to repeat what Mark said -- you have done nothing wrong. I would only suggest a modernization of methodology.

Actually, I remember at least three other programmers over the last year and a half showing up and asking about 'architecture'. They were not answered at all, and left quietly. I tried to get one fellow from work involved a few weeks ago, and he read thru some of these discussions and decided I was nuts for pushing ya'll into OO -- he felt ya'll were so dead set against it there was no point in any OO programmer like him getting involved.

I, unfortunately, love to be out there on the bleeding edge.

Mark:

Perhaps this is partly a miscommunication problem -- when programmers like myself offer to work on architecture, and when other programmers ask about architecture, we're actually talking about the first stage of programming the game. That is not a 'design doc', that is actual code.

Ya'll have consistently disregarded talk about architecture and OO design in favor of 'design doc' and 'model' talk. Most programmers who have experience with design docs will consider those nothing but management overhead that will bear little resemblance to the final product we code.

So ignoring object design and architecture talk/requests is turning down coding help.

Ya'll:

Yes, a 'tech' object is a good start. Ya'll actually told me 'no' on that, once upon a time.

This is the beginning of a 'tech' system object design. It has to start there.

Well, live and learn. (Its much better than the alternative )

These three coders that we ignored... can you point them out to me when you come across them? I searched under 'architecture' and didn't find anyone that isn't currently on the project.

Diminishing Returns...

Well I guess the mood was unfriendly so sorry, though i don't regret what i did...i never regret anything.

Anyway as far as a 'tree' structure you say, not really....a 'tree' refers to branches that come out of one main stem and continue into smaller ones. That's not what the tech model is....basic technologies yes (with a few crossovers maybe), but the application techs aren't like that. They have requirements, but these requirements don't nes limit similar application techs that seem more advanced such as bronze working and iron working. You need certain metals and without them, you can't do reasearch on one type, but it doesn't stop you from the other, but might hinder it.

Also there are some things that we have that still need to be in there for balancing issues and other stuff....how its done doesn't matter, if the user sees the same thing using one coding method as another that's okay. And if some things need to be changed, yea that's fine too, but the fundimental building blocks are there because they need to be in order for the system to function properly. You say you're familar with the tech model so you should know what most of those are.

I wouldn't say 'unfriendly'. I'd just say receptive. I always felt like ya'll were being very polite and friendly.

Mark:

I will look for their posts. We might be able to woo them into this, now that we can show them the design stuff. I seem to remember the name 'Stephan Deadelus' or something like that, too -- I can't remember why/where he went, but he was another one of those coders that we might be able to get back.

All:

Let's see. We have a base 'tech' object. Then it seems like the 'application' tech needs to be a seperate object, agreed?

Japan isn't Small. Its GDP is about 70% of the US's! Its population is about half of the US. I think produced amount (using GDP as a proxy) is a better basis for RPs than raw population, although I guess we need to discuss that... Japan should keep up very nicely, especially when tech difusion takes hold. Anyway, like I said, IMO the other things need to be figured out Before we discuss diminshing returns in RPs. Otherwise we will have no idea where we Really need the diminishing returns.

F_Smith:

S_D Is working on the project... see my note in the other thread. Please remember I do a lot of stuff by email that doesn't ever get seen here. I try to encourage programmers to discuss things here, but by and large they don't seem to like to... with a few clear exceptions of course

I'm reproducing here a short talk between LGJ and I via e-mail regarding ideologies in the tech system. Just for the record.

LGJ:"Can you explain what you mean by government types in the tech model? Also a better explanation of ideologies would be nice."

roquijad:"Ideologies and govt types are essentially the same thing. A description of how the govt should be. [...] The tech level of an ideology should represent popular knowledge about it. Know it and understand it. If the tech level is low (10%, FE) we'd say it's only a vague idea a few philosophers have. When it's like 60% then we say some people know it very good and know how to implement it, but still there's a lot of people who don't know it well or don't know it at all. At levels of 90% we'd say it's well known by population. To know an ideology of course doesn't mean to like it. It doesn't either mean how effective its implementation would be. I believe all govt forms implemented for the first time in a country are less effective than they could be. This is a nice effect I didn't consider in my model and now I'd like to add, but I don't want this feature to be managed by the tech level, but by actual usage by the civ (i.e. in the govt model)."

It's not ness for you to discuss the above. Only if you feel there's something very wrong, of course. I'm just putting it so you and LGJ have the same info.

One question I have is how "standard" is RP production. Are all techs fed equally based, FE, on econ model's variables? Is it possible to design a specific RP production equation for ideologies?

Now, on a totally different topic, I didn't know about the diminishing returns for RP's. I never knew about such discussion and I'm probably saying something that has already been said, but if it's not yet settled, I'd prefer no dim. returns. I can't help giving arguments against dim. returns, so excuse me if I'm resurrecting a dead discussion...

IMO the dim. returns approach assumes creativity depends a lot in local govt's administration capacity. If I expand a province geographically, what only happens is the local govt now has to administrate more land. The govt can indeed be less efficient/effective because of this, but the question is why creativity would be affected too. This would only happen if the local govt has a big role in producing innovation. Of course the govt has a big role in terms of defining the degree of liberties and the economic system used, but that's irrelevant in this analysis because geographic expansion doesn't imply changes in policies. Geographic expansion only affects the govt's administration capacity, like being able to manage the sewer systems of the new towns added, FE. If, within this administration, we consider things like handling public funds for scientific research, then we can consider RP production affected by a less effective local govt given by the geographic expansion. So, IMO, RP production should not work with diminishing returns, but with constant returns. If the govt spends money for sci research (money converted to RP's directly somehow), we can penalize that according to local govt's effectiveness. This effectiveness should IMO be an input from the econ/govt models.

As I feared, there might be some problems with your approach to the government techs. The tech system is not designed to handle "popular knowledge"; IMO that is something that is better handled by the social model. Our ideas of RP production and tech levels and implementation assume that high tech levels mean something is getting more effective.

But I think we can resolve this. For a while now we have been thinking of creating a different system for social techs. The plan for the ideology tech confirms this need. The social tech system would use a new type of RP produced mainly by the social model rather than the economic model.

A new social tech plan based on popular knowledge and/or approval could be a valuable addition to the game. There are many social technologies that would use exactly the same system.

Actually, the ideologies could have two tech levels. The social tech level describes knowledge and popularity as you desctibed, while the normal tech level describes the actual efficiency and effectiveness of the government type. So, you could have a popular ideology that doesn't manage the country well or vice versa.

We have to decide who will be developing this system. We agreed earlier that I would do military and LGJ would do the social stuff, but if you want me to do some of this that would be okay. Of course, we would have to work closely with someone working on the social model. Rodrigo is the obvious choice here. LGJ and Rodrigo, would you two like to work on the new system?

Diminishing Returns:

These are designed to represent duplicated effort. RP's represent new ideas or improvements to current practices. But what happens if the ideas are the same? If two farmers might generate RP's representing new ideas but their ideas are the same, the civ should not get twice as many RP's. The idea only happened once, so the extra RP's are duplicated effort and are therefore lost.

The idea was to implement diminishing returns based on the communication within the civ. If there is not much communication, there is a bigger chance of duplicated effort and RP wasting. If there is not much communication, then the people in the 20th province are not likely to have many ideas that the people in the first through 19th provinces have not already had. This means that their ideas are redundant and their RP contribution would be very low.

We can no longer use provinces for these diminishing returns, so we have to figure out how to implement a similar thing for square based RP production. It doesn't necessarily have to be diminishing returns, but it should have the effect of negating redundant RP production.

GDP:

I am with Rodrigo, I think the effect of diminishing returns can actually be very small under the right circumstances. Richard, I agree with your statement that ideas will be duplicated the more people there are working in a given area. But progress in technology is Not just about idea generation! Idea generation is only the very first step in pushing technology forward. Idea generation probably was not the most difficult part of technological progress during most of history. The value the society places on innovation, and the receptivity with which an innovation is greeted, are IMO much more important.

What I think is valuable is having different systems for RP production depending on the particular techs. I support the idea of taking inputs for RP's equations from the econ model for the majority of techs, but I think other techs would be better modeled if RP's they receive come from other calculations. Military techs might receive RP's from the number of battles in a game turn, FE. Having a special RP production system for ideologies would be nice in this line of thought.

As for diminishing returns, you have a very good point when you talk about duplicated effort. I didn't see that. However, I feel the best way to introduce dup-eff is at the civ level instead of province level. If, FE, I have a civ with a single province and the level of dup-eff is X and then I decide to split my province into two, then I'd expect the total dup-eff level in the civ to stay being X. It's the same people and with the same communication techs as before, so if something was being developed simultneously in two towns, it will remain that way with new political division. My suggestion would be to take RP's produced in all provinces (without diminishing returns at that level) and then penalize the total to introduce the effect of dup-eff.

Small innovations and improvements can also be duplicated. If farmer X does something that makes his plow harness go 10% faster and farmer Y on the other edge of the civ does exactly the same thing independently, then their effort is duplicated and some RP is lost. They couldn't communicate, so their work was redundant. If there was a good communication system, then they could work together and make the plow 20% faster. For this reason, we should include the option of a diminishing rteturns system based on communication.

roquijad: There is still a need for a social tech system. Would you like to work on that? It would give you a chance to make a social tech system that fits your needs.

While normal science and engineering stuff is designed to keep advancing, social techs can bounce up and down. A certain social tech can be high in a bronze age society and very low in a modern society.

It is entirely possible that these should be handled by the social model. We assumed we would do them because they are part of the "tech tree" in other civ games, but other civ games don't have a good social model like we do. When we first started working, Clash didn't have the social model it does now, so our earlier assumptions may not be valid now. Some things we were calling techs might be batter handled as social characteristics.