Right now the autobuild just picks up what's cheaper.
As if you build a factory, next factory's cost is up 75 production points and next lab's cost is up 50 pp and vice-versa for a lab built, this leads to factory->lab->factory->lab, etc.

The thing is, it's not terribly effecient.
It doesn't take into account industry and science buildings levels, it doesn't take into account race affinity.
All in all, it's a placeholder.

UPD: nevermind, found a bug in my model, updating my thoughts.
Here's the updated model if you're interested - http://rghost.ru/download/7nMhdcFxr/e86 ... iSTest.zip

Once we add the production queue, the autobuild feature should be less important or even disabled.

faijeya wrote:It doesn't take into account industry and science buildings levels, it doesn't take into account race affinity.
All in all, it's a placeholder.

Yeah, it's definitely a placeholder behavior. The first change I think we need to make here is to the way production complete reports are handled -- right now, the interface is still more cumbersome than it really needs to be. Autobuild logic of some sort will probably remain in the game -- but Arioch and I are still debating the details. But the present factory/lab/factory/lab sequence will certainly change.

Ok, well, so what I meant to say if I didn't derp the understaffed buildings calculation and didn't have to go home already.
It's a shame that a derped (used a limiting variable instead of the counter in the loop) model gave more lively results.

My model is somewhat flawed, because I didn't replicate the growth after 1/2 of planet capacity true to the game.
I just did a "close enough" 95% of the multiplier (0,025) each turn.
But that shouldn't really impact the results.

Also I found out that I switched industry and science buildings levels in the output. My bad.


Ok, while the current placeholder is ineffective, the optimal strategy is very straightforward and boring, with few outlying cases.
Either you do all labs if you want maximum cumulative research output in the long run, either you do all factories.
Increasing costs do not help even a little.

And if you want it balanced with a 50/50 split, doing factories first is not really faster (15-20%%), as the brunt of the production lies on your population and factories have a fixed bonus.

This leads to the same building strategies for all races whatever production per million you set.
Anyway it's all linear and the pattern won't change.

While increasing buildings cost is clever, I don't really think it can add variety.
I'll fiddle with the added cost tomorrow, but I don't hold my breath.
The only hope here is in the farming mechanics as it will influence the population growth and may introduce some non-linearity via it.


And that's why this:

Arioch wrote:Once we add the production queue, the autobuild feature should be less important or even disabled.

makes me worry, because disabling autobuild will:
- give a short-term gain of filling out the early game for the first few runs
- heavily impact the mid and late game pace
- add unneeded micromanagement, because the optimal strategy is the same for most cases and all races


Well, the philosophical question I wanted to ask is why not embrace the completely deterministic system and give both the player and the AI optimal autobuild solutions for a variety of goals?
Like "I want this backwater planet to be a research center and I want that border planet to be fortified as soon as possible".

This way the player makes strategic solutions and if need arises, tries to change gears without using the clutch.
And the AI may this way create much more coherent colonies for the player to capture, instead of "so what were they building here" giving "aha, I captured their main think tank!"

As sending out an unsigned .exe is not exactly the best way to distribute a model, I've just uploaded the whole MSVS project with a built .exe in it (it doesn't matter, debug or release).

The link is in the top post.

What you suggest is a kind of macro gouverneur system? For example I have a (played defined?) macro button which says: make this planet into a typical "fortress planet". Or make this planet a typical "production planet". If yes, then it would save micromanagement time and I am for it.

faijeya wrote:I've just uploaded the whole MSVS project with a built .exe in it (it doesn't matter, debug or release).

Nice model! I think it makes sense that, assuming you're aiming for a mix of science and production bonuses, building all the factories first, followed by labs, is going to be optimal over a long enough time period. Though in a real game, getting certain technologies quickly may well justify sacrificing a bit of the long term potential for a short-term gain. And, of course, the option of rush-building some of your improvements also further complicates the situation. The present AI, for example, is simply alternating improvement types (probably not the best strategy, I'll admit), but, it's also constantly rush-building production, whenever there's money to do so.

More generally, if you continue to be inspired to play around with these sorts of economic models, you should be aware that many of the core formulas can be found in the Lua State\ folder. Some of them are fairly human-readable. (For example, the improvement efficiency formula is on line 261 of improvements.lua). Beyond that, you might also find it interesting to look at the modder's orientation page (which is something I may update and expand a bit if we get much demand for it).

