{"id":29,"date":"2011-06-25T01:00:46","date_gmt":"2011-06-25T06:00:46","guid":{"rendered":"http:\/\/www.playwithlua.com\/?p=29"},"modified":"2020-05-22T13:32:08","modified_gmt":"2020-05-22T18:32:08","slug":"a-simple-puzzle-game-part-2","status":"publish","type":"post","link":"http:\/\/www.playwithlua.com\/?p=29","title":{"rendered":"A simple puzzle game (part 2)"},"content":{"rendered":"

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.<\/p>\n

I’m going to do this by using a game framework called Löve<\/a>. 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<\/i> 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!
\n
\nFirst, some organizational issues. Löve expects its games to be in folders, and to start with a file called main.lua<\/code>; this is the file that it will run first when it loads the game. So, let’s make a new directory, fallgame<\/code>, put our original file<\/a> in it (called fall.lua<\/code>, say), and put alongside it a file called main.lua<\/code> that Löve will actually run. main.lua<\/code> should do require 'fall'<\/code> on the first line, to load in all the code we wrote last time. Now, if you run Löve on that same directory, you should get a black window, because you’ve told it to load in a bunch of code but not actually do anything with it.<\/p>\n

How to run it, by the way, is platform-dependent<\/a>. I strongly recommend adding the directory containing Löve to your PATH<\/code> though, so you can just type love .<\/code> every time.<\/p>\n

Callbacks<\/h2>\n

Löve works around the idea of callbacks<\/i>. Your program doesn’t touch the flow of control; you define a handful of functions that it calls when it’s the right time: love.load()<\/code> once during startup, love.mousepressed()<\/code> when the player presses a mouse button, and so on. First thing we want to do is get rid of that ugly gray background, so let’s define a love.load<\/code> that sets a background color of a nice, tasteful blue-gray:<\/p>\n\n

require<\/span> 'fall'<\/span>\n \nfunction<\/span> love.<\/span>load(<\/span>)<\/span>\n   love.<\/span>graphics.<\/span>setBackgroundColor(<\/span>82<\/span>,<\/span>82<\/span>,<\/span>128<\/span>)<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
Now when you start it, it will load all the code in fall.lua<\/code>, then Löve will call love.load<\/code>, which will set the background color. We still need a board though, and love.load<\/code> is the proper place to set that up, so add this into that function:<\/p>\n\n
math.randomseed<\/span>(<\/span>love.<\/span>timer.<\/span>getMicroTime(<\/span>)<\/span>)<\/span>\nboard =<\/span> populate_board(<\/span>make_board(<\/span>8<\/span>)<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
The first line makes sure the board is random by seeding the random-number generator, and the second line calls our old functions from last time to make and fill a board (note we don’t say local board<\/code> anywhere; the board is stored in a global variable). Now we just need to draw it.<\/p>\n
Loading images<\/h2>\n
Löve has a lot of support for drawing tile-based graphics. The idea is you put all your images on one big tilesheet, and then cut rectangular areas out of it to display. We can load the image with love.graphics.newImage<\/code>, and then each rectangular area we want to draw is called a quad<\/i>. The image I made looks like this:<\/p>\n
\"\"<\/a><\/p>\n
I’m definitely not an artist, but I think it has a kind of SNES-era appeal. Each tile is 48×48 (blown up 300% from a 16×16 original) and there’s no spacing between them. Don’t forget to copy this or an image like it to your game directory.<\/p>\n
We want to have a big table of quads, where the keys are the things in our board (1-4 for the blocks and a-d for the crushers) and the values are quads that will cut sections out of this sheet. So we add this to love.load<\/code>:<\/p>\n\n
   tiles =<\/span> {<\/span>}<\/span>\n   for<\/span> k,<\/span>v in<\/span> pairs<\/span>{<\/span>'a'<\/span>,<\/span>'b'<\/span>,<\/span>'c'<\/span>,<\/span>'d'<\/span>}<\/span> do<\/span>\n      tiles[<\/span>k]<\/span> =<\/span> love.<\/span>graphics.<\/span>newQuad(<\/span>48<\/span>*<\/span>(<\/span>k-<\/span>1<\/span>)<\/span>,<\/span> 0<\/span>,<\/span> -- x, y<\/span>\n                                       48<\/span>,<\/span> 48<\/span>,<\/span> 48<\/span>*<\/span>4<\/span>,<\/span> 48<\/span>*<\/span>2<\/span>)<\/span> -- width, height, image dimensions<\/span>\n      tiles[<\/span>v]<\/span> =<\/span> love.<\/span>graphics.<\/span>newQuad(<\/span>48<\/span>*<\/span>(<\/span>k-<\/span>1<\/span>)<\/span>,<\/span> 48<\/span>,<\/span> -- x, y<\/span>\n                                       48<\/span>,<\/span> 48<\/span>,<\/span> 48<\/span>*<\/span>4<\/span>,<\/span> 48<\/span>*<\/span>2<\/span>)<\/span> -- width, height, image dimensions<\/span>\n   end<\/span><\/pre><\/div><\/div><\/div>\n\n
For that table {'a','b','c','d'}<\/code>, the pairs are (1, ‘a’), (2, ‘b’), and so on. So we can go through the table once and get all the quads we need.<\/p>\n
Drawing the board<\/h2>\n
Let’s draw the board in the center of the screen. We first want to determine the center of the screen, by dividing the screen size by 2 and subtracting half the board size. Since we know the board is 8×8 and it’s made of 48×48 tiles, it’s easy to figure that out:<\/p>\n\n
function<\/span> love.<\/span>draw(<\/span>)<\/span>\n   local<\/span> g =<\/span> love.<\/span>graphics\n   local<\/span> w,<\/span> h =<\/span> g.<\/span>getWidth(<\/span>)<\/span>,<\/span> g.<\/span>getHeight(<\/span>)<\/span>\n   local<\/span> left,<\/span> top =<\/span> w\/<\/span>2<\/span> -<\/span> 48<\/span>*<\/span>board.<\/span>size\/<\/span>2<\/span>,<\/span> h\/<\/span>2<\/span> -<\/span> 48<\/span>*<\/span>board.<\/span>size\/<\/span>2<\/span>\n \n   -- actually draw the board here<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
Actually drawing the board is simple. It’s a loop just like the ones in fall.lua<\/code>, and we call love.graphics.drawq<\/code> to draw a quad inside it (after looking up the correct quad based on the contents of the cell). This goes in love.draw<\/code>:<\/p>\n\n
   for<\/span> n=<\/span>0<\/span>,<\/span> board.<\/span>size *<\/span> board.<\/span>size -<\/span> 1<\/span> do<\/span>\n      local<\/span> x,<\/span> y =<\/span> n %<\/span> board.<\/span>size,<\/span> math.floor<\/span>(<\/span>n \/<\/span> board.<\/span>size)<\/span>\n      if<\/span> board[<\/span>n]<\/span> ~=<\/span> 0<\/span> then<\/span>\n         g.<\/span>drawq(<\/span>img,<\/span> tiles[<\/span>board[<\/span>n]<\/span>]<\/span>,<\/span>\n                 left +<\/span> x*<\/span>48<\/span>,<\/span>\n                 top +<\/span> y*<\/span>48<\/span>)<\/span>\n      end<\/span>\n   end<\/span><\/pre><\/div><\/div><\/div>\n\n
Taking input, updating the game state<\/h2>\n
Right now we can draw the board but that’s pretty much it. For a first step, let’s hook up rotating the board. We want to read in mouse clicks (left to rotate counter-clockwise, right for clockwise) and have the board rotate in response, after animating. So, what we’ll do is, have a global rotation_speed<\/code> variable, and a global angle<\/code> variable. When they click the mouse, we set the rotation speed (either positive or negative):<\/p>\n\n
function<\/span> love.<\/span>mousepressed(<\/span>x,<\/span> y,<\/span> btn)<\/span>\n   if<\/span> rotation_speed ~=<\/span> 0<\/span> then<\/span> return<\/span>\n   elseif<\/span> btn ==<\/span> 'l'<\/span> then<\/span> rotation_speed,<\/span> angle =<\/span> -<\/span>2<\/span>,<\/span> 0<\/span>\n   elseif<\/span> btn ==<\/span> 'r'<\/span> then<\/span> rotation_speed,<\/span> angle =<\/span> 2<\/span>,<\/span> 0<\/span>\n   end<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
And every time love.update<\/code> is called, we’ll update angle<\/code> based on that.<\/p>\n
This is a tricky one. When update<\/code> gets called, it’s passed the time since the last time it was called. We can use this to determine how much to change our internal model, without actually knowing or caring about our frames-per-second. It sounds tricky, but the rule of thumb is straightforward: just multiply all velocities by dt<\/code>. Here it is:<\/p>\n\n
function<\/span> love.<\/span>update(<\/span>dt)<\/span>\n   angle =<\/span> angle +<\/span> rotation_speed *<\/span> dt\n \n   if<\/span> rotation_speed &gt;<\/span> 0<\/span> and<\/span> angle &gt;=<\/span> math.pi<\/span>\/<\/span>2<\/span> then<\/span>\n      board,<\/span> rotation_speed,<\/span> angle =<\/span> rotate(<\/span>board)<\/span>,<\/span> 0<\/span>,<\/span> 0<\/span>\n   elseif<\/span> rotation_speed &lt;<\/span> 0<\/span> and<\/span> angle &lt;=<\/span> -<\/span>math.pi<\/span>\/<\/span>2<\/span> then<\/span>\n      board,<\/span> rotation_speed,<\/span> angle =<\/span> rotate(<\/span>rotate(<\/span>rotate(<\/span>board)<\/span>)<\/span>)<\/span>,<\/span> 0<\/span>,<\/span> 0<\/span>\n   end<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
The first line handles the actual rotation, the rest of it is just to detect when the rotation should stop. After we hit 90 degrees (or minus 90) we want to rotate the actual board with the game rules.<\/p>\n
One last thing and then we can play with this: we need to make the draw<\/code> function display the board rotated. The way we do this is to actually rotate the coordinate system we draw it in. Löve has two functions, translate<\/code> and rotate<\/code>, that we can use for this. We want to rotate the coordinates some around the center of the screen, so first we translate the origin to the center, then rotate by angle<\/code> radians (rotate<\/code> always rotates around the origin, which is why we translate it first), and then translate back:<\/p>\n\n
   -- Put this in love.draw before the drawing loop<\/span>\n   g.<\/span>translate(<\/span>w\/<\/span>2<\/span>,<\/span> h\/<\/span>2<\/span>)<\/span>\n   g.<\/span>rotate(<\/span>angle)<\/span>\n   g.<\/span>translate(<\/span>-<\/span>w\/<\/span>2<\/span>,-<\/span>h\/<\/span>2<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
Now you can load it up again and watch the board move around in response to your clicks.<\/p>\n
A problem arises<\/h2>\n
It may not look like it, but this is actually very bad code. If we tried to write the whole game like this, it would rapidly become very difficult to do. The problem lies in love.update<\/code>: it operates on two different levels of abstraction. On one level, it is responsible for keeping angle<\/code> updated in response to the game state created by love.mousepressed<\/code>, but it’s also where we put the code to update the actual game rules. This is clean enough when there are only three states the game can be in (rotating left, rotating right, or still) but even our simple game has many more states than that:<\/p>\n