More-Flexible Tech Prerequisites

[Dilvish]

That's fine, but what I really want to discuss is issues with / advantages of making all tech prereqs be optional / "or" style.

It looks to me like the 'issues' portion has already been discussed fairly thoroughly, just not with the result you want. As for the 'advantages' part, the only advantage I've seen you mention, is, well, hmm, with respect to the all-mandatory approach, it's different, and I suppose you can count that as an advantage if you like the difference.

With respect to a mixed system, which is what it looks to me like absolutely everyone who has replied to you has already said they would prefer, you have identified that a pure system (of either type) could have a somewhat simpler UI. It looks like we're all agreed that the pure-mandatory-prereqs system can have the simplest UI, that the pure-alternative-prereqs would be a little more complex because of uncertainty about how to automatically choose among alternative prereqs when someone queues a currently-locked prereq, and that a mixed system UI would be a bit more complex yet. I don't think I've seen any other proposed advantage of the 'pure alternatives' system over the mixed system-- do you have any other advantages to advocate?

How would requiring a building to be produced act as a replacement for the ability to have several mandatory prereqs for a tech?

The point was that buildings could provide a type of dependency that the tech tree didn't, primarily so that the tech tree itself could use just a single form of dependency (any vs. all). Having a particular building might be a requirement to use some aspect of some tech, which would require a player to either research that tech and produce the building, or capture the building from another empire and then be able to skip doing the extra research.

Geoff, all you are doing here is describing how pretty much all buildings already work (other than the Industrial Center and, as a practical matter, most shipyard buildings), and you seem to be rather pointedly ignoring that to the rest of us this does not at all seem to serve as a substitute for mandatory prereqs.

[OllyG]

...uncertainty about how to automatically choose among alternative prereqs when someone queues a currently-locked prereq...

Just make it choose the cheapest route. If a player selects an advanced tech they are probably unconcerned with which prereqs they get, just with getting their choice in the least time.

[Dilvish]

...uncertainty about how to automatically choose among alternative prereqs when someone queues a currently-locked prereq...

Just make it choose the cheapest route. If a player selects an advanced tech they are probably unconcerned with which prereqs they get, just with getting their choice in the least time.

That would be a reasonable decision, it's just that there is not a clear best decision-- another reasonable choice would be 'fastest', for which Geoff has already suggested a somewhat more complex variant that takes into account current RP availability. Sometimes these two rules might choose the same prereq, but not always.

I didn't mean to imply there were no known reasonable choices, just that we don't seem to have a clearly best rule, so no matter what we choose some players would probably think it's the wrong decision. Of course, that's probably a good choice for a setting to put either into the main config or into the common customizations file, but it still leaves the UI less inherently clear, somewhat more complex.

[Dilvish]

How would requiring a building to be produced act as a replacement for the ability to have several mandatory prereqs for a tech?

The point was that buildings could provide a type of dependency that the tech tree didn't, primarily so that the tech tree itself could use just a single form of dependency (any vs. all). Having a particular building might be a requirement to use some aspect of some tech, which would require a player to either research that tech and produce the building, or capture the building from another empire and then be able to skip doing the extra research.

So, I think I may finally have figured out what you were meaning to get at here-- that Tech A might unlock Building X, and the presence of Building X could be necessary to get the benefit from Tech B.

So, if that is what you were meaning there, then I guess I would agree that it sets up a situation that is at least very similar to Tech A being a mandatory prereq to Tech B, while the tech tree UI could just indicate the 'alternative' type prereqs. Having the tech tree UI just show the 'alternative' dependencies in that case would seem to me to be a two edged sword with a rather sharp second side though, since it seems to amount to hiding a critical dependency from the main tech tree display.

[MatGB]

Having a tech that doesn't do much unless you've got a building from another part of the tree is almost certainly going to cause confusion in newer players and be harder to explain.

It's not necessarily a bad idea, I keep wanting to do something with the Enclave Of the Void making it an earlier build that gets better with progressive techs, but in a different way to the Industrial Centre, for example, but we get enough confusion from people for basic level dependencies.

[Geoff the Medio]

It looks to me like the 'issues' portion [of making all tech prereqs be optional] has already been discussed fairly thoroughly...

I still don't understand what the argument is for why required-prerequisites are important to have. Vezzra asserts they are useful / important...

