I’m a newcomer that is discovering the world of interactive fiction. Maybe my opinion is quite different and erratic, so I would love to see diverse comments and opinions.
I’m mostly interested in retrogaming, specially in digital preservation by open source software.
At first, I tought there were just a few IF systems such as Z-Code and a few more. Then I discovered projects such as Gargoyle and Mac-centric Spatterlight, using “terps” to add them by the Glk (API?). To me, its quite comfortable to have all IF interpreters in the same interface.
A but later, I discovered an uglier reality toe. Some IF interpreters lacked a portable and Open Source implementation between them, had one but not integrated in multi-interpreters or available anywhere:
ScummVM’s ScummGLK: It implemented support for Archetype by reimplenting Pascal code to C++ and Comprehend by merging and heavily modifying a Comprehend interpreter.
Spatterlight added Quill support by adding an John Elliott’s UnQuill terp, but nor Gargoyle nor ScummVM has it. It seems to convert to Z-Code to play not sure if that conversion makes it lack certain stuff such as graphics. No idea about unqbbc usage, as BBC Micro support is absent in UnQuill.
John Elliott’s unplad and unphipps code is still there but it seem to not be interpreters at all.
Gackle exists to support GAC interpreter, but no other interpreter support it and less by using a terp. The same about Ascape for Adventurescape, developed by same developer (tautology0 at GitHub).
There are some interesting interpreters of PAWS for Z80 machines by saimazoom on GitHub and DAAD for MSX by nataliapc on GitHub. Those are not truly portable and feature complete. There aren’t others for the diverse (more than it seems) Quill/PAW(S) family at all too, forget about SWAN and many less known ones.
The list goes nearly to the infinite if your threshold of obscure old games gets to the max.
I understand constructive and proactive software R&D preservation is quite massive and difficult, requiring reverse engineering and using tools such as disassemblers and decompilers. This makes support lots of IF interpreters in portable form a daunting task.
Why a few metainterpreters instead a massively portable one? What about merging code and develop a portable one such as Gargoyle and ScummVM? I understand native widgets and such are nice, but compromises and backend code for each platform may solve this liking. ScummVM is based in Gargoyle/Garglk code, AFAIK.
I see an IF project needs to gain a lot more critical mass to see interested developers implement old interpreters and such (terps?). This critical mass may attract more developers and even participate in events such as Google Summer of Code.
I like features of both Gargoyle and Spatterlight, I consider them to be great projects. Fabularium and Hunky Punk are quite interesting, but they seem dead. Gelek Vanilla seems not so active too. Parchment and Lectrote seem quite interesting. ElseIFPlayer seems interesting but a other inactive project.
ScummVM has potential, despite supporting RPG and point & click graphical adventure games too.
I consider dividing efforts and public visibility is not so good for IF survival. There’s need of a MAME/MESS-like effort, IMHO.
Native vs non-native isn’t a so big problem, there are ways to compile C/C++ cofe to Javascript and WASM. Emstriptem is a valid way, for example. I prefer natuve, but web apps might be a preference or useful in certain conditions.
IF Archives and databases such as IFDB and CASA are amazing. Treaty of Babel is a great idea. That’s a great goal achievef, it just needs to be even more popularized too.
Glk seems a great concept. Not sure about limitations and if it’s focused on old of new IF systems, anyway.
Would that be reasonably solved by merging two or more projects into one instead forking and mixing them?
Or making code reuse a lot easier between projects? Terps are a good concept, for example. But many projects use C++ and may need to convert the original code from C, such as ScummVM.
DreamMaster wrote the following in ScummVM Glk wiki article:
Whilst at first I tried to keep the sub-engines as close to the original source they’re derived from as possible, this quickly proved impossible. Not only did I have to add in proper C++ namespaces to encapsulate all the code, but I also had to do various conversions to change them over from using STL to using ScummVM classes. So don’t anticipate that it’ll be easy to take any interpreters converted specifically for ScummVM Glk and simply drop them into any other Glk implementations.
A lot of it is driven by user demand. No doubt Gargoyle could add some other Glk-based interpreters, but has anyone actually asked? And are those interpreters being maintained, or would the Gargoyle “team” (ie, Chris) be taking on a maintenance burden for an unmaintained terp?
On the other hand, old obscure formats are probably best served by whole-system emulators. For example, archive.org now supports pretty much every DOS game by a WASM port of DosBox. Other old systems have other capable emulators. There’s not much to be gained by pulling those in all together, all it would really help is help people find the right emulator for each game. But archive.org can probably do that for a lot of them.
The retrogaming community is really quite distinct from the IF community. There are of course a lot of overlaps, but the purposes and values of each are distinct. I’m not really part of the retrogaming community, but I’d expect that for a lot of people, part of the fun of the hobby is the process of working out how to best revive the experience of play decades-old games in the most authentic way possible. Many emulators aim to run at original CPU speeds, sometimes because the games won’t actually run if they emulate faster, but sometimes just for authenticity. There are even emulators with fake CRT flicker effects!
So I’m not sure how many retrogaming fans would be interested in Parchment adding support for more old formats. The fans who want to play Infocom games on an old Apple II vs those who want to play in a modern interpreter with crisp 4K text wouldn’t have much overlap. As the maintainer of Parchment I’m serving the latter. If I received a request for a new format to be supported in Parchment I’d consider it, but after 10 years or so of maintaining it I can say that I don’t get requests from retrogamers. In fact almost no one asks me to add support for new formats to Parchment, even of those more from the modern IF community!
I’m the (de facto) Gargoyle maintainer; I’ll give my thoughts on some of these questions here from that perspective.
If you mean, why do Gargoyle + Spatterlight + ScummVM exist all to do the same thing, when you could devote resources to one of them, a primary answer (beyond “we want to”, which, in such a niche area with zero/negative monetary incentive, can’t be dismissed) is that consolidating these so-called “metainterpreters” wouldn’t really do anything. The magic that makes them work is Glk, which means that once an interpreter is written, it takes effectively no work to get it working with existing Glk implementations such as Gargoyle or Spatterlight. The work is in the interpreter, not the Glk implementation.
Related to the above, if anybody wants to implement new interpreters, we already do have a single target interface for them to use: Glk. If an old game is roughly shaped like an Infocom game, then there’s effectively no reason not to just write an interpreter against Glk.
I’m not against adding new interpreters to Gargoyle, by the way, but my experience is the same as Dannii’s: there’s just not demand for them. I’ll seriously consider any new Glk interpreters for Gargoyle if somebody makes a request, but I’m just not sure how much interest anybody has in writing new interpreters for obscure old platforms/games, beyond what we already have.
First, I don’t think IF’s in any danger of dying.
Second, I’m not sure what would be gained by combining anything. How would you even start to combine Parchment and Gargoyle, for example? And while there’s definitely overlap between Spatterlight and Gargoyle, combining them won’t really have any effect. It won’t make interpreters start appearing any faster. And there’s already collaboration occurring among us all.
Glk really is the glue that you’re looking for.
ScummVM didn’t need to convert anything: it chose to. Gargoyle is C++, and most interpreters are C, and they’re being used with no issue. Glk defines a C API, and most languages are able to work with a C API. ScummVM had an existing framework they needed to fit into, and modifying interpreters made sense for them, but it does diverge from Glk.
A fun(?) project could be to write a compatibility layer between ScummVM’s Glk for and proper Glk, so the ScummVM-specific interpreters could be used elsewhere, but I’m not sure anybody’d be willing to do that work.
I should point out (at risk of repeating common knowledge) that Glk is a most common IF features interface, not a supports absolutely everything that every IF system does interface.
When I came up with the idea 25 years ago, I envisioned Glk as a completely universal interface. But that proved to be impractical and is no longer a goal.
This is why Gargoyle (and Lectrote, which takes a similar approach) is many interpreters with a common interface. This is great for some purposes! (You can set your display preferences once and all interpreters in the app will use them.) But some platform features (notably Z-code color) require extra hacks and don’t necessarily fit in well. Other platform features (like Vorple) will never be part of these universal intepreters.
So a one-universal-app-does-everything approach does not make sense on the face of it.
I’m not sure if I understand your opinion correctly.
I would say, in my opinion, that there are two philosophies that goes in parallel: preservation/retrocomputing and accessibility/play in a modern way. One that would be interested in emulating a system and the other in to play a game on any platform.
The way of playing IF as [interface | api | interpreter | game data] is, again in my opinion, the most versatile way of doing this as having one huge code, I think, would fail in supporting everything and would be difficult to maintain.
Some other random thoughts:
The DAAD development has been quite uninterrupted since Aventuras AD broke. Check the repor of Uto Utodev (Uto) · GitHub that has everything you could imagine.
It would be cool to have a glk layer for the DAAD interpreter? Yep. Possible? I don’t think so.
SWAN was an «intermediate step between» (in a lot of inverted commas) PAWS and DAAD with ¿1? game made for it?
I hadn’t time to update it, but I plan to do it (now that Ubuntu Touch upgrades to new version of the OS) but think about it as an experiment. I’m a terrible programmer and GeLeK is sort of a try to learn and set a build system, sort of a Gargoyle for mobile. It uses the same terps and the glk layer, the only new is the frontend. See? If we had only one huge interpreter I probably couldn’t have built it for the mobile OS. In the end, I may be the only one using it.
In my opinión I don’t understand why there is no universal if interpretar for Android wich is one of the more used platforms today. Everyone has got one.
There are some abandoned projects as Fabularium, Thunderword, Incant, etc that are more or less tricky to Work with. Fabularium doesn’t make properly transcripts with glulxe games, Text Fiction for Thunderword are the one properly working with glulxe but is unstable and Incant only works with downloaded games from it’s database.
I think there would be by today some multi interpreter like frotz for ios system.
In a community this small, there can be determining factors like ‘Is there some person who wants to do it and can do it?’ So maybe there just is no-one. But as to why there might be fewer in the possibility space for Android, it could just be because, as I understand it, Android development (edit - and maintenance, hence the static projects) is hard due to the great variation in what an Android can be.
MAME/MESS are rather unique I think in their noble goal of exact emulation for historical documentation purposes.
Funny you mention MAME/MESS. I was spurred to write my first Z-machine interpreter back before MAME merged wth MESS when I asked someone working on MESS if a Z-machine driver was possible. They pointed out, rightly, that the Z-machine is not a complete virtual machine. Its screen model is not a virtual display but rather a set of guidelines and rules open to multiple interpretations. I’m not familair with other older formats, but I wonder if many older platforms share quirks like this. This would make a universal interpreter very difficult to achieve without massive effort, or substantial compromises.
Personally, I’d rather see a number of full-featured interpreters than a universal one that cuts corners. Others may prefer the opposite. Getting the best of both worlds would be a lot of work for even a well organized team.
Some of this has already been addressed in this thread, but just adding a few comments myself…
Firstly, a lot of what you’re referring to in the comments below are text adventure engines and authoring systems for specific 1980s microcomputers. You’d lose a lot of the charm of the original games by playing them through a “modern” multi-interpreter if it was one of those that stripped out all the lovely old fonts, colours, screen resolutions and graphics… There’s no appeal for me of playing a Quilled game that’s running as a bloated z-machine port, for example. It’s already so easy to load up the appropriate emulator and play the games how the original authors intended.
Yes BBC Quill is different enough as a system from the other variants of The Quill/AdventureWriter to make including it in unQuill difficult. There have been some efforts to create a browser-based way of playing Quilled games that were created on the various different platforms, such as Quill Adventure Player
No, they’re ways of viewing the source code of those games. The “un” programs; such as unQuill, unPAWS etc. are primarily focussed on dissembling the games to see how they work.
There are completely feature complete interpreters for DAAD for ZX Spectrum, Amstrad CPC, MSX1, MSX2, DOS, C64 & CPlus4, Amstrad PCW (& CP/M), ZX Uno/Next, Atari ST, Amiga… and most recently for internet browser in the form of jDAAD. DAAD is pretty portable and although it’s not trivial to do you can get Quill and PAWed games running on it fairly easily.
It wouldn’t be that tricky for authors of multi-interpreters to include DAAD support. The MSX2 and jDAAD interpreters are brand new implementations… so it’s perfectly possible to create your own “terp” if you know what you are doing.
(I’ve spent most of my day today porting some of my DAAD games to different platforms, such as the browser… We’re quite active in that community… People like Uto are providing us with great tools like DAADready which really make targeting multiple platforms very easy.)
Re. SWAN… NAPS seems to include support for that… but there were only ever two games made with SWAN anyway.
I must apologize for the extended silence on my end. I’ve been dealing with some personal challenges that have demanded much of my time and attention. I regret not having been able to respond more promptly.
Despite these circumstances, my passion for our common interests remains strong, and I’m more committed than ever. I’m currently in the process of reorganizing my personal affairs to better pursue these passions. The world of interactive fiction has been a remarkable discovery for me; as a voracious reader and gaming enthusiast, I’m drawn to its narrative depth and textual interactivity. Additionally, as a Linux user, I have a particular fondness for the command-line interface (CLI).
Please accept my apologies for the length of this reply. I wanted to ensure that I addressed each of your points comprehensively to everyone that replied here, as they all present valuable perspectives that enrich our conversation.
Well, that may be true if there isn’t coordination between projects and consensus. However, I believe that efforts like SDL are far from being a failure. They provide a valuable framework that has been used in numerous successful projects. It’s important to note that the success of a project doesn’t solely depend on whether it’s a unified effort or not, but also on other factors such as the dedication and skills of the contributors, the usefulness of the project, and the demand for it.
Indeed, I might have been a bit shy about asking for the addition of “terps”.
However, I understand that maintaining unmaintained interpreters would add a significant maintenance burden to the developer.
It’s important to remember that these projects are often open-source and rely on the voluntary contributions of developers.
Therefore, I completely understand that the decision to add or not add certain features or components often depends on the resources available and the demand from the user community. Thanks for remembering it to me!
While some may hold differing views, I personally find the underlying logic of interactive fiction games as enriching as the gameplay itself. I see general-purpose emulators for specific platforms as temporary solutions, compared to the more sustainable approach of redeveloping those vintage formats, parsers, and engines.
The term I use to describe this process is “digital archaeology”. It involves reverse engineering efforts that delve into the core of these games, unearthing the intricate mechanisms that once brought them to life. This process, to me, is not just a technical endeavor, but also a fascinating journey into the history of interactive storytelling. It’s like piecing together a digital puzzle, where each piece contributes to our understanding of the game’s original design and functionality. This, in my opinion, is an incredibly intriguing aspect of interactive fiction.
I appreciate your perspective, and I’d like to offer a counterpoint in a constructive and respectful manner. While it’s true that many projects draw users by incorporating their favorite games, I believe there’s a broader picture to consider.
The actual appeal of retro elements is known as “retrowave” trend. It’s characterized by a nostalgic affinity for the 80s, is captivating new generations. This trend is evident in various forms of media, such as “Stranger Things” TV series and retro-inspired video games.
In interactive fiction, this could mean preserving the original retro style on modern systems, or blending retro aesthetics with high-resolution font rendering. The possibilities are varied and cater to a wide range of preferences.
Just as today’s teenagers are rediscovering bands like Nirvana, they could also be drawn to interactive fiction if presented in a relatable, retro-inspired format.
In conclusion, while adding popular games can draw users, exploring the retrowave trend and reimagining classic elements could broaden interactive fiction’s appeal and inspire innovation.
Thanks a lot. I consider your opinion to be quite important!
Certainly! I appreciate your perspective on GLK as a valuable concept for code sharing and collaboration. It indeed provides a solid foundation for interactive fiction development.
Regarding your request, I’ll gladly explore the possibility of syncing with Splatterlight and incorporating Unquill. Unquill, being an intriguing tool for interactive fiction, could enhance the overall experience. Let’s embrace the spirit of collaboration and continue to evolve the world of text-based adventures!
Excuse me! Maybe it was my subjective point of view. I would love IF to be a lot more popular.
As a non-developer, I might miss many details. I consider the non-parser/engine code sharing would make things easier, but I might miss many details. Excuse me for my immense ignorance!
I discovered this world recently and I’m amazed with it. Previously, I was a bit scared to enter this world.
Absolutely! You’ve captured precisely what was on my mind!
What do you think about the idea of organizing a virtual meeting with various prominent programmers, including DreamMaster (Paul Gilbert), yourself, and other members of the interactive fiction (IF) developer community, in order to reach a unanimous agreement and streamline the process? I am confident that it would lead to a highly productive collaboration.
In light of the current GLK limitations, do you think the answer might lie in developing an enhanced GLK2, or perhaps establishing a new standard, API, or interface for Interactive Fiction? Such a solution should not only tackle the existing shortcomings but also be adaptable enough for less powerful platforms, avoiding an over-reliance on web technologies. While these technologies are portable, they tend to be bloated and may not operate optimally on those platforms.
Would it be posible to reimplement those other platform features such as Vorple in a more portable and lightweight way?
Indeed, I’m aware of it. Despite this, I don’t see teams, but rather ‘one-man armies’ implementing DAAD across various platforms.
Why isn’t possible? Is it a limitation of GLK API?
But is it real DAAD or inspired in it?
Well. It might not be an high priority, but it might be interesting as digital preservation and digital archeology effort.
I get it.
What about making it multiplatform? For example, Android and iOS…
ScummVM is accessible on both Android and iOS platforms. Furthermore, recent regulatory pressure from the EU has prompted Apple to ease some of its restrictions regarding emulators and related software.
Yes, I tought about that too. That’s why having IF interpreters such as ScummVM or others would be good for those platforms.
Yes, MAME/MESS (now both merged into MAME) have very unique idiosincrasies.
Indeed, there’s a broad spectrum of tastes out there, so implementing special filters and rendering techniques to faithfully replicate the original experience is a viable approach.
With today’s powerful GPUs and shader technology, I find it entirely achievable. This method could please both individuals who desire a contemporary gaming experience and those who yearn for authenticity akin to the game’s original release period, all without relying on retro hardware that’s becoming rarer and pricier due to wear and market speculation.
It would be interesting if Gargoyle, Splatterlight, and others also supported these. Web technologies are intriguing, but I believe that the future lies in WebAssembly.
It’s truly commendable to see such dedication to these projects. I find myself longing for a multiplatform DAAD interpreter that operates on native code, such as C/C++, which can offer superior performance and compatibility in certain scenarios. The need for such an interpreter is evident, as it would greatly benefit modern computing environments by providing a more efficient and direct way to execute interactive fiction titles.
Is NAPS an implementation and/or IDE of DAAD? Please excuse my lack of knowledge. I’m still navigating the vast expanse of interactive fiction. It’s a much broader field than I initially realized, and I’m eager to learn more about its intricacies and the various tools used by the community.
Despite the fact that SWAN may have a limited catalog with only a handful of games, delving into its capabilities could offer valuable insights, particularly in the realm of digital archaeology. Understanding SWAN through reverse engineering could shed light on the digital history of interactive fiction and contribute to the preservation of its legacy.
I apologize in advance, because what I’m about to say is basically arguing against some of your points without talking about anything I agree with. I don’t have much to say on the technical side of things, but I think from your perspective as a retrogame player, you’re misunderstanding some of our situation.
[IF in this context refers to parsers.]
The core of IF is text. Sometimes the way the text is presented is important (e.g. Photopia), but ultimately most games (especially parser games, which I’m assuming you’re referring to based on the interpreters) are text-based in whatever theme the player decides. There is no real “core” that needs to be preserved, and the “intricate mechanisms” are still being brought to life—they’re still displayed as text on a screen with a command prompt, just as they’ve always been.
Again, no real purpose to having “retro” graphics. If you really want retro, Adventuron games are pretty good at looking “old”. We don’t need retro aesthetics. We don’t even need aesthetics. I’m sure that there are interpreters/themes that can recreate old computer graphics perfectly well for nostalgia.
As one of “today’s teenagers”, I would honestly been drawn away from IF if it were similar to how it was in the past. There’s so much QoL stuff that has changed since then—more open parsers, kinder games, cleaner interfaces—that I feel it would be hindering to go back to those days. It would only add to the stereotype that IF is dying/backwards. It isn’t. It’s evolving just as much as other media are evolving (books, movies, video games, etc.) and even though there may be a niche for cruel retro games, it isn’t the main niche in IF and interpreters, especially a “global” interpreter, shouldn’t only reflect that small percentage.
I’m not a “prominent programmer”, but I think most people would not be interested in this. It ain’t broke. This is a hobby for most people, and a meeting to find a solution that doesn’t have a problem sounds like a waste of time. And there isn’t a problem. We’re doing perfectly fine with our few major interpreters. There’s no real need to create one ultimate one, and it would take too much traction to be the one people recommend over Gargoyle, Frotz, etc. so it would just be yet another interpreter (see xkcd 927).
IF is naturally easy to play on weaker computers. PunyInform IF can run on an 8-bit computer. But these aren’t interpreter-side “issues”. These are code-side. Changing interpreters wouldn’t do anything to make IF less intensive to play.
We’re not reliant on web technologies, either. Many code from the terminal/command line, or an IDE. The only web coding I typically see people do is on Adventuron, Borogrove snippets, and choice-based games.
So do you want IF to be playable on less-advanced computers or more?
Ultimately many interpreters are already multi-platform, and they are similar enough in function that it doesn’t really matter anyways. I understand what you’re asking about, but some of the problems you’re seeking to fix aren’t really issues.
Personally, I would prefer a more modular system with fewer interpreters installed by default. Additional interpreters could be downloaded and installed as needed, similar to the RetroArch emulator front end.
The system could include settings for default colours, fonts etc. with the option to override them for each interpreter. That way, you could play (for example) Level 9 games with yellow text on a black background and Infocom games with black text on a white background if you wished.
Glk allows us to make incremental changes to the API. Watch the interpreters category here and you can see when extensions get proposed and implemented. Most of these extensions aren’t things that couldn’t be implemented on less powerful platforms, aside from the old 8 and 16 bit computers which probably can’t implement the standard Glk API.
Glk interpreters are generally at most like 3MB, many are smaller than 1MB. Having to download them separately doesn’t seem to have any possible advantages to me. It’s not like you’d have to use the extra terps. The only thing I can think of is there’s a clash with file extensions? But most formats have unique enough extensions, I haven’t heard people say that’s been a problem for them.
For the ultimate in modularity, one could build each desired terp with RemGlk and then have the same small application talk RemGlk to any of those terps and relay the messages it its own Glk.
It sounds like fun, actually. But if you weren’t doing it for fun’s sake, it would be a lot of work to go to to not actually solve any real-world problems.
Bocfel is the Z-Machine interpreter. All of the rest total 5.4MB, just under half of which is TADS by itself. And in exchange you get easy support for 14 more formats.
What makes up the other 40MB? 4MB is for fonts, and the rest is for libraries. Don’t forget that the whole point of Gargoyle is to play all the formats with beautiful typography.
Gargoyle cares about typography! In this computer age of typographical poverty,
where horrible fonts, dazzling colors, and inadequate white space is God,
Gargoyle dares to rebel!
Subpixel font rendering for LCD screens.
Unhinted anti-aliased fonts: beautiful, the way they were designed.
Adjustable gamma correction: tune the rendering for your screen.
Floating point text layout for even spacing.
Kerning for even more even spacing.
Smart quotes and other punctuation formatting.
Ligatures for “fi”, “fl”, “ff”, “ffi”, and “ffl”.
Plenty o’ margins.
Plenty o’ line spacing.
Integrated scrollback.
If those features don’t interest you, there are many other Z-Machine interpreters that would be much smaller to download.
There’s absolutely no need for apologies! I hold every perspective in high regard. It’s beneficial to comprehend the diverse preferences of IF players.
While I fully grasp your viewpoint, others may seek an experience that’s more faithful to the original platform, resorting to emulators when authentic hardware isn’t accessible.
I’m convinced that it’s feasible to develop software that can cater to both user types and beyond.
As mentioned before, I acknowledge your stance. My preference leans towards “Quality of Life” enhancements, which is why I often favor software reimplementations over hardware emulators.
Your perspective is certainly respectable. However, I view it differently.
I would be enthusiastic about improved code sharing among Gargoyle, Splatterlight, ScummVM, and other platforms featuring IF interpreters. Hence, I believe a virtual meeting among the programmers involved in these projects could facilitate better coordination.
For instance, “ScummGLK” (the moniker for ScummVM’s implementation of GLK) transitioned “terps”/parsers/subengines to a more C++ oriented approach. Reaching a consensus on this could streamline code sharing, thereby reducing the effort required to integrate an interpreter/“terp”/parser/subengine.
Indeed, some IF titles depend on web technologies, though they appear to be the exception. It would be advantageous to possess tools capable of converting these games to non-web platforms.
Why not aim for compatibility with both advanced and basic computers?
A sophisticated software could leverage specific hardware features, such as graphical filters, when enabled. It’s more efficient on contemporary platforms to apply these filters using GPU hardware through shader programming languages than via software.
Naturally, such features would be optional. This approach is already implemented in RetroArch, ScummVM and other software projects.
I understand your viewpoint. Nevertheless, my passion lies in expanding support for an even broader array of games.
While others have mentioned that the space savings are minimal, this approach could be beneficial for devices with limited memory/resources.
Your concept of individually tailoring each output is indeed commendable.
So why Andrew Plotkin Andrew Plotkin (zarf) said the following?
The insights provided by Andrew Plotkin (zarf) underscore the complexity and diversity of interactive fiction systems.
While modularity offers certain conveniences, it also reveals the intricate balance between universal functionality and the unique characteristics of individual platforms.
The dialogue surrounding these topics is crucial as it propels the evolution of interactive fiction, ensuring that it remains accessible and enjoyable for all enthusiasts
As I said previously, It might be a good approach for memory/resource constrained devices.
I appreciate your insights. While I understand the rationale behind your perspective, I believe there’s room for further discussion and exploration in this area. The pursuit of modularity and efficiency in software is a continuous journey, and every contribution enriches the dialogue.