A Lua Snippet for Describing Tables to a File

function describeTable(t,indent,cache,f)
 indent = indent or ""
 cache = cache or {}
 for k,v in pairs(t) do
 local value=""
 if type(v)=="string" then
 value = "[value=\""..v.."\"]"
 elseif type(v)=="number" or type(v)=="boolean" then
 value = "[value=\""..tostring(v).."\"]"
 f:write(indent..k.." = "..tostring(v).."("..type(v)..")"..value.."\n")
 if type(v)=="table" and not cache[tostring(v)] then
 return result

local f ="output.txt","w")
love2d · lua

Bootstrapper Lua Library – Overengineered Love2D

In the games I am writing in Love2D, I tend to use various sorts of “managers” to cache things for me.

One of the more notable managers I use is an image repository. I want to simply do the following:

--loads the library

local images = require "game.images"

--caches the images

images.load() -- during love.load

--retrieves an image

local img = images.get("imageName") -- during love.draw

Typically, I don’t lazy load my images, but I could easily configure my images.lua file to do so.

I find myself faced with a number of these managers, however. I’ll have one for images, one for sound effects, one for music, one for options, one for image regions, and so on.

What I like to use for this is a meta-manager called a bootstrapper, which each of my managers will automatically add themselves to, and then during love.load, I only have to call bootstrapper.load().

So let us overengineer this solution. I’ve got my current implementation for bootstrapper:

local bootstrapper = {}

local loaders={}

function bootstrapper.add(loader)
 assert(type(loader)=="function","bootstrapper.add - loader must be a function")
 --TODO: idempotency?

function bootstrapper.load()
 for _,v in ipairs(loaders) do

return bootstrapper

And I want to add a few more bits of functionality:

  • I only want calls to bootstrapper.add to work before a call to bootstrapper.load.
  • I want to enforce only one call to bootstrapper.load.
  • I want calls to bootstrapper.add to be idempotent, as in my TODO
  • Do unit tests
  • Make bootstrapper use a proxy object, to keep it from being subverted by client code

If that all seems like a bit of overkill for something like a bootstrapper, then you are going to not like this series of articles.

The changes to the main part of the code are minor:

--bootstrapper library object
--initialize to empty object, as is my habit
local bootstrapper = {}

--static data for this library is hidden from the outside
--starts as empty table
--gets changed to nil after a call to bootstrapper.load
local loaders={}

--adds a function to the bootstrapper
--requires that the loader parameter is a function
--will throw an exception when called after bootstrapper.load
function bootstrapper.add(loader)
  assert(type(loader)=="function","bootstrapper.add - loader must be a function")
  assert(type(loaders)=="table","bootstrapper.add - cannot call after bootstrapper.load hase been called")
 --if the loader already exists in loaders, don't re-add it and just return
 for _,v in ipairs(loaders) do
   if v == loader then

function bootstrapper.load()
 assert(type(loaders)=="table","bootstrapper.load - cannot call multiple times")
 --perform the load actions
 for _,v in ipairs(loaders) do
 --eliminate loaders to keep from being re-called

I decided to make use of the static variable loaders instead of having a separate boolean flag for whether or not load has been called. There was no reason to hold on to that array after the call anyway.

Unit tests were a wholly different thing. Firstly, I don’t always want to run unit tests. I do when I’m developing, but not in release code. Of course, the scope of my activity today does not include any sort of unit testing framework, so I decided to at least mock out what I needed, with a plan to augment it later.

--runTests library
--This will eventually be a require that returns a function, so that I can turn off unit tests in one place
local runTests = function(f) f() end

  --save off old static state 
  local oldLoaders = loaders 
  loaders = {} 
  local start = os.clock() 

  --bootstrapper.add with non-function 
  local status, err = pcall(function() bootstrapper.add(nil) end) 
  assert(not status) 

  local counter = 0 
  local called1 = false 
  local called2 = false 

  function f1()  
    called1 = true 
    counter = counter + 1  
  function f2()  
    called2 = true 
    counter = counter + 1  

  --bootstrapper.add with function 
  --bootstrapper.add with same function 
  --bootstrapper.add with second function 

  --bootstrapper.add after load 
  status, err = pcall(function() bootstrapper.add(f1) end) 
  assert(not status) 
  --bootstrapper.load after load 
  status, err = pcall(function() bootstrapper.load() end) 
  assert(not status) 

  local elapsed = os.clock()-start 
  print(string.format("bootstrapper unit tests - %f",elapsed)) 
  --restore original static state 
  loaders = oldLoaders 

I set up my runTests function to call whatever function is passed to it. Eventually, this can be a library that I load instead, and I can configure that library to either run or not run the functions it passed depending on whether or not I am in “release” mode.

Before you go out and comment something about “pcall is inefficient!”, let me give you the results of these unit tests on each run of my application:


That’s right… the unit tests do not take up enough time to actually register time passing.

Finally, I make a protected proxy using a metatable:

local mt = { 
  __index=function (t,k)  
    return bootstrapper[k] 
  __newindex=function(t,k,v) end,  
local proxy = {}

return proxy

From what I read, this is all I need to do in order to protect bootstrapper from casual changes from outside code.

It occurs to me that this is going to be a common pattern I want to use, and so a more generic version of this code is likely to wind up in a utility library.

So, this concentration on making a robust bootstrapper seems to fly in the face of how I normally develop code. Almost invariably, I will recommend that one writes exactly the code that one needs, and once it is “good enough” then stop.

Actually, that is exactly what I am doing. The main difference is that this code has been deemed useful enough (by me) to be part of the framework I use in other games going forward, which means it needs to be library code – as bulletproof as I can make it.

Game Development

Click the Yellow Rhombus

So yeah. Missed adding this here, but I added Click the Yellow Rhombus over at

This is the second in a series of getting back to basics using Love2D.

In particular, CTYR required me to get good with handling mouse events. I wound up having to make simplistic controls on screen, which generally pushed me in a direction of needing a scene graph, which I have been working to build slowly since.

If you would like the source code, you can find it here.

Some of the things that got developed/advanced as compare to JetLag during this project:


I’m using actual images in CTYR, as compared to rectangles in JetLag. Some of the more simple graphics I made with InkScape.

I made the following graphics:

  • The rhombus
  • The background
  • The start button

Other graphics I got from

I get my fonts from dafont.

State Machine

CTYR has five states, so a full on state machine was an absolute need.


JetLag was keyboard only. Yes, I could have put in GamePad controls, but it would still be “hit a button on an external device” controls.

CTYR is completely mouse controlled, so controls are contextual based on where the mouse pointer is.

For this, I created a single control: the button. The start button is one. The mute and info icons are buttons. The rhombus is a button. It was all I needed.

In fact, the rhombus in CTYR is considered “clicked” if you get within its bounding box. Could I have been pixel perfect about it? Yep! Why didn’t I? I don’t need to.



Game Development

JetLag 2017


I have truly lost count of the number of times I have made more or less this exact same game.

Currently, it may be found on It requires Love2D to play it, as will all of my games for the next little while. If you are interested in the source code, you can find it here.

There is a reason I start with JetLag. When done correctly, it has all of the components of a much more sophisticated game in miniature.


I admit, the graphics are rudimentary. I use filled rectangles and text. These things are not earth shattering.  The point here is that this game draws onto the screen, and to quote Andre LaMothe: “if you can draw a pixel, you can make a game.”


It’s not quite true, about the pixel I mean. It is true that being able to draw a pixel gets you halfway to making a game. The other half is being able to get input from a player. However, once you have the ability to draw something on the screen and the ability to get any sort of input from the user, it makes game creation possible.

In JetLag, the controls are keyboard only, although I am considering supporting the gamepad as well.


Not all games require this, but enough of them do such that it may as well be a required thing. In JetLag, the love.update function hands me a time delta, from which I can calculate when to scroll the display.


JetLag can be enjoyed on mute. The music is merely there for ambiance. I’ve got some mixed feelings about game music.

When I am playing a game on my desktop computer, I may leave the music on, but this is for games like Minecraft or Yonder, where a great deal of thought has been put into the music for the game.

When I am playing a game on my phone, I immediately look to turn off the music and sound effects.  Why? because I want to be able to play the game when I’m “indisposed”, and it making noise is the last thing I want.

So I require of myself when adding music and/or sound effects that I provide a means by which it may be conveniently turned off.

Also, I’m not a composer, so while I do try to select music appropriate to the game, I’m not engineering an immersive experience here. I’m tacking on music because tacking on music is the thing to do.

Sound Effects

Sound effects I pull from sfxr/bfxr/some other sound effect generator. I’m not engineering realistic sounds.

Same deal applies for sound effects as does music. I want it there, but I want to be able to turn it off.

Persisted Preferences

And that brings me to persisted preferences. During a play session, if I turn off the audio, the next time I play, it better stay off!

So I save my preferences to disk somewhere. Love2D has a nice set of functions for saving and loading little files, and I found a usable json library for lua that suits my needs.

I also store the high score achieved in the game, just to add a little self-competition.

State Machine

JetLag has exactly two game states: game over and play, but it still qualifies as a state machine, and is a shadow of the more formalized state machines that I’ll wind up developing later.

The internal state of JetLag might look like it is a grid. It is not, because it doesn’t need to be. The renderable state is two arrays: one for block locations and one for tail locations. In fact, the only really important block/tail location is the head.

Game Development

Defold Lets Me Down, and Griblers Does Not

So, I tried defold, and after doing so, I’m going to go back to Love2D.


Defold is not a bad tool, it just isn’t for the kinds of games that I make. It is for sprite games where you jump and collide and whatnot.

I make games that take place on a grid.

This can be done in defold. Make a game object as the “controller” that responds to inputs, and have those inputs modify the grid. However, when I tried to layer my grid, the transparency didn’t work, so…

I’ve been playing a mobile game Griblers. I like it and highly recommend. It is a crafty-questy-gathery game.

Also, while I realize that I really, really, REALLY wanna make a Splorr!! game, they quickly collapse under their own weight, and really suck to work on after a short while.

So back to basics for me. JetLag, Wandermaze, Pipes, Honeycomb, etc for a while. I want to get several new/updated out on and GameJolt.