Print

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

[Toybasher]

Sneak preview: http://brage.info/~svein/console.png

It's not useful for much yet, but it does give you quick access to the gamelog/errorlog, at least. More later.

I see new stuff and I see matrixy stuff. Not sure whether to take you seriously or not..

Oh course its the secret Matrix mode that adds bullettime, weapons, and one hot dwarf called Urist McAnderson

[RAM]

Sneak preview: http://brage.info/~svein/console.png

It's not useful for much yet, but it does give you quick access to the gamelog/errorlog, at least. More later.

You really shouldn't leave your fisherdwarves so close to those crocodiles...

[Old-one-eye]

Can anyone else see the Lady in the Red Dress?

[Niveras]

That's not a dress, it's a floor-length beard.

And it's not a lady.

[G-Flex]

Sneak preview: http://brage.info/~svein/console.png

It's not useful for much yet, but it does give you quick access to the gamelog/errorlog, at least. More later.

I'm still extremely apprehensive about a Scheme console being integrated into the game (in case other info hasn't been mentioned, Baughn has been talking about wanting to implement a Scheme-based scripting console directly into the game).

There are arguments regarding the choice of scripting language itself, but that's not really my concern (there are other people, better educated than me in that matter, who could argue the point instead).


My concern is about allowing arbitrary scripting within the game itself. I'm aware that many games have this, including many I've played, but usually solely for debugging, cheating, testing, etc., never as something to be used as a gameplay mechanic.

Baughn has told me that much of the purpose of this scripting (aside from debug purposes) is to allow, say, better fortress automation, or otherwise for use as a gameplay tool.

But here's the thing. DF is already seen as somewhat impenetrable and elitist. There is a damn good chance that immediately after a feature like this is introduced, people would begin using it to compensate for shortcoming's in the game's interface. This might seem like a good thing on the surface, but I can nearly guarantee people new to the game (and some old) feeling a bit put-off by the seeming fact that they would have to learn an obscure scripting language in order to play the game to its fullest. We already have this situation with utilities like Dwarf Therapist to some degree, but those are 1) something you just download and run, requiring no particular skill on part of the user, and 2) not available by default, and as such do not necessarily reflect on the game itself as much.


If something like this were to be implemented, some assumptions would need to be met, and I'm not confident that they would be. Most importantly, the scripting system available in-game should not be able to do anything particularly gameplay-relevant that cannot be handled intuitively through the game's user interface. This might seem like a strange thing to say, but if this is not true, then you get the situation I mentioned above; the game does not need to come off as any more impenetrable than it does already, and players (especially newer ones) asking "Wait, so I need to learn how to program in order to tell my dwarves how to <insert some fairly intuitive task here, like changing crop planting patterns automatically every year, or changing military orders under certain conditions>?" would not be very good for the game's reputation. And you have to admit, they'd be completely justified.


This is the kind of thing that sounds like an amazing idea at first, and having a console for debug purposes is not a bad idea by any means, but the potential use of the scripting for gameplay/fortress-control purposes has some implications that need to be considered very, very carefully beforehand.

[Footkerchief]

Baughn has told me that much of the purpose of this scripting (aside from debug purposes) is to allow, say, better fortress automation, or otherwise for use as a gameplay tool.

I would be amazed if Toady actually exposed much of the game's guts to scripting.  I agree with your concerns completely, though.

[abadidea]

You mean I finally have to learn Lisp/Scheme?

But then what will I tell my old professor when he asks why I'm still a VIM user? 

[Baughn]

I don't think I stressed this enough, so -

You're not supposed to use the console in gameplay. The console is for modders, and there will be no interfaces added to it that don't have an equivalent non-console interface already.

Well. Admittedly it'd be possible to loop there, but that just makes it a nicer macro interface.

[G-Flex]

I don't think I stressed this enough, so -

You're not supposed to use the console in gameplay. The console is for modders

Its intent is honestly completely irrelevant. It doesn't matter what people are "supposed" to do with it. What matters is what they can do with it, and consequently what they will do with it.

, and there will be no interfaces added to it that don't have an equivalent non-console interface already.

Well. Admittedly it'd be possible to loop there, but that just makes it a nicer macro interface.

I honestly don't believe for a second that anything you could do via arbitrary Scheme scripting would have an equivalent method in the game's user interface. Even if most of the common cases are covered, there would still likely be huge gaps there.

[forsaken1111]

Yes, nobody cares what you think the console is for. What matters is what people can and will do with it.

[Psieye]

I don't think I stressed this enough, so -

You're not supposed to use the console in gameplay. The console is for modders

Its intent is honestly completely irrelevant. It doesn't matter what people are "supposed" to do with it. What matters is what they can do with it, and consequently what they will do with it.

, and there will be no interfaces added to it that don't have an equivalent non-console interface already.

Well. Admittedly it'd be possible to loop there, but that just makes it a nicer macro interface.

