[Feedback] Galactic Constructors III

Beta ver 0.81.0.0


*****


When I play GalCiv2, I use a mod I made which, among other things, reduces the number of constructors needed in a game, and I only build resource starbases (Morale, Military, etc.).
(In GalCiv2 (standard, not modded), there is already a lot of constructors to be built if the player want to play the game the way it is designed.)

In GalCiv3 there is resources to harvest everywhere... 8C
(It's just like an avalanche of constructors...)

*

So, I decided to play a game to test the "Request Constructor" feature.

To do this, my goal was to harvest all the resources and precursor relics on the map, and to improve the starbases.

Game settings:

Galaxy size: Medium
Type: Tight Clusters
All others settings to game default.
Playing Iconian against 7 major opponents.

I only used the "Request Constructor" button (except for the first constructors to build the starbases; and I also stole some "requested constructors", on the fly, to build some starbases (initial constructor) instead of directly build them at a shipyard).

I built only 1 Economic starbase for my homeworld (just to do it). ;-)

I bought mining starbases (resources and relics) from opponents (less than 5, if I remember correctly).

I had 6 shipyards sponsored by 7 planets to build the constructors (for a total of 13 planets at the end of playing; 6 planets flipped by influence and not used to sponsor shipyards).

I did not built warships (I bought them from opponents (more than 600 warships, if I remember correctly), and thus, I had to manage them (trade for them, and principally to send them to defend starbases, shipyards and planets)), and I built only 5 freighters and around 10 colony ships.

I harvested 66 resources (Elerium, etc.) and less than 10 precursor relics.

So, I built and improved 51 mining starbases for the resources and the precursor relics.

I was also unable to harvest 1 resource, due to others AI starbases positioning (Military and Economic starbases), preventing me to do it (more on this later).

I did not finish the game due to frequent crashes and the fact it was not possible to reload different save files; and it's not necessary to do it anymore.

I would have certainly winning the game, before finishing to improve all the starbases at maximal functionality.

*

Positive points:

Less clicks are needed to build a constructor; 1 click in the starbase screen instead of 2 clicks in the shipyard screen; and with the high number of constructors needed in the game, this is already a lot of clicks avoided.

No need to remember at which starbase to send the constructor (manage the constructor when it's built), all is done in the starbase screen; this is a big steps forward.

*

Negative points:

No way to choose the type of constructor the player wants, it's always the default game constructor "up-to-date" to the latest technologies, not the one the player designed for each particular task in the game (short range constructor, long range constructor, rapid constructor, local constructor, etc.).
(Also, the game allow to stack multiple constructor modules per constructor, but the player cannot choose them.)

No way to choose the shipyard where the constructors are built, it's always the nearest shipyard, even if it is busy and other shipyards build nothing currently.

*

Quoting myself from this topic, point "12) Starbase.":

https://forums.galciv3.com/462885

The "Request Constructor" feature is a step in the right direction to reduce micromanagement, thanks for this feature.

But, :) there is no way to select the constructor type you want to request (it's automatically the one generated by the program with the latest amelioration available).

And, I have specifically designed a particular type of constructor to upgrade local starbases, so, without the last engine (not needed for this task), or/and without lots of Life Supports (not needed for this task), or/and without lots of Navigational Sensors (not needed for this task).

And, I cannot select the shipyard, located 3 stars systems away, that could fulfill this role perfectly, instead of the automatically selected nearest shipyard, the one who is completely saturated by the construction of powerful combat ships for at least 40 turns.

So, basically, it's good enough as a temporary solution to help reduce the micromanagement while testing the game; but not efficient enough to seriously play the game.

I take this opportunity to include a link to a topic with suggestions to help reduce the micromanagement in the game:

https://forums.galciv3.com/462140


*

Another problem is that the player must go to each starbase when a constructor is available to select which module must be built.

In some way, the "Request Constructor" feature reduces the micromanagement a little, but merely move it to another location (from the shipyard screen to the starbase screen (1 click instead of 2 clicks)).

*

During this game, more than 80% of the playing time per turn was devoted to the management of constructors and starbases.

This is really too much.

Less than 5% of the playing time should be devoted to the management of constructors and starbases, I would even say much less than 5%.

What I mean is, it's a strategy game, not a management game.

I want to reflect when I play the game, not do repetitive and uninteresting tasks.

Basically, I want the playing time to be oriented to this:

Should I attack the Drengin now while they are still weak, but also take the risk that the Yor attack me if I do it, because they really seem to be on good terms...

...or should I try to first make an alliance with the Altarian, so, if the Yor attack me, the Altarian will join me in the fight...

...but at this time, the Drengin will be much stronger...

*

This planet seems to be the right one to build my manufacturing capital, but it may be a little too close to my potential enemies...

...this planet has less possibilities, but it is much less exposed and easier to defend, if necessary...

...I can also build a military starbase to defend the planet... ...ahem! ...no, I will not do that finally... ;-)

