Metal Maker AI

Caydr · Post by **Caydr** » 07 Oct 2007, 23:50

Does anyone else see this as quasi-cheating? It's a long-standing feature of the game, I get that, but I don't see myself ever using it. It seems dishonest. It takes away the much of the consequences of bad economic planning.

I'm asking this because I think the community has taken it for granted as a feature of Spring, but nobody's given it any critical thought. Less micromanagement isn't always better. I think there ought to be a way to disable it as a game option somehow... some way that it wouldn't be bypassed by just renaming the LUA file or something. Has anyone else had feelings like this?

Personally I've never used it.

Snipawolf · Post by **Snipawolf** » 07 Oct 2007, 23:51

I've never even used an AI like this :D

Caydr · Post by **Caydr** » 07 Oct 2007, 23:53

I hope LUA hacks like this don't get out of control. Next we'll have aimbots... Or a way to make constructors that are under attack automatically retreat or attempt to reclaim their attacker based on the unit's name, or automated DT blocking...

There needs to be a way for the host to say what specific scripts are allowed, if it's not already in place. (As you know I haven't played recently)

Neddie · Post by **Neddie** » 08 Oct 2007, 00:15

You can control what Lua is permitted in a game you host. Problem solved.

Caydr · Post by **Caydr** » 08 Oct 2007, 00:30

So there is no way for a client to use an LUA script the host has either a) ruled out or b) never heard of? If that's the case... relief. When did that get put in place?

imbaczek · Post by **imbaczek** » 08 Oct 2007, 00:59

there was a huge discussion when you were away (I think) about this very issue, might want to check the archives.

Saktoth · Post by **Saktoth** » 08 Oct 2007, 01:07

I disagree with this. From a game design perspective, anything that can be automated in this fashion is generally beneath the player. We should not be forced to do repetitive, menial tasks that can be done much more efficiently by a computer. Micro is a valid part of a game, but it should be meaningful, not mind-numbing.

IMO, anything that can be handled in this fashion and is not, shows nothing more than a hole in the UI that deserves to be plugged, and a task that is obviously too simple for a player to have thrust upon him.

The same argument can be made for area reclaim. One of the reasons reclaim wasnt so bad in OTA was the fact that you had to reclaim every single thing manually (And the much longer unpack times but thats another issue). With area reclaim, sucking up massive wreck fields is now trivial.

While Metal Maker economies are a problem, but there are other ways to handle them than to require the player to to manage them manually. You might as well make a mod where all units are stuck on hold fire, and must be manually ordered to fire.

This is a lot like the debate over the 'Plan B' widget. Sure, it made com ends in team games virtually pointless, but all it really did was point out an already existing problem which could be exploited manually to exactly the same effect. If its a problem, it deserves a game-side solution (Like Lineage, which is sadly, broken in tasclient ATM).

Caydr wrote:Or a way to make constructors... ...attempt to reclaim their attacker based on the unit's name

A great idea for a widget, especially for nanotowers. People do this manually at the moment anyway, so if this is a problem, its obviously a balance issue with the mod.

Now, should the engine support this sort of thing? Sure. Starcraft, allegedly one of the best RTS's ever divised, had artificial squad limits and lots of manually triggered commands. Basically, it had UI limitations as a game feature (Indeed, many would claim thats what makes it 'great'). Spring should support that. However, i would strongly discourage modders from going the route of making their players do trivial tasks, as its more the MMORPG school of design and shouldnt be emulated.

Post by **jcnossen** » 08 Oct 2007, 01:31

We should not be forced to do repetitive, menial tasks that can be done much more efficiently by a computer. Micro is a valid part of a game, but it should be meaningful, not mind-numbing.

It's not your call to judge what a modder thinks is needed in his game IMO.. For the same reason you probably disagree with starcraft gameplay but it's a very popular game.

LordMatt · Post by **LordMatt** » 08 Oct 2007, 02:43

Saktoth wrote: The same argument can be made for area reclaim. One of the reasons reclaim wasnt so bad in OTA was the fact that you had to reclaim every single thing manually (And the much longer unpack times but thats another issue). With area reclaim, sucking up massive wreck fields is now trivial.

