Ger: Who is here talking about interactive story-telling?
..The first meaning of fiction in my old Oxford (1980 $5.95)is: fiction= a product of imagination. (I place a good simulation or a good TextAdventure under this definition and even prefer a combination of these; like independent Characters moving in a story-maze.) ..The second meaning: fiction= an invented story. Even inside this second meaning you could wonder when a story is created: - When someone invents the scheme of the story? - When a good storyteller tunes this story to his estimation of his public? - Or when you - as listener with your own background - "read" between the story-lines? Interactiv Fiction is the dream that you could bring this even a step closer to the receiver...
-----Original Message----- From: Andrew C. Greenberg [mailto:werdna@mucow.com] Sent: maandag 30 juli 2001 17:40 To: squeak-dev@lists.squeakfoundation.org Subject: [OT] Interactive Fiction is an Oxymoron
Sorry, but the recent thread used a term that just makes me boil over. It is, in my view, the quest for "interactive fiction" that has held back gaming now for decades.
The reason for this is simple. Interaction is an anathema to excellent storytelling. A storyteller, at least per the Poetics, is concerned above all things, with timing. The tempo of a story is everything. The manner and velocity with which the characters are introduced and developed is essential to obtaining the necessary suspension of disbelief -- the tempo of building conflicts ultimately yielding a climax or climaxes drives the reader to continue, and the effectiveness of the denoument to finish, explain and justify the story are all measured along a timescale -- and the tempo between these elements is essential.
Ger: designing the tempo of a video on a stroyboard is very very difficult
for our students, A threaded storyline (Oops.. with LOOPS??) should be suddenly easy because the tool can do it easily?.
Ger: yes and no.. The RIGHT Tempo is everything (most games have boring
difficult=long puzzles on to many places... it invites children to cheat. As designer you can anticipate on that. My Youngest daughter cheats in ThemeHospital and then the speaker-system of the hospital shouts it loud over the corridors... She really hates it every time she does cheat, but not enough to turn off the sound...)
Ger: You can also create the feeling that the player thinks he is so close
to the solution that it would be a pitty to stop after all his efforts, hours later he still thinks the same. Or the puzzle should look misleading simple: like that simple looking rubic-cube puzzle: give it three turns from the correct position and then ask someone to solve it: he knows that you gave it only three turns...
It is the nature of a simulation, or interactive game, to permit the user control over his environment. Should he enjoy prowling around an arena for hours, so be it. If he wants to wander aimlessly through a jungle or search the interstices of irrelevant subject matter to the game -- again, so be it. The more detail, the more interesting the scenario -- but the far less effective the story. As an extreme example, while a simulation can sustain dead ends to make a game work, no story can survive that.
Ger: What about a good detective-story from Agatha Christie. Every time she
makes you think that the wrong person did it, until he dies also (MY favroite as child: Ten little ...)
On the other hand, if you have no dead ends at all, players feel a grave loss of challenge. (Enter the love-hate relationship between gamers, game designers and their game "cheats," walkthoughs and "cheat books.")
This inherent conflict, the war between storytelling and interaction is, to me, the locus where all games (including my own efforts in this regard) have failed.
Ger: I think that you can broaden here your criticism to lots of
Hypertext-dreams that did not work..
Of course, some merging of interaction and storytelling is possible without one destroying the other, but the more of one formulation is added, the more the other suffers. The trick, of course, is to recognize that interactive fiction is an oxymoron. To design the game well, first realistically design it as either a simulation-with-a-bit-o-story, or a story-with-a-bit-o-simulation. Then use smoke-and-mirrors, plain old theatre tricks plus new tech tricks, to make the game SEEM more storytelling, or more interactive, than it really is.
Ger: You have more hints to create better IF?
Ger: when desktop-tools came up everyone thought he could do quality
printing on the fly, isn't this the same with these tools? Don't we underestimate the creative work of heavy teams working at the creation of a new game: Didn't even Disney to easily think that they could compete with the real game-industry while they where good in movies, cartoons and theme-parks and heaving some of the best fiction-realizers in house? Why do game-companies rise and fall? (like Infocom, to stay with the subject.)
On Monday, July 30, 2001, at 03:04 PM, G.J.Tielemans@dinkel.utwente.nl wrote:
Ger: Who is here talking about interactive story-telling?
..The first meaning of fiction in my old Oxford (1980 $5.95)is: fiction= a product of imagination. (I place a good simulation or a good TextAdventure under this definition and even prefer a combination of these; like independent Characters moving in a story-maze.)
The sense of "imagination" as you are using it here is quite different from the dictionary definition to which you refer. The "imaginative" use is not the sense of child-like wonder, but rather the pejorative sense of fiction vs. fact.
The Amazon One-Click patent is also a product of imagination (intentional multiple-entendre). Nobody would consider it to be fiction in the sense in which you intended it here (although many consider the allegations of the complaint to be an excellent form of fiction).
..The second meaning: fiction= an invented story. Even inside this second meaning you could wonder when a story is created:
Indeed, I was equating fiction with "good fiction" qua "good storytelling." I think the best of the genre to date derived from those who recognized the story-telling limitations of a simulation medium, and worked around that rather than trying to harmonize the unharmonizable.
Ger: designing the tempo of a video on a stroyboard is very very difficult for our students, A threaded storyline (Oops.. with LOOPS??) should be suddenly easy because the tool can do it easily?.
As I noted, IF games have improved dramatically in terms of controlling of sequencing and adapting to state changes. My point is that this is insufficient to obtain good IF.
Ger: yes and no.. The RIGHT Tempo is everything (most games have boring difficult=long puzzles on to many places... it invites children to cheat. As designer you can anticipate on that. My Youngest daughter cheats in ThemeHospital and then the speaker-system of the hospital shouts it loud over the corridors... She really hates it every time she does cheat, but not enough to turn off the sound...)
I agree. A story must be appropriate for the particular reader/player. A great story for grown-ups may be wholly dull and unsuitable for children, and vice-versa. However, computers can do a great job with this, if you will. The computer game, unlike the paper book, can monitor and adapt to the behavior of the reader/player (although few do). Likewise, both the simulation and game tempo can be properly adapted accordingly. This is even more challenging once the game becomes multiplayer. But it can be done. I have experimented extensively in this arena both in the real-time/real-space and computer game media.
Adaptive story-telling simulations are possible, and are one of the "smoke and mirror" tricks to which I referred: If someone looks under a chair for something, they have told the computer a fundamentally important thing. They have told them that it would be interesting to them to see something there. A good story-teller (gamemaster) would recognize this and something would be there. Net effect, the player enjoys the result, and things the story-teller (gamemaster) quite brilliant for hiding the clue in such an interesting place.
You would be amazing how effectively this trick works.
Ger: You can also create the feeling that the player thinks he is so close to the solution that it would be a pitty to stop after all his efforts, hours later he still thinks the same. Or the puzzle should look misleading simple: like that simple looking rubic-cube puzzle: give it three turns from the correct position and then ask someone to solve it: he knows that you gave it only three turns...
Again, puzzles must also be adaptive, or else they become dead ends. You have a choice: have an excellent puzzle-game challenge; or tell a story. You can't do both in fact (although you can make users think that you are doing both -- which is how great games are made).
Ger: What about a good detective-story from Agatha Christie. Every time she makes you think that the wrong person did it, until he dies also (MY favroite as child: Ten little ...)
Good writing is one of the key differences between a good detective-story and a crappy one. Not a one of Conan-Doyle's stories made for good puzzles -- but they were so beautifully crafted that they caught imagination of the readers. Many modern products of the genre provide better, more sophisticated challenges (of the one-minute-myster type), but are not as well-written. I like both, in fact.
Ger: You have more hints to create better IF?
I have already posted several in this forum. The best hint is this: stop trying to make interactive fiction. Build an awesome simulation and superimpose a story, or vice-versa, and then try to "trick" the user (read cheat) to believing that either: (1) there is more freedom than there is; or (2) there is more story than there is. The manner with which this is done is, as noted, "smoke and mirrors," the very craft of stagework. [By the way, photorealism and other representational, as opposed to suggestive, media work very hard against smoke and mirrors. It is much easier to obtain a suspension of disbelief when the player isn't focused on inaccuracies. Consider, for example, Final Fantasy v. Shrek. not once did I concern myself in the latter case that the female protagonist's hair was identical throughout the movie.]
Ger: when desktop-tools came up everyone thought he could do quality printing on the fly, isn't this the same with these tools? Don't we underestimate the creative work of heavy teams working at the creation of a new game: Didn't even Disney to easily think that they could compete with the real game-industry while they where good in movies, cartoons and theme-parks and heaving some of the best fiction-realizers in house? Why do game-companies rise and fall? (like Infocom, to stay with the subject.)
I can tell you from personal experience that it has only a little bit to do with the quality of the product. Surviving business cycles has far more to do with the amount of cash flow and reserves held by a company than its intellectual property assets. Quality is a necessary (though not always), but not sufficient measure of success. The success of a game-company depends solely on the question whether there is market demand for the company's product. Infocom died (in practice) long before game hardware could make first-person real-time visuals -- it was something else entirely. In the case of Infocom, I stay out of it. There were internescine wars between the founders and creators of product -- and in those scenarios, nobody wins but the competitors. (Consider who won Lotus v. Borland, for example. After 10 years of litigation and a non-opinion Supreme Court opinion, who won? Microsoft!)
He, he... these threads reminded me of all the fun I had fitting an adventure game into an HP 41 calculator (not the big 41C types!) some 20 years ago.
One key aspects of my world domination plan is that people should learn Smalltalk as their first language. Converting people who started with something else is such a pain - why bother? Those who are already programming today will be a minority in a few years, so it's no big deal if my plan leaves them out initially.
The problem is that I have never read any Smalltlak book or tutorial written for non programmers, which is totally amazing considering what the language was created for. If I am wrong about this, please send me the references right away.
Anyway, I came up with the idea of writing just such a book in the form of an adventure game. Solve the puzzles and learn how to program! But then I started thinking that the book should be available in printed form in your nearest bookstore. If I am going after non programmers, then going after them in a non computer environment might be the smart thing to do.
But as Andrew pointed out, you can't have both a good story and a good simulation. So it can't be both a good book and a nice interactive "tutorial". The book by itself is unlikely to do much good (though I learned Smalltalk from the "blue book" this way and C from the K&R book, I am not a very typical person...) so I have to suppose the reader has access to a computer.
I can't decide: how to get the best of both worlds? Should they be two entirely different products?
-- Jecel
Jecel Assumpcao Jr wrote:
//snip//
One key aspects of my world domination plan is that people should learn Smalltalk as their first language. Converting people who started with something else is such a pain - why bother? Those who are already programming today will be a minority in a few years, so it's no big deal if my plan leaves them out initially.
The problem is that I have never read any Smalltlak book or tutorial written for non programmers, which is totally amazing considering what the language was created for. If I am wrong about this, please send me the references right away.
Well, the Open University's M206 tries to do this (you can probably find someone who has the material in Brazil) but the OU seems to see M206 as a fast path to Java, so I'm not so sure you'd approve of it!
I wonder how close Mark Guzdial's book comes to meeting the bill? I know it's not designed with that in mind, but if you told people to ignore the references to other languages, or maybe gave them 3 intensive days teaching with Bash (Bash because it's useful and doesn't introduce C habits as ksh or Csh would) first?
But this has nothing to do with the book or computer issue.....
Cheers
John
The problem is that I have never read any Smalltlak book or tutorial written for non programmers, which is totally amazing considering what the language was created for. If I am wrong about this, please send me the references right away.
Being new to Smalltalk and Squeak myself, I have a similar feeling. Two resources have helped, however.
John McGuinn's online tutorial: http://members.aol.com/M206ou/m206/
Patrick Winston's slim book "On to Smalltalk". I really like the way this guy writes and wish he would do a book on Squeak or Javascript.
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
John Hinsley wrote:
Well, the Open University's M206 tries to do this (you can probably find someone who has the material in Brazil) but the OU seems to see M206 as a fast path to Java, so I'm not so sure you'd approve of it!
If it gets the job done then I certainly won't quarrel about motives. I have tested LearningWorks, but only very superficially.
Roger Kenyon suggested:
John McGuinn's online tutorial: http://members.aol.com/M206ou/m206/
This is great material - thanks for the reference! But while it does a fantastic job of getting all the little details through in a reasonable order, I am not sure too many non programmers would enjoy it. As I thought about why I had this feeling, I saw that part of the fault is with the LearningWorks GUI itself. It is a serious improvement for the beginner compared to typing stuff in a workspace windows and doing "print it", but is way too abstract compared to Self. There the number 3 is an actual object that you drag around (with the morphic shadow). You send it messages more directly and the results are clearly new objects. I am sure we can do even better and it is likely that MorphicWrappers in Squeak might be a step in the right direction (I haven't tested it).
Then, of course, there is the tile script route...
Patrick Winston's slim book "On to Smalltalk". I really like the way this guy writes and wish he would do a book on Squeak or Javascript.
A review in the above site says "This text provides a concise introduction to the Smalltalk language, suitable for those who need a quick start with Smalltalk but who already know how to program."
And I agree. I had very high hopes when I first ordered this book since it was Winston's "red book" ("Artificial Intelligence", split into "AI" and "Lisp" books in later editions) that got me into computing. I found it a bit more formal than I had expected, just like McGuinn's tutorial. But I already knew Smalltalk very well when I read it and that might have given me a wrong impression of it.
John Hinsley also wrote:
I wonder how close Mark Guzdial's book comes to meeting the bill? I know it's not designed with that in mind, but if you told people to ignore the references to other languages, or maybe gave them 3 intensive days teaching with Bash (Bash because it's useful and doesn't introduce C habits as ksh or Csh would) first?
I haven't read it, but I am sure there are people for whom it would work. People have different tastes so it is impossible to generalize. I really enjoyed the original Kerninghan&Ritchie for C, for example, but many people hate it (they want more details and a slower pace).
-- Jecel
John McGuinn's online tutorial: http://members.aol.com/M206ou/m206/
This is great material - thanks for the reference! But while it does a fantastic job of getting all the little details through in a reasonable order, I am not sure too many non programmers would enjoy it.
Doesn't it seem that the typical introduction for the non-programmer is bass-ackwards. After an overview, there may be a tutorial and reference section. Along the way, it introduces objects, messages, controls, classes, methods, inheritance, and so on.
Case in point: http://www.inf.ufsc.br/poo/smalltalk/vwin20/index.htm. As a traditional intro, its pretty good, but it is not for the non-programmer.
An analogy. Suppose we decide to take "Poetry101; an introduction for the non-poet". It covers the lives of famous poets, parts of speech, rhyming patterns, and even has tutorials for constructing a sonnet and a ballad. Likely result: quantitatively-correct doggerel. Why? Because we learned poetry in the third-person; we learned to be mechanics, not drivers.
(Mixed metaphors? Hey, I am a driver; see my poetic license.)
Let's try another poetry class. We learn how to write descriptively so the reader envisions a mind movie; being transported in imagery. We learn how to write emotively through cultural-linguistic symbols. We learn how to write so the words themselves are part of the message; and so on. Each time checking, if we do this, then that happens. Likely result, we approach poetry as an activity; language as a vehicle; sympathy as a destination.
So how does one create a first-person approach applicable to learning Squeak? The folks at StageCast have a tutorial for Creator that combines traditional "introduction to the elements" with a guided, hand-on approach. That's closer, but not yet there.
Back to the analogy. Why write poems? For one thing, a poem can go where prose cannot. It can convey a sense of shared feelings. Why use Squeak? Well, for one thing, because a dynamic model go where a static description cannot. It can convey an interactive representation of cause and effect.
There is a good example of this in "Computers and Squeak as Environments for Learning" by John Steinmetz. He uses Squeak to show two different ways to envision a circle. In one perspective, a turtle works from a radius to draw a circle. Thus, circle = set of all points equidistant from a center. In the other perspective, the turtle is making a circle as the result of repeatedly, incrementally, moving forward then turning. These are different ways of modeling a circle: one as a set of entities that have a holistic identity (the set of points collectively construed as a circle); another as a process of deflection without regard to center or radius.
This is exactly what I am getting at in the Morphic Modeling in Middle-School Mathematics [MMMM] project (hey, sorry about not putting the outline in .zip or .sit format ). Squeak is a medium for dynamic what-if modeling. It is digital play-doh, pixel plasticine, and as such is effective for (2D, 3D, musical, . . .) cause-effect investigations.
What does this suggest as an intro for the non-programmer?
--
R. Kenyon
|T|h|i|n|k|L|i|n|k: http://www.riverwoodpub.com/educatio.htm Not everything is black & white: some things have to be read.
On Tuesday 31 July 2001 20:04, Roger Kenyon wrote:
Doesn't it seem that the typical introduction for the non-programmer is bass-ackwards. After an overview, there may be a tutorial and reference section. Along the way, it introduces objects, messages, controls, classes, methods, inheritance, and so on.
I have met many people who have taken "computer course" and yet failed to become programmers. Language details are important, of course, but they are not the main thing that programmers know and non programmers don't. Here is what I wrote a long time ago about which ideas need to be taught:
http://www.lsi.usp.br/~jecel/tut1.html
I would combine the ideas of "generalization" and "factoring" into a single "making things smaller". And it would be better to use something like the "spiral pattern" (see "whole course concerns" in http://www-lifia.info.unlp.edu.ar/ppp/element.htm) than to have separate modules as suggested in my page.
Speaking of patterns, I would say that Design Patterns have done a wonderful job of identifying things a programmer should know.
Case in point: http://www.inf.ufsc.br/poo/smalltalk/vwin20/index.htm. As a traditional intro, its pretty good, but it is not for the non-programmer.
The net isn't working too well for me today (I got the top page, but not the frame contents yet) but I'll take your word for it. Too bad the Federal University of Santa Catarina is less Smalltalk oriented these days (I am sure there are people on this list who don't agree, but I am thinking of those not on the list who have switched to Java) and the group at UFPE seems to have switched completely.
Let's try another poetry class. We learn how to write descriptively so the reader envisions a mind movie; being transported in imagery. We learn how to write emotively through cultural-linguistic symbols. We learn how to write so the words themselves are part of the message; and so on. Each time checking, if we do this, then that happens. Likely result, we approach poetry as an activity; language as a vehicle; sympathy as a destination.
And in the case of a regular class setting, you can get good results by having people read poems out loud to each other. The sounds themselves are important and just imagining them on your own isn't the same thing.
So how does one create a first-person approach applicable to learning Squeak? The folks at StageCast have a tutorial for Creator that combines traditional "introduction to the elements" with a guided, hand-on approach. That's closer, but not yet there.
In my "book vs interactive adventure game tutorial" problem, I would say that it is harder to do a hands-on course with a book.
This is exactly what I am getting at in the Morphic Modeling in Middle-School Mathematics [MMMM] project (hey, sorry about not putting the outline in .zip or .sit format ). Squeak is a medium for dynamic what-if modeling. It is digital play-doh, pixel plasticine, and as such is effective for (2D, 3D, musical, . . .) cause-effect investigations.
What does this suggest as an intro for the non-programmer?
It does suggest that a simple text won't do a very good job, first of all. You will waste three pages just describing how to use the menus or the flaps to start a new painting.
Some of the squeakland projects are already good examples of the direction to take. The problem is that if you give the student too much control it is impossible for an automated tutor to keep up. Specially since things break so easily.
The other extreme is the book, with nearly 100% author control. Or the movie. Much better for showing off Squeak. This could reach out to even more people than bookstore customers if it were shown on TV. That was the idea behind the original BBC Basic course (for which Sinclair and Acorn designed very neat machines), right? I didn't see it and have no idea of what the results were. And today you can distribute a movie on tape or a CD-ROM (or DVD), including in a bookstore.
This reminds me of the really nice "Self Movie". It is very well done and I have shown it to several non programmers to see their reaction. It starts out very well but Randy Smith loses his audience with his quick explanation of method execution as cloned prototype context objects (got that? ;-). People then ignore everything he says until he starts demonstrating how to take things apart in Morphic.
Are there any artists in the house? ;-) -- Jecel
Interesting how these two points (look at the web page!) make this thread merge with the one on Interactive Fiction!
don't. Here is what I wrote a long time ago about which ideas need to be taught:
The problem is that if you give the student too much control it is impossible for an automated tutor to keep up. Specially since things break so easily.
The other extreme is the book, with nearly 100% author control. Or the movie.
Now maybe it is not that strange, after all, that the authors of Wizardry and the Squeak reference sheet are one and the same...
method execution as cloned prototype context objects (got that? ;-).
That was a true enlightenment moment for me in the original Self paper. Very cool from an implementor's point of view! (But I wouldn't have understood it from your short description!)
Henrik
This site seems relevant to the interactive fiction thread:
Now maybe it is not that strange, after all, that the authors of Wizardry and the Squeak reference sheet are one and the same...
Nor is it strange that "Squeak and MUDs" is a frequently asked question around here.
method execution as cloned prototype context objects (got that? ;-).
That was a true enlightenment moment for me in the original Self paper. Very cool from an implementor's point of view! (But I wouldn't have understood it from your short description!)
He, he... that was the point I was trying to get across. If the author has total control (less in a book since the reader can go back and forth at his own pace, more in a movie for even on a VCR or DVD it isn't really convenient to pause or go back) then a single miscalculation of the "right flow" can be fatal.
To be fair, I watched the "Self; The Video" again last night and I doubt anyone on this list would have a problem with it. My test subjects were not programmers and don't know Smalltalk.
-- Jecel
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
G.J.Tielemans＠dinkel.utwente.nl -
Henrik Gedenryd -
Jecel Assumpcao Jr -
John Hinsley -
Roger Kenyon