*

Should I research more techs for the planet developement...

...or should I start looking for weapon techs... ...as the Iconian start to become exasperated with me...

...or should I buy some warships from the Altarian, they have a lot of warships, and we have good relations, thanks to our trade routes...

...or perhaps should I try to make the Drengin attack the Iconian as they have similar military power... ...and at the same time, both of them will not look at me...

Instead of this:

Build a constructor at this shipyard...
Send a constructor to this starbase...
Build this module at this starbase...
Repeat 1000 times... ...and more...

In the current state of the game, the constructors win.

*

It should be simple.

This should work this way:

Set the starbase location on the map (construct the "empty" starbase).
Select the starbase model to be built.
Set the starbase to auto-build (optional depending the player game style).
Select the shipyard(s) dedicated to upgrade all the starbases on the map when needed, and set them to auto-send constructors (optional depending the player game style).
Done.

Now, we can concentrate on the strategy.

*

So, the U.I. for constructors and starbases management must be greatly improved, to free certain players from uninteresting and repetitive tasks (for them), but also be made in an optional way, to let certain players more inclined to micromanagement do it.

Quoting myself from this topic:

https://forums.galciv3.com/462140/get;3527748

What is really significant from a strategic point of view is "WHERE you put a starbase" and "WHAT the starbase DOES", not the management of constructors to build it.

Perhaps a game option would be desirable for the game, "Auto Upgrade Starbases on/off".

So the "strategist" and the "manager" players can play the game the way they want.

The "strategist": I want this types of starbases here, here and here.
The starbases are automatically built without his intervention.

The "manager": I got my new technologies to upgrade my starbases.
So, I have 200 starbases, I need 900 constructors to upgrade them all at this time, I have 97 shipyards... ...hmm... ...let see how I will organize it all.


**

Some paths to be explored to solve the problems.

*

Add a quick list in starbase screen.

Quoting myself from this topic, point "8) Starbase.":

https://forums.galciv3.com/462394

Add a "quick list" for the next modules to be built in the starbase screen (it can be located below the available modules list). This allow the player to rapidly select some future modules to be built for the starbase, they are automatically built when a constructor is available (a sort of Manufacturing Queue for starbases).

So, there is less need for the player to go to each starbase when a constructor is available.

*

1) "Auto Upgrade Starbases" mode.

2) Add the possibility to create starbase models.

Points "1" and "2" from this topic:

https://forums.galciv3.com/462140

*

With the "Request Constructor" feature, in the current version of the game.

"Manual" function:

Add the possibility to select the type of constructors (the one specifically designed by the player to do this), in the starbase screen.
"Select Constructor Type" button.

*

Add the possibility to select the shipyard(s) where the constructors are built (the one(s) who will fulfill this role perfectly), in the starbase screen.
"Select Shipyards" button.

*

