Let me assure you that the path you’re proposing is not the “easier” path. At the very least I recommend that you write your first game in Inform, to get a deeper understanding of the industry standard approach, before attempting to create a domain-specific code library for developing IF in a general-purpose language.
Indeed, it’s not uncommon for IF enthusiasts to present this forum with alternate IF authoring systems (libraries!) 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.
The rules in full-blown text adventures typically aren’t like
onLook event 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.
This is also why GUIs for IF development tend to suck. It’s hard enough to write sophisticated rules in code; it’s actually harder to use a sophisticated drag-and-drop “low-code” tool to define rules like these. (And what problem is the GUI even solving? Anyone who could use a “low-code” tool for developing the rules would need all of the sophistication you’d need to write code.)
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.