|
From: SourceForge.net <no...@so...> - 2005-08-13 00:48:13
|
Feature Requests item #1256710, was opened at 2005-08-11 13:42 Message generated for change (Comment added) made by eric_mcdonald 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: Eric McDonald (eric_mcdonald) Date: 2005-08-13 00:48 Message: Logged In: YES user_id=1158352 I understand the point you were trying to make. I added the other things to the discussion, because I think they are relevant for getting this "right". We essentially have four elements involved in this problem: player expectations, game designer expectations, the ladder of actions the UI should attempt and which one should be at the top of the ladder, and how much control the game designer should/can have over said behaviors and their possible orderings. If one wished to extend the preferences file and preferences setting system, then a fifth element, player control over the UI behavior ladder, comes into play as well. If at all possible, I do not wish to bias the UI towards any particular game or style of play. Now, one of the reasons that I think a player may currently prefer attack-with-capture over direct capture is that most capturables in most games can be reasonably captured by attacking them without the risk that they will be destroyed in the process. This could change, however, if there could be a true choice between attack-without-capture and direct capture. A game designer could then resonably design a fragile, capturable unit that had best be attacked sparingly, unless one wished to actually destroy it instead of capture it. This is why I think it is important to address the question of separate probabilities for capture-by-attack, capture-by-fire, and direct capture. I am rather tempted to deal with this first, before thinking of changing the default UI behavior. As far as determining whether to directly capture or attack based on cost (or probability, as you suggest, which I thought of as well), I am not sure that it is as terrible as you make it out to be. If separate capture chances can be given for the various actions, then the designer will have all the tools he/she needs to determine which action is most natural. Presumably, if he/she did a good job of designing the game, the most natural action would correspond to one the player would find_, well, most natural. I think this is important, because, in your analysis, you focus on the player and the UI, but ignore the possibility that the game designer can help forge the UI behavior to meet player expectations. (I certainly agree with your comment about materials transfer. That behavior is indeed bad.) As far as your reference to bang-for-buck calculations goes, I just got done making a zillion of them a few weeks ago. Perusal of 'aiunit2.h' and 'aitact.h' will reveal those. As far as applying such things to the UI, I'm not sure that that is a good idea. I believe, and I think you believe as well, that the UI should be obedient to the player's wishes and should not try to second-guess the player. One particularly annoying example, which I fixed well over a year ago, was that the UI used to automatically try resuming construction on the nearest unit rather than honoring the actual utype the player wanted to create and where the player wanted to create it. I think Hans had originally put that logic in [the build task] to help the AI, and had apparently been oblivious to the fact that it was overriding the player's wishes. So, when you say that we should not bake something into the UI, I wholeheartedly agree. The point of me suggesting some sort of dynamic criteria (such as resources used by each action) was to help make this behavior more adjustable on a game-by-game basis. On a different note: it does not surprise me that there is separate behavior for advanced units. In introducing advanced units, Hans essentially created a game engine within a game engine. They also had their own separate mini-AI, which ran in the kernel run code! And, there are special behaviors associated with them, such as if you perform a create action on one with an unit that could build the type of one while said unit is in one. As I have proceeded with the remodeling (since Xconq seems to be a _This Old House_ rerun writ in code, except that I'm not Bob Vila (sp?) and I don't use Sears Craftsman compilers), I have tried to integrate handling of ACP-indep and advanced units into the mainstream code, but I wish Hans had done so from the beginning. ---------------------------------------------------------------------- Comment By: Matthew Skala (matthewskala) Date: 2005-08-12 03: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-12 00: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 |