Obviously the ability to make a certain, very special/very powerful tech harder to get. Or to grant access to certain special techs only to players who have researched a certain combination of other tech (lines).

But I don't remember seeing a clear discussion / example of when and why it would be very important to have required-prerequisites, rather than just any-of-prerequisites.

[Besides (UI) simplicity over a mixed system] I don't think I've seen any other proposed advantage of the 'pure alternatives' system over the mixed system-- do you have any other advantages to advocate?

An advantage of a pure optional tech dependency system is that it encourages the creation of dependency webs that make having "unavailable" techs more possible and plentiful. If there is too much emphasis on strict required tech dependencies, then the potential for having optionally-available techs is substantially reduced without other specific effort towards supporting it... That said, even with strict dependencies, local branching arrangements could be set up, so that, for example, a tech might unlock 4 other techs, any one of which will unlock the following tech and any 3 of which could be removed from the tree without breaking overall connectivity. But having only optional prereqs would encourage setting up a wider variety of optional paths through the tech tree, so that unless there is a reason why required prereqs need to be used, it might be better to not use them at all.

Tech A might unlock Building X, and the presence of Building X could be necessary to get the benefit from Tech B.

Not necessarily "the" benefit... Something to consider for future tech tree reworking is to consolidate multiple unlocks and effects from multiple separate techs into single multi-purpose techs, especially at the start of the game, to reduce the number of tech options at any one time (or equivalently reducing the breadth of the tree). A tech could give a bonus to a building unlocked from another tech. A tech could also unlock a building that has location requirements including the presence of another building, or a building could have location requirements for multiple other buildings all with their own distinct unlocking requirements.

As for displaying things, it seems to me that it would probably work out just fine if the primary graphical distinction were solid lines versus dotted (or dashed) connecting lines, indicating an AND-type unlocking or an OR-type unlocking. If Tech A and Tech B are both needed to unlock Tech C, their connections to Tech C are solid. If it's that either Tech A or Tech B is needed to unlock Tech C, their connections to Tech C are dotted. This would even let you clearly show that Tech E can be unlocked by either (i) Tech A (dotted line), (ii) Tech B (dotted line) or (iii) the combination of Tech C and Tech D (solid lines).

I don't understand the bold part... It sounds like

tech dependencies

techsdepends.png (7.19 KiB) Viewed 5636 times

Which I think you mean would indicate that E requires (A or B or (C and D)). But I would have guessed that that would indicate that C and D are both required, while A and B give some benefit to researching E but are not required.

In terms of what to implement in the engine, I think it would make sense for techs to have arbitrary combinations of:
-Required prerequisites: these must be researched to be able to research the following tech
-Optional prerequisites: if there are no required prerequisites, at least one of these must be researched to research the following tech. if there are required prerequisites, researching these reduces the time/cost of the following tech
-Negative / Exclusion prerequisites: if any of these are researched, the following tech cannot be researched

I imagine exclusion prerequisites would be mostly used for pick-one-of arrangements, where tech A unlocks techs B-1, B-2, and B-3, but only one of the B techs can be researched. This would be interesting because it forces the player to choose just one option. Situations where a following tech could be already-researched and then made unresearchable by an exclusion prerequisite being researched could be a bit odd, but might have some use as well. Generally I'd think that forcing a choice between mutually exclusive options on a larger scale (ie. only one of these three whole branches of the tree) would be best done with a non-tech gameplay system, such as picking a government or social policy or idiology point allocations.

I'd like to avoid nesting unlock logic like And(A, Or(B, (C and D))). As noted elsewhere, if absolutely required for some reason, other techs can be added to create that sort of dependence out of simpler relationships.

It might be worth removing the "prerequisites" list from tech definitions, and instead do all the unlocking with an expanded "unlocks" list, which would allow the various types of tech unlocking (required, optional, exclusion) to be specified. Having two ways to unlock techs seems unnecessary, and we can't avoid having the unlock list for other things, so it might make sense to remove the prereqs list instead.

[Dilvish]

An advantage of a pure optional tech dependency system is that it encourages the creation of dependency webs that make having "unavailable" techs more possible and plentiful.

"An advantage..."? So, there's this thing we've all said we'd like at least some of, and you'd apparently like a great deal of, and so to "encourage" it you propose actively suppressing the other options that most all of us have said we also like? If everyone (or most) involved felt that using just optional prereqs was universally superior, then sure, I could see such a suggestion potentially making sense as a proposed course of action. I don't understand how the idea is intended be persuasive of anything in our actual situation

