Could we make catapults less frustrating to use?

[Boudica]

Hello, I've been thinking about why the catapult behavior makes people mad and what could be done about it. I think there is a thing that could be considered a bug, which is probably easy to fix. Another thing is the UI design for siege packing itself. I've discussed a few times how I'd expect it to work differently but I haven't written it down and I'm not sure if there is any issue for it.

So where do we start? To me the ability to cancel packing or unpacking instantly doesn't make sense. The idea is that the packing process takes time. How is it possible to go from a 99% packed catapult to an unpacked one instantly, while from a 100% unpacked it takes a few seconds? So what follows is simple. We only need two icons: one for getting the catapult to a packed state and another for getting it to the unpacked state. If the packing process is in progress, the process just changes the direction as appropriate (0% is packed, 100% unpacked). If all catapults in the selection are in the same state, the icon can be grayed out.

OK, so that was mostly for the UI design. But what is the single thing that makes people lose catapults and rage quit a game? It's the automatic unpacking and the weird behavior when trying to move the catapult. When enemy units get in the range, the catapult starts unpacking. That sounds about right. Except that at this point that process can't really be cancelled by the cancel icon as it just starts all over again instantly (there are still targets in range, right?). You first have to change the unit stance to passive, otherwise the cancel icon is just for frustration. Then you order the catapult to move and what happens? It continues to unpack, just so that it could start packing up again for moving.

I think that the solution to the other problem is simple. I intentionally started with the idea to remove the cancel icon entirely because then we don't have to discuss what should it do in this case. If the cancel still is a thing, ordering the catapult to move sure should automatically cancel the ongoing unpacking because it's the fastest way that gets the thing done. With my first idea implemented, moving the catapult would mean ordering it to change to a packed state (as explained) with the move command chained. This eliminates people clicking on the cancel icon because they wanted the exact opposite of making the catapult unpack. To sum up, I think this is a small bug of not stopping the unpack process automatically when ordering a catapult to move.

There is a third note to this discussion. I'd suggest to remove automatic unpacking entirely. If you want to have catapults ready to move, you can have that. If you have moved them to a position for attack, you decide to unpack them. I think it happens very often that the unpacking starts when you don't want it. Even with my first idea implemented, if you ordered the catapult to pack, it could start unpacking automatically just after that. I imagine that handling the siege weapons would be much more pleasant if they just simply didn't unpack by themselves at all.

 

[Boudica]

I initially decided to write this all up because I was looking for a smaller issue I could work on myself. But I guess some things need to be fixed in the development process first before I could contribute anything? When I first worked on something here, elexis helped me with everything I need. I heard him say that he'd like to invest a lot of his time into the development again. But guess what? He's been incredibly frustrated with the situation that has been around here recently.

I don't even know who I'm talking to now. I just wanted to show that there are now more people that want to invest their time to make the game better but they can't. And I had the feeling that there is a lot of useless ego involved in this. Could you just put the ego behind in the name of making the game better? I'd personally be glad if elexis got more power in what gets into the game and if we listen to him more. He has incredible knowledge about the code and he puts great effort into making his contributions the best they can get. People from the player community would probably vote for elexis to become the next project leader. Or I sure would.

Please unfrustrate elexis for me and let us work together.

Edited June 19, 2019 by Boudica

[Stan`]

That sounds doable, maybe someone could make a patch for it. @Freagarach Is working on a feature that will allow one to use catapults to bombard areas, which might make them a bit more useful.

[Feldfeld]

Personally, i would prefer still having the cancel button. There was this patch : https://code.wildfiregames.com/D1520, I wonder how it went but it should be useful.
Additionally, I also think catapults shouldn't unpack automatically, they should only do so when we click the button or give an attack order in my opinion.

I'm pretty sure catapults were easier to use in a21, I'm not sure if it's me or if something changed by the time.

Edit : Also, when a catapult targets a unit that goes out of range, it will pack and try to follow it, which can be annoying when we intend to use catapult against army, we would just want it to switch target.

Edited June 19, 2019 by Feldfeld

[Stan`]

I guess packed units should be on standground ? Maybe something to include in @wraitii's changes

[Boudica]

Thanks for the replies. So it seems we can agree on some of the points. And the bugs seem to be known, we just might to check on the existing tickets.

Thanks for mentioning the unit following problem. I suppose it would be taken care of by omitting the automatic packing and unpacking (while an explicit move or attack command can still have a starting implied packing or unpacking prerequisite). Not sure how to handle the case when you try to attack a target that is out of range though. I guess it shouldn't then be possible to do this to maintain consistency. If the catapult moves automatically to have the target in range, why shouldn't it start moving again if a unit goes out of the range later?

