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. 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?