..:: New GUI Design - in progress ::..
Moderator: Moderators
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Ice, uses will vary.
I think the best way is to just have a few games yourself, and note which buttons you use the most, and which you neglect for hotkeys.
Mostly, anything that has a straight forward hotkey, with a single keypush, I will use over the UI. Only things which I need to see visually (building, move orders, etc), will I use the UI for.
I think the best way is to just have a few games yourself, and note which buttons you use the most, and which you neglect for hotkeys.
Mostly, anything that has a straight forward hotkey, with a single keypush, I will use over the UI. Only things which I need to see visually (building, move orders, etc), will I use the UI for.
Yes you are right.
I have this book about ui design, and actually though its quite thick, the final statement of it all is testing.. and resulting in getting the best ui.
i'll place the ai thing to the switches menu, so i can close the patrol/guard/move thing myself (because im a hotkey fanatic, in most games i have like 4 times as much keypresses as every other player)
later!
I have this book about ui design, and actually though its quite thick, the final statement of it all is testing.. and resulting in getting the best ui.
i'll place the ai thing to the switches menu, so i can close the patrol/guard/move thing myself (because im a hotkey fanatic, in most games i have like 4 times as much keypresses as every other player)

later!
Note one_s_. youll activate all you want. Well tabs may be a bad word.. More like checkboxes.Erom wrote:What if you want to see all of them?Comp1337 wrote:Tabs on the chat window would be ubercool. For example one tab for systemmessages, one for AI warnings, one for unitresponses, one for chat.
Activate the ones you wanna see.
I had invisioned them looking like tabs.
regardless of visual representation, some kind of toggle ideally...Comp1337 wrote:Note one_s_. youll activate all you want. Well tabs may be a bad word.. More like checkboxes.Erom wrote:What if you want to see all of them?Comp1337 wrote:Tabs on the chat window would be ubercool. For example one tab for systemmessages, one for AI warnings, one for unitresponses, one for chat.
Activate the ones you wanna see.
I had invisioned them looking like tabs.
-
- Posts: 13
- Joined: 23 Dec 2004, 05:13
For starters, trying to balance an rts through the gui is a BAD bad blizzard like idea. you shouldn't be impairing a player simply because you've been lazy on the GUI, even if everyone has to play with it (and because spring is modable not everyone has to play with it...).
Knorke made a very good point with the holding down of keys, unless you take one of the bucky keys away to implement the temporary selection it's not a feasible option. If you were to do it the alt key would be the least missed as at the moment alt only allows you to center screen on a hotkey group. That function is already overlapped by the t 'track' key in TA so the net loss would be quite minor.
With build priority, units won't be able to build any faster than their build times, so if you are metal stalling it's not going to give you any more metal to play with. It will however mean that you do not need to micro units to stop building just so you can get the higher priority structures built quicker. Microing for microings sake is never the way to go, even if ota did it like that.
With the priorities, only the things being built will have a priority, builders will have a priority setting only to initialise the buildings they are constructing with a priority. I'm not sure if you've implemented seeing the available construction options from all selected builders yet but if you have a situation like that it should use the highest priority of the builders. Colour coding the priorities would be a good idea.
The idea of selection channels is to implement fast semi permanent groups, it's not to compete with groups, but at the same time groups don't fufill the channels functionality. associating a unit type with channels would work but i was thinking of keeping them completely open in that regards. Issues of people forgetting that they can't select a unit because they aren't on the right channel would arise.
The system should allow selection of a unit no matter what channel you are on, and it's also meant to be an optional part of the interface so if you are a newb and don't want to have to deal with channels you don't have to. If unit type selection was involved then channel usage would be mandatory.
Perhaps if the channels system was integrated with the hotkeying map locations system would increase it's worth. Instead of needing to specifically save a spot to a function key that location remains with the hot key so if you switch channels your screen will move to the other channels location. The only issue I see with this is switching channels to grab a group of units then trying to go back in order to move them to the first channels location by reselecting that channel, you would loose your selection.
An idea i've had that might solve this is proximity move orders. Traditionally if you tell a unit to go somewhere precision isn't important, you just need them in the area, but you are forced to point the exact location on the map you want them. My idea is to make alternate methods for assigning move orders that are slightly faster (at the cost of accuracy). If you want them to move to the current location on screen tap the move button or the move hotkey twice quickly. if you want them to move to a location on another channel screen tap the move button or hotkey and then the channels button. The computer will queue a move co-ordinate at the center of the selected screen (doesn't matter if it isn't valid, you could order land units over water by mouse anyway).
The issue of trying to select only units of type x is a tricky one to solve. if you've got a bunch of aircraft doing figure 8's over your base and you only want to select them how do you do it? box selection and targeted deselection is so old fashioned so we need to do something about it. Infact i would say it's of higher priority than my channel selections idea, my only suggestion to solve it is to implement context menu's through either a right or middle mouse button click or the context menu button on the keyboard, and via that menu you can alter the current selection by clicking on the types you don't want to keep (leaving the ones you do) then pressing the context menu button again to confirm and cull the selection.
Display message breakdown is a good idea but perhaps instead of tabbing to select a different type, you toggle whether you want to see that type of message, so you could turn off system or server messages but keep unit response and unit event messages. But such a system is useless unless you know which peewee has issued the event so how about some sort of mechanism to select them or go to them or bring up some small unit report panel which formats itself based on what type of unit is being selected.
Just to those who think it's getting a little complex, people will always be able to rise up to using a complex interface, sure initially it's busy and overwhelming but eventually they will use it and then crave more from it. As long as it's not complexity for complexities sake then it's hard to go wrong. Everything that is essential and awesome for an rts has already been implemented, anything we think of now is simply trying to refine it further. So contrasted against the essentials, all our ideas will seem puny, but that won't negate their usefulness or impact on the game.
Well I think I'm done until next time, enjoy.
Knorke made a very good point with the holding down of keys, unless you take one of the bucky keys away to implement the temporary selection it's not a feasible option. If you were to do it the alt key would be the least missed as at the moment alt only allows you to center screen on a hotkey group. That function is already overlapped by the t 'track' key in TA so the net loss would be quite minor.
With build priority, units won't be able to build any faster than their build times, so if you are metal stalling it's not going to give you any more metal to play with. It will however mean that you do not need to micro units to stop building just so you can get the higher priority structures built quicker. Microing for microings sake is never the way to go, even if ota did it like that.
With the priorities, only the things being built will have a priority, builders will have a priority setting only to initialise the buildings they are constructing with a priority. I'm not sure if you've implemented seeing the available construction options from all selected builders yet but if you have a situation like that it should use the highest priority of the builders. Colour coding the priorities would be a good idea.
The idea of selection channels is to implement fast semi permanent groups, it's not to compete with groups, but at the same time groups don't fufill the channels functionality. associating a unit type with channels would work but i was thinking of keeping them completely open in that regards. Issues of people forgetting that they can't select a unit because they aren't on the right channel would arise.
The system should allow selection of a unit no matter what channel you are on, and it's also meant to be an optional part of the interface so if you are a newb and don't want to have to deal with channels you don't have to. If unit type selection was involved then channel usage would be mandatory.
Perhaps if the channels system was integrated with the hotkeying map locations system would increase it's worth. Instead of needing to specifically save a spot to a function key that location remains with the hot key so if you switch channels your screen will move to the other channels location. The only issue I see with this is switching channels to grab a group of units then trying to go back in order to move them to the first channels location by reselecting that channel, you would loose your selection.
An idea i've had that might solve this is proximity move orders. Traditionally if you tell a unit to go somewhere precision isn't important, you just need them in the area, but you are forced to point the exact location on the map you want them. My idea is to make alternate methods for assigning move orders that are slightly faster (at the cost of accuracy). If you want them to move to the current location on screen tap the move button or the move hotkey twice quickly. if you want them to move to a location on another channel screen tap the move button or hotkey and then the channels button. The computer will queue a move co-ordinate at the center of the selected screen (doesn't matter if it isn't valid, you could order land units over water by mouse anyway).
The issue of trying to select only units of type x is a tricky one to solve. if you've got a bunch of aircraft doing figure 8's over your base and you only want to select them how do you do it? box selection and targeted deselection is so old fashioned so we need to do something about it. Infact i would say it's of higher priority than my channel selections idea, my only suggestion to solve it is to implement context menu's through either a right or middle mouse button click or the context menu button on the keyboard, and via that menu you can alter the current selection by clicking on the types you don't want to keep (leaving the ones you do) then pressing the context menu button again to confirm and cull the selection.
Display message breakdown is a good idea but perhaps instead of tabbing to select a different type, you toggle whether you want to see that type of message, so you could turn off system or server messages but keep unit response and unit event messages. But such a system is useless unless you know which peewee has issued the event so how about some sort of mechanism to select them or go to them or bring up some small unit report panel which formats itself based on what type of unit is being selected.
Just to those who think it's getting a little complex, people will always be able to rise up to using a complex interface, sure initially it's busy and overwhelming but eventually they will use it and then crave more from it. As long as it's not complexity for complexities sake then it's hard to go wrong. Everything that is essential and awesome for an rts has already been implemented, anything we think of now is simply trying to refine it further. So contrasted against the essentials, all our ideas will seem puny, but that won't negate their usefulness or impact on the game.
Well I think I'm done until next time, enjoy.
An idea i've had that might solve this is proximity move orders. Traditionally if you tell a unit to go somewhere precision isn't important, you just need them in the area, but you are forced to point the exact location on the map you want them. My idea is to make alternate methods for assigning move orders that are slightly faster (at the cost of accuracy). If you want them to move to the current location on screen tap the move button or the move hotkey twice quickly. if you want them to move to a location on another channel screen tap the move button or hotkey and then the channels button. The computer will queue a move co-ordinate at the center of the selected screen (doesn't matter if it isn't valid, you could order land units over water by mouse anyway).
Sounds awfully like waypoints...
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
in this case yes indeed.
But i so dislike the trouble of uploading to some server, if i have my own private one, that is better configable, faster and easier in use.
Mofo hoster didn't even give notice of its bankruptcy, so i only have a backup of 2 months back.. Grmnbll. f*ckers.
hopefully back online within 2 weeks (on a even faster server :) )
But i so dislike the trouble of uploading to some server, if i have my own private one, that is better configable, faster and easier in use.
Mofo hoster didn't even give notice of its bankruptcy, so i only have a backup of 2 months back.. Grmnbll. f*ckers.
hopefully back online within 2 weeks (on a even faster server :) )
- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
I'm sorry, but I just think that this sounds too complicated. Becides, this really isn't just about the GUI. This is about making a big change to the game engien.DopeFishhh wrote:With the priorities, only the things being built will have a priority, builders will have a priority setting only to initialise the buildings they are constructing with a priority. I'm not sure if you've implemented seeing the available construction options from all selected builders yet but if you have a situation like that it should use the highest priority of the builders. Colour coding the priorities would be a good idea.
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
-
- Posts: 13
- Joined: 23 Dec 2004, 05:13
patmo98, complicated for who? the user? they don't have to use it at all, the default settings will play entirely like ta. For programmers? hardly they've overcome far bigger challenges already, i'd hardly think something like an already well described/defined build priority system would stop them.
Either way there are huge changes happening to the engine already, they are integrating lua (huge change no?) so this would merely be somethign that could be slotted in when things get ported over to lua. and we've already heard evidence that not needing to micro builders is a good thing. the only thing holding it back is it's rank in the list of things that need to be done (yes there are more important things at this point).
If my explanation was hard to understand i'll try again:
only things being built will use a priority setting, if it's already built a priority setting is quite useless no? so what is the default priority setting?
If we default everything to normal it would work but it would force the player to change the priority to high or low every time. In the case of a factory pumping out critical defense units that would be very annoying as you need to babysit it and whole priority system would have changed nothing. In the case of say a con vehicle building important mex's again the player would be forced to keep checking on it.
So instead if we tell a builder to set the priority of everything it builds to a specific priority then those units will automatically get high priority thus aleviating the amount of babysitting needed to be done.
In the case of multiple builders being ordered to work on something, if one of the builders has a higher priority than others then odds are you are or have been building important things with him. And if you are getting multiple builders onto something odds are it's a priority structure anyway so defaulting to the highest priority among the builders makes sense.
Hope that clears things up.
Either way there are huge changes happening to the engine already, they are integrating lua (huge change no?) so this would merely be somethign that could be slotted in when things get ported over to lua. and we've already heard evidence that not needing to micro builders is a good thing. the only thing holding it back is it's rank in the list of things that need to be done (yes there are more important things at this point).
If my explanation was hard to understand i'll try again:
only things being built will use a priority setting, if it's already built a priority setting is quite useless no? so what is the default priority setting?
If we default everything to normal it would work but it would force the player to change the priority to high or low every time. In the case of a factory pumping out critical defense units that would be very annoying as you need to babysit it and whole priority system would have changed nothing. In the case of say a con vehicle building important mex's again the player would be forced to keep checking on it.
So instead if we tell a builder to set the priority of everything it builds to a specific priority then those units will automatically get high priority thus aleviating the amount of babysitting needed to be done.
In the case of multiple builders being ordered to work on something, if one of the builders has a higher priority than others then odds are you are or have been building important things with him. And if you are getting multiple builders onto something odds are it's a priority structure anyway so defaulting to the highest priority among the builders makes sense.
Hope that clears things up.