The problem that I have is that you need to be involved in every step of the process to build up a starbase. You need your planet building ships, you need those ships to be constructors, you have to add to the queue each constructor you want 1 unit at a time, you then have to make sure they reach the starbase, and then you have to choose which modules to add to the starbase. The tools that you do get is the ability to use rally points, and the ability to add multiple constructor modules to a ship.

I find that it is usually less trouble to have a solar system to take care of its own starbase development than to have one somewhere else take care of things. This means local shipyard(s) building constructors. If they build them far away, not only are they going to take time to arrive, but I might also forget what I was doing with them (were they supposed go here or there?).

Anyways, whats this about starbases being more ship than planet? I disagree, they seem more planet than ship. If they were more ship like, I would imagine that they start out as a empty hull that you design in the ship editor. From there, you put modules on the starbase, even multiple modules of the same type. Some techs might give you more room to put stuff, miniaturize modules, or even unlock larger starbase sizes. At this time, a starbase is an immobile thing that you build with a constructor (a planet is an immobile thing that you colonize with a colony ship), that you gradually add stuff to or build up over time instead of building it complete at shipyard. Even the ability to customize them is more limited than planets. You can't put multiple factory assist modules on a starbase unless the game designer or modder decided that option existed before hand, while a planet can usually expect to be able to build multiple factories.

In lieu of responding directly, I'll give my typical meta-response, in which I see this problem-instance as one exemplar within a (much) larger space of game ideas.  4X is (surprise!) not the only genre that exhibits this symptom.  Hence, my arch-solution to the problem category will also somewhat transcend a 4X's scope.

3-4 minutes You do not fully grasp how much micro sucks, young grasshopper.  By turn 60, I'm already up to 10-20 minutes per turn (because I micro everything optimally), so I never even get to the point where I need to worry about quad-ctors.  Still, I fully agree that repetitive micro is less fun than playing those other games.  Or lifting weights.  Or grading homeworks for pay.

First, I'll pop up one tier and broaden my magpie-eye's view to encompass many game genres.  I've been a dev, I'm a C++ guru (hint: read Alexandrescu), and I daydream of being a designer, so I often ponder at this exalted level.  (Many of these ideas recur from my previous posts, but I'll add some new content, honest.)

A.  Simple UI Idioms, and the Click-Only UI

Many genres start out with beautifully simple ideas.  They provide the player with simple controls, which are primitive, atomic, and low-level: basically, you click once (or a few times) to trigger the special action.  Then they cast these primitives aloft willy-nilly, and allow the full power of conscious human cleverness to maximize output, efficacy, or whatever.  Some exemplars:

• collectible card game (CCG), whether physical or digital.  A card has tap state: it is either untapped, or tapped.  UI primitve: You tap your card to trigger an action.
• board game (Third Reich).  Armor's mobility is modeled via the breakthrough attack mechanism.  Combat has two phases.  In phase 1, you may declare an attack of 1+ armor units, and declare a mobile stack of nearby armor that does not participate, but only waits.  If you win and advance, your mobile stack gets breakthrough movement to pour through the gap (but usually you can only walk 1 hex into enemy armor's interlocking zone-of-control).  In phase 2, your breakthrough armor units may attack again, and you may drop your (singleton and very precious) paratroop unit onto the enemy 2nd line and gamble on a 1-1 exchange, which punches a 2nd hole.  Any breakthrough armor that didn't attack can now burrow through both holes and fan out behind enemy lines.  (Nobody ever has enough units to make three full lines of defense.)
• RPG (paper or digital).  Rounds, and actions per round.
• sports, e.g. gridiron football.  You may lateral the ball.  A lateral or backward pass is a lateral.  Primitive action: You throw the ball once.
• 4X (GC3/FE).  Starbases/outposts are created/upgraded by constructor modules/pioneers.  UI primitives: You build 1 ship, send it, and consume it to upgrade.

Primitive actions can be combined and composed into sequences.  This is way deeper than games; it pervades much of human endeavor, including programming languages, engineering, and even business ventures for manufacturing of goods.  Also, human players are very clever!  Hence, some clever people will deep-think through the entire set of all special abilities within one game, and devise complex in-game engines that combine many individual primitives synergistically, resulting in exponential or outrageous net effect.

