Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NW_Kohaku]

On Eternal Suggestion Voting.

OK, I'm now continuing my current theme of taking combining small gripes and requests for changes into a massive overhaul of a major game system so that the game can overall become more realistic and flexible and immersive.  Today's topic: Finding ways to have a little more control over those little buggers, while at the same time not having to micromanage them so darn much.

In a sense, this is a combination of two other suggestions.  The current second most popular suggestion on the ESV is the Standing Orders mod.  There is another set of suggestions that appears frequently on the boards for requesting meddling in the priorities that dwarves set for completing various jobs, often jobs like meeting with traders.

In another sense, however, this idea also stems a bit from playing games like Final Fantasy XII or Dragon Age, where you can rely upon relatively accessable player-editable scripts to make the micromanagement of your troops a much more simple affair.

I would like to have a system whereby we can create an AI script for your fortress to follow.  Preferably in an external utility, such as a text file, which can be imported, (or at least have an export/import saved script system) so that we players have the ability to transfer these scripts between games, creating complex scripts that will serve them at all stages throughout the life of a fortress.

This would also be the "Noob-friendly" aspect of this: Experienced players can upload general-purpose scripts to suppliment the one or two scripts that Toady would likely make part of the vanilla package, and the already-existant "Noob Pack" mods that include setting up init options and installing graphics packs can now also download a variety of "most commonly useful scripts" so that they don't have to muck around in the details.

Of course, if we are doing this by inputting .txt files, there will need to be a routine upon loading a script to scrub any commands that are invalid due to syntax errors, which, in turn, means it needs to have a means of reporting said errors (with at least an in-game pop-up message, not an invisible export to an errorlog.txt that players may not know to check) so that players aren't simply confused by why nothing seems to be working.


At its most basic, this should be a way of prioritizing what labors a dwarf should complete first.  Gone will be the complaints of dwarves set to meet with diplomats or caravans ignoring that in favor of making some barrels instead or cleaning up some mud stains because you forgot to turn off every other possible labor the dwarf might want to prefer over the one you set for it.

The script can basically just be an ordered list of actions that the dwarves will take, arranged by their priority.  This is, most likely, what we already have in the game in a hardcoded fashion, so I wouldn't expect making this part scriptable would be terrifically difficult.

The scripting, as I said, should be a combination of the "Standing Production Orders" scripting and a related Dwarven individual AI script.  The Standing Production Orders already, as described in the ESV, has implied that it can use variables that draw information out of sources like the stocks screen to figure when to add new jobs to job queues, as well as using boolean and comparative logic operations.

This would allow you to say that you would want some job, like, say, brewing, to be a higher priority job than, say, carpentry under normal conditions, however, when "EMPTY_BARREL < 4", then carpentry would be thrust up as a higher priority so that they would temporarily attempt to go out making more barrels first, and you could potentially put a "WOOD < 2" task to go woodcutting in along with it, to help dwarves always be part of trying to solve supply-chain problems, rather than simply quitting when they run out of materials, and generating job cancellation spam.

Another potential use for this would be, again, with the problems people have with dwarves needing to meet with diplomats or the like running off to eat and then sleep and then drink before meeting.  You could have priorities set to voluntarily send a dwarf off to eat before he is seriously hungry under certain conditions.  Thus, they would consider eating when their hunger meter is more than half full (probably best to measure these things percentage-wise, or with some sort of set, text-descriptive level, where "peckish" means half-hungry) more important than most normal functions, but then consider meeting with diplomats more important than food until it hits the critical point where dwarves will always consider their hunger the most important thing to them.


While this could be used with just the fairly basic steps above and make a wonderful addition to the game, I believe that it could be potentially used to greatly expand certain game mechanics. 

Consider, if you will, a "powergoal" of having a dwarven combat medic.  Not a real combatant, just a dwarf who is set to follow a squad, generally keeping out of danger, until a soldier dwarf becomes critically injured.  The medic could then try to rush in (hopefully with some script from the other soldiers to try to provoke the agressor onto themselves) and drag the wounded dwarf to a triage center.  There, dwarven medics could have scriptable priorities over what maladies (or important persons, such as champions and legendaries) to treat first.

This would require the ability to script in the ability to either be a part of a squad without actually being a "soldier" (which requires intigration with the military interface), or the ability to use in the scripting language a way to simply select squads to follow by number with a "when activated", having some control over whether or not dwarves run from enemies by default, or charge to their destinations regardless, having a "follow X tiles behind" syntax, and syntax for recognizing statuses of other dwarves (such as noticing when they are poisoned, unconscious, have significant wounds to specific locations, or other problems), a "taunt enemy" command, and a command to be able to haul injured dwarves to treatment, although that is already an extension of what doctors do, anyway, and perhaps something I am not noticing right now.

