Edit: Here is a link to the most recent content updates. /edit
I have revised the learning tree to make it more comprehensible, playable, and organized. The relevant text files are enclosed.
First of all, why I am reworking the tech tree: I believe that with the current state of the game, a fuller tech tree will make the FO legitimately playable as a multiplayer competitive game. When it is in this state, it will be much easier to attract new contributers. Furthermore, if basic organization of the tree happens now, it will be much easier to decide where new techs go, etc. later on.
I have tried to design based approximately on the following parameters:
Every theory is unlocked by one other theory of the same category, one level lower.
Some theories may be unlocked by a second theory of any lower level, of any category.
In special cases, additional prerequisites may be used.
Every application is unlocked by one theory of the same category of the same level
Some applications may be unlocked by a second theory of the same category at a lower level, or a different category at the same level.
In special cases, additional prerequisites - including other applications of lower levels - may be used.
Every refinement is unlocked by an application or refinement of the same level.
Some refinements may be unlocked by multiple refinements of the same application.
In special cases, a theory may act as a prerequisite for a refinement.
Now, not all of these cases take effect in the part of the tree I reworked, but it's fair to let you know what I'm trying to work towards. The new learning tree looks very pretty! You all should take a look. Note that the current research costs exist for organizational purposes only. Also note that I dramatically increased the effects of many techs. We don't want an infinitely long tree, and further more, the player should never research all of it in a game. +2 is a fairly insignificant bonus on a scale to 100. You'll also find that many Learning apps give secondary advantages to other things as well, since +X to meter Y is fairly boring all the time. I also tried to give a penalty to most Learning Buildings, in keeping with previously made design decisions.
Of note, there is also a new building, Black Hole Power Plant, with a corresponding tech, Advanced Energy Harnessing in the Production section. A Black Hole Power Plant seemed the natural precursor to the Artificial Black Hole, and when I do that part of the tree, it will likely be one of those App --> App special cases.
If you don't like what I've done, I can stop, but I think it could be very useful for drawing in new members if the game can actually be played competitively, for fun, and not just for testing.
PS: The Looking Glass probably won't end up having a health penalty: More likely just a huge maintenance cost (In PP, of course).
PPS: For some reason, whenever I specified the graphic for a tech as "", the game wouldn't start. Because of that, I reused a several tech graphics; hopefully this does not cause confusion.
Tech Tree Revision: Learning
Moderators: Oberlus, Committer
Tech Tree Revision: Learning
- Attachments
-
- buildings.txt
- (31.84 KiB) Downloaded 123 times
-
- eng_stringtable.txt
- (126.27 KiB) Downloaded 100 times
-
- techs.txt
- (68.81 KiB) Downloaded 109 times
Last edited by Bigjoe5 on Wed Dec 23, 2009 3:03 pm, edited 1 time in total.
Warning: Antarans in dimensional portal are closer than they appear.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Tech Tree Revision: Learning
You've got some planet size dependent bonuses for orbital farming. This isn't necessary or appropriate, as planets' output is already determined by multiplying the resource meter by the population, which is size dependent, making the total resource output alraedy size dependent.
Various buildings have multiple stacking groups for their multiple effectsgroups. When doing this, make sure that you actually want it to be possible for a given target object to get both effects. Looking at the code, it appears that the first listed effect will always be applied first, so use order for precedence if multiple effectsgroups have the same stacking group.
Bigger bonuses (+15 ish) are OK, as long as they're late game content. The scale going to 100 doesn't matter if typical meter levels are around 10 for a given time during a game.
It's be nice if most of the techs and buildings had build times larger than 1 turn. Some variety of long build times a low cost per turn or high cost a low minimum time might be nice, as well, although keep in mind that with enough PP, a high per turn limit with low minimum turns is less restrictive than low per turn limit.
Don't use SetCurrent* meter effects. They probably don't work like you think.
Don't use conversational or judgemental language in building descriptions. It's not "unfortunate" that a building has a travel disrupting effect.
Also, setting max fuel and supply to -100 within 500 distance is a bit much. If having ships nearby disrupts the building, then have a condition do that by turning off the effects if a ship comes too close.
If you could, please add a stacking group to limit the imperial palace to only one construction meter bonus per planet. Appropriate scope limits would also be nice... ie. no effect if there's another imperial palace within 4 starlane jumps.
Various buildings have multiple stacking groups for their multiple effectsgroups. When doing this, make sure that you actually want it to be possible for a given target object to get both effects. Looking at the code, it appears that the first listed effect will always be applied first, so use order for precedence if multiple effectsgroups have the same stacking group.
Bigger bonuses (+15 ish) are OK, as long as they're late game content. The scale going to 100 doesn't matter if typical meter levels are around 10 for a given time during a game.
It's be nice if most of the techs and buildings had build times larger than 1 turn. Some variety of long build times a low cost per turn or high cost a low minimum time might be nice, as well, although keep in mind that with enough PP, a high per turn limit with low minimum turns is less restrictive than low per turn limit.
Don't use SetCurrent* meter effects. They probably don't work like you think.
Don't use conversational or judgemental language in building descriptions. It's not "unfortunate" that a building has a travel disrupting effect.
Also, setting max fuel and supply to -100 within 500 distance is a bit much. If having ships nearby disrupts the building, then have a condition do that by turning off the effects if a ship comes too close.
If you could, please add a stacking group to limit the imperial palace to only one construction meter bonus per planet. Appropriate scope limits would also be nice... ie. no effect if there's another imperial palace within 4 starlane jumps.
Re: Tech Tree Revision: Learning
That's true of course, but my idea was that perhaps larger planets could simply be intrinsically better for farming, since we kind of have the opposite for industry. Furthermore, it seemed intuitive that a larger planet would have a greater capacity for orbital farming out of proportion with its population. I'll get rid of it though, since it's unnecessary and makes it so there's way too many effects groups .Geoff the Medio wrote:You've got some planet size dependent bonuses for orbital farming. This isn't necessary or appropriate, as planets' output is already determined by multiplying the resource meter by the population, which is size dependent, making the total resource output alraedy size dependent.
UnderstoodVarious buildings have multiple stacking groups for their multiple effectsgroups. When doing this, make sure that you actually want it to be possible for a given target object to get both effects. Looking at the code, it appears that the first listed effect will always be applied first, so use order for precedence if multiple effectsgroups have the same stacking group.
Bigger bonuses (+15 ish) are OK, as long as they're late game content. The scale going to 100 doesn't matter if typical meter levels are around 10 for a given time during a game.
My plan was to keep costs low for testing purposes for now, but I'll definitely keep that in mind when I go over it for balancing.It's be nice if most of the techs and buildings had build times larger than 1 turn. Some variety of long build times a low cost per turn or high cost a low minimum time might be nice, as well, although keep in mind that with enough PP, a high per turn limit with low minimum turns is less restrictive than low per turn limit.
Did I use SetCurrent? I thought I may have used SetMax value = Target.Current. Is that acceptable?Don't use SetCurrent* meter effects. They probably don't work like you think.
Can I do that? I don't know the location of the full effects library, as you may have guessed, so I've just been working by what I've seen, and on clues from the stringtable. <edit> Just noticed you linked me to it in the other thread. Thanks. </edit> And yes, it would be much more reasonable to do that, then I could have it apply to non-empire ships too.Don't use conversational or judgemental language in building descriptions. It's not "unfortunate" that a building has a travel disrupting effect.
Also, setting max fuel and supply to -100 within 500 distance is a bit much. If having ships nearby disrupts the building, then have a condition do that by turning off the effects if a ship comes too close.
Understood. Thank you for your input.If you could, please add a stacking group to limit the imperial palace to only one construction meter bonus per planet. Appropriate scope limits would also be nice... ie. no effect if there's another imperial palace within 4 starlane jumps.
Warning: Antarans in dimensional portal are closer than they appear.
- Krikkitone
- Creative Contributor
- Posts: 1559
- Joined: Sat Sep 13, 2003 6:52 pm
Re: Tech Tree Revision: Learning
The benefit for larger planets is their sizeBigjoe5 wrote:That's true of course, but my idea was that perhaps larger planets could simply be intrinsically better for farming, since we kind of have the opposite for industry. Furthermore, it seemed intuitive that a larger planet would have a greater capacity for orbital farming out of proportion with its population. I'll get rid of it though, since it's unnecessary and makes it so there's way too many effects groups .Geoff the Medio wrote:You've got some planet size dependent bonuses for orbital farming. This isn't necessary or appropriate, as planets' output is already determined by multiplying the resource meter by the population, which is size dependent, making the total resource output alraedy size dependent.
(and EP->better farming)
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Tech Tree Revision: Learning
Yes, in BLD_MONUMENT_EXODUSBigjoe5 wrote:Did I use SetCurrent?Don't use SetCurrent* meter effects. They probably don't work like you think.
Almost certainly not. That's even more likely to not do what you think. And if it does do what you think, you're making it too complicated.I thought I may have used SetMax value = Target.Current. Is that acceptable?
Yes. Probably using the Number and WithinDistance conditions.Can I do that?Also, setting max fuel and supply to -100 within 500 distance is a bit much. If having ships nearby disrupts the building, then have a condition do that by turning off the effects if a ship comes too close.