Search
Forum Home | Login
BehroozWolf
BehroozWolf
Join Date 03/2006
0

Auto-Transport orders option for reducing micromanagement.

With the 1.1 population algorithms, intra-empire transport is going to be even more useful, and reducing the micromanagement required would be nice.

March 25, 2006 4:45:23 PM from GalCiv II ForumsGalCiv II Forums
With the new population growth algorithms in 1.1, transporting population between planets will become an even more important task of any large empire. Unfortunately, the current implementation of transport in GalCiv2 with transports is a micromanagement-heavy task, requiring several steps of user input across multiple turns for each round-trip shipment.

I think this problem could be addressed by the creation of a new subset of ship/fleet orders, "Auto-transport", accessible for transport-capable fleets from the ship-info screen, just like auto-explore or auto-survey.

Ideal Interface Description:

(Checkbox) Auto-transport [Quantity] population from [Source] to [Destination]

The Quantity box would ideally default to the transport capacity of the fleet, and have a selectable drop-down list with "Until Full/Stopped" and 1x, 2x, 3x, 5x, 10x multipliers of the fleet's capacity, and additionally have the capability to simply type in a number in billions to transport. "Until Full/Stopped" ideally should calculate available population capacity on the fly for each trip based on the estimated traveltime and current growth rates of the destination planet and only pick up as much population as the target planet is expected to be able to handle at arrival.

The Source box should default to the planet that the ship/fleet is nearest to, and have a drop-down box wih "Full Planets" ">90% Full Planets" and all valid friendly source planets with at least (Quantity) population to select from, sorted by name, ideally with >90% populated planets marked with an icon and each planet's absolute population displayed via red-yellow-green color scale with red being planets barely meeting (Quantity) population and green for the largest-population planets in the empire. Oh, and the Source box should also support manually typing in the source planet's name.

The Destination box should be similar to the Source box with identical criteria using the available space under planets' population cap instead of their population, and additional options of "<10% Populated Planets" and "> Set %" for user-entered percentages.

Another checkbox at the end for "Automatically return to source after completing transport" to have the transporting fleet move itself back to the originating planet would be useful also.

Core Logic Requirements:
To take this concept to the most effective level, most or all of the required number-crunching and information-gathering should be done behind the scenes and gathered into the interface, as with the color-coded populations for planets listed in the drop-downs and the removal of unqualified planets from the dropdown lists based on information entered into the other fields.

The generalized options, for example "Full Planets", should act as wildcard specifiers that refresh for each trip iteration and return the nearest qualified planet.

Ideally, a player should be able to enter:

(Check)Auto-transport "Until Full/Stopped" population from "Full Planets" to "<10% Populated Planets" (Check) Return to origin when complete

With those orders, the transport fleet would check that there is a valid target planet and valid source planet, and then choose the nearest (or some weighted combination of nearest and lowest pop) valid target "<10% populated planet" to transport to, and set a course to pick up from a valid source "full planet" which will give the shortest total traveltime before arrival at the selected target. It would then drop off the population at the target. Then the fleet would do another check for a valid source/target combo, and either repeat the transport cycle, or move toward the origin if no valid combinations are found, checking each move for a valid combo to work on.

I think that the system described above provides a relatively flexible and extensible framework for rapid transport options. If implemented completely, players would be able to 'fire and forget' transport orders, greatly reducing micromanagement and the logistical/informational overhead of keeping things running smoothly.
Locked Post
Search this post
Advanced Search
Subscription Options
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
BehroozWolf
Join Date 03/2006
0
Reply #1 March 25, 2006 5:57:50 PM
from GalCiv II ForumsGalCiv II Forums
Going beyond the scope of this plan, the overall interface could be improved even more by the addition of a global "Transport Queue". As envisioned here, a Transport Queue would involve significantly more complexity in implementation, but would allow transports to be placed in the auto-transport queue and then completely forgotten about.

Ideally, a TransportQ would have the following characteristics:

Individual ships/fleets assigned to the transport queue with 'autotransport queue' orders.

Queued requests entered similar to above, assigned to a priority rather than to a specific ship/fleet.

Three priority levels for queued requests: Urgent, Normal, Low. Higher-priority requests would override lower priorities on a continuous basis:

Each turn, claimed Urgents are evaluated to see if there are non-urgent ship(s) capable of fullfilling the request significantly faster than the currently tasked ship(s), if so, they and their ships get thrown into the un-claimed Urgent pool. Then, un-claimed Urgent requests get their pick of all transports not already tasked on an Urgent request, and through a miracle of hand-waving, all un-claimed Urgents are assigned ships in a way that minimizes the number of turns required to complete them all.

Claimed normal-priority requests do not require further evaluation. Unclaimed Normal requests get their pick of available and low ships.

Claimed low-priority requests are not re-evaluated. Unclaimed low requests get anything that's left over after everything else.

To minimize overhead, "Urgent" priority requests must have a specific destination planet, while normal and low requests can have wildcard destinations such as <75% full.

