Am I really the only person who doesn't get I7

Part 3 – the vagaries of story space.

It works out that our notions of space and how to navigate it are heavily biased by our culture. I live in the States. Within cities, we tend to name and number streets as we do blocks and buildings. So locations are usually given as 123 Sesame Street. While this rule is not universal, it is nearly so.

By way of contrast, it is my understanding that in Japan streets are not named nor numbered. It is blocks which are identified. The number a building has on the block depends on the order it was built. That makes number 1 on the block the first building built. Number 5 is the fifth. So number 1 on a block can have number 15 on one side and number 3 on the other. All the while, number 2 hides on the opposite side of the block.

The problem gets more interesting when we start talking about how people remember real space. Very few people know the map of an entire city by heart. Most of us only know those parts we routinely travel. Few of us know what lies even two blocks from our routine route to and from work.

Likewise, we tend to ignore street names and numbers. Rather we use landmarks. We tell our friends the location of a new restaurant not by its street address but by being in a particular shopping plaza. Unless you live in the country, you also tend to ignore compass direction. Like the song says … New York, New York what a wonderful town the east side’s up and the battery’s down ….

On the other hand, the starting point for story space is the mental model of a board game. So story space corresponds to the game board. The game board is divided into a bunch of places we usually call squares. It is handy that the squares cover all of the game space and don’t over lap. (You’re right, they don’t have to be squares. Any regular tessellation will do. Oh heck, any irregular tessellation will work too.)

We don’t have to stay in two dimensions, we could jump to three or more. Now we expect the “square” packs without leaving gaps or over lapping. Not to go completely crazy, we tend to stick to squares and cubes. They are simple and obey our needs.

Game squares carry the idea of adjacency. A square touches (is touched by) other squares which are thought of as adjacent to the first square. Here story space takes its first step away from real space. If we wanted to map real space, we would overlay a grid of squares. We would then fill in the details for each square. Eventually each square in the grid will be described. In story space we only create accessible squares. These are the ones needed to tell the story. There are no unmapped squares.

Thus story space can represent the set of all possible routes or all possible places. For example, the story space for a cave ignores the parts of the underground rock in which there are no passages. Thereby it represents routes or paths. By contrast a large open field might be represented through a three by three grid. Here there is no constraint on path, but there is a constraint on possible place.

Story space takes a further departure from real space because it is rubbery. One might think that story space should map to a fixed amount of real space. Thus all squares are the same size. We know that is not true. We can have a location – the open sea. It can be represented by a single square. We can have a location – the garden. It can be represented by three squares.

To a story teller the notion of rubbery space is perfectly natural. If we need the open sea as part of the story, we include it. If nothing important to the plot occurs on the open sea, it is given passing mention. On the other hand the story may call for three scenes in different places within the garden. Here we need three squares to tell the story. Thus story space is driven by plot and not geometry.

I am sitting in a room writing my reply. I can look through an arch into the next room. I can see some of the next room and its contents. I can also see through a doorway in the other room to the room beyond it. I am next to a window which lets me see onto a stone patio and beyond to the garden. Right now, story space only lets me see what it is in the square I occupy.

We have learned to overcome the visibility limitations of story space by following some conventions. For example a room description might read – You are standing in a neatly manicured lawn ringed by tidy flower beds. You are bathed in the lazy drone of bees tending to their work. The garden path pushes to the east through a pergola drowning in scarlet clematis. The path beckons from the garden beyond.

The point is story space doesn’t behave much like real space at all. I don’t have any serious problems with I7 rooms and associated things like scenery. The room metaphor has been with IF since the beginning. I think it faces challenges as story tellers move to using plot to drive things.

To me the game board metaphor is in taters. The room metaphor may not be much better off. It feels like things have been added piecemeal to address weaknesses in the room metaphor. Perhaps it is time to pull all of the story space ideas together to develop a coherent mental model. Whichever story space metaphor you embrace, it is like one of those baseball batting records with an asterisk after it.