It would be nice if con units reclaimed whatever resource you had less % full of, instead of whatever is nearest. It's really annoying trying to use area reclaim in an area with trees and wrecks (I often end up queuing long reclaim queues in this case just to be sure the units are being efficient).

Also a metal maker AI is not cheating or dishonest for the reasons Saktoth mentioned, and also because managing metal makers is not really a very critical aspect of the game. A plan B widget was cheating IMO because that determines the most critical aspect of the game (when it's over for the player without player input), however a keybind shortcut that does the same thing, just not automatically, would not be cheating.

Erom · Post by **Erom** » 08 Oct 2007, 03:19

Maybe the metal maker wasn't cheating in *A, but that decision should be up to the mod maker, not the user.

stilicho · Post by **stilicho** » 08 Oct 2007, 05:38

So the next version of Spring will give hosts the ability to limit widgets?

What about GroupAIs? If I limit TheFatController's Metal Maker Widget in my game, what's to stop people from just assigning their mms to the the Metal Maker AI that comes with Spring? I'm assuming it's just as possible to write a "cheater" AI as it is a "cheater" widget.

smoth · Post by **smoth** » 08 Oct 2007, 05:40

We have already discussed this to a length that frankly made me sick. I believe you can find it in the lau forum caydr.

Personally, I think the mm manager stuff is good but that is me.

Post by **trepan** » 08 Oct 2007, 05:41

LuaUI can now be placed completely under the control of the mod:
http://spring.clan-sy.com/phpbb/viewtop ... highlight=

I don't really think that this is the best approach, but essentially, I don't care anymore.

smoth · Post by **smoth** » 08 Oct 2007, 05:44

can you explain a better approach trepan? I will try and do it if you wish.

Saktoth · Post by **Saktoth** » 08 Oct 2007, 06:46

jcnossen wrote:It's not your call to judge what a modder thinks is needed in his game IMO.. For the same reason you probably disagree with starcraft gameplay but it's a very popular game.

Precisely, which is why im saying that while spring should support it, i think its a very bad idea from a design perspective and Caydr shouldnt follow that route. Still, even starcraft didnt have anything as menial as toggling your Metal Makers every time you have a high e drain.

SwiftSpear · Post by **SwiftSpear** » 08 Oct 2007, 07:23

Saktoth wrote:You might as well make a mod where all units are stuck on hold fire, and must be manually ordered to fire.

It's called "comm shooter" and it would suck ass if there were a way to dodge this restriction.

Ideals regarding what a great game "should look like" have no place in engine development. If a mod restricts a behavior to a certain action by the player, or enforces that a certain action must be preformed with a certain method, that should be absolute. Not dodge able by the player via group AI or lua script.

Tell mods that they shouldn't be forcing players to do unnecessary micromanagement within the context of the mod, FINE. But that kind of thinking has no place in engine development. The engine must accommodate possibilities we have never considered as much as possible, and to make that work, the modder must have more authority than the player.

[edit] Ok, reading your second post, that's valid. I just wanted to ensure that there was no confusion regarding the difference between what is appropriate for engine design, and what is appropriate for game design. I think for MOST RTS based spring mods as few restrictions on lua and GAI as possible is healthy for the most part, because most of them are using features that can't be exploited by default with player GAI or LUA, the systems are mostly just used for customization.

Saktoth · Post by **Saktoth** » 08 Oct 2007, 10:43

Saktoth wrote:Now, should the engine support this sort of thing? Sure.

Saktoth wrote:Precisely, which is why im saying that while spring should support it, i think its a very bad idea from a design perspective and Caydr shouldnt follow that route.

Ive already agreed twice, i dont think i need to make a third post doing so.

Decimator · Post by **Decimator** » 08 Oct 2007, 18:27

More control in the hands of modders is a wonderful thing. However, I reserve my right to not play any mod that restricts metalmaker ai.

Hellspawn · Post by **Hellspawn** » 08 Oct 2007, 22:08

I find MMAI ok.

LUA automated other things as well, but they all currently look positive change to me.

CautionToTheWind · Post by **CautionToTheWind** » 08 Oct 2007, 23:09

And i think the horrible sound of metal makers turning on and off is more than enough punishment for the advantage it provides. It makes me develop a balanced economy so i dont hear them switch mode so often.

Spring RTS Engine

Metal Maker AI

Metal Maker AI