I honestly don't believe for a second that anything you could do via arbitrary Scheme scripting would have an equivalent method in the game's user interface. Even if most of the common cases are covered, there would still likely be huge gaps there.

And where exactly would those gaps be? Would the average player care? We're throwing around conjectures based on what? One screenshot showing nothing?

If you want this resolved, ask to see an exact Statement of Scope covering all the functionalities the console will do and more importantly, what it explicitly won't do. Before then, everyone's arguments will be unsynchronised as everyone will have a different concept of what 'console' actually will do. Unsynchronised arguments are fine if you just want to pass away time but you seem to want some relevant answers.

[VWSpeedRacer]

Unsynchronised arguments are fine if you just want to pass away time but you seem to want some relevant answers.

Unsynchronized console arguments in a release thread, however, perhaps not so fine?

[G-Flex]

And where exactly would those gaps be? Would the average player care? We're throwing around conjectures based on what? One screenshot showing nothing?

My "conjecture" is largely based on conversation with Baughn in #bay12games, not the screenshot. I thought I had mentioned that, but I guess I wasn't very specific. From what he was telling me, it would very easily serve as the backbone for, say, standing production orders (although these themselves would likely have a more intuitive UI representation), allow for debugging purposes, and, well, any number of other things. So yeah, it does have the sort of capability I'm speaking of.

The gaps would be... well, obvious. It would let you do things that you can't do using the game interface proper, which is pretty clear to me. After all, if it can handle standing orders for workshops, and is given fairly transparent access to such internal data, then there are clear implications regarding its utility for fortress automation in general.

The average player would care, I think, if he sees people playing the game more effectively than him (or doing things he cannot do) because they know how to futz around with a scripting language in-game and he doesn't.

If you want this resolved, ask to see an exact Statement of Scope covering all the functionalities the console will do and more importantly, what it explicitly won't do.

This is exactly why I'm bringing this up; I'm suggesting limitations to that scope, in one form or another. It also seemed apparently from my conversation with Baughn that he might not have considered these concerns yet.

[Footkerchief]

From what he was telling me, it would very easily serve as the backbone for, say, standing production orders (although these themselves would likely have a more intuitive UI representation), allow for debugging purposes, and, well, any number of other things. So yeah, it does have the sort of capability I'm speaking of.

The gaps would be... well, obvious. It would let you do things that you can't do using the game interface proper, which is pretty clear to me. After all, if it can handle standing orders for workshops, and is given fairly transparent access to such internal data, then there are clear implications regarding its utility for fortress automation in general.

Again, I would be amazed if Toady had exposed the game's internals to scripting.  I would be amazed if it were even feasible without a major overhaul.  Did Baughn talk about work done on Toady's end, or just about the theoretical possibilities of a console?

[G-Flex]

Baughn linked us to this e-mail he sent to Toady.

Also, here's a relevant log snippet, with the most relevant parts bolded by me:

[07/07/10 13:49:47][07/07/10 13:49:12] <G-Flex> production orders should be simple enough that any idiot can take near full advantage of them
[07/07/10 13:49:19] <smeding> yeah
[07/07/10 13:49:38] <veryinky> :|
[07/07/10 13:49:45] <G-Flex> I mean, to a reasonable degree
[07/07/10 13:49:47] <Baughn> More conditions will likely be added, later.
[07/07/10 13:49:50] <smeding> i just thought of implementing a silly wysiwyg kind of thing. instead of typing it, you add bits from a menu\
[07/07/10 13:49:56] <Baughn> So long as it's just production orders, you're probably right, but..
[07/07/10 13:50:01] <G-Flex> obviously you need to have at least 1/5 of a logic-brain to understand "make more booze if you have none but still have a bunch of plants"
[07/07/10 13:50:16] <G-Flex> smeding: yeah
[07/07/10 13:50:35] <Baughn> What about if you want to say "When there is an invasion, close these doors and pull these levers, set them back afterwards, activate these borrows, etc. etc."
[07/07/10 13:50:38] <BW> well, just the ability to have access to counts of basic items, and queue jobs based on simple numerical comparison would be awesome.
[07/07/10 13:50:49] <G-Flex> Baughn: that sounds like a job for alert states
[07/07/10 13:50:55] <Baughn> Obviously that wouldn't be /required/ to play the game, but it'd be awesome to have the capability
[07/07/10 13:51:10] <Kidiri> !
[07/07/10 13:51:12] <G-Flex> yes, but it should be simple enough to set up that anybody who understands what you just said should be able to set it up
[07/07/10 13:51:30] <Baughn> Sometimes.
[07/07/10 13:51:33] * ilikepie (~weechat@NewNet-97B37D71.cablep.bezeqint.net) has joined #bay12games
[07/07/10 13:51:46] <Baughn> The idea of having a programming language underneath is as a fallback; to catch the cases Toady /didn't/ think of.
[07/07/10 13:51:52] <Baughn> Yes, I know that's heresy.

So yes, it seems the idea is to allow a pretty decent amount of control and access.