and what is better and worse about it compared to TADS 3
Eric’s article (the link above) is very good. I’ve written games using both systems, and I can summarize my experiences briefly:
I7 is easier to get started with than T3. But as you get more familiar with the language and want to do more complex things, T3 becomes easier to work with than I7. For that and other reasons, I tend to think of T3 as “the IF programming language for grown-ups.” I can articulate my reasons for thinking this if you’re interested.
If you’re using Windows, T3 has a very nice front end called Workbench, which is similar in concept (though not in details) to the I7 IDE. However, Workbench does not run natively on Mac or Linux. I’ve used it under Crossover (currently $29) on the Mac, and it works about 99% – a couple of features aren’t quite right.
T3 has a much larger built-in library of game features than I7. You can create a flashlight or a ship’s deck and cabins, for instance, using built-in widgets, and never need extensions. However, I7 has a large and enthusiastic community of folks who are writing extensions; T3 doesn’t.
T3 is stable. I7 is still in development, which means it’s in a state of flux.
If you’re interested in letting players run your games in a web browser, I7 (and for that matter, I6) has a big advantage: the Parchment and Quixe interpreters. Before too long T3 may have something even cooler in the way of a Web-based gaming experience, but it’s going to require that the author jump through some extra hoops, and it’s still not released.
Let’s not forget Inform 6, though. It’s fully functional, it’s stable, it has its own suite of debugging tools, it’s considerably easier to learn than T3, there’s a good-sized list of extensions you can download, and it presents the author with a programming syntax that is, in my opinion, more straightforward than I7’s. Of course, there’s no front end for programming – you’ll have to download a text editor and an interpreter. But that’s not a deal-breaker.
This is a question that has been asked many times, and people tend to have very strong opinions on the topic. If I recall correctly, you’re planning on working with other people on this project, so it may be relevant to you that one of the nice things about Inform7’s syntax is that it’s fairly easy to read*, which may help if you are in the habit of regularly passing code between project partners.
*which is not at all to say that it’s necessarily easy to write! Personally, I’ve gotten used to it and am quite happy with I7, but the “natural language” aspect of Inform7 (that is, where the code “looks like” real English) can be very, very frustrating to work with. Some people claim that it’s even worse for programmers who are used to writing in other languages, because it looks wrong, but I’d actually say that it’s worse for people who don’t have much experience programming and therefore don’t have a built-up understanding of what kinds of things ought to work.
Unless you happen to use a Mac, I think. Doesn’t Inform’s IDE for the Mac function as a front end to Inform 6 as well?
No. Those features are non-functional. They’re stubs that have never been properly fleshed out.
Ah, that’s a pity.
I’ve been struggling with Inform. It isn’t so much a “programming language” as it just “just a language”. Tads seems more like a programming language. I can’t disagree with Jim, as he obviously as worlds more experience than I do and I’m copying stuff from his “Inform Handbook” more than I’m writing stuff on my own.
I honestly think, from what I’ve seen, that Inform is just as powerful as Tads, there’s just a different way of getting there. As far as I can tell, extensions for Inform don’t ADD anything to the system. They simply give you a different (and sometimes easier) way of coming to the same solution.
My struggle with Inform has been accepting it as a programming language. I think I would have a much easier time picking up and learning something like Tads or Inform 6. But because I’m stubborn, I choose to try to learn the “natural language” structure of Inform 7.
I all boils down to how your brain works. If you can more easily “visualize” code as a set of variables, functions, classes and declarations read in the sequence and structure that YOU define, then by all means go with Tads or Inform 6. If, however, you have no foundation or preconceived notion of what a programming language should look like and your brain is more comfortable reading sentences instead of lines of code, Inform 7 should definitely be your cup o’ tea.
That said, I do think Inform’s sense of precedence and structure should be heavily re-evaluated.
But that’s a segue.
Yes. When you create a new project, you can select either Inform 7 or Inform 6.3. The Index tab doesn’t work with an I6 project, and the I6 designer’s manual isn’t included, but the IDE works.
In coming to make my first IF in a modern language, I was coming from being a black belt in Applesoft BASIC and a green belt in 8/16 bit assembly language. I was open to using either TADS or Inform. I just wanted to use whichever one I felt I could understand and learn more easily.
I downloaded the TADs docs first, and in reading them I learned more about these modern concepts like classes and such than I ever learned from past casual encounters. So that was a good learning experience. But it was still apparent that TADs would be far more like those other modern languages in syntax than Inform would, and I didn’t really want to get into that. So I got Aaron Reed’s book and I got into Inform. It’s working out great with my game. I don’t like command lines much either, and the TADs graphical frontend for Mac is not up to date, whereas Inform’s IDE is integral to it, so that was another choice for a person like me.
I’ve no doubt both systems are great. Individuals just need to find the one that suits their programming styles and habits, what OS they use, how they like to use that OS, are there any post-game issues you’re interested in (like Inform’s online-ability.) etc.
Is it though?
Compared to T3 code separated out into different files and demarcated into classes and methods with braces, I struggle to actually find my place in I7. (I think something that might help would be if the headers were more like the headers in Microsoft Office 2007+, with increasing sizes and boldness as you move up the hierarchy.)
Hm, I meant more at the sentence level. (I don’t find I7 particularly bad at the overall project level either, but 1) I tend to make small projects, and 2) my code organization skills are not great anyway.) Now, I’ve never actually worked with T3, but in other similarly-syntaxed languages I’ve used, my problem is always that I’ll inevitably have to look at the documentation for a method when I’m reading it again later because I’ve forgotten what the arguments are or what order they are supposed to be supplied in. For an obvious case that would probably never actually be a problem if I’d written a game using it, but to grab some code from that comparison page, in “redBall:Thing ‘red ball’ ‘red ball’ @garden;” I could very easily see myself wondering, “wait, is the first ‘red ball’ the [in Informese] printed name, or the understood name?” Now, in Inform, if I wanted to change the “printed name” I’d still possibly be dicey on whether or not I remembered the “printed name” incantation in the first place to write it, but I would have no trouble reading it later.
But again, of course, it all comes down to personal style, and maybe I’m more forgetful than average (I do tend to comment the heck out of my non-Inform code).
The macro abbreviations are one of things I love most about T3, but you don’t have to use them. You can name those properties explicitly when you set them (“name” and “vocabWords” respectively).
I don’t see much difference myself. It’s really cool that a declaration in I7 can be exactly what you mean in game terms (“After looking in the grassy knoll, now the JFK conspiracy is solved.”) but the conciseness of T3 makes it nicely to the point.