Tech tree pictures

I'm not sure I understand what you mean... Scouts aren't that useful, they are marginally better than Wanderers, and Chasers are better than Scouts to fight animals (and possibly get a Master Hunter animal).
Well, unless you have changed the stats of chasers/scouts in your modmod, scouts are better than chasers against animals and subdue just as well until hunter 2 promotion is unlocked. A freshly built scout has 1.3 strength and 100% vs animals; while chasers have 0.7 strength and 200% vs animals. Terrain defense and promotion with % buffs greatly improves a scouts survivability while it marginally helps a chaser. The scout has a much greater survival rate when meeting humanoid barbs giving him a lot of usability.

Chasers are good and all but many players skip building them because the more useful scout is unlocked in the next tech. This would be the strongest argument for moving scouts to games instead of the tracker.
I often, after discovering pers. hunting, delayed the invention of tracking until after cultural heritage because chasers do a good enough job. ^^
 
Well, unless you have changed the stats of chasers/scouts in your modmod, scouts are better than chasers against animals and subdue just as well until hunter 2 promotion is unlocked. A freshly built scout has 1.3 strength and 100% vs animals; while chasers have 0.7 strength and 200% vs animals. Terrain defense and promotion with % buffs greatly improves a scouts survivability while it marginally helps a chaser. The scout has a much greater survival rate when meeting humanoid barbs giving him a lot of usability.

Chasers are good and all but many players skip building them because the more useful scout is unlocked in the next tech. This would be the strongest argument for moving scouts to games instead of the tracker.
I often, after discovering pers. hunting, delayed the invention of tracking until after cultural heritage because chasers do a good enough job. ^^

Oh, OK, thanks for the clarification. Yeah, Scouts in the modmod have been reduced to 1 :strength: (0,7 with SizeMatters) so that they aren't better than Chasers :D (now I think about it they are identical to Wanderers now though... I guess I'll remove the Hunter Sight 1 free promotion from Wanderers so that Scouts are actually better).
 
Oh, OK, thanks for the clarification. Yeah, Scouts in the modmod have been reduced to 1 :strength: (0,7 with SizeMatters) so that they aren't better than Chasers :D (now I think about it they are identical to Wanderers now though... I guess I'll remove the Hunter Sight 1 free promotion from Wanderers so that Scouts are actually better).
Hope you increased their withdrawal rates; or else scouts would be completely useless in your modmod and trackers/hunters would have to escort them to every tribal hut on the map. ^^

Instead of decreasing their strength I would remove their bones vs animals.
 
riiiiiiiiiggght,

ok well,

a radical answer would be, since it's so appropriate for much of the prehistoric era at least, use no arrows at all and just AND icons exclusively. It's like... you know in the base game...

k it's like this

Most of the techs are concepted with PrereqOrs. It is a many-rebranching tech tree.
Some techs have necessary prereqs instead of any choice in the matter.
Extremely few of them have a necessary prereq plus some choice. For some of those, the necessary tech is implied by some of the OrPrereqs.

That's one viewpoint of the tech tree. Another viewpoint is the overall generalities, which certainly doesn't apply to the whole C2C tree, but in base game:

The tree is composed of multiple potential histories with disjunctive prerequisites, but with some necessary items to rein things in. Like gating the advanced eras through Writing, and through Machinery, and through Philosophy. It's subtle. This is a visible part of design above the particulars.
Because of the previous point, wanting to draw an arrow is a primary option for indicating the tree. Techs that have multiple prerequisites have icons, and the 'option' of using an arrow, where, as you notice, the use of exactly one PrereqOr is indistinct from addressing that with a PrereqAnd. Arrows allow you to follow any tech to a successor. The grid arrangement is something that has to -get out of the way- for the Human to read it.
In large part, arrows indicate the main flow of the tree, and necessary prereqs are used for distant techs or in place of arrows that traverse the entire height. But the -ability- to have this relatively freeform style choice owes itself to the fact that base game accommodates a mostly -all conjunctive- or -all disjunctive- set of tech prereqs.