It would be very interesting to see what kind alternatives you come up with.

For now, it seems like most games separate spaces by the limits of perception, not necessarily of movement. Good games seem to avoid situations where that would be awkward - a choice of design rather than a feature of coding. For cases where there are dramatic differences between the two (or between the limits of different senses), I think I7 has some extensions and TADS has some built-in capability.

It’s easy enough to write a far-off view into a room description. I’ve come to notice how such a simple trick can do wonders for the illusion of space in a game. The extended capability is only needed when the player has to make out changing details in the distance. And that capability has been around for a long time. Deadline, Infocom’s first non-Zork game, had it.

Part 4 – Choose Your Own Adventure

To take the next step, I would like to circle back to the notion of IF genera. The examples I gave earlier fit into a metaphor I called boardgames. I believe there is another metaphor in use. It is the Choose Your Own Adventure (CYOA) story.

In CYOA the reader reads a section of story and then is given a choice – ride the horse, hide in the thicket. Depending on the choice, the reader will be told to turn to a particular page where the story line picks up again. Eventually, the reader reaches the end of the story thread and stops. Each book contains lots of story threads. This lets the reader reread the book exploring alternative outcomes.

CYOA uses the basic building blocks of story telling – character, conflict, dialogue and action to tell the story. Like most stories CYOA uses the scene as its basic unit of story. It takes advantage of the elements of a scene to link different story threads together.

To be effective, every scene in traditional story telling must accomplish five things:
It must convey something important to the reader
The two main forces in the plot line must meet and clash
The encounter between the main forces must do one of two things:
[list]Attempt to give or seek information
Overcome the other by using things like logic, argument, guile or brute force
Somebody must win, lose or quit
The state of mind of the character or the state of affairs in the story lead to the next scene or resolve the plot line.
[/list:u]

CYOA are usually written in the first person (I, We). Thus the reader is the protagonist or antagonist of the story. There are a few written in the second person (You, You). Here the reader is a secondary character who helps the protagonist or antagonist. This imposes two constraints. First, the only action that can be revealed is action witnessed by the reader. Second, the reader can only be in one place at any given moment. Since time cannot run backwards, the reader cannot backtrack in a plot line.

Let’s take a look at the differences in the genera’s approach to the same situation. Some place romantic and daring is always a good setting. Like titans Hercule Poirot and James Bond before us, we are riding in a sleeper car on the Orient Express. We are in pursuit of the antagonist. We are carrying an item in our luggage which will help us defeat the antagonist. The car’s conductor has been waylaid. The antagonist’s henchman has taken his place. His goal is to stop you.

In the puzzle genera we have to include some kind of puzzle. You have to successfully solve this puzzle to move to the next location. Some potential puzzles come to mind. First, you have to determine that the conductor is the henchman before he is able to kill you and take the luggage. Second, you have to determine that the item has been removed from your luggage, discover its hiding place and retrieve it. Third, you have to discover the bomb the conductor has placed in your compartment and disarm it. Solving the puzzle in the time allotted (the length of the train trip) lets you on to the next location.

In the discovery genera we have to explore the train. You have to successfully visit every place you can. Some potential places come to mind. First, you have to “open” everything you can in your compartment. Second, there are two other compartments in this car. One is occupied the other is not. You have to evade the conductor and the other occupants to enter the other compartments and “open” everything you can. Third, you have to enter the passageways between cars and“open” everything you can. You engage in this behavior; because, a mysterious card with a single large black dot falls from the book you are reading. If you find the bottle of poison, forged documents, and map of the conductor’s escape route, you are on to the next location.