I'm not sure what your reasons are to keep the cancel command in place. What do you think about the logical problem of unpacking an almost packed catapult instantly by just cancelling? How to handle the case when there are multiple catapults with different states in the selection? I don't know if I should use the unpack icon or the cancel packing icon. I see several problems with the cancel icon and I don't really see an advantage of it.

@Stan`, I guess standground is the default, perhaps you meant passive instead? I'd just think that the various stances probably don't make much sense for catapults anyway. Maybe there should be one when the catapult just doesn't pick targets by itself (passive) and then the default (standground).

That reminds me of another issue I forgot to mention. I don't know how the attack-move commands work for catapults but it could be useful to tell the catapults to target units in their range. Perhaps this also is solved by targeting areas. Catapults are especially powerful against units but the problem is that it's hard to make them attack units only when there are buildings near.

[Feldfeld]

25 minutes ago, Boudica said:

I'm not sure what your reasons are to keep the cancel command in place. What do you think about the logical problem of unpacking an almost packed catapult instantly by just cancelling? How to handle the case when there are multiple catapults with different states in the selection? I don't know if I should use the unpack icon or the cancel packing icon. I see several problems with the cancel icon and I don't really see an advantage of it.

For me it just feels nicer to use gameplay-wise. Without the cancel i would have to stay frustrated with needing to wait for the catapult to unpack to pack it again. It is also how it's done in AoE2.
Currently, the case where multiple catapults in different states are in selection is handled by having 2 different cancel buttons, although they look the same.
It's also not realistic having to let the catapult finish unpack where it is at only 1% on the progress, but to be fair I don't want to have a game 100% realistic in situations like this anyway.

[Boudica]

Yeah, I know my initial post is quite long (and I tried to make it as short as possible). But let my quote myself:

3 hours ago, Boudica said:

If the packing process is in progress, the process just changes the direction as appropriate (0% is packed, 100% unpacked).

So I didn't suggest to let the catapult finish its current action instead of cancelling. I even later mark that as weird behavior that happens when you try to move an unpacking catapult.

My idea was that if you start unpacking and get to i.e. 75% progress, then you can get to 0% in the same time by ordering the catapult to pack. You mostly only say which state you want the weapon to be in and it gets there smoothly from whatever state it is in. So neither jumping from 75% to 0% instantly (as cancelling does), neither going further up to 100% and only then going back to 0% (because there is no reason to).

[wraitii]

@Boudica What stance does this happen in? Default stance for siege units is Stand Ground, which sounds like it shouldn't exhibit this behaviour - if it does, it should be fixed.

The way I understand it, there are a few things at play:

• Catapults auto-unpack if on "aggressive/defensive/standground" and units come in-range.
  • That does sound wrong on most states to me.
• Cancelling packing/unpacking at 90% progress is instant ( @Boudica you would prefer that it takes as much time to go 0-90 and 90-0 I understand?)
• Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move
  • This sounds broken to me in all cases, even for forced orders.
  • We could do it only for forced orders, never on its own for unforced orders.
• Regular stances are not sufficient for catapults
  • No way to tell them to prefer units or buildings
  • Agressive/defensive/flee/standground isn't very helpful with regards to packing - unpacking.

Is this complete?

Points 1-3 seem like unitAI issues that we could fix for A24 - depending on what happens exactly.
Point 4 is probably something we should do but it would be harder.
Point 2 is doable also, but would be a change of behaviour - not sure if we want that or not, as @Feldfeld has said, AoE 2 has immediate-cancelling.

[Boudica]

Thanks for the summary. I'll just add to some of the points:

1 hour ago, wraitii said:

Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move

• This sounds broken to me in all cases, even for forced orders.
• We could do it only for forced orders, never on its own for unforced orders.

This currently only happens for those forced orders but still it perhaps shouldn't. I'm not really sure if this depends on the stance but I don't think so. Soldiers behave in the same way in that when you make them attack a certain unit, they will do so and even follow it as necessary. We should discuss if the catapult should start moving if the selected target wasn't in its range at the beginning. Otherwise such an action would result in a no-op and the attack cursor better be grayed out for targets out of range.

1 hour ago, wraitii said:

Regular stances are not sufficient for catapults

• No way to tell them to prefer units or buildings
• Agressive/defensive/flee/standground isn't very helpful with regards to packing - unpacking.

Regular units can't be easily told what target type to pick either, so perhaps it is a broader issue. For units, we have the attack move (with possible modifiers), but using an attack move doesn't sound right for catapults that aren't supposed to move while attacking.

The item that is possibly missing:

• Ordering a catapult to move while it's unpacking doesn't cancel the unpacking process and waits for it to complete.
  • This seemed to be addressed in one of the existing tickets.

EDIT:

Oh yeah, and regarding the instant cancellation, I understand that it's how it works in AoE but we don't take that as a relevant argument for it, right? I'd look at what looks more realistic here unless there are good reasons not to.

I've even considered a similar thing regarding buildings several times (going slightly off topic now). An important part of the game currently is deleting some buildings before they get captured to 50%. But isn't that a weird thing to have in the game? It comes to mind that the destruction of own buildings might require workers to be assigned to the job. Similar to construction but faster and actually very close to attacking that building. This is actually quite a different issue but it's similar in the way that something is instant and it might better not.

Edited June 19, 2019 by Boudica

[elexis]

6 hours ago, Boudica said:

To me the ability to cancel packing or unpacking instantly doesn't make sense. The idea is that the packing process takes time. How is it possible to go from a 99% packed catapult to an unpacked one instantly, while from a 100% unpacked it takes a few seconds? So what follows is simple. We only need two icons: one for getting the catapult to a packed state and another for getting it to the unpacked state. If the packing process is in progress, the process just changes the direction as appropriate (0% is packed, 100% unpacked). If all catapults in the selection are in the same state, the icon can be grayed out. 

Maybe that would be more logical indeed.

6 hours ago, Boudica said:

OK, so that was mostly for the UI design. But what is the single thing that makes people lose catapults and rage quit a game? It's the automatic unpacking and the weird behavior when trying to move the catapult. When enemy units get in the range, the catapult starts unpacking. That sounds about right. Except that at this point that process can't really be cancelled by the cancel icon as it just starts all over again instantly (there are still targets in range, right?). You first have to change the unit stance to passive, otherwise the cancel icon is just for frustration. Then you order the catapult to move and what happens? It continues to unpack, just so that it could start packing up again for moving.

March 2018:

• rP21630 Fix UnitAI behaviour inconsistent with its stance for packed units and set default stance to standground for packed units.

April 2018:

• rP21784 Fix a couple of packing problems from rP21630
• rP21786 really fix packing problems reported in rP21630

May 2018:

• #5175

October 2018:

So perhaps the fix to #5091 should be different, I didn't want to get involved with that mudding, but the unpack-loop issue remains reported and is put into the scheduled list #5328 (which means there will be at least three clicks being spent on the issue).

6 hours ago, Boudica said:

moving the catapult would mean ordering it to change to a packed state (as explained) with the move command chained

(Already the case?)

6 hours ago, Boudica said:

automatically cancel the ongoing unpacking

#4015 and D1520 as FeldFeld pointed out.

5 hours ago, Feldfeld said:

 Edit : Also, when a catapult targets a unit that goes out of range, it will pack and try to follow it, which can be annoying when we intend to use catapult against army, we would just want it to switch target. 

Standground?

4 hours ago, Boudica said:

I'm not sure what your reasons are to keep the cancel command in place.

Simulation commands are orders. The user sends an order so as to start a process. UnitAI has an order queue and performs that one step at a time. Orders can be cancelled by removing them from the queue. So it's logically consistent with the UnitAI in general, but this packing AI may be unique and warrant some different behavior. Reverting to 0% slowly seems sound to me instead of instantly jumping to 0%, which indeed would justify considering to replace the cancel command with the pack/unpack command, and account for that somehow in the packing part of UnitAI. Sounds like invoking spaghetti code but, maybe inevitable.

4 hours ago, Feldfeld said:

Without the cancel i would have to stay frustrated with needing to wait for the catapult to unpack to pack it again

But that's the weakpoint of siege engines, they should be and remain that vulnerable during that stage, no?

4 hours ago, Feldfeld said:

I don't want to have a game 100% realistic in situations like this anyway. 

Agree, it must be fun to play. That proportional-progress proposal is possibly still the right thing to do, depending on expectations of logic and gameplay design.

3 hours ago, wraitii said:

Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move 

• This sounds broken to me in all cases
• We could do it only for forced orders, never on its own for unforced orders.

For aggressive stance, and for forced attacks in any stance it sounds reasonable to follow the attacked target. I suppose it's important to satisfy the definition of an order. If there is an order to perform X, then by definition X is ordered to be performed, and that means doing the preconditions like packing to achieve that. So one could introduce an order type (such as ground based attacks) where the siege engine attakcs units in the target area without implying that a specific unit should be attacked (thus not providing reason to have it unpack at any time). Dunno.

7 hours ago, Boudica said:

I initially decided to write this all up because I was looking for a smaller issue I could work on myself. But I guess some things need to be fixed in the development process first before I could contribute anything? When I first worked on something here, elexis helped me with everything I need. I heard him say that he'd like to invest a lot of his time into the development again. But guess what? He's been incredibly frustrated with the situation that has been around here recently. 

I don't even know who I'm talking to now. I just wanted to show that there are now more people that want to invest their time to make the game better but they can't. And I had the feeling that there is a lot of useless ego involved in this. Could you just put the ego behind in the name of making the game better? I'd personally be glad if elexis got more power in what gets into the game and if we listen to him more. He has incredible knowledge about the code and he puts great effort into making his contributions the best they can get. People from the player community would probably vote for elexis to become the next project leader. Or I sure would. 

 Please unfrustrate elexis for me and let us work together. 

Images may vary slightly from actual product. There are many ways to skin a cat. Doesn't require hierarchical force to commit a catapult AI fix. But for my review I need a decision whether I want to be frustrated by throwing or riding the bomb.

Spoiler

 

 

[Feldfeld]

1 hour ago, elexis said:

Standground?

 

1 hour ago, elexis said:

For aggressive stance, and for forced attacks in any stance it sounds reasonable to follow the attacked target. I suppose it's important to satisfy the definition of an order. If there is an order to perform X, then by definition X is ordered to be performed, and that means doing the preconditions like packing to achieve that. So one could introduce an order type (such as ground based attacks) where the siege engine attakcs units in the target area without implying that a specific unit should be attacked (thus not providing reason to have it unpack at any time). Dunno.

I meant when an attack order is given, I wasn't precise. Even if in a general case it makes sense to follow a target with attack order, it is often not the case for catapults who target a unit which goes then out of range (since we just want to target the army actually). And the case might happen if we click on a unit that is out of range but with other valid targets around, would we really want the catapult to take a lot of time to pack/unpack in middle of the fight ? But of course, then comes the situation where we target a unit (building) that is out of range and we want the catapult to do all the actions to do so. Since it's difficult to differentiate the case, a solution needs to be taken. In AoE2, packing the trebuchets is always manual, which can be frustrating especially for players slow/not experienced but otherwise the system works well, it's just a matter of choice i suppose.

1 hour ago, elexis said:

But that's the weakpoint of siege engines, they should be and remain that vulnerable during that stage, no?

Well, the weakness would be far from removed (actually, if only this is their weakness then we could say that current cata don't have weakness since we can cancel instantly if we ever want to). The catapults will still have to pack if you see that your army protecting them is losing and you have to go back. This situation is in the case where catapult starts unpacking because you decided so/made mistake.

[Stan`]

