Relic Quest

BFG10K
I've completed the first two games in a series I've been developing:




If you want yours to look as pretty as mine (Consolas size 26), follow the last two lines from in-game help:


Both are classic text adventure games that should provide several hours of solid gameplay each. They were designed and programmed by myself in C++. Windows Vista or better is required.

Playing the games and sharing your experiences here will encourage me to develop further instalments in the series. Also please report any bugs you find so I can fix them.

Download link: http://www.intfiction.org/forum/downloa ... hp?id=1100

jaynabonne
It has a polished feel, and there are definitely niceties put in (the "fast travel" options, for example), but the parser is frustrating and (possibly) buggy.

I suppose it's a choice to not follow the standard IF convention of providing descriptions for the various nouns in the main area descriptions, but to me it gives it a bit of claustrophobic feel. I like being to explore my surroundings. Personal preference, I suppose. As an example, in the shed, it says "It has several spacious shelves...", but when I type "x shelves" (or "look at" or "examine" - I'm not even sure which one it is), it just tells me "Type a recognized item, click menu, or use numpad." When I do try to examine a "recognized item" (in this case the crowbar), it says, "The crowbar can't be used alone. Try a combo with another item." Given that I hadn't tried to use it, that message is a bit odd.

I like being able to use the numpad to move. It's quick and easy.

In the garden, more fun. Trying to "examine" anything just gives the "Type a recognized item..." message. I can't imagine an IF/text adventure parser game without an "x" command. The description says, "All manner of flowers and shrubs grow here...", so I tried "pick flower", and it replies with the cryptic "Orchid not available."

The description describes a bench. I tried "x bench" to no avail (when will I learn?). I tried sit on bench, with the standard "Type a recogn...". On a lark, I tried "take bench", expecting it to say I couldn't. Instead, it said, "You can't take anything right now." So... I figured maybe I could only carry one thing at a time. I dropped the crowbar I was carrying, typed "take bench"... and it picked up the crowbar!

I'm sensing that this is a keyword based approach to parsing. My theory: When I typed "x crowbar", it ignored the "x" and just looked at "crowbar"; hence the message about "The crowbar can't be used alone." Similarly, when I typed "x bench", it understood neither "x" nor "bench", and so told me to type something it understood. And finally, when I typed "take bench", it didn't understand bench, so it just executed "take".

I experimented myself with a keyword/topic based approach, and I gave it up in the end. It just had too many false positives on things that didn't make sense.

It's possible there are some good times to be had here, and I might explore it a bit. But it flaunts so many IF/text adventure conventions, that I think you're going to get some push back from people who play. I think your help text is misleading when it says it "accepts the classic verb + noun combo", as it doesn't really accept classic verbs (short of "take" and "drop", and those don't even work in the "verb + noun" fashion.)

I hope this doesn't sound too negative. I can see you put a lot of work into this, and it looks nicely designed and polished. I think you just need to really teach the player that this is *not* a game in the classic Zork parser vein but something new and different - and how to do it. Then it might allow us to put our expectations to the side and come at it fresh and interact with the games in the way you have designed them.

jaynabonne
Following up on my discovery of responses based on objects not in my location (the "Orchid" incident), for fun I just started typing in random words. Cat, dog, spoon, shovel. So far, I've found that there will eventually be a rock, a hammer, water, a well (which came up when I type "stone"... a stone well perhaps?), a Harpy (came up when I typed "bird"), mud (when I typed "patch"), dirt, etc.

Perhaps you might want object lookup to occur based on what's in the vicinity...

BFG10K
Thanks Jaynabonne, your examples show the parser is working as designed.

A few notes on how it works:

[list][*]The colored highlighting signifies which objects you can interact with. In most cases they have multiple recognized words behind the scenes, but the upshot is that anything without a color (e.g. the main description block) is part of the scenery and can't be manipulated.

