New Inform 7 - Very Cool, But ...

I’m sure you’re most likely right. As I said, it was years ago, and my memory of what was said is dim. In any event, I can certainly understand that Graham prefers to handle WWI himself; his wonderful manual for I6 was what got me into writing IF in the first place. He has a gift for writing tutorial material that is (to borrow a phrase from the DM4) neither leaden nor patronizing.

If I were competent in other areas, I’d volunteer to help. But I’m not.

Lots of good points. It’s fairly clear not much is likely to change on this front and I understand that. I don’t mean to single out one reply or one person, but just to cover what seems to be a theme …

Anyone who knows anything about development knows that developers (should!) want a critical audience because that’s an engaged audience and one that cares. So, actually, James, developers should be glad to hear people not just singing the praises and saying how grateful they are. It’s easy to be someone who just accepts everything. It’s a little more brave to recognize something is cool but also point out some flaws, particularly if you think it could be that much better. If a development crew doesn’t want some unpopular feedback, they are probably in the wrong business and should make nothing publically available.

The case in point for all of this is really simple: there are bugs, as I said, that were found literally within the first hours of release of Inform 7. I’m not condemning Graham or anyone else for that fact. It happens; it’s a fact of development. What I do say, however, is that if, as is apparent, these bugs could have been found that quickly – by people who were not using the in-development release over the course of its development – then why couldn’t they have been found during testing? Maybe they could have, maybe they couldn’t have. It’s quite possible the developers simply get myopic as the release goes on. That happens and it’s understandable. That’s why you open up your development enough to allow people in.

Another case in point: the Windows slow down issue – which I’ve had, and which Zarf has posted a temporary fix to – could have been found before release. It took some of us no time at all to find it: literally just by compiling the simplest of games. Maybe the dev team didn’t have enough Windows machines to test this on? Fine. That’s why you rely on the community; a community that found the issue within moments of release.

Any responsible development team uses a metric of “bugs missed.” You don’t beat yourself up for it, but you do recognize it. And here’s something you can do if you’re curious about Inform development: check back to the posts from Inform’s last release. You’ll see the exact same issue of bugs not found during testing occurred there. And these weren’t hard to reproduce bugs or edge cases: they were stuff people found just by compiling fairly simple starter games.

So how do you do this? People keep saying: Suggestions! I hear no suggestions!

Obviously I gave one repeatedly: open up to the community more. I just repeated how that could be done above. Beyond opening it up more, it’s kind of hard to offer specific suggestions because the process is opaque. I don’t see posts here asking for specific help from the development team. So should I and others just sit here offering random help when we don’t know what problems are being faced? Or should the development team maybe, you know, involve us and clue us in? What seems like a better use of time?

By way of example, consider the Old Republic MMO. (Yes, I know it’s an MMO, not a text game. It’s not free – although it certainly can be. There is a huge player base that pays nothing for it at the moment.) They release updates and expansions on a PTS (Public Test Server). This has helped find numerous bugs in one hour that the development team has missed over the course of a month or more of testing. It’s not perfect, of course, but it leads to a much more dynamic and engaged community.

That alone might be a start with Inform. When a new feature is being considered, like the adaptive prose, build it iteratively. Involve the community in short development spikes to test it out, and get feedback. Find what works, what doesn’t. Have people try it with various extensions and maybe even full games. Don’t work on ten features at once; get that one feature solid as hell.

Look at that! More suggestions. :slight_smile: Maybe the dev team doesn’t want to do any of that. Yet I keep hearing it’s a one-man project with limited time and thus limited bandwidth. Understandable. So does no one see that shorter release cycles, with smaller feature sets, actually means shorter time scales and thus removes some of the limited time and limited bandwidth issues? Does no one see how involving more of the community in an interactive feedback cycle actually improves on time by providing less feature churn and less bug misses?

Maybe we could just turn something that’s already happening into something official.

Unofficially, the week-or-so after a new release is out is the time when the community plays with it and finds out how it’s breaking. This is the time last-minue changes are, or can be, made.

We could just stick a label on that and make it part of the development process. Call it a beta, throw it at the community for us to toy with and break, and use the feedback, without calling it “finished” until there are no more pressing issues to be resolved.

AFAIK, this is already what’s happening, anyway.

