Raspberry Pi · Uncategorized

Suddenly, I find myself using VIM

From time to time, I wander into very different directions. Last week, on a whim, I decided to buy myself a Raspberry Pi Zero W with the pins soldered in (because while I technically have the capability of soldering the pins, my practice with soldering is practically nil).

Also got a case, the joy bonnet (makes it like a game controller), and an mini HDMI adapter.

And in the last few days, I have done things that I never generally do. I’ve burned images onto SD cards, I’ve dinked with config files. I’ve puTTY’d and sudo’d.

In other words, I’d say I’ve been having a Flintstonian “gay old time.”

Originally, I had been thinking python, and indeed I had been learning python and pygame. After the number of languages I’ve learned and used over the years, I give python the following summation: “it’s a module based language about scope and indentation level(really, the two things are identical in python), and a rather useful ‘in’ operator”, and I’m certain I will be glad I familiarized myself with it.

But ultimately, I said to myself, “Why don’t I just use C?”

With a few brief tutorials, the syntax for gcc is elementary, and after employing a well chosen makefile template unnecessary.

So I now ssh over the network to the pi with puTTY, work in VIM with my .c files in tabs. It works fine, with an occasional :!make. I’ve got tmux on my list of things to get more familiar with.

Mostly, I’m reminded of when I was using Turbo Pascal 5.5 in High School in 1991. No intellisense. No real debugger except printf statements.

I even took a brief look at framebuffer coding. I cleared the screen white and gray.

Normally, especially with my day job, I’m looking for a simple high level library that does all of my work for me.

When I’m doing Pi stuff, I’m the exact opposite. I’ll certainly use a library. Heck, <stdio.h> is a high level of abstraction above the metal. But I like the low level stuff I get to do with ioctl. It dusts off a part of my brain that used to NEED to do these things.

And it’s fun. Plus, I’m not afraid of gcc or VIM or gpio pins or debouncing.

My coworker mentioned that I have all of the skills necessary to come up with a completely new arcade cabinet. I have woodworking tools. I have the ability to write code. I can wire up a breadboard to attach to joysticks and buttons to gpio pins.

I don’t know where this is heading me, but I know I won’t be any worse off for doing these things.




Roku GameDev and Me

So, recently, I dusted off the Roku SDK and started making little “games” for my children.

This one is currently unnamed, but my younger daughter says it should be named “Unicorn and Star”. Naming is hard, and she’s 4.

Unicorn and Star it is, then!


The current version can be installed by clicking here. If that doesn’t work, try here. If that doesn’t work, you are a future person, and it is no longer available.

The goal of the game is to move the unicorn onto the star. At that point, the star then moves to a random spot, and you can move the unicorn to it again.

It challenged my concept of “game,” because it has no success metric, but I am reminded that game in the current use of the word encompasses all forms of digital interactive media, for which this certainly qualifies.

I got the graphics from http://game-icons.net, to no one’s surprise. The Unicorn is by Delapouite, and the Star is by Lorc.

The maze generation is, as usual, my homegrown implementation of Prim’s Algorithm.

My older daughter played for a good ten minutes this morning, so it is successful for now. Methinks it will need enhancements before too long, however.




F# is bad for Game Development

Yes. The title is misleading. I will explain.

It isn’t just F# that is bad for Game Development. It is just the functional programming language I’m most familiar with and can actually use “effectively”.

To be more complete…. functional languages are bad for game development.

I had two main problems with the F# community. First, I was told a number of times that my code wasn’t pure enough, functional enough, etc. Because it wasn’t, and could not be, because I was making games.

The second is because the group used terms like inclusiveness like a banner of pride, but is really a cult that expects normative behavior. This will be my final mention of this. Don’t talk to me about it, you will get a “cool story bro” at best or a “get off my lawn” at worst.

Back to functional languages being bad for games. Why do I say this?

It would be more accurate, and less accusative, if I were to state “game projects are a poor choice for functional languages”.

And even so, you might ask why.

Let us explore, for a moment, some of the things that F# and other functional languages are principally against:

  • Global state
  • Side effects

Games are pretty much nothing but state, and must be considered often as a whole. Even in a simple game like checkers, the state of the game must be considered as a whole. You don’t perform operations on pieces without regard for the rest of the board.

And video games primarily communicate with the user via graphics and sound, which are both side effects.

So games are made up of nothing but state and make all sorts of side effects as their very purpose.

This is not to say that it is impossible to make a game using F# or another functional language, but its sort of like making an imperative language do functional things. It wasn’t built with that in mind.

So like I said:

F# is bad for game development.




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 = io.open("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 itch.io.

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 game-icons.net.

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 itch.io. 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.