Category Archives: DevLog

Learning Web Assembly

Web Assembly is a technology that allows code to be compiled to a portable byte code that can be run at near-native performance.

Web Assembly modules can be run by modern browsers and called from within the Javascript of a normal web page.

This offers the tantalizing prospect of creating high-performance code for games that can run on multiple platforms without the need for the user to download or install any ‘apps’.

Mandelbrot Web Assembly

A view from within the Mandelbrot Set

The first full project I have completed using Web Assembly in the browser is a Mandelbrot Fractal Explorer.

This was a good project to learn Web Assembly as it involves a looping procedure that can require many thousands of iterations.

The Mandelbrot Set is implemented in C with a function that can be called from Javascript. There is no shared state between any of the function calls.

You can try the Mandelbrot Explorer here:

The source code is available here – in a repository I’m using to collect the projects I use to learn how to use Web Assembly:

Future Learning

The next project I try with Web Assembly will be a Cellular Automata. This will let me try something with a persistent state inside the Web-Assembly module.

I’d like to try using PixiJS as a renderer to see if it’s possible to speed up the access to the pixel buffer.

The GUI for the Mandelbrot explorer was hacked together in a few days using native Javascript. It is a bit of a pain to keep a DOM form full of data in sync with the data being used to render the image so I may try using a framework such as VueJS for this purpose.

Learning how to render the Mandelbrot set is a lot of fun and it is addictive to mess with the colours and improve performance. I ultimately decided on a limited set of features just to get the project complete as my main goal was to learn Web Assembly – not make the perfect Mandelbrot renderer.

A gallery of screenshots taken during the development process can be found here:

Get Lamp

Interactive Fiction on Twitter

I put together a twitter bot that lets you play classic Text Based Adventures through twitter. The bot runs a game on a Raspberry Pi and tweets the console output from the game. Periodically the bot checks its mentions for tweets containing commands and sends those to the game.

The bot’s twitter feed can be found here:

The source code for the bot can be found here:

I made the bot after watching an interesting documentary on the history of Interactive Fiction:

The project served as a good distraction from burnout on my other project – virtual reality snake. In that project I have been using Test Driven Development fairly heavily with the goal of having complete test coverage. It’s slow going and I reached a breaking point when I went to shuffle a list in JavaScript and found that I would have to write my own shuffle function. I didn’t really feel like writing a Fischer-Yates shuffle for the millionth time

Making a project using Python was a nice change of pace since it includes most of those little functions you often find yourself needing.

The twitter bot also served as a good opportunity to make a project using Docker. Containerization on Linux is a new concept to me and I have to say I’m completely blown away by it. It solves a lot of the problems I was having with Python in the past – chiefly: packaging Python programs for other people to use.

Repeat Fractal

I put a gallery of fractals I made here:

Devlog – Gift-wrapped Python

Cellular Automata with Python

I am interested in exploring game design focused around simulating a game world using Cellular Automata.

Conway's Game of Life

Conway’s Game of Life

Using Python I have implemented Conway’s Game of Life. The code for the project can be found in this Git Hub repository:

The code is still quite rough around the edges with plenty of TODO statements to be found.

Creating a Python Packagae

Usually I would dump my code in a folder and call it a day but for this project I decided to try and follow standard Python practice as much as possible.

This talk from Dave Forgac was a great resource:

The process of using Virtual Environments, Cookie Cutter and Tox integration testing tools was well explained.

I ran into some difficulty getting my Cython code to build correctly as this was outside the scope of the video.

After some searching I found the solution was to update the manifest file to include the code:


The Autumn CA package provides Cellular Automata computing through NumPy arrays.

Other tools such as rendering engines could import this package.

Most of the work in the short term will be ensuring the code works as a standard Python package.

Devlog – Cellular Automata

Simulating the Universe

Cellular Automata could provide interesting results for the simulation of video game worlds.

Systems using this model are described by a regular grid of cells with a numerical state. During the simulation each cell decides its next state by applying a rule function to the cells next to it.

An example of such a system is Conway’s Game of Life. This famous Cellular Automaton shows how incredible complexity can arise from a system with simple rules.

