10-03-2001 04:37									#31
	Suffering from ads?

Richard:

Cool, we'll try the XML for now, if it doesn't work out, I'll do that tech builder. I'll send you a sample file soon.

I think many players will actually want to see the tag strength that goes into various things. Of course, I could be wrong. But given the amount of micromanagement people are willing to put into Civ...

I still favor using the same scale for all technologies. Some players Will want to see a big readout of all the tech levels. I'm one of them . The reason is that a lot of the effect of the technology Web depends on achieving specific numbers. If I am racing for Gunpowder, I want to know how close I am! It's not historically accurate, but its IMO and important feature in 4X type games. I agree that the kind of more-realistic interface that you are looking for will appeal to many players. But I think there are also many who will want more details. I expect we'll need to do both. Anyway, playtesting and opinions from the public are needed to resolve this IMO.

Thanks for the info Laurent! That will indeed make the files easier to read. Have you got a parser that will read this kind of XML? Or do they all? Thanks also for the < > trick!

	10-03-2001 05:36									#32
	Remove this text

Quick OO Strategy, high-level

Two basic tech objects, Tech and Application.

Tech is split into three categories: Theory (level 1), Field (level 2) and Skill (level 3). For now there is really no distinction between these three levels, but I am keeping them separate for possible future use.

Applications really behave differently, so they're a unique object by themselves.

I am also going to have a TechInfo class that holds all the unchanging info about each tech (most of the info in the tech model is of this sort). This will give more efficient memory usage, and allow for easy changing of Tech characteristics on the fly during the game for testing. All the actual Theory etc. objects will have is a pointer to the TechInfo object, a level and whatever else is civ-specific. There will be an analagous ApplicationInfo object.

BTW don't we need applications to have a tag to feed back tech growth that comes from use? FE Muskets have a Military tag? I wanted way back to have each application also have an experience level associated with it, but was outvoted ...

[This message has been edited by Mark_Everson (edited March 09, 2001).]

	10-03-2001 20:00									#33
	Support Apolyton, buy Civilization III: Complete

Serious coding has started I don't have an XML parser yet, but hopefully will have one soon.

Are the required techs always going to be the same as the helpers?

Right now I have a container for each of required and helper techs, but if they're always the same then perhaps we just would need to add a 'required level' field to all the helpers. Though it may be safer just to leave the two types in to accomodate the occasional tech that is required but not a helper.

How about this. We unify Required techs and helpers. Helpers remain the same, but have a new value called 'required level'. Where there is a Req tech thats not a helper you can set h=0 and the 'helping' will have no effect regardless of the other parameters. Where there is a helper with no requirement you set Req level = 0. In lots of cases the helper is also a requirement and vice versa, and this will streamline things.

Whatcha think?

[This message has been edited by Mark_Everson (edited March 10, 2001).]

	11-03-2001 04:12									#34
	Increase Your PM Length

Here is some initial output for you just to look over. I have gone ahead and unified Required and Helper techs as I mentioned above. These are "TechSpecs" objects that are the Platonic ideal of Techs, so they don't show current level. The tech objects that are actually used are set up, but I havent got them in the diagnostic trace. Nothing does anything yet, but the data structures are set up, and the objects are on their way! Next step will be to set up a clone of the spreadsheet, and run the tests for that.

Techs Existing:

Tech: Agriculture, Level 2
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Helper: Biology, Weight 3, Offset 0, Level Required 0
Helper: Earth Sciences, Weight 2, Offset 0, Level Required 0
Tag: Agriculture Weight = 10

Tech: Biology, Level 1
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Tag: Pure Science Weight = 10

Tech: Earth Sciences, Level 1
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Tag: Pure Science Weight = 10


Richard: Is there a time its important for me to get the XML spec to you by considering your workload? I don't want to slow you down, but I'm not experienced with that stuff, and don't want to waste time either. I can get you something immediately if you want to get started, and don't mind potentially redoing a little bit of it in the future. If you wouldn't have much time to work on it in the near future anyway, then I'll definitely wait till like next weekend to get you someting.

-Mark

	11-03-2001 18:59									#35
	Got spare money?

I am on Spring break at home now, and will soon be going to a research conference, so I won't be able to do much until next week.

