Showing a warning when attacking a territory where units can scramble.
-
@Hepps said in Showing a warning when attacking a territory where units can scramble.:
... why does the game automatically prompt the defender to scramble to any and all attacks, ...
I'm not sure how triplea could do it otherwise. At the end of the combat move phase is when scrambling takes place ( in the global game ). If there is no prompt asking if you want to scramble, when would the defender have the chance to do it ? Change the prompt to "Any Defender Action ? " and not mention scrambling ? Scrambling is the only action they can take though, so idk how that would be any different.
The way forum games are played, after the attacker makes his moves they ask the defender if he wants to scramble. I don't see how that is anything other than normal game play. What it doesn't do is say "you could be scrambled on this attack".
How do ftf players handle it ? I don't ( sadly ) play ftf so idk. Does the defender have to jump in and say i want to scramble without the attacker saying anything ? Maybe a 60 second window for defender to scramble at end of combat move ? You'd still have to say when that window opens which is basically saying the same thing, do you want to scramble ?
As I said above you could just ask "Any Scramble" without giving the specific options, but that seems as if it would unnecessarily make the whole thing take longer. i guess you could make an option that does that or keep it the way it is but either way the defender has to be asked if he wants to scramble at some point.
-
i think if anything it should be a game option that way it can be agreed upon before the start of the game i think it would def be helpful for players who are getting used to it. Myself i still get surprised by them sometimes especially with the scramble to any amphibious assault option enabled.
-
just had another random thought about this i do like @Hepps UI indicator idea but it might also be good to add it as an option to the battle calc. Like a check for scrambles button or something.
-
wow this got uber in-depth anal-retentive game nerdy
-
@Hepps said in Showing a warning when attacking a territory where units can scramble.:
I think my argument would come down to one thing... why does the game automatically prompt the defender to scramble to any and all attacks, but not remind an attacking player that those those possibilities exist during the attacking phase.
If we have automated the potential options for defender... why then should the attacker have the entire burden of experience be placed on their skill and insight-fullness?Because it is the attacker's turn, not the defender's. The attacker triggers a potential reaction of the defender. The defender simply kicks in at one time during the attacker's turn when deciding about a scramble. The defender needs an information that he has to perform a single action (scrambling) despite it is not his turn. Once the defender becomes the attacker again (on his turn) "all the burden" is on him. That is fair. It's the nature of the game that the player whose turn it is has all the burden.
Anyway, I think we have a consensus with an acceptable solution.
Don't always trust TripleA when it comes to rules questions. Know the rules before you start … and better check what TripleA has done.
-
Would need a new phase 'Scramble" at end of combat move, Don't know how much work it'd take but "Do You Want To Scramble ? " as opposed to saying what you CAN scramble, as it is right now.
Anyway, I like the Feature, think it should be optional : )
-
@Panther I appreciate everything you're saying and get the rationale behind it. There is something to be said about a player being aware of whats going on in the game he is playing and winning (or loosing) based on the merits of his own gameplay.
-
@beelee said in Showing a warning when attacking a territory where units can scramble.:
Anyway, I like the Feature, think it should be optional : )
Would be great if it could be set up as a map option...
This way the players could decide at the outset of a game whether they want "training wheels" or not.
-
heh heh I wonder if the AI could use it ? I know I need as much help as possible. Not just in triplea but life in general
-
@beelee The code for this feature is actually taken from the AI as it already does a check to see what units can scramble to territories its considering attacking.
-
Nice ! Sorry AI
-
Did this discussion and its results have any effect on coding and implementing this feature?
I see the pull request has been merged now .... -
@Panther The feature is behind the 'beta-feature' test flag available in 'game settings > testing', and is now available for experimentation. Merge is not the end of the story, it's the start, see: iterative-development
It's a project anti-pattern for PRs to be open for long periods of time (ideally it's hours or a day or two). https://blog.newrelic.com/culture/long-running-branches-considered-harmful/
We are labor-scarce, we tend to take longer, but even so PRs are ideally merged relatively soon so we can avoid the risk and unnecessary overhead of long-running branches.
-
@LaFayette I understand. I was just asking.
How do we keep track of the ideas developed during a discussion?The feature for now has been included "as is" with the normative power of the fact.
How to make sure that the result of this discussion will be considered/implemented at any time?This topic will get buried in forum history soon.
-
@Panther not easy questions to answer it turns out:
How do we keep track of the ideas developed during a discussion?
There is not set process. Keeping track of 'feature requests' is done via larger list in forums, for a specific feature, there is nothing set. The answer to this I don't think changes whether we are pre-merge or post-merge of the first version of a feature. We should not expect for updates to have every feature on the first version. Merges are not indicating that a feature is done and complete and will not be touched, but it means we have a minimum, useful start. For example, detecting a scramble is a feature, displaying the warning is a feature that builds on top, and giving an option to hide/ignore or always show the warning is yet another feature. It's not just one feature, but a set of features, we should not try to build it all at once.
The feature for now has been included "as is" with the normative power of the fact.
I respectively disagree with the concept of 'normative power of the fact'. I see many shortcomings from legacy technology that have morphed from "we don't do this because the technology does not allow us to", to "it is a rule that we don't do this". We lose sight of when we don't do something because we couldn't, rather than shouldn't. Having access to the code history, a number of things are clearly accidental and limitations rather than intentional rules.
To illustrate this difference in perception, a good example is spaces in names. Many years ago, lots of code was rushed out. Shortly later, it was realized that tracking users by name is not a great thing and there are problems with it. There was more code added to handle this situation, hence why duplicate logins get the " (1)" appended to them and a rule was added to disallow spaces in names so that player tracking strategy (by name) would work. Later the context was forgotton, lost, polished over, and the original: "we hacked up some code and made a bad decision and then hacked in even more code to make it work", morphed into: "It was wisely decided and mandated that users should have no spaces in their names."
So maybe to another extent I agree actually to this "normative power", but I'd point out that a number of the norms are accident, not the results of reasoned decisions. We have the power to release frequently now, to make updates to the codebase without huge overhead, so we can change things. Before it was all a process of sending email patches to Veqryn to be included on the next release, that is a six month turn-around, something that we do now in hours.
This topic will get buried in forum history soon.
The merged feature is behind the 'beta-feature' flag. It won't come out from that for a bit. That helps ensure we keep working on it. This thread won't drop in history quite that fast.
A bigger issue is we need to decide requirements for the next iteration sooner, rather than later. If we can't come up with those requirements, the coder will do their best and will be forced to decide them where needed. If we delay on defining requirements, it's going to be a headache and lost effort.
I expect @Alexei-Svitkine will jump in at some point, summarize the suggestions and discuss pros/cons and which ones he thinks are feasible and best to continue exploring.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login