All of the cells change their state at the same time using the data from the last state. This is interesting because it means Cellular Automata could benefit from parallel processing from multi-core CPUs, GPUs and perhaps even Quantum Computing.

Besides simulating the universe Cellular Automata can be used to make psychedelic ‘living paintings’:

Creating my own CA with Python

I have made some progress in creating my own Cellular Automata using Python:

Game Of Life - Python

Conway’s game of life running in Python. Rendered using Pygame.

The first iteration can run a 100×100 simulation at around 13 frames per second. Python’s lists were used for the data structure so the performance is not great.

Now that I have the basic structure of the program and benchmarking system I am working on making a faster version using the NumPy library. It provides access to fast arrays implemented in C so it should be possible to make the simulation much faster.

Unfortunately the process of speeding up the program is more involved than putting ‘import numpy’ at the top of the file. This is my first time trying to use NumPy Arrays and it is an interesting learning process!

DevLog: One Step Forwards – Two Steps Back

The development of the Flower Plower prototype is currently on pause.

Flower Plower started 5 months ago with the hopes of making a ‘quick prototype’ that would give me a chance to develop my tools and frameworks so that future games could be prototyped more quickly.

The overall design of the game was not completely solid. I had some vague ideas of how things would work but changed my mind as things progressed. The design of the project changed from Pacman to Chu Chu Rocket.

While I still really like the idea for Flower Plower as a simulation puzzle the process of converting the code from how it was designed for a maze running arcade game to a puzzle game is getting in the way of the initial goal for the game: Optimize my Unity Workflow

The work I have done so far on Flower Plower was by no means a waste of time as I was focusing on code that I can re-use for any game.

I have taken the code that I developed for Flower Plower and re-purposed it for a new game. Now I can focus on building my tools and solving the problems relevant to many games rather than refactoring classes and staring at compiler warnings.

The idea for the new game is kinda dumb so I’m really excited to work on it!

Devlog – Discretion Required

Booming flower prices promise great rewards for the fastest Flower Plower!

Initially Flower Plower was conceived as a Pacman style maze running game.

The design of that game called for a continuous movement grid. Objects on the grid can move smoothly between grid cells but are only allowed to turn when they are in the center of a grid space.

Objects have two variables controlling their direction. Current Direction and Desired Direction. If the object wants to change its direction it sets the Desired Direction variable.

When the object reaches the center of a grid space it checks if the Current Direction is equal to Desired Direction and tries to turn if not. If a wall is blocking the turn the Current Direction remains the same until it is possible to turn.

This system allows the player to hold the direction they want to turn early and their character will turn when it is possible.

Continuous Grid Turn

Objects move continuously and are only allowed to turn in the center of a grid node.

One added complexity is allowing 180 degree turns in between tiles. It might feel better to allow players to turn slightly late and move back to perform a turn – just a slightly wider window of opportunity.

This system works well for a Pacman style maze runner but now that my prototype is heading in a simulation puzzle direction I have decided to use a discrete grid.

A discrete grid uses arrays of integers for positions rather than Unity vector3s with float values. This means that an object can not be between two grid locations.

This approach has brought with it a lot of additional complexity but I am starting to see the light at the end of the tunnel! So hopefully there will be more details in a future post.

Devlog – Fine by Design

Coordinate the chaos of flower farming during boom times. Become the ultimate Flower Plower

The Limitations of the Design

The initial plan for the game was something similar to Pac Man where you plant seeds and grow flowers.

As development progressed important questions such as ‘What should the player do?’ and ‘What makes the game fun?’ were mostly answered by hand waving.

The rough idea is that the player would plant flowers in the paths between fields. The fields would be filled with sheep who would periodically move from one field to another blocking the paths. As the game progressed the player would expand their network of fields and paths so the strategy would be to create paths that would be good for farming big combos from the flowers while still having enough branches to avoid the sheep.

On the surface it sounds great but when trying to make the ideas more concrete it becomes more difficult to find the fun. Flocks of sheep that block the maze as the main obstacle isn’t great and while the idea that the player creates their own maze is cool the mazes would ultimately be a little dull. After creating your own 4 directional maze you will still end up with a simple maze – it’s hard to see where there’s much room for excitement.