If that’s already what’s happening, then it would even more suggest figuring out why bugs are being missed, particularly those found very quickly after “official” release. Also, this doesn’t have to even be “unofficial” or “official.” It’s simply part of how you do development. I would argue that it’s not Inform 7 as a whole that would be “beta” – it would be that particular feature.

If I were in a development team project like Inform, I would do something like the following:

(1) Propose features that are constrained and can be timeboxed into a series of development spikes.
(2) Get feedback on the proposal.
(3) Implement the proposal, releasing each development spike iteratively.
(4) If the proposal passes the “smell test”, then …
(4a) Test it with existing extensions.
(4b) Test it with some of the released “Worked Examples” or the some of the open source games on IFDB.

Item (1) happens a bit with features provided on UserVoice, but there’s no way looking at that to determine if you are dealing with an “epic” or a moderately sized feature. (Well, you can guess based on some of the suggestions, but still: it would be better to have this constrained by an understanding of how systemic the change is.)

Item (2) can happen as it probably does with UserVoice but the trick is rather than entertaining slews of suggestions for a “next release”, you focus on just one or two that can be timeboxed and more easily worked on in a way that maximizes feedback, reduces feature churn, constrains testing, and allows for easier documentation updates since the changes are relatively localized to specific areas of functionality.

Item (3) is critical in terms of keeping the cycles shorter but involving more people. Sometimes people worry that they’ll get too many people participating and thus get flooded. Maybe. You’d have to see. My experience is that not everyone is going to jump on that feature and test it. What you want to cultivate is a set of early adopters in a community. Find out in particular if any hobbyists here have a background in development or testing. (Never saw the development team even ask the community about that.) Try to reach out to those people in particular.

Regarding (4a), ideally you test with all extensions. If those extensions provide examples – which they should! – then testing is a simple matter of first running the extension without changes (regression) to see if it works. Then running the extension modified to support the changes (new feature) to see if it works.

Regarding (4b), ideally the worked examples would be canonical in that they should always be updated to support new features. “Bronze” would probably be a good case of that. (After all, a “worked example” doesn’t make sense unless it works!) This would serve as a nice regression suite in and of itself, where changes are made only a bit at a time since you are working on isolated features rather than swathes of functionality all at once (plus numerous bug fixes!)

A lot of this gets past the notion of “Mega Releases” and instead focuses on smaller releases of core features or even simple QoL (Quality of Life) type stuff. This approach also allows you to “take a break” here and there and perhaps do small maintenance releases with a focus on low-hanging fruit that quite frankly has simply not had the priority, but it’s stuff that people have wanted to get done.

These are just off-the-cuff ideas and would need some revision, of course.

Those bugs are being missed for the same reason that a beta-tester catches bugs or behaviour the author didn’t… it comes with the territory. I’m not sure it would translate into it being at all possible for the team to catch those bugs before release - these are things that crop up as people integrate the new Inform into their projects, which may be doing things none of the development team thought of.

If you are thinking of a “perfect” official release… I have never, ever seen an official release of any software that didn’t need some patching up soon after it was out in the world.

Except maybe for some games back in the nineties. People seemed to be more thorough back then, for some games, in some studios. But a game is not like development software, of course…

That is argued against by the very fact that some bugs were found within moments. You are correct: not all bugs can be found. I get that. But some clearly could have. Some of these bugs literally came up by testing an already-existing extension, which had examples in it. So literally it was just a matter of a simple couple-room game that includes the extension. The Windows slow down. Again, could easily have been caught before release: you simply create a multi-room game. (Granted, there you might not have the Windows machines among the development staff. So: poll the community – “Windows Users! We need you. Check out this new release, tell us if you have any issues.”)

Again, you are correct – not all issues can be found. No one is saying that. But you have a much better chance of finding bugs, the more people you involve and the more constrained your feature set is that requires testing in the first place. This is obvious stuff! :slight_smile: When you have less to test and more varied people testing it, things tend to get found quicker. And that means you fix them quicker. And that means you have less knock-on effects (regression) because the area being changed is smaller. That means documentation is easier to update. That means you can more quickly get on to the next exciting feature you want to work on.

While I still stand in my opinion - that Inform is a Gift rather than an Appointment; but that’s pretty personal - I’d like to stress out that it was not about the contents but about the tone. I didn’t like the repeating three years, and that’s all. And I want to stress out, also, that I was probably in the worst possibile mood to try and post something (41 yo and still making teen mistakes, it figures). Along comes the fact that I may even have misunderstood your tone being no native speaker. So, it’s better I apologize and we forget this thing.

