By day, I'm a software engineer with a particular focus on iOS, although have some not insubstantial professional experience with various backend technologies and other client platforms. I consider myself to be a pragmatic, product focused engineer. I've always been more motivated by the thing I'm making (and it's impact) than the way I'm making it. I care a lot about team culture and making sure we create an environment that works for everyone, as well as treating our process as something that can be constantly iterated on, improved, and adapted as our circumstances change.
I spend quite a bit of my time on procedural generation, aka "teaching a computer to make things". I am particularly interested in creature generation, and within that have been mostly focused on generating dinosaurs. I'm also a regular contributor to Seeds, the PROCJAM zine.
My main procedural generation project is "THE DINOSAUR GENERATOR", you can probably guess what it does. It's a long term exploratory project, rather than having any particular long term goals. The current medium term goal is to generate skeletal diagrams, like this.
The original idea was to use applied domain specific knowledge to inform the generation process, whilst keeping it generalisable and as flexible as possible. It does so by focusing on things such as meta data as part of the generation process, which can then help the output be used in a game (e.g. animating, or figuring out how the dinosaur fits in the world, what it probably ate, its predators etc.)
It's implemented using a custom domain specific language (DSL), called Anatomy.
Originally created for THE DINOSAUR GENERATOR, Anatomy is a DSL implemented in Racket, capable of specifying parameterised arbitrary skeletons. It's designed to be used to create procedural creature generators. For example, a single bird skeleton could be defined, with parameters that modify various aspects of it, so that, depending on the parameter values, different bird species can be represented.
The example shows animated changing parameter values, showing how the same skeleton definition can be used to represent multiple dinosaurs. You can view the source on github, or read more about it in the seeds article. I also presented it at Racketfest.
Originally created for PROCJAM 2017, THE tinySAUR GENERATOR is a twitter bot that tweets procedurally generated small scale pixel dinosaurs. It tweets once a day, at 7pm (UTC), from 11/12/2017 until eternity. A tinySAUR a day keeps the ARHGH aHHH OH MY GO......
It's the little sibling to my much more ambitious project THE DINOSAUR GENERATOR. Whereas THE DINOSAUR GENERATOR is ambitious and focuses on things like generalisability and reusability, THE tinySAUR GENERATOR does none of that, doing whatever seemed most expedient to making pretty little pixelated dinosaurs at the time.
It's written in Python, using NumPy and Pillow, TkInter for the GUI, and Tweepy and Heroku for the Twitter bot. You can read more about its design in the Seeds article.
There is also a tinySAUR server that you can use for your own nefarious purposes at tiny.dinos.dev (that's right, I own dinos.dev!). The below images are procedurally generated live, so will be different every time you refresh the page.
A spin off of the THE tinySAUR GENERATOR, THE tinyHORSE GENERATOR is a twitter bot works in largely the same way, with the main technical addition being a hair system that allows for different lengths, which builds on the feather system of the tinysaurs. I think the main interesting thing about it is how the general approach works with a more constrained set of output targets, compared with the tinysaur generator. For each horse, there's a small chance it will use the tinysaur generator's colourer, which is why the colours sometimes seem very unhorse like. Also look out for something more mythical every now and then.
Remember, fifty tinyHorses a day keep the horse sized ducks away.
Created for PROCJAM 2018, THE SAUROPOD GENERATOR was conceived of as a medium point between THE tinySAUR GENERATOR and THE DINOSAUR GENERATOR, but with more constrained output target (i.e. sauropods), so I could finish it more quickly. The idea was to be more pragmatic than the dinosaur generator, but a bit more flexible than the tinysaur generator. It works in a fairly similar manner to the tinysaur generator, with the swapping out of different body parts, but also performs transformations on these parts, much like the dinosaur generator, making it nearly as quick to develop as the former, but with a lot of the befits of the latter. Another appeal of the idea was that it would allow me to produce a 3D generator relatively quickly. Unfortunately, the development time was cut short due to illness, so it's not quite as fleshed out as I'd like. I do really like the colour palette though, and may reuse it in the future.
I've been a regular contributer to Seeds, the PROCJAM zine for a few years now
In which I attempt to explain how to use language oriented programming for proc gen in less than 800 words, including Anatomy and THE DINOSAUR GENERATOR as an example. Ultimately, it's a lot to cover in 800 words, and I think may be worth a longer exploration at some point. It's a concept I'm particularly keen to explore more as it applies to proc gen, as it can potentially make proc gen accessible even to none programmers.
Rock Paper Shotgun (the PC gaming site) wrote about it! I discovered this organically, whilst scrolling through the site, which was so cool! It includes this quote, which I particularly enjoy:
I originally created THE tinySAUR GENERATOR for PROCJAM 2017, and then wrote a bit about it for next year's Seeds. If you want to learn how it works, you can read my article directly, or read the complete 3rd issue here.Rock Paper Shotgun (the PC gaming site) wrote about it! This was the first time having anything I'd made be written or featured by anyone, and was very exciting! They even used my image for the main article image and was the first time anyone really paid attention to what I was making.
In the first issue of Seeds I took part in, I had two separate articles. You can find the full PDF here.
The first is on Turing patterns (p29), and how to generate them by performing the simulation of a reaction-diffusion system on a grid. Turing patterns encompass a wide variety of natural patterns, including spirals, stripes, and spots, and appear everywhere in nature, from zebras, to leopards, to giraffes, to obnoxious 80s wallpaper. Such a system can therefore be used for the procedural generation of highly varied and naturalistic textures.
The second is on THE DINOSAUR GENERATOR (p82), and explains a little of how it works, and the motivation behind it.
I'm fortunate to have had my work mentioned in Rock Paper Shotgun (the PC gaming site) twice. The first time for my 2018 article on THE tinySaur GENERATOR, and the second for my 2019 article on "Writing programming languages for procedural generation". Given that they have a readership in the millions, their coverage represents the height of my proc gen notoriety. I was very excited that both times they used my images for the article headers. Here's a visual depiction of exactly how excited I was.
I was very excited to be invited to speak at Racketfest in February 2020, to talk about how I use Racket for "Programming a Programming Language in Which to Program Dinosaurs". Had you been there, you could "Learn how I use Racket and language-oriented programming to procedurally generate dinosaurs, and potentially other animals, through my own DSL. This language, called Anatomy, lets me concisely define bones and how they can change in relation to one another, letting me define a generic dinosaur skeleton that’s capable of morphing into any dinosaur! Learn even more about different ways you can use language oriented programming for procedural generation, but most of all, expect to learn more about taxonomy than you wanted to!""
For a hackday at Deliveroo, I wrote a procedural experiment idea generator for the consumer app (e.g. "Make higher discount offers more visible"). It was implemented using a DSL that can be used to write programs that output arbitrary descriptions, called ‘Terms’. It’s fairly simple: a Terms program consists of a file defining the structure of the description (e.g. ‘a [size] [shape] [colour] egg with [spots]’), and then a file for each descriptor listing the possibilities (e.g. for colour “white, blue, green, ecru…”). When run, it then selects a possibility for each term, producing a description as output. Given the limits of a hackday, there's a lot of room for further development, such as constraints on which descriptors can go with others, and making certain descriptors optional.
I play guitar in a band called Pigeon Queen! I refuse to play any guitar that isn't a hollow body or that doesn't have a Bigsby.
I used to do quite a variety of creative pursuits, but now mostly focus on guitar/bass/music as I enjoy the process more. This has left me with quite a wide variety of skills, but with most of these activities, I became too focused on the results, and stopped enjoying the process. I used to spend a lot of my time sculpting, both with polymer clay and digitally (with Maya), and did a fair amount of drawing. I also enjoy wildlife photography (enjoying the wildlife more than the photography). I used to do figure skating and play ice hockey, and now, in the absence of an ice rink, now I occasionally rollerblade.
I've dabbled in lots of different things, such as making t-shirts, graphic design, making websites (like this one!), and I just generally enjoy making things, or, perhaps more accurately, really don't enjoy it when I can't make things.
In the past, I've invested a lot of time and energy into game development (time and energy that is now mostly invested into procedural generation). In many ways, it turned me into the software engineer I am today, in part because of its interesting technical problems, but mostly because of the difficulty of creating a complete game as an individual/duo, and the necessary pragmatism it inspires. I gave a presentation on this topic entitled "Game Development and Me: How Game Development Made Me a Worse Developer". How tongue in cheek that title is depends largely on your opinion of me as a developer.
My biggest claim to fame is demoing a game to Peter Molyneux at Molyjam 2013. It was an iOS stealth game where you played as a chameleon, and had to find ways to change your emotions so you could blend into the background and avoid being seen. You had to infiltrate Peter Molyneux's secret lair, where he was hiding nuclear weapons and threatening to blow up the games industry. He tweeted about it, which remains the highlight of my game dev career. I didn't finish the game after the jam since I wanted to focus on a different project at the time, but I did produce this informative leaflet.
I have strong opinions on game development, and generally don't love the direction the medium has moved in. In general, I like games that are systems driven, with intelligent agents, emergent strategy, and "avant-garde problem solving". The general approach could maybe described as building worlds and simulations, then building a game within that. Dwarf fortress is a good, if rather extreme and inaccessible, example of this. There are many games I'd like to make that I will likely never make, with the top of the list being "Dinosaurs with Cities on Their Backs".