Spring RTS Engine

So after of losing some games, I decided it was not my own fault but instead blamed the game/engine.

There is ambiguity in the mouse control scheme regarding single unit targeting and area commands.

To target a single target you have to press the mouse button and then release the mouse button over the target without moving the mouse.
To make an area attack you have to press the mouse button and then just move the mouse a few pixels or more and then release the mouse button.

I think there is some ambiguity between these 2 as it requires too much precision from the player in order to execute a single target command because if the player moves the mouse in the slightest while he clicks, he will not get a single targeting command but an area command.

Compare that to Starcraft where a command is executed on mouse button press and the release of the mouse button is irrelevant. This gives much better precision to the player.

However in order to use such powerful UI options such as area commands, lines of buildings and custom formations, commands can't always be executed on mouse button press.
In this simple widget for attack commands, area commands will be overridden if there is a unit under the mouse cursor on mouse button release. This makes precision targeting easier for the player while still allowing them to perform area attacks with ease.
However there is some ambiguity when trying to perform an area attack as any unit that is under the mouse cursor during mouse button release will trigger a single target attack even if that is a friendly unit.

Problems with default targeting behavior:

1. Targeting enemies with attack commands or area attack commands
Attack command is usually the default command that you get when you right click on an enemy unit. However targeting that specific unit under the mouse cursor can be pretty tricky.
If the unit is moving, a new player will naturally try to move the cursor with the unit and get an area command. If the player is trying to target a specific airplane this is very hard as he basically needs to hold the mouse cursor completely still on a moving enemy while performing the click as fast as possible without a big delay between mouse press and mouse release because otherwise the unit will pass by under the cursor.
The area command is an upright cylinder that requires that the unit center is inside the cylinder. Even if the cursor is on top of the unit during mouse button press and release, an area command can totally miss the intended target if the area command doesn't extend all the way to the unit center.
Worse yet. If you are trying to target an aircraft, the cylinder is likely to be offset by the camera angle and miss the aircraft completely.

2. Repair and load targeting
Repairing and load area commands seems to be spheres that only have to touch the unit radius to include that unit.
Targeting a specific flying unit with a repair commands is particularly tricky as area commands will originate on the ground and therefore probably not reach the flying unit regardless of the camera angle.

3. Reclaim
Reclaiming an enemy unit is particularly difficult as any area command will ignore units and only target features. Reclaim area commands also seems to be spheres.

4. Capture
Capture is weird because the area command seems to be a cylinder with extended radius, as enemies will get targeted even if they are quite a bit outside the area command. Tested in XTA 9.745 with /luaui disable.

5. Single placement and multi placement of buildings
Placing several single buildings quickly without making a row of buildings can be difficult depending on the size of the building and the selected buildspacing.

6. Lag, single target and area commands
My feeling is that it is harder to make single target commands with the default mouse behavior and especially to place single buildings quickly when the framerate is low .

My initial to response to the problems mentioned in 1-3 have been this slightly more advanced widget. This widget will override area commands if the same unit is under the cursor both during mouse press and mouse release. This makes it much easier to target a specific unit while maintaining the full power of area commands.

One idea that I have is to make orders executed immediately on right mouse button press while left button works as described in the above mentioned widget. This makes single targeting with the default commands when you mouseover different units much easier to perform while maintaining the full power of area commands if you have selected a specific command. There is some ambiguity here as the timing will be a little different depending on if you have a command selected via hotkey or command menu or if you just hovered your mouse over a target without any command preselected.

Arguably, there are some commands that should always be executed on mouse button press like DGun regardless if you have selected it via hotkey or command menu but this ads some ambiguity.

For buildings I think it would be necessary to have some key that switches between making single buildings or several buildings with 1 click. Placing single buildings should be done on mouse button press then.


So do you think there is ambiguity in the mouse control scheme that decreases player control precision and makes it harder to target individual units?

If so, then what would you do about it?

Godde wrote: However there is some ambiguity when trying to perform an area attack as any unit that is under the mouse cursor during mouse button release will trigger a single target attack even if that is a friendly unit.

You know, it's possible to check if units is allied and only trigger attack for enemy units:
It could also make some sense maybe to filter out units that are not completed.

Other than that, yes I agree that there are issues with the user interface, but also a lot has been done to correct this and it's getting better. At least I I think that this is something that should have priority. But it's not so easy to make these decisions, as the there are many scenarios where if you make one decision that "this is probably what the user intends in this situation", it can instead have bad implications for another, similar, situation.

One such example that comes to mind is what default action you want associated with hovering the mouse over a feature with the commander selected. Usually you want the reclaim action to be the default, but not when there are enemies around and you are cloaked, because then accidentally ordering the commander to move where a tree is breaks the cloak. But if the default action is move then you always have to first select reclaim before (like in original TA), and that also gets tedious. I don't know how to best handle this situation: some kind of algorithm whether commander is in danger and then choose default command. It gets fast very complicated and the more you assume the more errors you will introduce into the code.

Another example are the numerous widgets that set commander to hold fire when cloaked, so as to not break cloak. But if enemy has radar coverage and fires at you, or sends a bunch of pw:s running after you, then you can assume the cloak is effectively broken and you would want the commander to fire at will (while possible running away). Also applies to cloaked commander that is about to be napped by atlas (the only way to escape napping is to walk away and let commander laser the atlas).

I think the only way to improve these areas is to discuss them and then improve the code. Most can be solved but it can be hard to know what we really want to happen in each situation.

To conclude I would like to point to some improvements that I have made regarding the interface. They are not directly related to the selection areas you listed but they are similar problems where users can get rated(frust) ™.

1. Show user he cannot load unit:



2. Show user he cannot attack target:



3. Show user the underwater building will not be completely underwater:



4. Show user he cannot D-Gun (no energy):

Jools wrote:

Godde wrote: However there is some ambiguity when trying to perform an area attack as any unit that is under the mouse cursor during mouse button release will trigger a single target attack even if that is a friendly unit.

You know, it's possible to check if units is allied and only trigger attack for enemy units:

Yeah, it is possible. However in those situations when you want to attack your own unit, it makes it harder to do so. Admittedly only a few mods allow your units to fire at allied units so it wouldn't matter in other mods.

Certainly all area commands should use cylinder.

Preferentially, the UI that draws this should highlight accepted targets while circle is being drawn, or even draw it as a cylinder where applicable (e.g. when flying units can be affected - possibly not needed e.g. for area reclaim).

It should be possible to do the graphical part game-side but unsure whether redefining command selection targeting in lua is really worthwhile.

Or maybe the selection could be done in screen coordinates instead of world coordinates. That's how CAD software does it.