posted 04-23-99 06:06 AM ET
Madpig, I agree wholeheartedly with you. Another example of the same oversight is the G and J goto commands, which only take units to an allied city, never to an enemy city or any other square.
Apparently Firaxis didn't much consider filters or control statements for their movement commands.
Something that's obvious to me, and which looks natural given SMAC's current path capabilities, is the concept of routes as a basic data object. The idea is that rather than having to assign waypoints to a unit, then sending it immediately, players should be able to define a route using waypoints, independently of the existence of any units.
Routes could be named, for easy reference. It's a lot easier to say `silk route' than to specify all the waypoints through Europe and Asia _each and every time you want to use it_.
You could name routes 1, 2, 3 if you really wanted to. But I prefer names that relate to terrain or purpose.
For quick access, routes would be listed in a table, in order by name.
Talking of accessing names in a table, what Civ2 and SMAC badly lack for large empires is a multiletter (incremental) search. The initial letter is just not enough to get to the right city fast enough (RSI, you know, Brian). If I need to find Szucity quickly, I don't want to go through all the S's to get there, I should only have to type `Sz' (or at worst `Szu') to go there instantly. There have for decades been commonplace programs that do that efficiently, so why not SMAC?
Routes are a flexible generalisation of autoforwarding, as they would connect any squares, not just to bases.
We would use routes for supply crawlers, armies, anything that can move on land, sea
or air.
Units could be told to go to a near point on a route, then follow it, as simply as `<select route> <select units> <end selection>'.
A valuable complement to routes is a group of units, especially a named group. We should be able to say `<hotkey> <name group>' and `<hotkey> <select group> <select units for group> <end selection>'. Then order the group to move, gather at a square, sentry there, attack a square, the same sorts of things that individual units can (or should be able to) do.
For groups, following a route would be simply `<select route> <select groups> <end selection>'.
There's no reason to stop at one route per operation. Armies often have to navigate through a series of familiar and unfamiliar territory, so why not combine old routes into new ones, as in `<hotkey> <new route> <select routes> <end selection>'. Routes that do not already meet can be connected by either the player fixing by manually adding the connecting routes, or by letting the AI do it automatically; for small distances, the AI might even do a tolerable job. Once the route is determined, it remains firm, and the player and the AI never have to re-establish or recalculate it.
Routes should also be deletable, and editable by cutting sections out of them (who says a route has to be continuous?). Other operations may come to mind to anyone who's used a drawing/paint program. Because all routes are is oriented polylines (piecewise linear paths).
Let's face it, real life commanders don't rely on AI to direct their troops, they direct them by saying `take this valley route, then go there and take that route, if you meet the enemy, hide out until they pass, then proceed by this route if safe, otherwise take that route'.
The best thing about named routes is that they're easy to program, make great sense to player commanders, require much less management than the present system, and are strategically much more useful.