I forgot to add that I too hate having to "babysit" units because they are too stupid to know what''s good for them. That''s why I call RTS''s today, Micromanagers or click fests. There''s really very little strategy involved, since as Sandman pointed out, it becomes REACTING and not acting.

Now, a part of good strategy is forcing your opponent to react to your moves, but that''s not the case with RTS''s. They just require too much hand-holding to implement more sophisticated strategies.

I think one thing that can be done other than a pre-planning turn phase, is to REALLY slow down the pacing of the real-time, ala Starfleet Command. If units move very slowly, then it will give you more time to think about what needs to be done, and you won''t miss a group you created that you had PLANNED on assualting with, but forgot because a base of yours came under attack.

Some ideas (that would take up lots of power to run, but this seems to be a wishlist, so here''s to the future!):

Visibility: 2 Screens that can be toggled between one another. One is you basic every single RTS screen; the other toggles to a fullscreen map for quick survellience of the entire map. The coolest part of the idea...if you have mad haxor skills, give the game an option to run these screens on dual monitors with a keyboard toggle interface between the two, for those hardcore gamers running multiple video cards and/or monitors. But definitely keep a single monitor option available to toggle between the two.

Um, about reacting...yes, I hate some aspects. I think that all aspects of the game that do not directly involve attacking or defending enemies should be handled once it is set in motion, i.e. less lame peasant management.

--OctDev

The Command and Conquer games (and doubtless many others which I have been too deprived to experience) let you assign units to a quick-key, so that you could quickly jump between about 8 different places on the map. This kind of thing can help with the player''s visibility, especially if you can place these viewpoints in locations rather than just on units, and perhaps have a row of tabs (like the Windows taskbar) along the top or bottom of the screen to flip easily between them. It should be really easy to implement: basically, you just store 8 (or more) sets of x,y camera coordinates rather than 1 set, and another variable to keep track of what the current view is. So there''s little reason why all games can''t support this.

Kylotan

Even with hot keys, it''s very diffucult to launch coordinated attacks. And it still means that you can only have one group do as you want at a time. It''s still sort of a "mob" ordering. I want more fine control than that, plus the ability to order groups of groups to different tasks...all simultaneously.

I think the only way to have this level of control is through a pre-plan phase, or issuing order to AI commanders, who in turn order their subordinates. And the only way to do this is to give all the AI leaders a set of guidelines, parameters and protocols if you will, on how to go about their orders. I just wish there was more I in AI. I''m definitely not a strong enough programmer to help out in that respect....

I agree with Dauntless: hotkeys are nothing new, and they simply arent enough. I find myself clustering 4 - 5 large groups of similar units together and using the hotkeys to coordinate them - but there is still a lot of babysitting involved. Some units move faster than others for example (it would be nice to be able to group different units and have them move at the pace of the slowest - this would save a lot of babysitting IMHO, since you could be sure that they all arrived at the same time, instead of turning up in dribs and drabs and getting annihilated by the enemy.

I think view distance is very important. I think units need longer lines of sight, and as already mentioned, they need to let you know when they have spotted the enemy. You would then have time to respond to the potential attack. I like the idea of variable visibility of units - it is more realitic to make visibility an attribute of the thing you are looking at rather than the thing that is doing the looking. There would also be a distinct advantage to attacking an opponent with a small group of infantry rather than a tank rush: the swarm of tanks would be spotted a mile off, and bombarded into oblivion before they even got close. The infantry on the other hand, could sneak up close and do their damage before you can react. The time it takes them to get to you would be your planning phase (this is how it worked in shogun - you could see your opponents miles off, you has a few minutes to order your troops and prepare for the battle).

I am still worried about UI complexity though. On the one hand, it is difficult or impossible to manage complex strategies with the one click interface we have now. But if the interface were more complex, would the player be struggling to cope with it all?

SANDMAN:

For ''medieval'' rts games, I think the interface should be based on the old ''flag'' system. Generals used flags to signal orders to their troops.

I think that would be an excellent way to design an interface: give the player the ability to preconstruct orders and then have those assigned to hotkeys. The smarter the player''s troops are, the more commands they will be able to understand. The more commands they''re able to understand, the more flexibility you have as a general in your combat strategy.

I think there are two ways to tackle the questions posed in this thread:

1) How do we deal with these issues in games that would work much like existing games?

2) How would we design completely new types of games using the perfect answers we find?

Should we aim for both?

