 |
|
 |
|
On Sun, 24 May 2009 08:29:46 -0700, Jim Aikin <...@gmail.com
Based on a quick glance at their web page, they seem very prestigious.
This is a real coup!
Have they figured out a way to get Workbench running on the Mac? It
...sort of... works, but the last time I checked (using Crossover), a
couple of dialog boxes were still only partially functional. Maybe this
development will give Mike Roberts an incentive to take a fresh look at
that code.
Are they planning to publish their findings? This type of in-depth
analysis would be extremely useful for the designers of systems, I'd
think, as well as for authors who want to think about things like pacing.
I'm sure I don't have to say, "Try hard not to get yourself
inconveniently dead."
In a legal sense? :-)
u n me both.
--JA
|
|
 |
|
 |
|
|
|
|
On Mon, 25 May 2009 05:51:47 -0700 (PDT), Jeff Nyman <...@gmail.com
On May 24, 10:29 am, Jim Aikin <...@gmail.com
They have done nothing with the Mac, at least from what I know. From
what I gather, the Mac wasn't an issue. I do know there was a
discussion as to whether the operating system mattered from an
authoring standpoint, as opposed to a reading/playing standpoint. But
from what I understand -- and I can attempt to find out the details --
the operating systems were all firmly in the Windows world, with
Windows XP being the most common. I think there were some individual
laptops that were Mac's but they were running Parallels and it wasn't
an issue.
I should add, though, that we aren't planning on using the Workbench,
even on Windows. Or, I should say, people can use it if they want, but
I have a few alternatives lined up. One is a modified SciTE interface
that is very minimalist but works for class purposes. Another is using
the editor EditPad Pro.
To be honest, I don't really know. That being said, I'd be surprised
if they would be against publishing this. I can certainly ask. I
actually "funded" this effort through my a company that is
(hopefully!) holding a job for me. That company engaged ThoughtWorks
for an internal four week analysis of refactoring and TDD practices. I
then piggy-backed my own department's funds in a way that is a bit
strange. Specifically, I'm hiring a writer and novelist for a role as
Business Acceptance Analyst. (I look at business requirements and
acceptance tests as narrative elements in a wider story.) I also
called in a favor with a few ThoughtWorks higher-ups who I've provided
a lot of business for. So nothing they worked on is under any sort of
non-disclosure and I'm fairly confident I can get them to publish (or
at least release) everything they did.
- Jeff
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 08:59:23 -0700, Jim Aikin <...@gmail.com
Color me baffled. Do you grow your own papyrus reeds for making paper? I
mean, okay, 95% of what I do in Workbench (or did, when I was writing T3
games) was use the editor. But being able to rerun scripts with one
click (equivalent to the I7 Skein) is extremely handy, as is having a
browser that shows your files. Once in a while I set a breakpoint or use
the Watch window. Why deprive yourself or your students of those features?
I think I share Andrew's concerns about the methodology that may have
been used in reaching the conclusions that they did. It would be useful
for that reason alone to know how they went about it. Not that I don't
approve of using T3! Andrew's feelings about that are probably different
from mine. But it does seem to me that I7 offers some advantages for
writers who are unfamiliar with programming languages in general.
Or perhaps not ... perhaps my original view of I7 (that it muddles
together the writing and coding, when they would be better kept
separate) is still defensible.
--JA
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 09:35:25 -0700 (PDT), Jeff Nyman <...@gmail.com
On May 25, 10:59 am, Jim Aikin <...@gmail.com
The problem with Workbench -- when starting out, anyway -- is that it
often becomes a distraction. Or, at least, so I've found in classes
where I've used it. That being said, I can do the same things you do
in Workbench with my minimalist editor (except for debugging). My
minimalist editor just removes some of the complication so we can
focus on certain elements first. I've found that to be more effective
when getting TADS introduced to people. Some people do eventually
switch to using the Workbench; others opt not to.
It's a question of whether it's deprivation or not. The TADS Workbench
is a programmatic tool and presents itself that way. As such, some
people find it distracting or "a little busy." Yes, of course, they
can just ignore the elements there and not use them. But, again, I'm
just basing this on my own experiences with people. Other people's
experiences may differ. Usually what I've done in the past is that
after we've talked about TADS for a bit, as a language, I then have
people open their .t3m file in Workbench and go through some of that.
(It's the exact same logic whereby you probably wouldn't have someone
learn Java by using IntelliJ or Eclipse first. Rather, have them learn
the language. Then have them learn the supporting IDE. It's the
language that ultimately matters.)
If you mean the ThoughtWorks side of things, that was solely based on
looking at how people generalized the code constructs of each
language. In other words, how easy was it for them to do a similar
task after they were shown a related, but slightly different one? How
often were they able to put the correct elements in place to achieve
the effect they wanted? How often were they able to match the style of
their thinking to the style of their implementation? How often could
they identify the correct path to take to achieve a given effect? How
much of the underlying system (such as the library) could they
"override" if and when they wanted to? How consistent were the styles
of implementation of various aspects in each language?
(This is the same kind of analysis that is done when programming shops
make a decision as to whether to focus on, say, a J2EE environment --
with Java coding -- or a .NET envrionment -- with C# coding.
Alternatively, it's similar to when there are analysis sessions done
on using Rails vs. Django vs. Pylons. Schools make similar decisions
when they decide what languages or tools most effectively seem to
promote the ideas that the classes are designed to show.)
ThoughtWorks wasn't looking at the writing aspects of this. (They
would scarcely have had the expertise to do so.) What they were doing
is what they specialize in: looking at how ideas and concepts
(thoughts) are capable of being coded with the language/tool of choice
and then how people seem to respond to that, in terms of their ability
to specialize, generalize, and create.
Many people seem to say that. But then when it gets tested in reality,
I rarely find that to be the case. What I have found -- and, again,
this is with testing with actual writers -- is that Inform 7 is
preferred up to a point. (The "up to a point" has been a bit variable,
granted.) After awhile, however, writers tend to find that Inform gets
cumbersome. One is the fact that it's all one source "page." Even with
the Index elements, most of the people I work with just don't like
that. Another thing I find is that the rule structure gets in the way
rather than helping, particularly when it comes to conceptualizing.
It's also often reported to me that Inform 7 implementations seem
"inconsistent." Part of that is due to the natural language aspects
which, of course, must break down at certain points but part of it
also seems to be due to how the language itself is constructed. As one
example, people tend to like the fact that TADS promotes the idea of
methods on objects, as in dobjFor(whatever) and iobjFor(whatever).
They also like how that logic is seen to work with other methods like
roomBeforeAction(), roomAfterAction(), roomAction(), actorAction(),
etc. Another major area that writers tend to focus on is how verbs are
constructed. Another major area is how easy it is to apply styles to
text.
What I've often found is that the writers I work with often want to do
very detail-oriented things with room descriptions, item descriptions,
character dialogue, etc. And when they do those, they find that Inform
7 seems to make that a little more cumbersome than TADS 3.
I should also add that the issue for writers (at least the ones I deal
with) isn't that Inform 7 or TADS 3 are programming languages. Thus
their familiarity with languages in general is rarely an issue. What
is at issue is whether the language seems to allow them to translate
writing concepts -- as they understand them -- into an implementation
form that they can readily adapt to.
I've long maintained that as a working hypothesis and much of the time
I've found that to be repeated in the comments of various classes,
except with the younger crowds who tend not to make that distinction.
In the programming world, there is a lot of buy-in to the idea of
programming languages that let you write logic based on intent rather
than implementation. It's questionable to me whether it's possible to
say whether Inform 7 or TADS 3 actually does that more effectively and
efficiently. What I've often found is that most of my classes actually
don't care about that -- even assuming they understood the
distinction. What it comes down to is really trust. People need to
trust that the language is going to allow them to do what they need to
do, as they want to do it, in a way that actually makes sense to them.
- Jeff
|
|
|
|
|
|
|
|
|
On Sun, 24 May 2009 16:39:46 +0000 (UTC), Andrew Plotkin <...@eblong.com
Here, Jeff Nyman <...@gmail.com
This is really nifty.
However, looking at their web site -- "a global IT consultancy" -- I
have to wonder if you should have also engaged a global art or design
consultancy. :)
How IF-savvy were these writers?
I'm not worried that the study was aimed at the wrong kind of student;
I know that the point is to teach IF to total IF newcomers. What I'm
wondering is, what level of IF technique were these test subjects
testing out.
As an exaggerated example: if you asked me to demonstrate a scene with
an urgent pace, I would maybe have an NPC in the room reacting to my
commands. ("Why are you searching under the furniture when that bomb
is ticking?!") I'd customize a lot of default responses ("wait") and
probably a lot of game-specific ones too (object descriptions would
point you back at the bomb, movement would be restricted, etc).
This level of technique, by no coincidence, really points up the
different approaches of I7 and T3.
Whereas if I asked a completely IF-native writer to set up the room
the bomb, I'd expect him to write a few paragraphs of really sharp
prose and then drop them into the room description. Trivial in any IF
design system, but it tells you nothing.
Can you go into detail about the tasks you studied? And (if we're
really lucky) the results?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 05:36:42 -0700 (PDT), Jeff Nyman <...@gmail.com
On May 24, 11:39 am, Andrew Plotkin <...@eblong.com
Not necessarily very savvy. But that was partly the point. We needed
people with some stranger value but also who had aptitude and attitude
to learn. (You can always teach skill; you can't impart the latter two
elements.) So the system had to prove that it was something they could
learn and readily adapt to. Here "learn and readily adapt to" really
meant that they found effective and efficient heuristics for
generalizing in certain cases and then bringing those generalizations
down to specifics in others. Of course, this didn't mean whatever they
were using was the "best" system or the "more powerful" one
necessarily; it's simply the one that people felt they could do more
with.
You might be surprised at the level of detail that people produce (or
try to produce) when they are *non-textual IF writers* but also
approach textual IF *as a writing discipline* in the first place. I've
consistently found that people who do write have a sort of intuitive
sense about what they want textual IF to be capable of doing. What
then matters is how easily the system they use let them translate
those thoughts into implementation. In terms of NPCs, the things
writers often want to do with them are very complex, often hinging on
subtleties of mood and emotion. They also would prefer to do
techniques like scene weaves.
The pace example you give with the bomb about to go off is really more
one about establishing tension, not pace. The pace would have to the
speed at which those events in the room occur, even separate from the
actions of the protagonist. However, as my writers would point out,
the pace also has to tie in with the emotional involvement of the
reader. So just taking a scene like "a bomb is about to go off" is
not, generally, how my writers look at it. They look at it as "how did
I get the protagonist to this room, why is the bomb here, why does the
protagonist just not leave, what will it matter if the bomb goes
off..." and then they craft mini-scenes around that with that
background knowledge operative. Then they would customize the "default
responses" to act accordingly, and eventually forcing action (of some
sort) to happen if the player-as-protagonist continues to do nothing.
Regarding your "NPC in the room reacting to commands", they would then
first situate what the relationship is between that NPC and the PC
(which I have them call Protagonist Character instead of Player
Character) and then craft elements accordingly. They would also try
different things like (1) the NPC has a gag on, (2) the NPC is someone
the PC wants to leave in the room but needs to get information out of.
In that latter case the goal would be (a) get the information out of
the NPC, (b) while looking like you are searching for the bomb (the
NPC must be convinced!), and (c) really just trying to get the PC out
of the room, with the bomb still ticking, and the NPC getting caught
in the blast. (If you take too long, the NPC might break free of his
bonds. Or, if you take too long, the bomb might go off, taking you
with it. Or, if you leave too soon, the you may still kill the NPC,
but you won't have the information you need.)
What about moral premise? Another aspect of this might be that you, as
the PC, do find the bomb and deactivate it temporarily. But you don't
let the NPC know that. You still act like you are searching and,
meanwhile, you still pump for information. Now, once you have the
information ... you could reactivate the bomb and leave. Or you could
leave it deactivated. Will this moral choice define your PC? Will it
have demonstrable effects later in the story? Even if that NPC doesn't
appear later, your actions have now defined some aspect of the PC and
they may hesitate to act a certain way later on. Or they may "fail to
notice" -- i.e., fail to to report to the reader/player -- certain
things based on their new way of thinking. That latter point is
something I've been working on with writers a lot. Have the PC
describe rooms or items a certain way based on whether or not they
have acted in certain ways earlier. What we see around us, and what we
think to do with what we see around us, is often predicated upon how
we view the world, often based on our past actions and experiences.
Capturing that in a PC and then having them look at the world through
those eyes -- through those eyes we, as reader/player, helped build --
is a way that the PC becomes an active part of the "puzzles."
Anyway, that's the kind of stuff my non-novice people (to textual IF)
tend to come up with. That is then what they try to implement.
- Jeff
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 09:18:22 -0700, Jim Aikin <...@gmail.com
I guess I'm just getting old, fat, and lazy. I can see that what you're
describing here would add depth to a game. But to me it feels like a lot
of work to implement a variety of (i.e., more than two) "moral states"
or "cognitive states" for the PC.
My suspicion is that the amount of work that would be required would not
be repaid in terms of improving or deepening the reader/player's
experience of the story.
Let's suppose, to make up an example, that you can get into the
underground bomb factory either by hitting the guard with a lead pipe or
by giving the guard a six-pack of beer. If you show the game that you're
a violent person, room descriptions within the bomb factory might be
more stark. Other NPCs might be described in less friendly terms -- and
certain topics of NPC conversation might be shut off with a "Why should
you care what she thinks about that?" message.
That's all well and good, but the story still has to be structured in
such a way that the player can reach the happy ending, no matter what
their moral state. If your choice of hitting the guard proves, 200 moves
later, to make the happy ending unavailable, that's just a horrible
design mistake.
So really, what this "moral state" coding would do would be to force the
author to write two closely related stories instead of one. And any
given reader/player will most likely only encounter one of the two
stories, because the differences in outcome would not be sufficiently
engaging to entice them into going through the whole thing a second time.
As a writer, I'd prefer to focus my effort on writing ONE well-crafted
story. But that's just me. As I said, old and lazy. YMMV.
What Emily Short did in Floatpoint was put the moral choice at the very
end of the story. It's a branching ending, but you can save just before
the ending and then replay it. This is easier to implement, and it
doesn't cheat the player. But it isn't as interesting either, from a
narrative standpoint, as what you're talking about. Hmmm....
--JA
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 09:55:12 -0700 (PDT), Jeff Nyman <...@gmail.com
On May 25, 11:18 am, Jim Aikin <...@gmail.com
It is a lot of work, no doubt. That's the part that writers find
challening about textual IF.
I think that a lot of what people talk about in textual IF doesn't
require "narrative engines" or "drama engines" or "better AI" but,
really, just hard work and a lot of implementation detail. To the
extent that such "engines" can make that work easier, or provide
supporting frameworks -- great. But it does come down to work.
That's part of what I've long been wanting to test in a structured
way. You may be right. I have no idea. My working hypothesis is that
the amount of work required would be repaid, assuming the supporting
elements (effective narrative, good plot, engaging characters) are in
place. That then assumes that the level of writing matters.
Or the ending isn't a "happy ending." A good example -- albeit not
textual IF -- is the game "Blade Runner", which changed the ending
based on how you acted during the game. Thus "happy" or "sad" ending
was really kind of up to you, even in interpretation. (Contrast that
with the simplistic route taken by a game like "Deus Ex" -- again, not
textual IF -- where your decisions, although leading to branch points,
really didn't matter in any meaningful way.)
Maybe. I wouldn't be so categorical on that. But I also see your
point. That's something my writers want to experiment with. In other
words, in real life, our decisions ultimately lead to a set of
consequences. That's how the world works. In novels and in film,
that's the same case -- except we don't have control of that. In
textual IF, we do. Or, at least, we do *to some extent.* It's the "to
some extent" that I think is interesting to explore and the idea of
how you do (or do not) close off alternatives based on actions the
reader/player takes. And it's not just closing off actions or paths.
It's also questioning whether you, as author, can still tell the story
you want to tell if the reader/player starts going in a different
direction. (It's akin to imagining "The Godfather" where Michael
Corleone never took over the family. Okay, that can be a possible
story. But it's a very, very different story. It would not be
effective -- in most cases -- for the author to try to tell both
because, after all, that wasn't the theme of the story.)
I talk about this in an old blog post:
http://jeffnyman.wordpress.com/2009/02/22/arguing-from-your-premise/
So ...
Exactly. And most writers feel, as I think you feel, that this would
not be effective because it would force you to entertain multiple
premises. That can work in a game (and this is really what "Deus Ex"
did) but it can't as easily work in a story (which is why the various
endings to "Blade Runner" were actually not necessarily happy or sad).
As a textual IF example, what if in "Trinity" you truly could prevent
the explosion of the first atomic weapon? In that case, not only was
the time travel logic thrown off, but a key aspect of the overall
theme was thrown off as well. You simply couldn't tell the story in
that way: at least not and have it be the same story. But that's easy
to say. What's harder is to try it. One of my examples was creating a
protagonist for "Trinity" (Harry Smolin) and have him be a very anti-
nuclear person.
Now, with that, I knew that if I wanted to keep the story "Trinity"
was trying to tell, I couldn't have Harry *actually* stop the atomic
explosion. That needed to happen. The paradox had to be stopped. But
what I could do was try to make the reader/player actions more
meaningful in relation to Harry's feelings. I could have Harry develop
as a character such that Harry and the reader/player had to start
thinking alike, as it were; had to start moving down the same path.
The story element came in from making it clear to the reader what my
premise was and why I chose to structure the story path in that way.
The reader/player could still disagree. But they couldn't say that
violated my premise.
(I know I've blabbed about that in a lot of threads, so I'm sorry if I
keep sounding like a broken record but it was one of the more
enlightening times I had when playing around with what textual IF is
capable of.)
No, actually I agree. (About your preference that is; not the old and
lazy part!) So the key thing here that I've long been looking at is
how, as writers, can we incorporate effective moral premises within
textual IF but still allow the reader/player freedom of action? How
are actions constrained such that the premise is not compromised, but
the playability nature still exists? The notion of "cheating the
reader/player" is, I think, not quite the binary one it's often made
out to be. But I do agree that it's an uneasy balance, when you place
the emphasis on story as opposed to game.
- Jeff
|
|
|
|
|
|
|
|
|
On Mon, 25 May 2009 10:54:11 -0700 (PDT), Conrad <...@gmail.com
On May 25, 12:55 pm, Jeff Nyman <...@gmail.com
The conventional wisdom on this point is that it's a mistake for a
*minor* choice to block out successful completion of the game.
A player who has their character murder an NPC who they could have
drunk under the table usually, I think, wouldn't object to seeing the
Inevitable Consequences of that action play out. Rather, it might be
part of the fun.
A happy ending for the player might not be happy for the PC.
So really it depends on how the game frames "hitting the guard" -- how
much weight the action is given, whether there was a clear
alternative, whether there are reminders of the consequences, and so
on.
Yeah, an interesting discussion. I personally favor allowing for
distinct storylines to emerge as a consequence of player choices,
because I think it's cool; but I don't have evidence that such games
are more satisfying to most players.
Conrad.
|
|
|
|
|
|
|