Cruiser Command

Corinthian wrote:I LOVE IT.

... but even if it was more expensive... it would still be MASSIVELY EXPLOITABLE (just take my word for it)

The least broken way I can think to use it:
If the research time was low enough, <5 seconds, it could be used as an awesome escape plan.

450 regular resources + 50 kerm just to make a single escape sounds like it would take a lot of coordination, and put you a bit behind. I don't feel it's something you can usually pull off when being surprise attacked, and on the other hand if you're full and ready (yet still running) you should be at a disadvantage. At a disadvantage, that 50 kerm means a lot.

I said least broken.

We are all becoming really good at coordination.

I will message you the minimum energy equivalent of the purchase.

aw no bomber man mimic XD

Hope raises a good point. In bomberbot, or whatever it's called nowadays what with all the "clone-of-a-real-game" maps, after a set time, the map starts shrinking until it is too small and the enemies can't get away from each other.

It could be something along the lines of:

• 60 minutes: No wrap.
• 70 minutes: Map size shrinks to 9/16, in the sense that its width is shortened to 75% of the original width, and the height is shortened to 75% of the original height. Battlecruisers get moved to within bounds on their respective sides at the border. For example, if a BC is at (x, y), if x is out of bounds, then move the BC to ((.75 * max width), (max width * y / x)), so that the new x coordinate is within bounds and the new y coordinate puts the BC in the same direction from the origin of the map. Repeat this with x and y reversed to get y within bounds if needed. Even easier, multiply position by .75 of the BC, guaranteed to be within new bounds, so then if it wasn't at the border before, it's not at the border now, and no if statements needed.
• 80 minutes: Map size shrinks to 1/4, with width and height shortened to 50%. Same translation needed for the BC.
• 90 minutes: Map size shrinks to 1/16, with width and height shortened to 25%. Same translation needed for the BC.

Edit paragraph: It could even be a 'continuous' event, with each second the width and height of the map (and position of ship objects) is shrunk by .0005, which would take 2000 seconds to completely shrink the map to 0, or exactly 30 minutes to shrink it to 10% of its original size in either dimension. This would do a pretty cool job of simulating a gravity well in the center, I would imagine.

Now, the enemy BC would be within ~1 boost of you, and it would be hard to avoid the final confrontation. Especially now that repair stations have been brought in line with the upgrades.

Also, I would rather wait before implementing something new, just to test out how the disabled map wrap affects the end game and to see if it is actually enough to narrow the length of the end game.

zakhennahr wrote:Hope raises a good point. In bomberbot, or whatever it's called nowadays what with all the "clone-of-a-real-game" maps, after a set time, the map starts shrinking until it is too small and the enemies can't get away from each other.

It could be something along the lines of:

• 60 minutes: No wrap.
• 70 minutes: Map size shrinks to 9/16, in the sense that its width is shortened to 75% of the original width, and the height is shortened to 75% of the original height. Battlecruisers get moved to within bounds on their respective sides at the border. For example, if a BC is at (x, y), if x is out of bounds, then move the BC to ((.75 * max width), (max width * y / x)), so that the new x coordinate is within bounds and the new y coordinate puts the BC in the same direction from the origin of the map. Repeat this with x and y reversed to get y within bounds if needed. Even easier, multiply position by .75 of the BC, guaranteed to be within new bounds, so then if it wasn't at the border before, it's not at the border now, and no if statements needed.
• 80 minutes: Map size shrinks to 1/4, with width and height shortened to 50%. Same translation needed for the BC.
• 90 minutes: Map size shrinks to 1/16, with width and height shortened to 25%. Same translation needed for the BC.

Edit paragraph: It could even be a 'continuous' event, with each second the width and height of the map (and position of ship objects) is shrunk by .0005, which would take 2000 seconds to completely shrink the map to 0, or exactly 30 minutes to shrink it to 10% of its original size in either dimension. This would do a pretty cool job of simulating a gravity well in the center, I would imagine.

Now, the enemy BC would be within ~1 boost of you, and it would be hard to avoid the final confrontation. Especially now that repair stations have been brought in line with the upgrades.

Also, I would rather wait before implementing something new, just to test out how the disabled map wrap affects the end game and to see if it is actually enough to narrow the length of the end game.

I like the idea, but before we start considering such changes I think we need to get some in game action and see if what we already have is actually enough. Further alteration may actually be entirely unnecessary considering the current scheme.

i would just put a firewall around the edges (kinda like the one mission in the WOL campaign) and it would get closer and closer! call it a plasma storm for all i care!

Red-Rocket wrote:i would just put a firewall around the edges (kinda like the one mission in the WOL campaign) and it would get closer and closer! call it a plasma storm for all i care!

Number one reason I think this won't work:

This does not penalize the running player. It hurts both sides equally, meaning that the better equipped team won't be able to chase most effectively -- it will be the team with the most hull upgrades. Even assuming you deal 1000 or even 2000 damage with each wrap, it'll only take 5-10 repair kits to heal each respectively even with the new patch on Nanobot Miniaturization. Damage is not the issue.

Crowbar brought up a very good point when I was discussing this with CCA; so long as we're going this route, why wouldn't it deal core damage instead? Core Purging costs actual Kermiculite, meaning that the chasing team will end up worse for wear when it comes to the core damage, which will also cause a lot of issues regarding power.

However, I do not think this is the solution either. This means that if the running team has a superior power manager, ignoring everything else, they can run away effectively without worry still by managing core purges. And, to boot, the chasing team ends up losing Kermiculite for the chase.

So yeah. I don't think this is the solution either, sorry.

It's already that way that the chaser can push the core for an energy advantage for the sake of kerm.
This change would just speed the whole running/chasing part up by further increasing the need of kerm to effectively hold a stability or energy advantage.

It would also prevent several map wraps in the matter of a few seconds, which would currently result in the chaser losing the track (even though the ping up helps) and thus losing a lot of energy, buying some time for the runner.

I think the core damage idea is a quite good one.