There isn't any problem with unifying the required and helper techs that I can see.

I think that we can and should give the players all the tech information they need without using lists of numbers. What should they know?

The civ's tech ability compared to the neighbors.
The ability compared to the past; how much has it improved?
How happy is the populace with the tech level?

These three can easily be displayed with icons, no numbers required. Theae are also things that any ruler could be expected to know. Other things players want to know are not things that real rulers would know, but are important to the game. Here is my idea for displaying this:

The amount the tech level changed since last turn can be displayed with a color-coded list; players do not need to know the actual tech levels:

Tech Change:
Agriculture: +.2
Architecture:+1.2
Astronomy: +.01
Biology: -.2


Clicking on a number in this list could bring up a line graph that shows the recent trends in the tech level. Upcoming developments, like a new application or technology, could be marked on this graph, so the player sees a pictorial representation of where the tech is, where it has been, where it is going, and how long it will take to get there. Note that this graph does no necessarily have to have the actual tceh level marked on it.

Mark, I'll send you a Excel file with an example for this spreadsheet.

Edit: Attempting to get colored text
[This message has been edited by Richard Bruns (edited March 11, 2001).]

	12-03-2001 03:34									#36
	Lose 30 kilos (of popups)

Thanks for the info! In terms of the final part of your interface suggestion, I think it's moving in the right direction, but isn't quite there yet. The thing that I have trouble with is what if the critical application I am going for requires more than one tech? Other than that, your proposal strikes me as fairly reasonable, although I haven't put a lot of thought into this... We're not really at the point where we need to decide on the final interface yet anyway. The interface is going to be crude for quite some time and hopefully we'll get some further ideas on a final interface during playtesting.

	12-03-2001 20:36									#37
	Support Apolyton buy from Amazon

We can put multiple graphs on one screen. The past progress, projection, and goals for a tech can all be the same color, and in this way we can put around half a dozen techs up on one chart. Or we can display techs in multiple charts and switch between the charts.

	13-03-2001 10:05									#38
	Support Apolyton, pre-order Civilization IV

That might work, but it sounds as bad as numbers at least to me...

On another topic. My coding has made me think about the helper tech level equation: RHL = (h1*(HT1n +O1-Tn) + . . . + hx*(HTxn +Ox-Tn))/(h1+ . . .hx). The problem I've just seen is that, because of the divisor, the following effects of a single helper tech are identical for the FratPranks Tech that helps the CowTipping tech:
h=1 FratPranks
h=5 FratPranks
h=10 FratPranks

All give the same resulting RHL = HT1n +O1-Tn

Also the following two helper tech systems are identical:
h=1 FratPranks
h=1 IntenseBoredom

h=10 FratPranks
h=10 IntenseBoredom

I know you can change W, or the Os to make these various equivalent things have different effects, but its not very intuitive.

I propose that we ditch the denominator in the formula above. That way a helper with an h=10 will directly have the intuitive result of being much stronger than one with h=2. We can rescale W if necessary because of this change.

It seems to me my proposal is more straightforward for players and scenario designers. Do you agree, or do you see problems with it, and if so what? I'll code it as-is for now, since its trivial to change it, and wait to see what you have to say.

	13-03-2001 21:00									#39
	Increase Your PM Length

Mark:

About your concerns for the graph proposal (in dealing with techs with multiplie requirements) Rich brought up in dealing with tech levels we could do something along the following:

Have the graph show when at current rate, an application will be discovered, when you'll meet the requirements for that particular tech level for it, if it will be earlier (kinda like a dashed line showing the exact date). You can click a button to see what other techs affect it and do the same for those that are required techs. For helper techs it may be a little more difficult.

Anyway this is also good for use with people that want just general knowledge on their tech levels and want to hear quick ideas such as "We're nearing a breakthough in physics, just a few more years!" or "We seem to be lagging in our biological research and its hampering other areas because of this."

	14-03-2001 08:04									#40
	Put an end to popups!

Yes, Mark, I agree with the point about the helper techs. . .

