Blitz more like amphibious attacks?

Cernel

In my opinion, blitz is a bad (I would say silly) rule, that should not exist, and I suggest avoid having it for any custom maps.
Main reasons are:

When you get blocked, it makes no sense that 1 thing blocks 1 million things.
When you don't get blocked, it makes no sense that it is as good to directly attack a territory or first taking another empty one for free (simple example is WW1 Classic with the armour that blitz some Saharian territory before attacking Egypt; you would not do that, realistically; if you want to attack Egypt, you would just attack Egypt, taking something else should not be free, but should require that at least 1 of your unit is not available for something else, meaning you would be weaker in attaking Egypt, if you want to take something else on the same turn, even if undefended).

If you want a strategic penetration dynamic of some sort, a way you can do it is giving players two turns, one after the other, except the productive things not repeated, and setting a limited number of combat rounds.

What you are suggesting, that it is practically allowing a same player to do canopeners for itself, can actually be already mostly achieved, but you really need to have a good hang on the xml, and it might be argued it is a hack (I might actually release a mod doing it in the near future; I'll tell you here, in case).

liberty_lion

@Hepps I agree, there are many details to work out. I don't have any hard thoughts about which way these should go. What I considered "default" is to treat the blitzing units as if they are in a "virtual transport" and thereby dependent on the non-blitz battle. Could something more complex make sense and be done, perhaps. However, I would prefer to see some option like this than status quo.

@Cernel I see your point about the silliness, though couldn't a map maker leave the "canBlitz" flag false on all units, thereby eliminating the blitzing ability for the map/game? Is there a reason to set this flag to true for units that is unrelated to silly blitzing?

Perhaps blitzing should also require either:

At least one land unit remain in the initial region, or
The second region cannot be adjacent to the initial region

For #2, if two regions are adjacent to an initial region, then neither can be the subject of a blitz from the initial region. This would not prevent a single land unit from taking the non-blitz region and then the remainder of the attack force engaging the blitz target region, so on first consideration #2 is similar to #1, though #1 would have other, greater implications.

So perhaps there are more aspects to consider and if they are important enough to do, then that would be good too. If the solution/suggestion is to do two combat phases, then perhaps that is enough, though why not do this to handle amphibious attacks too?

Cernel

I don't believe, sounds aside, that there are currently any other implications from not having blitzing. If a map doesn't have any blitz units, then its multiple movement units will always end movement upon conquering an undefended territory.
I think this is preferable but, on the other hand, you could still get through with multiplayers "canopeners" (a player takes the territory, then an ally moves its multiple movement units through it).

Hepps

@liberty_lion As I said... it's an interesting concept. See if more people chime in with idea's.

wirkey

@liberty_lion In one of the board games, might have been revised, there was an optional rule. If all defending units are destroyed in the first round of combat, tanks may move one more space to an empty hostile territory.

Cernel

@wirkey You might be thinking about the "Panzerblitz" National Advantage for Germany in Axis&Allies Revised, but I just checked that one allows only to Non Combat Move further 1 if you win in 1 combat round (potentially making your Armours move 3 spaces total).
That is still a cool concept, as it allows fast unit to work akin to air units (kill the enemies, then move out of counterattack), and it would be particularly cool if applied to cavalry units, also before WW2.
But, yah, that's more of another way to have the special ability of air unit, than a blitz thing, tho taking a hostile undefended then going in a friendly is blitzing too, technically (still, you cannot wait NCM to do it; so, not strictly).
I always wanted a way to retreat with land units after killing all enemies, and maybe I will make a feature request about it (I talked about it in the old developer forum, a while ago).

wirkey

@cernel yeah, that's what i was talking about

prastle

@wirkey it also occurred in Xeno's version but they had double combat move round 1 only

wirkey

@prastle yeah, I loved that game, although it had a lot of flaws. A friend of mine has that board game but we haven't had time to play it in ages.

zlefin

A long time ago I was considering some sort of deep penetration mechanic;
the one I was considering would be that blitz (or super-blitz or whatever y awanna call it, since it'd be a different mechanic than the standard blitz rules) units could go past enemy defenders, but only if there's at least 1 other attacker for each defender.
so for instance, if you have 1 infantry and 2 tanks to attack with; and the defenders are 2 infantry; then one of the attacking tanks could go deeper, but the other tank would have to stay there
whereas if there was only one defending infantry, then both tanks could go past.

Hepps

@zlefin So if there was as in your second example.... would this then leave 1 Infantry to attack 1 defending Infantry?

So then in this type of scenario.... I am assuming the results of the first battle do not impact the "Super Blitz".

I like the concept.

prastle

@hepps no leaving 1 infantry and 1 tank to attack the 2 inf. while the other tank goes deeper I believe. Neat idea @zlefin

Hepps

@zlefin This type of system could also be used to deal with the blocker flotilla's in naval and add a very interesting dynamic that could potentially back fire on the attacker.

No idea how this would be coded.... But I like the concept.

zlefin

@hepps
correct, in the second example it would leave 1 infantry attacking 1 defending infantry and the results of the first battle don't impact whether the second is allowed. so it'd be more of a sacrifice play to serve as a distraction while the blitzers go deep in that case.
code-wise, all the validation/control has to happen in the combat move phase, for combat itself units simply attack the province they're in.

in other circumstances it simply functions as a way to let massive stacks go past small blocker forces.

I don't remember how hard/feasible it is to implement; as it was long ago that I looked. you definitely have to make sure it has some validation locks in place to prevent people from undo-ing actions that were necessary to have enough units in the territory to let other units go past.

as I think about how it'd all work; I wonder if air units should be able to provide the "pin"; or if only units of the same domain (air/sea/land) should be able to provide the distraction that enables other forces to go past.
if an air unit was part of providing the pin, then you'd need to make sure it couldn't move again; code-wise it's probably a bunch easier to do if air units can't provide a pin.

aye, it would also help deal with the one blockin gship issue.
I think I was playing a lot of nwo when I was looking at the idea; as nwo has a lot of huge stacks blocked by one small thing. ofc changing that would massively change the balance on nwo.

prastle

@zlefin and why can't we make you a mod/dev again?

Hepps

@zlefin whether you included the feature in NWO is a matter of deciding whether to include it or not.

In all reality... this feature would likely be independent of the current mechanics.... so you would likely end up making a stand alone version and then re-balance the game to suit.

General_Zod

@zlefin

It seems that the only way to implement this via xml would be to count units. That's a big xml hurdle, imo. Other components appear reasonably doable.

The idea as a whole is cool, maybe place a feature request once you confirm what is truely missing to make it happen.

Although I should add counting units is also doable just extremely unpractical to code in existing xml.

CrazyG

There is a map called roll through the reich which had something like this. There was a second combat move phase that only allowed tanks and other mechanized units to move

zlefin

I looked a bit at the code to see how hard it would be to implement one of these; it looks like it would require a moderate amount of work, but not huge. definitely not trivial though.
If I had to guess, i'd say 6-10 hours of work (factoring in the thoughtful coding, some ui decisions, debugging, and discussion), but it's notoriously hard to estimate work times on things like this.

most of the work would be changes in movevalidator as far as I can tell, with maybe a few ancillary changes elsewhere. there's several different sections of code in there that would need to be modified to allow for some form of deeper blitz, and it's not quite as simple as just adding a check.

you'd need to decide which implementation(s) to use if you were gonna do something; my proposal, liberty's, or some other one. Doing multiple proposals at once is definitely more work than just oding one, but there's a lot of overlap, so if in the future you'd want want more than one of the implementations, it could be worthwhile to do all at once.

if one were to go for a proposal, there's a number of particular details to work out in relation to the ui about what makes for the best/easiest interface for it. like will it autoform a blitz path if you click deeper into enemy territory; how to decide which units are getting left behind for the pin force (under my proposal).

so i'd say the main question/process from her eis:

is there a mapmaker going to make a map, that will see sufficient use, to justify the work of implementation.? if not, wait until there is.
if so, then start ironing out the details of the behavior and how it will present through the interface.

redrum

@zlefin Really depends which of the several different proposals you went with as some would be much easier to implement than others. I would say probably all of them would take more than 6 hours of development especially when you consider unit tests and manual testing. Probably more like 10-15 hours for the ones that aren't too complex would be more realistic.