If a transport fleet is removed from 'auto-transport queue' setting or destroyed, the request in the queue remains, and other ships get assigned as per the priorities list above until the request is fullfilled.

I'm sure lots more stuff could be added, but that works as a basic outline.
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
Ammo0
Join Date 03/2006
0
Reply #2 March 25, 2006 6:47:26 PM
from GalCiv II ForumsGalCiv II Forums
To go along with this, I would like to see an Auto Colonize Option in the ship info screen and Game options menu that would give the comand to all colonizers when launched, maybe somthing like this:

[X] Auto Colonize (closest / furthest / highest rated) known world.

Also the AI would not send a ship to a world that already has a ship on its way to colonize it.
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
Alfonse
Join Date 02/2006
+12
Reply #3 March 25, 2006 7:10:59 PM
from GalCiv II ForumsGalCiv II Forums
While you're at it, why don't you just have a "play game for me" button that makes the AI play the whole game for you. No micromanagement to worry about then...

You're going to either be pressing the "Turn" button and letting the game play itself, or you're going to have to actually play the game. That's going to require some drudgery. Ferrying people about the Empire is not a difficult task.

UI streamlining is one thing. Making a button that says, "Automatically do everything I want" is quite different.
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
MegaVolt
Join Date 07/2004
+3
Reply #4 March 25, 2006 7:39:38 PM
from GalCiv II ForumsGalCiv II Forums
i also think those changes are not needed at all
ferrying ppl around is not really important and not much micromanagement (just buy big transports)
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
Oneirocrat
Join Date 12/2005
0
Reply #5 March 25, 2006 8:52:48 PM
from GalCiv II ForumsGalCiv II Forums
Or simplfy the whole problem by allowing emigration.

MoO3 did that to the point of being annoying, where citizens would emigrate to empty planets, thereby colonising them. We don't want that, but a simple 'this planet is more crowded than that planet, so I'm moving' algorithm would pretty much obviate all the micromanagement, and work beneath the AI layer.

And, in game, it would add some truth to those planet descriptions which say '...it is the dream of all citizens of [YourEmpireName] to live here'.
Reason for Karma (Optional)
Successfully updated karma reason!
BehroozWolf
Oneirocrat
Join Date 12/2005
0
Reply #6 March 25, 2006 9:28:56 PM
from GalCiv II ForumsGalCiv II Forums
(Rant)

Something I'd like to get off my chest - it is really starting to p*** me off that every time somebody posts an idea around here, some toe-rag pipes up 'Do you want an 'I Win' button with that, too?'

If you want to sit and do repetitive, menial labour in a game, go make up times-tables in Excel. Without formulae. To about 1000. When you're done, come back here and be humble.

The OP has correctly identified a change to the game mechanics which could well push towards micromanagement, and is suggesting a way to alleviate it. That heads-up is to everyones' benefit, ultimately.

Many here are veterans of the Orions. Myself, I was too young for MoO, but still consider MoO2 my favourite game of all time. Yes, bloody awful late-game colony management and all. Okay, it had a few other less-than-desirable points too. And MoO3 was as much a disappointment to me as to anyone.

MoO2's pop growth algorithm was at least a little better looking than a straight percentage of existing pop, simply because it was a power of the lesser of the existing pop or the remaining space for pop. So the growth is a kind of bell-curve. Both MoO2 and GalCiv2 put a cap on the pop than a planet can support. As you approach that cap, MoO2 would slow the pop growth, whereas the 3% of existing pop calculation in GalCiv2 will continue accelerating until it hits the brick wall. But that's irrelevant. What's important is the difference it creates between an established world with high growth, and a new colony with low growth.

I can well remember having to build extra freighters mid-game to shift pop from established worlds to new colonies, and all the frakking about that entailed. I REALLY don't want to see it in GalCiv2, especially given how smooth everything else is. MoO3's solution (allowing population to osmose) was simple and elegant, so I commend it.

But if you're happy launching transports full, sending them to destinations, re-launching them with one pop, returning them to full planets, and repeating, and repeating...

Go right ahead. But don't say we all have to do it.

It may be that the actual impact of percentage growth won't be similar to MoO2's situation. It may be that it is, but Stardock implements an even more elegant solution than has been thought of here. It may even be that you get through your games without ever populating your colony worlds. But don't just post to say that somebody else's idea is worthless just because you don't see a problem.

Either answer the point critically, or go play with Excel.

(/Rant)

I really shouldn't post this late at night.
Reason for Karma (Optional)
Successfully updated karma reason!
View all recent posts
Mark all posts as read Delete cookies created by the forum Return to Top
Stardock Forums v        Server Load Time:   Page Render Time:
About us | Contacts | Privacy Statement | Register
©1995-2026 Stardock Entertainment. Galactic Civilizations is a registered trademark of Stardock Entertainment. Steam and the Steam logo are trademarks and/or registered trademarks of Valve Corporation in the U.S. and/or other countries. Bank Gothic is a trademark of MyFonts and may be registered in certain jurisdictions. All rights reserved.