Add the possibility to create and load starbase models (point "2" from this topic: https://forums.galciv3.com/462140).

**

Complementary Automatic function:

Add a "Starbase Auto Request Constructors" button (on/off button), in the starbase screen.

When doing this ("Starbase Auto Request Constructors" button set to "on", so in automatic function mode), the "Select Constructor Type" button, and the "Select Shipyards" button become inoperative (there is no need as it's automatic and the choices are made at the shipyard(s)).
(The "manual" settings (for the "Manual" function) are conserved, not erased.)

The player loads a starbase model (point "2" from this topic: https://forums.galciv3.com/462140).

*

Add an "Auto Build Constructors" button (on/off button)(relative to the starbases with "Starbase Auto Request Constructors" set to "on" only), in the shipyard screen.

When doing this ("Auto Build Constructors" button set to "on", so in automatic function mode), the player selects the type of constructors he want to use for the task, in the shipyard screen; and then he activates the auto repeat function in the shipyard list, so the shipyard auto build the constructors when there is nothing else to build (the player can add prioritary ships at his will, and it works as currently), and send them to the starbases where constructors are needed.

The program dispatches the constructors in a smart way, and is smart enough to pause and resume the building of constructors when needed (point "1" from this topic: https://forums.galciv3.com/462140).


*****


Other complementary paths.

**

Reduce the number of starbases needed.

Currently, the starbases are divided into several types, (Military, Economic, Mining, etc.).
This artificially augments the number of constructors needed to build them.

The constructors needed to build the initial starbases ("empty" starbases), and all the constructors needed to protect the starbases (all the modules needed for the defense of the starbase for each type of starbase).

With only 1 unique type of "universal starbase", the same starbase can be Military, Economic, Mining, etc., all types at the same time.
This will reduce the number of constructors needed to only 1 for the initial starbase, and only 1 time all the modules needed for the defense of the starbase.

This will also make a starbase a much more strategic target, as the loss of a starbase becomes more important.

**

Make the starbases more "powerful".

(All numbers are for explanation only.)

Instead of allowing the building of 10 starbases with each module with 10% bonuses, allow only the building of 5 starbases with each module with 20% bonuses.

Change the cost of the modules to reflect this:

10 times 1 module with 10% bonuses at a cost of 10 per module, becomes:
5 times 1 module with 20% bonuses at a cost of 20 per module.

This will almost cut by half all the constructors needed for a game.


I take this opportunity to include a quote from a topic with feedback about bonuses of starbases:

Quoting myself from this topic, point "8) Starbase.":

https://forums.galciv3.com/462394

The bonuses provided by a starbase are too small compared to an improvement built on the planet.

First, the player has to build a starbase, then construct and send some constructors to get the bonuses.
At this time, the bonus provided is much less than one improvement built on the planet.

Then, the player must construct and send some more constructors to defend the starbase (modules), and eventually construct and send some ships to further defend the starbase.

All of this just to have a bonus less significant than a lone tile (improvement) on the planet.

It's really not worth the effort.

The bonuses provided by a starbase should be much more important, at least the value of 3 or 4 tiles (improvements) on a planet.

***** Added 03/13/2015. Start.*****

It seems that this is not clear enough.
The comparison is for the "% bonuses" (starbase modules and improvements), without taking into account the production bonus (Economic Ring, as the production bonus works for all the "% bonuses").

***** Added 03/13/2015. End.*****


*****

Reduce the number of starbases (problem).


It would not be simple to reduce the number of starbase (by modding) the way the limitation of starbases is currently implemented in the game (minimum distance in hexes between starbases).

And sometimes, the system can be constraining.
Per example, during my test game:

"I was also unable to harvest 1 resource, due to others AI starbases positioning (Military and Economic starbases), preventing me to do it (more on this later)."
(it's now later) ;-)

It was not very fun to try to find a spot where to build the starbase for harvesting this resource, and finally, there was no spot available; and I counted the tiles more than I should while searching the free spot with the opponent starbases (and not seeing them all at the same time due to a short radar range with the constructor).

I make a suggestion about this, as counting the tiles on the map to place starbase is not very entertaining.

Quoting myself from this topic, point "8) Starbase.":

https://forums.galciv3.com/462394

Construction limitation of starbases.

I find that the current limitation system based on a minimum distance between starbases is not very convenient. The player need to count the hexes, and this, even with the starbases of the opponents.

And it can be easily abused to prevent the AI to build a starbase near one of your planet or near one of his planets. As the starbases of the opponents are taken into account for the limitation, the player can build "empty" starbases to "block" the AI and protect his planets, and even block the construction of starbases near the planets of the opponents.


I suggest to change the way the limitation is applied.

The limitation should be based on the number of overlapping effect areas of starbases (the number of layers), anywhere on the map.

(The effect areas of starbases increased by starbase modules are taken into account before the modules are researched, so, always based on the max effect areas of starbase available (change in game, modding).)

Ex:

It cannot have more than 6 effect areas of starbases overlapping for the player, and 6 effect areas of starbases overlapping for all the opponents, near one player's planet.

So, basically, in the example, 6 starbases max per planet for a player's planet, and 6 starbases max for all the opponents for the same planet.
A total of 12 starbases max per planet.

The player can have more than 6 starbases per planet only if he "trade" for a starbase of an opponent, or if the starbase "flip", (or eventually by boarding it, in the future of the game), but the limit is always 12 starbases max.

Much more user friendly; the player wants 1, 2, 3 starbases, he just has to build them on the map without the need to "count the hexes", and the AI cannot be "blocked".

Another solution would be to bring back the "system of areas" used in GalCiv2 (or a similar system), the "sectors system" (1 sector = 15 X 15 tiles) and to set a number of starbase per sector for the player and the opponents (player: 6 starbases max, all the opponents: 6 starbases max).
Don't know if it's easily feasible in GalCiv3.

A "sectors system" is also really needed in GalCiv3 to help the player to evaluate the distances on the map.


***** Added 03/14/2015. Start.*****

Also, a system based on "effect areas of starbases overlapping" (layers) is much more flexible for modding (ex: make more "powerful" starbases and limit them to 1 or 2 starbases per planet).

***** Added 03/14/2015. End.*****


And with a limitation of 1 hex of minimal distance between the starbases to avoid the "wall of starbases" effect.


**********
**********


So, finally, the current system used to upgrade starbases, based on the constructors, needs to be seriously revised, because it requires really too much time during the course of the game.

73,268 views 35 replies
Reply #1 Top

Building starbases the way the system currently is setup is like not being able to save ship designs ... Every time you want to build a new ship you need to design it from scratch even if youve designed the exact same ship ten times or a thousand times already

Reply #2 Top

Quoting androshalforc, reply 1

Building starbases the way the system currently is setup is like not being able to save ship designs ... Every time you want to build a new ship you need to design it from scratch even if youve designed the exact same ship ten times or a thousand times already

 

Admittedly, there can be local variations depending on where the starbase is - you might want to insert some relic-study modules into your build somewhere if there's a relic nearby, the number of morale modules you want can vary, and it can vary whether you want to add research modules, wealth modules, or both.  Perhaps a nice solution would be for you to save a starbase "build order" (which can include modules you don't have the tech for yet), choose to give a starbase that build order, and when you end turn, if there are any spare construction points that you haven't already assigned, they're directed to completing the build order elements that you have the tech for.

Reply #3 Top

[quote 

Negative points:

No way to choose the type of constructor the player wants, it's always the default game constructor "up-to-date" to the latest technologies, not the one the player designed for each particular task in the game (short range constructor, long range constructor, rapid constructor, local constructor, etc.).
(Also, the game allow to stack multiple constructor modules per constructor, but the player cannot choose them.)

I would like to ve able to design my own constructor for thisif I want to.I

No way to choose the shipyard where the constructors are built, it's always the nearest shipyard, even if it is busy and other shipyards build nothing currently.

There should be a feature tonpick which shipyards to use I agree with this.


Another problem is that the player must go to each starbase when a constructor is available to select which module must be built.

It would be nice to set points to send constructors for a certain amount,  or untill done. Even to all available resources,  or untill done with all current starbases, or dIscovered from exploration. If multiple respurces one each untill no more empty resources. Then to upgrading starbases. Setting priority respurces. I agree with this. Ie one resource, or space station per starbase-multiple starbases for one resource,  or space station-one starbase for multiple resources,  or space stations.

In some way, the "Request Constructor" feature reduces the micromanagement a little, but merely move it to another location (from the shipyard screen to the starbase screen (1 click instead of 2 clicks))

I like thisidea too.

During this game, more than 80% of the playing time per turn was devoted to the management of constructors and starbases.

This would depend on your play style

What I mean is, it's a strategy game, not a management game.

I disagree the more complex eith different features thr better to my opinio,  but I'm just one person. 

Set the starbase to auto-build (optional depending the player game style).
Select the shipyard(s) dedicated to upgrade all the starbases on the map when needed, and set them to auto-send constructors (optional depending the player game style).
Done.

I really like thisidea.

Quoting myself from this topic


Add a quick list in starbase screen.

Quoting myself from this topic, point "8) Starbase.":

Add a "quick list" for the next modules to be built in the starbase screen (it can be located below the available modules list). This allow the player to rapidly select some future modules to be built for the starbase, they are automatically built when a constructor is available (a sort of Manufacturing Queue for starbases).


So, there is less need for the player to go to each starbase when a constructor is available.

Awesome.

1) "Auto Upgrade Starbases" mode.

GoodideaI

2) Add the possibility to create starbase models.

Great

With the "Request Constructor" feature, in the current version of the game.

"Manual" function:

Add the possibility to select the type of constructors (the one specifically designed by the player to do this), in the starbase screen.
"Select Constructor Type" button.

Agree

Add the possibility to select the shipyard(s) where the constructors are built (the one(s) who will fulfill this role perfectly), in the starbase screen.
"Select Shipyards" button.

Agree


Add the possibility to create and load starbase models 

Agree

Complementary Automatic function:

Add a "Starbase Auto Request Constructors" button (on/off button), in the starbase screen.

When doing this ("Starbase Auto Request Constructors" button set to "on", so in automatic function mode), the "Select Constructor Type" button, and the "Select Shipyards" button become inoperative (there is no need as it's automatic and the choices are made at the shipyard(s)).
(The "manual" settings (for the "Manual" function) are conserved, not erased.)

Agree

Add an "Auto Build Constructors" button (on/off button)(relative to the starbases with "Starbase Auto Request Constructors" set to "on" only), in the shipyard screen.

When doing this ("Auto Build Constructors" button set to "on", so in automatic function mode), the player selects the type of constructors he want to use for the task, in the shipyard screen; and then he activates the auto repeat function in the shipyard list, so the shipyard auto build the constructors when there is nothing else to build (the player can add prioritary ships at his will, and it works as currently), and send them to the starbases where constructors are needed.

The program dispatches the constructors in a smart way, and is smart enough to pause and resume the building of constructors when needed (point "1" from this topic:

Up to this point you sound pretty good.


Other complementary paths.

I take this opportunity to include a quote from a topic with feedback about bonuses of starbases:

Quoting 


I make a suggestion about this, as counting the tiles on the map to place starbase is not very entertaining.

Idon't find unentertaining either. 

Quoting myself from this topic, point "8) Starbase.":

The limitation should be based on the number of overlapping effect areas of starbases (the number of layers), anywhere on the map.
 
Limited starbase number would at least let us be more stragetIc in starbase placrment. Just let me to be able to destroy my starbases for later placement.

(The effect areas of starbases increased by starbase modules are taken into account before the modules are researched, so, always based on the max effect areas of starbase available (change in game, modding).)
 
This way if we do the above idea at least I'm not wasting research on techs I can't use. Though to free up techs I would have to destroy starbases,  so maybe this last part should be reconsidered.

Another solution would be to bring back the "system of areas" used in GalCiv2 (or a similar system), the "sectors system" (1 sector = 15 X 15 tiles) and to set a number of starbase per sector for the player and the opponents (player: 6 starbases max, all the opponents: 6 starbases max).
 
Why dId they get rid of this.
 
A "sectors system" is also really needed in GalCiv3 to help the player to evaluate the distances on the map.



So, finally, the current system used to upgrade starbases, based on the constructors, needs to be seriously revised, because it requires really too much time during the course of the game.

[/quote]

Againit really depends on you pIay style.

Reply #4 Top

The OP has spent a lot of time and done a good job describing the overall SB management problem, and adding some very good suggestions. Others have also posted good ideas around the forum.

Brad has made it clear that star bases are going to be a huge part of the game, and I am 100% in favor of this.

On the gripping hand :) the SB management system deserves major attention and deserves to be far more dynamic than the good, yet simple solution offered so far.

Sometimes we ask for features that might be good ideas but they fall into the, "egg in our beer" category. This is not true of the SB management category. Some of the suggestions I have seen are simple and appear easy to implement. Others might be a bit complex and/or work intensive. Frankly, imo there is no solution too complex or work intensive to be considered for a part of the game that is going to occupy over half our playing time.

I believe that star base/constructor management deserves at least as much attention as the battle viewer and I hope that the devs will allot the needed time, and give strong consideration to all the suggestions in this post and other posts. We need a system that will make star base development a fun part of the game and not the part that everyone hates.

The current tool is a good first step, but much more is needed  

Reply #5 Top

VERY good overview OP. I agree with all the major points you make.

The biggest 3 changes I'd like to see are

  1. Unifying the 3 types of SB into one OR making different types of SB buildable within another SB's ZOC, with a 2-3 hex separation.
  2. A set-it and forget-it feature like the OP describes, where you set the location, type, and priority of the modules: econ -> subtypes, then military -> subtypes. Rough example: I set the SB to build the econ modules first, going from manuf->money->res->approval, then military going from basic->missiles->fighters->defensive->beams->kinetics). This makes setting a starbase a lot of clicks, but it's a one-time deal. If this was implemented, it probably(?) wouldn't be difficult to allow the play to mix up the order between say econ and military or culture and military, for flexibility.
  3. Player-chosen constructors are auto routed to the SBs. The auto-route feature would need to be dynamic such that if a constructor is en route from 30 hexes away and another (auto-built) constructor is created 10 hexes away, the closest one is used and the farther constructor is re-routed to a different needy SB. If the player "steals" a constructor en route, the feature should adjust other constructor paths to take that into account. Shipyards that are idle can be set to make constructors (of a chosen type!) as needed and obviously any manual changes to the build queue take precedent.

So that's more like 10 features rolled into three. O:)

To me, the biggest constructor annoyance right now isn't the flood, it's having to click into the SB and pick which modules I want. For every single SB. /arg

Reply #6 Top

This is mostly what I've been trying to convince people about, way to much time spent building and directing constructors.  I also think that the 2 for one construction module should be implemented in the tech tree across the board, implemented as miniaturization.  Its just annoying otherwise send so many constructors out.

 

Also I don't use the request constructor feature due to lack of ability to choose which constructor type is sent.

Reply #7 Top

Personally, I am still think that Constructors should be massive permanent ships similar to how GC II had Miner ships.

Each starbase/Starport module would have a cost that would come from the total economy.  200-5000 credits depending on what they were and would take 1-5 turns to complete.

Research and Ideology choices would make constructor ships faster and more efficient, Lowering cost (possibly to zero)  and turns to build improvements.

 

We then build a few constructor ships (probably with guard) and send them out into the stars to build starbases.    We could even possibly have a Queue for the starbase build list that a constructor would work through.  

 

We could then have the Request Constructor button request the closest constructor which would then come and upgrade the starbase.   This way all we would need to do is go and visit our starbases  when there is new tech and build up the queue and let the constructors go to work.    



Reply #8 Top

Personally I would rid us of the whole constructor aspect of upgrading StarBases.

I would still have a constructor to establish bases, but once built, I would have a  StarBase select a "sponsor" just like Shipyards.

 

You can then que upgrades on your StarBase to your heart's content all at once, and they will leach manufacturing points from the planet as they get constructed over time.

 

 

This solution provides a very simply and fast way to build/plan/execute a new StarBase and still ends up leeching manufacturing capacity from your empire's Shipyards (which I think is the intent of having to continually build constructors) by stealing sponsors away from them.

This also presents new and interesting challenges, it simply will be agonizingly slow to manufacture modules on StarBases super far away from your planets. Which I deem as a good thing. You can also limit production of new modules to StarBases in your zone of control, which may be a nice feature to prevent people from dropping fully built up bases instantly in enemy territory to assist in a war or culture flipping super fast.

 

 

Lots of great ideas here, but the pattern is pretty clear, the current system is just a giant chore.

+1 Loading…
Reply #9 Top

Constructor spamming starbases is just annoying, but it's not constant enough to make them sponsored like shipyards are.

 

I would instead have it be a work order that would put a build item into the host planet's production queue.  This would detract from more civilian improvement than military, but most starbase upgrades are civilian in nature anyway and we really don't have enough to do on planets besides produce money/research.

Reply #10 Top

Quoting psychoak, reply 9
Constructor spamming starbases is just annoying, but it's not constant enough to make them sponsored like shipyards are.
I would instead have it be a work order that would put a build item into the host planet's production queue.  This would detract from more civilian improvement than military, but most starbase upgrades are civilian in nature anyway and we really don't have enough to do on planets besides produce money/research.
Based on Frogboy's post in another thread, they specifically want constructors to take time at shipyards, not planets. They want the shipyards occupied building constructors instead of colony/military ships.

I think a sponsorship program for modules could work (not the original base), but they could leave in the send-a-constructor option for far starbases/relic capture.

Reply #11 Top

Lol that's a funny title. Alot of its true too.

Reply #12 Top

Based on Frogboy's post in another thread, they specifically want constructors to take time at shipyards, not planets. They want the shipyards occupied building constructors instead of colony/military ships.

 

This may be the intent, but it's irrelevant where the production is actually pulled from for two reasons.  Production can be purchased, and production can be moved.

 

In the end stages, I can buy large quantities of firepower quite efficiently.  If you gear several planets towards monetary maximization and have them produce credits, you can purchase a lot of ships rapidly from few construction yards, which leaves you far more flexibility than taking the long road of constructing them over time.  They can be produced at higher technological levels with on the fly situational needs.  It's a highly effective mechanism.

 

Second, there is a slider to change production between civilian and military, shifting your on site planetary production to offsite shipyards.  The practical effect of this is that planetary production is shipyard production.

 

If you're actually trying to do what the OP did, a system of sponsorship will be little different from the current implementation.  Instead of ordering constructors and upgrading starbases in a make-work fashion, you would shift sponsors from starbase to starbase in a make-work fashion instead.

Reply #13 Top

I get where Brad is coming from in wanting to make it a choice of what to build with your shipyards and not wanting to just use them for warships, colony ships and the occasional freighter but I know I spend a lot more time building constructors and getting them where I want them to build and its not very fun.  I don't know how best to fix this issue but I have been saying its a problem for months.  

 

I don't really mind using the shipyard to build constructors, what I do mind is having to send so many constructors to build a starbase.  This includes what I'm doing in my current game of loading up a large hull with an engine and as many construction modules as possible.  With the 2 for 1 pragmatic that builds an economic starbase, no defenses just the manufacturing, science, economic and approval modules, 10 to where I have currently researched.  This is my problem, it takes another constructor for each upgrade.  I would much prefer each module to be treated like the buildings on planets.  Brad responded to this idea by saying starbases don't have inherent production so they can't do that.  This is exactly my point, by mid game several starbases give much smaller bonuses to production than the buildings on the planet is supports.  So my suggestion is that starbases give manufacturing, research and economic production rather than bonues.  They don't have to be big, I think 1 per tier might be too high.  However this way starbases can upgrade themselves so we just have to send a few constructors to get a starbase started then it will build up on its own.  This could also allow for the current system to continue to work if you want to continue spamming constructors.  

 

A few other things, first I think the types of starbases should be dropped too, just let me throw a mining ring on my economic starbase, it would resolve some of the minor issues with starbases as well.  Next I highly recommend renaming social and military planetary spending to planetary and orbial, both are used for both purposes and it just makes more sense and my(and I'm sure others as well) OCD will stop bothering me.  

Reply #14 Top

Quoting Smithy6482, reply 10


Quoting psychoak,
Constructor spamming starbases is just annoying, but it's not constant enough to make them sponsored like shipyards are.
I would instead have it be a work order that would put a build item into the host planet's production queue.  This would detract from more civilian improvement than military, but most starbase upgrades are civilian in nature anyway and we really don't have enough to do on planets besides produce money/research.

Based on Frogboy's post in another thread, they specifically want constructors to take time at shipyards, not planets. They want the shipyards occupied building constructors instead of colony/military ships.

I think a sponsorship program for modules could work (not the original base), but they could leave in the send-a-constructor option for far starbases/relic capture.

 

Having planets sponsor Starbases does eat Shipyard time albeit indirectly. Every Starbase sponsored, is a planet that can't sponsor a Shipyard, this reduces production rates, and thus increases the time it takes to build anything at that yard, exactly the same as if the yard was busy building a constructor. Thus, we are still "killing" production time form a Shipyard. Its all going to boil down to how you rate production VS producing the modules, to update your Starbase as quickly as we do now, you're likely going to need to sponsor it with 3 planets. That is a big slow down to the yards your NOT sponsoring with those planets.

As for whether we are shifting the makework... we are, but there IS less makework because your Starbase has a Que for all of its upgrades (and its production comes from the sponsoring planets). You go through the Starbase once and plan/order all modules in ONE action, they then produce over time. This means your checking on this base once instead of a dozen times, furthermore, no clicking ordering constructors to a particular spot, not making rally points for them, or assigning them to a planet to stockpile, nor checking on that stockpile when its orbit is full.

 

 

I also agree somewhat with what others have said about the varying types of Starbases, Econ, Military, Culture, and Mining is one too many, make any/all yards mine. Then maybe, just maybe, I'd bother with a military Starbase.

Reply #15 Top

Quoting Gauntlet03, reply 14
Having planets sponsor Starbases does eat Shipyard time albeit indirectly. Every Starbase sponsored, is a planet that can't sponsor a Shipyard, this reduces production rates, and thus increases the time it takes to build anything at that yard, exactly the same as if the yard was busy building a constructor. Thus, we are still "killing" production time form a Shipyard.

Ahh, I didn't realize you were suggesting a sponsorship system that parallels the shipyard one. Yes, that could work well. They'd have to adjust balance for the distance factor that constructors must traverse (for long distance upgrades), but I'd be all for that over the current system.

In my current game, I'm trying to overlap my starbases as much as possible to test out what other people have commented on. Yeesh, what a spammy nightmare! It takes 5-10 minutes just to deal with the SB/constructor stuff and I'm only on the Beta 4 max size map (around 70 colonies at the moment).

Reply #16 Top

I actually think that sounds like the best solution; make the starbase require a constructor to found it them let it be sponsored like a Shipyard by a planet and put modules for it in it's build queue. Economically that system can parallel the current one but is much less micromanagement. In addition they should as suggested make it so a planet can sponsor only one starbase or one shipyard at once not both to keep it simple.

 So yes for what it's worth that gets my vote, constructor micromanagement has always been a failure of the GalCiv games in my experience, great though they are in general and it would be great to see that resolved here.

Reply #17 Top

While i dont mind only being to upgrade 1 per turn i would like to be able to sponsor multiple and have the planet regularly check and change current "primary" sponsor

Reply #18 Top

Simple fix...

 

Sponsor Starbases WITH Shipyards.       The more starbases you sponsor, the more it impacts how quickly you product things.    

This means for each Starbase we would build only one constructor.      Once the starbase is made we would select a sponsor shipyard and then queue up the upgrades we want.  The production for these upgrades would siphon off of the production supply for the shipyard.

 

 

+1 Loading…
Reply #19 Top

Problem with that, is you'll end up having to re-do sponsorship much more often than if it were planets.


With planets, you could assign 10 of your colonies to support 10 Starbases and leave them for maybe 30-50 turns as they slowly build it out. OR you can do 10 planets to one if you really want it to upgrade fast.

With yards, you'd still end up editing the sponsors to do the same effect (slow or fast) except you'd have to build many more yards if you wanted to upgrade 10 starbases at once (albeit slowly). Its less flexible. 

Now that isn't necessarily bad, but you are introducing an extra layer to the process which will lead to extra clicks and extra micromanagement. Which will lessen the effect we are looking for (reducing SB micromanagement).

 

 

Reply #20 Top

Then make it fixed...  the Shipyard that sent the initial constructor is the only sponsor.     If said shipyard is destroyed a popup alerting you that a non-sponsored starbase needs looking at.   you then select a new sponsor.

If we cannot Change the sponsor then it becomes a bit more of a choice... do I set this to my super huge super productive shipyard and slow it down... or this other one that is really slow and make for a very slow upgrade process for the starbase?

 

 

reduces micro... and increases judgement cost.

 

Reply #21 Top

Except that you can always change the sponsor of your yards, so you can effectively swap which yards are the super producers and which ones are not. If you made it this limiting, the players will just build a extra yard at their major hubs (they are pretty cheap) in order to work around your solution.

All the production actually comes from the planets. So whether you sponsor a base with a planet/s or a shipyard is irrelevant, its the same thing, except the yards gives you less flexibility and will require more yard spam which will lead to more clicking.

Now that would still be better than what we have, but I don't see the point in making it yard sponsored instead of planet sponsored. Presumably it'd be more development time too, as planets already sponsor things, and Shipyards don't.

 

A- Planets - Shipyard - Starbase

B- Planets - Starbase OR Shipyard

 

In example A, to adjust development times of Starbases I have to go to the Starbase in question, check the yard that supports it and the modules que, then find the Shipyard that sponsors it and change planet sponsors.

In example B, to adjust development times of Starbases I have to go to the Starbase in question check the modules que and change planet sponsors.

 

One of these is less clicks, searches, and mouse movement.

Reply #22 Top

Quoting Gauntlet03, reply 21
A- Planets - Shipyard - Starbase
B- Planets - Starbase OR Shipyard

I'm with you, Gauntlet: option B is MUCH more intuitive and makes for less micromanagement. It would also satisfy the developer methodology of "choose between military or starbase production." With option A, you make it a 3-chain sequence to edit how a planet is sponsored. That's headache-inducing and I don't think it'd be any better than the current system.

A bonus side effect is this system would also reduce the "idle shipyard" alerts, since the planet isn't sponsoring a shipyard, it's sponsoring a starbase that you have presumably queued to suite your build order preference. While upgrading starbases, the associated shipyards are shut down. /shutupandtakemymoney!

Reply #23 Top

Oh i agree it makes more sense to have planets sponsor the starbases..

 

But the point of the constructor spam as stated by Stardock is to reduce the rate at which a player can build up their military.  They must chose A Constructors, or B military ships.

By linking the support of the starbases to the shipyards it slows the production down without having to do a whole ton of micromanagement.

Mostly, it makes micromanagement a choice, rather than a necessity.

 

 

Reply #24 Top

In order to allow for shipyard sponsorship perhaps modules should simply be added to the queue. Or a "govern" screen could be devised for the shipyard allowing one to create an allocation between shipbuilding and starbase construction. Shipbuilding shouldn't cease entirely as a consequence of starbase sponsorship.

 

Reply #25 Top

Quoting Wer900, reply 24
In order to allow for shipyard sponsorship perhaps modules should simply be added to the queue. Or a "govern" screen could be devised for the shipyard allowing one to create an allocation between shipbuilding and starbase construction. Shipbuilding shouldn't cease entirely as a consequence of starbase sponsorship.

Based on what the devs have said, that's exactly the point building constructors: it slows down your military construction. I know some people have a problem with that, but it doesn't look like it's going away. That makes the question here "How can we reduce micro & constructor spam while staying true to the design intent?" If there's a way to make the build-a-module work (& reduce micro!) with shipyards, great. But, at least to me, that road leads to less micro reduction than direct planet sponsorship. Direct sponsorship would reduce "idle shipyard" alerts and/or allow you to split a multi-planet system into starbase and shipyard production working in parallel.

Disclosure: I prefer large maps with lots of planets.