Variable time restriction on building off an MCV -- I mean something like, if you immediately place down your MCV at the start of the game you can start building right away, or another player can put down buildings next to you as soon as they can build them. (So the same as the game functions now.)
But however, if you try to drive a little way to another ore patch, maybe there is a 5 second delay proportionate to the driving time. Or if you try to drive over to the enemy for an immediate base push, maybe something like a 12 second delay depending on map size of course.
I'm guessing this wouldn't technically be an easy thing to change in the game.
It's just a suggestion that might make a difference to base pushing right at the start of the game, or to single MCV base pushing. (Which maybe some people like and consider a fair strategy anyway.)
Perhaps the same distance rule could be applied to Chronosphere as well.
This suggestion obviously wouldn't stop base expansion and base pushing from being powerful tactics generally speaking (and I wouldn't even want that).
Variable time restriction on building off an MCV
Why is another punishment needed for a player who already sacrificed several seconds to move his MCV on game start?
A lot of useful discussion on basepushing can be read in this thread. Proposed feature doesn't really solve most of them, introduces unneeded complications and is counter-intuitive.
A lot of useful discussion on basepushing can be read in this thread. Proposed feature doesn't really solve most of them, introduces unneeded complications and is counter-intuitive.
Why more punishment for it when you have already lost a few seconds? -- because it can still be a very strong tactic if a team works together and has a turret and barracks ready. If you aren't consciously thinking of defending against the tactic, and/or your team aren't all skilled players, then early base pushing can end games quickly.
And it might be thought to be a cheap tactic that should be discouraged.
I would also mention that the OP explicitly said that it wasn't about all issues to do with base pushing. And actually, I don't want to stop base pushing by any means. I like base pushing and it's fine that it's part of the game. This is just an idea for reducing certain (arguably) cheap tactics, or too powerful tactics.
And it might be thought to be a cheap tactic that should be discouraged.
I would also mention that the OP explicitly said that it wasn't about all issues to do with base pushing. And actually, I don't want to stop base pushing by any means. I like base pushing and it's fine that it's part of the game. This is just an idea for reducing certain (arguably) cheap tactics, or too powerful tactics.
-
AoAGeneral1
- Posts: 597
- Joined: Wed Apr 29, 2015 6:11 pm
This won't work because this will punish defending players in other ways. If you move your MCV because you hear "Atom Bomb, Detected." redeploy somewhere else safer you have 5 seconds-ish to build something.
Another example can be your being grenadier/flamer rushed and move your MCV to protect it. Punished for protecting early game.
Another example can be your being grenadier/flamer rushed and move your MCV to protect it. Punished for protecting early game.
Yes but then it could be argued:AoAGeneral1 wrote: ↑This won't work because this will punish defending players in other ways. If you move your MCV because you hear "Atom Bomb, Detected." redeploy somewhere else safer you have 5 seconds-ish to build something.
Another example can be your being grenadier/flamer rushed and move your MCV to protect it. Punished for protecting early game.
(1) you "should" have some defence around your MCV, and it's fair to get a little more punished for not having it.
(2) a few extra seconds punishment isn't a big deal anyway. You take a risk by using APC attacks in money/production time so if you can sometimes get something out of it well that's fair enough.
Also, at the nuke stage of the game, losing a few seconds of production time may not be a big deal either. You may well have multiple MCV by that time anyway so you will likely be able to continue to build with just slightly reduced build speed I'm guessing.
The OP idea could be done in a couple of different ways:
(1) delay being about to build off a deployed MCV
(2) delay being able to deploy your MCV. So a "cool down" period is needed after medium/long travel before you can deploy. (Wouldn't have to apply to very short travel time.)
I think the second way is more interesting, because it makes an expanding player more vulnerable to an enemy army or enemy air attacks. Expansion would still be powerful, but there would be less value in rushing to expand perhaps.
Also it could reduce the ability of Chrono base attacks as you could more easily kill with air.
(1) delay being about to build off a deployed MCV
(2) delay being able to deploy your MCV. So a "cool down" period is needed after medium/long travel before you can deploy. (Wouldn't have to apply to very short travel time.)
I think the second way is more interesting, because it makes an expanding player more vulnerable to an enemy army or enemy air attacks. Expansion would still be powerful, but there would be less value in rushing to expand perhaps.
Also it could reduce the ability of Chrono base attacks as you could more easily kill with air.
Hm, I've actually come up with a simple solution to heavily punish base pushing in NvN games - just don't check "Buid off allies con'yards" and that's it. Player that does early game base move will then face N already built up enemies and their armies with no support from his own allies.
Basically, I think the main problem in multiplayer base pushing is that one player moves the base and then provides the build space for others, so that they can do immediate reinforcements right into opponent's bases without getting much harm to their ones.
Basically, I think the main problem in multiplayer base pushing is that one player moves the base and then provides the build space for others, so that they can do immediate reinforcements right into opponent's bases without getting much harm to their ones.
So, instead of using the feature that is already sufficient to fix the problem you mention, you suggest to introduce another feature which would require code implementation and then would break the current game balance by introducing new complications and possible currently unknown problems. I doubt this is how the project is intended to evolve.
well that sounds familiarnetnazgul wrote: ↑So, instead of using the feature that is already sufficient to fix the problem you mention, you suggest to introduce another feature which would require code implementation and then would break the current game balance by introducing new complications and possible currently unknown problems. I doubt this is how the project is intended to evolve.
Nice, so I already have a grasp on how's everything done hereHappy wrote: ↑ well that sounds familiar
