Maybe the game applicability got lost in that last post. I''ll try to clarigy a bit. There are really four map based elements to my idea.

Map Entrance Point
Supply Lane
Drop Off Point
Supply Depot

Map entrance points are an area along the edge of the map where a supply lane begins (or you can think of this as the place where the supply lane enters the map). In order to connect a supply lane to an entrance point the player must control the entrance point. In the event that the player loses control of the entrance point the supply lane becomes dead and no goods will enter the map via this point. Inbound supplies on this route will be redirected accruing a time to delivery penalty.

The entrance points can be of two types, static or dynamic. Static entrance points represent major highways, airports, and railroad rails which are constructed prior to the battle, hence the reason they are static. Static entrance points allow the most goods to flow in the shortest amount of time. It is important to control static entrance points.

Dynamic entrance points are small roads that litter the edges of the map. These can be moved along any edge that you control. You can limit the number of dynamic entrance points an edge can contain. These have a lower rate of supply delivery because they represent the fact that the goods being delivered using efficient methods of travel like trains and highways but rather are trickling in by any way possible.

Supply Lanes are corridors that define the path along which supply units travel once they enter an entrance point to the drop off point. The supply lane starts at an entrance point and ends at a drop off point. Should an enemy capture part of a supply lane part of the supply units currently on the lane will be captured or destroyed while the remaining will return to the drop off points (for outbound units) or exit the map and redirect via a different entrance point. A supply lane can be bombarded by the enemy.

There are static and dynamic supply lanes. Railroad rails are static supply lanes that connect the static rail entrance point to the static train station. They are static since they were built BEFORE the siege.

Major road and small road entrance points can have dynamic supply lanes connecting to them that are user changeable. Should the enemy cut off a dynamic supply lane it can be redirected to a differnt destination (drop off point).

The drop off points are the places where the supply units drop off their supplies. They are the terminal points for the supply lanes. Train stations and airports are static drop off points whilst major road and minor road drop off points are dynamic and can be changed by the users. Each drop off point will route inbound supplies to user specified supply depots. Troops can be directed to go to one place while fuel and ammunition to another. If there are no supply depots specified for certains goods they will remain at the drop off point.

Supply depots are the places where the dropped off supplies are actually stored on the battle field (in the rear). Should you have two main battle forces that have been split in half and one has an ammo dump (supply depot with ammo) and the other doesn''t then one battle group will be without ammunition. Supply dumps are important to keep near active forces with special needs. Fuel dumps are important near tank groups and mobile units. Artillery dumps are important near artillery batteries.

The closer the supply depot is to the unit the faster it will automatically replenish its supplies. If the nearest kitchen (supply depot with food) is all the way across the map your forces may experience slow starvation. There must be an open avenue of geographical control from the unit to the supply depot in order to procure supplies.

I hope this was interesting. Most of this can be set up automatically. You can tell each drop off point how to distribute the goods or you can have a computer controlled AI determine the best way to distribute the goods based upon number of available supply depots and concentration of certain unit types. Player can have engineering units build new depots as the front lines change. The reason for not having too many depots is that loss of a depot means that the enemy captures or destroys those goods. You''ll of course want to give the players the option of clearing out or abandoning a depot should they deem it necessary.

With this in mind you''d be able to direct a group of soldiers to "conserve ammo", "ration food", "ration fuel", at which point they will use it sparingly. On the other hand you could also encourage them to "expend ammo" for massive bombardment or "normal ammo" for normal consumption/attrition.

RandomTask

RandomTask-
Excellent ideas, and they are very similar to my own. I''m glad to see that other people here recognize and value the supply side factors in fighting. When you really think about it, the most difficult part about fighting effectively is making sure your units CAN fight. Stalingrad is an excellent example of supplyside factors swinging the tide of battle, and in many respects it was the Japanese inability to stem the supply side of American troops in the Pacific campaign that lost them the war.

The Japanese unlike the Germans felt that their submarines were too precious a commodity to use against "mere" convoys. It was less than honorable to shoot down helpless convoys so it was deemed more appropriate to their sensibilities to use submarines to attack other warships. This meant that unlike the Atlantic, the convoys were rarely in threat of being sunk. This in turn meant that the Japanese had to extremely fortify all of the islands that created a chain-link of supply. They knew that the Americans had to capture some of these islands to directly attack or invade Japan.

