I’ve heard people on here mention before that, instead of making new development systems, they wish people would work on the older tools in maintaining and updating them.
With that in mind, what is your ‘wishlist’ for improvements to old tools? And, to help with anyone who would actually like to work on the improvement, why is it difficult to do, what approaches would you suggest, and how much time do you think it would take?
Twine and Inform are in active development as is zilf, a very old tool. I would like to see TADS and its interpreters maintained.
I do very much enjoy Dialog and its development. It is refreshing to see the developer that is very active here and watch him refine and add new features based on input here.
v/r
Jeff
Dialog is great, I completely agree! This in no way is a dig at Dialog. The fact that people are using it and it compiles to polished games already places it in the same tier as TADS, Inform, and zilf for me.
This is more about people who come into the community saying they want to improve everyone’s lives. Having a list of achievable goals could help match talent with problem.
Gargoyle needs a new release. It’s not completely abandoned, and the person who has been in charge hasn’t disappeared, but discussions are slow to progress. I’m not sure what the solution is.
There’s this list that @mulehollandaise did on IFWiki a few years ago. It doesn’t seem to have been updated recently, so some things are out of date (about Vorple, for exemple).
But still a useful ressource, I believe.
TL;DR: People have different reasons for fixing old tools than they have for creating new tools. Instead of asking why new users don’t show up to fix existing tools, it might make more sense to ask what’s been keeping existing users from fixing problems with existing tools.
And, to help with anyone who would actually like to work on the improvement, why is it difficult to do, what approaches would you suggest, and how much time do you think it would take?
I’m not familiar with whatever backlog the popular software here has, but I’ve seen this same sort of discussion crop up in several software communities now. Here are some patterns I notice.
Difficulty getting old software updated can stem from any number of things:
Not open source; no available path for user contributions.
Distributed under a restrictive license that turns potential contributors away.
Maintainers are very slow to accept patches / pull requests.
Code is a mess, or targets outdated language version, or otherwise a maintenance headache.
Users generally not proficient in language / frameworks being used.
Those are just off the top of my head, I’m sure there are more. With projects that maintain an issue tracker, keep up with patch sumissions / pull requests (either accepting or rejecting them in a reasonable amount of time), keep up with changes in language, and has users interested in and capable of helping maintain the software, I haven’t seen these problems as nearly often.
But these contributions almost always come from people that are already using the tools and have identified problems that they want fixed, not by new users, who tend to be largely unfamiliar with existing problems with tools.
The exception to this is new users who show up because they found a problem with a tool and are seeking help with that (or already figured out a fix).
instead of making new development systems, they wish people would work on the older tools in maintaining and updating them.
Even if none of the problems on the list above exist, there are plenty of reasons why this doesn’t happen.
Making new things is more fun than maintaining old things. If people are doing it for fun, rather than because they have a problem with a tool they use, expect this.
New contributions can play with new ideas without worrying about past baggage. If the ideas work, existing tools can adopt them.
New contributions can put pressure on existing tools through friendly competition. If a new tool provides some features that a tool in closed development lacks, they may choose to adopt those features in order to keep their users. This can be a way to get features into tools that are in closed development. If the new tool is published under a non-restrictive license, the existing tools would be free to borrow code directly from the new tools.
In other words, lamenting time spent on new tools doing new things or doing old things in innovative ways, because it’s not time spent on maintaining old tools, could be short-sighted.
This is more about people who come into the community saying they want to improve everyone’s lives.
Does this actually happen? In my experience, new arrivals are unlikely to show up because they want to solve old problems with old tools. New arrivals to the community are less likely to be using the old tools. People who don’t use those tools are much less likely to start fixing problems with them.
And generally people don’t show up in new communities because they want to improve everyone’s lives. There’s some aspect of what the community is about that’s interesting to them, and they want to discuss it. Instead of expecting them to get to work fixing the existing toolset, maybe see if they can bring a different perspective instead.
Old tools are fixed out of necessity. New tools are created for any number of reasons besides necessity: just for fun, for personal enrichment, for the sake of experimentation. To people who are not using the old tools, fixing them is unnecessary. New users are less likely to be using the existing tools, so they’re less likely to be fixing them up.
One consideration is that often the people that use a specific software Framework / Engine / Game Maker don’t have the programming skills to enhance it.
eg. Many of the users of the Twine 2.x application are Writers / Authors / Artists, and not software developers / programmers.
I haven’t really seen people lamenting that. People here are usually pretty interested to see new projects doing these things.
But over the years I’ve also seen many people come here to announce a barely complete project that is a poor imitation of Zork, with seemingly little awareness of the many directions the community has developed and experimented since then. Most of the time there’s no problem with such projects, we’ll collectively say “Cool, nice work,” but on very rare occasions you’ll get someone who seems to think the community owes them appreciation or interest. Which isn’t how anything works. Just as there’s no obligation for anyone to work on any particular project or problem, there’s no obligation for anyone in the community to be interested in anyone else’s work. If you want interest, know the community so that you can do something actually innovative. If you want appreciation, helping with the infrastructure is fantastic.
I haven’t really seen people lamenting that. People here are usually pretty interested to see new projects doing these things.
That was in response to this:
I’ve heard people on here mention before that, instead of making new development systems, they wish people would work on the older tools in maintaining and updating them.
I understand what you’re saying, though. This only applies to new development systems that aren’t doing anything innovative or new. Fair enough, but then it seems like something is missing here:
But over the years I’ve also seen many people come here to announce a barely complete project that is a poor imitation of Zork, with seemingly little awareness of the many directions the community has developed and experimented since then.
What you’re talking about here is the end result of what’s presumably a demonstration of the engine. Zork is old hat, people do all kinds cool new games now, I get that. But this doesn’t take into account whether that Zork clone is innovative under the hood. Even if the game plays exactly like Zork, the system underneath could be innovative – is it? Is the system also appropriate for creating games that go in the other directions you mention? Does it make creating those games easier or more enjoyable?
If not, and if people want attention for a system that’s really not doing anything innovative, I agree that’s annoying. Pointing out that the existing systems have already innovated whatever is thought to be original should address it.
But just looking at the end result and saying “it’s just Zork” doesn’t seem like a fair consideration of the system under the hood.
I think part of the disconnect here may be that there’s more of a retrocomputing aspect to this community than other communities that seem similar at a glance. What I mean is that there’s a lot of attention payed to making new things run in the old interpreters, where some other communities are more focused on making an old family of games run on modern systems (and secondarily, support for modding those games).
So maybe this is something like showing up to an antique car show asking for input on a prototype for a 2020 model car? I don’t know. What interests me personally is the prospect of creating old-style text adventures while levaraging modern computing power. I feel like this opens the door to designing a very simple language that’s expressive and easy to implement, but would have been prohibitively expensive (computationally) 30 years ago. Essentially, offloading the more fiddly stuff onto the CPU. I don’t know whether that’s the kind of thing the community is interested in, though… part of the reason I’m here is to find that out. I notice there are at least a few people here interested in graph-driven systems, and inferential engines, so that’s promising.
It’s the developers responsibility to explain what makes their project interesting, whether that’s easily visible or not.
No I think you’ve got it backwards. I think many newcomers to the community assume there’s a much bigger retrocomputing aspect that there is. For sure it’s there in part: ZILF wouldn’t have the interest it does if there were no retrocomputing enthusiasts. But I think for many in the community having comparisons drawn repeatedly back to the past can be discouraging. Article titles like this one are insulting: “Text adventures are back from the dead” (Polygon). To take your car show analogy, it’s more like turning up to next years F1 with a hand made Ferrari 246 F1.
Sentences like these are part of the problem. I don’t know exactly what you’re referring to, but if I read that the least charitably I can it sounds incredibly condescending. What do you think the community has been doing? Leveraging modern computing power isn’t a prospect, it’s bread and butter. Expressive languages aren’t behind a closed door, they’re decades old.
I wish someone would maintain the Gargoyle project (crossplatform C++). It’s so dead I have to recommend Lectrote as a main Windows interpreter.
By the way, Lectrote itself (Javascript on Electron) needs help: last commit was more than a year ago. It could use some optimization and host more web interpreters like Quest, Texture, Squiffy, ChoiceScript, INSTEAD, Adventuron, webURQ.
There’re no Javascript interpreters (the kind where the author doesn’t have to host a server) for TADS and ADRIFT, so those engines go obsolete without online games.
And there’s a whole empty niche of IF planning tools like plotex where the author can put in the game rules and the script checks if the game is winnable and if there are alternative solutions. Our computers are already powerful enough to bruteforce this combinatorial explosion.
It’s not intended to be condescending in any way. I’m interested in inferential engines on top of graph-driven systems, as mentioned in the last sentence of that paragraph (not quoted). Inferential engines, historically, have been too slow to be practical for games. What I’m not talking about is memory-hungry frameworks like Electron to do the same job that a simple console would have done in the past (I don’t know if that’s the sort of thing you thought I meant).
For example, consider how Prolog wouldn’t have been sensible for anything time-critical around the time of its inception, but now days it can be. Even though it’s still comparatively slow, I think you could do parser games in it now, but I doubt you could have in the 80s. This is what I mean by leveraging modern computing power.
Even more specifically, what interests me is the marriage of expressiveness, ease of implementation for language interpreter, and an inferential design. If something like this already exists, I would definitely like to know about it – I’d likely drop my own pet project and collaborate on something like this. If there isn’t anything like this, it’s totally understandable because it’s a challenge (which is what makes it interesting in the first place, to me). Yes, expressive languages exist (Inform7 has one), but how easy is it to implement an interpreter/compiler for language like that? Could something nearly as expressive be done with a language that’s much easier to implement?
Regarding retrocomputing, I’m just observing that there is a non-negligible interest in it here. I’ve seen several threads already about running things on old systems or on emulators for them. In other old software communities, you may see a single thread like that once every few years, but you’re much more likely to see (for example) threads about how the Vulkan backend is coming along for a source port where the software renderer has long since been scrapped.
Not that there’s anything wrong with that, at all. But taking this into account could explain some disinterest in language-level approaches that would not be remotely viable on old systems or emulators.
I realise I’ve banged this drum before, but I still believe that, speaking specifically about parser game development, we need a new crop of tools that provide a fully integrated, simple to use, IDE which enables both the logic programming through simple wizards, and the ability to develop the user experience UI. Sort of like a Unity for Inform/Dialog/TADS/whatever.
Things that would be really awesome to be part of it :
The process of developing, building and releasing a parser game is pretty gnarly. If you want to include some form of UI it’s even worse (I find it almost impossible).
Just so long as it’s not actually Unity 
Me too.
I honestly just want to be able to port IF with graphical enhancements on specs suitable for retro machines. I want reasonably stylish presentation married to sizes at or below 1 MB rather than something a hundred times that size. There’s no reason it couldn’t be done other than lack of tools.
On the plus side, it seems Dialog is heading in roughly that direction.
I’ve been treating Lectrote as stable. But I should do semi-regular bumps to get it up to last-stable major versions of Electron.
As Lectrote is currently structured, it is a framework for interpreter engines that support Glk (or GlkOte). Compiling VMs with emglken is the easiest way to add to Lectrote. Supporting other web frameworks is possible, but it would be extra work and you’d lose the visual consistency that Lectrote has now. (Which includes interpreter-wide font/theme preferences.)
What kind of graphical enhancements do you have in mind - more than what Infocom did with their V6 games? Because Zork Zero ran on the Apple II, and the tools for building Zork Zero exist today.
Well, the ability to draw IFF images onto the screen as the story dictates would be the bare minimum. A generous story file size and hyperlink capability would be quite nice as well. Really, most of what I want could be summarized as, “please make the Å-machine run on the Amiga.”
(I’m tempted to take a stab at it myself, but it strikes me as a bit overly ambitious in my current situation. I’m guessing it will keep, since it’d surprise me if very many programmers were lining up for the job of porting modern IF software to the Amiga.)
The reason I kept the description sort of vague was to fold it into a broader desideratum: having a game with the capability of Vorple but distributable without, say, Electron. I just can’t see myself writing a one-room scenario and distributing it as a 120 MB file.
If 512 KB is generous enough (not counting the graphics and sound), and if you don’t need hyperlinks, it sounds like Z-machine V6 would fit the bill.