If C2C really had its tree drawn up in the same style as base game, I believe, the prehistoric era would have almost no arrows. But if C2C could do its tech tree, it wouldn't even have been programmed with a library that drew the prereqs the way this game does.

What happens if you take one of your style assumptions and reverse it: Putting techs on the same row shouldn't exclude drawing a line, it should be the primary time to use it. And this, because you can't communicate things with the grid. People cannot process the tree like that because of the spacing. If the spacing could be redone, maybe the mind could be coerced into using the tree that way, but in this , it can't.


C2C's tech tree is also very dense, so whereas arrows across time were quite helpful in base game, they're just not an option for it in 80% of cases. So imagine if you represented all the prereqs as strictly conjunctive (which they are for all of prehistory), and now your task is to pick y-coordinates for those techs to allow the -most- arrows to be drawn, and have no line crossings? Drawing arrow by expanding one of the conjunctive prereqs of a tech into an arrow.

This sounds like the kind of problem for a script to generate the solution for. The difficulty is that the tech tree is not in a suitable state to process for that script, because logically all the prereqs are And, but the database has the ambiguous, stylised language previously mentioned, where an Orprereq is used and doesn't mean that.
I'm gonna look at this problem assuming the script could be passed a representation of strict prerequisites and it will output y-coordinates and arrows for techs to maximize the given measure.


-----
I notice you also pushed the techs around the x-axis. Didn't that involve updating the entire tree to push it futureward? Wasn't that development-time-consuming? Is there a utility to ease that? Or is it... not time-consuming?
 
a radical answer would be, since it's so appropriate for much of the prehistoric era at least, use no arrows at all and just AND icons exclusively. It's like... you know in the base game...

Well if you do that, you remove every arrow. Being able to put some is still better than nothing to help a bit with readability!

What happens if you take one of your style assumptions and reverse it: Putting techs on the same row shouldn't exclude drawing a line, it should be the primary time to use it. And this, because you can't communicate things with the grid. People cannot process the tree like that because of the spacing. If the spacing could be redone, maybe the mind could be coerced into using the tree that way, but in this , it can't.

Problem is, you can only have 1 arrow going to a tech (remember, max. 1 tech in PrereqOr). So I'd rather use it to point prereq tech from other rows.

C2C's tech tree is also very dense, so whereas arrows across time were quite helpful in base game, they're just not an option for it in 80% of cases. So imagine if you represented all the prereqs as strictly conjunctive (which they are for all of prehistory), and now your task is to pick y-coordinates for those techs to allow the -most- arrows to be drawn, and have no line crossings? Drawing arrow by expanding one of the conjunctive prereqs of a tech into an arrow.

It's impossible to have a "perfect" tree (unless of course you change the current prerequisite tech), you have at several locations inevitable crossings from a topological point of view...
If you want to try to build a script to have the "best" one, go ahead, but I'm quite sure I'd be even more difficult than doing it manually ;)

I notice you also pushed the techs around the x-axis. Didn't that involve updating the entire tree to push it futureward? Wasn't that development-time-consuming? Is there a utility to ease that? Or is it... not time-consuming?

Yeah, I have an Excel sheet to generate the TechInfos file (and also to provide me with a simplified view of the tech tree based on the iGridX and iGridY) which is immensely helpful, but you still have to find the best location for each tech and arrow (knowing that you can't do it perfectly so it's a matter of finding a "not too bad" setup) and that's what very time-consuming ;) (it must have taken maybe 5h to do the Prehistoric era above)
 
Sir, I am a script-kiddy. The effort plateau is always below doing it manually.

Problem is, you can only have 1 arrow going to a tech (remember, max. 1 tech in PrereqOr). So I'd rather use it to point prereq tech from other rows.

My post was constructed as an answer to this fact, which you pointed out with the previous one of yours.

