 |
| |
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
There wasn't any real debate about this topic. The current system was simply introduced and we all thought it was good.
Mark: Enjoy your vacation. I'll be going next week, so the spreadsheet will probably be the last thing I do for a while.
LGJ (and anyone else who is interested): Could you use the spreadsheet to test the system while we are gone? I mean really test it; try to crash the thing by manipulating RP's, tech attributes and constants, and default settings. When I get back, I want to know about anything that gives odd results. And if it survives a month of this testing, I'd say it should do pretty well.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
While building the spreadsheet, I found a couple things that need to be changed. Previously, H and I only affected the excess RP's, the ones not needed for tech upkeep. I found that this can create problems. The marginal tech gain per RP will change a lot at the point where the tech change is zero. This creates instability, so I changed the equations so H and I affect all RP's produced. Tech growth is a lot more smooth now.
Also, I needed to introduce a change in the naming system. Previously there were two things that were called Levels. The most common use referred to the tech level that changed based on RP input. However, a tech's place in the 3-layer tech hierarchy was also called its level, as in "Level 2 Technology." To avoid confucion, the tech's place in the hierarchy will now be called Tier, as in "Tier 2 Technology."
I sent the new spreadsheets and their instructions to Kull to be posted on the Clash web site.
|
|
| |
|
|
|
Stuff2
|
|
I was reading a book about technological history today and some things did come to my mind.
One is that the 'research' has in some periods been concentrated in mysticizm and religion and stuff like that and in other periods of time concentrating on the actual reality.
It was also clear that when empires was getting bigger they also often got more decadant. Decadance in science had several reasons.
1. Slavery
There has in history been a big connection between slavery and lack of scientific research. Mainly beacouse you don't have to develop industrial techs as long as you have slaves, and slaves work better the less they know.
2. Economic system
It was first in the european renasissance when the economic system got more and more capitalistic the scientific research started to get a real boost.
3. Power.
Priest and aristocrats was concentrating on keeping the lower classes surpressed and a way to do that was to hold on to a conception of the world that justified their power.
4. convinience.
When the higher classes was satisfied with their lives noone was interested in research, except the poor people that was to uneducated and to hardworking to care about stuff like that.
One other thing that was striking was how big civilizations not only beacome decadant they also became more concentrating on keeping their own population content rather than improve their weaponry. Nomadic barbarians on the other hand was almost totally concentrating on military improvement and time after time took over the power of their bigger but military weaker neighbours. Then these 'barbarians' eventually became big decadent civilizations that within some centuries was eithier falling apart in smaller nations or overrun bye barbarians. (usually both).
Considering this I really do think that big civilization (atleast before living in a capitalistic economy) should get scientific penalties in some form.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Stuff2: I agree with all of your points, but I do not agree that research penalties should simply be assigned based on size. A small civ can be just as decadent as a big one and size does not automatically lead to decay.
All of the things that you mentioned are covered to some extent in the social model. The attitudes of the various social classes will have an impact on research. Decadence in the civ will affect research as well as many other civ activities.
I agree that excessive size should be punished, especially if the size is due to conquest. But I do not agree that the tech model is the proper model to punish this size. The social and riot models should be the places where size is punished. Rather than assigning arbitrary research penalties, we should go to the source of the issue and work in the social model.
Also, don't forget that our diminishing returns system of province RP generation gives very little benefit to huge civs. If you look at my post near the top of the thread, you will see that a small civ with good infrastructure will produce more RP's than a large civ with bad infrastructure.
I am not especially familiar with the guts of the social model. Stuff2, if you know both models it would be great if you could make a proposal for the details of the interaction of the social and tech models. That way you can make sure that these issues and many others are dealt with as seamlessly as possible.
|
|
| |
|
|
|
Lord God Jinnai
|
 |