quote: Originally posted by Richard Bruns on 03-01-2000 10:45 AM As I did a final review of the system last night, I noticed a few things that might need to be changed. The first is the formula for the RHL. Dividing by the sum of the h values hurts the system IMO. Currently, it would be impossible to change the total effect that RP's have. If you assigned a h1 of 3 and a h2 of 6, the H factor would be exactly the same as if you assigned a h1 of 1 and a h2 of 2. Given the stated definition of h, I don't think that is a good thing. So I propose that we stop dividing by the h terms. This would make the H value larger, but that can be compensated for by changing the other variables. If it turns out that I am wrong, we can fix things so that the sum of h is one, and the system will act the way it currently does. Dividing by the values makes the system a lot less flexible; there is no way to alter the total effect that helper techs have.

	14-03-2001 08:14									#41
	Increase Your PM Length

Aw, dang! I suspected as much, since some of your equations had the divisor and others didn't. And also the spreadsheet didn't have a divisor. But I'd already written the thing before I twigged to that, so I figured I'd make sure...

	19-03-2001 04:02									#42
	Remove this text

Coding Status Update

A new pro Java programmer, named Gary, has expressed interest in taking over coding of the tech model. I have turned over what I had accomplished over the past ten days or so to him. He said he already has a good HTML parser at work, and thought he could manage both the parser for tech, and the GUI tech builder utility by the end of this coming week. Hopefully we'll hear from him here shortly. He also has an extensive math background, so he should be able to fully participate in the discussions on mathematical details of the model. He's also an XP advocate, so we've gotta get him and F_Smith together .

When you get here Gary, an official welcome to the Clash project!

[This message has been edited by Mark_Everson (edited March 18, 2001).]

	19-03-2001 05:38									#43
	Increase Your PM Length

Mark has asked me to take over the coding for the Technology section.

I am a Java Architect and used to be a technical team leader for a Java coding team.

I have read all the tech threads (that wiped out the weekend).

My design orientation is very similar to that of F_Smith - I am an enthusiast for OO programming, and Kent Beck's Extreme Programming in particular.

I also have quite a bit of experience with XML. I will try and have a working user interface to allow input of technologies and applications within the next few days. This will follow the requirements listed a few posts back.

Cheers

	19-03-2001 07:33									#45
	Remove this text

Thanks for the Welcome!

The email I got with my password said that I can change it: "Note that you change this password online using the "edit profile" button on our bulletin board"

When I tried this, there did not seem to be any option to change my password. Can you change your password?

First cut at the tech editing user interface is working - it picks up a file and parses it. Course it doesn't do anything else, but I am getting there.

Cheers

	19-03-2001 07:40									#46
	Support Apolyton buy from Amazon

Hey Gary:

Yeah the change password seems to be accessable to me. I hit profile, then entered username & pw and hit submit ID. Then you get a screen that has a lot of editable fields, one of which is the pw. I didn't try actually changing mine, but it looks like it should do the trick.

Good progress! I'm getting the merchants going for the econ model...

	19-03-2001 08:03									#47
	Put an end to popups!

Hey Gary! Glad to see some help here! Me and Rich will insert the actual techs we plan to use once you got a descent user model working so I can't wait!

Hope you didn't fall asleep reading all those posts either

	19-03-2001 08:48									#48
	Tired of ads?

Thanks - I must have been blind - I didn't see the password box. I have now changed it to something I can remember. Coming from an unusual country I have an advantage with passwords - I just use a Maori word.

In writing the data editor I have taken

1. Set default values for m, c, W, and DR.

2. For every technology, input:
a. Technology name and text description.
b. The level of the technology.
c. Technology requirements and Ts.
d. Values for m, c, and DR. It would be a big help if these were defined in terms of the defaults (default c times some value). This way, we can change the default values and not have to redo individual values; they would keep the same ratio.
e. Helper technologies with O and h for each helper tech, as well as a W value defined in terms of the default value.

It would be nice if parts a through e were in different sections. Also, space should be left for the the Alter Variable section and sections dealing with E and I.

3. For every application, input:
a. Application name and text description.
b. The L value of the application.
c. Technology requirements with an h value for each requirement.

as the substantive definition of requirements.

This raises a coding point. One of the most well-accepted, ingrained even, principles of coding is that all identifiers must be descriptive. Under no circumstances should you ever use single letter variable names (sometimes people get away with i for an index and e for an exception, but that is it).

