borg starship construction frm nodes

posted on April 22nd, 2009, 9:28 pm

At the moment, as I have already mentioned, constructing a specific ship for the borg entails manually building a node, then selecting a hull, and then choosing the specific modules.
When engaging in combat, most normal players do not have the ability to toggle back to keep building while still controlling the fleet at the same time.
In effect for the borg more than the other races, we find that rebuilding a fleet after a battle is almost always starting from point 0.
Compared to this, other races are able to set a queue of ships and continue about their business.
Although I do agree that queues run out, they are able to set a complete queue before engaging in combat, and are able to see ships still being produced while fighting.
The borg production on the other hand comes to a complete halt.

I understand that initially it was so designed with the idea of borg relying on a few ships. however, with balancing of the initial borg design as well as the problems faced with resource management and incubation supply construction from an outset of 1 construction ship, the borg are put at a slight disadvantage - not through anything else but cumbersome controls due to this.

I would therefore request that a node not dissipate until the queue set up on it is cleared.

What I mean by this is as follows:

1. A node can produce more than 1 ship.
2. The ships are set in queue.
3. the number to be set in queue will be set by the user.
4. Maximum of 4 can be set per node. After which the node mandatorily breaks up as it does now on completion.
5. the queue is not flexible to allow differnt types of ships. It will accept from the user the configuration that is wanted and the hull. for example assimilator config 2 torps and 1 beam.
the user will then set how many with a MAX of 4 to be set in queue.
resources of course will still be taken for each setup.
The node will also act as a form of macro noting how long the user took to select the hull and select the specific modules. the subsequent ships will be created using that very time-gap -- think excel action repetition macros...
6. The user may create multiple nodes. Different queues may be set for each - depending on what i wan to build.

There will be no problem here as it merely involves easing the manual tediousness of creating each borg ship.
the primary constraint will still be resources.
If there are insufficient resources to complete the build, the we get the same error messages we typically get from the normal races' yards - insufficient trilithium etc.

Let me know if this sounds ok from a gameplay perspective, as well as from a programming perspective, cos I do not know if the macro part will be viable, or if the subsequent constructions will be able top mimic the time and sequence taken for the construction of the first ship.

posted on April 22nd, 2009, 9:43 pm

How about, if you pick borg, then at the start of the game (pre-game, I mean), you can set some settings for your ships, so for example. Pre-game, I would put in: Cube, two tactical armors, 3 torps and a regen (for example), and I could then insta select that option from the node, hence, quicker ship- building.

posted on April 22nd, 2009, 9:52 pm

interesting idea 

but how many can be set? and what f I want to change in game? depending on the strategy i prefer..

a good example is couintering a powerful fed rush.

typically assims can have 2 torps and 1 weapon beam. however at times in certain scenarios they are more useful with an assimilator beam instead.

presetting when selecting the avatar limits my options to improvise in game. while the one i requested enables the switch as i can also cancel the queue and end the node. i can set a new unique queue for each node.

allows me to be more flexible.

posted on April 22nd, 2009, 10:43 pm

Gotta say... I don't really like it. Borg are already easily the least micro-intensive of any of the races, and their build mechanic actually keeps them balanced in my mind. I would personally hate to see the nodes become mini shipyards, especially considering that currently it is a viable strategy to attack an unfinished node and destroy it while the player desperately tries to get enough resources to finish that last node. Correct me if I'm wrong but it sounds like you like the way the AI builds Borg ships, and want to use a similar mechanism for the player. Likewise, a node that can be q'd puts less emphasis on protecting and using one's construction ship, as you can simply build four more ships out of that one node if your construction happens to be destroyed (and your construction ship only has to build every fourth time, rather than requiring more micro). Other races have their disadvantages too... namely ones that the Borg don't have: you only have to build 5 types of stations, and only 1 of them you are forced to build more than once (the supply depot... you can choose to or not in a quick game). Likewise most research is done at the Collective hub and is not limited by resources (other races you have to constantly go back to check if you have enough resources to go for that tech).

posted on April 22nd, 2009, 10:57 pm

I was thinking if you wanted to try this you should change the game to whatever yard the borg Ai uses.

posted on April 23rd, 2009, 1:58 am

While it sounds interesting i must agree with dom, That would ruin alot of strategies against the borg.
When one cube is capable of destroying more than one ship of any race in the game, and a micro'd cube can rip a tavara (shield torp then cutting beam while still fireing).

