demagogue

I get the feeling you guys should be testing this out in the field more and then be citing field reports rather than speculating (maybe you are). The T2 FM that immediately comes to my mind when thinking about 1-shot seriously wound/kill arrows is Midday Escape. And if you read the players reports on it, there was a lot of frustration on the fact that 1 arrow could stop a run in its tracks, forcing you to repeat running past them play after play so it turns into more like a reflex game (at least for that area) than plotting how to sneak by an obstacle like how I normally think the classic gameplay should be. Also, reports were that it was hard to be sure one was completely clear of an archer's line of sight until you were basically maimed/killed by the first (otherwise "warning") arrow ... although granted the draconian design contributed to the frustration; but, then again, 1-shot kill arrows might encourage that kind of draconian design. And in response, authors might just start using less archerers and so the gameworld is simply diminished. Anyway, I haven't thought enough about it to have a strong opinion, but thinking in terms of how the flow of gameplay is affected by these sorts of mechanics using the actual experience of real gameplay is what I wish there was more going on here.

I wouldn't be so bitter about it ... to me they were just joking around, and even then mostly about Slash's free use of the term "official", not really about anything he was going to make per se. Also, I think TDM's quality will largely be able to speak for itself ... It's not like the team is going to be policing what can and can't be made with it. Dromed never got a wiff of LGS support and the Editor's Guild is notorious for attacking the latest mega-projects; doesn't seem to make T2 FM-making any less popular. And even if some guys do appear to attack some projects with a roll of their eyes, sometimes mega-visions should be chastized a little to force the creators to defend them or at least think realistically about them. If Slash thinks what they said was unfair, he can try to convince them otherwise. Anyway, this thread looks exactly like the one in the Off Topic forum, so my answer will be the same: http://forums.thedarkmod.com/index.php?s=&sh...indpost&p=61672

I don't know why I need to bother, but just to respond to ZB: substitute "being able to see a guard charge you" with "being able to watch a guard make his patrol in the distance" ... So while you're in a still position reading anyway, it wouldn't hurt to have the ability to do a little multi-tasking and already have an eye on foward-areas that you'll negotiate next to plan your next moves, and a clear view helps. Or to put it more generally: T1/T2 style readables were so noticible (notorious) for the *dead* time they created ... If TDM is going to liven that time up, they may as well run with the idea and make it really worth something.

Yeah, for aesthetic reasons I could see how a slight softening of the background would look good. It would really make the readable stand out and just add a veneer to the whole setup, like special thought was put into the look and feel of it. The main catch I guess is that things are still going on in real-time and it would be helpful to see that an AI was charging you and not have your attention blunted by the effect, particularly when put in such a vulnerable position (cf. the SS2 or DX inventory screens). So my thinking is that these sorts of considerations simply outweigh whatever advantages the soft blurring might add... not that it's a bad idea in itself; I can actually see the merit of it, but given competing goals this one should take priority.

