• Advertisement
  • entries
    146
  • comments
    436
  • views
    198359

Your Grim Future

Sign in to follow this  

142 views

It is surprising how fast time passes. I was going through the backlogs of this journal and realized just how much I've written since I first started. At the same time, I realized just how little I've actually written. So, I've been thinking of pulling another series of posts out of my tentacles and giving you something on either the Interpreter pattern, or on .Net again. The thing is, if I revisit .Net again, it will have to be on serialization and how to redo the serializer I originally wrote. Something that I'm not too keen on, although it should probably be done.

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.
Sign in to follow this  


4 Comments


Recommended Comments

The Interpreter pattern is great. I see it on a fairly regular basis (our engine has the pattern at two discrete layers and uses it on a smaller scale in many other places) but I've never really read a good, generalized explanation of how the pattern is implemented and where it can be useful. I look forward to what you've got to say on the matter [smile]

Share this comment


Link to comment
That's an interesting way of treating the data itself. I'll look forward to reading your analysis of the topic. =)

Share this comment


Link to comment
Seriously, where the hell do you learn this crap? You spit more out in one post than I could after my 7 years of self teaching.

Bravo. Can't wait to read more.

Share this comment


Link to comment

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
  • Advertisement