Bael's Rock [New zorkian text adventure in Steam]

I’ve found this text adventure in Reddit:

https://store.steampowered.com/app/3694940/Baels_Rock_A_Text_Adventure/

The OP (Shichi193) says:

Hey adventurers!

Over the years, I’ve been working on a passion project called Bael’s Rock - a fantasy text adventure inspired by classics like Zork. What started as a little side project (I never dreamed I’d actually release it) just kept growing - about 10 years in the making, with some breaks and restarts along the way.

In short: a mysterious fantasy story, challenging puzzles, and an old-school parser-based text adventure, where you type and the world reacts.

Here’s the Steam page if you’d like to check it out and support in any way - wishlist, share with friends, or dive into the adventure yourself:
https://store.steampowered.com/app/3694940/Baels_Rock_A_Text_Adventure/

Thanks for reading, for all the support, and for the feedback from my earlier posts.
May your Firefly Torch stay lit!

I have not played it yet, but it looks cool.

I don’t know if the parser will be to our standards.

6 Likes

I took a quick look. The first chapter is a tutorial that directly tells you what to type. After that it’s a “traditional” parser game, but with music, a separate inventory pane, and slow-print text. (Hit enter to speed it up.)

I just tried a few moves in the second chapter. The parser is not as nice as we’re used to, but it may be good enough for the kind of game this is. I won’t try to speculate further until I’ve played more.

7 Likes

Has anybody else looked at this? I got stuck in the first room (of chapter 2).

The parser is not in fact very good but I can’t tell if that’s the problem.

1 Like

I am also stuck. There are things I like about it. The “three window” thing is nice and new. Agreed on the parser.

I’m stuck after doing the following:

Chapter Two, where I am stuck

I read the inscription. It says to free myself of my past. Well, the amulet is the only thing involving my past. I can’t drop it or put it someplace. It said to shatter that which gives life… I threw my sword away following the tutorial so I can’t use it to shatter the life-giving fountain. I did manage to bring forth darkness by closing the gate and I got a cube fragment, but I can’t throw it at the fountain to break it. The other thing it says is to abandon hope, which I tried as >abandon hope, but it doesn’t let me do that either. This is where, during beta-testing, I would just tell the creator that their game is too tough for me!

Yeah, that’s all I’ve done. I think there must be some noun which is so obvious to the designer that they didn’t bother to mention it.

Hello everyone!
I was planning to post about my game on intfiction next month (since I didn’t want to do it while IFComp is running), but it’s really nice that it already got some recognition and interest.

Regarding the parser and Chapter 2: I know for a fact that some people from the community have made it through without any hints (at least one player reached Chapter 6, another Chapter 5 - you can check the discussion on the Steam forum).

I can assure you that all the necessary nouns are there (and there are many aliases both for verbs, nouns and their combinations), and your train of thought is mostly right!

Reading your comments, I’m wondering - did you leave the room through the gate? If not, do you think that part feels counterintuitive?

EDIT: I now know why you probably didn’t:

I didn’t handle SOUTH/S commands without verbs in the chapter 2, and I know you’re probably used to that. (I do handle them in later chapters, so it’s just unlucky that it happens at the start.) There are still lots of ways to move around: GO SOUTH, GO CAVERN, GO OUTSIDE, ENTER DESERT, and many more. I am going to patch it as soon as possible.

EDIT2: Fixed! Unified chapter 1 and chapter 2 movement with the rest of the game.

If you did leave the room, here are a couple of hints:

Hint 1

There is indeed a way to shatter the fountain with something, and that’s part of the puzzle.

Hint 2

There is a way to drop the amulet somewhere, and that’s another part of the puzzle.

Let me know if you’d like more hints, and I really appreciate every bit of feedback I can get!

5 Likes

Also, just a little disclaimer - I’m new to this forum and haven’t really been part of any text adventure communities before, for various reasons. But this game is something I’ve worked on for many years, and it’s always been an important project to me.

