Play With Lua!

When we left off last week, we had part of a game. It would display a board, and we could rotate it left or right. It would even animate, which was cool, but already our code was starting to get complex, so we were probably going about things the wrong way.

The issue is that we need to start an animation, then return from the function so that Löve can actually show the animation. But, the animation isn’t the entire turn; we have more game logic that needs to run after it finishes.

Currently, the only way to find out when something finishes is by checking for it in love.update, right? So we can make this game by making something like this:
Read the rest of this entry »

In part one of this post, I walked through the logic and game rules of a puzzle game, written in functional style. This time I’m going to turn that into a real game, that you can give to people to play: it will have graphics, animations, and run without installing Lua or any other dependencies.

I’m going to do this by using a game framework called Löve. I don’t want this blog to turn into library-of-the-week, but it’s impossible to do this stuff in a blog entry without using some framework, and Löve is a good one: it’s free and open-source, works on all three platforms, and its “Hello, World” is under five lines. So let’s download it and put some game rules into it!
Read the rest of this entry »

You know how if you have a box of little square things, and you rotate it, all the pieces thunk to the bottom and it’s kinda satisfying? Even more so if all the pieces are (say) dice, and they make a neat stack when they hit. That was my inspiration when I decided to make a puzzle game the other day. In this game, you have a square board partially full of colored pieces, and each turn you can rotate it ninety degrees either left or right, and all the pieces fall to the bottom. The pieces are four different colors, and there are four special pieces (one of each color) that are crushers. A crusher landing on top of a piece of its color will crush that piece and shift down one square.

What I’m going to do is talk about the design of the game and how I implemented the rules in this post, and then how I wrote the graphics and interface code in the next post. The post after that will have the final version of the game, with some explanation about how to organize code like this. But first, let’s write the game rules.
Read the rest of this entry »

There’s a book I have, Beautiful Code, which is a bunch of essays about programming by various famous programmers. It’s a great book. The chapters are on all different topics; the only thing they have in common is a piece of code that makes you think “wow, that’s really clever”. This post is about chapter one of that book, which is about a regular expression matcher.

Regular expressions are a domain-specific language for describing finite state machines. Specifically, finite state machines where the state transitions are successive characters in a string: you can use them to check if input strings match certain formats, like, a phone number: three digits followed by a dash followed by four digits. Kernighan’s matcher, which I’m going to translate to Lua and then extend a little bit, is really compact and beautiful. It’s about thirty lines, and recognizes these tokens:

• A dot (“.”) matches any single character
• A caret (“^”) matches the beginning of the string
• A dollar sign (“$”) matches the end of the string
• A star (“*”) matches zero or more repetitions of the previous token
• Any other character (like “a”) matches itself.

My plan is first to duplicate Kernighan’s matcher in Lua and then extend it to also handle character sets, like “[abc]” would match a single “a”, “b”, or “c”. Because of this, I’m not going to port his code across directly, but rather make some changes for extensibility.
Read the rest of this entry »

I decided to clean up and refactor the code some from part one, although it still works the same way: we still have behaviors that various objects can become. I’m not going to go through every part of the code, but I will talk about how behaviors are designed, explain the parser, how commands are handled, and how a prop (the lamp) is implemented.

Behaviors

First, here’s how you create a behavior:

Something = behavior()
function Something.methods.whatever(self) ... end

Read the rest of this entry »

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. If your first language supports it (like Java or Ruby, say) then it becomes very hard to distinguish between object-oriented programming and how your language does object-oriented programming.

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 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 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.
Read the rest of this entry »

This is a problem in The Art of Computer Programming volume 4A, which only came out a few months ago. My solution isn’t Knuth’s solution, mostly because I don’t understand Knuth’s solution, but it works and it’s fairly easy to explain.

The problem is this: given a number of nodes (like, say, 4), generate every possible arrangement of those nodes into a tree. So this is one:

() () () ()

This is another one:

() () (())

And so on. For n nodes there are 2^n-1 possible trees. And it’s not immediately obvious how to generate them.
Read the rest of this entry »

Lua is a pretty much ideal language for playing around with map generating functions. I made a cute one today, combining linear noise with a couple other things.

To start off with, here’s how I create a Lua map class: I start by making a “Map” table that contains a “methods” table. Anything class-level (what Java would call “static”) goes in Map; anything instance-level goes is Map.methods. I make a Map.new function that creates a new Map of a certain size, filling it with either a constant value or linear noise (I’m using 16 elevation levels):

Map = {methods={}}
 
-- Make a grid of random values 0..15, or a fill value
function Map.new(width, height, fill)
   local map = {width=width, height=height}
   setmetatable(map,{__index=Map.methods})
 
   for n = 1, (width * height) do
	  map[n] = fill or (math.random(16) - 1)
   end
 
   return map
end

Pretty basic so far. I’ll add a few methods like at and set that change values based on x and y coordinates.

Read the rest of this entry »

Lua is designed for embedding into larger host programs. Last time I talked about how to make C functions available to Lua, now I want to talk about how to bundle Lua libraries in with your host program.

First, we have to understand what it means to load a library. Most Lua libraries are packaged into modules (which I’ll get into later), one module per file. You call require and pass it a module name, and it returns the module (usually as a table containing some functions).

Notably, you’re not passing a file name to require, you’re passing a module name. The fact that these modules map to files is just sort of coincidence. In actuality, require looks in several different places (locations on package.path, C libraries on package.cpath, and so on) for a function that will evaluate to the module.

A function that evaluates to a module is called a loader. Searchers try to find loaders, so there’s a searcher that looks in files and returns functions that call dofile on them, for example. Each searcher that Lua uses is stored in the confusingly-named package.loaders, so one way to find this would be to add a searcher that will look for a particularly-named function (exposed from C) and call it, like if I try to load “foo” that means try to call “load_foo_from_c()“.

But, even before it starts calling searchers, it checks if you’ve provided a loader for that module by hand. You can do that by putting it in a table, package.preload. If you only want one module this is much easier to do.

Read the rest of this entry »

I wanted to write something about Lua’s C interface, but I couldn’t think of anything good and self-contained with my Cocoa Lua stuff (part of the point of using notifications is that I don’t have to do much C interface stuff) so I figured, I’ll write a tiny tile-based map thing.

Let’s say you want to write a game in Lua, and you want to have a really gigantic map. Storing it as a Lua table would be a little unwieldy, especially if you want to do things like run functions over it for map generation (fractal map generation, smoothing, whatever). It would be really nice to write that in C and have some basic functions in Lua to access it. So, we’re going to write a function that creates a map of a certain size, and another one that returns (as a table) a rectangular “slice” of the map:

map = Map.create(256, 256)
Map.slice(map, 256, 100, 100, 15, 15) -- map_width, x, y, width, height

Read the rest of this entry »