Huge games:

Well, there really aren''t very many factors that can be improved in a game with huge numbers of units. Just like an N x N matrix can''t be multiplied in less than n^2 multiplications because something has to be done with each element at least once, a game with huge numbers of units can''t be run faster than the frequency with which the data of those units are accessed. So the obvious choice is to minimize this frequency. Making it easy and helpful to leave garrisons or patrols would be good. Garrisons can simply be ignored unless an enemy is in their sight. If one uses a circular bounding box for this comparison, nearby units can use that same check. Patrols need not pathfind every time they follow a route unless there''s an enemy nearby, although their position must be updated if there''s a minimap.

Perhaps it would be possible to gather statistics on which units are viewed most frequently. My guess would be that any areas where there are or have been enemy units, and where the player is currently looking would be good to have completely in memory. Perhaps decaying this data (as in having it be overwritten by more pressing data) whenever it is not viewed would be a good idea.

Implementing your own virtual memory scheme might be a good idea (probably not as hard as you''d think), as you''re more likely to know when you''ll need data than the operating system.

Dauntless, I think having the player care about their units, seeing them as actual people would add an interesting dynamic to the game. I know that I certainly don''t feel sorry for any of the hundreds of units that get killed when I play RTS games now. Its so far from the way RTS games are now, that its hard to imagine feeling bad about sending my units into battle.

The concept of having to maintain communication with your commanders in the battlefield is a good one. I think trying to avoid the standard RTS game concept of being able to see anything any unit sees is a good goal. However, if your game is set in a sci-fi setting, then the communication shouldn''t be easily interrupted, as it would be in a more historical perspective. In an advanced time, a general should be able to know a lot about the positions of their units. I know you mentioned jamming, but its hard to think of a mode of communication that can be very easily jammed, like radar. If your game was set more in a historical setting, then I think it would entirely appropriate and realistic to lose control of your armies from time to time, and have to trust your subordinates.

Also, you mentioned that the killing of a commander would cause disarray in the group he was controlling. But generally, the armed forces have chains of command so that if someone dies, someone else steps up to take command quite quickly so that everything stays running smoothly. I really like the idea of having your commanding units have personalities. As a player, it would add the necessity to choose your commanders carefully, favoring more aggressive, ruthless commanders in some situations, and cautious ones in other cases. It would be good to have some commanders and units be somewhat poor commanders or fighters, to remind the player that the units are human, and have faults.

I really like where you are going with your RTS game Dauntless, (and I''m looking forward to seeing the website.)

quote: Original post by Dauntless
[...]I feel that most RTS games on the market today are more tactically oriented than strategically oriented.[...]

I agree that they arent oriented toward strategy, but I wouldn''t say they are oriented toward tactics either. The main thing that wins most current RTS is clicking the buttons fastest. Its all about speed, and not at all about anything related to tactics or strategy.

About the AI - I don''t think you should use GA. NN *might* do ok if you find a fast learning algorithm. I really think you might do better with something else, like simple pattern recognition. The AI could store everything the player tells it to do and then look for patterns and try to repeat those patterns. The problem with NN and GA is they generally ''learn'' slowly (it could take hundreds of games for it to ''get it'', and the resulting data might only apply to that one map).

quote: Original post by RandomTask
I like your idea. You are moving from a squad based control to a "command & control" (C&C in military terms) based system. With this in mind you need a way to slow down the combat a bit or else the whole supply chain idea will be for nothing when the enemy storms into your rear lines or rushes your supply depots before you get a chance to set up.

Yes, the pace of my game is going to be a bit slower than what people are probably used to. Also, I didn''t make this clear in the other post, but since it is a hyrbid turn/RT system, once you issue your orders, you pretty much can only watch the events unfold. Unlike the Combat Mission games, I will allow a small amount of "correction", however, there will be a delay in the unit getting and acting out the order.

quote: Original post by RandomTask
You may want to consider having a turn prior to real-time play where each side deploys their units along their areas of control. This would prevent all out rushes for certain areas. I''d also give each player enough units at the start of the game to make something like a bum rush a bad idea.

