Daddio, I am posting my answers here until I can get into the other forum. Query 1 - Feasibility?
"It is hard to believe that it is feasible in practice."
Answer 1
The question of whether such a game is feasible falls into two distinct areas. Firstly, is it technically feasible? Secondly, is it feasible as a playable game? (This leaves out any consideration of commercial feasibility at this point.)
As to technical feasibility, yes it is feasible. Let us compare it to OC Mod Cossacks based on Cossacks BTW released in 2002. This is an engine with 3d terrain and 2d sprites. OC Mod can handle two players with up to 6,400 units each. Admittedly, it often crashes at about this limit. This is with a game engine built around year 2000 and run on a 2004 machine. A new game with 64,000 units per player for four players is 20 times that size. The growth in desktop processing power from 2004 to 2011 has been of the order of 100 times improvement. The wider extent of maps and increased unit number requirements will increase overall data array requirements (HD and RAM load) but will not necessarily increase graphics demand too significantly. There is only so much of the battlefield that can be meaningfully shown in a tactical view on screen. Therefore graphical display requirements do not grow as fast as map size and army size increments.
Whether it is feasible as a playable game will depend on the success of the two speed time engine and the success of the Command Model (how you command the troops). Stated design goals are realistic time and space scales, realistic military action and realistic interactions with the environment. Thus the design layers to begin with are the environment and the military. Furthermore, the layering method of design (building up layers of design) suggests we start testing our assumptions with the simplest environment possible. Consistent with our goal of realistic scaling this should be a rendition of a flat plain scaled to represent 10,000 metres by 10,000 metres of ground.
I would advocate the creation of an initial experimental engine at low cost. The test engine would require a landscape with no or few terrain features (a flat plain), an editor capacity to place several musket formations (battalion size or about 1,200 men with 120 per company in ten companies) for each side and suitable basic graphics and mechanics for simple musket formation engagements at distance (ignore cold steel engagements for the initial trials). In addition, the experimental engine must contain first cuts of the strategic and tactical components and interfaces of the two-speed time management engine. The idea would be that developers (or testers) could trial traversing and manoeuvring musket formations (shown as symbols) in the strategic time display (at the 60x time speed) until engagement range was achieved. Then they could fight tactical engagements, continue these engagements and/or seek to disengage (separately and jointly) and see how the trial engine handled it.
Just as importantly, they would be seeing how they handled it as players. That is they would be assessing the playability and subjective feel of such a game design. Such trials should be made both without and with a realistic fog of war. A realistic (as opposed to stylistic) implementation of the fog of war needs to be investigated.
Query 2 - What is a Significant Force?
"What is a militarily significant force?
Answer 2
I would advocate testing the basic test engine with 5% of total forces set as the parameter for a militarily significant force. A further proviso would be that both sides would need at least 5% of their forces present for the parameter to be satisfied. For example, if both sides have 10,000 troops each then at least 500 troops from each side must be in engagement range for the engine to switch to tactical time. Otherwise, the engine would decide the engagement automatically in strategic time in the fog of war. Many problems (and their possible solutions) will probably be discovered whilst testing militarily significant force parameters, engagement range definitions and so on.
The 5% might not be the right setting. It might turn out that 2.5% is better or some other percentage is better. This stage of testing the two speed time engine, the militarily significant force parameters and the engagement range definitions, might well be the place where the whole project succeeds or fails. Creative solutions to practical playing problems (discovered at this point) will have to be found. The two-speed time engine idea is bold and innovative and only practical model testing will tell us whether it can be made to work or not.
The algorithm to determine strategic time / tactical time switches might have to be quite sophisticated and might even have to use fuzzy logic so that it is not too predictable. It might, for example, be that 2.5% of forces from each side in one engagement range area could be set to be enough to cause the switch. But it might be that 5% of forces from each side are required to cause the switch when there are several small skirmishes of say 1% force size each happening at several widely separated engagement range sites. It might be that cavalry will require special treatment by the algorithm as the act of galloping them in and out of engagement range (accidently or deliberately) could cause the engine to flip back and forth between strategic and tactical modes. Some players may even "game" the engine in this way to make it keep flipping modes. Testers should certainly do things like this to try to break the test engine or to make the test game unplayable. Designers and programmers must then search for answers to these problems. It might be that the engine requires a mandatory delay once it has changed modes. This mandatory delay might be different depending on which way the time engine has just changed.
Query 3 - What is the Command Model?
"How could a human player really control 64 thousand troops total within his army?"
"What about player actions? He proposes a game with as little mouse clicks as possible - 12 command clicks per minute. Are we to just issue commands to battalions and regiments and let formations decide when to fire at the enemy, when to mount cavalry attacks, what formation to use?"
"As I can understand his proposition, he wants to use more complex army organisation, where formations will be allowed to make some tactical decisions and it will not need to issue so many commands by players."
Answer 3
General Comments First.
There is absolutely no excuse in this day and age for negative factors like poor AI, poor path finding, poor formation handling and permitting outright stupidity in autonomous unit actions. When poor formation options, poor formation handling and stupid unit decisions (when they act autonomously as singles or in formations) are inflicted on the player by the game design, despite the player’s best efforts, then this might merely indicate poor algorithms. It might also go deeper and indicate a lack of thought by the designers about a key concept. This key concept we might term the “User Control" design.
Before we design a user interface and user command functions we must develop a very comprehensive User Control design "philosophy" and then build a model to implement it. We must ask some key questions. Where is the player or user going to be placed on the spectrum that slides from total manual tactical command of every tiny action to the issuing of the broadest strategic commands only? Will the player be placed statically or allowed to move up and down this control spectrum? Will the player’s movement up and down this spectrum be player managed, game engine managed or both (in some form)? Will all of this be managed “in-game” or will we give the player some ability to further tailor control settings to his preferred playing style in a game utility before live games? Such a utility could enable the setting of preferred defaults, preferred target orders, preferred formations and so on for different units; a kind of standing orders system in fact. A player could even be permitted to design his own formation types and corps system.
A proper approach to integrated design recognizes the fact that integrated design is only as good as its weakest link. Let us look at a very appropriate example and relate it back to the User Control design philosophy. AI is Artificial Intelligence (so-called) which in this context means how the computer plays the game against a human opponent. However, in an integrated design the AI does much more than just manage how the computer plays against a human opponent. It will also manage all the human player's nation's automatic actions within the User Control Module according to the standing orders and unit autonomous behaviour rules laid out in the User Control Design.
That is to say when the combination of engine determined settings and user determined settings taken together indicate that a tactical action is to be engine controlled then it will be engine controlled by the AI to the appropriate level of “intelligence”. Designed properly, this will do away with autonomously or semi-autonomously acting units belonging to the human player doing excessively stupid things that the human would never do if he/she was watching and managing every unit all the time. This stupidity moreover is something which computer AI often does not inflict upon itself or which the computer AI instantly recovers from on its own behalf because it can “micro” so well. The most common example of autonomous unit stupidity affecting the human player is when units (who have not been expressly told to hold position) always seem to want to run into danger to engage an enemy even when it is clearly suicidal to do so. This is unrealistic.
These control issues affect both player versus player and player versus AI games and become more and more important as unit numbers climb. As unit numbers rise, the game becomes less tactical and more strategic. As unit numbers rise, the actions we can reasonably expect the human player to ‘‘micro” (as a percentage of total human player nation actions) must necessarily decline. For all these reasons, the quality of the AI module and the concept design of the User Control Philosophy are interwoven. Similar arguments can be employed to show that path finding, flocking, swarming, formation movement algorithms and so on must all be of the highest order and all integrated into the AI module. From thence they are available to the computer for computer play and partially available to the human (mediated through engine control and user control decisions) to handle that level of ‘microing’ which the human never handles or handles progressively less of as unit levels climb.
Specific Comments
Large unit games are not difficult to control if the User Control Module is designed properly. First though, let us recognise that large unit RTS still starts with small initial numbers. This is the nature of RTS. Therefore when the unit numbers are small it is appropriate that the user micro many individual construction and tactical actions. In fact, if we did not put this load on the player early on, then players who like to be busy will find the early phases slow and boring. My first idea of 12 clicks a minute is probably wrong on this assessment. Perhaps 60 clicks or commands per minute (one per second) is about right. A game "governed" to this rate will be fair for all players at standard internet lag intervals; typically 250ms to 500 ms but sometimes as bad as 800 ms.
Thus, the game would begin with relatively high individual micro requirements. Even then, high micro requirements do not mean, for example, that you do several keystrokes to make each soldier reload his musket. This obviously absurd example is given to highlight the fact that the engine always does some micro for the player even in high micro games. The key idea is to have a sliding micro requirement as outlined in my general comments. Players of Cossacks would be aware that once you create a formation of 120 men, a company, you can essentially micro those 120 men with one command. This illustrates how large unit games are micro-ed and it is essentially the first part of a sliding micro requirement system. The next step will be to place companies in battalions, battalions into regiments and so on. Command options (issuing orders) at each level will be appropriate to the size and organisation of the body of men being ordered.
Your questions, about micro-control and allowing formations to make some tactical decisions, have indeed made me think further. You might order a battalion to take a particular objective by a particular method (e.g. "full frontal bayonet charge, in column, two companies wide, five companies deep, do not stop to fire") which order will be implemented by a quick combination of clicks, drags and symbol clicks. Without further orders, this battalion would then attempt to take the objective by cold steel charge until successful or until the morale of a majority of the companies breaks.
However, as the bayonet charge progresses, you may see that the rear two companies on the left would assist the assault more if they wheeled oblique left and laid down a suppressing fire on concealed enemy firing from light flanking cover of sparse bushes. You could order this action, which would mimic the battalion commander showing initiative on the spot. At the same time, a reserve of 400 hussars (currently on station in reserve) could be ordered by you to follow up the suppressing fire by galloping into that flank and routing the enemy from the bushes. This gives an example of how the player can order large formation actions and then go further down the command chain to micro more detail to enhance tactics at particular points. The main infantry body will continue to execute original battalion orders while the detachment of two companies follows their separate orders. This capacity to make detachments with separate orders would be important to the design. In large attacks, you would never give orders below company level. If the battalion attack (which might be the hinge of a whole movement) is going well and no micro is needed there, then you could stay at a more strategic command level and order a succession of other battalions in at their point along the attack front.
With construction or economics style RTS actions, the game, if of classic RTS style, could be designed so it needs early individual micro of workers but then allows upgrades which help "automate" the work. For example, an upgrade to create overseers or work gang bosses. This upgrade would mean that peasants are automatically assigned tasks when it is relatively obvious to the engine what they should be doing. For example, if they build a gathering shed near wood, clearly they should then move on to wood gathering. Peasants finishing construction would move along to help any other construction in the immediate vicinity. Idle peasants around the town could be automatically rounded up by an overseer and given tasks according to an engine assessment of what resources you are short of. This latter enhancement of assessing what resources you are short of and automatically rebalancing the peasant labour force might become available after a second upgrade to Quantity Surveyor. Early on, you might need to micro the supply to troops in the field but after a Quartermaster upgrade, the engine takes over supply. This is if the game is to be one with this kind of upgrade system.
However, my main suggested design proposes keeping building to the building of field works (trenches, palisades etc.) rather than building of whole new towns. It does this because then time does not have to be distorted (even in strategic time) to let things be built.
I hope these notes answer you questions.
, nevertheless he presented impresive ideas. 