• CCG: Any 1-turn kill combo.  These typically invest an intricate combination to force open one attack channel, render yourself unblockable (or similar) along it, and preemptively neutralize all possible counters.  Other clockwork combo-categories exist:
• Simple chaining.  e.g. two cards both have the ability "tap and target friendly X to give him +Y".  So every single turn, you tap them both.  Essentially, those three cards become one indivisible chunk (like an object in C++), and you want to call its operator()(), without repeating 3 mouse clicks or 3 lines of code every single time.  Gosh, it'd be nice if ...
  
• Positive feedback engine.  Most CCGs equate a card draw with a resource cost: some cards let you buy more card draws by paying.  Some others have goofball abilities that pay you back when $X occurs.  Combine those in wacky ways, and you can net a profit.  This can be about an 8-card subset that you squeeze into a 40-card competition deck, which when fully deployed and running becomes very much like a subroutine at the start of every k turns: tap this, tap that, do this, feed this to that, and you net +m resources and side benefits i and j.  The complexity is its own deterrent, and generally all combos (in every CCG!) lose to Cheese Speed or Cheese Beatdown.  But if you ever think one up and get it going ... it can be the most cackling, knee-slapping, seat-bouncing fun you'll have in two weeks of cutthroat play.
• Turn-1 kill deck.  Combines both of the above.  Also useful as a theoretical exercise in CCG deck construction.  At least 2 exist in M:tG (the Stroke deck and 1 other).  At least 1 exists in Chron X (Codeslinger + Lancer Rifle).  None exist in Sanctum, because it's half-eCCG, half-board game, and you can't physically achieve the board game win condition on turn 1.
• The M:tG Stroke turn-1 kill deck uses some of the Power 9 (Lotus, moxen) for instant mana, something to make card draws pay you mana(?), deck recursion to ensure that you see everything twice (so that deck sequence for the 1st time through your deck is irrelevant), and mana batteries as a 7-bit register to count up to (i.e. store/stockpile) 127 mana.  Then it Strokes your opponent's deck for 125 cards in the top of the 1st inning, which usually wins instantly by decking her.  It is beautiful when it goes off.  Your opponent is entitled to force you to play by the rules and physically tap every single card, exactly in sequence, which can result in several hundred separate hand/card actions over 10-15 minutes.  This might be half the fun, because the entire store and five bystanders on the sidewalk will crowd around your table just to watch it, like Golden State's bench when Klay Thompson kept hitting all those 3s.  (Seriously, tho ... build yourself a Lego Mindstorm 8-bit binary register, and watch it count from 0000 0000 to 0111 1111, and probably you'll be bored before it's done.)  Maybe after twenty such wins (or two) ... the novelty/excitement wears off, and it just becomes tedium.
• board game (Third Reich): The oddball/weird mechanism of breakthrough attacks instantly emerges as the uber-arch-tactic in the game.  Tactical skill in the game consists largely of how well you can set up and conduct breakthroughs 3 turns out of every 4.  Conversely, defensive skill, and 95%+ of defensive positioning, consists of preventing breakthroughs (or knowing when to sacrifice half you nation's land space and retreat to avoid an even worse encirclement -- which is actually historically accurate).  Ergo, most of the game consists of both sides hypothetically-doodling all possible breakthrough-gatherings of local forces.  So it should be the UI primitive, and not rely on the (mind-numbingly laborious) manual repetition of click-only primitives.
• RPG: I suppose teamwork amongst a party can be an emergent, scriptable effect.  Hilarious: it's very similar to a good gridiron football team: your O-line (fighters, paladins, maybe a cleric) stops the big baddies' dumb rush, your QBs (mages, maybe archers) bomb/snipe from safety, your trainers (clerics) heal whomever needs it.
• Battle preamble.  In some digital RPGs, and maybe Runequest, there are no Fireball-class spells of mass destruction.  Instead, you have little pump-up spells.  So before, or at the start of, every battle, you run through a canned script of these pump-ups, where your backline spellcasters' first 1-3 rounds of actions are all scripted by rote.  In classless RPGs (cf. Jeff Vogel's Exile/Avernum), I happily exploit this by having my dumb jocks take level 1 in mage and cleric spells, just so they can cast a few weenie pump-ups and heals.  It's by far the best use of those skill points.  In Runequest, we joke that this is your hallway habit, as every adventuring group pauses outside every closed door and casts 1-2 rounds of battle magic on themselves before they open it.
• Sports: You can script a trick-play punt return, e.g. a lateral (or fake lateral).  You can't quite script The Play (seven laterals for a game-winning TD), but it's happened so often that it's become a meme.  (In rugby, you do script and practice it, since the rules of the game reward higher risk.)
• 4X (SE5).  Tactical combat gets to be not-fun when you realize you've played the same combat out a hundred times (and each one is wasting 2-5 minutes wall clock time).  Many of my tactical combats follow the same high-level program: { fly away until point defense kills all fighters; fly circles until antiprotons outrange all ships' cannons; weave sine curve around planet's missile range until bombardment kills all platforms; bring transport and drop troops; speed up to 8x and wait out tactical clock }.  The details change, but the program is always the same.  Monotony is a special kind of gamer hell.

