As I said in another thread:
I think such a chat-tree system would be infinitely more useful than an integrated voice comms, as well as simpler to create and keep functional. Attempting to integrate another, already existing software runs the risk of compatibility and updating issues, and developing an entirely new comms system for I:B would be additional development strain, as well as requiring additional bandwidth and server hosting issues.
The idea is, in itself fairly simple: in WoT, you hold down one key to bring up the menu, then use your mouse to hover over the selection you want. It can have different effects, based on whether you are aiming at friend, foe, or nothing at all, as well as being customizable through mods to say something entirely new. While effective, I feel this may impede use during periods of action as it will disrupt mouse and potentially keyboard use, or if using HOTAS/controller, may disrupt everything all at once. Paragon and Rocket League both use a slightly different system, where you push one key to bring up the menu and then use a series of up/down/left/right to navigate the menus to get to the broadcast you want. This has benefits to allowing continued use of one hand while using the other to navigate the menus, but requires some degree of memorization (or macros) to quickly get messages out in a timely manner.
I’d prefer a system closer to Paragon and Rocket League’s, but with further customization on what keys do what. I could, for instance, have one key bring up the quick-chat menu, and then have every key on the keyboard assigned to a different phrase, as well as one key for going to the next menu, or have a more Paragon-esque style where you use just a few keys to navigate through several layers of menu to get to just a couple options, leaving the rest of my keyboard open for use during that time. Having some sort of customizable-tree file/menu option would make this easiest to allow players to develop for their own tastes. Here is something of how I imagine such a file looking like, although it is very much a pseudo-code mockup:
The list is by no means exhaustive, but the game would assume any option that does not have a sub-category is an actual command instead of a sub-menu. The bracketed numbers would be the hotkey assigned to that option: to call out “Attack!” I’d press 1 -> 2 -> 5. “Gather at the base!” would be 2 -> 1 -> 2.
Additionally, I think there should be basic phrases translated into all the languages offered by the game normally. This would allow players to quickly say things like “Help!” or “Attack [Current_Target]!” or “Retreat!” in all the languages people play the game in normally, reducing confusion across the language barrier.
As goes my opinion with most game features, I hope this system would also have a “Friend/Priority” and “Ignore” feature. Such an implement would allow you to block certain users’ quick chats from showing up on your screen (spammer, suspect players, etc.) while highlighting those you have designated as “Friend” or “Priority” to separate them from the rest. If the system is intuitive and simple enough to add/delete from, you could even have the ability to create multiple lists and activate/deactivate them at will, allowing players to “Ignore All” and “Priority [Players_In_Group]” giving players the ability to form command structures on their own. I imagine something like a Platoon_Leader could have only the Squad_Leaders active, and Squad_Leaders would just have the Platoon_Leader and their Squad_Members active, etc.
Preferably, there would be a HUD implement to go along with the quick commands, with different colors possible for (at a minimum) general chats vs priority chats. Some sort of marker for [Current_Target] commands on the target, or just a marker on the speaker for non-targeted commands.
Finally, there are several implements to prevent spamming/reduce sensory overload. For one, you can prevent players from activating quick-chats more than once every [X] seconds. Two, you can create a sort of “proximity” priority tree with non-custom commands: a request to “Attack [Current_Target]” does not need to be broadcast more than [X] km away from the originator, while a “Gather at [Current_Target]” would maybe be system-wide. Three, the previously mentioned “Priority” and “Ignore” functions could be used to filter through the noise. Four, HUD implements could be enabled/disabled/customized to increase or decrease their impact on the player (for instance, I may make the general chats nearly transparent, while making priority chats opaque).