I’m with Peter when he says that we are already having the beta test session in these post-release days. I was not aware/present at the time when the last release was out, so I don’t know if the bugs discovered back then have been later corrected (like, immediately) or we had to wait for 6L02. If the latter is the case, I suppose it is better if a new release comes out in a few days. (But, then again, I’m not complaining :slight_smile: )

On behalf of the “continuing upgrade”, although it looks like a very viable option, I sense a problem.
In my specific case, I have been working on a game for a couple of months when the new Inform7 came out. I have now to update and change 3/4 of the content, while abandoning an extension for another one (which seems pretty cooler, atm). Games, stories sometimes take ages to be completed. I wouldn’t want to remake the same things over and over while the system gets updated every three weeks. It’s not exactly like a MMORPG, in which you are usually pretty passive on the changes made to the system; but I can remember very well how I got frustrated when I had to re-roll my character or change the fight system every month because of an update on the Warlock in Warcraft.
I can’t actually foresee how the “continuing upgrade” would spoil my programming, but I guess it’s a point that has to be taken.

Have a nice time.

That’s how EVERY SINGLE bug passes the programming-stage. Had we the gift to think about everything and to foresee the future, beta testers would not be needed. There is ALWAYS a bug that “could have been found”. :slight_smile:

For the purpose of your peace of mind, let me assure you as a native speaker of English that you understood his tone perfectly.

And that’s fair. Perhaps I was being a bit over the top there. On the other hand, it was deliberate to make a point: not so much about bugs being missed, but about how three years is just way too long given that it actually puts more stress on a limited development team. In fact, to your point:

So here’s a case where you could consider more limited feature changes as a benefit, which is exactly the point I’ve been making.

This current release is, so far as I know, the most comprehensive in terms of breaking existing features. That tends not to be the case, as least so far as I’ve seen with Inform. However, it shows my point: there are now multiple new features and multiple new changes all at once – because there were three years to develop all of them. This includes not just compiler changes, but language changes, and even interface changes, combined with lots of documentation changes. Whereas a shorter release cycle, with more minimal goals, would have only perhaps one major feature change and even that could be an iterative one. Also, Inform does have the provision for “deprecated features” and that could be used as well.

Do note that a lot of what I’m saying about limited feature changes presumes you can make such limits. If Inform tightly couples parts of itself to every other part of itself, that actually could be a big problem. Which is another reason why you want modern development practices in place to make sure you don’t do that. (Consider the AGS development system. When it went open source and got more iterative, it got a much better code base that actually opened up what the system could do and a large part of that was because the original was very, very hard to maintain due to a less than optimum architecture.)

This is true. But a good development team looks at how easy a bug was to find and considers that. The most common question: “What’s the earliest time we could have caught that?” I don’t know why people here seemingly can’t make that distinction; I don’t mean that to you personally, but I say it because it seems to be a common refrain. Consider, what should be more likely?

  • Missing a really hard-to-find edge case that requires two extensions working together along with an I6 inclusion.
  • Missing a case where a three room game takes much longer to compile.

If you miss the former, well, yeah. Okay. If you miss the latter, well, still okay. But you have to consider your testing in relation to that fact. Again, this is what development teams do! And it’s for their own benefit! No one likes fixing bugs. You’d rather be developing the next cool feature, rather than fixing all the things you missed – because that now requires another release just to fix bugs. (Or you keep the bugs around for years until you have your new features.)

But as Whyld pointed out, there’s a serious advantage to Inform’s present way of doing things: for three years, Inform has been quite stable, and a lot of authors who are working on their WiPs have the choice to stick to the previous build rather than switching. They can do that because the previous build was so stable already. A gradual implementation would probably be more disruptive, as bug-fixing would go hand-in-hand with source-code-mangling. “Here, we’ve fixed the bug you needed fixing for your Wip…” “Huzzah!” “…but we’ve also implemented other features and fixed other bugs that mean you’ll have to retouch most of your code” “Oh. Crap.” If the game is big enough…

As it currently stands, Inform disrupts existing code every year, or every two years, or every three years, and provides extensive documentation on what’s changed. The alternative - possibility of disrupting some code now, then some code later, then possibly back-tracking because what was done before wasn’t as good as something else we just thought of - seems very, very painful.