I know the parser and some other aspects may not be what you’re used to (since I wasn’t influenced by the community or existing engines while creating it), but I’m really proud of how it turned out and have been polishing it for a long time. I just ask that you stay open-minded and give it a chance!

Any help or feedback will be invaluable, and nothing is stopping me from improving the game even after release. So if you have ideas or concerns, they can absolutely have an influence on it! I’d love to become a part of this community.

5 Likes

Movement in this game does not necessarily follow the “usual” standards that we’re used to, you might have to a bit more verbose.

I didn’t handle SOUTH/S commands without verbs in the chapter 2, and I now know you’re probably used to that. I do handle them (and other directions of course too) in later chapters, so it’s just unlucky that it happens at the start. There are lots of ways to move around here: GO SOUTH, GO CAVERN, GO OUTSIDE, ENTER DESERT, and many more. I am going to patch it as soon as possible.

EDIT: Fixed! Unified chapter 1 and chapter 2 movement with the rest of the game.

1 Like

Thanks for showing up to post!

Yeah, that’s exactly what happened to me. (And Robb too I’m sure.) I tried “SOUTH” and the game said “That doesn’t make sense” and I was like, welp, I guess the deadly desert is too deadly to explore.

Having a consistent verb set is one of the big ways people approach parser games. Some of the first commands I tried were SEARCH FOUNTAIN and DIG IN SAND. Both of those were rejected with generic failure messages, so I learned that the game doesn’t use those verbs ever, anywhere.

(If you look at Jason Dyer’s blog – he’s playing early IF games, like 1982-1983 – you’ll see he often starts by trying every common verb, to get an idea of what kind of actions the game is going to look for. This post is an example. If the game uses situational verb parsing, that doesn’t work, and then the whole thing can bog down.)

I’ve installed your update and I’ll keep kicking at the game. Thanks!

9 Likes

Other notes:

It would be good to have a preference setting for “print all the text at once, thanks”. Right now I have to play by double-hitting Return on every command, because I literally can’t read text as slowly as the game prints it out by default. Even the fast print speed (after I hit Return) is barely fast enough.

You wrote:

If you did leave the room, here are a couple of hints:

Even without leaving the room, I was already sure both of those hints were true! The game did a good job of conveying that info.

5 Likes

Ok, then maybe it’s worth pointing out early on that in my game a generic failure doesn’t necessarily mean the verb won’t work elsewhere. I read the post you linked and I understand the concept, but I also feel that testing every verb at the start (or at any point) can sometimes turn into a mechanical exercise that risks breaking immersion (almost a bit spoilery for the actual puzzles).

I know there are risks with situational verb parsing, but I wanted to take that route. My goal is for players to figure things out from the situation they’re in, and I believe that comes down to the quality of the writing, the exposition, and a flexible command list (and of course I realize there’s a risk of failing on any of those fronts).

I don’t want to argue this point too strongly - you clearly have much more experience in the genre - but that’s the vision I tried to follow while making the game.

I set it up this way so the second Return also acts as a failsafe against accidentally skipping text. But I agree, an option to print everything instantly definitely makes sense. I’ll be working on adding that, along with better sound management. It might take a bit of time though. Not because it’s hard to implement, but because proper testing of these features will be time-consuming.

The point is that Jason is doing that because he’s playing games from 1982, when the state of the art was very shaky and the world was full of half-assed parsers.

(Infocom games were an honorable exception, but there were only about six of them at that point!)

Nobody runs the verb chart in any modern game! Because we’re all used to IF systems that have a guaranteed stock of familiar verbs and a world model that produces sensible failure messages. (“You can’t go that way,” “You can’t dig here,” “It doesn’t move,” etc, etc.) Essentially all IF games written since 1992 work this way.

I’m not trying to criticize you; I’m just saying that your approach is pushing against a lot of history.

4 Likes

I’m not trying to criticize you; I’m just saying that your approach is pushing against a lot of history.