Just to complete my thought, and then I'll shut up about it (Sorry about length. If you read nothing else, read the last paragraph about my suggestion if back-picking is to be done): I've thought more about this back-picking possibility and think my primary gripe with it is the following. Authors often want to make pick-opening a lock a more-or-less long, tedious process, modulating the difficulty to build tension or whatever. But back-picking a lock to locked wouldn't make sense unless it were relatively quick. If it were long and tedious, then who would ever want to use it because you mainly use it to lock an AI inside, which will normally be in motion, so players would want the interface to let him act quickly or they'd be legitimately annoyed if they couldn't. The alternative is it would tempt people to start back-picking and they'd have to stop. You'll very likely get a volley of annoyed comments (if asked about it, anyway) saying "why won't you speed up the back-picking so I can actually use it when I need it??!!11" (By the way, an aside, what happens to a half-back-picked lock? A half-picked lock remains unlocked until it's fully picked, and that makes sense. But does a half-back-picked lock remain unlocked until it's fully back-picked? And you can come back to complete the back-pick later?? And what about a half re-picked lock after back-picking? Issues may vary depending on the answer to these questions; generally it would lead to cases of half back-picked locks ambiguously lying around, but all this is an aside to the general grumbling slow back-picking would create in any event.) So I'm thinking that there will be pressure to speed up the process in the face of a bunch of grumbling if it isn't, the alternative being a persistent feeling that the function is just frustratingly off if it's left slow, or at best the feeling that it's just irrelevant to normal gameplay because it's so slow. But the *real* problem I'm thinking about is what happens if back-picking should be made to be relatively quick to cater to the legitimate desires of players, that is, to make sense in implementing it in the first place. That will tempt players to quickly back-pick a lock to get out of a sticky situation only to discover that it's a long and tedious process to re-pick the door unlocked when they need to get in there. Generally speaking, I frown on gameplay features that seduce the PC into making on-the-fly decisions that make his life particularly troublesome later on. It isn't irreversible, of course, but it sure is a pain to have to spend another minute to re-pick a lock after the 10 second on-the-fly decision to back-pick it locked (esp if it's a central part of the author's design to make that lock difficult enough to take a minute to pick for whatever reason). You might answer that PC's should just keep that in mind before they start back-picking, but I don't like that answer when it involves the sort of on-the-fly, half thought out decision which is almost always going to be involved with back-picking in the first place: trap this moving AI in this room. It's an invitation to later frustration. But the key point I'd make here is that this situation will occur essentially *every* time a lock is back-picked. It's much different than the half-second decision to re-lock a door which only involves another half-second decision to re-unlock it. So whether the back-picking is fast or slow (the only 2 options you have), either way it's an invitation to legitimate gripes of annoyance or frustration for players, or a feeling that it's just irrelevant to their gameplay (in a way that key-relocking isn't), so not worth the trouble to implement it. So, like I said before, it just rubs me the wrong way. At least some real thought should go into these issues before thinking about doing it. For example, maybe once a lock if fully picked as tediously as the author intended, *then* both back-picking and re-picking would be relatively quick, or maybe even automatically like a key (to stay away from the trouble of half back-picked and re-picked locks)... Then you have for all practical purposes transformed the lockpicks into a key or key-like once the door is fully picked the first time. It's not greatly intuitive, but that would probably be the best way to do it if it's done at all, IMO. Actually, the only real gripe I'd have about this way is that it's unintuitive and might just look odd (you can imagine someone asking: why does picking a lock take 1 minute the first time and 1 second the next?), but at least it avoids the above pitfalls.

I've been long thinking about adapting some classic IF adventures into Thief FMs ... they'd work even better in TDM. The best one, the one I want to do the most, would be Magnetic Scroll's *Guild of Thieves*, which fits the thief world to a T. It has everything you'd ever want in a medievalesque burglary FM, and all the readables, back-story and logical progression, all well designed I thought, is already mapped out for me! Aside from this one, I wanted to do an adaptation of The Pawn (I just liked the world it was in) or what would really work well is Anchorhead, which is a very Lovecraftian, dark horrorish piece that, as an interactive game, is brilliantly plotted, scripted and logically worked out (what distinguishes IF from normal fiction) ... It reminded me a lot of Rowena's Curse in its logical flow, where the plot progresses/unfolds as you solve key puzzles/events (or Ominous Bequest, although less so) & I like that style, but more than that: the atmosphere/ environment/ setting is absolutely lush: overcast, rainy, foggy, dark forested, victorian archetecture and furniture (although there are some modern objects as well). Finally, I was thinking about trying to adapt some more serious literary works just to start raising the bar on the possibilities with FMs, so e.g., Camus's The Plague, with the PC as the character trying to do anything to escape the arabesque, Meditteranean quarantined city, while at the same time dealing with more serious themes about mortality and religion (without being preachy).

Maybe this is answered somewhere and I missed it, but I thought of a concern. Will you still support text written unmediated directly on the screen, e.g., plaque style. It's just so useful to have that sometimes, since it allows meta-messages in-game, you can break up a game into *chapters* with it (like Willow Island) or cueing stuff like new objectives or adding information about world-objects (e.g., you frob a book and it tells you the pages are all blank, rather than writing that in brackets in the pages itself), you can run credits like Deceptive Perceptions, subtitle dialogue or make it easy for builders to drop voice-acting altogether and throw in subtitled dialogue on-the-cheap (Emilie Victor)... I mean, there are so many cases when this kind of text comes in handy that I hope TDP will still support it on top of this. Also, thinking about things like Deceptive Perceptions, how will you handle post-frobbed cued events by a book if it's in real time? Usually, you'd think you'd want to give the player time to read the text before the *event* hits, esp when it's a shocker or time sensitive. I can think of lots of examples of this...

Actually, when I think of a locked state having a visual cue with a round knob, it's of a horizontal knob below it either vertical or horizontal depending on the lock status ... but maybe that's anachronistic. After 1/2 a second of reflection: actually, what am I saying?! That's essentialy a hand lock which you can lock/unlock just by turning ... so obviously a stupid idea from the outside of a door if the whole point is you need to pick it or find a key. Then again, now I wonder if it still couldn't be implemented on 1 side of a door for some rooms, that might be cool. Although then it's maybe more work to make than it's worth. Now I can see the sorts of things T1 developers were thinking when they thought of using the knob-orientation as the cue. By the way, in most post above, I had in mind my sometimes-practice of just leaving my picks readied for use on any door, and the first thing I'd do when I reached a new door I'd use them right away and use the click as the cue it's unlocked, not even really paying attention to the knob. I suppose my practice would just change under a new system. It just generally rubs me the wrong way I guess.

Whatever the actual mechanics of it are, I never thought of relocking doors with lockpics as general gameplay knowledge. I'd use keys for that, but it wouldn't occur to me to use picks, even if I pick-unlocked the door; it's not a general expectation, right or wrong. Maybe you can argue this is just because using the pick on an unlocked door would immediately give the *can't do it* click and I quickly learned from that, and if it an unlocked door started picking I'd learn from it and have the expectation that picks can lock doors... which raises another issue by the way (a quick aside): What if a person begins "picking" a door, taking the beginning of the process as the obvious cue that it needs to be picked, and completes the task only to realize that he's just picked it *locked* and it was unlocked all the while! For a lot of people expecting (even if by "unfair past experience") picks only lock doors, it would come as a rude shock. For the key, people might pay more attention to what's been locked & unlocked with the key (they're usually for 1 door), but even then you could imagine making the occasional mistake and accidentally locking an unlocked door, but they're still able to quickly remedy the situation. But for a 45 second pick-sequence it could lead to big trouble, and it doesn't make as much sense to toy with players' expectations like that and leave the possibility even open. Also, an important thing to keep in mind, I have an idea that a lot of authors won't have it in their mind that lockpicks can lock doors either, and so having it as a default possibility will screw with their mission planning and their own balancing because of wrong expectations in making decisions about what doors should only have keys, what doors have keys & are pickable, and what doors are only pickable (no keys). So even if it's possible to add, I wouldn't like to see it as a default feature. I mean, it's not the most critical feature in the world one way or another ... I didn't know in Thief you could bash wooden doors in with the sword for a long time, but after I did know that it actually didn't make that big a difference except opened up a few new possibilities here and there. So I wouldn't be mortally appalled at the idea and could happily live with it. I just have the intuition that locking doors with picks might be trouble because it plays against players' general expectations in a way that could be troublesome. My 2 cents on it.

It's a nascent FM project for the dark mod when it comes out, or it *was*. Not being on TTLG, you missed all the action: clicky The project is apparently dead now - not that that's so surprising - but it was incredibly quick given all the heat they stirred up: The boards kind of got a reputation for soliciting anything cool from anyone and trying to throw it in, and for trying to do TDM's work for them. It didn't try very hard to command much respect; and the openness of it did NOT help ... but whatever. It just wasn't a well-defined project. I don't blame people for wanting to get a jump on mapping TDM FMs, though.

I love those readables you posted today! Do you want to talk about how they function? (I might wade thru a search to find out, but since I'm congratulating the team, anyway, didn't think it would hurt to provoke a little elaboration...) Is it easy to get custom material, fonts, pictures, maps, etc., in them? And the way they are displayed in your screenshot it's as if the engine were actually rendering the readable-info ... but it's probably more likely just a skin for an object custom made to match, is that right? (also, after just making a candle in T2 yesterday I'd dream to have a flame like that...) Anyway, kudoos.

There's an interesting discussion going on in the SS2 forum at TTLG about moving SS2 assets over to Thief-dromed to make SS2-type FMs in Thief (this will be relevant, don't worry...). The main punchline of the discussion is that classic-SS2 FMs virtually *never* get made because they have RPG elements; and there are so many Thief FMs precisely because they are not RPG, but limited, discrete, one-shot type missions. Having stats, improvable/upgradable skills, etc, all the RPG elements you see in DX and SS2 require epic campaigns to even be relevant ... and the lion's share of TDM FMs won't (or shouldn't) be like that, nor should authors feel pressured to make epic style FMs (and I mean really big; think about it) because so many RPG elements are part of the basic interface. A lot of authors won't want to bother (they'd rather make the more discrete mission, particularly novices, which everyone will be at one point; and getting new authors to *want* to build with TDM is essential to keeping TDM FMs continuing to be made), and those that do try will waste years making 1 probably incomplete FM when they could have made 3+ complete non-RPG FMs in the same time. That's the best argument I see against having any RPG elements in TDM, and comparing the number of DX & SS2 FMs vs. Thief FMs (not just for that reason, but that's a big reason), is the best evidence. ps, I should say I loved both SS2 and DX, and I loved their RPG elements ... so it's not because of any intrinsic dislike of RPGs that I'm saying this. I just don't think it's conducive to FM-making; it'd do much more harm than good IMHO.

I liked burricks... something about them. There in the shadows Of my fading memory, A lonely burrick.

Yeah, funny as hell ... I should have added that but was being rushed in that post, which I find always makes me sound more serious than I really am... I remember doing something like this in anticipation (or anxiety) of just how bad Thief III might be (3 of us in a row, keeping it going): http://www.ttlg.com/forums/showthread.php?...6828#post796828 And yeah, nat'l language parsers have so far to go. I still hope you guys think about some menu-based NPC-interaction system, though, or at least put it on the back-burner. (& I'll maybe deal with how I might set up my own idea myself after release if I still feel like it ... now that I have an idea of how it might even be possible. Crackpot as it admittedly is; when you've played around with parsers and IF stuff long enough, like any programming, it just becomes 2nd-nature to think about, and since I'm only in this FM biz for my own kicks, I thought it couldn't hurt to ask what's possible for me to do myself when the time comes). More OT, I find it (maybe ironically) reassuring that stupid topics like this are up in the thread queue (even if it is my own topic) ... It gives the impression that you've pretty much got all the basics under control and it's just a matter of time getting it all together. (.")-b

Well, for the record, I was really just interested in NPC interaction. The rest of it I agree is better off using other control methods, of course, and don't really care about. So I spent a lot of time in university studying AI ... but I was most interested in parsers and natural language. And we were doing some pretty exciting stuff that I knew would sooner or later make it into games ... I mean, pretty sophisticated AI comprehension, goal orientated responses, etc. It's one thing to say that using text as a control for movement or object manipulation is absurd ... it is I agree. But for NPC interaction, that's where open textured language might really shine. And I don't think any game has seen the state of the art on it ... Don't get me wrong, I think menu-based interaction is the best way to go design-wise and for all practical purposes, and like someone said, you don't want to be fighting the console. My motives for suggesting it in the Dark Mod were pretty much entirely selfish in that I wanted to keep working on a game-oriented NPC parser that I'm already playing with anyway, but in the context of a game I really like, where I can care about the characters. It wouldn't be good as a default feature - honestly, natural language parsers aren't there yet. I just wanted to know if it'd be easy for me to rig for my own kicks. That's it. And nothing really like the examples you guys rightfully poked fun at.

That's good news, and makes it sound pretty straightforward to implement by an FM-maker (or someone releasing a generic script later on FM makers can build off of) without any extra work on you guys' part in development. That's a really great thing and I hope something that FM makers start using ... it was definately part of DX's magic. I still wish that I could get a functioning text-prompt in-game... (This is now my own, out-of-play meta-comment ) I've long had this dream that fps's and IF could be somehow integrated. And if you think about it, there are really just two main missing links (that I can think of), since most kinds of movement and most kinds of basic object manipulation are already in FPSs ... 1) is open NPC interaction. 2) is maybe non-standard (open) object manipulation, using objects in non-intuitive, novel ways. Frobbing an object, or an object to another object, is a pretty blunt instrument, but then again a good designer can do a lot with just that, as I've seen in many a creative T2 FM. And adding much more complexity only marginally opens up the kinds of interactions you can have for the trouble. 3) Edit, maybe three. Also, there's non-standard (open) player movements like lying down, sitting down, dancing ... again, interesting, but only marginally so for most games, esp given the trouble it'd probably cause. But NPC interactions, and in particular *open* NPC interactions, seems almost fundamental to getting really immersive / interactive (IF-level) story-telling & puzzle-solving off the ground. So really #1 is the main missing link that could make a difference. The difference between menu-based and open/text-based dialogue/interaction is maybe how much you want to lean towards the console side vs. the IF side of NPC interaction ... You can tell where my sympathies are. Anyway, TDM just rekindled my ideas and made me wonder if it's possible and what would have to be done to get there. Thanks for replying, all. ------------------------------------------------------------------ Edit. On reflection, it occurs to me that most (even seemingly open) NPC interactions could be taken care of with a menu that comes up when frobbing an NPC. Along with a list of pre-provided phrases for various AI, there could be also a more open menu system that could allow the player to "ask" the AI about a particular listed topic/object/person/place (not all of them with answers, of course; Q: can you modify a menu list so that new objects you discover can be added?), or "command" an NPC to do a listed action (create a distraction), or even a nice list of "stock-phrases" ("What the hell are you looking at?", "shhh....", "evening") ... open enough that there's lots of room for experimenting and creativity, but closed enough to make it functionally manageable ... just a lot of links to take care of, time-consuming at worst. The more I think about it, the more it seems there's something to this idea. For my own gratification I'll think about it some more, look at how different Adv games use dialogue menus in different ways, and see what I come up with.

All of that sounds right. For how I was thinking about it (thinking back to some AGS's), a dialogue GUI popping up would do the trick ... and even if it pauses the game so you can't control the character until you exited the mode, it wouldn't be the end of the world. If I could get just that much up and running, I'd be willing to try getting it set up with a basic parser... It sounds hard, but I can't help but think it would really open up some awesome possibilities. Anyway, I'm just throwing out the idea. Also, I forgot to mention plan-B, what about a menu based dialogue-system a la Deus Ex 1? I just love NPC interaction, and anyway I can get a foothold into it I'm interested.

In-game text prompt, that is. This is a quick question just to test the waters and see if there are any fish. Ever since I noticed you could type text in-game in Thief with the command line ( cntl+; ), I had this idea that it might be possible to add commands in-game through a text-prompt, sort of like IF-style or the old AGS games (kings quest, space quest, etc.) built into the game, where you could say particular things to NPCs -- like saying a particular password or answering a question to get past an NPC (i.e., the input triggers some AI movement), or "ask X about Y" to learn new info (i.e., the input triggers a screen-text or voice file), where the text itself is triggering things in-game -- and I thought if done right, it might really add to the richness of the game's interactivity, push it more in the interactive fiction direction, which is good IMO. I've played around a lot with parsers, so I could do a lot of the work if the basics were in place (and even pretty unsophisticated parsing can add to a game), but getting the basics into place is what I don't know. Of course, everything concerning the command-line in Thief is beyond access. But what about TDM? Is it reasonably possible to get a text prompt in-game and link it to in-game tools, enough that an enterprising FM-maker could take care of setting the links up by hand? Where on the possibility scale is something like that? Keep up the good work, gentlemen. I salute you.