The problem I'm proposing to solve is the one of taking a tree of prerequisites and deciding which ones to draw with arrows (leaving the rest to the symbols) given that at most one arrow into each tech is allowed, and that arrows should not cross each other, and there are (what?) 12 rows. And wanting to draw the maximal number of arrows.
It's a well-defined problem. But its complexity class is large and, sadly, combinatorial. So I need to hunt either for a heuristic or a faux-rule, and that's in addition to not moving the x-axis.

Arrows aren't allowed to cross each other in this solution because we can't control how they are drawn to cross each other, which can produce unreadable images.

The solution generated will be perfect, inasmuch as the algorithm is correct.

But I can't capture facts like the following: Prehistoric Dance and Prehistoric Music should relate in a symmetric way to Oral Tradition (and to Ritualism). So actually, if I wanted to be useful, I'd plan to make the script spit out something in an intermediate state to readjust for things like that (effectively, to not do premature optimization).

I reiterate that your result is beautiful in many ways. Perhaps truly, what I long for is to program the manner in which you made adjustments, rather than capture the definition of the ideal. Perhaps a 'local maximum' of tree elegance is pleasing without cost.
 
While I also think your version looks way better, it causes another problem: Currently, all techs have costs according to their x-Position in the tree. If you spread them out more, moving techs around will be a hell of maintenance since you not only have their position in your tree, but also keep in mind which x-value they had to adjust the costs.
 
While I also think your version looks way better, it causes another problem: Currently, all techs have costs according to their x-Position in the tree. If you spread them out more, moving techs around will be a hell of maintenance since you not only have their position in your tree, but also keep in mind which x-value they had to adjust the costs.

Buildings including Great Wonder and National Wonder costs as well as unit costs are also based on the x-Grid.
 
While I also think your version looks way better, it causes another problem: Currently, all techs have costs according to their x-Position in the tree. If you spread them out more, moving techs around will be a hell of maintenance since you not only have their position in your tree, but also keep in mind which x-value they had to adjust the costs.

Not sure I understand. Yes, some tech were moved on the X axis, which makes it slightly less obvious to guess the cost of a tech, but the difference remains limited (I'd say you shouldn't find a tech more than 20% cheaper on a later iGridX than a another tech) and this is something that is already true with the current tree (ex. Chariotry is three columns earlier than Soap Making but has a base cost of 105 vs. 85 ; Fire Making is earlier than Canine Domestication but has a cost of 50 vs. 30...).
If you're talking about adjusting tech cost according to the new tree, well, that's certainly easily doable but I won't take myself the initiative of doing that ;)
 
Not sure I understand. Yes, some tech were moved on the X axis, which makes it slightly less obvious to guess the cost of a tech, but the difference remains limited (I'd say you shouldn't find a tech more than 20% cheaper on a later iGridX than a another tech) and this is something that is already true with the current tree (ex. Chariotry is three columns earlier than Soap Making but has a base cost of 105 vs. 85 ; Fire Making is earlier than Canine Domestication but has a cost of 50 vs. 30...).
If you're talking about adjusting tech cost according to the new tree, well, that's certainly easily doable but I won't take myself the initiative of doing that ;)

No that's not what I meant. As the tree is now, a tech as a x-position. Then the costs for techs is a function of this x value; same is true for buildings and units costs.
Let's say we have a tech that has the x-value of 40 and that a building in it has a cost of 40²=1600. If you move around your tech tree (it looks way more expanend) then the tech ends up with an x-value of 50. The costs for the unit is still 1600 - which is ok; after all, you will need the exact same time to reach this point as before since you only moved stuff around and not adjusted values.

Then, after some time since your tree was introduced, we move around techs,change prereqs etc and now the unit ends up with an x-value of 60 instead of 50 in your tree. Now... what should be the costs for it now? 60²? No, it wasn't 50² before that. We can guess that it would be around 45², or we can look it up in a table we have to make before.

I'm not against it, it is just more complicated than simply moving techs around. I'd even suggest that units and buildings should not have a fixed cost based on x-value WITHOUT EXCEPTION, but rather have the X-Value as a guideline. If a Basket Ball Field and the Minor League Station were at the same x-value, they should NOT be equal IMO. More complex buildings on the same x-position should cost more than simple ones.
 