Sure, I understand - and as I said, I really appreciate all feedback! I’d be glad to hear more of your thoughts, positive or negative - both are important.

2 Likes

Yeah, the big problem with parser games is that the possibility space of verbs and nouns is so absurdly huge. The fantasy of a parser game is that you can type anything and have it recognized, but English has, as a Fermi estimate, a couple hundred thousand verbs and a couple hundred thousand nouns to combine them with. There’s no way any parser can handle all of those in a meaningful way!

As a result, conventions have arisen to let authors suggest to players what verbs and nouns they should try. For example, most parser players assume that nouns mentioned explicitly in the text are fair game, while other nouns generally aren’t, even if they’re implied by the context—if the game mentions a river flowing past, RIVER is fair game, but MUD isn’t, even if the presence of a river implies the presence of mud. If you want players to think of MUD as a noun, you need to phrase the message in a way that mentions it (perhaps saying the riverbank is muddy here).

As an author, it’s not unreasonable to assume that, if there’s a river, there also has to be mud. But there are so many nouns that are implied by the world that no author can implement them all. The convention of only referring to nouns that are explicitly mentioned in the text is a way that authors and players can agree on a more limited set of nouns to use—a player won’t write a review saying “the game didn’t let me TAKE MUD”, and in return the author won’t write a puzzle requiring TAKE MUD.

And the same goes for verbs! The convention nowadays is that a standard set of verbs can be assumed unless otherwise specified (GO, EXAMINE, TAKE, DROP, OPEN, etc), and anything beyond that has to be suggested by the text: if you want a player in a chemistry lab to HYDROLYZE a chemical, you should mention “the equipment is set up to hydrolyze chemicals”. Again, the convention here is good for both authors and players: if there’s not a sentence like that, the player won’t get upset if the parser doesn’t understand HYDROLYZE, and also the author won’t expect the player to guess at that verb to solve a puzzle.

The convention zarf mentioned—that an error message like “that doesn’t make sense!” is an indication to the player that a particular verb will never be needed—is another part of this. With hundreds of thousands of possible verbs out there, it’s not reasonable to try them all; giving players feedback that “you’ll never need that verb in this game” helps them cut down that possibility space. And if that feedback is misleading, that conveys to the players that they’ll never know which verbs they need; for me at least, that tends to erode my trust that the game is going to play fair. Now I’m going to go into every situation expecting guess-the-verb puzzles with zero feedback, or worse, misleading feedback (there’s an infamous puzzle from the Infocom era where a game lies to the player about whether a verb works until you try it a few times in a row).

12 Likes

In other words, authors have figured out over the years that players really appreciate a distinction between “that doesn’t work in this context” and “that doesn’t work in this game”.

I totally get the experience Alex is chasing—the limitless freedom to try any action you think of is exactly what I love about parser games. But this experience is always a balancing act between two extremes. On the one hand, you can tell the player outright what commands are acceptable; this makes gameplay frictionless but mechanical. On the other hand, you can give the player no feedback at all; this tends to reduce puzzles to Guess the Verb or Guess the Noun, which decades of players have decided is Not Fun (unless you are Leonard Richardson). The rare, magical balance is when players truly feel like they are the character—they can have a flash of lateral insight, express that idea to the game, and the game immediately understands and describes what happens next.

Maintaining that illusion is both art and science. Part of it is “juiciness”: the game squishes interestingly when you poke it, even if the action didn’t actually solve the puzzle. Part of it is subtly communicating to the player what sorts of commands the game is likely to accept, so that when they do get that beautiful flash of insight, they already know how to express it to the game. Both of these very often look like:

> DIG WITH SHOVEL
You scratch around in the dirt, but don't find anything of interest.

…rather than:

> DIG WITH SHOVEL
That doesn't make sense.
9 Likes