In the DND genera we aim to increase the “strength” of the avatar. You have to choose trials to increase the avatar’s strength. Some potential trials come to mind. First, the player rests, which increases his health. Unfortunately, the henchman successfully steals the item from the luggage while you are sleeping. You get off at your stop, but you no longer have the item. Second, you make friends with the person in the next compartment. By this interaction you increase your intelligence. Once your avatar reaches a predetermined level of intelligence, it is able to recognize that someone has tampered with your luggage. The henchman has hidden the item. You must find it before you reach your destination. Third, you discover the conductor in your compartment. There is a fight. If you win, you win combat points and keep the item otherwise you lose the item. The conductor may be injured or killed. He may escape. You may be injured or killed. Even if you get off at your stop, your avatar may not be able to continue.

Part 5 – CYOA Part Deux

In CYOA we aim to provide multiply connected story threads that engage and entertain the reader. Since the smallest unit of story telling is the scene, a story thread must contain one or more scenes. Each scene is a tiny little story. A scene has a beginning, middle and end. The purpose of the scene is resolved in a little climax in which someone wins, loses or quits. It is followed by the aftermath. The aftermath is either the set-up for the next scene or the falling action at the end of the story

A story form or plot combines scenes together to tell a story. The most commonly used story form is one that has a beginning, middle and end. It is the three act play. In Act I we meet the characters. At the end we learn the protagonist’s visible goal, which has a definite endpoint. In Act II the protagonist confronts a series of obstacles which become increasingly difficult to surmount. These obstacles advance the outer arc, the visible part of the story. They also serve to push the protagonist further out of his comfort zone. This advances the inner arc, the psychological part of the story. The last obstacle in Act II makes it seem to the reader that all is lost. The only way for the protagonist to succeed is to make one last do-or-die effort. Act III contains the climax where the visible goal we learned about in Act I is resolved. This resolves the outer arc. The protagonist must face the climax alone. This resolves the inner arc. Then there is falling action and the house lights come up.

CYOA follows this structure. The story teller lays out a story that looks like a traditional story. All of the scenes are identified along with their resolutions. This creates the main-line story. Once this is done additional story arcs can be created. The connection between scenes lies in the aftermath of the preceding scene. The aftermath is a direct result of the resolution at the climax of a scene. To create an alternate story line, we change the climax, which gives us a different aftermath. Remember the encounter between the main forces must do one of two things:
Attempt to give or seek information
Overcome the other by using things like logic, argument, guile or brute force.

In CYOA the reader selects the alternative resolution and then turns to the corresponding page. The reader then reads the corresponding aftermath and begins the new scene.

Its time to hop the Orient Express to see how the CYOA genera deals with the situation. We know the set-up. The henchman is there to stop the protagonist. So this is a scene where the antagonist (through his henchman) tries to overcome the protagonist. We have to decide how. In celebration of the current era, we will use a bomb. Now we have to decide who wins. I’d like a little twist here so the henchman wins. I don’t want to end the story, so the protagonist is forward in the dining car when the bomb goes off. He is safe. The item is destroyed. The henchman wins. In the aftermath of the explosion, we learn that the bomb was in the protagonist’s compartment. The protagonist is suspected of being a terrorist. This sets up the next scene. .

Now we look at alternative resolutions. First, the bomb doesn’t explode. You return to your compartment. You discover and deactivate the bomb. The construction of the bomb will provide you will all sorts of clues to the antagonist. This could launch a thread in which the henchman attempts to kill you, take the item and use the bomb to cover his tracks. Second, you set out for the dining car with the passenger in the next compartment. In the dining car you realize you have forgotten something in your compartment. You excuse yourself. You see the henchman entering your compartment. You catch him planting the bomb. There is fight. This could launch a thread in which you have to conceal the dead henchman. You get the idea.

Part 6 – So how am I going to do that

As a story teller I use the elements of conflict, character, action, and dialog to tell the story.The story teller has created the conflict and put it in a location.

It looks like we need several locations to tell the main-line story:
Three sleeper compartments.
The sleeper car’s corridor.
The dining car.
Two passageways between cars.