Doing even more in conjunction with the military interface (which might benefit from scripting and import/export abilities, like haivng the ability to import and export uniform data or training schedules, so that the scripting can be less time-consuming), we might even be able to finally get some manner of control over military tactics.  Instead of charging enemies, we might have the ability to set up certain dwarves to be "wingmen" who stay in a certain formation (2 tiles to the left side of the squad leader's facing) until battle is met, who will not rush out to engage until fellow warriors are amassed, who will disengage on anything besides death or fear, so that they do not fight even past being tired and wounded and dying of thirst against creatures like Bronze Collosi that refuse to die.

By extension, we could also make dwarves automatically enter and exit burrows depending on certain conditions, such as making woodcutters no longer be allowed in their "outside" burrows when seiges take place.  (Like with squads, for this to happen in scripts that have no direct access to game data, you would need to have some ability to designate burrows by number, or the ability to make a custom string on burrows that scripts can do a search for.) We can then automate the process, so that the barrelmaker that is scripted to start cutting wood when it runs out will suddenly be changed from a burrow that includes only his workplace, living quarters, and other general public areas could then be put into a burrow that includes areas to chop wood, and then a script line puts them back to their original burrow when the lack of wood case is no longer true.


EDIT:  Addendum that I forgot in first posting:  I have been considering including in this the ability to let the scripts automatically change labor settings, as well. 

On the "pros" side, it would give more power to the player who could set up more sophisticated scripts because of it, and giving players options they don't have to use is never really a bad thing.

However, n one sense, you could use the previous scripting and just not give a job any priority at all except under special conditions, which would effectively replicate the labor being disabled, anyway.  Making scripts change labors could also lead to players trying to struggle against their own scripts if they need to make more dynamic changes (although simply switching to a different script would be a better solution to that).

[existent]

As good as all this is, I honestly don't see it as something I would ever personally use (except MAYBE the standing orders).

[tfaal]

Standing orders and job priorities I would use. Everything else falls into my personal "too complicated" category. In addition to my personal dislike of it, improving control of dwarves by a method this complex might be shooting ourselves in the foot when it comes to new players. If you have to write or download a script to make your dudes do what you want, especially when it's something reasonably simple, then you've got some serious UI problems.

[NW_Kohaku]

Actually, there was something else I forgot to mention in the first post, I'll just edit it in, though...

Standing orders and job priorities I would use. Everything else falls into my personal "too complicated" category. In addition to my personal dislike of it, improving control of dwarves by a method this complex might be shooting ourselves in the foot when it comes to new players. If you have to write or download a script to make your dudes do what you want, especially when it's something reasonably simple, then you've got some serious UI problems.

Full manual control is always going to be there, of course, but let me tell you, when you have the option to automate the tedius parts of manually altering labors or manually altering who is in what burrow just to achieve small, minor things, you will both use it and love it and refuse to play again wtihout it.

For the newbies, downloading scripts would be as easy as downloading the bundled packages of graphics packs and other sundry mods that many newbies already download and play with without ever playing in the original pseudo-ASCII tileset, and, if kept relatively generalized, would never need to be tweaked until they actually wanted to start using it.

Besides, scripting priorities is hardly the sort of stuff that is so terribly complex few people would ever use it... Again, the Final Fantasy series, which is not known for making anything terribly complex, was capable of basically automating everything you would want to do in combat to the point where you could walk away from combat secure in the knowledge that you were going to win in FF 12.  If it's the sort of thing that is not considered so off-putting to newbies that games like Final Fantasy are doing it, then you can be assured that the DF crowd is capable of handling a little scripting.

[marcusbjol]

I am not sure how this would be much better than the standing production orders combined with improved unit control.

Unit control in combat is one of the things we have that is lacking.  We basically have move or stay orders  (patrol is a combination of move orders) and they are auto engage on all enemies within a certain radius.  So we are controlling.... berserkers.  By which I mean we have no control on how to tell them to stop attacking and run away (other than deactivate the squad). 

The station command should force them to stay where they are.  If I have them assigned to guarding a bridge, I want them to stand on that bridge until I tell them to move.  No I do not want them charging to engage the nearest enemy, as that might pull them out of position to guard the bridge and enemies might get through.

Add in auto alert level changing for the civvies when sieges/ambushes happen, and you have 95% of what is being looked for at 20% of the effort. 

With that level of automation, the simulation (DF) can be run without the user, and where is the game in that?

[NW_Kohaku]

I am not sure how this would be much better than the standing production orders combined with improved unit control.

Unit control in combat is one of the things we have that is lacking.  We basically have move or stay orders  (patrol is a combination of move orders) and they are auto engage on all enemies within a certain radius.  So we are controlling.... berserkers.  By which I mean we have no control on how to tell them to stop attacking and run away (other than deactivate the squad). 

The station command should force them to stay where they are.  If I have them assigned to guarding a bridge, I want them to stand on that bridge until I tell them to move.  No I do not want them charging to engage the nearest enemy, as that might pull them out of position to guard the bridge and enemies might get through.

Add in auto alert level changing for the civvies when sieges/ambushes happen, and you have 95% of what is being looked for at 20% of the effort. 

With that level of automation, the simulation (DF) can be run without the user, and where is the game in that?

I would say that many people specifically try to aim for automating their entire fortress.

The game is in building the system, as it always has.  You can't honestly say that the part of DF that you most enjoy is the part where you look through screens to see what animals you want to slaughter, track through who has what labors enabled, or track through what jobs were cancelled because of supply hiccups, can you?

This lets you refocus upon designing the fortress itself. 

Frankly, I'm astounded that so far, nobody seems to see how fantastic scripting is.  This forum or the DF General Discussion is usually flooded with complaints over how upset players are with how "stupid" dwarves behave... but when you see a suggestion that proposes to give you, yourself the tools to dynamically fix the problem, you complain that you wouldn't want to use it?

[existent]

Frankly, I'm astounded that so far, nobody seems to see how fantastic scripting is.  This forum or the DF General Discussion is usually flooded with complaints over how upset players are with how "stupid" dwarves behave... but when you see a suggestion that proposes to give you, yourself the tools to dynamically fix the problem, you complain that you wouldn't want to use it?

Frankly, it would just slip through into that category of stuff I never use, which also includes dyer's workshops, traffic designations, the burrow system, and Bic pens.

[marcusbjol]

I would say that many people specifically try to aim for automating their entire fortress.

So the game will devolve into who is the better scripter?

The game is in building the system, as it always has.  You can't honestly say that the part of DF that you most enjoy is the part where you look through screens to see what animals you want to slaughter, track through who has what labors enabled, or track through what jobs were cancelled because of supply hiccups, can you?

Not at all.  But standing orders will take care of that without a scripting interface.

This lets you refocus upon designing the fortress itself. 

Frankly, I'm astounded that so far, nobody seems to see how fantastic scripting is.  This forum or the DF General Discussion is usually flooded with complaints over how upset players are with how "stupid" dwarves behave... but when you see a suggestion that proposes to give you, yourself the tools to dynamically fix the problem, you complain that you wouldn't want to use it?

Its more about how much time Toady has to make the game.  If 90% of what was mentioned is on the drawing board already covers what is wanted and can be accomplished in 10% of the time, that is what will get done.

Yes, scripting is powerful, and time consuming to implement.  The games mentioned have teams of people working on it, not 1.  Its a language Toady has to support, and ultimately, if he doesnt see value in it, it wont get done. 

[G-Flex]

I've argued against this kind of thing before and won't rehash too much of it, but I will say this:

Anything about this that players in general would find useful should never be limited to custom scripting. Stuff like that should not be outsourced to modders/players. DF is user-unfriendly enough without new features being implemented in the most brainfuckingly impenetrable manner possible.


DF needs standing orders, workshop/fortress automation, and that kind of thing. It also needs those things to be accessible to the player. They need to be intuitive, and this doesn't fit the bill.

[NW_Kohaku]

So the game will devolve into who is the better scripter?

Since when was DF a competition with other players? 

By that token, why hasn't the game devolved into "whoever can mod in reactions to give themselves infinite adamantine"?

Not at all.  But standing orders will take care of that without a scripting interface.

Standing orders IS a scripting interface.  This is simply suggesting that a similar scripting interface be used on individual dwarves.

Its more about how much time Toady has to make the game.  If 90% of what was mentioned is on the drawing board already covers what is wanted and can be accomplished in 10% of the time, that is what will get done.

Which is the same silly argument that can be (and has been) made against every single suggestion.  Really, it's just shorthand for "I don't like it, but can't give a good reason."

Yes, scripting is powerful, and time consuming to implement.  The games mentioned have teams of people working on it, not 1.  Its a language Toady has to support, and ultimately, if he doesnt see value in it, it wont get done.

An argument that falls down when, again, a scripting language is already planned for being supported in the game in the form of the standing orders system.  It would give more power to players when much of this is already a sunk cost.

Anything about this that players in general would find useful should never be limited to custom scripting. Stuff like that should not be outsourced to modders/players. DF is user-unfriendly enough without new features being implemented in the most brainfuckingly impenetrable manner possible.

DF needs standing orders, workshop/fortress automation, and that kind of thing. It also needs those things to be accessible to the player. They need to be intuitive, and this doesn't fit the bill.

Should we then take out mechanics, because mechanical devices are too complex or obtuse for most players to use? 

Priority scripting is hardly overly complex.  I went further and suggested more complex things to give more power to the players who really want to use it, but you can always just use priority scripting, possibly with simple booleans.

Really, systems like mechanics and fluids are the highlights of this game - they are the things that aren't necessary for players to build a proper fortress, but offer the flexibility and scripting power to give the players willing to take the time to understand and properly use them.

[existent]

While I've made my lack of interest clear, I feel for the sake of argument, I must direct attention over here:

http://df.magmawiki.com/index.php/DF2010:Computing

Now, that's the DEFINITION of complex, useless, and anything else that's been said in here so far, and people do THAT, so the only argument I see is Toady's time and effort vs places people might feel it would be better spent.

[G-Flex]

Priority scripting is hardly overly complex.  I went further and suggested more complex things to give more power to the players who really want to use it, but you can always just use priority scripting, possibly with simple booleans.

How difficult it is depends on how it's set up. If you tell them "here's javascript/scheme/whatever, go nuts", that's not intuitive no matter how simple the script itself would be. It boils down to how it's presented to the user, and how intuitive the tools are.

[NW_Kohaku]

While I've made my lack of interest clear, I feel for the sake of argument, I must direct attention over here:

http://df.magmawiki.com/index.php/DF2010:Computing

Now, that's the DEFINITION of complex, useless, and anything else that's been said in here so far, and people do THAT, so the only argument I see is Toady's time and effort vs places people might feel it would be better spent.

You mean the definition of one of the crowning achievements of what can be accomplished with DF, right?

It allows people to use the game in extremely powerful ways, and allows people to truly enjoy the sandbox complexity of the game, all by only using some fairly simple machines that are nowhere near as complex or difficult for Toady to program as the aggregation of many of these niggling little suggestions that should really be solved by giving the players the power to solve their own problems.

How difficult it is depends on how it's set up. If you tell them "here's javascript/scheme/whatever, go nuts", that's not intuitive no matter how simple the script itself would be. It boils down to how it's presented to the user, and how intuitive the tools are.

Honestly, the most I hope to get from Toady is a .txt file to work with, instead of something like the military interface.

If everything can come from a .txt file that is importable/exportable, players can make third-party utilities that would add actual GUI options to the scripting, like just being able to drag-and-drop certain script lines up and down the list to change priorities. Potentially, if someone wants to really go out of their way to make user-friendly interfaces, even make script lines out of drag-and-drop fill-in-the-blank lines that you can put specific labors or variables into the blanks, and make even the complex stuff fairly simple.

[existent]

While I've made my lack of interest clear, I feel for the sake of argument, I must direct attention over here:

http://df.magmawiki.com/index.php/DF2010:Computing

Now, that's the DEFINITION of complex, useless, and anything else that's been said in here so far, and people do THAT, so the only argument I see is Toady's time and effort vs places people might feel it would be better spent.

You mean the definition of one of the crowning achievements of what can be accomplished with DF, right?

It allows people to use the game in extremely powerful ways, and allows people to truly enjoy the sandbox complexity of the game, all by only using some fairly simple machines that are nowhere near as complex or difficult for Toady to program as the aggregation of many of these niggling little suggestions that should really be solved by giving the players the power to solve their own problems.=

Yes. My point is, I agree with what you're saying as to WHY a scripting system would be nice, even if I wouldn't use it myself. the only REAL argument here is whether Toady should do your thing, or spend his time on something other people want more.

Again, though, I don't really care. As long as it's just there to enhance, and not replace- IE, as long as I can do without it if I choose to (which you've said would be the case) I'd be fine with it. It's really a non-issue to me.

As far as I'm concerned, DF 0.31.10 is done. The game is finished. It has no bugs that I really notice during the game, and I enjoy playing, especially in conjunction with the online community (succession games, and what have you.)

Anything that's done AFTER 31.10 is, to me, like an expansion pack. Bonus features, if you will. Am I excited about new features? Why, of course. But I consider them dessert, not the main course. I don't feel like Toady is obligated to put them in, even if it would (will) be awesome when he does. That's basically how I feel about scripting as well- might be nice, but I'd be happy to play without it.

[G-Flex]

As far as I'm concerned, DF 0.31.10 is done. The game is finished. It has no bugs that I really notice during the game

In other words, all you care about is your own anecdotal opinion and not, say, reality. There are plenty of outstanding bugs and issues in 0.31.10.

Anything that's done AFTER 31.10 is, to me, like an expansion pack. Bonus features, if you will. Am I excited about new features? Why, of course. But I consider them dessert, not the main course. I don't feel like Toady is obligated to put them in, even if it would (will) be awesome when he does. That's basically how I feel about scripting as well- might be nice, but I'd be happy to play without it.

You're showing an extreme amount of ignorance here in your claim that, since you can currently enjoy the game, it must be a finished product. I enjoy licking cake batter out of the bowl, but that doesn't mean I'm not going to actually bake the stuff.