Which brings me to another point, I guess. This way, Inform is released like a novel, with the possibility of future editions correcting a few mistakes. If it were released the way you suggest, it would be more like releasing drafts, individual chapters… and what if, mid-novel, you want to re-write the first chapter? You’re screwed, and so are your readers.

Mind that, of course, serialised novels do exist. Meaning, your suggestions are valid. I’m just enjoying the discussion. :slight_smile:

Fair. But is this assuming that all feature changes must be massively comprehensive, requiring tons of change every time? Does this assume that additional features equate to lack of stability? Does it mean games in development must fall into the either-or of “upgrade or not”? Genuine questions, as I don’t know.

People tend to assume that more rapid releases means less stability, more churn, more uncertainty, etc. The development industry as a whole, whether in game development shops or otherwise, has largely shown that to be false. (Obviously much of this has to do with situational concerns, so it’s a broad brush to paint with.)

Consider: Google Chrome does updates pretty much all the time and people’s sites, by and large, continue to work. People aren’t having to redo their CSS or JavaScript every time. Most people don’t even know when their Chrome updates. Firefox has a rapid release cycle and, again, not every site has to change its HTML, CSS, or JavaScript to accommodate each and every change. AGS (graphical game system) releases a new system very regularly (now, anyway) and unless there are stated backwards compatibility breaking things, people’s games continue to work and run just fine. Minecraft makes lots of changes and while there have been some compatibility breaking stuff, most people play (build their worlds) just fine regularly – and their plugin authoring works as before – even with those relatively rapid changes.

None of those are Inform, I realize. But I point them out to show that you can have very visible projects, heavily used, with lots of people doing lots of things, and have more iterative release cycles without entire disruption to people using those solutions (whether that use involves writing web pages, creating a graphical game, or writing plugins for a system). Further, if the changes are small enough and appear more harmful than helpful, they can more easily be backed out or made as alternative implementations rather than as the only.

So maybe we have our first operational question: What impacts would a more rapid release cycle have on Inform authors?

The problem there is it’s entirely theoretical. To even begin to answer it,of course, requires considering it not in the abstract but with specific examples. Yet in lieu of that, we have to use our best guesses or actually try it out for a given feature.

And, mind, none of this says that sometimes you won’t have the Mega Release type thing that is a breaker for a lot and has impact on authors. Consider when Minecraft changed its entire permissions system. It was massively disruptive to plugin authors, but it happened only once. Consider when AGS changed how it recognized native system resolutions. Very disruptive to game authors but also a very rare release. Consider (way back) when Firefox changed its JavaScript engine. Not fun for developers (or users!), but also not a regular occurrence.

Fair questions. Here are some more which I also don’t know about - what exactly entails a new Inform release in terms of installation? In terms of overriding existing user content? How much work is it? Is it worth reinstalling the whole thing every time there’s a nre minor release if there are lots of them? In minor releases, portable .zipped upgrades seem a better idea, but is this possible given I7’s structure? Again, I don’t know the answer. Maybe someone can illuminate us. :slight_smile: “Additional features equating to lack of stability” has to do with I7’s nature, which I’ll come to shortly.

True, rapid releases don’t have to be as negative as all that. But given the context of any given individual piece of software, one has to consider whether the benefits of changing outweigh the hardship and inconvenience of altering an existing, establish modus operandi - in this case, one that’s so many years old, and still hinges on one single person. Personally, if we have in GN a “benevolent dictator”, I wouldn’t have it any other way, since he’s clearly open to advice, and he clearly values some people’s advice more than others: he has a group of people like Zarf and Short whom he respects so much he allows them to shape Inform, and he also values the community’s input (as seen by the bug reports and suggestions taken up) to a lesser but important and decisive degree. Again, I wouldn’t have it any other way - the man knows what he’s doing. And he’s got class.

Here’s my flimsy argument: that’s right, none of them are Inform. Not much of an argument, yeah? But consider the complexity that goes into I7, the fact that it’s still shifting and metamorphosing into better shapes (case in point: the Response system). It’s not finished yet, the same way that I6 is finished, but actively growing and getting better, and its users are doing, as a matter of course, things of great complexity that make full use of the system’s versatility. Although I don’t have any figures or fact to back my next statement up, I would imagine that the percentage of Inform 7 users that make complex use of it is bigger than the percentage of users of any of the other systems you’ve mentioned (doing complex, system-bending stuff). Every system has a number of people that bends it beyond belief, but in our smaller community, a larger percentage of us does it because the thing is so damn flexible and thought-provoking and inspiring. Consider Counterfeit Monkey as the most recent example… Consider even the various ZMachine abuses throughout the years…