Character, action, and dialog are provided by N/PC’s:
Protagonist – PC
Henchman – NPC
The other passenger – NPC
Waiter – NPC.

We will need a few things:
The item
Bomb
Luggage
Escape map
Bottle of poison
Forged documents.

Further, we have constructed the story thread so that it is one way. The train will not go backwards. It is also time bound. The train ride will come to and end.

This is where the mental model I suggested for N/PC’s comes into play. The protagonist is a PC. He is based on Player. We need to track inner arc changes, so Player is based on Avatar, which is based on Token. The henchman is an NPC which needs to change or adapt. He is an Individual. He has a Personality which is based on AI. He is also a Player, based on Avatar which is base on Token. The remaining two NPC’s don’t need to change or adapt during this scene. They are built like the henchman, but the Avatar is left out.

Conceptually, each NPC has some behaviors that go with their role. They also may have some behavior that are goal seeking. In this example they also can talk. Part of what they say or do may advance the plot.

For example, the henchman character’s dialog and action can be stated as:
He behaves like a conductor
[list]Checks tickets
Moves in the corridor
He behaves like a henchman
He must plant the bomb before your last stop
He must not be blown up by the bomb
He must not be seen carrying the bomb
Nobody can be in the compartment when he plants the bomb
He must not be seen leaving the compartment when he plants the bomb.
He talks about conductor things
Asks for your ticket
Announces your stop
Tells you how long to your destination
Knows where the dining car is
He makes small talk
Talks about the weather
Inquires about your comfort[/list:u]

To make this work, all of the characters are placed in the location and the scene is started. You go to your compartment. You store your luggage. You sit down. The train starts moving. The conductor asks for your ticket. The rest is now up to the PC. He has much more latitude than the CYOA reader. For example he can stay in his compartment throughout the trip. He can spend his entire time in the dining car. He can snoop around.

By specifying the henchman’s goal seeking behavior, the story teller can adapt his strategy in response to the PC. If the story teller wants to make sure the item is taken by the end of the scene, then the henchman’s behavior ensures that. On the other hand, it may be that the story teller doesn’t care. So the henchman’s behavior allows for failure.

Have you read “So, Do We Need This Parser Thing Anyway?” on Emily Short’s blog?

emshort.wordpress.com/2010/06/07 … ng-anyway/

She tries a similar overview of IF to what you’re doing here, including a discussion of CYOA.

capmikee: I had not seen the article. Thanks for pointing it out. I found it very helpful. It makes a lot of points along the lines I am thinking. To me the article deals with a lot of implementation issues. I am at a stage prior to it. To me the root cause of the parser issues lies in the mental model. The reason people struggle, particularly in the beginning is there is no clear mental model. Their actions do not generate feedback which helps them create one.

To go back to the word processing example, everyone starts with something that looks like a blank piece of paper. When you got the product you new it would let you type letters. That’s a whole lot of mental model to work with. I am not so sure you get anywhere near that much when you open a work of Interactive Fiction.

To me the “>” prompt is equivalent to the computer saying “huh?”. In the olden days this kind of command line prompt usually honored “?” as a request for some assistance. I don’t think it works that way in I7.

Right after that we are confronted by some serious differences in natural languages. The structure of English is not universal to all languages. If you think so, just ask someone who lives in India or China, where two thirds of the world’s population resides.

At the implementation level we might take a leaf from the structural linguist’s book. We can see English as made up of a few word patterns which create clauses.

For transitive verbs the patterns are:

Noun-Verb – I run
Noun-Verb-Noun – I kicked the ball
Noun -Verb-Noun-Noun – I gave Marry flowers.

For intransitive verbs the patterns are:
Noun-LinkingVerb – I am.
Noun-LinkingVerb-Noun – I am Susan
Noun-LinkingVerb-Modifier – I am well.

