• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
jniblick

How to build a simple text parser

7 posts in this topic

I have been working for a little while now on a text based adventure game in the vein of Zork, and I have gotten to the point where I need a text parser. I naturally went online and looked for a tutorial on building one, but I came up short. I was dearly hoping that someone here could give me the basics on building a text parser and help me get my project going. Thank you.
0

Share this post


Link to post
Share on other sites
Please be more specific. There are an endless variety of text-parsers that work in ways limited only by your imagination; from command-line parsers to rich-text parsers...
0

Share this post


Link to post
Share on other sites
I describe basic text parsing [url="http://www.gamedev.net/topic/630916-zork-like-text-input/page__p__4977514#entry4977514"]here[/url]; is that the kind of text parsing you're interested in?
1

Share this post


Link to post
Share on other sites
I am looking to build a very simple command line parser that will work in a similar manner to that of Zork and take input from the player and respond without the need to hard code all the different possible outcomes. I want to build something very simple that breaks down the string into tokens and then compares those tokens to words that the game recognizes. I do not know how to do this.
0

Share this post


Link to post
Share on other sites
[quote name='jniblick' timestamp='1347840943' post='4980741']
I naturally went online and looked for a tutorial on building one, but I came up short.
[/quote]

That is likely because what you are looking for is complicated. In short, there is no short and easy answer.

For a very simple text adventure game, you could opt to support a limited subset of input, for example only verb + noun.

Once you start wanting to parse more robust input, things quickly get more complicated.

[quote]
> Examine the sword
Which sword, the silver one or the green one?
> The green one
The green sword is very sharp.
> Pick it up and put it on the altar of silver
You pick up the green sword and place it on the Altar of Silver Light.
[/quote]

Notice the disambiguation and handling of ambiguous English in the commands.

[quote]
>Pick it up and put it on the altar of silver
[/quote]

In the above line alone, the parser has to determine that both of the "it" words refer to the sword just picked up, that "put in on" doesn't mean wear something, that "silver" refers to an object named "Altar of Silver" and not an adjective for the silver sword, etc. To handle this type of complexity, you need a parser that can handle ambiguous grammar, and a system built around it that can select the correct parse tree from a collection of possibilities, or othewise ask for clarification from the player in order to select the correct tree. You will also need some sort of database of world objects, along with their names and adjectives, including plural forms, together with a sytem to keep track of item scope (i.e. what objects the player can see, or touch, or pick up).

Zork was created using a domain language called Inform, you can find a lot of info on it here, including a lot of high level info on their parser:
[url="http://emshort.wordpress.com/how-to-play/writing-if/books-and-other-resources/inform-designers-manual/"]http://emshort.wordp...signers-manual/[/url]

Here a couple links for discussions on the subject:
[url="http://www.mud.co.uk/richard/commpars.htm"]http://www.mud.co.uk...rd/commpars.htm[/url]
[url="https://groups.google.com/forum/?fromgroups=#!msg/rec.arts.int-fiction/Y-S-bBojK7E/e-xy-z6WRfUJ"]https://groups.googl...7E/e-xy-z6WRfUJ[/url]

Here is another take on tackling the problem:
[url="http://fiziwig.com/intfic/design.html"]http://fiziwig.com/intfic/design.html[/url]

Finally, a while back I implmented an Earley parser ([url="http://en.wikipedia.org/wiki/Earley_parser"]http://en.wikipedia....i/Earley_parser[/url]), which is a type of parser that can handle ambiguous grammar, as an experiment in creating a generalized parser for these kinds of games. I can tell you it was not easy, at least for me, since I have had little experience with the field myself.

EDIT: just saw your clarification on "very simple parser", in this case I wouldn't aim as high as Zork, instead try and get a verb + noun system to work first. Edited by laztrezort
0

Share this post


Link to post
Share on other sites
Perhaps you can, for the sake of learning, abandon the concept of writing an advanced text parser accepting commands in [action][target] form... Perhaps the best way for you to go is to use a "multiple choice" type of system, which means you only have to handle a limited number of cases and user input. You can step things up a notch and "script" your entire game in a basic text file the game just reads... the game knows what to expect as input, things work easily and transparently, everyone wins...
0

Share this post


Link to post
Share on other sites
Keep it simple for now. Split your dictionary into verbs and objects, you might even want to stick with the typical verbs found in point and click adventures.

"Please use the hammer to hit the nail"

First thing you are looking for is a verb, so look for one.

"Please" is useless and not found in the list of verbs. Move on.
"Use" is found, so from now on you search the object list.
"the" is again useless, not found and skipped.
"hammer" is found, so you got your first object.
"hit" is not found in the object list (though it could be in the verb list). Ignore.
"nail" is finally found and your sentence is complete: "use hammer nail"

Of course the objects might be looked for in the players inventory or the current scene (a global list would require storing the current location for each object).

To "resolve" your input, you could for example just use a nested map, so to define the outcome it could be something like:

someMap3["use"]["hammer"]["nail"] = functionToExecute;
someMap3["use"]["nail"]["hammer"] = functionToExecute;

Why both? Because the user could go with "hit nail with hammer" instead.

Also, there would be maps for just verbs ("look") and the most common 2 word inputs ("examine hammer", "open door"). Unless of course you'd rather go with a tree for parsing, which might seem a bit more natural.

Note that this is a very primitive method and you have to be careful not to have multiple objects with the same name. Also, several words should refer to the same verb or object, also easily done with a map.

verbs["hit"] = "use";
verbs["open"] = "use";

That drastically limits your combinations, but also allows generic inputs like "use chest". You can also go with enums for all your verbs and/or objects. Changing the maps to

verbs["hit"] = VERB_USE;
verbs["open"] = VERB_USE;

Error messages might not always be useful, especially when things are ambiguous.

"Hammer nail into wall". If hammer isn't a verb, the parsing will fail completely ("What?"). If it is, you might get "Hammer with what?", requiring absurd input like "hammer nail into wall with hammer", which can fail if wall is also recognized ("I can't use wall").

So the first decision: do you want to spend a good bit of time on a clever parser or just make it work? Edited by Trienco
0

Share this post


Link to post
Share on other sites
I am looking for a basic idea for a command line text parser. I am really just looking for a basic idea for now and I will build upon it as necessary. You have helped me all to that extent and for that I thank you.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0