Just to add a positive note: I noticed that the hand-coded parser was actually better at certain cases that the Inform parser struggles with. Specifically, mass nouns.
(This isn’t an exact quote from the game, but roughly:)
> X STONES
The ground is covered with small stones.
> TAKE STONE
You pick up a stone.
> X STONES
The ground is covered with small stones, and you’re also carrying one.
Disambiguating the plural STONES from the singular STONE isn’t a problem when the game doesn’t support disambiguation!
I feel curious… Which language/creation tool has Bael been written with? I know some other Steam text-adventures have been created with something called AppGameKit Studio, as the Jimjams games Eye of Borrack and Stranded 2. Bael looks like it could have been done with Unity or Godot or something like that!
Yes, it’s basically a React app wrapped in Electron, coded in JavaScript (TypeScript to be precise). No conventional game engine involved. So if it looks like it could’ve been made in Unity or Godot, that’s definitely nice to hear.
Now, all that said, this forum is a pretty small audience compared to Steam! You don’t have to take everything we say as gospel.
Unfortunately, Steam’s player base is so massive, and with so many games being released, that there’s almost zero chance of reaching players who might be interested in such a niche genre (let alone those who don’t yet know they’d enjoy it). So in reality, this forum still feels like the best place to find people who’d genuinely connect with the game.
By the way, I only decided to put it on Steam about 3-4 months ago. At first I wasn’t planning to release it at all, but it had grown large enough that I thought, why not? Plus, I always wanted to see what it’s like behind the scenes. For now I’ve sold just over 20 copies - which almost covers the publishing fee.
I originally wanted to wait until after IFComp to promote here (I only found out about the comp in late August, too late to adjust my release). I still hope I can interest some people here later on. Any advice on how I should approach that would be great - whether I should ask for playtests, reviews, or reach out directly. I’m also fine with doing giveaways; money isn’t really the main goal here (though it’d be nice to eventually cover the Apple developer fee so I could port it to macos).
EDIT:
By “niche” I meant in Steam terms - we’re up against Call of Duty, Silksong, Clair Obscure, all that. Didn’t mean it in a bad way toward IF itself.
The best way for detailed reviews is the annual Review-a-thon, or to submit it to one of the major competitions (e.g. Spring Thing). You can also ask for playtesters in Playing > Beta Testing Requests and Discussion.
Most IF we make are free to play, so if yours isn’t, it may turn people away from playing. Successful commercial IF do exist (e.g. Hadean Lands) but they usually come from well-established authors.
Most bestselling novels follow a set of best practices honed over centuries of literary culture. Most Nobel Prize-winning novels flagrantly violate one or more of those practices.
The IF community similarly has two great traditions:
Someone releases a game that is Different. Some people Get It, while others tell them they’re Doing It Wrong. The Different part eventually becomes Standard.
Someone releases a game (often a first game) that is Different. It gets some pushback, and they spend awhile engaging with the reviews and tweaking their ideas. Their next game is Still Different But Better and wins All The Awards.
This is the artist’s paradox—the attitude “am I out of touch? no, it’s everyone else who is wrong!” is both their greatest asset and greatest liability. Great artists have to have the humility to learn from the Old Masters and the hubris to think they can do better. Fortunately, the IF community is generally good at thoughtful feedback.
I really appreciate your words, and please don’t think I don’t value your experience and knowledge. Over the next few days I won’t have much time to work directly on the game, but I’ll use that time to rethink the parser aspects we’ve been discussing (and try to balance out the hubris).
I have some ideas for how I might adjust it to better align with your expectations, though I’d prefer to wait until (if) more people play through a larger portion - so I can get feedback on the parser in the broader context of the game’s design, not just in isolation. As I mentioned before, I plan to wait until the IFComp dust settles and then reach out to more people.
In the meantime, I focused on something more immediate: I added an option to disable the “typewriter” effect, as you suggested, and made some minor text revisions.
While I can turn off the typewriter effect, it doesn’t stay off. On returning to the game, I have to turn it off again.
You’re right - currently, settings aren’t persisted in the game data. For a long time, there weren’t many options in the menu, so it didn’t feel essential. I’ve added this to my to-do list for the next patch and hope to have it done by the end of the week.
Also why do I have to press Enter each time I start?
This comes from the fact that the game was originally run in a web browser. Browsers don’t allow audio to start before the user interacts with the page (it’s a security restriction). I decided to keep it as is - it only happens at the very start, and I’ve kind of gotten used to it.
I also noticed a couple of typos/grammar errors in chapter 2. Sorry I didn’t note them down for you.
Sorry about that! I’m not a native speaker, and I’ve tried my best - proofreading and revising hundreds of times - but I’ll go through it again. If you happen to play a bit more and notice anything obvious (typos, not grammar - I don’t want to take up your time), I’d really appreciate a heads-up.
It took a little longer than I planned, but the new patch is up
It includes a few smaller updates, like settings persistence in save data, volume levels, and several minor interaction and text improvements.
But the biggest change, and the one we discussed the most, is that I’ve added another layer to the parser that runs only after the first one, if an action fails. It’s a compromise that lets me keep the flexible logic I first designed and wanted to keep, while also introducing the kind of global verb recognition you suggested.
In short, it now detects verbs that are usable elsewhere and gives custom responses. For example: “You can’t examine that.”, “You can’t dig here.”, and involving inventory items, like: “You can’t use this item to do that.”, “You can’t drop it here.”, “You can’t put an item anywhere if you don’t have it.” etc.
I’m sure it’s still simplified compared to your standards in this aspect, but I hope it’s a good step in that direction.
