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.

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


Hunting the Wumpus (Searching For "The Ultimate" GameDev Tool)

On Hunting the Wumpus (The Quest for “The Ultimate” GameDev Tool)

I embark upon a quest that cannot be achieved. No, there is no “Ultimate” GameDev tool.

Mostly, I’m looking for one that makes me the least grumpy.

So, the best way I can think of to do this is to try things, take some metrics, and come up with a score.

I’ve decided to go with a “Grumpiness Index” (a negative score) instead of a positive merit based score. This just means that low scores are good.

So, I have categories:

  • Cross Platform(Weight: 3): does the tool allow building for multiple platforms?
  • Local Storage(Weight: 9): can I save data to be retrieved later?
  • Text Input(Weight: 3): can I get an actual unicode input string from the player?
  • Localization(Weight: 3): how hard is it to change display language?
  • Debugging(Weight: 9): how bad are the debugging tools?
  • Strongly Typed(Weight: 3): versus weakly typed.
  • Web Service(Weight: 9): how hard is it to make a request to a web page and get a result?
  • Database(Weight: 1): can I connect to a databse?
  • GamePad(Weight: 1): is using the gamepad supported?
  • Cost(Weight: 9): how expensive is it?
  • Ramp Up(Weight: 9): how difficult is it to learn?

Notice the Weight values after each. A 1 is a “nice to have” and a 9 is an essential feature. A 3 I can live without, but prefer not to.

When evaluating something, I will also give scores of 1, 3 or 9. Occasionally, I’ll give a 0 for the Cost category when something is free, 1 if something isn’t too much of a hassle, 3 if it is a minor pain point, and 9 if it is an intolerable deal breaker.

Multiply scores by weights, add them up, and get a grumpiness score, called the wumpuscore.