EDIT - Also, AFAIK, the main platform I7 is designed for is the mac. I7 also needs to be available, at time of release, for Windows and Linux, and these understakings are done by a different set of people. That can’t be easy to maintain in short bursts of releases.

Actually the Inform builds kind of mirror on a larger scale what authors do with interactive fiction games:

  1. Worked on in secret. It’s your baby. It’s going to live, and you will show it to no one!
  2. Possibly solicit advice on the hard to manage parts from your closest ally.
  3. Release it to a very narrow group who know what they are doing and have your confidence and discretion.
  4. Release it to the public, where some people are like “huzzah!” and others get ready to tear it apart, “Um, on the first screen, you spelled your name wrong…”
  5. Fix all the post release bugs.

Well spotted. We’re a secretive bunch. DaveC had it right - we’re a herd of cats, man!

Ha, perhaps so. But remember herd behavior is rarely what you want:

It’s not exactly a compliment. :slight_smile: Most cats I know – and I own six – are not really secretive; they are often very stubborn though and rarely listen to what anyone says.

Seriously, it’s genuinely a pity to me that there isn’t more active discussion about the Inform development process and maybe even a bit more experimentation. I think the Inform development team could actually open itself up to some cool ideas and new ways of doing things that may have very positive impacts on Inform development. But it requires trying new things (albeit, in a responsible way). I see that trying to get the developers to experiment with that – or even talk about it substantively – is probably a bit of a lost cause and I would eventually (if have not already) cross the line from being supportive-but-critical to simply being critical. It was worth a try, if nothing else.

The Inform community has mostly given up on changing Graham’s mind about this, and Graham has mostly given up on reading people’s arguments about how Inform should be developed differently. (I doubt he’s reading any posts in this thread, for example.)

Your best bet at this point is to take the open-source materials that Graham has made available, fork it, and make it obviously better than Inform. But who has that much time?

For my opinion, Inform is only being developed somewhat suboptimally, but it’s not a big deal. At least somebody’s working on it!

“The Dude abides. I don’t know about you, but I take comfort in that. It’s good knowin’ he’s out there.”

Shame. He’d see a lot of support, and he’d see that even the criticism is well-meaning and constructive.

But I totally understand it. It’d be emotionally draining to have to read this sort of thing every time it came up.

Personally I find GN to be a sort of God-like creature. I have faith he exists, and he occasionally blesses us with a miracle in the shape of the newest I7. But I know him only by his prophets, who populate the board, and by the sacred texts, the DM4 and WiI.

Hey, belief in GN has given me more than belief in God ever has.

I always feel obligated somehow to comment on these half-baked kinds of posts because I’m a professional software dev who’s not on the Inform7 dev team, but who still stands with a few others as being slightly more “in” with the dev team than most.

I think their existing process is fine. Lots of little release aren’t inherently better than fewer bigger ones. Feedback from large groups is frequently self-contradictory. Few actual game authors would want to pull down daily builds because it’s spending time not building a game. There will always be day-one bugs on major releases no matter how many testers you have. And when a new build finally comes out, it is an event as real as the annual Comp.

The dev team listens a lot to many communities besides this forum’s: the educational community which teaches to schoolchildren, the academic community aiming for e-literature, the non-coder i-f community which ping-pongs between Inform and Twine. For example, the telemetry options were added for teachers to ease gathering students’ classwork. The fact that Glulx is now the default was due to large and sustained community outcry, which I infer Graham wasn’t overly thrilled about.

And ordinary forum people here can get an elevated role in pre-release testing the same way as in the corporate world: bring something undeniably useful to the table. For example, I’ve been invited several times to help test pre-release builds, because one of my extensions or Mantis code patches become part of Inform. My “[we]” category of substitutions that’s now in 6L02 was originally expressed not as a 5-minute forum post telling the devs what they should do, but as working code which first proved itself in the marketplace.

Suggestions which can’t be “proved” in working code nor a great game have a formal process at UserVoice voting site to gather as many votes as the idea merits. Threads like this should only exist for raising awareness of a particular UserVoice suggestion.