Maybe then we could restrict catapults to buildings when attack range is implemented.

[wraitii]

16 hours ago, Boudica said:

I've even considered a similar thing regarding buildings several times (going slightly off topic now). An important part of the game currently is deleting some buildings before they get captured to 50%. But isn't that a weird thing to have in the game? It comes to mind that the destruction of own buildings might require workers to be assigned to the job. Similar to construction but faster and actually very close to attacking that building. This is actually quite a different issue but it's similar in the way that something is instant and it might better not.

During AoE2's design they considered allowing capturing. The way it worked was that building below 25% HP would become disabled, and repairing them above 50% would make them yours. I've come to think, over time, that this is a strictly better design than ours.

14 hours ago, elexis said:

For aggressive stance, and for forced attacks in any stance it sounds reasonable to follow the attacked target. I suppose it's important to satisfy the definition of an order. If there is an order to perform X, then by definition X is ordered to be performed, and that means doing the preconditions like packing to achieve that

The question is whether the player meant that to happen. All orders from the player are forced, with I believe no way to un-force them. Perhaps we should only mark them forced on double-clicking, not single clicking.

In the heat of a battle, if you order a catapult to attack one unit from a group, you probably aren't expecting it to chase that unit.

[WhiteTreePaladin]

11 hours ago, wraitii said:

During AoE2's design they considered allowing capturing. The way it worked was that building below 25% HP would become disabled, and repairing them above 50% would make them yours. I've come to think, over time, that this is a strictly better design than ours.

That makes more sense than what we have. How would multiple capturing parties be handled? Right now there is split loyalty, and the structure is awarded to the player with the most loyalty points when the original owner's points have been fully depleted.

[wraitii]

1 hour ago, WhiteTreePaladin said:

That makes more sense than what we have. How would multiple capturing parties be handled? Right now there is split loyalty, and the structure is awarded to the player with the most loyalty points when the original owner's points have been fully depleted.

The easy way is to make it so that the first to start repairing is the only one who can until all repairers are killed.

[borg-]

Only manual pack/unpack it would be perfect and simple.