Simulation Puzzle

So the new idea is something of a Simulation Puzzle.

The player places signals on the farm that control the movement of tractors. The tractors pull trailers that will perform actions such as planting seeds and harvesting flowers. The game will reward getting things done as fast as possible and their will be an emphasis on timing actions so that they occur simultaneously.

The main influences on the design currently would be the Dreamcast classic Chu Chu Rocket and a great construction sim called Factorio. There should be plenty of potential fun to be found from setting a farm up, watching it run and trying to improve the amount of flowers you can produce.

Implementation Progress

A focus of the implementation strategy is to reduce coupling between components so that the game objects can be repurposed without throwing out all the code. Happily the plan is working and good progress is being made.

The new design does have the requirement that objects should move across the grid in a predictable fashion.

Objects move continuously through the grid using floating point numbers to represent their current position. The downside to this is that if you move two objects the same distance at the same speed they may arrive on different frames.

This indeterminism is caused by inaccuracies that can result from rounding floating point numbers. Long numbers can’t be represented exactly by a 32-bit number so over time mistakes will creep in.

I have dealt with this problem before when trying to make an action replay system for Jet The Pack and my solution then was to just scrap the replay system. It’s very hard to get the Unity physics engine to do the same thing twice.

For this game I plan to update the objects that move on the grid so that logically they are only ever in the center of a tile. They can move periodically using a tick sent through the event system and the meshes that provide their graphics on-screen can be moved over time using linear interpolation.

Devlog – Every Event Needs a Queue

Sow the seeds of an ultimate score rush combo in Flower Plower!

Before adding exciting gameplay features an important question has to be answered:

How do game objects talk to each other?

One of the most important goals of software design is to reduce coupling.

Coupling occurs when the actions of one system depend on the state of another. If two objects are coupled then making changes one could result in a bug in the other. As the game grows in complexity this can lead to frustrating hours reading stack traces.

Ideally the components of the game should know nothing about each other. The tractor should have no idea what a flower is, how gravity ties it to the road or what strange force is compelling it to change direction. The tractor should sit in isolation just doing whatever tractors do.

If all the components are completely separate then how does the system handle interactions between them? How does the tractor tell the game that it just harvested a flower and scored a point if it doesn’t know what a flower is or even that its performance as a tractor is being evaluated?

This is where Software Design Patterns come in handy. This problem of code getting hairy when components meet has been suffered and studied for a long time. Some smart people have identified the problems that happen most frequently and come up with some template solutions that can solve them.

For this project I went with the Event Queue:

The specifics of my Unity implementation are somewhat different but it has the following features:

  • An Event Queue component can be added to any object and stores a list of events that happened on that frame – the list is cleared during LateUpdate (So technically it’s the events that happened last frame).
  • Objects can read or post events using an Event Queue Accessor component. The accessor component stores a reference to the event queue and actively checks rather than being notified by the queue.
  • The Event Queue does not store a reference to Event Accessor components so it will not keep them alive if they are destroyed. The accessors need to have their reference to the queue set when they are cloned at run time.

An example of how I have used it in Flower Plower would be the detection of the tractor colliding with the flower. Both these objects have a parent called ‘Farm’ with an event queue.

When the flower collider detects a collision with a harvester it puts a ‘Flower Harvested’ event on the farm’s queue. The Score and Audio system don’t need to know the specifics of the collision but they can check the farm’s event queue to find out what’s going on on the farm.

It’s a powerful idea that the Flower and Tractor can do their thing without having to report to any component except to say ‘This Happened’ to the event manager it makes it possible to combine modules in various ways. E.g. the same Tractor that is used for player control could be used in a game demo system.

It took a lot of work to prototype this important system but hopefully it will work well throughout the rest of the development.

As a reward for making it through that wall of text here’s a bonus video of some integration tests running!

Just look at those glorious green ticks.

Each test starts the game and goes through the menus before doing their thing so any weird edge-cases will be caught! My last game Spacebomb has some glitches that can make the player totally invincible so I’d like to avoid that this time.