Syntactically we use these clause patterns to create three sentence structures:
Simple sentence
[list]Made from a single clause
I run
Compound sentence
Made from two clauses
Joined by a comma and a coordinate conjunction
I run, and I jump
The complex sentence
Made from two clauses
Joined by a semicolon,subordinate conjunction and comma
I run; because, I jump.[/list:u]

In this view Noun is not understood as a single word. Rather it is a phrase which functions like a noun. Likewise, Verb is a phrase functioning as a verb.

On top of that most of us use colloquial and idiomatic speech. The one example I believe used in I7 is “feed the dog”. We are asked – feed the dog to what? In my part of the world we have an idiom – to feed someone or something. When I feed the dog, I am providing the dog something to eat. Likewise I understand to feed the five thousand as a miraculous feast not a grotesque act of human sacrifice.

The first teacher to introduce me to idioms remarked that idioms mean what they say but don’t say what they mean. When I am unpersuaded by a weak argument, occasionally I am provoked to remark – that dog don’t hunt. I know it draws sideways glances. I imagine it would stop almost any parser in its tracks.

Just like the article I believe both the author and the player need to have a simplified language to work in. It needs to be backed up by a clear mental model/metaphor.

Oh and for those who claim the I7 development language is natural English, please tell me who speaks like this:

“AARP-Gnosis”
Fitting relates various things to one thing (called the home). The verb to fit (it fits, they fit, it is fitted) implies the fitting relation. Definition: a thing is missing if it is not part of the home of it.
A collective is a kind of thing.
Before doing something to something which is part of a collective:
let space be the holder of the home of the noun;
move the noun to the space.
Instead of examining a collective:
say “[The noun] consists of [the list of things which are part of the noun].”

I don’t think anyone has ever claimed Inform 7 is natural English.

Speaking only for myself, I’m a writer who has always had a hard time thinking in traditional programming constructs. Inform 7 has always felt very natural and organic to me. I love that I can write lines of code like:

The player carries a wallet. The wallet is closed and openable. In the wallet is a driver's license and a receipt from Big Jimmy's. The receipt suggests your shit job.

To me, that feels more like writing than any other programming language I’ve ever encountered.

That’s a great point. Whatever else its flaws, Inform 7 actually feels like writing. The effect of that on your creative state of mind while doing it is pretty powerful and a little bit exciting, I have found.

And here I was all ready to hate i7 thinking it was like AppleScript. But AppleScript doesn’t feel like writing at all; probably because AS code doesn’t structure any differently than an object-oriented language — it’s the same thing as C++ just way more verbose and sometimes maddeningly difficult to read. Having investigated i7 I now think that AppleScript missed most of the point of a natural language approach, which isn’t just to replace every plus or equals sign or other operator with a corresponding English word.

P.

I have the same feeling. When I am dealing in simple assertions, I don’t have to deal “computer stuff”. Unfortunately, if you stray too far from simple assertions I feel it rapidly becomes very opaque language.

I feel that’s the point where I start rummaging around for very general, far-reaching statements of code. To me, it doesn’t become nearly as opaque if I can tuck in all the overarching behaviour code into its own area and give it the proper English-sounding phrase. That lets me mentally compartmentalize the game similarly to what you’d do in OOP.

To me, you give voice to one of the feelings that drives me to a comprehensive mental model.

…does that mean that I’m making some kind of sense, or that the kind of weird non-English I slipped into is part of what you can’t stand about I7? :slight_smile:

You make sense to me. :sunglasses: I suspect people’s passing exposure to computer programming is part of the difficulty here :open_mouth:

When someone is designing a new computer language, fundamental choices have to be made. One of the choices is about programming paradigm. A paradigm is a mental model that structures the way problems are specified and resolved.

If you learned a language like BASIC, FORTRAN or C, you learned one kind of imperative programming – procedural programming. You learned that a program expresses an algorithm. An algorithm can be thought of as a step-by-step recipe for completing a task. You learned about control of flow through things like if and while. You learned about assertion though things like assignment and compare. Because it is procedural, you learned how to create and invoke procedures.