So I would like the model designers to provide me with descriptive values for: m, c, W, DR, Ts, O, h, E, I and L.

I am unclear what "Technology requirements" means.

The file will be in a simple XML format (so I can use a simple parser), here is a sample:


<Parameter>
<mValue>0.1</mValue>
</Parameter>

<Technology>
<Name>FarmMachinery</Name>
<Description>Farm machinery and equipment</Description>
<Level>3</Level>
<mRatio>1.4</mRatio>
<cRatio>1.2</cRatio>
<Requirement>
<Name>Agriculture</Name>
<Value>10</Value>
</Requirement>
<Helper>
<Name>Automation</Name>
<Value>0.7</Value>
<Offset>20</Offset>
</Helper>
</Technology>


However, the users of the utility will never need to look at this.

Since getting the utility out seemed the biggest priority I have not gone over the equations very closely. However I did notice that h and W seem to share the same dimension space - that is, if you double all the h values and double the W value, the result is unchanged.

Enough for now. I am hoping that all my & g t and such come out right!

Cheers

	19-03-2001 09:13									#49
	Increase the size of your Attachments

Damn - all my careful indentations of the XML got lost. It will really look like:


<Parameter>
  <mValue>0.1</mValue>
</Parameter>


I hope that works. If there is no indentation it didn't work.

I have two questions.

Somewhere in my voluminous reading I remember seeing a comment that "Level" was used for two quite different things (tech level 1-3, and level of a particular technology on a 1-100 scale), and an alternative was proposed for one of them. Could somebody let me know what that alternative was and for which one. Thanks.

My other question relates to "Requirement" which crept into the XML example, but does not appear to be part of the model. What is the situation there?

Cheers

	19-03-2001 10:05									#50
	Support Apolyton

Welcome, Gary, and thanks for helping!

Technology requirements are the tech levels that are required for an application or another technology to become available. FE the tech requirements for the first cannon might be explosives level 10 and metallurgy level 30. The tech requirement for Explosives might be Chemistry level 20. Requirements will typically be helper techs.

The user can choose to define tech layers or "Tiers." These used to be called "levels." The Tier defines how the interface treats the tech, and it also sets the framework for vital techs.

The difference between h and W is in terms of what they apply to. W is an overall variable that affects every helper and vital tech equation. h, however, is different for every helper or vital tech. h is used to set up the relative effect of all the techs that help a single technology. For example, we may want to set up the following:

Aircraft Helpers:

Propulsion Systems h = .3
Physics (Mechanics) h = .5
Electronics h = .1

In this way, we can set up the relative effects of all the techs that help the development of airplanes. But what do we do if playtesting shows that, overall, helper techs have too much or too little effect overall? It would be horribly tedious to change every h value, so I put in the W value so we could easily change the whole system at once.

Descriptive requirements:

I had much more of more of a math background than a programming one when I wrote the model, and now that I have learned more about programminr I see that the names are pretty arcane. So I'll take a shot at decent names:

default m = BaseGrowthRate
default c = BaseUpkeep
default W = BaseGlobalHelperEffect
default DR = BaseRPDiminishingReturns

For individual Technologies:

m = GrowthRateMultiplier
c = UpkeepMultiplier
default DR = RPDiminishingReturnsMultiplier
Ts = StartLevel
O = HelperLevelOffset
h = HelperTechEffect
I = ExternalGrowthRateMultiplier
E = ExternalUpkeepMultiplier
L = ApplicationLongevity
[This message has been edited by Richard Bruns (edited March 19, 2001).]

	19-03-2001 17:54									#51
	Get a bigger avatar today!

Great to see tech chargin' forward!

