Star Base Upgrades and the Over Discussed Constructor Spam Ideas!!

Much simpler: allow planets to "sponsor" starbases just like they currently sponsor shipyards. Then divert production directly to starbase upgrades, without constructor ships at all (which are abolished, other than for the initial creation of the starbase, to determine location). Show the progress bar directly in the starbase window.

A alternative of this would be to let shipyards sponsor starbases.

This would be less intrusive than the standard sponsorship. You don't have to mess with military spending, how military bonuses would affect starbase components, all the little details that change in going away from a constructor model. You in effect allow the shipyard to "create constructors" without it actually creating constructors.

Another option, though less elegant in my opinion, is to add the "request constructor" option into the mass command area (similar to upgrading ships).

Let me send a bulk command: All starbases that need "X module" request a constructor.

 Paul said something about maybe on this! on either planets or shipyards sponsoring the starbases. I know there is changes in the works for the starbases and constructors!

A combination of the above ideas could be abstracted as follows: 

- Drop the whole request constructor thing altogether

- When you build a component at a SB, give the user a list of shipyards (by distance) to "build" the component

- the component is queued at the shipyard, and added directly to the starbase on completion

- the cost of the component is inflated by distance from the shipyard

- optionally, the cost of the components could be influenced by the ZOI as well

ADVANTAGES

There is no need to design/build/manage hundreds of constructors.

The distance from shipyard penalty serves to penalise players for spamming starbases all over the map, as it now makes more sense to build within a decent range of a shipyard

You can then have a mechanic where different component cost different amounts of production, with higher tech modules costing more.

There is no need to manage sponsors, constructors, etc. 

Shipyards are kept busy building Sb components, instead of constructors.

It is easier for the player to customise his SB at any time, rather than to have to remember which SB must get which upgrades when the Upgrade Starbase icon pops up. The only thing the user then manages is the build queues at his shipyards.

DISADVANTAGES

Could take multiple ticks to build a component, whereas you can currently build a 4-constructor ship in 1 tick. Don;t have to account for travel time though.

You can't kill enemy constructors (no raiding). You would still need a constructor to build a starbase in the first place, and a 4-module constructor could build 4 starbases.

Good discussion so far this is what I'm seeing with the few replies to this point and what I could see working.

It seems everyone agrees there should be a build list. (To build module as constructor/construction point is available.)

There should be an option to auto build any new module as available (again as long as constructor/construction point is available).

If a similar format stays in place in the future, allow one to request their user made constructors with the following options...

• Allow shipyards to sponsor star bases.
• Add build command to keep creating/sending constructors as long as a sponsor needs one.

Alternative to that would be to let star bases build components with shipyards help as follows.

• Have star base select to build component and choose star base to sponsor them, once completed module is created.
• Have a distance factor closer shipyards build faster than distant shipyards or cost is increased.
• Star bases would still require constructors to be built initially.

What these suggestions help or fix.