Units doing two things at once has already been done, in sudden strike (ww2 rts). If ur units retreat the tanks will still fire while rolling away. or it miht be in sudden strike forever (expansion pack) one of those,

Later

I guarantee you I can design (although not yet execute) an excellent set of UI interfaces for multiple different control styles. If you dig around under my profile you will see what many of my ideas are, and a majority of them do focus on the UI (because there''s never enough friggin detail for me!).

Yes, the devil is in the details, like layout, visibility, accesibility, and so forth.

Pathing - Done. Objectivizing - Done. In-game data management w/prioritizing - Done.

--------------
-WarMage
...the impossible problems I solve right away, Miracles take a few minutes.

Another game that has some good RTS ideas, even though it isn''t itself an RTS, is Ogre Battle 64.

First of all, visiblity was not an issue, as it was assumed that, since the battlegrounds were not unexplored territory, the player''s forces would already know the layout of the map. (Although in the original Ogre Battle, there were also places that were hidden, so that you would actually have to look for them.) Enemy groups aren''t shown on the map unless they are in the field of view of one of your units. Most units could see enemy units from quite a distance in front of them, but had limited viewing range behind, although flying units had larger fields of view that went the same distance in all directions, making flying units quite useful as scouts.

As for marching orders, you basically told a unit to go to a specific place, and had the option of making them go straight there, or having them seek out or avoid any enemy units they encountered. You could also command a unit to seek and destroy a specific enemy unit, though they would stop if they were unable to see the target for some time. A stationary unit could be ordered to hold it''s ground, attack approaching enemies, or flee if enemies drew near.

And best of all, the player could essentially pause the game when scrolling around the map or giving orders.

When you think about it, goups of units are given orders, not individual units. Plus, a group of units will carry those orders within different paramters as I suggested from my examples above.

In tabletop wargaming, it''s very common to have different unit orders such as "Hold, fire, Move, Conditional Move, Conditional Fire, Rally, Reorganize, Form....etc". I don''t see why this can''t be done in an RTS.

What I really think needs to be done though is have group variables defined by the orders on which they are given. The most fundamental would be an aggression/caution variable which would dictate how committed to an offense the unit would be. Initiative would be another primary stat, and would determine if the unit would attack a unit of opportunity (i.e. fire at will, fire only in defense, fire only by command, fire only if superior, etc.). Another variable would be pathfinding...the higher the stat the more likely the unit will attempt to find a different path to its objective otherwise it will wait for direct command. Motivation is a little hard to describe, and it''s partially covered by aggression, but it basically covers how willing a unit is to suffer losses. It''s therefore possible to have a high aggression low motivation ordered unit which will make a hard strike at first, then pull out as soon as it takes casualties.

so you could have something like this...

class Orders
{
public
RetrieveOrder( ); /*accessor function for unit object to retrieve order settings (through a virtual function to an array??)*/
InvokeSettings(int, enum, int, int); /* this is important and will be called on alot. It''s how the officer "orders" the unit*/
private
int Agression;
enum Initiative;
int Pathfinding;
int Motivation;
};


So going back to my order list and variables set from 1-10. I''m assuming I''d probably have to set up pointers to these objects on the heap, so you''d do a New Order = SearchDestory, or better yet:

order * pOrder = SearchDestroy

pOrder->SearchDestroy.
Agression = 8, Initiative = "fire at will" (I''d set this up as an ENUM constant), Pathfinding = 7, Motivation = 5

pOrder->Recon.
Agression = 3, Initiative = "fire only at command", Pathfinding = 10, Motivation = 2

And so on and so forth. Here I think is what I''d do with this order class. And the more I think about it, the more I think it should be an array instead. Why? Think about the officers. You the player will access your unit groups via your sub-officers. You pass these "order objects" to your commanders who can call them with the RetrieveOrder function and he in turn passes this as an array to the unit groups that use this array as parameters for their AI behavior.

My programming is very limited, so if anyone here sees flaws in my logic, please point them out to me. Hopefully though you get the idea. You have an order class which in turn would get turned into an array somewhere on the freetore. You pass this order object to your AI commanders who then issue the orders to your unit groupings. I can see you asking why bother with the indirection of going through your sub-commanders instead of ordering the troops directly?

Partially out of realism. In RL, the general doesn''t order squads what to do. Also, it adds a very real possibility to strategy gaming....keeping your officers alive. When an officer gets taken out, how do you pass on orders? Obviously, chain of command gets re-established, but it takes awhile, and during this point, the enemy can seize the initiative.