Good point. In the start of the game, the player will already have had a chance to build up his country''s infrastructure and armed forces with an allotment of points. From this base pool of points, the player can determine his country''s armed force composition, as well as initial manufacturing capabilities. A tradeoff will happen though. If a player elects to have little resources or manufacturing centers but lots of troops at the beginning (a tank rush philosophy) then he must hope that his forces crush his opponent at the beginning. Since I have supply side rules dictating the effectiveness of units, this strategy only has a slim chance of success, since even though he has a huge army, he still must pay for supplies and upkeep. In other words, he''s very strong, but has little endurance. Conversely, a country that spends most of its points on manufacturing and resources (in order to be able to shift into war production later) is at risk of being toppled by a more balanced country early in the game. If the balanced country does not take out the strong industrialized country early, then it runs the risk of eventually being overpowered (you can say that America was a strong industrialized country with an average to weak military at the start of the war...our tanks were not on par with our adversaries, and the Japanese Navy was qualitatively as good as ours but after Pearl Harbor were in superior numbers...we won by wearing out the other nations and using the two great oceans as our best defense). This does lead to a slight problem...obviously the best kind of country to play is an island nation. They can afford to have high manufacturing and resources, but skimp on the initial investment in troops. I''m not quite sure how I''m going to handle that since it''s pretty much the luck of the draw in terms of who gets the best property.

quote: Original post by RandomTask
Also, when working designing your tanks make sure that you include hull down, hunting, overwatch, bounding, bounding overwatch, etc. You can learn all about tank tactics on Battlefront''s website: www.battlefront.com.

I love those guys. A lot of the stuff they are doing is what I''d like to do in my own games. I think players who aren''t into military tactics or strategy will be surprised at the cool things you can do (like having bounding overwatch....which will necessitate objects to have "fields of vision", and not 360 degree detection areas). Also, tanks and helicopters that go "hull down" should be much harder to hit. In my game, I do have something like Mecha, but they are more like really large suits of powered armor. The reason I didn''t want to put in the cliched 30'' tall iron beasts was that it just doesn''t make sense. If military commanders try to go hull down to lower their target silhouette, why do you want to stride into battle in something 3 stories tall? May as well have a neon bullseye on your chest. my mechs are only about 10-15'' tall. I''m more about logical consistency than realism....to me giant mechs simply aren''t cool because they aren''t consistent with game rules (they should be very easy to hit, quite vulnerable to equal mass tanks, and cost a fortune). Game designers like to shoehorn mechs (or other ghastly designs) into their game pretty much based on how "cool" they are, without thinking logically through how those units affect gameplay.

quote: Original post by RandomTask
So, are you going to make it so you can select a commander, and his list of units will come up on the bottom of the screen at which point you can select a unit and tell it to attack a position?

Precisely. When you select a Commander, it will cascade down and show all the other Commanders and units under his command. If you give a top level Commander an order, an interface will pop up asking if you want all sub-Commanders to follow through, or only portions of them (drag and drop probably). From here, I''d like to have coordinated unit tactics such as formations, or offensive or defensive postures based on the unit types that have been selected (sort of like calling football plays).

Flarelocke-
I''m not sure how I can reduce the accessing of units....unless it is easier to process one large group of unit than many several smaller ones. I don''t think at that low a level of programming yet (though I wish I could).

Is there a difference between AI control of units and having an event dispatcher "listen" for events that the player is doing to control units? I would imagine that an event is an event irregardless of whether the player caused the event to happen or if it was an interprocess event (object messaging) between objects.

Since my game will have most of the clicking done during the order phase, pretty much the computer AI interprets the orders it was given, and then follows through. The player can try to change things though, but I''m going to discourage this by having penalties but it will be there as a possibility. So the player really isn''t going to be doing too much interacting once the RT portion of the game begins.

aleclair-
That''s why I want players to think differently about my game. It''s really going to be totally different from other games out there for lots of reasons. But I want the player to see his Commanders like NPC''s with distinct personalities. For that I''m going to have them have certain behavioral traits like how aggressive, brave, independent or discplined they are.

As for communication breakdown, I havent'' posited much more advanced communication technologies than exist today (even though this is probably going to be the most radically changing aspect of technology in the next few decades...I just can''t think of anything). One thing that I probably will do even though I''m somewhat loathe to do it, is introduce quantum encryption, meaning that transmissions are uncrackable without the key. I had originally intended to have the possibility of orders being intercepted and deciphered, but there seemed to be some backlash to this...so I''m not sure if I''ll inlude that feature or not.