• The build list and toggle box to build as available solves the tediousness of having to click and upgrade all star bases as one researches a weapon tech (some players have 100's of star bases).
• Shipyards sponsoring star bases and requesting constructors as long as needed solves, having to update the shipyard build list to ones custom constructor manually, then send to specific star base.
• Alternative just allows one to build modules as they can based on the ship yard sponsor, personally not a fan of this one but, will also keep things moving.

I know we all want to reduce SB micro, and some good ideas up above, but by NOT building constructors, then you eliminate the risk and time of the constructor's journey to the starbase.  You could have a starbase in enemy territory, with your entire fleet garrisoned to protect the immature SB.  Have a planet on the other side of the galaxy sponsor it (assuming engineer and pragmatic coordinated will work with this) and build up the starbase with no need to escort the constructor convoy.

Request Constructor is fine, with the gross exception that you cannot pick which type of constructor.  Some may be short range requests.  Some may need constructors with lots of engines.  Some Constructors might need to be high capacity constructors.  You can have all of these designs available, but cannot currently choose.  If request constructor was a shortcut to the nearest shipyard, this would could A LONG way in reducing the micro, and quite easy.

SB Governors where the SB requests their own constructors, build certain end goals and SB Designs, etc, will certainly not work to everyone's liking, and micro will have to continue.  

Therefore, just having a quick link to the nearest shipyard in the SB menu would be something simple to start out with.  However, when you select a constructor (or any additional ships while the window is open), they have automatic rally points set to the starbase, just like the current request constructor option.

This is pretty damn easy to do, and would help quite a lot IMO.

On the flip side, with this method I might no longer be able to send in a few full stocked constructors with my fleet, and then immediately build a fully defended military starbase. I would have to build the initial one and let it "slowly" build up to full.

This would actually be a benefit to the AI, who could focus on the problem of the starbase, instead of getting creative and killing the constructor train (which a human would know to do, but an AI would not).

Until I can select which constructor to use and, more importantly, where it is built the whole mechanic remains irrelevant to me. That's all the functionality I would like since I like to pick my modules manually depending on where they are.

I usually do all my production from at maximum 3-4 high production shipyards, I don't want it to queue somewhere (closest shipyard) that has only 5 manu per turn.

Excellent point, so request constructor should first show a list of all shipyards with distance and manufacturing points, so you can first select the appropriate shipyard.  

@stalker, I really would like the ability actually to build only 1 module per turn, but this can be accomplished in the current system as well, allowing you to spend only 1 constructor point per turn.  

As far as helping the AI, I just think the AI needs to grow up a bit.  It needs to learn to retreat defenseless ships nor send any constructors to a SB which has enemy forces anywhere near it....as a human would.  Giving 1 turn construction ability across a great distance isnt fair for anyone, human or AI.  You have to handle the logistics, period.

Starbase development should be a sponsor mechanic similar to that of Shipyards, and to prevent Starbases from developing when 'cut off' use a mechanic similar to that of freighter trade whereby the supply route can be raided.  Constructors are still necessary to drop the initial Starbase.

Constructor spam is the bane of this game and it needs to be hacked down, not merely pruned.

Yes. It's a trade off. I think the message is coming across loud-and-clear that we (this forum at least) thinks constructor micro makes the game less fun, and needs to be reduced. You point out an example of an exception: where fine control of constructors adds tactical depth. Accepted. It wouldn't have been in there in the first place if the devs didn't think it added something.

However (i) the AI isn't good this aspect of tactical play and, more importantly, (ii) it just isn't worth it: mostly, constructor micro gets in the way of the game, so let's find a way to eliminate it, and concentrate on finding other, better ways to improve tactical depth. We're not short of ideas about that: see, for many examples, the threads on carrier balance (especially mine!) and on military starbases.

Summary of workable interface ideas ...

1. request a specific constructor from a specific starbase

2. queue upgrades at the starbase, then auto-implement as "construction points" arrive on the constructors. This will eliminate guesswork as to what I wanted when the starbase window pops up,

The last issue then is the monitoring of progress ... would we just get a notice that the upgrade has happened, or can we manually check the queue on the starbase? Because surely we wouldn't get the full-screen SB window anymore, which i personally hate, because I have to close it to see where the starbase is to remind me what I wanted.

Gampelay options I am happy to leave to the devs to decide: e.g. whether to set a point limit for upgrades per turn, or to vary the cost of some upgrades.

Just to point out the contrariness of opinions....   Constructors are a big part of the charm of GalCiv.  They need to be celebrated for the fun they are.  They need to have even more usage as military starbases get figured out.  Yay, constructors!

I have this cloud of them building starbases for planets, claiming resources and relics, keeping my economy growing, being a visible and vulnerable indication of my economy's strength and growth.  Please do not make a dislike of constructors an axiom of this discussion.  It is not universal on the forums and it is possibly even less universal in the overall player base.  Constructors help make the economy and its growth an actual play mechanism as opposed to an automated system you set up and let run.  That makes a lot of difference to a lot of player types who may not haunt these forums.

That being said, I like some of the automation ideas and look forward to what happens in that field.  The present request constructor function isn't working for me, either.  I would really need the list of shipyards and list of constructors, probably the module build queue as well.  That seems like a lot to expect any time real soon, but it is what I am seeing in my game play.

This is the solution I tend to prefer.

All "fun" is of course subjective, but I think a larger number of folks find constructors deeply "unfun".

I'm very in favor of a military shipyard sponsoring a starbase and then having a que list on the starbase itself. This won't be perfect, but it will at least maintain the reduction in shipbuilding capacity that constructors are meant to incur.

Someone mentioned that we won't be able to snipe en-route constructor ships, that is true, but how often has anyone found that necessary in a war? The Starbases are not tough enough to warrant guerrilla warfare, and the AI not skilled enough to employ such a tactic anyways.

Annnd now you can (and should) just snipe the shipyard, which is generally immobile and thus, easier to find/target, but tougher to destroy.

This is my thoughts if we are constrained to the system more or less as-is. If not so constrained, preferably, I would have constructor ships be like workers in a RTS game, they build starbases and ship yards, using military funds (slowing all shipyards equally) but when completed, they are not destroyed/consumed and can be assigned to a new project. Constant upgrades means building a Constructor ship per Starbase and assigning it to it. Still induces SOME spam, but not nearly to the current extent, and actually makes the ship itself meaningful. Of course the ship's expense would have to be increased appropriately.

To be fair, there is like no mechanic in existence that would have universal support:)