The only beef i have with the borg is that of all the races they take the weakest use of mixed tech.

and being borg i beleive that they shouldnt have mixed tech ships, but say, make the mixed tach yard for each race a bit diff, and only that races ships to to there mixed tch yard, and every assimilated ship dissassembled there adds say a 2% damage resistance to that race.

posted on April 23rd, 2009, 8:50 am

The dev team have already stated that they are working on an alternative ship construction method for the Borg.

posted on April 23rd, 2009, 3:52 pm

The dev team have already stated that they are working on an alternative ship construction method for the Borg.

yup.

I look forward to that one . venturing opinions and ideas here..

[Anonymous]

posted on April 23rd, 2009, 4:46 pm

Last edited by Anonymous on April 23rd, 2009, 5:20 pm, edited 1 time in total.

I agree with your concerns on the face of it.

However, we need to consider the actual gameplay in question.

Also we should not confuse research station builds which are purely in-game handicaps with human control handicaps.. Game balancing is supposed to account for the research stations  etc, and I believe that was the logic behind the high costs and the need for so many incubation centers for the borg.
control handicaps are a completely different animal.

As far as tactics go, Borg construction ships come into focus primarily when the borg fleet has been destroyed or has been lured away far enough for the enemy to hit the ship. before that the enemy isnt going to get near the ship.

Now at this time if we look at borg play, we see that at this level, a lured fleet or a lost fleet will allow the enemy to destroy existing nodes as well as the construction ship.

Most of the time they do, as in most cases nodes are already building ships at the time that an enemy fleet reaches the construction ship. The enemy then easily destroys the nodes and the construction ship. resources are still as relevant as it would be in the scenario of a queue.

What I suggested was simply setting a very limited queue of about 3 or 4 ships. It may or may not mimic the AI fashion of construction, but will certainly use the initially created ship that was manually constructed as a template. This template will take into account not just configuration, but also time taken by the user to create his ship - it will be monitored from initial hull selection to last "check" click which confirms the creation. so the user who does not have enough resources when setting the queue, will end up setting a longer queue than he would f he did have resources. In both cases the time to manually config is still a factor, the only difference being the optimized click lcikc time, vs the wait for resource time.
On clicking the check button, the user has the option to choose to continue with the node and confirm a queue of 1-3 more ships. At this time, the ship will be constructed with additional resources taken for each node+hull. In effect if the user does not have the resources the construction will stop, as it does in regular shipyards.
So the resource scurrying will still be relevant.

The attacker if able to breach borg defenses to get in to destroy the construction ship will face no different a scenario as he would were he to breach and then find ships being built - being able to destroy the nodes.
moreover, if a priority station is destroyed the entire queue is to be lost, with the resources spent on the "in-progress" ship from the queue (not manual one) being lost as it would be if cancel were clicked instead of confirm.

The only element being adjusted here, then, is the delay in further construction caused by intrinsic human limitations on multi-tasking - focusing on attack and build at the same time (toggling between views). We should note that a small queue of 2-3 ships is still going to expire, and in longer tactical battles the borg will still be handicapped.

We should not forget that borg balancing involves incubation centers, mining, and then nodes+manual configurations. Balancing of the borg took into account resources, and stats of other races. But it did not take into account the human aspect of multi-tasking, where focusing on an attack simply stops all borg building - adding one more inhibition... simply attack the borg with a strong enough fleet and u will buy time to stop borg construction completely.

Which I believe is an additional handicap and must also be accounted for in balancing of borg ships and the corresponding stats.

PS: couple this with miner dances around mining stations, nerfed specials of assimilator beams and assimilation cube beams, as well as placing and building incubation centers to getenough supply, and we have a micro-management nightmare for the borg.

But I look forward to see what the mods have in mind. this may no longer be relevant once they make their changes.....

posted on April 23rd, 2009, 6:08 pm

ok sence I dont have time to read all these long posts, Ill say I agree.  I think it would be cool, if there was a point on the starbase, or other station where a node would be rebuilt. that way after you built a ship, there would a cool down period where the node was rebuilt.  It would also be an avatar bonus, to shorten the cool down/rebuild.  Also this would allow for smaller ships to have a shorter rebuild cycle, becaues less of the node frame was used.  I'm sory if this Idea was already stated, like I said I dont have time to read it all this instant.