No that's not what I meant. As the tree is now, a tech as a x-position. Then the costs for techs is a function of this x value; same is true for buildings and units costs.
Let's say we have a tech that has the x-value of 40 and that a building in it has a cost of 40²=1600. If you move around your tech tree (it looks way more expanend) then the tech ends up with an x-value of 50. The costs for the unit is still 1600 - which is ok; after all, you will need the exact same time to reach this point as before since you only moved stuff around and not adjusted values.

Then, after some time since your tree was introduced, we move around techs,change prereqs etc and now the unit ends up with an x-value of 60 instead of 50 in your tree. Now... what should be the costs for it now? 60²? No, it wasn't 50² before that. We can guess that it would be around 45², or we can look it up in a table we have to make before.

I'm not against it, it is just more complicated than simply moving techs around. I'd even suggest that units and buildings should not have a fixed cost based on x-value WITHOUT EXCEPTION, but rather have the X-Value as a guideline. If a Basket Ball Field and the Minor League Station were at the same x-value, they should NOT be equal IMO. More complex buildings on the same x-position should cost more than simple ones.

OK, I understand better now.
I can easily put the old iGridX in comment in the xml so that it's convenient to track down if it's necessary to use it as guideline for adjusting costs.
As for using the iGridX as a guideline, not a definite value for the unit/building costs, well, I completely agree but I thought it was already the case? I think I remember some buildings like mines that were significantly more expensive than other contemporary buildings, but I may be wrong.

Anyway, what I'd like to know is whether changing the tech tree like the part above for Prehistoric era is worth it or should I leave the tree as is and move on to something else?
 
Tech bar that auto adjusts width based on max number of icons per tech.
Ability to show partial tech tree based on era
Ability to hide what has been researched
 
I'm currently looking at the TechInfos file and thought it could be a good opportunity to redraw a bit the tech tree - I find the current version very confusing with all the lines crossing in every way (it took me several games to figure out that SedLifestyle did not require Celebration for instance...).

I tried to reorganize a bit the tree, starting with Prehistoric era. Of course I kept every tech requirement the same, only the positioning of the tech window and the lines are changed.

There are heavy limitations on how one can draw the tree (since the arrows are only for PrereqOr, you can only have one if you have no optional prereq tech; I tried putting several techs in both PrereqOr and PrereqAnd, it works but messes up a bit the prereq entry in the Pedia so it's no good), but I tried to follow as much as possible these guidelines:
- No crossing lines or lines behind tech windows (cf. the aformentioned Celebration trick due to the line from Conduct to SedLifestyle)
- A tech shouldn't have a prereq tech on the same column (or after), only in a previous column (cf. Trapping/Tracking in the current tree)
- Two techs on the same row following each other means that the second one requires the first (and there's no arrow in between). Arrows are used for a prerequisite tech on a different row.
It's not possible to have those rules always enforced (especially the 3rd), but they should be more often than not. If you wonder how to get a given tech, looking for any tech pointing at it and/or earlier on the same row should most of the time be right.

It was hell to tweak each tech individually several times, but here's the best result I could get:

Spoiler :
efwfXct.jpg



Before I go any further, I'd like to know if you have any comment!

I don't like that Language is in the 2nd column. I thsould be in the first. Also why's it have no links at all?
 
I don't like that Language is in the 2nd column. I thsould be in the first. Also why's it have no links at all?

I talked about it early in the thread, basically it's the result of an unavoidable compromise.
A tech can't have two links coming to it (unless only one of the prereq tech is required), so I'd rather have a link coming to Cooperation from Gathering which isn't on the same line. But then it's harder to spot that it also requires Language, that's why I put Language just before. Anyway, I've put it back on 1st column since.

That being said I've stopped working on the tech tree, it's a daunting task and I don't want to further invest time there if it's not that useful (or if the tech tree is due to change).
 
Back
Top Bottom