|
From: SourceForge.net <no...@so...> - 2005-08-12 03:59:42
|
Feature Requests item #1256710, was opened at 2005-08-11 09:42 Message generated for change (Comment added) made by matthewskala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1256710&group_id=124062 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Skala (matthewskala) Assigned to: Nobody/Anonymous (nobody) Summary: Attempt attack by default Initial Comment: There's some room for debate as to what's the correct behaviour here, which is why I'm filing this as an RFE instead of a bug, but: If I click on an enemy unit to attack it, the UI code will make a capture attempt if capture is possible at all; and a capture attempt means no attack attempt occurs. On the other hand, if I explicitly request an attack (not capture) I get the capture attempt afterwards anyway, and for free with no ACP cost. When capture is available as a choice, then attack will only be availabe if explicitly requested. If (as is the case in one game I'm working on) the chance of success with an attack is high, but the chance of success with a capture is low, then just clicking around on the map means I'll be wasting my effort in seldom-successful capture attempts. I'd rather have the default when I click be "attack", and do an explicit capture command when I want to attempt a capture without doing damage. That seems more intuitive and useful. It might be possible to simulate in the GDL by using the "surrender" mechanism rather than the "capture" mechanism, but that may have different semantics, it means capture as a separate action without attack is no longer possible, and I don't know whether it would connect with the changed-type-if-captured table. I think the simplest way to make this change would be to move the capture logic that starts around like 3336 of ui.c, to after the regular-attack logic, but I haven't tested that carefully. ---------------------------------------------------------------------- >Comment By: Matthew Skala (matthewskala) Date: 2005-08-11 23:59 Message: Logged In: YES user_id=1167698 I agree that it would be nice to be able to separate capture completely from attack, but that's not the point I was intending to make. At present, the system provides attack with capture, and capture alone, and defaults to capture alone. Those choices are okay for the game in question, but I think the player is likely to want "attack with capture" much more often than capture alone, and I think the player will expect that to be the default. Capture alone, which is what you'd want if it's important to take the target intact, is currently available if you ask for it explicitly, and would remain so; it would just stop being the default. I don't like the idea of having the default depend on which action is more expensive in ACP, because that would make it even less predictable for the user than it already is. The crux of the problem, as I see it, is that when I click on an enemy unit I expect to be attacking it. Some units I can try to capture instead of or in addition to attacking, and I think "in addition" is closer to what I expect when clicking in general means "attack". If I want to only capture without attempting to do damage, I'll ask for that explicitly. But although changing the meaning of a click depending on whether capture is possible is bad, it would be even worse if it depended on ACP costs, because then to predict the behaviour I have to think about not only whether capture is possible, but how expensive it might be - I have to memorize a bunch of rules from the individual game just to know what one of the most frequently used commands in the UI actually does. Then it would seem like "when you click, the game will decide for you whether you want to attack or capture", and I'd expect to spend a lot of time as a player cursing it for overriding my wishes. (Much the same annoyance that crops up with the materials give and take commands, which often exchange with a unit other than the one I'd have wanted.) Inconsistent or unpredictable meanings for a user interface command = teh bad. The point about it being preferable to capture an enemy unit undamaged is a good one, but in the situation where neither attacking nor capturing is likely to defeat the unit in one attempt, I'd much rather have a chance at both instead of attemping only the one that's least likely to succeed. It's not clever to go to lengths to protect an enemy unit from harm, just so it can destroy me while I'm waiting for the rare event of taking it cleanly. I also think that's very much a decision that should be up to the player. It's not one we should decide in advance and bake into the UI. Maybe making the default depend on the percentage chance of success - do whichever one is most likely to succeed - might be a better idea than making it depend on the cost of the attempt, although it still has most of the same disadvantages. It's also possible to imagine (though the predictability would be very poor) a formula that would calculate how much "bang" (in terms of chances of success) you get for the "buck" (of ACP cost) - roll in chance of success, expected amount of damage done for attacks, and cost of the two actions. That might be more appropriate for the AI, though, in deciding what it wants, than for the UI in deciding what the player is likely to want. Note: there is special handling in the code for advanced units. I don't fully understand the rules there, but it looks like there's some kind of handling to make it easier to capture an advanced unit if there are no occupants to act as defenders. It may be that that's aimed at the idea that attackers won't want to cause damage to a unit they're about to capture, if they can capture it without causing damage. I don't think it applies to non-advanced units, though. It may be, from a philosophical point of view, that I'd be best served by simply using the "surrender" mechanism in my game instead of "capture". It may better reflect what I'm trying to do with the low capture chance and relatively high hit chance. I wonder if it'll be possible to make a type change happen on surrender; I'll have to check whether it uses the changed-type-if-captured table. ---------------------------------------------------------------------- Comment By: Eric McDonald (eric_mcdonald) Date: 2005-08-11 20:06 Message: Logged In: YES user_id=1158352 My biggest problem with the whole attack/capture issue is that there is not a separate table for capture chance from an attack. I ran into this problem several years ago, and it annoyed me. Basically, if you want to allow direct capture, and attack, then you also automatically allow capture-by-attack. From my point of view, I think direct capture could be made into a more useful game device by having the ability to shut off capture-by-attack (and capture-by-fire). As far as the UI attempting direct capture before capture-by-attack, I have mixed feelings on the subject. On the one hand, I certainly see your viewpoint. One the other hand, I think we should still prefer the more graceful method. Why trash something that you can capture cleanly? Was it not Sun Tzu in his Thirteen Chapters (aka., the Art of War), who recommended that attrition only be used as the last resort? One possible improvement would be to always choose the method that costs the least resources (ACP inclusive-or materials). If an attack (with or without capture) cost less than a direct capture, then that would be preferred. Otherwise, the direct capture would be attempted. But, like I said at the beginning of this reply, attack-with-capture being implied by a >0% capture chance and the availability of an attack bothers me more than the UI's affinity for one or the other. I would rather be able to shut off the capture extension for attacks and firing. This would cleanly separate the two actions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1256710&group_id=124062 |