St. Louis
Sep 1999
time: 23:13
|
|
Cont from other thread:
quote:
The idea I like is that the individuals in each square do their own 'tech' advancement and innovation. The player wouldn't 'spend' RPs, but instead build/fund research centers that would innovate on their own. Then tech can spread like a 'disease', and farmers/producers (depending on available resources) would adapt to and use the newest tech they know about. So tech would 'spread' out from 'innovative' areas.
Certain ethnic groups can be more 'innovative', as a cultural trait. Increasing the amount of 'education infrastructure' in a mapsquare would increase the innovation of those people. Etc.
|
You're idea has one very major flaw in it. This isn't how tech works for most of history. Rulers didn't fund research centers or the like. They might have things researched, but generally that would be at the capitol or other major city, usually outside his control. The effects were very targeted, FE a new weapon. Once that occured, research was shut down.
As to the spreading, it doesn't work like that generally. First off, cities will learn of it and use most technology before rural areas, usually learning via merchants. Second, military tech cannot be handled this way since once a new technology is found that wants to be incorperated the local ruler will attempt to fit all his troops with this new technology. The same holds true for many ideas, only limited to the econimics and practicality.
Also you weren't looking at what I was saying i think. RP production doesn't care for specific areas usually. Also it must all be recalculated every turn. This is why its better to get all the numbers for a general area than each mapsquare because RP production is based on virtually everything done in an civ, ie farming adds more agricultureal/farming RPs, building road between to cities add Transportation/Land RP and Communication RP as well as maybe Economic RP, building and training troops adds many differnt types depending on the actual RP. A lot of this can't be handled at the mapsquare level either.
As to ethnic groups innovation level, increasing it may help, then again it may not. This also depends on IoR and its innovation level for the people and also if they distrust government and generally very low innovation groups it will have no/min effect on because they keep their kids away or teach them outside schools differntly.
quote:
One other thing:
(quote)
The thing is, atleast in my view, the Tech model doesn't handle that. It handles on the development of technologies, basic and application. Its up to the other models to see how they are used, for farmers its up to the economic model.
(endquote)
I couldn't disagree more.
You may remember my vocal disagreement on this topic.
A basic definition of techs is actually similar to the basic definition of various ethnic groups, or religions, a civs, or rulers (like in the beast). That is not a system. That is actually a function of scenario designers.
For example, scenario designers can add their own 'techs', can't they? Like a 'fire magic' tech? Granted, we can pre-define a bunch of techs to ease the job of scenario designers, but that is not the same thing as doing work on the model.
A tech 'system' will have to define how techs interact with the other code. How will the increase of a farming tech cause the farming code to increase farm output? Until you've decided upon the specifics of how things will be implemented (clearly the hardest part), the tech system won't be 'done'. Until I finish the 'turn' methods for the object builder beast, I am not done with the Population and Government models. Likewise for the tech model.
|
Don't exactly remember that disagreement...just that you thought it should be programed in OO...
I don't exactly understand what you mean by "basic definition of techs." Yea application techs can be created by scenerio designers, though i don't know about basic technologies, atleast not completely new branches, maybe sub-branches.
Can you explain yourself again why its so wrong, espically in light of what i just said earlier?
Also i don't know about "fire-magic" tech...
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Lordy:
Please realize, this is just my opinion. I understand if you disagree with me.
From my standpoint, I intend to eventually (this is not a top priority, it'll be at least a month before I can get to it) code up an alternate tech system that spreads tech based upon lines of communication. The RPs will be in individual mapsquares, possibly even by individual ethnic groups. Everything those EGs take part in, they will have a chance for innovating a better way (based upon all sorts of factors, of course, including their access to education and entertainment, the % of the rewards that will be theirs -- the 'private property' govt policy, and a lot of other factors. If a mapsquare will check all mapsquares it has contact with, and try to adopt any tech that they find that they want/need, based upon a million factors. The leader will be able to influence this spread in several ways, including by financing a 'research' place (temple/craftsman shop/forge/university/whatever). You could build 'Stonehenge' and get a boost in astronomy tech. That kind of thing. As far as providing techs to soldiers, that's an economic question of buying and supplying weaponry. I believe that is how it worked/works.
And as I said, this is only going to be an option. Yours will be the default tech system.
* * *
Also,
However ya'll end up coding the tech will be fine, I'm sure.
The only point I'm really going to make now about coding is that just remember, 'the developers aren't done until all the tests run'. The coding of the model isn't done until you can watch a tech change cause a value change in exactly the way ya'll want it to act.
* * *
I'm sorry, I was assuming that this tech system will be able to be customized to include magic 'techs', futuristic 'techs', and user-defined 'techs'. I may be mistaken.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
F_Smith: I think I know what you want, and I think the current system already provides it. Here is what I think you are saying:
1) People should do research themselves, and they should work on what they need and what they are good at. The ideas they come up with are then spread to the rest of the civilization.
2) RP generation should depend on communication.
3) The tech system should interact with other models to define how tech levels are used.
We have already dealt with number one with the plan for "tagged RP's." The basic idea is that every activity within the civ generates RP's that are used only for techs related to that activity. So a farming province generates lots of RP's that are used to advance farming techs. The current model assumes that all provinces are doing this simultaneously, so at the end of the turn all of the RP's are combined (after a diminishing returns system that simulates duplicated effort) and the civilization's tech levels are adjusted.
We do not have a detailed plan for RP production. But we have agreed on the following principles:
An RP is anything that would serve to improve something that the civ is doing. They are generated by research or basic activities, which represents innovation within the civ. They also can be generated by contact with other civs, which represents acquiring knowledge from others.
RP's are not a commodity that can be stored. They are generated anew every turn, and all RP's that are generated are spent the same turn.
The effects of communication within the civ are dealt with after RP's are generated. Some research and innovation efforts are duplicated, so the RP's are essentially lost. For more details on this, look at the diminishing returns discussion above.
Speaking of duplicated effort, I don't think we need to work on competing tech systems. New suggestions can be and have been incorporated into our system. We can still be flexible, so if you suggest improvements to the current model we will consider them.
Your ideas are seem mostly centered on RP production, so could you make an RP production model that fits with the current system? This would allow you to include your ideas in the system without changing or redoing the whole thing.
I think that the tech model should work to define the use, application, and effect of technologies. Tagged RP's are used for the interface between the tech model and the other models. This page has discussion about the uses of tagged RP's, and so does the previous thread.
If my assumptions about you believe are wrong, please let me know.
By the way, have you looked at the tech system spreadsheets I made? I think that they would help you understand the system better and give you a chance to test out the system and see if it works as it should.
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Richard:
Actually, it's very healthy for this game to develop several different versions of each game model and then including them as options. Don't worry about wasted effort, my approach will only take about a month to do something like techs.
While we are after systems that do similar things, the radical difference in our approaches has produced radically different systems that will play quite differently. I see this as a bonus to game players.
There is one basic difference -- different mapsquares can have different levels of techs, even within the same Province/Civ. My approach will have pockets of innovation, and tech will spread/diffuse out from there. Ya'lls approach, I believe, assumes all members of a civ have the same tech level.
I like the idea that in a province, the city dwellers might be significantly more technologically advanced than the provincials.
Research and innovation will happen in specific places, in my approach, not on a 'civ-wide' macro level. You can build a highly sophisticated urban 'Rome' type city, and still have far-flung provinces that are far from 'modern'. This, to me, sounds fun.
I believe I understand your tech system very well. It works well, from a 'big-picture' approach, altho it is not really based in a mapsquare world. I just have taken a different approach, and 'localized' things.
|
|
| |
|
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:13
|
|
Hi Gentlemen:
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:
I don't think there would be anything stopping us from tacking on that sort of thing at a future date. Right now, though, we don't even know for sure if the basics of the system work, so it seems premature to talk extensively about this.
|
|
| |
|
|
|
Illmuri
|
|
Idle thoughts:
-
I know its a bit old by now, but what was decided on roads helping tech etc? If you dont want them to just make road after road and abuse it, have it find the max amount of RP to take in, then shave off a % from certain areas if they dont have good communication (roads, etc). Building roads just gets you back to full, but after that you just have infrastructure in place doing nothing but givin your troops somethin to do (a useful tactic in peacetimes, but that last bit on troops is just rambling).
-
Oh my, go axi go! Axi is a role model to all. Good job!
-
Well, I had more ideas, but I actually went through and read the threads, answering questions etc. Most ideas have been forgotten by now *doh*
-
Im not sure about small civs and big civs and how many RPs they get, but civs that fall behind should get a bonus. That post on comunication with another civ and proximity etc was right on. If someone has more tech, being close to them should up you RP collection (suppose its just from the fact that you have an idea what you want to learn, and work towards it, much faster than accidently findin it).
-
Ive seen a lot on not everyone adding to reasearch because of communication, but what about the other way? I mean, unlike civ, where you find "computers" and bam, everyone knows it, it took time for computers to be in "every" home etc. So if it fits somehow (this is just a rough idea, and not tailored to this specific game), maybe they find something new, levels go up, whatever, and over time, the benefits from it could go up, depending on other things (I sure use too many commas). Like having a nation that has many good horsemen (Mongols), they didnt start that way, over many years though, the horses helped cause they used it.
-
Hmm, most of these thoughts arent really thought out, I have the bad habit of making things up as fast as I type.
-
That fits in on that little post on people with better cavalry than others, I suppose you could implement this if you can think of a way.
-
Im not a programmer, and Im just a little kid in high school, so I dont have years of studying history etc that would really help me on making intelligent contribution.
-
I hope I havent just wasted your time on this, and maybe some little detail hasnt been suggested (I havent quite read all on tech, going to next).
[This message has been edited by Illmuri (edited August 05, 2000).]
|
|
| |
|
|
|
Lord God Jinnai
|
|
St. Louis
Sep 1999
time: 23:13
|
|
quote:
Originally posted by Illmuri on 08-05-2000 07:19 PMI know its a bit old by now, but what was decided on roads helping tech etc? If you dont want them to just make road after road and abuse it, have it find the max amount of RP to take in, then shave off a % from certain areas if they dont have good communication (roads, etc). Building roads just gets you back to full, but after that you just have infrastructure in place doing nothing but givin your troops somethin to do (a useful tactic in peacetimes, but that last bit on troops is just rambling).
|
The way roads will help the tech system is to increase rp production because of better communication and transporation from point to point, mainly cities and other strategic locations. That means you can go out and build all the roads you want, affecting the enviorment in a negative way and do sh*t after you got the best routes to and from each place taken care of, but hey, no ones stopping you!
quote:
Originally posted by Illmuri on 08-05-2000 07:19 PMWell, I had more ideas, but I actually went through and read the threads, answering questions etc. Most ideas have been forgotten by now *doh*
|
Yeah, hate when that happens...Anyway no rush. I doubt we'll have a breakthru tommorrow, maybe the next day though 
quote:
Originally posted by Illmuri on 08-05-2000 07:19 PMIm not sure about small civs and big civs and how many RPs they get, but civs that fall behind should get a bonus. That post on comunication with another civ and proximity etc was right on. If someone has more tech, being close to them should up you RP collection (suppose its just from the fact that you have an idea what you want to learn, and work towards it, much faster than accidently findin it).
|
If you mean it should because of communication and the eventual spread of technology, yea that's already taken care of. However, just because 1 civ is seen as more advanced doesn't ness. make the lower-tech civ want to spend more on its advancements...this depends on the ethnic/religious modifiers as well as politics.
quote:
Originally posted by Illmuri on 08-05-2000 07:19 PMIve seen a lot on not everyone adding to reasearch because of communication, but what about the other way? I mean, unlike civ, where you find "computers" and bam, everyone knows it, it took time for computers to be in "every" home etc. So if it fits somehow (this is just a rough idea, and not tailored to this specific game), maybe they find something new, levels go up, whatever, and over time, the benefits from it could go up, depending on other things (I sure use too many commas). Like having a nation that has many good horsemen (Mongols), they didnt start that way, over many years though, the horses helped cause they used it.
|
Already taken care of...or well atleast we plan to. I believe it has though.
quote]Originally posted by Illmuri on 08-05-2000 07:19 PMIm not a programmer, and Im just a little kid in high school, so I dont have years of studying history etc that would really help me on making intelligent contribution.[/quote]Everyone's welcome to express there opions. All we ask is read the models and current discussion so you know what's going on.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
F_Smith: The tech level indicated by the technology model is not meant to represent the infrastructure or systems in place in a province. Rather, it represents the best knowledge available to the civ. Certain provinces can have an actual tech level A that is different from the ideal tech level T. A approaches T as more capital is invested in the province, and if there is no investment the province will fall behind the rest of the civ. This is handled in Mark's economic model; you can look in the economic thread for more information.
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.
LGJ: We could easily have guilds and corporations do research on their own. I believe we already have plans for dealing with such entities, and having them sell technology would be a great addition. Mark is right, however: we should worry about such bells and whistles later.
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Richard:
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.
I just have a different approach, that will turn out a different product. And since one of the biggest strengths of using a 'component' architecture like we are is that you can easily 'plug and play' different versions of a system (that 'flexibility' that ya'll are wanting so badly).
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
F_Smith: I am not trying to criticise you; I ask this because I want to learn: What is the difference between the current system and what you want, and why would the current system be hard to program?
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.
I can e-mail you the spreadsheets. Could you look at them and then tell my why it would be so hard to make Java code that did the same thing?
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Changes in the economy model have forced us to change the technology model. The economy model is now being run at the mapsquare level and the player will have the ability to shift province borders at will. This means that we can no longer use a RP production and diminishing returns system based on provinces.
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.
F_Smith: This is your opportunity. Your ideas now have a very good chance of being put in the main tech system. I haven't been able to come up with a good square based RP plan, and you seem to have one. I don't understand exactly what you are planning to do, so could you explain it carefully so I can see if it can be included?
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Hi, Richard:
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.
One or two more nites . . . after that, I'll work in the 'tech' code.
|
|
| |
|
|
|
roquijad
|
|
Santiago
Nov 1999
time: 05:13
|
|
Since Richard has invited all model leads to present a list of the techs each model needs, here's mine for the govt model.
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.
What I also need from the tech model is a couple of measures (not techs). First, an Overall Tech Level (OTL), that would be a sort of average of all tech levels in order to know how advanced a civ is. Second, a Communications Tech Level (CTL), that would be a measure of how easy is for people to communicate and should be a sort of average of all techs related to transportation (railroad, sailing, etc) and communication (press, internet, etc).
[This message has been edited by roquijad (edited August 08, 2000).]
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Thank you for the explanation, F_Smith. It was very helpful; I finally understand why you have been bugging us for the past few months. So, as you look at the system, could you see if there is a way to salvage all of the work we have already done? I like the system a lot and almost everyone else does too.
Do you have any general principles I should keep in mind as I work on my other models? I want to make sure they can be coded easily.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Roquijad:
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.
I hope this helps. By the way, thank you for noticing and responding to the request thread.
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Richard:
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.
Lots of little pieces, instead of one big one. It'll always run more efficiently. And be easiliy modifiable.
|
|
| |
|
|
|
roquijad
|
|
Santiago
Nov 1999
time: 05:13
|
|
Thanks for the answers, Richard. I'm glad about what you say for CTL and OTL.
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
|
|
Santiago
Nov 1999
time: 05:13
|
|
double post!
[This message has been edited by roquijad (edited August 09, 2000).]
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
Mark:
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.
We do not have to change the whole model. We only need to change the system of RP generation. We need a good RP generation system that includes diminishing returns yet cannot be manipulated by shifting the province border.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:13
|
|
As I was perusing the Government - Economic models interconnections thread, I came across this quote fron F_Smith:
-----
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.
I don't want to cause any more problems like this, so could someone please tell me what I have been doing wrong?
|
|
| |
|
|
|
F_Smith
|
|
Austin, Tx 78728
May 1999
time: 05:13
|
|
Richard:
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.
Forgive me?
|
|
| |
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
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
|
|
|
|
|
|
22-06-2000 05:05
|