I'm just getting back into playing this game after a stint of Supreme Commander and Total Annihilation. In both those games Comm Ends is default, and 'Annihilation' or 'Comm Continues' is a rarity.
I could go into all the advantages of this in huge detail but you all know the argument well already. Suffice to say giving players a free mini nuke in the first 10 minutes is pretty balance breaking, even if you try and reduce the radius of the explosion as much as has been done so far.
At least if the game is comm ends you can choose to comm bomb someone to help your ally but you'll be out of the game. But in large team games at the moment it's pretty much a given that people will build a load of tanks, walk their comm into yours and follow up with their army.
Suggestion: Comm Ends as default
Moderator: Moderators
Commander ends is fruitless because it changes the dynamic into a commander hunt game. Ontop of that I've seen many people loose their commanders then go on to win the game.
Its simply a matter of seeing that a com ends isnt a foolproof way of killing off combombing and combombing isnt a bad tactic beause it gives you advantages and disadvantages, a good player will exploit an enemy combomber mercilessly and to great effect.
For example, people rarely play with storage in BA, so if the enemy combombs then he's completely annihilated any chance of winning by crippling their economy. You can simply rush in with a horde of units a minute later and they wont have the storage to keep things firing and rebuilding, theyll be wasting masses of resources.
There's also the very valuable wreckage left behind afterwards in BA. In XTA your commander is a valuable offensive/defensive tool when used correctly and removing it via combomb cripples your ability to defend against a com push before you can get a HLT or lvl 2 up and running.
Its simply a matter of seeing that a com ends isnt a foolproof way of killing off combombing and combombing isnt a bad tactic beause it gives you advantages and disadvantages, a good player will exploit an enemy combomber mercilessly and to great effect.
For example, people rarely play with storage in BA, so if the enemy combombs then he's completely annihilated any chance of winning by crippling their economy. You can simply rush in with a horde of units a minute later and they wont have the storage to keep things firing and rebuilding, theyll be wasting masses of resources.
There's also the very valuable wreckage left behind afterwards in BA. In XTA your commander is a valuable offensive/defensive tool when used correctly and removing it via combomb cripples your ability to defend against a com push before you can get a HLT or lvl 2 up and running.
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
how about thrashing completely stuff like starting metal, comm ends, ecc and instead have a direct lua interface mod-lobby that will let you define/create/restrict the launching options?
CA's deployment would become a lobby option, not a mutator
mods like EE would finally not be played in commander ends mode, ecc..
EDIT: if you think lua is overkill, an xml-based defin would work as well, hell even a plain text file would be better, at least it would pass the mod specific options to the lobby!
CA's deployment would become a lobby option, not a mutator
mods like EE would finally not be played in commander ends mode, ecc..
EDIT: if you think lua is overkill, an xml-based defin would work as well, hell even a plain text file would be better, at least it would pass the mod specific options to the lobby!
I think it should go in the opposite direction. Just have mutators for mods with different game modes. Instead of playing BA with com ends, you could play a BA mutator called "BA Commander Ends" which defined the end conditions in LuaRules. This would be very easy if the lobby supported changing the mod without rehosting.
1UPBrain Damage wrote:how about thrashing completely stuff like starting metal, comm ends, ecc and instead have a direct lua interface mod-lobby that will let you define/create/restrict the launching options?
CA's deployment would become a lobby option, not a mutator
mods like EE would finally not be played in commander ends mode, ecc..
EDIT: if you think lua is overkill, an xml-based defin would work as well, hell even a plain text file would be better, at least it would pass the mod specific options to the lobby!
No. That'd force one mod file for each possible combination of the settings ("CA Deployment Hovercoms, Com ends, limit DGun, no diminishing mexes, 1000 Metal, 2000 Energy, Random start position"). It'll cause your mod list to grow insanely long, make it hard to impossible to find the right version you want to play (both as a host and joiner), creates a maintenance nightmare for modders, makes changing settings impossible without closing the game and rehosting and makes it impossible to have adjustable numbers for the settings (e.g. "frag limit" for com shooter).det wrote:I think it should go in the opposite direction. Just have mutators for mods with different game modes. Instead of playing BA with com ends, you could play a BA mutator called "BA Commander Ends" which defined the end conditions in LuaRules. This would be very easy if the lobby supported changing the mod without rehosting.
-
KingRaptor
- Zero-K Developer
- Posts: 838
- Joined: 14 Mar 2007, 03:44
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
There we go!Brain Damage wrote:how about thrashing completely stuff like starting metal, comm ends, ecc and instead have a direct lua interface mod-lobby that will let you define/create/restrict the launching options?
CA's deployment would become a lobby option, not a mutator
mods like EE would finally not be played in commander ends mode, ecc..
EDIT: if you think lua is overkill, an xml-based defin would work as well, hell even a plain text file would be better, at least it would pass the mod specific options to the lobby!
Ya, basically, global defaults are bad, because spring isn't a game, it's an engine that runs many games. We need to impliment systems to allow each game to control it's own default systems independently.
IMO the current lobby's system of managing game interfacing is temporary at best. Even the way alliances and teams are handled will likely need a retake for some mod styles.
Imho, the simplest approach would be to allow structuring mods as a tree.
That is, first I have AA - once I click AA, I can go with default AA, or use one of it's child mods.
The child mods would include the various commander mutators, game-ends mutators, and resource mutators.
Those mods would, in turn, have child mods for their own mutators.
Thus, you'd have to make a mod for every permutation of configuration, but it would appear relatively clean to the user. Give the mod two names - a "menuname" and a "fullname" - the menuname is what it is called when listed as a sub-menu, and the fullname is what it is called elsewhere.
Thus, "Balanced Annihilation, Game Ends, Max Resources, Hovercomms" Would be set up by selecting
Balanced Annihilation -> Game ENds -> Max Resources -> Hovercomms.
Of course, you'd still need to have a brazillion mods to implement the full set of permutations of the option tree, so a mechanism for defining oodles of mods within a single SDZ would need to be available to avoid foisting a maintenance nightmare onto the user.
I know this approach is ugly, but would work the best with the current mechanisms of modding.
I think that a mixed approach - the "mod tree" approach for old-style unit-based modding, and a Lua-GUI for the selected mod is available for Lua-based changes, wherein the selected options are passed into the start script.
The former approach means that Lua isn't necessary to provide complex options to the user without flooding the mod-list, and the latter approach allows the hardcores to use Lua for clever stuff.
That is, first I have AA - once I click AA, I can go with default AA, or use one of it's child mods.
The child mods would include the various commander mutators, game-ends mutators, and resource mutators.
Those mods would, in turn, have child mods for their own mutators.
Thus, you'd have to make a mod for every permutation of configuration, but it would appear relatively clean to the user. Give the mod two names - a "menuname" and a "fullname" - the menuname is what it is called when listed as a sub-menu, and the fullname is what it is called elsewhere.
Thus, "Balanced Annihilation, Game Ends, Max Resources, Hovercomms" Would be set up by selecting
Balanced Annihilation -> Game ENds -> Max Resources -> Hovercomms.
Of course, you'd still need to have a brazillion mods to implement the full set of permutations of the option tree, so a mechanism for defining oodles of mods within a single SDZ would need to be available to avoid foisting a maintenance nightmare onto the user.
I know this approach is ugly, but would work the best with the current mechanisms of modding.
I think that a mixed approach - the "mod tree" approach for old-style unit-based modding, and a Lua-GUI for the selected mod is available for Lua-based changes, wherein the selected options are passed into the start script.
The former approach means that Lua isn't necessary to provide complex options to the user without flooding the mod-list, and the latter approach allows the hardcores to use Lua for clever stuff.
Pxtl, why would you need the tree?
Creating a list of premade options is just restrictive, no matter how you show it to the player. What if someone wants 2500 metal but there's only 1000 and 5000 on offer? What if the modder forgot to update a file in an option five layers down that makes it crash/behave extremely bad in one config? You get loads of file clutter and no real gain except for modders who are unwilling to learn how to use a new method. Just let us place input boxes (and checkboxes, radiobuttons and comboboxes,of course) in the effing lobby and be done with it, you're saving us a lot of trouble, make it easier and thus MUCH less bug prone! Building a complex mutator tree isn't going to be much easier than just writing a way to lua this.
Creating a list of premade options is just restrictive, no matter how you show it to the player. What if someone wants 2500 metal but there's only 1000 and 5000 on offer? What if the modder forgot to update a file in an option five layers down that makes it crash/behave extremely bad in one config? You get loads of file clutter and no real gain except for modders who are unwilling to learn how to use a new method. Just let us place input boxes (and checkboxes, radiobuttons and comboboxes,of course) in the effing lobby and be done with it, you're saving us a lot of trouble, make it easier and thus MUCH less bug prone! Building a complex mutator tree isn't going to be much easier than just writing a way to lua this.
Well, I was trying to suggest the simplest approach that didn't involve constructing a whole LUA-based form-rendering system for the client. Not necessarily the best approach, but the simplest. The LUA-based system could come later, while the tree-based system would provide a way to clean up a problem that exists now (mod/mutator versions clutterring up the mod listings).KDR_11k wrote:Pxtl, why would you need the tree?
Creating a list of premade options is just restrictive, no matter how you show it to the player. What if someone wants 2500 metal but there's only 1000 and 5000 on offer? What if the modder forgot to update a file in an option five layers down that makes it crash/behave extremely bad in one config? You get loads of file clutter and no real gain except for modders who are unwilling to learn how to use a new method. Just let us place input boxes (and checkboxes, radiobuttons and comboboxes,of course) in the effing lobby and be done with it, you're saving us a lot of trouble, make it easier and thus MUCH less bug prone! Building a complex mutator tree isn't going to be much easier than just writing a way to lua this.
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
adding a new tree-based mutator scheme & new file format scheme would requies as much as work as implementing one of the interfaces i suggested
also i think it's waste doing something that would become obsolete in a short time
also a lua-gui is totally unnecessary, the modders would have only to define the options trought functions, the abstracted libs that are already used by the lobbies would merely be called by a definition file i that will get interpreted by a C/pascal/java/whatever code. While spring didn't have a gui lib (iceui is an attempt) all the standard programming langauges already have, so it will be relatively easy to do
off course a basic minimum syntax will have to be defined, but that's not really the problem
if you're scared of modder unfriendliness, default lua/xml/text scripts could be set & included into spring that would implement linage, comm ends,ecc
but then modders would have the freedom to disable, overwrite with theyr version & add more; also would save backwards compatibility of mods
also i think it's waste doing something that would become obsolete in a short time
also a lua-gui is totally unnecessary, the modders would have only to define the options trought functions, the abstracted libs that are already used by the lobbies would merely be called by a definition file i that will get interpreted by a C/pascal/java/whatever code. While spring didn't have a gui lib (iceui is an attempt) all the standard programming langauges already have, so it will be relatively easy to do
off course a basic minimum syntax will have to be defined, but that's not really the problem
if you're scared of modder unfriendliness, default lua/xml/text scripts could be set & included into spring that would implement linage, comm ends,ecc
but then modders would have the freedom to disable, overwrite with theyr version & add more; also would save backwards compatibility of mods
I just don't like how the Commander has been nerfed, and nerfed to the point now where he's ridiculously vulnerable. In Balanced Annihilation he has a pitiful amount of armour. He's meant to be the most powerful unit int the game for the first 15 minutes or so. As it stands now he's an absolute panzy.
Yeah, you can make the wreck worth alot. And give him little armour. And cripple you with no storage. But it's not a very satisfying way to do it. Better to make him your king that you have to protect at all costs and make him a dangerous unit that people want to keep rather than throwing away in a suicide mission.
Yeah, you can make the wreck worth alot. And give him little armour. And cripple you with no storage. But it's not a very satisfying way to do it. Better to make him your king that you have to protect at all costs and make him a dangerous unit that people want to keep rather than throwing away in a suicide mission.