When you entered your second programming class, you thought you knew programming. But the instructor told you that procedural programming has some definite limitations. Specifically, it could not handle events. The window-based programs on your Mac or PC used an entirely different approach. They used objects and something called Model-View-Controller (MVC) to get the job done.

Now you learned that an object has a name, data that it alone knows and something called methods (procedures). To use an object you had to instantiate it to create an instance of the object. The instances of objects interact through something a lot like a conversation – here is the mysterious event. There is a conversational rule called MVC which made window-based programming possible.

Being a thoroughly modern person, you wanted to learn how to do web page design. Your next instructor talked about something called Web 2.0. You are told you will learn AJAX. Now you know about Hypertext Markup Language, HTML; Cascading Style Sheets, CSS; Document Object Model, DOM; Java Script and a framework like JScript. You might have run through a course on Relational Databases. There you would have learned Data Definition Language, DDL and Structured Query Language, SQL.

Your instructor for the web and database classes most likely left something out. He or she forgot to mention that SQL, DDL, HTML, CSS and so on are computer programming languages. They are not procedural nor object oriented. Rather these languages use the declarative paradigm.

The declarative paradigm specifies the logic of computation (the what) and does not specify flow of control (the how and when). In other words there are no algorithms. Suddenly, you realize that the course on spreadsheets was your introduction to declarative programming. You specified what each cell was to do, but you didn’t have any control over the flow of execution. In SQL you specified what to join and what you wanted back, but you said nothing about how it was to be accomplished.

After you completed your formal education, you may have learned other languages like PHP, Python, or Perl. You found out these languages support multiple paradigms. Now you were free to choose the paradigm.

I suspect that unless you are forced into an event driven world, most people select the procedural paradigm. It seems to match our intuition about how the world works. In procedure land farmers bring cows to the milking barn, where the cows are milked. There is a bunch of procedures or processes that must be followed to complete this compound task.

In object land the milking barn is a container which holds cows. The farmer asks the barn to provide milk. The barn in turn asks the cows to milk themselves. The cows create new instances of a container called milk can which are kept in a heap. When all the cattle are done milking themselves they notify the milking barn. The milking barn tells the farmer where the heap of milk cans can be found.

In declarative programing the farmer specifies there is a container called milk can which holds the cows’ milk.

If you are like me, you want to concentrate on the story. I don’t want to spend my time thinking about procedural ideas like before or after. I don’t find objects to be a particularly natural way to think about anything. Also once I get past a couple of dozen objects, I seem to spend a disproportionate amount of time trying to keep track of them.

I find the declarative paradigm lets me concentrate on the story. It lets me deal with ideas of location separate from ideas of character. It lets me deal with scenes and thus story. It ought to let me make statements like this:
Asriel is an Elf who lives in the Eastern Enchanted Forest.
Ethyl Red is a Human. He is the King of a Clan called the Plinth who live in the Fen.
The Eastern Enchanted Forest is a region comprised of:
[list]Room One
Room Two.
An Elf is an Individual.
Knowledge ranges from 5 to 9
Magic ranges from 7 to 10.
[/list:u]
Consequently, I can organize the elements of my story neatly. I can put all of the elves of the same clan together. I can implement the back story directly in the character. Locations can form a map. And best of all I don’t have to worry about any “computer stuff”. :smiley:

You’re going to have to deal with “computer stuff” at some point if you want to make a story that runs on a computer. The question is which paradigm you’re most comfortable approaching that stuff with. And I really don’t see much difference between the paradigm you’re proposing and what Inform 7 already allows, except that you’re not defining some terms that a computer will need to make sense of your proposal. What does it mean to be a king in your story world? What does it mean to “live” somewhere? Is that the same as physically being present, or does it imply other things relevant to your story?