Which I think you mean would indicate that E requires (A or B or (C and D)). But I would have guessed that that would indicate that C and D are both required, while A and B give some benefit to researching E but are not required.

You're right that (as for many of our UI elements) there could be multiple different reasonable assignments of meaning, and what you propose, while different from my initial suggestion, could be a reasonable way to handle things within the mixed approach, and has some interesting characteristics.

It might be worth removing the "prerequisites" list from tech definitions, and instead do all the unlocking with an expanded "unlocks" list, which would allow the various types of tech unlocking (required, optional, exclusion) to be specified. Having two ways to unlock techs seems unnecessary, and we can't avoid having the unlock list for other things, so it might make sense to remove the prereqs list instead.

**edit snip-- see at bottom ** While the unlock list is perfectly suitable for the optional unlocks, it doesn't really seem very well suited to handling the required unlocks or exclusions. But perhaps I'm too focused on the current unlocks list, and you have something a bit different in mind, more focused on just the tech unlocking rather than how it is now.

** I had said 'I'm not sure what you're referring to here by "Having two ways to unlock techs", ' but now I think I realize you meant (i) by using the 'unlocks' list in the unlocking tech and/or (ii) by listing the unlocking tech as a prereq in the tech to be unlocked. If that's what you meant, no need for further comment, I was just being a bit slow, I guess.

[em3]

It might be worth removing the "prerequisites" list from tech definitions, and instead do all the unlocking with an expanded "unlocks" list, which would allow the various types of tech unlocking (required, optional, exclusion) to be specified. Having two ways to unlock techs seems unnecessary, and we can't avoid having the unlock list for other things, so it might make sense to remove the prereqs list instead.

This would make the technology tree harder to mod. When you want to add a single tech, the change is localized (you create the definition and list the prerequisites). A new technology branch can be "grafted" onto the existing tree without touching the default techs. Doing it the other way would require modifications to lists contained in existing technologies.

[MatGB]

Agreed, and I regularly look at prerequisites on a tech that I have as an objective, if I want, say, a Sentient Hull, I want to look at the tech for that and have a list of what I need to have researched.

[MatGB]

I finally got around (af4e48c) to finishing off, committing and testing some of the stuff suggested above, I've created new techs to unlock the ship stealth parts and removed them from the planetary specials, but each is now cheaper if you've already researched the counterpart (not sure on costs for this but the principle is sound).

In addition, the stealth parts don't follow each other through the chain, instead each is unlocked by the same tier of detection tech (you can't fool radar if you don't know how that works, etc).

I quite like the way this plays and it's all possible within existing scripting powers, but if someone wants to look see if my scripts could be tidied up/made more efficient in some way that'd be good.

[labgnome]

I know I've talked about the tech tree before, and I actually worked some concept revised tech trees in Open Office Draw (which is good for visualizing the connections). I was hoping to convert those to jpg or some other more easily viewable file at some point. More on-topic though: I do like the general direction of this idea, but do have concerns for the implementation. I also agree that a mixed system is preferable to a purely optional system.

However I'm going to throw a wrench in the whole thing by suggesting a third option. Why no instead of having "required" and "optional" prerequisites, have required prerequsites, and then have other techs that reduce the cost and/or time of research, that way they're not required, and it won't screw-up building a tech queue but they will still be something that you might want to get.

It would make for more disjointed areas, for example I'd want to change advanced damage control so it's prerequisite remained galactic infrastructure not just fleet field repair.

So taking that example, you could say have Galactic Infrastructure be the required tech, but have fleet field repair say make it only 1/2 the cost it would be otherwise.

The other advantage of this idea is that it can also allow the opposite, having tech that increase the cost or time to research other techs, allowing specialization along certain branches or with certain strategies to be encouraged, while not being forced onto the player.

So for another discussion going on about pop-based bonuses and "tall" versus "wide" empires, you could have the techs that would increase the populations on planets make the techs for colonizing more kinds of planets make each other cost more, so you are encouraged to pick one or the other. Likewise, you could make techs that give a flat bonus and techs that give pop-based bonuses make each other cost more, so you are encouraged to pick one over the other in your strategy.