Devlog – Progressive Regression

Flower Plower is an arcade maze runner where you use a tractor to plant and harvest flowers. Score enough points and you can create new areas on the map. Shape the layout of the maze to maximize your combos and achieve high scores. Just don’t run over your sheep!


Progress is coming along nicely on the prototype version of flower plower.

The basic mechanics of driving a tractor around planting and harvesting flowers are in place as this high quality but low file-size webm video will show

Recording videos and producing good quality web-friendly videos has been a learning curve. The current process is as follows:

  1. Record the screen using Open Broadcaster Software
  2. Edit the video using Power Director
  3. Convert to the video to webm using FFMPEG (My version of Power Director does not support webm).

It’s a slow process but it works!

Regression Testing

There’s currently a bug that occurs when the player changes direction when between two tiles.

As part of my new commitment to following some sort of Software Engineering practice I decided to make a test to re-create the bug before even attempting to fix it:

I had to redesign the input handling so that it would be possible to control the tractor via test scripts. The code is a lot stronger as a result!

I used the Command Pattern to encapsulate any calls to Unity’s Input methods. It helps reduce coupling and now it’s possible to create some sort of replay system if I decide to.

Creating a test that recreates the bug before attempting to fix it is a nice way to approach the problem as it gives you a chance to figure out exactly what the problem is before poking in code.

Unity’s Test Runner is great for executing testings from within the editor. It’s satisfying to watch all the tests run…

Devlog – Adventures in Pathfinding

I am currently prototyping a new game that works a lot like Pac Man except you’re a farmer planting and harvesting flowers.

The finer details of the game are still to be worked out. The first prototype had an open grid of squares and the player was able to move freely in any direction.

Flower Plower Prototype

An open grid did not work well with Pac Man style controls.

This approach did not work due to how the movement system works. The player’s tractor moves continuously in a straight line but is only allowed to turn when it is in the centre of a tile. Turning felt unresponsive if the player turned between tiles.

As a solution I decided to try mazes with long corridors. I wanted a maze that would start small but grow into a large maze as the player progressed.

Starting Maze

The maze starts with 1 square and grows as the player scores points.

After dusting of the old Data Structures and Algorithms textbooks I thought that a good approach would be to use a graph data structure. I put together a simple implementation using C# that I’ll share on GitHub in the future.

One constraint on the grid is that there should always be an Euler Cycle available. This means that it should be able to visit every path in the maze without repeats. The player’s score will scale with big combos of flowers so it’d be nice to always have plenty of scope for long chains without repeats.

The easiest way to accomplish this was to make sure that each node in the grid has 2 or 4 paths as continuous graphs where all nodes have an even number of vertices will always have an Euler cycle.

Maze Extension

The results of applying 1 extension to the grid.

The algorithm for extending the maze is as follows:

  1. Select 2 random degree two nodes. (I.e. Nodes with 2 links.)
  2. Add an extra link to each of these nodes so there are 2 nodes in the graph with 1 link.
  3. While there remains an odd node in the graph: Link it to another odd node.

All being well this method can be used to extend the maze while ensuring there’s an Euler cycle.

Big Maze

A large maze created by repeatedly extending the maze with this algorithm.

When the method works it can generate large mazes with Euler cycles very quickly however it has 2 major disadvantages:

  1. It is complex and error prone: On the plus side I now know how to recover Unity from an infinite loop. On the negative side I put Unity into many infinite loops and chased many frustrating bugs trying to get the thing to work. It would be difficult to further tune the algorithm for varied gameplay.
  2. The mazes aren’t that fun: There’s an infinite variety of mazes but they’re all quite ‘samey’. Playing on random mazes doesn’t seem like it will be terribly engaging.

So while the random maze prototype did not completely pan out it wasn’t a total waste of time. I have a decent graph data structure that can be used to represent levels in future version and some path-finding code that can be used for AI.

Scratch Memory Match

Memory match card game tutorial in progress.

In other news I have a Scratch tutorial in progress detailing how a memory match card game could work.

The Scratch code is nearly complete and I’ll be starting the write-up soon.