Brainstorming Building, tech, specials

[Impaler]

Orgasmatron: +50 Happyness, -20 Resarch, Trade, Industry

[tzlaine]

We can't use percentages in the current version....

To be clear, percentage as modifications to values cannot be used, but percentages should (I think) be usable to indicate the chance that something will happen. So "10% chance of causing Grey Mass Incident" is fine, but not "-5% production".

Actually, I'm writing the Effects code so that you can do this. You should be able to say the Effect will do something like:

Code: Select all

Target.CurrentPopulation = Target.CurrentPopulation * 0.5

to kill off half the population on a planet. Here, Target is a proxy for each item in the scope of the Effect.

[Geoff the Medio]

You should be able to say the Effect will do something like:

Code: Select all

Target.CurrentPopulation = Target.CurrentPopulation * 0.5

to kill off half the population on a planet. Here, Target is a proxy for each item in the scope of the Effect.

We decided to omit that sort of thing from the v0.3 design because it's not associative with addition and subtraction. This isn't a problem if you can precisely control the order in which effects fire... but since there's no way to do that in v0.3 outside of a single effects group, we figured it was best not to have such an effect.

HOWEVER! We did have an idea to make multipliers associative with addition/subtration, which was to have each meter keep track of a "multiplier" value, separate from the "base meter value".

Base meter value would work like we're used to, with (only or primarily) additions and subtractions. Additions and subtractions are associative with eachother, so X + 4 + 2 - 6 = X - 6 + 4 + 2.

The multiplier value would be a separate value, that defaults to 1.0. Effects would only alter this with multiplication factors like 1.2, 0.5 or 19.2425. Multiplication is associative with itself, so X * 0.5 * 0.1 * 20 = X * 20 * 0.5 * 0.1.

The multiplier and base meter value are kept separate until the meter needs to be evaluated for some purpose. When that happens, the multiplier is multiplied by the base meter value to give an effective meter value. If the base meter value was 20 and the multiplier was 1.2, the effective meter value would be 24, which is the value that would be used for most purposes. (It might as well be possible to separately access the base value and multipliers for effect or condition parameters as well).

Anyway, if you're going to impliment multiplication, I'd suggest/request you do it as described here... or at least this way in addition to having a separate effect that applies a multiplier directly to the base meter value.

[drek]

We decided to omit that sort of thing from the v0.3 design....

Well, in this case, we as in you.

I deleted a whole bunch of my mails, which turned out to be a bad idea, cause it be cool to have a list of the changes to the effects doc compared to the implementation, so the wiki doc can be updated.

[tzlaine]

You should be able to say the Effect will do something like:

Code: Select all

Target.CurrentPopulation = Target.CurrentPopulation * 0.5

to kill off half the population on a planet. Here, Target is a proxy for each item in the scope of the Effect.

We decided to omit that sort of thing from the v0.3 design because it's not associative with addition and subtraction. This isn't a problem if you can precisely control the order in which effects fire... but since there's no way to do that in v0.3 outside of a single effects group, we figured it was best not to have such an effect.

HOWEVER! We did have an idea to make multipliers associative with addition/subtration, which was to have each meter keep track of a "multiplier" value, separate from the "base meter value".

Base meter value would work like we're used to, with (only or primarily) additions and subtractions. Additions and subtractions are associative with eachother, so X + 4 + 2 - 6 = X - 6 + 4 + 2.

The multiplier value would be a separate value, that defaults to 1.0. Effects would only alter this with multiplication factors like 1.2, 0.5 or 19.2425. Multiplication is associative with itself, so X * 0.5 * 0.1 * 20 = X * 20 * 0.5 * 0.1.

The multiplier and base meter value are kept separate until the meter needs to be evaluated for some purpose. When that happens, the multiplier is multiplied by the base meter value to give an effective meter value. If the base meter value was 20 and the multiplier was 1.2, the effective meter value would be 24, which is the value that would be used for most purposes. (It might as well be possible to separately access the base value and multipliers for effect or condition parameters as well).

Anyway, if you're going to impliment multiplication, I'd suggest/request you do it as described here... or at least this way in addition to having a separate effect that applies a multiplier directly to the base meter value.

I was only following orders. From the Effects Wiki:

Code: Select all

Numeric Parameters

Numeric parameters for some effects and some effects group scope or activation conditions may take the form of expressions involving constants, arithmetic operations and references to meter values (max or current) of the source object and/or target (scope) object.

Parameter Expression Operators

The arithmetic operations in parameter expressions are represented by their corresponding standard operators, and may include:

    * Addition, +
    * Subtraction, -
    * Multiplication, * 

Expressions take the form of a sum of terms, (having no mathematical brackets, () ). Terms are constants, references to meter values, or products thereof.

Programmers may restrict product terms to only having a single * operator each as in "5*3", or they may permit "chaining" of * operators, as in "5*3*2*5*1". Similarly, expressions may be limited to only a signle + or - operator, as in "4 + 2", or multiple +'s and/or -'s may be chained, as in "4 + 2 - 6 + 3".

Expressions are evaluated according to the standard order of operations rules, so multiplication operations (product terms) are evaluated first, then + or - operations between terms.

I've actually written this code already, and it supports arbitrarily complex arithmetic expressions involving +,-,*,/, and (). Constants and variables like Target.System.StarType are both supported in these expressions.

That said, I see your point. I'll make sure that all multiplications (or division) Effects happen before all addition (or subtraction) Effects. Does that sound ok?

[tzlaine]

Actually, now that I think about it, what I wrote is not doable.

This is because allowing arbitrary expressions might lead to:

Code: Select all

Target.CurrentPopulation = Target.CurrentPopulation * 0.5 + 10

