Elegant Command-Parsing in an Oop-Based Text Game

Elegant command-parsing in an OOP-based text game

The Interpreter design pattern is the most object-oriented approach to parsing that I'm aware of, but I'm sure compiler experts will point out algorithms that are more powerful.

Best language and framework for a text based game like mafia wars

I'm going to try something original here - give Natural language a try.

Inform is a tool for creating interactive fiction (a.k.a. text-based adventures) that features its own language. It takes care of creating the initial "infrastructure" (taking user input, recognizing verbs, that sort of thing) and lets you concentrate on creating "things", "places" and "actions".

Here's a sample, extracted from its tutorial:

The wood-slatted crate is in the Gazebo. The crate is a container.

Mr Jones wears a top hat. The crate contains a croquet mallet.

It looks deceitfully easy, I know. But try it :)

Inform also allows you publish it on The Interactive Fiction Database, as well as export it to a standard Z-machine format (I belive the file extension for this is .z8) .There's even a javascript z-machine interpreter, in case you prefer to host your adventure on a web-page yourself.

Edit: I've found two additional "frameworks" - I don't know whether they use a programming language, or they are completely graphical, I don't use windows: Adrift and TADS 3

Searching algorithmics: Parsing and processing a request OOP style

Your problem is well suited to a document-oriented store such as Lucene. For example you can design a schema such as

Type

Variety

Color

Origin
DateSold
etc
:

Then you can write a Lucene query such as Type:Fruit AND Color:Green. You can also build nested queries such as (Fruit:Straberry AND Color:Deep Red) AND NOT Origin:Spain.

Apache Lucene is a Java library with portts available for most major languages. Apache Solr is a full-fledged search server built using Lucene lib and easily integrable into your platform-of-choice because it has a RESTful API.

BTW Solr has something called faceting which lets the user filter results using each of the criteria above. So user types fruit into search box and then gets results back.

---

Type:
- Fruit (109)
- Nut (99)

Origin:
- Spain(32)
- France(39)

Color:
- Red (22)
- Deep Red(45)

---

Clicking on each of the facets filters the results with the intersection. So if you want a more user-friendly interaction model, faceting/filtering is much easier, than getting users to type extensive Lucene queries.

Update: You might still need to do some lexical parsing if you wish to let users type natural language queries and break it down, but given the tremendously difficult challenge, my suggestion would be to use the simple & powerful faceting approach.
Hope that helps.

Building a Semi-Natural Language DSL in Ruby

Building on @David_James' answer, I've come up with a regex-only solution to this since I'm not actually using the DSL anywhere else to build scores and am merely parsing out points to users. I've got two patterns that I'll use to search:

SEARCH_STRING = "@Scorekeeper give a healthy 4 to the great @USER_A for doing something 
really cool.Then give the friendly @USER_B a healthy five points for working on this. 
Then take seven points from the jerk @USER_C."

PATTERN_A = /\b(give|take)[\s\w]*([+-]?[0-9]|one|two|three|four|five|six|seven|eight|nine|ten)[\s\w]*\b(to|from)[\s\w]*@([a-zA-Z0-9_]*)\b/i

PATTERN_B = /\bgive[\s\w]*@([a-zA-Z0-9_]*)\b[\s\w]*([+-]?[0-9]|one|two|three|four|five|six|seven|eight|nine|ten)/i

SEARCH_STRING.scan(PATTERN_A) # => [["give", "4", "to", "USER_A"],
                              #     ["take", "seven", "from", "USER_C"]]
SEARCH_STRING.scan(PATTERN_B) # => [["USER_B", "five"]]

The regex might be cleaned up a bit, but this allows me to have syntax that allows a few fun adjectives while still pulling the core information using both "name->points" and "points->name" syntaxes. It does not allow me to grab the reason, but that's so complex that for now I'm going to just store the entire update, since the whole update will be related to the context of each score anyway in all but outlier cases. Getting the "giver" username can be done elsewhere as well.

I've written up a description of these expressions as well, in hopes that other people might find that useful (and so that I can go back to it and remember what that long string of gobbledygook means :)

---

Related Topics