Technology System Version 5.2

[Richard Bruns]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

double post!
[This message has been edited by roquijad (edited August 09, 2000).]

[Richard Bruns]

Nooooo!



roquijad:

I never meant to ask you to change anything. I thought I made it clear that I was offering to alter the tech system procedure to suit what you wanted. But I just realised that it looked like I was asking you to alter something. That was purely a fault of my communication skills; I never meant for you to change the government model according to my whims. I was outlining the current technology system so you would know if you needed to change it to suit the government model.

[Richard Bruns]

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]

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]

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?