I see 2 broad categories where scripting would be concerned: use in-game to enhance the playing of an existing or new fort and use for content generation. There is certainly demand for standing production orders and no matter how you look at it, that's "scripting" to some degree or other (the question is how much flexibility the players are given). I'm also seeing some fantasy ideal cases here of running some megascript to say, automate the first year of a new fort. From what I read of Toady's post, he feels DF is a game to be played, not a simulation engine to be run by a script - the 'game' part of the DF project description clashes with the very nature of standing production orders which require scripting to some extent or other.
It's my view that any scripting that directly influences the running of a fort should only be able to enhance the mid-late game aspect of Fortress Mode to free up the player to focus on the more interesting issues that don't arise in the early game. Maybe require the manager dwarf and ~40 population before it's available. In the early-mid game there isn't much for the player to do besides carve out the fortress and keep food/booze in stock so the player has plenty to do. Late game when nobles, guilds and sieges come into play, the player wants to focus on those issues and not the mundane "we need more booze" or "we're running low on bolts". Scripting would be designed to alleviate the player only at that point when more interesting issues come out. Maybe then, instead of an arbitrary population cap, the standing orders can be tied to the existence of guilds: handwave that the dwarves need guilds to get that organised. If a player has no programming skill whatsoever, standing orders are simple enough to understand that they can just copy/paste from a cookbook or from forum posts if the interface needs syntax care - simple IF ELSE statements are understood even by non-programmers as it's part of everyday logic in life. I have no comment at present about using scripting for improved machinery.
Seems that Toady's (and Baughn's) main thoughts with scripting is towards content generation. A special ability or magic artifact that does X, where X can be whatever the modder wants via scripting. Or a random creature Y, where the algorithm that chooses how to build Y is guided by the modder via scripting. These uses of scripting won't be of interest to casual players who just want to play the fort - they want to use what the modders cook up, but they're not interested in doing any modding themselves and hence, doing any content generation scripting themselves.
In which case why not expand or branch off the Arena mode we have right now? To test random creature physiology, let Arena mode spawn random creatures (e.g. "make me a random dragon as I wrote in the raw scripts"). To test special abilities/magic, have some sort of 'Testbed fort' - a 1x1 embark zone with limited z-levels and starting conditions (like number of dwarves at what skill) generated as dictated by a start-up script (just like how the terrain of Arena mode is read from a start-up file right now). Make console-scripting only available here in addition to Arena mode "spawn creature at will" where modders can pull up the console to try out various things to test their special ability/magic idea. Cripple this mode in whatever ways the scripting won't ever have to be concerned with, e.g. "this mode auto-terminates after 1 game-year" or "no trade goods" or whatever. Once they have tested out their idea, the modders would need a way to translate their console-scripting experiments onto raws in some way. Then they can let other players use those raws and casual players will thus get to play with advanced modding content without having to look at console-scripting ever.
Author
Topic: Dwarf Fortress 0.31.08 Released (Read 133591 times)