faijeya wrote:

Arioch wrote:Once we add the production queue, the autobuild feature should be less important or even disabled.

makes me worry, because disabling autobuild will:
- give a short-term gain of filling out the early game for the first few runs
- heavily impact the mid and late game pace
- add unneeded micromanagement, because the optimal strategy is the same for most cases and all races

The autobuild is a good feature to help reduce late-game micromanagement, but in my opinion it shouldn't be on by default. If player choice is not required in the construction of infrastructure, and the autobuild can reliably make optimal choices right from the beginning of the game, then the infrastructure system is irrelevant and should be removed. I don't think that's the case, even with only two options, and I expect the addition of new infrastructure types to improve the situation.

enpi wrote:What you suggest is a kind of macro gouverneur system?

More or less.
If there is a handful of optimal build-orders, I believe it may be better to just embrace it, leaving the manual assignment available, but entirely optional.

sven wrote:Nice model! I think it makes sense that, assuming you're aiming for a mix of science and production bonuses, building all the factories first, followed by labs, is going to be optimal over a long enough time period.

In a certain corner case (7-slot gaia) it's more optimal to build three factories, then three labs, then the last factory, though the margin isn't that big.

The thing is that the buildings are not that important optional.
If I get the current vision right, small planets are not meant to be useful (and they aren't for a variety of reasons), and for sizes 12+ (the only planets worth colonizing in my experience) and default 50/50 split, factories input will start being noticeable only at level 3.

sven wrote:Though in a real game, getting certain technologies quickly may well justify sacrificing a bit of the long term potential for a short-term gain.

Well, I may be wrong here, but I feel that the tech tree is currently too convoluted to keep it in mind and adjust colony development accordingly.
I can't tell for every player, but I believe that usually people sacrifice lesser-needed techs instead.

sven wrote:And, of course, the option of rush-building some of your improvements also further complicates the situation.
The present AI, for example, is simply alternating improvement types (probably not the best strategy, I'll admit), but, it's also constantly rush-building production, whenever there's money to do so.

I'll add this to the model at Monday, as I'm already counting the money gained, but I sincerely doubt it changes the picture.
The output of a colony depends mainly at the population, as factories and labs are standalone (do not influence the population stats) and, to drive the point further, are dependent on the population count.

If we do not rush-buy everything at once, these buildings are just left unattended (if my population growth isn't way off, buildings stay empty or not fully occupied for some time even without buying them).
If we do rush-buy everything at once, that makes the question of buildings order kinda moot.

sven wrote:More generally, if you continue to be inspired to play around with these sorts of economic models, you should be aware that many of the core formulas can be found in the Lua State\ folder.

Oh, my.
And I tried to reverse-engineer the population growth by a polynomial or two.

I've got one concern though.
You've went to great length to create an honest implementation of multi-racial multi-environment growth model.
However, the script explicitly does not allow less than 1 million of a race on the planet.
This means there can't be any gameplay mechanism for some race just to get to a planet and stay there, no stowaways, no emigrants, nothing.
This in its own turn means that a multi-racial colony can either:
- be created intentionally for some weird reason, as bonuses for shipping a race with an another race are not really transparent
- be created by settling on a planet with natives
- be created by invading a colony and boosting it with your own population

While colonies with two races are bound to be in pretty much every run (imperials, gaia, natives), can you take a look how many three-race colonies were there in submitted games?
I'm concerned there will be a handful of them and this, if true, will probably mean that the bonuses of a melting pot should be more emphasized, both in game mechanics (with additional mechanisms) and in UI.

sven wrote:(For example, the improvement efficiency formula is on line 261 of improvements.lua).

Ow, I love Q3's fast inverse square root as much as the next guy, but return round | 7.662143601261782*(1 - exp(-0.07478070085209826*slots)) fills me with dread on par with an uncommented regexp.
Just couldn't not mention it.

Ok, so now to me being dumb.
For some reason it stuck in my mind that population enables buildings one by one and is not spread thin across them.
Rechecked the game, and it says the same 0,2 + 0,8*(pop_available/pop_needed) right there.
Well, one more thing to fix and to look at results.

sven wrote:Beyond that, you might also find it interesting to look at the modder's orientation page (which is something I may update and expand a bit if we get much demand for it).

Well, I'm not a real programmer.
Hypothetically, there might have been a short period when I got money for being a "software engineer", but even if I was, it was long ago.
Anyway, I'll probably wait for a finished version of mechanisms I'm particularly interested in before doing any proof-of-concepts.

Arioch wrote:The autobuild is a good feature to help reduce late-game micromanagement, but in my opinion it shouldn't be on by default. If player choice is not required in the construction of infrastructure, and the autobuild can reliably make optimal choices right from the beginning of the game, then the infrastructure system is irrelevant and should be removed. I don't think that's the case, even with only two options, and I expect the addition of new infrastructure types to improve the situation.

That's entirely your call to make.
Personally, I feel that:
- the always-on autobuild is crucial for maintaining the light pace of the game (I trudged through six hours of GC3 today and went home with an aching head)
- the infrastructure system is crucial for these rare, but enjoyable moments when you really have to make a judgement call
- the lull at the start of the game felt by some players can be mitigated by other means

It's really close to MOO1's colony management system, where the possibility to just leave the new colony be and it'll grow ok was very enjoyable.
Sure, transferring pop, cloning, etc helped make it faster, but you could just leave it if you felt like it.

faijeya wrote:Oh, my.
And I tried to reverse-engineer the population growth by a polynomial or two.

Don't be overly intimidated by pop_growth.lua -- nearly all of the complex logic is involved in the the calculation of population *caps* -- the heart of the growth model is presently very simple.

The idea is just that each race grows by a static mult (determined by habitat affinity and racial traits) X MIN(space remaining, current pop).

And that's why the growth curve changes when you pass 50% population. As you noticed, the rate changes a bit when the planet is nearly full -- but that's just a kludge to avoid asymptotic convergence.

In the case of a multi-species colony, what "space remaining" means can get pretty complex, but, in single race situations, there's really not much to it.

faijeya wrote:I've got one concern though.
You've went to great length to create an honest implementation of multi-racial multi-environment growth model.
However, the script explicitly does not allow less than 1 million of a race on the planet.

I actually commented out this part of the code last week -- as of the latest builds, we are allowing < 1 million population sizes. They're just quite rare, in practice. (But they can happen, generally in response to planetary bombardment.)

faijeya wrote:- be created intentionally for some weird reason, as bonuses for shipping a race with an another race are not really transparent

Yeah, as I've said in other threads, this is something I need to improve. Mixed population planets are intended to have the potential to be very strong (powerful racial synergies were a feature of MOO2 I liked, and wanted to elaborate on in SiS). But, right now, I think most people aren't noticing just how valuable it is to build a multi-racial empire.

I also think we need to add some drawbacks to multi-racial colonies (and the morale system is intended to play a significant role in that), right now, they're really *too* strong.

faijeya wrote:The output of a colony depends mainly at the population, as factories and labs are standalone (do not influence the population stats) and, to drive the point further, are dependent on the population count.

Yeah, you may be overstating things a bit -- but it's certainly true that improvement choice matters a lot less on big worlds than it does on smaller ones.

And I suspect that's not a good thing. I picked the "flat bonus" model for improvements because it seemed pretty workable, and I'm a fan of transparent rule mechanics wherever possible. But, given the complexities of the under-staffing penalty, the production system isn't really *that* transparent as is -- and I suspect that a more sophisticated model, one that implies that player's choices have a bigger impact on the production of their best worlds, might well be an improvement.

When farms and mines go into the game, we'll probably revisit the core rules around just how improvements boost production. I also think decreasing the total number of improvements per-planet (while boosting their impact per-improvement) might be worth looking at. If what you want is just to build nothing but factories, or nothing but labs, making you queue up 6-7 build-lab orders may be a bit excessive. But queuing up 2 or 3, assuming a reasonably good build queue UI, really isn't much more onerous than setting the planetary governor to "research mode" or something similar -- and could have pretty much the same effect.

Sorry for the delay, had some work to do.
Either way, here's an updated version, with proper understaffed calculations and a "rush buy" checkbox - http://rghost.ru/download/7QR8nWJfx/ceb ... iSTest.zip

Rush buy indeed makes the optimal strategies even more pronounced, as there's no need to build factories even if you want a relatively short-term (80-90 turns) science output.


Queueing of a conquered planet distracts you from flying ships and breaking things and, while not complicated in itself, may be frustrating for quite a large number of players who just can't let the asset do nothing.