I think you’ll find that it’ll be easier to get critical mass if you pick a target audience to start with.
Of course, if your target audience is “people who already know JS,” then catering to coding newbies would indeed be extremely silly. But that brings me to the other problem, that people who know JS just write their own engine.
Text adventure engines specifically.
It’s not uncommon for IF enthusiasts to present this forum with alternate IF authoring systems in which authors can develop IF with a “real” programming language, typically one of the top 20 languages on the TIOBE index, or at least a language that ranks highly on StackOverflow’s “most loved languages” list.
But these authoring systems never seem to gain traction. None of the most popular parser-IF systems require authors to use a “real” programming language. All of the most popular systems use a domain-specific language for IF.
Why is the IF community so enamored of DSLs? This isn’t like other parts of the game industry. In the game industry in general, even if people do decide to implement their own engine from time to time, the most popular game engines use popular general-purpose programming languages, the same languages everybody else uses. The IF community must be full of weirdos, right?
Well, yes, but we’re not the only weird ones. Consider querying a database. You could do it in C or in JS, and some people do, but the industry has discovered that using a declarative query language is better, and SQL is by far the most popular language for doing it, despite the fact that SQL doesn’t have much in the way of step-wise debugging support. If you’re querying a database, trust me, you should just use SQL. (At a minimum, you should learn SQL before attempting to query a database in another language.)
Text adventures aren’t like other programs that run step by step from beginning to end; they’re programs to cooperatively generate text, incorporating commands from the player while subtly guiding the player how to use the correct commands to win. Coding a parser-based text adventure is mostly about declaring data (what are the rooms and objects in the game) and a rules engine of events that fire when certain conditions occur.
And, of course, that’s what you see in Text-engine. Text-engine’s “JSON” includes backtick template strings, event-handler functions. But the rules in full-blown text adventures typically aren’t like
onLook handlers. They’re more like, “when the dragon is asleep and the player has brought the princess to the same room with the dragon and the princess has her wakizashi or one of the following five weapons…”
The general industry wisdom when it comes to rules engines is that they all kinda suck. It’s easy to get started rolling your own rules engine, but it’s hard to write a good one, so everybody just rolls their own. And this is another area where DSLs often do thrive. (The article I linked above is by Martin Fowler, who concludes, “there’s a lot to be said for avoiding rules engine products.”)
Then, when you add in the fact that most IF authors see themselves as writers first and coders second (if at all), you start to see why a community has formed around DSLs for text-adventure rule engines, and why good programmers keep writing their own IF-rules engines rather than use anybody else’s.
Consider also that a lot of folks appreciate IF due to nostalgia for retro hardware. (I note that you’ve styled your Text-engine demo to look and feel like a machine from the 1980s.) A lot of people who enjoy that sort of thing tend to want their games to actually run on old hardware, or at least run on emulators for old hardware.
I suppose you could write JS that transpiles to Z-machine code, but probably only a subset of JS, at which point what you have is a JS-like DSL.
I’m telling you all this not to be discouraging. I think the world could be a better place with a popular IF engine oriented around a general-purpose programming language, and especially if someone were to implement a rules engine for JS that people love, not just for IF, but for all sorts of rules-engine shaped problems.
The path up this mountain is littered with the frozen corpses of others who have tried and failed to reach the top, but I hope somebody manages to climb it, and I wish you the best of luck.
P.S. One more parting thought. Rather than write your own admirable IF from scratch, you might find it productive to port an existing IF game into Text-engine. Emily Short’s Bronze is available under Creative Commons. Porting it to Text-engine would probably be a valuable exercise.