In terms of losing contact though, with good EW teams, white noise creators can jam radio and radar receptions. This also means though that that all kinds of passive and active communications and detection systems are vulnerable to certain weapons technologies (for example HARM...homing anti-radar missle). Point to point communications technology will be the least susceptible to jamming or interference, but require line of site transmission which isn''t always possible especially if your satellite gets blow out of the sky (or any other transciever for that matter). When we hit Iraq in ''91, we made sure they were blind deaf and dumb to our attacks. Fortunately no one has been able to put a dent in our communications infrastructure in warfare, but seeing as how it was our first and primary target in Gulf Storm shows how vitally important communications links are for fighting war.

This is just one more way for me to ensure that building the humungous armada is useless if you can''t control it. Just as the supply considerations will make a player realize that having a unit is not the same as being able to use a unit...same goes with communications. You''ve got to feed a unit, supply a unit, and communicate with a unit to use it. Games today abstract this process and assume that of course you can do this...how much fun would it be if you had to worry about that? Well, I don''t think anyone knows because no one''s really done it I want to show that true skill takes more than just creating an army, it takes generalship to lead and communicate with your units, and it takes good logistical understanding to give your units the endurance necessary to keep fighting.

Extrarius-
I''m going to head off to some AI websites so I can get a good idea of what would work. Obviously, I''m not going to be coding the AI "engine" anytime soon But hopefully pretty soon I''ll start a project on this where people can contribute to the design and I can see what they are doing. I''ll need to talk with AI programmers on terms they can understand. Currently, I only have a vague idea of the uses of GA and NN, and I get the feeling that GA is good for "the process of elimination", and NN is good for learning (seeing which nodes have the best chance of "stimulating" the neuron). Obviously there''s more to it than that, but I have lots of studying to do.

BTW, have you done any more looking into game scripting? I was thinking of getting that Game Scripting Mastery book in the game development series since it seems to be getting really good reviews. I''m realizing more and more how critically important the scripting system is to my game now. Not just for unit creation and organizational structure, but also for coding "rules of engagement" that the AI ordering system will use as parameters for its FSM and also applying tweaks to the "War Machine" equation (production ratios, supply routes, and other details about getting war material to the frontlines).

Unfortunately, no I haven''t. I''m working with a book I have now about writing a pascal interpreter/compiler in C/C++(its like a half-assed attempt at making it object oriented) trying to use the info to create a C++ interpreter in an actually object oriented way. The code in the book uses lots of globals that should be class members etc so its taking a lot of work to make it OO.

Isn''t Delphi and Kylix object oriented Pascal? I was curious for a while about Kylix, but I decided I should concentrate on C++ instead. I also started studying Java but after hearing a lot of complaints about Java I decided to look into Python instead.

I think my worst fault is my short attention span. I get interested in too many things at once and have problems getting down to the nitty gritty detail of things. That''s why starting tomorrow I''m just going to start working on the rules structure of my game in a non-language oriented way (not even pseudo-code). Once I get that completed, I''ll see about converting it into UML so that more experienced can take a look at what I''m trying to do (since my syntax with C++ is still very inexperienced, and I have trouble writing in code what I''m envisioning in my head).

Anyways, good luck with your scripting engine. I''ve come close 2 times today about buying that Game Scripting Mastery book on Amazon.com but I just haven''t willed myself to shell out the money yet. I''ll probably wait a little and save up to get a good AI book at the same time....assuming I knew a good AI book to buy for a not-totally newbie programmer.

quote: Original post by Flarelocke
Implementing your own virtual memory scheme might be a good idea (probably not as hard as you''d think), as you''re more likely to know when you''ll need data than the operating system.

I think we call this "caching" and the methods used to determine what remains in the cache would be called use frequency algorithms like "least frequently used", "last used", etc.

Maybe what you can do is for every map square you have a list of pointers to units that can see that square. This way, when a unit enters the square you wake the surrounding units of its presence. Now you don''t have check every unit to see if he sees something in all his squares. This would mean that only moving the units that are moving need to be actively processed. And only the enemies units would trigger the squares, thus only moving enemies would trigger your stationary units.

RandomTask