Just a quick note for Gary. If you read the faq under 'UBB Code' you will learn a bunch of useful formatting commands. One of them is the Code tag that preserves indentation. its ['code] ... ['/code] (remove ' when using).

	20-03-2001 10:03									#52
	Put an end to popups!

[Edit]
This is a public service announcement to future readers of this thread... In this post I confused 'requirements' which still exist, for 'vital techs' which have been eliminated in the design. So you can mostly ignore this post as confusing and irrelevant . The only reason I'm leaving it here is so that subsequent comments about the post make sense. -Mark
[End Edit]

Gary, just something you missed when reading the tome. For a regular tech (as opposed to an application) there are no longer vital techs (called requirements in the original spec). All techs that adjust difficulty are called helpers, and a formerly vital one is just one with a large value of h.

The discussion of this change started at the bottom of my post of Mar 8 in this thread (p1).

-Mark

[This message has been edited by Mark_Everson (edited March 20, 2001).]

	20-03-2001 00:52									#53
	Support Apolyton or Terrorists Win

Many thanks for the prompt response. And particularly thanks for the English language names for the variables.

Mark: I was sure I did use the code tag for my XML sample. Oh well, I will be more careful next time.

I have a contradiction of requirements (using the word advisedly). Richard says that requirements are required, Mark says they are not...

Seconds out.

Cheers

	20-03-2001 04:09									#54
	Support Apolyton, buy Call to Power 2

Gary:

You used 'code' with angle brackets. UBB seems not to parse that right. Use plain brackets and it'll work fine.

Resoving my statements with Richard's...
He was talking about Applications (Tier IV) techs Only AFAIK. I was saying they aren't needed for Tier I - III (Theory - Skills). I believe Richard and I agreed on this in the posts after that 3/8 one I talked about. So in your parlance... Requirements are required for Applications, but requirements aren't required for other techs, where you are helped by helpers instead.

	20-03-2001 05:40									#55
	Get a bigger avatar today!

But there is an attribute of the helper tech called the requirement. That is the level of the helper tech that is required for the tech to exist. Flight does not exist until you get to a certain level of the helper techs; those levels are the 'requirements' for Flight.

	20-03-2001 06:00									#56
	Inflate your Upload Space

Thanks for clarifying! All I can say is OOps

[This message has been edited by Mark_Everson (edited March 19, 2001).]

	20-03-2001 08:29									#57
	Put an end to popups!

It appears to be something of a terminology mixup:

To Mark "requirements" meant extra strong helpers.

To Richard "requirements" meant prerequisites.

To Gary "requirements" are the rules for writing the whole thing.

Just joking.

The code for the utility progresses.

Looking beyond the code, it is perhaps time to give thought to program (as opposed to model) design.

I have to concoct some way of a technology for a civilization (as opposed to the overall technology data) being able to find the helper levels for that civilization. This is a bit tricky so far.

The technology objects, which know about helpers, know nothing about the relative levels for a particular civilization.

A specific technology for a specific civilization can look up the helpers from the overall technology data. But then how does it find out what the levels are for its own civilization?

This sort of thing accounts for most of the labour of coding. The algebraic part can be done in a few minutes. The interconnection between the various part can take days or weeks.

I will be thinking on the matter as I finish the utility.

Cheers

	21-03-2001 01:35									#58
	Enter the AD-FREE zone

The utility is progressing well. About 2000 lines written and working.

I had to digress into the actual model - not really required for the utility, but needful if the final result is to be coherent.

There are two matters that I would like some clarification on.

Tags:
I did read some information about tags in my marathon reading effort.
Unfortunately I left my hard copy at home (100 miles away) and really don't have the time to pursue elucidation on the web.

So I would appreciate some clarification of the current situation.

I am unclear whether tags are used merely to inform the player of the status of research, or to indicate which technologies will receive the benefit of current research. If the latter, some further clarification and perhaps model development is required.

Tiers:
I can't see why tier information is read into the program. It is never used and has no effect on game play.

Cheers

Gary

	21-03-2001 03:08									#59
	Support Apolyton

Tech tags determine a lot of things. First, they are an important way for the players and the AI to interact with the tech tree. For example, If disease is a problem, then the player will know to funnel research into the "Health" tag. This should also be easy to program into the AI, so it doesn't have to 'know' a whole lot about the tech tree when making decisions.

Tech tags are also the way that most RP's are assigned. Most RP's will come from basic economic activity. These activities, like building castles or running a government, will increase related techs, as your people get more experienced in doing something. The tag of the technologies determines which tech these activities will add RP's to.

For more complete info, look here.

Tiers do have an effect. As currently designed, Tier 1 techs are theoretical techs like "Chemistry" that historical rulers did not know about or relate to. As such, the players will not see ststus reports of tehse techs and cannot order research to be directly put into them. They will only order direct involvement into the Tier 3 techs like Shipbuilding. No ancient king said, "Learn about Chemistry." They said, "Build better Siege Engines." As the game progresses, players will gain the ability to interact with the more theoretical technologies.

We have made some attempts at OO modeling. Maybe these got lost in the shuffle:

quote: Outline for Tech System Implementation with OO modeling: This outlines the entire tech system procedure, starting and ending with object parameters for the other game models. This is mainly a definition of the objects and their interactions; the equations will come later. The system is run at the end of the turn. It uses data about events and attributes from that turn and the results are implemented at the beginning of the next turn. This system can be run at the civ, province, or even the square level. The default would be the civ level, but if you wanted different provinces or squares to have different tech levels you could run these methods at that level. 1) Data about RP generating activity in the area (civ, province, or square) is collected. I would assume that this would be a matter of inputing object parameters (trade, construction, etc.) from the other game models. 2) Tagged RP's are generated from this data. Each tech tag has a Tagged RP object that calculates itself based on the data gathered in step 1. 3) Social effects and other external multiplicative effects are applied to RP generation by tag. The object parameters from the other models again cause the Tagged RP objects to recalculate themselves. (Note that this allows society to have different impacts on different fields of study. Philosophy innovation might be frowned upon while Agriculture innovation might be supported.) 4) Tagged RP's are distributed among the technologies. Each technology has an associated Tech RP object that calculates itself based on data from the Tagged RP objects and the level of the associated tech. 5) THL (Total Helper Level) values are calculated. Each tech has an associated THL object that recalculates itself based on data about the helper and vital techs. 6) Each tech level is recalculated. Each tech object recalculates itself based on data from the associated RP object, THL object, tech attributes, and its own tech level. (This is the step that is detailed in the spreadsheet.) 7) Tech diffusion is calculated. The tech objects recalculate themselves based on data from surrounding areas and the internal conditions of the area. (Note that this is in addition to the effects of trade. Trade generates RP's that must be turned into technology by the civ or province. This gives completed technology directly to the area. So, your society might not provide a good environment for the development of something, but they would use it once it is completed.) 8) Application levels are calculated. Each application object recalculates its level based on the tech objects and its own attributes. 9) The effects of application levels are implemented. The objects in the other models recalculate themselves based on the parameters of the application objects. These effects will take place before the start of the next turn. So the basic outline is: Other model objects (previous turn) -> Tagged RP objects -> Tech RP objects -> Tech objects -> Application objects -> Other model objects (next turn)

quote: I could finalize my plan for the methods if the following object list is agreed upon: Tech Tag objects, with the Tagged RP's as parameters and the methods for calculating the tagged RP's. One Tech RP object for every technology, with the methods for calculating itself based on parameters in the Tech Tag object. The Technology object, with the level as a parameter and methods for calculating the level. (Would it be better to have the RP as a parameter in the tech object? I'm not sure about this one.) The Application Objects, with methods for calculating the level based on parameters in the tech object.

	21-03-2001 05:47									#60
	Browse Apolyton AD-FREE

I am still rather vague on how "Tags" work. Are they research areas? If so, it would be nice to call then ResearchAreas or some such. "tag" as a word, is rather overworked - to me it means something like <Technology> in an XML (or HTML) file. It is also something that goes in a sheep's ear.

Are the tag areas to be built in to the code? Or configurable?

There doesn't seem to be any provision to read the tag levels for each technology from the XML file. Are they supposed to be part of the data input utility?

It would seem to be a reasonable idea to read in the tags from the same file as technologies.

It has just occurred to me that the tags might be part of one of the other models and described there. Is this so?

Alternatively are they a completely separate model of their own?

Sorry to be so confused. I have no difficulties with the idea of coding for tags (provided they get a more explanatory name) in an OO modelling way. The idea of using such a structure for intercommunication is appealing.

More or less by accident, the technology model is becoming data driven, with the possibility of swapping from one tech file to another for specific scenarios. This is the type of code structure that I particularly like, for it generality, extensibility, and configurability.

Cheers