Also separating techs into what's required and what's optional, but beneficial could allow us to do things like have a random or species-specific tech trees, as there would be "core" techs that everyone would get and would be needed, but also optional techs that you might not need but would be useful, and potentially add diversity or flavor.

[AndrewW]

I know I've talked about the tech tree before, and I actually worked some concept revised tech trees in Open Office Draw (which is good for visualizing the connections). I was hoping to convert those to jpg or some other more easily viewable file at some point.

Just a matter of exporting to whatever format you wanted to use, svg or png could work too as browsers can render that.

[MatGB]

However I'm going to throw a wrench in the whole thing by suggesting a third option. Why no instead of having "required" and "optional" prerequisites, have required prerequsites, and then have other techs that reduce the cost and/or time of research, that way they're not required, and it won't screw-up building a tech queue but they will still be something that you might want to get.

*cough*

I think we agree here

The reverse decrease for the parts appears to have gotten lost at some point, probably during the file splitup, I'll have to dig that out and put it back in.

The other advantage of this idea is that it can also allow the opposite, having tech that increase the cost or time to research other techs, allowing specialization along certain branches or with certain strategies to be encouraged, while not being forced onto the player.

Yeah, I've been thinking about a similar approach to some of the growth techs: if you want to research Cyborgs, for example, it makes Terraforming/Gaia transformation more expensive, and vice verse.

Also separating techs into what's required and what's optional, but beneficial could allow us to do things like have a random or species-specific tech trees, as there would be "core" techs that everyone would get and would be needed, but also optional techs that you might not need but would be useful, and potentially add diversity or flavor.

Aye: in the example above you'd want to take Cyborgs out of the main tree that heads towards Transcendance.

I keep meaning to spec up different growth techs for the different metabolism types as I think that could be interesting, but it's a very low priority.

[Krikkitone]

If the Tech A increases/decreases the cost of Tech B model is added in, one thing to watch out for would be order.


Should
A then B
cost less/more/the same as
B then A

I'd argue they should cost the same*.... so if researching A makes the cost of B change by +-X, then researching B should change the cost of A by +-X as well.

*both for avoiding micromanagement,
And for flavor.... if you want empires to get techs A OR B [increasing the cost of each other] or techs A AND B [decreasing the cost of each other], then the order shouldn't matter as much.

[labgnome]

Just a matter of exporting to whatever format you wanted to use, svg or png could work too as browsers can render that.

I will definitely do that at some point as I think I found the files, but I do need to do some work to ensure legibility. One is highly abstract and more an exercise in my idea for the general "shape" of the tech tree, and the other is has some more specific thoughts on various techs.

Yeah, I've been thinking about a similar approach to some of the growth techs: if you want to research Cyborgs, for example, it makes Terraforming/Gaia transformation more expensive, and vice verse.

I really like this kind of specialization. I also think it's a good way to get games to feel different without "locking in" players too much with their initial choices.

Aye: in the example above you'd want to take Cyborgs out of the main tree that heads towards Transcendance.

Yes, I think the rout to Trancendance should be mostly, if not completely, "theory" techs. IE: things that offer little-to-no direct benefit (outside of the Trancendance goal) and eventually cost a lot, so that you have to research other things to be able to do things like defend yourself or get the necessary research budget to even get there.

I keep meaning to spec up different growth techs for the different metabolism types as I think that could be interesting, but it's a very low priority.

I should just put up something on my ideas long those lines. I have a fairly general concept of what I want to do with them. Also in the non-required realm, I think that those growth specials should only be available to empires that actually have species with those metabolisms in them, so that you can't say research all the good robotic growth techs as an organic species then go an grab-up a decent robotic species, making them really good of the bat.

If the Tech A increases/decreases the cost of Tech B model is added in, one thing to watch out for would be order.


Should
A then B
cost less/more/the same as
B then A

I'd argue they should cost the same*.... so if researching A makes the cost of B change by +-X, then researching B should change the cost of A by +-X as well.

*both for avoiding micromanagement,
And for flavor.... if you want empires to get techs A OR B [increasing the cost of each other] or techs A AND B [decreasing the cost of each other], then the order shouldn't matter as much.

I think this is in-line with what I was thinking. I tend to be a visual thinker, so I usually think of them in terms of "where" they are in the tech tree, even though I know it's to some degree arbitrary and abstract in actuality. I don't know if there are scenarios where that would create potential issues, but otherwise I think this makes sense.