So the Americans just simply bypassed many of these islands starving the garrisons left there. The Americans had a much better grasp of supply side equations of battle than the Japanese did. And if you really think about it, the entire war was fought because the Japanese didn''t have enough oil to conquer the rest of asia. They had to fight to America (and the Dutch and English) to capture vital oil fields. Too many games assume that once you create the units, that''s it, your done. You can use them as long as you like whenever you like. A truly good general must consider much more than that, and that''s the flavor I''m trying to get across in my game. In my game, you may be a very good tactical general and know how to defeat superior froces, but if you can''t see the larger picture, you may win the battles but lose the war.

Your ideas about the following are similar to mine:
1)Map Entrance Point: In my game, this is similar to the Manufacturing Center. It is the point at which goods are actually made and rolled off the assembly line
2)Supply Lane: This to me is the Transport Unit route that goes from the Manufacturing Center to the Distribution Hubs
3)Drop Off Point: I think this is your idea of what I would call a Distribution Hub. This is the wharehouse area that contains all the assembled good from the homefront as a clearinghouse to go to the frontline. Think of the huge artificial docks (Mulberry''s) that were created at Normandy, and this is a Distribution Hub (a major one in the case of the Mulberry)
4)Supply Depot: I don''t have a direct equivalent to this, as I assume this is your idea of a Quartermaster? I do have something like this, but it is an abstracted object within a Battlegroup and can only be targeted indirectly.

I do have one more which is the link between 3) and 4) which are the actual supply unis (transport trucks, cargo ships, ferries, etc) that shuttle goods between the Distribution Hubs and the actual Supply Depots (Quartermasters).

Thanks for your reply Dauntless. (I posted the anonymous message. I have a user name now.)

I think that this idea of a Mercantile Commander is a very good one. It seems to me to solve the problem of micromanaging the supply side of the game in a way that is flexible, (especially if it can learn) and intuitive for the player. One thing I''m wondering, though, is what type of government there would be. If your Mercantile Commander controls all the people in the town having them produce goods for the war, then it sounds more like a communist/dicatorship type government. Maybe I''ve misunderstood your intentions. Do you mean that the Mercantile Commander would just control government owned factories and crop fields, hiring workers to produce goods for the government? Or, would the MC buy goods from private companies which would supply goods to meet the government''s demand for weapons, food, and supplies?

The capitalist system would be more realistic, but also more complicated when it comes to the game, because the player would have to act as a government leader as well, taxing citizens, buying supplies and recruiting new soldiers. With this system, then the "production" of soldiers could basically be the costs required to hire them and pay them, (unless you had a draft.) It all seems like it would get quite complex. With complete control over your citizens, you could just force people to be soldiers, and worry only about having enough workers making supplies and keeping people in your city fed.

Theres one final thing I''m noticing about this whole idea. It strikes me, as I believe someone said earlier, that this game is going to require HUGE maps. If the game is going to have reasonably large cities as well as enough land so that the battle isn''t happening in the cities backyard, these maps are going to have to be detailed in their geography as well as having realistic cities. Do you have any idea as to how you''ll manage this in the game?

quote: This is not a renewable resource. And just as importantly, if your country is invaded or bombed, your population will also decrease. A countries population is ABSOULTELY its most vital resource since it can not be recaptured or manufactured. It may possibly be bought (through mercenaries) but that''s it. And yet how many games have population as a resource? Very few. By stressing this resource, it should make players less willing to throw troops away needlessly (I really hate the cannon fodder mentality of most RTS games in which there is no penalty for destorying large sums of your own armed forces). It will also mean they should be much more willing to protect even pure civillian based cities with no military or manufacturing centers (think Dresden).

That''s the thing that bothers me the most when playing stratagy games is that you have essentially unlimited population under your control... which allows you to overwhelm the enemy...

I think that Starcraft may have been a better game if they had implimented this, because in the manual and in the game, they talk about massive losses of the Humans and Protoss against the Zerg, and the fact that the Zerg were winning due to their unique ability to create units so fast, but this was only implimented in the unit costs, rather than put in game. Even the human forces in the end combined with the Protoss weren''t enough to overwhelm the Zerg, but this was implimented through only a cut-scene...

-Drugs are bad. Especially if they look like machines. Serial Experiments Lain