B.  Composition of Primitives

In many game genres, the set of primitive elements in the game space hits some critical threshold that allows fantastic, eye-popping engines (Rube Goldberg machines, clockwork devices) to be embedded.  These are often emergent constructs that nobody could anticipate, because they rely on intricate combinations of primitives that were not fully comprehended by any of the primitives' designers.  Human ingenuity will find them!  (and then open competition will kill them off, but that's a different problem)

But having found them ... you're still mostly forced to use the same click-only UI to manually walk through your intricate clockwork program, one step at a time.  Very few game genres explicitly acknowledge the existence of composition of primitives as a 1st-class element, and provide higher-level UI or organizational support for them.  (In the real world, we do exactly this, hence we have assembly lines, server farms, functions in all programming and script languages, and classes in Java/C#/C++.)  I loosely conjecture that this lack of support arises from -- a collective smallness of vision?

From a CS standpoint, composition of primitives can give you function call, which is "halfway" to being Turing-complete.  (Specifically, conditional and iteration suffices to be Turing-complete(!).  Function call allows recursion, which subsumes iteration -- ergo, Lisp.  So composition + conditional suffices.  Hence, composition alone is already very powerful -- and in every endeavor except gaming, we've acknowledged this by making composition be a primitive language construct, and building wonders on top of it.)

C.  Lifting the Level: Composition through ... Automation?

Hence, I see this not as simply an issue of GC3 constructor spam for starbase upgrades, but (much) more broadly: as the gap between primitives and composition.  Beyond the click-only UI, what can we add?  The obvious lesson from programming et al. is: just bite the bullet and go to a full script language, with a complete game engine API under it.  Make it Turing-complete, because it'll end up there anyways.  I will, of course, always lean in this direction, because I think it is the arch-solution to this problem-category, across all genres.

• 4X (GC3): Starbase constructor spam is similar to the M:tG Stroke deck's inherent tedium.  There's a simple goal at the top (upgrade this starbase along path I-J-K-L-M), with a complex clockwork underneath it (planets build ships, ships fly to starbase, starbase alerts you).  With a click-only UI, we must manually click every decision in that clockwork by ourselves, with our mouse and the wall clock.  (I would do this regardless, because I micro everything ... but even I don't enjoy it.)  Some candidate solution-branches:
• Replace constructors with something else.  (cf. the OP's post)  The intent is good, but ... realistically, your vision is probably not going to trump the designer's vision at this late stage.  From GC2 until now, the constructor-to-starbase mechanism has been deeply etched into the design for many, many years.  Nobody is going to just throw all of that away in the last ~3 months before release.
• Automate the constructors.  (numerous)  Many posters have suggested a project-like link from 1 planet to 1 starbase, which would compose the primitives of UPSTAB { build constructor; constructor goto starbase; starbase upgrade path }.  Maybe then as long as this UPSTAB project runs on that planet, it will quietly do that until the starbase reports that it's done.
• Lisp(-ish) script.  (me)  Then you could script the simple UPSTAB program yourself, or modify/customize it however you see fit.
• CCG: I have pondered a novel new dimension in eCCGs, which embraces exactly this idea (in all its sprawling splendor).  First, I'll draw a contrast:
• Most (e)CCGs that provide tap-state implicitly assume (by forcing a click-only UI upon you) that most decks, most of the time, don't tap.  That is, most cards (in successful open competition decks) don't tap, or tap only to pump themselves up (i.e. zero interdependence on any combo), or tap in very simple combos: pairs, or maybe trios.  Tapping is presumed to be an abnormal action.  Ergo, you are subtly discouraged from building intricate, tap-heavy, combo-dependent and sequence-critical decks, which is tantamount to encouraging players to build only the simplistic decks (like Cheese Speed or Big Stupid Mil).
• Many CCGs also tolerate the existence of these clockwork combos.  By hook or by crook, they did end up in the union of all card sets.  No designer ever sat down and explicitly decided I shall put this card into the game so that it enables that huge combo.  Instead, they emerged through competition and human cleverness.  You can build such decks if you want to, and you'll win a few games that you shouldn't have.  Generally, they are their own punishment.  They're hard to get running, they don't win enough to be dominant, and they're inconvenient to micromanage.  Nothing in the game's UI or rules helps you to manage the complexity; you just click with the mouse.
• Hence, I postulate a new (tier of) eCCG: the Rube Goldberg mousetrap CCG.  I explicitly lift clockwork combos to 1st-class by establishing that the premise of the game is that you shall construct clockworks, and that your clockwork will fight my clockwork.  For example, you may need to build 3 separate pyramids of card-groups, respectively a Battle Group, a Lookup Table, and a Mana Market (haha!), which interact in wacky ways.  Tapping evolves from being an abnormal action, subtly discouraged, to being a nigh-mandatory action, and even then not enough.  The whole point is to out-do the other guy's mousetrap by constructing a better mousetrap.
• The UI explicitly helps you do this by defining higher-level UI idioms (obviously borrowing from 40 years of programming languages).  Just for example:
• Tap-chains: a chain of cards, like dominoes (or groups in PowerPoint).  Tap the chain and they all tap in sequence.
• Tap-trees: a chain with branching factor 2+
• Target-graphs: drag-and-drop composable as explicit arcs that glow and hover over the board.  Lets you lock-in a target (so that your tap-tree doesn't bug you every time).
• In/out flows: Some taps produce a new card or thing (e.g. "tap and pay 2 cyber to create Shock Treatment in your hand").  Some taps consume a thing (e.g. "tap and target a card in hand: discard that card to gain $X").  You compose outputs to inputs with drag-and-drop links, as a graph editor.  (During play, they're animated with little icons scurrying down the arcs, like a EE circuit emulator.)
• Target currying: A tap-tree may consist of 5 dudes who all target $Q to ding $Q.  Click "curry target" to create a new target-box, drag-and-drop from all 5 dudes' I-need-a-target box to the new target box, and your tap-tree now all targets $Q, where $Q is a variable.  Your tap-tree could chain together N-1 mandatory inputs per card, so that all cards are happy except they all need a $Q, which is not yet specified.  On each turn, you tap your tree and the UI engine asks you, Who is $Q for this salvo?  Ergo, a fire team pattern (which is historically accurate in squad-level tactical combat).  More generally, currying allows you to partially-satisfy (freeze, bind, lock in) some arguments of an n-ary function, which reduces the remnant to a k-ary function, for k < n.
• Hence, halfway through a game in progress, your game board will look like a freeway overpass or CPU circuit, with cards organized into trees, graph links arching over groups of card-trees, target links from your card-trees to her hapless target-cards, ..., and maybe glider-proteins spawning off your opponent's own engine that you just took over, encoded on your injected card-engine's introns.  That's a lifting-of-level.  It's the 3rd dimension of complexity floating above and over every 2D CCG on a flat tabletop (and, by extension, over every board game, RPG castle grid, and 2D 4X).  The set of your individual cards in play would be a tiny, tiny fraction of the real complexity.  And you're dueling the other clockwork at the level of high-level patterns you freely devise, way above the details of one card.
• Ergo, I think this can only be an eCCG.  You can't do this with paper cards on a tabletop, because the premise is that we explicitly add the layers above both of those.
• The card set itself also explicitly supports such clockworks by simply ... embracing the complexity.  Have cards that do input/output, some that do conditionals, some that chain linearly (or chain-react), some that target friendly units, some that target enemy things.  Very soon (I think), the union of card capabilities will cross the threshold and enable clockworks to be composed.
• Finally, the game shall come with a few stock AIs ... and each one is simply a mediocre mousetrap, which utterly crushes your card-at-a-time sheep or newbie deck, until you learn to build a more powerful mousetrap.  For example, maybe your best stud asset is a 4, but my weenies all benefit from my Artillery tap-tree, so they'll eventually be 2+9s, for cheaper, and I have more of them.  You better build up your own tap-tree that pumps your guys by +8 ... or does other things that negate my tap-trees.  Briefly, if your side of the board is less cluttered with your own 3D floating arcs, links, chains, groups, and other active links -- then you're doing it wrong, and you're probably losing.  The lesson is also the incentive.

Getting back to GC3 constructor spam: I am ultimately agnostic about this issue.

• Yes, it's micro-intensive.  But I'm already in micro-hell, so I don't see that as any more of a problem than the rest of GC3's UI already is
• I trust Stardock to have some anti-spam tricks up their sleeves.  I'm willing to wait for Beta 5 (and Beta 6 if there is such a thing)
• Even if there is no magic solution in GC3 Release, that's not much of a show-stopper for me.  It means my market niche is still fallow, and maybe I can still get there first

https://forums.galciv3.com/460951. What do you all think about this idea?

It isn't just an issue of unfun.  It also isn't sexy to have your galaxy map covered in constructors.  

@Gilmoy:  As far as microing for 20 minutes every turn, that's one way to play.   the gain you will get from micro'ing colonial production each turn for each colony so you don't get production over run, and putting the rest to economy or research might get you a noticeable edge in the early game.  Late game due to overrun not being lost, it is less noticeable.    You *can* micro all 30 planets in your empire this way, but the gain you will get is less than the benefit of a single starbase boosting a single planet.   

Failing to micro my planets the way you suggest won't cause me to lose the game.   Failure to maintain optimal starbase coverage will.



@Turkwise: As far as it being a bug to build multiple starbases,  I do not believe it is.  I too assumed 1 per planet was the most that was useful, until I watched them do it in a dev stream a couple weeks ago and I've been fidgeting with it ever sense.  


After those two weeks of playing with it, I came to the conclusions I posted above.   

@Jhanglyn I dont dislike your solution.

All in all, I think we are all in agreement that the current constructor spam method isn't fun.  There are a variety of solutions posted, I'm sure stardock can take it from here.


The part I really think isn't receiving enough attention, is the "starbase construction module selection" screen.   It isn't important.   You almost always build the same modules, in the same order.   And even when you don't want to build in that order, if you had to,  it wouldn't be any great disadvantage. (the notable exception to this are defensive modules.   But truth be told, you're far better off building ships to defend your starbases than you are modules, and I expect that likely won't change.


I really like the idea of a starbase having a planet like placement grid.   Give each starbase one "combat adjacency bonus" tile, and one "economic adjacency bonus" tile.  Don't make these tile placements random, or you'd wind up feeling like you had to destroy starbases that got bad random placements.  Higher tech levels could unlock additional tiles,  and each race could have their own starbase layout.    Warmongering races for example might have two "combat adjacency bonus tiles".

If you're going to make us click all the modules we build,  at least make placing them fun, like it is with planets.



 

heres a thought with the way constructors currently work 
if i build a huge hull Ctor and load it up with as many modules as i needed to max 1 starbase +1 module and filled it the rest with engines send it out upgrade a starbase when done send it to the next "upgrade" the Ctor would that then replenish the modules rinse repeat? 

I'm not sure it's too late.  Remember, starbases originally weren't added until the last stage of beta for their original appearance.  While I will certainly accept a developer stating there is no time for such a change, I don't believe our limited understanding of how their code is structured should allow us to make decisions about what ideas we should share with them .

Either way, I would be happy to see this implemented with DLC too.   Being a founder has advantages hah!