Where does that sit in the chain of Effect execution so that the result is always deterministic? Maybe we just shouldn't worry about determinism so much.

[Geoff the Medio]

It didn't occur to me that accessing numeric properties of targets would let effects like target.currentpopulation = target.currentpopulation * 0.5 be done, which is unfortunate as doing so compeltely destroys order-independence of the results for multiple different effects.

I guess there's no good way to absolutely preserve causality from a coding perspective, without severely limiting the parameter values that can be used. We can impose some limits on content design to accomplish this, though, if deemed necessary.

It would still be nice to have separate "multiplier" and "base value" parts to each meter though. If the content designers don't write effects that specifically circumvent the separation of these (like AddToMeter(-0.5*target.metervalue)), then things should work out nicely for the most part... (that is, results mostly independent of effect firing order)

[guiguibaah]

Idea for Great wonder is as follows

Premise:
Great Wonders: Affect the system and neighboring systems 1 starlane away.
Wonders: Affect all planets in the system
Sub - Wonder: Affect the planet and moons

Functionality:

The Em emergency defence force (EDF) wonder is considered a GREAT Wonder. The EDF is comprised of about 300 industry points. When it is created, players can pick and choose a total of 200 industry points worth of of pre-designed ships from their design manifold.

By comparison:
Frigates are 20
Cruisers are 40
Battleships are 100
Titans are 600
Doom Stars are 1500

You could mix and match the number of ships in your EDF task force up to the point that they do not exceed 200 industry points. For example: 10 Frigates, or 5 frigates, 1 Battleship. etc...

EDF ships are the same as standard ships with an exception described below.

EDF ships, being "System Ships" by nature have more space to install weapons instead of fuel reservoirs and multi-use warp engines. As a result, EDF ships gain a 25% offensive and 25% defensive bonus.


How it works:

The EDF is automatically deployed when a planet within the system containing the great-wonder is attacked.

The EDF is automatically deployed when a planet within 1 starlane of the great wonder is attacked, but the EDF arrives after 1 combat turn has elapsed.

The wonder is a planet-warp boosting device, that instantly boosts the ships without needing jump drive. However in order to make the return jump, the ships are installed with a smaller single-use drive.

If the EDF survives the attack they return back to the home base within 1 turn.

If the EDF is completely destroyed, it takes a full 10 turns before they return to full complement.

If the EDF is partially destroyed, they can be redeployed in 4 turns.


You can update your EDF ship list whenever during the game, taking advantage of new technologies instantly.

EDF is only used for defensive purposes - cannot deploy the EDF if you are attacking a system / planet.


Conclusion:
The EDF Great Wonder option has less micromanagement than did the system ship defences of Moo3.

(Picture)

[emrys]

It didn't occur to me that accessing numeric properties of targets would let effects like target.currentpopulation = target.currentpopulation * 0.5 be done, which is unfortunate as doing so compeltely destroys order-independence of the results for multiple different effects.

I guess there's no good way to absolutely preserve causality from a coding perspective, without severely limiting the parameter values that can be used. We can impose some limits on content design to accomplish this, though, if deemed necessary.

It would still be nice to have separate "multiplier" and "base value" parts to each meter though. If the content designers don't write effects that specifically circumvent the separation of these (like AddToMeter(-0.5*target.metervalue)), then things should work out nicely for the most part... (that is, results mostly independent of effect firing order)

Suggestion for tzlaine regarding implementation.

The difficulty seems to come when the current values are used in setting the new value, and the current value when the next effet runs is therefore different.

The solution to this would be for each variable to expose five properties to be used in the effects scripting: current_multiplier, current_base, current_value (=current_base * current_multiplier), new_multiplier and new_base. The new_multiplier could only be used in scripts like "value.new_multiplier *= blah" (or equally /=), the new_offset could only be used as in "value.new_base += blah" (or of course -=). The old could only be used on the right hand side of equations.

At the start of script processing the new_multipliers would be set to 1 or the old multipler, depending on whether effects are evaluated once or from scratch every turn, and the new_base to 0 or the old base (same reason).

So to do "Target.CurrentPopulation = Target.CurrentPopulation * 0.5 + 10 " would strictly be impossible, but to do the equivalent "Target.CurrentPopulation = (Target.CurrentPopulation + 20)* 0.5" the scripter would write two lines:

Code: Select all

Target.CurrentPopulation.new_multiplier *= 0.5
Target.CurrentPopulation.new_offset += 20

Having run thorugh all the scripts you would then for each variable set
the old_values to the new_ones, and have the values ready for next turn.

this way you could still write complex expressions, e.g.

Code: Select all

Target.CurrentPopulation.new_multiplier *= IF ( Target.CurrentPopulation.old_value > 4) { 0.5} ELSE { Target.CurrentPopulation.old_value /2 }

and be sure that they would all function as expected independent of execution order, since each script has only access to the previous turns values, doesn't modifier them directly, and can only perform commutative operations on the values it can modify.

[Moriarty]

A number of the suggested buildings here have abilities that range over X starlane jumps.

Wouldn't it make more sense for them to all have a short effect range at the start, but the more advanced the empire becomes, the further their effects?

I mean the Original Stock exchanges were very limited in the areas they covered (i.e. the NYSE was originally founded in 1792 by a group of merchants and stockbrokers. It's effect would only have been local (probably not even statewide).
But now with the Internet etc, it's global.

Simialrly i'd suggest that the effects of these wonders become further ranging over time.

[Daveybaby]

You could replicate that effect by just having more advanced versions of buildings with longer range. So you first research stock market level 1, and build that, then once you have dont that you can research stock market level 2, and upgrade your level1 building, to give an effect over a broader area.

[Moriarty]

but wouldn't u then have to rebuild the buildings? Whereas general progression would keep things simpler for the same benefit.