I hope you’re open to some critique too, because if not then I’m cooked. As an outsider, I find it kind of funny that people who’ve never played these games before often get through the first chapters without much trouble, while veterans with thousands of hours of experience can get stuck just trying to leave the room through the gate - mainly because the least organic command (SOUTH) doesn’t work.

The game actually allows for a wide mix of commands: GO/ENTER/TRAVEL/MOVE/WALK (and more) with GATE/DESERT/ENTRANCE/SOUTH/OUTSIDE (and more). You can throw in adjectives and prepositions too, so WALK THROUGH THE GATE, GO INTO THE VAST DESERT, etc., all work. And of course simple ones like GO SOUTH or GO GATE do too. I create aliases for everything and combine them, so there are often dozens (sometimes hundreds) of possible inputs for one action. I added standalone direction commands like SOUTH/S starting in chapter 3 (I admit I should have unified this earlier for ch1 and ch2), but honestly, I don’t think it would be bad if they didn’t exist at all, since they aren’t exactly ‘natural.’

Just so it’s clear what I do and don’t do:

  • Nouns: All nouns needed to parse actions are always present in the text. That’s important, and I make sure it holds. On top of that, most nouns have multiple aliases and some alternative adjectives. Example: one tester (who never played parser games before) examined a “chasm” described in the location text. The details mentioned it was “bottomless,” so she tried JUMP INTO THE BOTTOMLESS PIT. Even though “chasm” was the actual noun, the command still worked. JUMP CHASM would’ve been enough, but I want the game to accept natural, immersive phrasing newcomers might use - while still letting regulars rely on short, simplified commands.

  • Verbs: A generic failure doesn’t necessarily mean the verb is useless everywhere. Risky, yes, but I’m okay with that trade-off. To balance it, I included as many optional, “flavor” actions as possible that don’t change game state - like BATHE IN FOUNTAIN or even ABANDON HOPE - which still give custom responses. But outside those contexts, those verbs don’t exist, and I’m fine with that. I don’t want to hint that “bathing” might be a critical action elsewhere by letting the parser say things like “You can’t bathe in the wall”.

    But if there’s ever a need for a very rare or situational verb like HYDROLIZE, I always make sure to hint at that possibility in the text, as you’ve advised.

Someone mentioned the split into a location window and a reaction window is unusual. I honestly didn’t realize that - it just felt like a natural design choice to me. Maybe there are other “fresh” things in my game that aren’t obvious right away.

It might even be the game’s biggest strength, that it’s a bit more accessible for new players. Either way, I hope you’ll give it a try and just have fun with it! (And of course, I’m still open to any further feedback.)

PS

The fantasy of a parser game is that you can type anything and have it recognized, but English has, as a Fermi estimate, a couple hundred thousand verbs and a couple hundred thousand nouns to combine them with. There’s no way any parser can handle all of those in a meaningful way!

Yes, but we only need a fraction of a fraction of those in everyday use - especially in the context of a simple adventure. I don’t think limiting the vocabulary to a fixed set of familiar commands and building strict mechanisms around them is the only right approach. My way is to cover and predict as many natural possibilities as I can, even if similar attempts may have failed in the past, and it won’t work well in every case.

1 Like

This forum is the folks whose idea of “natural” converged on a common concensus thirty years ago. :)

This is really the key idea. When you’re used to the standard IF parser, you assume that the game will understand any combination of a verb phrase and an object phrase. (For objects in the room, at least.) “WALK THROUGH SWORD” will get a failure message, but it will be understood – the combination of the Enter action and the Sword object.

So it’s natural to type EXAMINE __ on literally anything, just to test whether the game recognizes the object. And, conversely, to try DIG IN __ on something that might not be diggable (e.g. the sand) to test whether the verb is worth remembering.

It’s generally inefficient to generate the complete X*Y matrix of commands as a list in your program. That’s why parsers are a bit complicated to write. (But not very complicated – there were perfectly good ones in BASIC in the 80s.)

4 Likes

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.

3 Likes