Since I know English already, that’s a big hurdle cleared with Inform 7, and learning the idiosyncratic Inform-English was a lot easier when I got to the point I wanted to do more complicated things. I was “hooked” and willing to learn later in the process since I’d already experienced how useful it is.
I’m not saying anyone is wrong if they don’t like Inform 7, and I readily admit the learning-curve steepens as you get further into it. I’m just saying $m39m4’s experience isn’t the definitive one, and it’s a little too easily reductionist for them to just declare I7 is “a mess” when so many people have found success and made games with it.
This is the crux of every design discussion–what you have already done matters a lot more than what you think you can do. I personally have all sorts of crazy design theories I talk about a lot, but I don’t expect anyone to take it seriously without making a game showcasing it. And like you said, it’s hard to claim that a language is bad without demonstrating that you can make something much better in another language.
For instance, with Aikin’s games, Not Just an Ordinary Ballerina was the second ‘big game’ I ever played, and I loved it; Lydia’s Heart is bigger and better, but not so much better than Ballerina that I think ‘TADS is a much better language than Inform’.
Along similar lines, a very minor rant about bashing existing development systems.
I think people also tend to overestimate their own understanding of how things “ought” to be, and underestimate the amount of history, design, and forethought that went into something like TADS or I7. (I’ll limit my comments to I7 since I’m most familiar with that.)
I7 is a third- or fourth-generation tool built from the collective experience and design input of some of the absolute gods of IF (Graham Nelson, Emily Short, zarf, Jesse McGrew). It’s far more than just a natural-language syntax wrapper for I6/Z-code; it’s a complete reimagining of how the IF workflow could look. I remember actually giggling out loud the first time I fully understood the genius that is the rulebook system.
“I7 is good until you try to do anything complicated” is kind of a myth, IMHO. I7 is very, very good at what it does; it’s just that there are some odd points in the learning curve where the trees look weird until you understand the forest. (It’s worth noting that Hadean Lands and Counterfeit Monkey, two of the most technically complicated parser games ever released, were both written in I7.)
Now, if you want to do something I7 isn’t designed to do - like advanced multimedia, or experimental UIs, or you just have a cool idea about how to structure the world model - by all means, create your amazing C# class library and unleash it on the world. New systems are awesome and experiments like that are how the medium advances. But please, have a little humility and don’t diss what you don’t understand.
My opinion is immature, since it’s only been a week that I’ve known about this community. I’m studying the best options, and for everything available, I think TADS is better since coding isn’t a problem for me. I think TADS is easier to understand. That said, every component in I7 is completely non-proprietary, which is insane but smart in the other sense. Neither platform is perfect. I7’s advantage is also its disadvantage. TADS is proprietary and restrictive. It’s also loosely-typed, and not that well documented, mostly because it’s loosely typed. It’s not enough to say that a parameter is a list that will be used to do X. It’s a list of what? Documentation is not as necessary if a compiler complains that what I’m feeding a method with is garbage. Programming becomes more intuitive.
Both seem to do too much. All I wish for is to have a dynamic link library to work with using a well-known programming language (that’s strongly-typed please), and allow people to develop off that. Give me the parser, interpreter, and the a library of objects that the parser understands. Keep the inner workings sealed; I don’t care. But don’t dictate how the game should be displayed. Offer a front-end solution, but make it a choice.
MVC/MVVM or die.
I don’t want to reinvent the wheel; that’s why I’m examining the options available. I’m sure both Inform and TADS have good algorithms, and I would like to see them ported, rather than contended with.
The history of IF is what dictates the display. This type of game originated in the days when a text-based command line was the ONLY thing a computer could display. Everything that IF game-play software does today is still hanging from that hook.
Any time you start thinking about display options, programming gets more complicated by an order of magnitude. Now you’re talking about graphics-based games, not text games. I mentioned Undum (vorple-if.com/vorple/doc/undum/e … orple.html). With this system you get a much nicer browser-based graphic environment for your interactive story. What you don’t get is a parser or a library of objects.
Undum is not in active development – but since you’re a real programmer, I would urge you to give it a serious look. If you were to write your own parser and library (in javascript) and graft them into Undum’s existing framework (somehow), you might have exactly what you want, and you might attract a few other authors in this community to use your authoring tools.
In fact, this is exactly what I’ve been wishing someone in this community would do!
Also to be fair, Inform 7 is designed to create a game in the very specific template created by Infocom, and its output is straight up text, no matter what font, what color, what background image, or CSS. There are transcripts of Enchanter that are in all-caps.
Inform actually probably offers more options than the Imps had in their day, and the fact it will build you an entire website with your game playable is a good starting point to customizing the output.
So the output is highly dependent on the interpreter and its functionality, which is why Vorple exists. Problem is, you can’t always count on what interpreter the player will use unless you only release as a website, and then it also can be dependent on the browser used.
I know there are ways to wrap that website in an app for more control. It’s easy on Mac with Fluid, and there are other options on Windows.
True, but there aren’t that many browsers. Your game beta-testers would have to include both Mac and Windows users, because the browser behavior can differ from one OS to the other. (Linux users can debug the javascript themselves, right? That’s what they do for fun!)
Yup, I know. I think the market dictates the importance of this type of game. I’m not sure how correct I would be to say that the ratio of IF makers is disproportionately high for its consumer base. I wonder what the market looks on the adult content side of things…
You see, I don’t agree. I looked at Vorple, and it’s my opinion that it’s rather useless. Vorple is just a series of functions designed to “help” get the html syntax right, which saves about zero time; if you’re already dabbling in javascript/html/css, you already know how to form image tags and whatnot… Which brings me to this ultimate point: If people are so ready to learn these esoteric languages to get something done, why not understand the mainstream ones? Undum is much more useful, but as you pointed out earlier, it only organizes links in such a way that a story having multiple outcomes is shown in an elegant way.
His/her library is insignificant compared to the richness of TADS and Inform. It’s really night and day in terms of work. If I were to make such a javascript engine, and if I had decided to include a front-end solution (displaying solution), then I’d just go the extra mile and make my own without using his/her work, which if you checked the source code, he/she had included works from other programmers.
It’s a lot of work to do for free, but it would probably put every other solution to shame.
It would, and yet it wouldn’t. If you (or someone else) were to do this, the quality of the games and stories that could be created would be far, far beyond anything we have today. And yet nothing would change.
First, most authors of IF (a tiny community to begin with) are not real programmers, and would flee in droves from any suggestion that they ought to learn javascript.
Second, the presentation layer – graphics, text blocks that adjust themselves on the fly, in-game-object toolboxes with drag and drop, you name it – matters less than the ability to tell a coherent and meaningful story. You can tell a coherent and meaningful story (or fail to) using a typewriter. Ultimately, the presentation layer is just eye candy.
For those two reasons, IF will continue to muddle along using development systems that are (barely) “good enough.”
To make games, you need programmers. It doesn’t look like IF is the odd man out here. In fact, it looks like the opposite is true. IF requires less programming than other game genres, even if you’re using TADS, as the most difficult parts of the programming are handled for you, and you only have to program the game logic.
I suspect this is a case of “you don’t even know how good you have it” syndrome
By the way (as a general comment), doesn’t Hugo have video, sound, flexible windows, etc.? Cryptozookeeper is fully illustrated and has a soundtrack, while Future Boy! had voice acting and animations.
The frustrating thing is that Lectrote and the web Hugo (Hugor?) both run Hugo pretty well, but neither one supports saving and restoring (at least the github version of Lectrote I compiled and the web version of Hugor at textadventures.online).