[/*:m]
[*]The parser has been designed to remove a lot of the burden that other parsers have with regards to mandatory words and/or placement. In particular, it removes the verb from the equation as much as possible and places the focus on the objects themselves. When combined with the recognized objects above, it allows virtually infinite combinations over any hardcoded thesaurus.

[/*:m]
[*]With your random word example of the orchid, I can do the same in most other games by typing <x object> and it’ll either reply the object isn’t available, or that it doesn’t understand it. This is correct behaviour.

[/*:m]
[*]I’ve had positive feedback from newer players who were able to solve puzzles where more traditional games blocked their commands because they weren't "correct". They also found it clearer to see what items need their attention, and what's just scenery. [/*:m][/list:u]

Anyway, many thanks for your time and feedback! :)

jaynabonne
I realize the parser is working as you wished (though I disagree about the "object not here" message, as normal IF games do not distinguish between objects that do and do not exist in the game - it's just an "I can't see that" message, which provides no hint about what might actually exist elsewhere) - I was trying to suggest (lamely it seems) that you might wish to mitigate the expectations of those who have played other IF by explaining a bit how yours differs. At the very least, you might wish to remove the "classic" phrasing from your help, as this is not a classic style game! From what I have read on the IF sites, plus my own experience, the most widely used command in IF is "x",which doesn't exist in your game, either literally as an input command or even in function.

Two more thoughts:

1) As you have pared things down so much, even to the point of eliminating verbs as a fundamental input necessity, where the player is effectively entering words they see on screen (hint hint!), you could probably dispense with the parser altogether. That might be against your design goals, but I'm throwing it out there as an option you might not have considered, as it would help players have a different set of expectations up front.

2) I've thought about this a bit over night, and I've come to realize that the deal breaker for me is the lack of the ability to explore textually the game environment. That gets back to our friend "x" (or "examine" or "look at" or whatever). A major draw for me with IF is being able to dive into the environment, to eke out details by looking at things and finding new things to look at. I love having nice rich descriptions that put me in the game. I must confess that I'm not a big puzzle fan. I'm not that keen on the whole "magpie collecting items to use in arcane ways elsewhere" thing. I'll do it, and I know it's key to this sort of IF, but if a game is reduced down to being *solely* that, with no roses to smell along the way, then it's lost its appeal for me. I'm basically walking around looking for things to pick up. Since you have said others have enjoyed it, I'll leave it at that. I'm clearly not your target audience. But I wanted to offer that last bit of feedback, in case it's useful to you.

I am also most impressed that you wrote this in C++, rolling your own system instead of using someone else's! That is no small feat, and you've done a great job. :)

BFG10K
jaynabonne wrote:I realize the parser is working as you wished (though I disagree about the "object not here" message, as normal IF games do not distinguish between objects that do and do not exist in the game - it's just an "I can't see that" message, which provides no hint about what might actually exist elsewhere) - I was trying to suggest (lamely it seems) that you might wish to mitigate the expectations of those who have played other IF by explaining a bit how yours differs.

While this may be normal for Quest games, many other games I've seen do in fact make such a differentiation. Here's an example from classic Zork - you clearly see 'Crayon' doesn't exist while 'Thief' does:



I personally think this is the correct way to handle things.

At the very least, you might wish to remove the "classic" phrasing from your help, as this is not a classic style game! From what I have read on the IF sites, plus my own experience, the most widely used command in IF is "x",which doesn't exist in your game, either literally as an input command or even in function.


The 'x' command is there, it just doesn't matter if you type 'x', 'use', or whatever else makes sense for that item. The items that react when referred to in a solo fashion will do things, including showing more detail if necessary, just like the traditional examine. If you found the Grate or the Well in the garden, try typing 'x' on those to see what I mean.

1) As you have pared things down so much, even to the point of eliminating verbs as a fundamental input necessity, where the player is effectively entering words they see on screen (hint hint!), you could probably dispense with the parser altogether. That might be against your design goals, but I'm throwing it out there as an option you might not have considered, as it would help players have a different set of expectations up front.


This is an interesting idea, but it's not possible if you want to still let players type sentences. You also need fundamental verbs like "take".

2) I've thought about this a bit over night, and I've come to realize that the deal breaker for me is the lack of the ability to explore textually the game environment. That gets back to our friend "x" (or "examine" or "look at" or whatever). A major draw for me with IF is being able to dive into the environment, to eke out details by looking at things and finding new things to look at. I love having nice rich descriptions that put me in the game. I must confess that I'm not a big puzzle fan. I'm not that keen on the whole "magpie collecting items to use in arcane ways elsewhere" thing. I'll do it, and I know it's key to this sort of IF, but if a game is reduced down to being *solely* that, with no roses to smell along the way, then it's lost its appeal for me. I'm basically walking around looking for things to pick up. Since you have said others have enjoyed it, I'll leave it at that. I'm clearly not your target audience. But I wanted to offer that last bit of feedback, in case it's useful to you.


Understood. You're right, the engine has been designed to place heavy emphasis on item combinations and/or usage at certain locations to solve puzzles, while verbs have been abstracted out as much as possible.

The puzzles are also designed to avoid being overtly complicated, illogical, or obscure. It's also impossible to save yourself into a "no-win" situation.

I am also most impressed that you wrote this in C++, rolling your own system instead of using someone else's! That is no small feat, and you've done a great job. :)


Thanks - It turned out better than I expected. I also anticipated releasing a lot of games with it, so the engine has been designed to perform a lot of the heavy-lifting for you.

I've actually finished planning the third game (a "haunted house" of sorts), but I'll take a bit of a break before implementing it. ;)

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums