Grid-based keybinding system

Grid-based keybinding system

Classic game design, maintained to please you...

Moderator: Content Developer

Post Reply
Ares
Balanced Annihilation Developer
Posts: 558
Joined: 19 Mar 2011, 13:43

Grid-based keybinding system

Post by Ares »

I enjoy using Beherith's great binds, however I often wonder if there is a more complete solution to the problem. Is it possible for every object on the build menu to be easily accessed while still microing elsewhere with your mouse? In the past when I have introduced SC players to BA this is the main feature they miss.

Both ideas are based off a grid system.

1. Arrange the build menu into 4*3 format (up to 6*3, but might need the menu along bottom of screen), each building is mapped onto a respective key on your keyboard. So as not to interrupt the attack, repair, fight hotkeys, the grid could lie with corners "t>,". Use o and l to jump selection box up/down 3 (or turn pages,) and voila mouse never needs to move from the action again.

2. No one likes to cut the build menu into small parts so for this solution simply rotate your keyboard sideways, now you have a crazy large 10*4 grid for every unit on the menu! :wink:

What are your opinions, is such a system feasable or desirable and would it work?
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Grid-based keybinding system

Post by Niobium »

Ares wrote:I enjoy using Beherith's great binds, however I often wonder if there is a more complete solution to the problem. Is it possible for every object on the build menu to be easily accessed while still microing elsewhere with your mouse?
The buildmenu is definitely a problem. While keybindings let you avoid the buildmenu entirely they don't solve it, and I think it needs solving.

Solving the buildmenu problem is extremely difficult though, and it's basically down to the sheer number of commands/buildoptions that are presented. Taking the commander as an example, the first unit someone new to the game would use, they need to be presented with the 5 toggleable states, the 12 executable commands (attack/reclaim/etc), and a ridiculous 25 different units they can build.

Ignoring the commands and just focusing on the number of buildings, I think a lot of progress could be made by simply removing the redundant ones and merging others. A quick look at the commander shows it's buildmenu could be reduced from 25 to 12 without any significant change to gameplay, allowing for an easy to display/use/keybind 4x3 grid.

The fact that the commanders buildmenu, arguably the most important constructor in the game, could have more than half its buildmenu stripped without too much effect just shows how unrefined BA is, especially in useability/UI.
Ares
Balanced Annihilation Developer
Posts: 558
Joined: 19 Mar 2011, 13:43

Re: Grid-based keybinding system

Post by Ares »

Just to avoid confusion, I have only been talking about a system for the structure building menu (the grid with the pictures). The command menu with attack/reclaim/repair/repeat is a separate puzzle, as you say, but the same principles could be applied.

I personally like the intuitive a = attack, r = reclaim, c = capture, etc system. Fortunately this logic can still remain, slotting into a grid system while still lining up with the appropriate key positions.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Grid-based keybinding system

Post by Beherith »

An issue I see off the bat is how will the commands be layed out when multiple unit types are selected?
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Grid-based keybinding system

Post by Anarchid »

How about this:

Generic commands and build options go into separate widgets.

The actual commands get assigned logical/mnemonic buttons (a for attack, f for fight, v for vendetta).

Build options get assigned modifier+grid, like ctrl+qwerty-asdfg-zxcvb, or something like that. Since most pplz play spring from their hightower, maybe use numpad if it's available.

Also, here's a novel idea: all of this should be visible for the user on the actual interface (i.e, colored hotkey text under each icon, with different colors for build options and real orders) :P
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Grid-based keybinding system

Post by Niobium »

Beherith wrote:An issue I see off the bat is how will the commands be layed out when multiple unit types are selected?
- Show build commands for only one of the constructor types at a time, allow cycling through them (ideally with a nice shortcut key like tab). (This is how starcraft does it, works well)
- Tab between the varying tech levels (T2/T3 aren't likely to be needed in a hurry, so the extra difficulty of tabs isn't too bad)
- Go for a more 'fixed'/'selection-independant' system, where all buildoptions are shown in some way, and sections enable/disable based on what constructors you have selected.

I like option 1 personally, the concept of an active unit type would also translate nicely to the display of commands/states, which also grow in number as you select more units. I think it's pretty silly to attempt to try display all of them, especially when the mix/count can vary a lot.
Ares
Balanced Annihilation Developer
Posts: 558
Joined: 19 Mar 2011, 13:43

Re: Grid-based keybinding system

Post by Ares »

Beherith wrote:An issue I see off the bat is how will the commands be layed out when multiple unit types are selected?
The current system of deciding what gets displayed in the building and commands menu is good overall, doesn't seem in need of changing. A grid system would simply use what already exists, repositioned.

With multiple constructors selected lowest tech builder menu takes priority, followed by subsequent levels. Also builders take priority over factories when displaying build options.

I'd rather see highest tech take priority, as in general if I select a group with a t3 bot in, its normally because I want them all to work on a t3 project together (like a fusion or extractors).

As for mixtures of combat units and command, I think all the generic attack, patrol etc commands fit perfectly onto the 12 keys from "q>v" already. Gridding them to match what you see in your onscreen simply makes the mental link between the keyboard and on-screen menu more intuitive.

For example the 2nd row keys asdf for grid based could be: a - attack, s - stop, d - defend (guard), f - fight. I wouldn't include top row commands such as repeat on, hold fire, roam in the grid - as fast access to such commands isn't so essential. \ could be used to cycle the menu selector down another 3 blocks at a time, eventually looping back round to the original block.

Example of grid in sc2, applies to building and units
http://starcraft2guidepro.com/wp-conten ... idmain.jpg
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Grid-based keybinding system

Post by Pxtl »

Try Zero-K's radial buildmenu. That wouldn't work perfectly with BA, since the radial buildmenu is based on the fact that all the builders in ZK have the same build-list (except for the combat engineer)... but still, it gives you an approach for a simple, geometric keyboard-driven build-selection system.
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Grid-based keybinding system

Post by CarRepairer »

Pxtl wrote:Try Zero-K's radial buildmenu. That wouldn't work perfectly with BA, since the radial buildmenu is based on the fact that all the builders in ZK have the same build-list (except for the combat engineer)... but still, it gives you an approach for a simple, geometric keyboard-driven build-selection system.
Actually it's taken into account. Every time you tap D it cycles to the next builder type in your selection.

It's a three click or three key building system (derived from the gesture menu). Press D (or click the center button) to initiate the radial buildmenu, then tapping a surrounding key WERSFXCV (or click the buttons) to get to a category, then finally one of the WERSFXCV to get one of the units. That's a total of 8x8=64 units per builder that can be built. No keybinds are occupied except for the initial D key. Mex is D,E,E, solar is D,E,S.

Obviously BA would need a non-chili equivalent and a different initial key from D. S is ideal except that it's used for stop, so I went with D.
Post Reply

Return to “Balanced Annihilation”