Could you elaborate a bit on that?
I thought Piergiorgio’s comments were pretty easy to understand and didn’t need a retranslation. 
Also, First things First is a 20 year old TADS game with time travel.
4 Likes
Oh, it seems I misunderstood a few things then. ^_^()
also you do a very terrible mistranslation of the inform 7 cite, because you render that I wrote messy code in I7, when I mean that I mess around and/or fool around I7 because isn’t stable enough under Linux, and because is still closed-source, there’s few workover possible, and I don’t consider it a “production-grade” language.
(if you search this very forum, you will find debates on ni segmentation fault, and figuring together a workover about the segfault issue under Debian and/or Ubuntu, with many posts from myself)
Also, as Tayruh pointed out, First things First was a TADS2 game, one of the major ones written during the “Renaissance of IF” of late 90s-early aughties…
Best regards from Italy,
dott. Piergiorgio.
ps: a little excerpt from a testing/messing/fooling around with I7, to explain in practice the concept:
"cottage" by "PGdE"
[heading order: volume-book-part-chapter-section]
[a three-room-plus-outside and attic & cellar cottage for small romps...]
[the player is outside_cottage.]
When play begins: say "An Imp is fooling around a cottage, in search of new ways of implementing things with I7."
The description of the player is "an Imp engaged in coding and testing."
The player wears the Imp's Robe. the description of the Imp's Robe is "the most powerful artifact, surpassing even the One Ring: with it, the owner has the power of building worlds out of nothing !"
[not strictly necessary, but nice to have around. I always prefer that read and examine are different]
A thing has some text called printing. The printing of a thing is usually "".
Understand the command "read" as something new. Understand "read [something]" as reading. Reading is an action applying to one thing, requiring light. Check reading: if the printing of the noun is "", say "Nothing is written on [the noun]." instead. Carry out reading: say "You read: [printing of the noun][line break]". Report reading: do nothing.
outside cottage is a room. "outside a cottage.The entrance is west, and east from here is a path toward the forest you came.[line break] Also, you can enter the outhouse here."
An mailbox is here. "a mailbox is here." A leaflet is in the mailbox. The description of the leaflet is "An advert for a game called Zork I"
The printing of leaflet is "No computer should be without Zork I. Even a tandy ! and don't touch that bit !"
The mailbox is closed, fixed in place and openable. The description of the mailbox is "a [if closed]closed[end if] vanilla mailbox."
instead of taking the mailbox: say "Vandalism isn't the answer to this one."
3 Likes
I apologize if I came off as rude, Piergiorgio_d_errico. Are you saying that since Inform 7 for Linux is unstable and since it’s closed-source, you content yourself with writing very small programs in it?
not precisely content. it’s a powerful language, and it’s a pity that I can’t trust its stability. Disappointed is more precise, I think.
Anyway, I’ll wait the opensource release and let’s put it at par with the current Linux libraries & calls. (the most frequent cause of ni’s instability)
Best regards from Italy,
dott. Piergiorgio.
2 Likes
OK, so when you say that Inform7 is good at scene handling, are you saying that it’s scene-oriented in the sense that you can clump everything related to a particular scene together, as opposed to having to clump everything related to an object together inside that object as is the case for object-oriented programming?
And getting back to ALAN, how does the fact that there’s not much of a core library make ALAN’s parser’s flexibility both a strength and a weakness?
I suspect you have a bit more flexibility in how you arrange your code in Inform 7 as compared to object-oriented languages, but I suspect what Piergiorgio was referring to is the way Inform 7 allows you to divide your story’s action into different named scenes. The documentation explains this concept well, but basically in your code you can manage when different scenes begin or end (or overlap), and apply rules to them the same way you can apply them to the player’s individual actions. I don’t believe any of the other major languages support this feature, though I’m definitely not an expert!
1 Like
My understanding (and someone please correct me if I’m wrong) is that scenes are basically triggers that are checked after or before every action and they’ll fire off when their conditions are met. Like the “waiting for the train” scene is triggered if “you are standing on the train platform while holding a train ticket”. (That’s pseudo code, but knowing I7 it might be legit code.)
But anything can do condition checks, right? That’s not special. What makes scenes special is that they double as a state tracker. They have an optional definable ending that cancels the state (“when the player boards the train”). I7 tracks whether a scene is currently active or inactive, whether it’s been active before, and how many times it’s been active.
All of this for the simple command of something along the lines of: "waiting for the train" is a scene that starts when the player is on the train platform and holding a ticket and ends when the player is on the train. (Again, pseudo code, but pretty close, I think.)
And then you can set actions to automatically happen when entering a scene, or maybe just the first time, or change what a character says or how a verb acts while in that scene, etc.
It makes for some really clean code because you can build the world and how it normally works, but then you can have your scenes for certain moments of the game collected off to the side so you’re not adding situation specific conditions in multiple places in the code. It’s nice and consolidated.
I also thought I remembered TADS3 having scenes too, but I’m not seeing it in the docs. I was pretty sure that’s what I used as a reference when adding scenes to my own engine, so now I’m really confused.
Edit:
Aha. I found it. It’s TADS 3’s adv3lite library that has scenes.
4 Likes
I tried to give a small overview about scenes already way above (in the lower half of that post), but maybe the post was a bit “TL;DR” 
3 Likes
Oh, so you did. I had read it too, now that I see it again. I just forgot because it was days ago, I guess.
It doesn’t seem like Alex had grasped the concept either way though, since they seemed to think scenes had described typical game/movie scenes (scenery, actors, story, etc) and not an I7 concept or keyword.
1 Like
Hehe, yeah, this thread in general is slightly chaotic. 
I think your explanation of what makes I7 scenes interesting & useful was very good.
2 Likes
I think I just forgot to read that part of your post. As you’ve pointed out, this topic has become rather chaotic.
Yeah, it seems events are global states triggered by events/conditions.
In that case, let me summarize as best as I can:
ADRIFT:
Almost everything can be done with drop-down menus. If you want to stick with traditional adventures (exploring the map, finding and manipulating objects, talking to NPCs), you can create pretty much your entire game from the map-view.
You need to be very careful about creating general commands (SHOOT {anything}) and overruling those with specific commands (SHOOT {GUN}). If you are, it’s a great low-threshold IF creation system.
Its “write-from-the-map approach” is very rewarding. Just double-click the map grid fright in front of you to create a location, click on the location to pop up a location window, and create everything in or about that location (e.g. objects, NPCs, and all their commands and tasks) with drop-down menus within the location window. Click and drag to make pathways to other locations. Repeat a few times and you’re good to go.
It’s also easier to create alternative descriptions for changing game states. Just click the bottom of a given description window to create alternative description. Use the drop-down menu to select conditions under which alternative description should be shown to player.
TADS:
TADS’s multiple inheritance makes it susceptible to the diamond problem.
It makes writing conversations easier out of the box than Inform does because TADS makes some elementary decisions on the behalf of the author, and that makes it easier to get started. But you end up having to do more work if you want to deviate from TADS’s creator’s vision in this regard.
- you can use it to implement a hybrid ASK/TELL system with topic suggestions:
“(You could ask Charlie about Dave, or tell him about Edgar.)”
- TopicEntry can also be used to model PC knowledge and extended for NPCs
- it supports forms of greetings and goodbyes, making conversations more natural
- NPCs can initiate conversations
- NPCs can continue talking to the PC, even if the PC is doing something else in the middle of the conversation
- the system has a notion of “nodes” which lend structure to the conversation, affecting the topics which are available at certain points
- you can define one-off commands which are only valid at particular nodes:
“(You could sigh, shake your head, or accuse him of lying.)”
Inform:
Inform has scenes, which are essentially global states triggered by events/conditions.
Eric Eve has implemented a similar conversation conversation system to TADS’s in an extension for Inform.
You have rules for handling actions, but this can get confusing. For example, you might use an “Instead of jumping” rule to quickly override some default behaviour, but you have to keep in mind that this means that the action did not actually take place, as far as Inform is concerned (because we have done something else instead ). So later checks for “If we have jumped” will turn out false, which might not be what you intended.
As another example, you might use a “Carry Out” rule to customize what an action does, and then find out that the Standard Rules have a Report rule which tacks on a message that’s incongruent with what you just implemented.
Dialog:
It’s based on the same concepts as Prolog.
There haven’t been a ton of games made in it because it’s still fairly new (only a few years old), but it’s really complete. It may join the ranks of Inform and TADS in terms of impact. It compiles to zcode so it runs in any interpreter that runs Inform, along with having its own browser implementation that handles clickable links.
Like Inform, Dialog doesn’t have an object model as it’s not object-oriented. The objects act the way they do because they’re the result of a bunch of global rules that manipulate the game logic to give the appearance of objects. This could be considered a drawback, but it can be used in some really powerful ways that would be difficult to implement in other languages.
It enables you to write unit tests in the language itself, and you get a lot of the things you might spend a lot of time implementing in other languages right out of the box.
Finally, one consideration for a simple system is the user interface. If you look at an SA datafile, it’s just a simple table listing of matches, conditionals, and actions. With proper UI implementation, you can have a game that presents the UI progressing from Troll Tales (menu-based) to Mickey’s Space Adventure (point-and-click) to Pirate Adventure (parser-based) all in one game, differing only by the method the interpreter executes the code. You don’t need to change the game data at all! It’s like the Model-View-Controller (MVC) scheme long used by programmers. This would be quite doable in Dialog.
7 Likes
OK, I think the only thing I’m not clear on is how the fact that there’s not much of a core library in ALAN makes its parser’s flexibility both a strength and a weakness?
Well, anyway, based on everything everyone has said here, I think I’ll pick Dialog for my next game and see where to take things from there.
I think it’s very much a “On the one hand, you get to build the parser almost from scratch. On the other hand, you have to build the parser almost from scratch.” kind of problem. (Though I have not worked in ALAN and if I’m wrong, hopefully someone who has will correct me.)
With something like Inform, the parser already has a (large) set of standard verbs and default responses to them in various circumstances. This comes in handy if the thing you’re writing in Inform falls in the “normal range” of parser IF: it has objects and location, and the commands you want to implement fall into the general category of “VERB NOUN, plus standard expanded variations on that for indirect objects, giving NPCs commands, etc.”. This comes in handy: the parser already has a bunch of work done for you with default “that does nothing useful” messages that you can replace if you want, but you don’t have to add the logic in by hand, yourself, for every game you write.
On the other hand, if you want to use Inform 7 or TADS or something along those lines for implementing some very different kind of interface, you have to undo a lot of that work that’s already been done. Inform (and I think TADS) gives you a lot of freedom to do this, but it’s still work you have to do to tear down the structure that’s already there before you can start to build the structure you want to build to replace it. There are of course Inform extensions that help with this, but there’s still the work of building the new interface, dealing with edge cases in user input, anticipating problems, etc. etc. etc.
With ALAN, though, a lot of the grammar has to be defined directly by the user anyway; so if you’re going to do some unusual thing where you’re doing noun-only commands, or a purely conversation-based interface, or a series of nodes in a maze that the PC is traversing as a single move, or a musical game where the commands are certain notes that the player has to whistle on-key to advance, then at least you don’t have to tear out the existing parser structure before you start doing so.
There’s not necessarily a lot of overlap between people who say “I want to write a game where you wake up alone on a deserted spaceship with no memory and have to figure out how you got there” and people who say “I’d like to describe the structure of all legal English-like commands in a BNF-like form,” though, so what counts as a benefit for some people seems like a complex and unnecessary slog to others.
Taking a look at this section of the ALAN manual and the few sections after it might give you an idea of the scope of what’s at stake.
2 Likes
Thank you! That was exactly the sort of answer I was looking for. I really like the way ALAN’s parser seems to work, though, as its “Syntax” approach doesn’t seem to require significantly more effort than other approaches like, say, dobjWaveat(Actor) and iobjWaveAt(dobj, Actor). Dialog seems as though it might be almost as easy to customize, thanks to its logic-programming approach.
1 Like
When Dialog came out, I thought, Oooh, I’m going to take a look at that when it stabilizes. And, of course, I haven’t yet got to doing so. Maybe when this Inform project is finally done …
It’s maybe only fair to say that Inform’s syntax-building rules are more flexible than I presented here, and that chapter 17 (“Understanding”) in Writing with Inform is all about teaching the built-in parser to do what you want.
Anyway. Glad to be helpful! Good luck with your upcoming project.
1 Like
It probably wouldn’t hurt to check out the Inform 7 and Dialog sections of this board, if you haven’t already. I7 is especially informative because you can observe the many difficult problems that are solved easily and efficiently by the knowledgeable users on this board. Dialog to a lesser degree, but the engine is new and the percentage of users is nowhere near I7, so that’s to be expected.
3 Likes