Landflood is win, but...
Moderator: Moderators
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Landflood is win, but...
Could we get a floodload?
THat would be 100% more win on top of the 100% win that is landflood, making a combined total of 200% win!
THat would be 100% more win on top of the 100% win that is landflood, making a combined total of 200% win!
- Michilus_nimbus
- Posts: 634
- Joined: 19 Nov 2004, 20:38
- EXit_W0und
- Posts: 164
- Joined: 22 Dec 2005, 01:33
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
- EXit_W0und
- Posts: 164
- Joined: 22 Dec 2005, 01:33
Its generally more useful for other chains of commands &Its too complex and has holes in it and is tricky to set up correctly.
I actually found the repeat function more intuitive than the ferry function, but maybe I just have a backwards way of looking at things
Btw I resolved the stuck units problem on 'flood load' (someone please give me a better name for these) :)
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
The repeat command is a more powerful UI tool, I think, because it is one button that can be used for so many applications.
But in terms of actual functionality within the game, as they both currently stand, the ferry function is far more functional, and far more intuitive.
What I am suggesting here is not that we adopt the ferry system, but more that the repeat function for transports in Spring still needs a bit of work.
It's lots of little things like, transports set to load an area, and unload an area will sit and wait at the drop zone, rather then the loading zone; tranports will often leave with one unit for a long trip, despite having a loading capacity of 10+ units.
Advantages the ferry route has are that the loading process is object oriented - as in, you task your units to a point that is always visible, and both the unit and the transport are made aware that a loading order exists. Currently, if you give a transport a load area order, this order is only visible when the transport is selected (and the perimeter is not displayed, simply the load icon). Once the order is given, it is very difficult to work out exactly how big the loading circle is.
Further, in the Supcom system it is very easy to add extra transports to an existing ferry route. You simply task new transports onto the existing ferry beacon. This is extremely helpful, and impossible to do in Spring without issuing new orders.
Finally, the supcom ferry system uses the 'active orders' system, allowing you to change the ferry route in a second by simply dragging the target destination to a new point, and any transports enroute will immediately update their orders and do so. This combines with the previous point to allow an entire invasion to be rerouted in seconds if the landing zone becomes too hot, etc.
To reiterate, I am not proposing we simply implement the SupCom ferry route system, I am merely pointing out that there is a lot of room for improvement, and simply because we have the very clever 'repeat function' (which potentially supcom nicked off Spring) that works in a number of situations with the same UI space (an excellent feature), does not mean we have a fully comprehensive, hell, a fully functional transportation repeat system. And given that it's one of the most touted features of supcom, and one of the most regularly cited in reviews, it's clearly an important element of the game.
But in terms of actual functionality within the game, as they both currently stand, the ferry function is far more functional, and far more intuitive.
What I am suggesting here is not that we adopt the ferry system, but more that the repeat function for transports in Spring still needs a bit of work.
It's lots of little things like, transports set to load an area, and unload an area will sit and wait at the drop zone, rather then the loading zone; tranports will often leave with one unit for a long trip, despite having a loading capacity of 10+ units.
Advantages the ferry route has are that the loading process is object oriented - as in, you task your units to a point that is always visible, and both the unit and the transport are made aware that a loading order exists. Currently, if you give a transport a load area order, this order is only visible when the transport is selected (and the perimeter is not displayed, simply the load icon). Once the order is given, it is very difficult to work out exactly how big the loading circle is.
Further, in the Supcom system it is very easy to add extra transports to an existing ferry route. You simply task new transports onto the existing ferry beacon. This is extremely helpful, and impossible to do in Spring without issuing new orders.
Finally, the supcom ferry system uses the 'active orders' system, allowing you to change the ferry route in a second by simply dragging the target destination to a new point, and any transports enroute will immediately update their orders and do so. This combines with the previous point to allow an entire invasion to be rerouted in seconds if the landing zone becomes too hot, etc.
To reiterate, I am not proposing we simply implement the SupCom ferry route system, I am merely pointing out that there is a lot of room for improvement, and simply because we have the very clever 'repeat function' (which potentially supcom nicked off Spring) that works in a number of situations with the same UI space (an excellent feature), does not mean we have a fully comprehensive, hell, a fully functional transportation repeat system. And given that it's one of the most touted features of supcom, and one of the most regularly cited in reviews, it's clearly an important element of the game.
Its almost like you need the paint tool in MS Word, where you highlight formatting, click the paint brush, highlight what you want formatted, click the paint brush, and then it applies the formatting at the new location, too. Perhaps not a paint brush for Spring, maybe some cute symbol could be cooked up that means to assimilate the command(s) of another unit.