Answering some of those questions arbitrarily, I’d render your plan in I7 like this:

The Eastern Enchanted Forest is a region. Room One and Room Two are in it.

Every region has a clan called the territorial owner. The Fen is a region. The territorial owner of the Fen is the Plinth.

An elf is a kind of person. Asriel is an elf in Room One. [if we want to define "lives in" more specifically, we'd need rules to support this: can people move outside of the area they live in? Do they behave differently if foreigners enter their region? These would be authorial decisions based on what is necessary to tell your story. Most simply, we can just start our character within a room in the region he lives in.]

A human is a kind of person. Ethyl Red is a human.

A clan is a kind of value. The Plinth is a clan. Every person has a clan. 

["Ruling" by itself doesn't mean anything to the system. But we can define it.]

Ruling relates one person (called the king) to various clans. The verb to rule (he rules) implies the ruling relation. 

Ethyl Red rules the Plinth.

Every person has a number called knowledge. Every person has a number called magic. The knowledge of a human is usually 5. The knowledge of an elf is usually 7. The knowledge of Ethyl Red is 8.

Part 7 – Where did I wind up

I think I can now answer the original questions – what is my perfect IF language.

The first part of the answer deals with the mental model or metaphor underlying the language. I believe the underlying mental model should be the story telling model. I believe I showed that puzzle based, exploration based, DND and COYA based stories can all be accounted for within the story telling model. Further the story telling model allows us to create richer IF than the other basic models.

Story telling uses character, action, dialog, and conflict to create stories. The model must explicitly support them. I showed that character, action, and dialog can be accounted for by an N/PC. I identified the specific conceptual structure of an N/PC. Further, a PC which includes Avatar allows the story teller to represent both the outer story arc and the inner story arc. The fundamental conflict is created by the story teller when the basic goal for the protagonist is set. The antagonist opposes the protagonist throughout the story. Specific conflicts arise as the PC makes choices.

The scene is the fundamental unit of story telling. I laid out how scenes are linked together and can support both outward and inward branching. This allows the story teller to use story structures or plots. Scenes take place at a specific time and location. In IF time can only run one way. Thus we cannot directly support multiple parallel plot lines. The PC can play any character. The most likely choices are protagonist or antagonist. Thus a single story can be enjoyed from multiple perspectives. Something that traditional fiction cannot do.

I looked at physical location and found that Room, a traditional element in IF, is a strong start for the location needed to expand the capabilities of IF.

The second part of the answer deals with the programming paradigm. I identified four major paradigms in use today - Procedural, Object Oriented, Functional and multiple paradigm. In my opinion, the functional paradigm meets the needs of the story teller better than the other three. Functional programming deals with what the computer does and not how or when the computer does it.

There is no doubt in my mind that I7 is a domain specific language. Further, specifying location does not have to use the same language as specifying character or dialog. This another reason why the functional paradigm makes more sense to me. Anyone who has used a spreadsheet or HTML has firsthand knowledge of the functional paradigm. It is not some weird computer-geek thing.

I also point out that I believe in TMTOWTDI. Thus, I have no objections to the language developers supporting multiple paradigms. The only thing I ask is that they don’t force the author to mix programing paradigms.

The third part of the answer deals with the PC. While I speak English most of the world doesn’t. English word order is not universal. To me this means that the language developers have to separate the User Interface structure from the story telling structure. Carnegie Mellon’s Software Engineering Institute has done extensive work in Software Product Lines. They give real life examples of how to do this.

The fourth part of the answer deals with the language developers. Developing any language is far from a trivial task. Since I believe I7 is clearly a domain specific language, I7 is not a self-extensible language. In other word you can’t implement I7 using the I7 language. I think a small base language with a framework/module library makes a lot of sense.

I like this approach. I want to say that, and I also want to head off the “But you can do all that in I7!” replies (which are somewhat inevitable in this sort of discussion).

I think, however, that you’re attacking both “world model” (or “story model”) and programming language in your analysis, and they can be kept more separate.

As a tangent: you left out “declarative” in your list of language paradigms, and I point it out because (a) HTML (your example) is declarative, not functional (to the extent that HTML is a programming language at all); and (b) I see I7 as being more declarative than most other programming languages. (Whereas I7 is much less of a functional language than nearly any other high-level language I know.)

Zarf: Thank you for the kind words. It is my hope to contribute to the development of the language and IF.

I think you are right. I got a little sloppy with functional. I believe declarative is generally considered the umbrella term. It certainly includes functional and domain specific. I appreciate you catching my mistake. I am sure both of us would rather not get pulled off topic by it. :blush:

Also, I believe CMI calls Software Product Lines a development paradigm.

Aaronius: I am glad you don’t see much difference between what I am proposing and what I7 does now. The point is to improve I7 not replace it.

First off my example was not intended to be a full implementation. Rather it was to illustrate the general way I suppose a declarative implementation should look.

I find your proposed implementation interesting on a couple of points. Since I take your implementation at face value, I am not suggesting there is an alternate way to implement in I7. Let’s look at the implementation of clan:

A human is a kind of person. Ethyl Red is a human.
A clan is a kind of value. The Plinth is a clan. Every person has a clan.

To me the author is attempting to define an ontology. (I think Wikipedia’s article on Ontology (Information Science) covers the topic well.) That means there is a formal representation of concepts (knowledge) within a domain and the relationships among them. An ontology is handy because it lets us reason about the domain and describe it.

To me Kind is a class or set. So we know that Person is a class and human is a subclass (subset) of that class. We also know that there are instances of classes. In this case Ethyl Red is an instance of the human subclass. Since human is a subclass of Person we know that Ethyl Red is also a Person. Ethyl Red is a value of name,which is an attribute of Person. To me this works well. The game-world model matches my real-world model.

Clan is defined as a subclass of Value. Plinth is defined as an instance of clan, thus it is a value. This one does not match up very well with my real-world model.

I think of a clan as a set of people, thus it is a class. Membership in a clan is a relationship between instances of the class - human and the class - clan. There is a restriction on clan membership – a human can only be a member through familial relationships (marriage, adoption or birth). Plinth is a value of name, which is an attribute of Clan. So far we have not said anything about the class Clan.

The ontology lets me make my first point. The I7 implementation of clan is inconsistent with similar implementations – human. It works against the author’s mental model of the language. Likewise, it works against the player’s real-world mental model. Clans are groups of humans.

Let me move on to my second point. An Ontology is written in a formal language designed to make it easy to create and reason about an ontology. Usually, they are declarative languages. I am inclined to a language, like I7, that makes English-like statements. The problem is English is a living natural language. What that leads to is the use of something called a controlled natural language.

In this case it looks like English. It is a restricted subset of the language, which can be mapped to a formal language. This means automated tools can be written that validate the language and let us make inferences from it. Attempto Controlled English (ACE) is an example of such a language.

Before someone jumps me about ACE, I am not extolling its virtues. I am just pointing to an existing example of a controlled natural language. ACE does have tools to support ontology. For example, ACE View lets us create OWL ontologies. Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. OWL is endorsed by W3C.

This lets me make my second point. I7 is a significant departure from I6. It is growing into a controlled natural language that lets us express a game-world model (ontology). Rather than reinventing the wheel, I would like to encourage the adoption of approaches already in use. I am clearly in the camp,which wants to grow I7 into a declarative language so that authors can concentrate on the “what” of IF and not the “how and when” of computers.

OK-- Inform 7 can set things up this way too, if you like. See the section on “Relations in groups” in the docs. You could then create a series of rules to restrict when clan relations change.

If you can propose actual pseudocode that would be a) theoretically compileable, and b) clearly more straightforward than an implementation in Inform 7, I’d start to get interested.