{"id":20,"date":"2011-05-26T20:09:51","date_gmt":"2011-05-27T01:09:51","guid":{"rendered":"http:\/\/www.playwithlua.com\/?p=20"},"modified":"2011-05-26T20:09:51","modified_gmt":"2011-05-27T01:09:51","slug":"interactive-fiction-part-1","status":"publish","type":"post","link":"http:\/\/www.playwithlua.com\/?p=20","title":{"rendered":"Interactive Fiction (part 1)"},"content":{"rendered":"

Like it or hate it, and there are plenty of reasons to do both, object-oriented programming is an idea that you can’t escape. Practically every language and every library uses it. Every CS curriculum teaches it. Every learn-to-program tutorial explains it. And so, people have some funny ideas about what it exactly is<\/em>. If your first language supports it (like Java or Ruby, say) then it becomes very hard to distinguish between object-oriented programming<\/em> and how your language does object-oriented programming<\/em>.<\/p>\n

Unless you’re using Lua. Because OO in Lua is whatever you write for it. The language doesn’t offer any of what a Java programmer would consider essential features, like classes, instance variables, even types. What it offers is a way to make<\/em> those things. So that’s what I’m going to do over the next couple posts, in the process of writing a miniature interactive fiction engine. At the end it’ll look a little bit like this<\/a> except that I’m going to make a bunch of compromises that Zarf never would, because he’s smarter than I am and can foresee how it’ll mess everything up. Also because he intends to use his for longer than a blog post.
\n<\/p>\n

Game design<\/h2>\n

First, let’s define what we’re going to do. We want to have a system that simulates a world, which interacts with the user solely through text. We’ll give it commands like “get lamp” or “walk north” or “put chalice on altar”, and it will change the game state in some way and respond with a message. First, let’s talk about how we’re going to represent the game world.<\/p>\n

As far as nouns go, there are two kinds of things in our game: there are rooms, which are the locations the player can be in (“you are in the kitchen”), and there are props, which are the things that are in the rooms (“there is a knife and a pan of brownies here”). Props can also be other places too, like in the player’s inventory or inside other props (“the chest contains a sword and a blue cloak”). So the world is a directed graph of rooms, and each room is the root of a tree of objects. In addition to this, there can be other “global” factors at play, like if it’s dark then all room descriptions are “it’s dark, you may be eaten by a Grue”. We’ll have a list of global rules that aren’t part of the world graph, but get first dibs on any command.<\/p>\n

Time for a big helpful picture or two. Here’s how the rooms will be laid out:
\n<\/p>\n

And here’s the layout of items within a single room:
\n<\/p>\n

This first post, we’re going to lay the groundwork, and talk about how to implement rooms. First though, since this is ostensibly about object-oriented programming, it’s about time we mentioned objects.<\/p>\n

Basic objects<\/h2>\n

An object, in the Java \/ C++ sense, is an instance of a class. And a class is a user-defined datatype (where you, the programmer, are the user; classes are typically defined in code), just like “string” or “array”. This method of OO is almost totally dominant, to the point where languages like Javascript are thought of as not supporting OO because they use a different model. Really, though, an object is anything that fits these criteria:<\/p>\n