-Small girls with a single braid in their hair are all-powerful God''''s. Accept it. (Phar)

RandomTask-
I''ve been thinking about your concept of having both static routes and dynamic routes. In a way, you have to think of it in two terms. A static route is essentially a pathway which is always there. It is a road, a railroad, a river, or some other medium of transportation which is fixed and unalterable. Dynamic routers are routes which really have no defined setting...the sea, the air, or overland. Now you also have to think about the actual "routing" (not to be confused with the noun route). You can "statically route" (in the verb form) meaning that your pathway is fixed. You have a set direction and roadmap that you have to follow. Then you can have dynamic routing which means that the directions you take to get somewhere can change...maybe instead of taking I-4 to the Greenway Express, you decide to take SR 50 over to Sand Lake (fill in your own road directions here).

To differentiate the usage of "route", I''ll say pathway for the noun usage, and use "route" to mean determining the direction and map to get somewhere.

So, static pathways must be defined on the world map. These will quite obviously be very valuable strategic targets. Controlling static pathways means that you can transport items more quickly than through overland routes. The only thing that would be faster are dynamic pathways in the air.

The second thing that has to be considered is, how do you determine if the supplies take a static or dynamic route? And once they decide that, how do they know if they do it over a static or dynamic pathway? Some kind of AI is going to have to determine what the fastest (or safest) route is to get from the Distribution hubs and into the hands of the BattleGroup''s quartermasters. Probably what I''ll do is put a minor MercantileCommander in place here who specializes in routing functions. He determines what the fastest means of travel are by comparing his Supply Units (does he have access to Air transports, or does he only have trucks) and the map of the land. He''d have to compare where the Distribution hub was compared to where the BattleGroup is, and determine what the fastest method (or safest depending on what the player wants) to get the supplies there.

I''ve only dabbled in using routing protocols like RIP and OSPF, but they''ve given me some ideas on how to determine the fastest ways to get supplies to units.

aleclair-
That was me who said the maps are going to be huge...and its something I''m worrying about. My game is really on a very grand scale in terms of the numbers of units involved and the span of the warfare. I''m really not sure how I''m going to create the world database that will require this kind of detail.

I had originally thought about having a database describe the world, but not actually generate the maps unless the players decided to fight there. The disadvantage of that scheme is the awful load times that''s going to cause, because the game is quite literally going to have to create the world on the fly. I''m actually going to make my game on linux first, and since all Linux computers have gcc on them, I might even do something whacky like literally create the .so objects on the fly (from source code) and somehow tell the game to look for the newly created object in the library (I''m not sure how to do that...or even if its possible for that matter).

If anyone has any ideas on how to create a super large world like this, I''d love to hear some suggestions. This aspect more than anything else has me worried from a technical standpoint. I actually think the AI requirements are doable, and the sheer size of the forces (about 150-500 icons per side...and that alone should give you an idea of how huge the battlemaps are going to be) I think are doable...especially since this game probably won''t see the light of day for at least a good 2 years

Here''s a couple thoughts from a programmer''s point of view.

If you are doing a US Civil War game I don''t think you can go about generating the maps on the fly. You''ll probably want to premake all the maps to make sure you have historical accuracy. For instance the geography of Gettysburg and Antietam already exists. The reasons that battles took place the way they did was because of the terrain and geography.

Remember, you only need to have the active map that is being played on loaded in memory. This would mean that you''d break your world up into manageable map segments.

You are going to have well over 500 units if I understand the scale of you game correctly. In your game in particular you''ll have your generals, foots soldiers, irregulars (like long rifle companies), cavalry, cannons, mortars, engineers, horse carts, trains, boats, scouts, doctors & nurses. Picking the Civil War is good because it limits the number of possible units.

As far as having supply officers. I think the AI''s that handle this kind of work are essential but I think it might be a bad idea to actually represent them in the game as an actual unit that walks around. Regardless of whether this unit gets killed or not the goods will always continue to flow. Rarely would this officer ever actually leave his depot except to procure goods from the distribution points. Even then he would most often send out one of his grunts to get the goods he needs. If you do have him exist I''d say make him either always in a supply vehicle moving from depot to distribution point or make him in the depot. Don''t let the player move him and don''t make him too easy to kill. In large scale sieges officers are killed/replaced all the time and the subordinates or replacements that step up are qualified to continue the procurement of goods. The moving of goods should still exist but I think you can manage it with the officers implicitly staying in the depot''s better than with actual units that can be easily walk about and get killed. On a MACRO level the supply depot officers and the STAFF are what make the goods move.

In the same respect I wouldn''t have the physical general. I would have the generals convoy and the generals bunker. The engineers can build different bunkers about the map and the generals staff can be moved from bunker to bunker via his convoy. He either exists in the convoy or in the bunker. The generals are another unit that is relatively easy to replace. New ones would quite often replace the others in the field, even during battles and campaigns. The generals STAFF is the important part. On a macro level the general AND his STAFF are what get things done.

Don''t make your players micro manage too much or the game will be absolutely overwhelming and totally unplayable. You can add supply logistics without making THAT the entire game. Most games do not try to handle it in a real way because it is entirely too cumbersome to deal with. If you add to much micro management being good involves player efficiency rather than skill and smarts. This would mean that a computer would always win out over the human because a computer is way more efficient at moving supplies than you ever could be.

You have to think about the type of game you are making here. It seems that you want to have warcraft II/starcraft level micro management of units and yet you also want to have MASSIVE sieges AND supply chain logistics. This isn''t possible without multiple players per side handling each issue separately. You may have to sacrifice micro management and the concept of the SINGLE unit for the ability to have large sieges.

In this respect you''ll hvae macro management. You''ll have head quarters units, supply units, caravans of fuel trucks and supply trucks, command units, etc. As someone mentioned earlier, the number of supply units to fighting units in large scale battles is ridiculous. You don''t want to make the player player 500 supply units and only have 100 fighting units.

Great ideas floating around here. I just recommend simplification for the sake of the player''s sanity. Don''t overwhelm the player.

RandomTask

More on path finding. Path finding shouldn''t be that difficult to do. Basically what you''re going to have to do to determine if supply routes are under your control anyway is keep track of who controls a section of terrain. Also, keep track of what is passable terrain (roads, fields, trails) and what is not (buildings, trenches, forests).

If you control it or it is neutral then you can move goods across it. Otherwise you can not. A supply convoy (controlled by a path finding AI) will try to reach its destination via its prescribed route. When it reaches a break in your control area it will skirt your area of control (behind the frontline) and try to return to its prescribed path after the break in the control area where it will then continue to your depot.

Should you feel that you''ve seriously lost a block of terrain for good it would be fitting to allow the user to then change the dynamic supply routes so that the AI pathfinders don''t have to make any decisions that might get them killed.

Of course, if someone takes a segment of your railroad tracks, you''ll be in trouble so you''ll need to protect those very well.

RandomTask

quote: Original post by RandomTask
You are going to have well over 500 units if I understand the scale of you game correctly. In your game in particular you'll have your generals, foots soldiers, irregulars (like long rifle companies), cavalry, cannons, mortars, engineers, horse carts, trains, boats, scouts, doctors & nurses. Picking the Civil War is good because it limits the number of possible units.

I figure about 500 units (total on both sides) is roundabout what I'll have, but larger games could have twice that much. My game right now is a near-future sci-fi simulation, but the Civil War is a very cool period, and if I had to do a historic genre setting, I'd probably do that first, and the Revolutionary War second (although I've always wanted to do a 1890-1920's time period setting too...maybe play some Filipino Insurrection fighting, the Boxer Rebellion as well as WWI stuff).

quote: Original post by RandomTask
Don't make your players micro manage too much or the game will be absolutely overwhelming and totally unplayable. You can add supply logistics without making THAT the entire game. Most games do not try to handle it in a real way because it is entirely too cumbersome to deal with. If you add to much micro management being good involves player efficiency rather than skill and smarts. This would mean that a computer would always win out over the human because a computer is way more efficient at moving supplies than you ever could be.

With supplying, I think you're right. The rules for supply side routing will be pretty formalized and therefore fairly deterministic and predictable. So computers will indeed be better suited to handling this than humans. The reason I was thinking of this in networking terms was for fault tolerance. In networks, if a name server crashes, or if physical cabling gets disabled somehow, the IP protocol will find a way around these obstacles (hopefully). I pretty much want the same capacity here, where instead of cabling, hubs and routers, you have roads, bridges and railroads, and instead of name servers and routing protocols, you have Supply Managers who calculate this stuff for you. I think the key player involvement will be in directing the priorities that he'd like to see...something the computer won't be that good at. Perhaps the player will need to switch to dynamic routing over dynamic pathways to get supplies behind enemy lines for example.

quote: Original post by RandomTask
You have to think about the type of game you are making here. It seems that you want to have warcraft II/starcraft level micro management of units and yet you also want to have MASSIVE sieges AND supply chain logistics.

Acckkk, God no!! lol. I wouldn't wish Blizzard/Westwood style micromanagement on anyone. Indeed, my whole game structure is to almost completely leave that RTS paradigm.

A lot of the micromanagement of my game system will be taken out by having AI Commanders, and by having logical groupings of units called Clusters and BattleGroups. Clusters are dynamic container that hold pointers to actual unit objects. For example, 4 M1A2 Abrams make up one tank platoon. Clusters do not have to be homogenous...for example you can assign 4 M2 Bradley's and 4 infantry rifle squads into a Cluster to create a mechanized rifle platoon. The smallest atomic "unit" is one vehicle or one "team" of infantry (a team is variable in number...it might be 10 men to a squad, or a 2-man sniper team). Every Cluster and BattleGroup is controlled directly by an AI Commander object (and the Cluster has a pointer to this Commander object). The Commander takes orders from an Avatar, which is the physical representation of the player on the map itself. BattleGroups are simply another kind of container that holds pointers to Clusters and other BattleGroups...and are logical organizations of Clusters. For example, a company BattleGroup may contain 4 Platoon Clusters, and a Battalion BattleGroup will contain 4 Company BattleGroups...etc etc.

This is where I disagree about having generals in the background (but I do agree with you about the Mercantile or Supply officers). To me, while generals can lead from the rear, the field officers (from about Major on down) pretty much have to fight with their troops. These Commander objects can not be directly attacked, however, they can and will die from time to time when going into battle. This is important because the Commander is the nervous system of the unit. If they lose their Commander, they can react to an extent, but will be penalized until the chain of command gets re-established. The higher up the rank of the Commander, the less likely he is to get killed in battle because he is further behind lines.

There is another reason I want Commanders. They are not only the nervous system of Clusters and BattleGroups, but also its eyes, ears and mouth. The player will only know what a Commander knows if the Commander can see it, and if that information is relayed to the player. For example, if a BattleGroup is somehow cut-off from communication (all its comm teams have been destroyed, it is being jammed, or natural terrain has cut it off), then to the player that group just disappeared! Until communication is re-established (and this is done automatically via the comm teams in all units) then the player will have no idea what is happening to that unit.

I have done this to get rid of God-like gaming which ALL strategy games that I am aware of do. A player must ensure unit integrity and communication links at all times. This means that a player is not guaranteed of always knowing what his Commanders know, nor is he guaranteed of having access to them. It will require the player's skill to maintain good links of communication and unit integrity amongst his BattleGroups.

So where does the easing of micro-management come from? By logically organizing large to small groups, the player will be able to assign large groups to do complicated manuevers and tasks. I'm going to develop an ordering system which will have two kinds of AI: an FSM that looks at "rules of engagement" parameters, and an autonomous AI that the AI commanders use independently (I think I will only give this level of AI to at least "Company" level Commanders...I say "Company" because the player is free to design his own unit organizational structure).

Also, my system will be a hybrid turn/RT based system, so that will allow players some time to think of issuing Orders to BattleGroups as well as a strategic phase (after the battles are over) to tweak the Mercantile Officers or Supply Officers settings.

The most important thing I want in my game is to get rid of the God-level of control (omniscience and omnipotence over his troops), and the second most important thing I want about my game is for the player to CARE about his people. That's a big reason I hate the cannon fodder mentality and a lot of my design considerations try to think of ways to make the player have to think about what he's doing (the supply side of war efforts, implementing sophisticated morale, unit experience, Commander personalities, etc etc.). In the end, I want the player to feel as attached to his armed forces as most RPG'ers feel about their character. I think too many RTS games use pieces as pawns...simply tools to get the job done. And while war truly is about sacrificing what you have to to win the war, I want it to be painful for the player to do so.



[edited by - dauntless on February 6, 2003 1:42:25 PM]

Great points dauntless. I think it would be fine to have commanders as units on the field if you are getting rid of micro management. You seem to have some good ideas how to do this. You might want to take a look at the game Combat Mission: Berlin to Barbarossa to see how they handle the AI aspects of unit control.

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.

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.

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.

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?

RandomTask

[edited by - RandomTask on February 6, 2003 2:00:58 PM]