The interpreter pattern would be an interesting one to do a series of posts on, simply because it features so many cool and interesting usages in game programming (of which many might surprise you) while still being applicable to general programming. Not only that, but you can extend it to a scripted language easily enough. This doubles its capabilities significantly (while enabling the introduction of BNF notation as well, oh my!)
Demonstrating the usage of the interpreter pattern poses a problem, as the examples would need to be suitably complex as to demonstrate the concept, while being simple enough for the general reader to understand. Obviously this is a complex balance to strike.
Look at your game state, it's probably made up of a few different trees, a scene graph, and object relation tree (world - entities - player - inventory), and various other components that all combine together to give the general state of your game at any one moment. You often times will ask this tree various questions. Questions such as: "Does this ray intersect another living entity?" or perhaps: "Who all is in an area of radius R around point P?" These questions are often times formulated as for/while loops, and quite often rely on information that is stored in the scene graph (such as using spatial partitions to optimize your searches for information pertaining to locations). You might also want to ask other questions of your game, such as: "Return all monsters that have been dead for more than 2 minutes." Obviously you would be expecting an array to be returned that contains a list of entities that are monsters, and that have been dead for longer than 2 minutes.
We often times issue these queries without actually noticing that they are queries. So here's a quick question that should help to understand why I perceive them as queries: What structure does your game state represent? Now, you probably have a couple of different answers in mind, but the one that I'm looking for is: A database. You issue queries against databases, and since your game state is a database, you are issuing queries. These queries are done in code, but could just as easily be represented by a query language (think SQL). Of course, we wouldn't actually want to use a query language like that directly, as it would be potentially slow. If we turned that query into an AST (Abstract Syntax Tree) then it would be a simple tree traversal, which would be quite fast to execute.
Such ASTs are the primary components of the Interpreter pattern, and will be the focus of the next few posts. We'll start off with a few introductory ideas and some thoughts on the development and evolution of our queries. Then we'll introduce some queries in code, which will most likely flow from our previous examples. After examining those sample queries in depth we'll move on to the actual pattern and its usage in this context. Finally we'll look at what it would take to build an actual query language which could be translated into an AST from a query string, allowing us to expose this capability to scripted engines almost transparently.