I think the ideas being suggested here would still get you the meat of you what want:

1) Strategic Placement of Starbases: You still have an initial constructor, and still have to choose where that starbase goes. That would remain intact.

2) Choosing of SB modules: Most of the ideas here still allow you to choose what module your SB gets.

3) Growth over time: SBs still grow over time as new modules are researched and added.

4) A factor of your economy: SBs would not be free, they would still consume the manu provides from your starports, just as constructors do now.

Ultimately, most of the ideas presented here keep the strategic meat of the current system. You still make the same key decisions as before, it just removes the tedious middleman. Now is there some loss there....of course, everything is a tradeoff. But I firmly believe that the little bit of benefit is not worth the large amount of micromanagement that constructors currently require.

Durable constructors, in the sense of they are not used up in the building process, with each module posessing a build cost and the constructors having a build rate per turn base on tech level and maybe additional ship upgrades.

This isn't a bad idea. In GC3, constructors are basically spam, you rarely regret the loss of 1. Having a constructor be an expensive mobile shipyard you have to protect could add some dynamics to the play. 

Ofc, starbases are pretty weak, and currently easily replaced. I would have also have preferred a mechanism to make starbases more substantial, costly, and valuable, rather than the spam they are now. They cost next to nothing to maintain, and are virtually "free" econ boosters, for as many as you can stack on a planet.

I have to agree with erischild.  Though some better management options would be great, I love the constructor sub-game.  I rarely have to go to war (though it usually seems to find me) to win the game.  Maintaining a robust economy, and projecting a domineering influence, due to the ability to spam constructors, of all varieties, and needs, and to send them about staking my empire's domain, while fending off incursions, is my typical play style.  Unlike others, who like to abuse the sensor stacking on ships, I use my screen of star bases to provide my early warning system.  So, in short, other than being able to automate some of the build functions, and queuing, I am rather happy with the implementation of star bases and constructors in GC3.

The last 4X game that required GC3-levels of nannying was Colonization, with the trade caravans.  That was 20 years ago and, thankfully, things have moved on since then.  (A few 4Xs still make this mistake but none to the degree that GC3 does in the mid-late game.)

I'd be happy if the upcoming SB development tools meant that I didn't have to control endless fleets of constructors; I don't mind them being on the map in their droves but I do very much mind having to nanny every single one of them, every step of the way. 

'Light touch' SB management: yes please! 

'Busy work' SB management: just, no.

I like this idea and think it would be a great improvement over the current situation. But I do have a rather different idea that I think may work even better. I think starbase upgrades should track with progress on the tech tree and possession of resources. While I prefer the idea of shipyards sponsoring starbase development to what currently exists, I think an even better solution would be to do away with overt production altogether. Starbases should build their own modules (which is not unreasonable, given that shipyards manage to build all this other stuff by themselves as well). Construction of a given upgrade would commence as soon as a starbase has access to the tech needed to build it, and would last more or less time depending on a combination of the following factors:

• proximity to homeworld (governance/bureaucracy penalty)
• proximity to any owned world, or any allied world with a trade route (access to materials)
• cultural influence
• starbase population (a new stat that gradually increases based on security, influence, and a new "hull size" upgrade path. For instance, could make the generic "defence systems" upgrade instead a size upgrade, which provides a larger hull for more components, more personel, more defensive equipment, etc.)
• happiness (a new stat for on-starbase population, which should exist, though in relatively small numbers, and be based on a combo of cultural influence and relations with neighbouring powers)
• access to resources (i.e. if the starbase is itself mining durantium, it should receive a substantial bonus to its construction of armor upgrades)

You will all note that this unhinges starbases from dependence on the production of shipyards/planets. I think this is necessary to make micromanaging them less of a nightmare. I think that the addition of a population stat, coupled with a hull size upgrade path, makes sense of "who" is doing this on-starbase production (and who is sending out imaginary shuttles to go grab the materials needed to complete these upgrades). The "hull size" upgrade branch should provide more space for additional modules, population, and also for the starbase's total hull points to increase, a problem that I think currently makes starbases overly vulnerable to even the most low-end fleet in mid-late game.

One thing that may make this new system of starbase construction/management even more interesting would be the option to load a small amount of population (between 0.1-1.0) onto constructors that you build for the purposes of SB construction. Loading up a constructor heavily on population to give a starbase a kick-start in terms of its production will be a tough choice, especially in the early-mid game, when population on planets/colonies may be hard enough to come by. I like the risk/reward mechanism felt when you invest citizens into colony ships and transports, hoping their fragile cargoes will reach their destination intact, and think it would be appealing to have it extended to starbase construction. Even if you chose to settle a starbase with a "ghost crew" of 0.1, its population should naturally increase, tracking with hull size and in response to influence, proximity to well-populated planets, etc.

Looking forward to feedback on this different idea for fixing SBs!

I vote no on this.

I prefer making a strategic decision on which upgrades i want on which starbases, depending what they are mining, where they are located, which planets they are supporting, and and their proximity to vulnerable borders. This is also necessary given that it is inevitable that SB maintenance will be increased at some point to prevent SB spam, and maintenance will probably linked to components. i.e., you shouldn't get every upgrade on every starbase because it will kill your economy. Otherwise there is no game.

Kinda just feel like wish-listing...

Starbase-s would be more fun (IMO) if they were bigger, more powerful, but also rarer/more expensive constructs.

1) No more "types" all upgrades available, so you can mix and match and make things the way you want.

2) Fewer Starbases allowed next to each other, but have a larger area effect, and greater maintenance costs.

3) Eventually (with tech) ability to also act as a shipyard.

4) If built adjacent to a planet, than invasion of that planet is not possible until the Starbase is destroyed (due to #2, this will not be feasible for every planet). Alternatively, planets in area of effect have their planetary defense increased by various modules on the Starbase.

5) Constructors are permanent expensive ships that are needed to produce upgrades on Starbases. (Thus they can be destroyed to prevent a Starbase from becoming more powerful, and the player feels the pain). 

6) Starbases with an upgrade, can move, just as a Shipyard (AKA, super slowly).

In retrospect, this all seems do-able with modding... I general am not keen on making content changes mods, but it might be fun.

Why does it have to eliminate the risk?

  Under a shipyard-sponsor model the supply line could still be interdicted. The simplest way is to have a 'shipping lane' that can be blocked by a hostile fleet parking on it, similar to what freighter-initiated trade has now.

  However, as long as you have to send discrete 'constructors' across the map, you can't get rid of the micro, and that micro is far more trouble than any strategic implications of being able to intercept them are worth - especially since it doesn't happen now (unless you allow it to) because if you're building a starbase somewhere hostile and far away you can just send a group of constructors there alongside a defending fleet and build the thing in one turn.

One of the weak areas on starbases is the 200 hitpoint limit. If starbases also had a level linked to maintenance cost and the number type of upgrades you could add it would help a lot.

I.e.

a level 1 starbases has 200hp but can only install components up to a certain tech level and dock a max of 20 logistic points of ships.

A level 2 starbase might have 400 hp and access to a wider range of modules.

And you might go up to a level 4 or 5 starbases with a 60 logistic point hangar.

Basically if you are prepared to pay the maintenance you should be able to build a 1000hp monster that will not go down to some random medium hulled scout but require a significant fleet to take down.