Not only that, but as of earlier this year I'm also a founding member of our Cloud Platform team, which well and truly completes my move away from being a mobile developer. I'm incredibly grateful to my current employer for giving me a chance even though my professional experience wasn't an obvious match. Sixteen months ago I doubted I'd ever be able to make this leap and now I spend my days writing Clojure tooling, libraries and services and spinning cloud infrastructure up and down with terraform. I'm learning so much every day, and most weeks I genuinely look forward to going to work.

There's nothing more to this post than that. I just wanted a record of this for myself, and just maybe it'll inspire someone else some day: I took a (small) leap by applying to the kind of job I wanted rather than what I'd been doing, someone was willing to tkae a chance on me, and now I'm happier with my work than I've been in a very long time. Sometimes you've just got to take a moment to appreciate what you've achieved and what you've got.

Clojure is my favourite language at this point; I've been using it to make art and websites for a few years, and last year got my first job using it. I was all in and I'd never have to write in a lesser language again. And then I spent most of my spare time this year writing small games in Ruby. What gives?

The reason is I wanted to make games again, and the reason is the DragonRuby Game Toolkit (DR). Many people come to DR because of Ruby, but I'm using it despite it using Ruby, so I thought I'd write down some things I think it has going for it that's not "you can write your game in Ruby".

It's a 2D-first code-only engine

For some it's a limitation, for me it's a strength. I made The Wallslider in Godot and I think it's an amazing open source project (Godot, not my game); but it does a lot of things I just don't need and they're always there in the editor. I have no interest in making 3D games. DragonRuby's focus on 2D means its APIs are designed and optimised for my use case, and I get to keep working in my beloved Emacs.

Simple, low-level, data-oriented APIs

The creator of DR, Amir Rajan, has said this aspect of DR's design is inspired by Clojure which might explain why despite the languages' many differences I feel quite at home in this strange corner of Ruby-land (all the mutation still makes me feel icky though).

There's no complex machinery or class hierarchy to hook into - just some simple basic abstractions to build on top of as you see fit.

There's a tick function (method, technically, but we can pretend), that gets called 60 times a second (or as close as it can get), and each tick you tell DR what to render, handle input, compute any changes to your game state, etc.

Rendering graphics and playing audio is just pushing hashes (maps/dictionaries) into arrays and letting the engine handle the rest. Handling input is just checking the current state.

That's about it. The rest is up to you. But actually there's lots of well considered helper functions for collision detection, easing and interpolation, animation, etc and dozens and dozens of examples provided for all kinds of game styles and features.

Dogmatic dedication to cross-platform support and easy deployment.

This is one of the main reasons I'm investing time in DR - Amir created DR to solve his own problems as a solo indie game developer trying to ship multiple games on multiple platforms.

As someone's who's built mobile apps for a living and has seen the effort that can go in supporting even just two platforms, I really appreciate the complete focus on cross platform support.

This comes with some caveats or limitations, like currently no shaders because doing this truly cross platforms is hard. A lot of these are tied to what SDL supports (one of the developers of DR is also a core contributor and maintainer of SDL), and so some shader support might be on its way with SDL3, but in the meantime it has some features that can fill in a lot of the use cases for shaders in 2D and I can trust that my code will run pretty much identically on all platforms without modification.

Building for Windows, Mac, Linux and Web with a single command is great - it can even deploy automatically to itch.io and has beta support for easier Steam deployment. I've not yet tried its mobile support and I'm unlikely to ever ship to console, but I like to know they are available with a (quite reasonably priced) pro licence.

Hot reload

Good hot reload is a super power and DR's is excellent. When I make an error, the built-in console shows me the stack trace and some often helpful error message, then the game picks right back up where it left off with my new changes applied.

For the situations where your new code can't work with the current state, you can reset the game and you're back in at the start of your game within a second.

It's actually pretty fast

"But Ruby is slow!" - a language can't be slow, silly! It's down to the implementation. DragonRuby is based on mruby, not the Ruby of Rails, which is designed to be embedded. Also a lot of the engine is actually C, and the developers are even working on a compiler for the Ruby parts. Amir gave a good overview of how the engine works and their future plans at rubyconf last year.

A lovely supporting community on Discord

The docs are somewhat lacking in places, but the community on discord (which includes the developers themselves) is always there to help and support.

The End

And that's it.

It has its quirks (when will DR get circle primitives is a running joke, "just use a sprite" is the official answer) and it lacks the ecosystem of bigger engines, but DragonRuby is pretty darn good and I plan to continue using it for my game making efforts in the foreseeable future (whilst I continue to encourage Amir to make a lisp version).

The old stack: a Clojure app that connects to a Postgres database, all hosted on Heroku. It was very easy and allowed me to ship it quickly at the time, but since the game hasn't exactly sold in huge numbers, I was making an ever increasing loss¹ on keeping the leaderboard running for the handful of people that still play it.

But I still love my little game and I love those few players! So my main goals were:

1. free, or at least no additional costs
2. very little extra maintenance burden once the migration was done

After exploring a few options², I settled on the cutting edge approach of just using an existing server!

I'm already running a small VPS on Digital Ocean that serves another Clojure app intended to host various small personal projects. That project's codebase is set up using polylith, which lends itself quite well to my needs here. I created a new component for all The Wallslider's server code and then added the few required endpoint to my app's base. That took care of the code.

While I've gotten much more comfortable with databases the last few years, it doesn't mean I want the hassle of managing a Postgres cluster. But I also don't want to pay someone to manage one for me.

Enter SQLite! As I'm running a single instance of my app on a dedicate (virtual) server, SQLite is more than enough for my needs and the data is now just a file that sits on my server. There was a little bit of SQL tweaking required but it mostly "just worked". The main downside of SQLite is the risk of data loss if something happens to that file or the server it's hosted on.

Enter Litestream! This is designed exactly for my kind of scenario, small to medium apps that want to safeguard their data but keep the simplicity of using SQLite. It does so by streaming changes to an S3 compatible bucket, which is generally pretty cheap. But better than cheap is free.

Enter Cloudflare R2! They have a generous free tier which is more than enough for my tiny app and its tiny database.

Now I have all the tools I need and a new stack: A Digitial Ocean droplet running my Clojure app (fronted by nginx, which redirects various domains to the right endpoints), SQLite and Litestream and an R2 bucket to safeguard the data.

The total cost is about 7$/month for the droplet, which I was already spending and can continue adding other small projects to it. If any project ever takes off and needs to scale, polylith should make it straightforward to package the right components into a different app and ship it separately. Overall I'm pretty happy with this new setup.

1. I'm still spending money on the domain and my Apple developer account. The latter is a fixed cost no matter how many apps I have, but currently The Wallslider is the only app I have, and I'm considering releasing a new version that points to app.freeston.me instead so I can eventually drop the domain altogether.↩
2. Including fly.io, which seems very cool and employs Ben Johnson who created Litestream.↩

The approach described here is entirely unnecessary if you control the API: add the Content-Disposition: attachment header to the response and the browser should download the file rather than display it.

The Problem

I want the user of a web page to be able select some parameters, then click a button that triggers the download of a document (in my case an SVG file) based on those selected parameters. The API being used is designed as a GET request with query parameters - this last bit is important for the approach described here to be viable.

A <form> is a nearly-perfect HTML-only solution, except that the download property is only available on anchor (<a>) elements. The best I can do is set the target attribute to _blank and have it open in a new tab or window.

It looks simply like this:

<form action="some-url" method="get" target="_blank">
  ... form content ...
  <button "type="submit">Download</button>
</form>

The Approach

I decided to use scripting to replace the <button> with an <a> tag that points to the same URL the form would and keep that URL up to date whenever the content of the form changes.

For this I decided to use hyperscript¹. Firstly, I defined a function to build up the equivalent GET url for a form and put it in a <script> tag:

def formURL(form)
  set vs to form as Values
  set params to Object.keys(vs).map( \ k -> k + '=' + vs[k]).join('&')
  return (@action of form) + '?' + params
end

Then when the page loads, I replace the button with an anchor using the following script on the submit button:

init make <a#download-link/>
put '<filename>' into its @download
put formURL(closest <form/>) into its @href
put my.innerHTML into it
put it after me
remove me

It's a bit wordy, but should be fairly self-explanatory (hyperscript is good like that). The reason I do this part with a script rather than simply use an anchor to begin with is to embrace the idea of progressive enhancement. If JavaScript is disabled or the HyperScript dependency can't be loaded, we're still left with our default working behaviour of opening the file into a new tab.

With a bit of CSS I can make the button and the anchor look the same, making the experience virtually identical in both scenarios (apart from the download enhancement) and avoid any visible flash as one element replaces the other.

Finally, the key part is to keep the URL up to date as the form's inputs change, which can now be done by attaching this one-liner to the form element²:

on change put formURL(me) into @href of #download-link

The Result

The resulting code is sufficiently generic that it should be possible to drop this into any HTML page and have it mostly "just work"³:

<script src="https://unpkg.com/hyperscript.org@0.9.5"></script>

<script type="text/hyperscript">
  def formURL(form)
    set vs to form as Values
    set params to Object.keys(vs).map( \ k -> k + '=' + vs[k]).join('&')
    return (@action of form) + '?' + params
  end
</script>

<form action="some-url" method="get" target="_blank"
      _="on change put formURL(me) into @href of #download-link">

  ... form content ...
  
  <button type="submit"
          _= "init make <a#download-link/>
              put '<filename>' into its @download
              put formURL(closest <form/>) into its @href
              put my.innerHTML into it
              put it after me
              remove me">
    Download
  </button>
</form>

1. For no other reason than I've been meaning to give it and its companion htmx a go, though it does seem particularly well suited to this kind of DOM manipulation.↩
2. At first I thought I needed to attach this script to every field in the form, but putting it on the form element itself seems to do the trick.↩
3. Of course, the filename will need to be updated to something suitable and the form content needs to be filled in!↩

I was working with a babashka file which spits out an HTML file when I evaluate it and since babashka can also easily run shell commands, I figured I could just add these two lines at the bottom of my nrepl-connected script:

(defonce browser-window
  (:out (shell/sh "xdotool" "selectwindow")))
(shell/sh "xdotool" "key" "--window" browser-window "F5")

The first time it's evaluated, I can use the mouse to select the desired window and from then on that window will be reloaded every time I evaluate the file. There's a bit of a limitation in that it doesn't care what the current browser tab is, it just triggers whatever is currently selected, but it's good enough for my purposes.

Job done! Well, not quite.

Of course this doesn't automate the reload when tweaking the CSS file. And it would be nice to have that functionality when working on this site. Really, I need a file watcher, and happily there's a babashka pod for file watching¹. Hooking it up is straightforward, but when there's dozens or even hundreds of file changes, it gets a bit manic, so I hacked up together a debouncer using a cancellable future in an atom ²:

(def reload-op (atom nil))
(defn trigger-reload []
  (let [[old _] (reset-vals! reload-op (future (Thread/sleep 20) (reload)))]
    (when old (future-cancel old))))

I also used the same mechanism to implement a watch command for this site which triggers a re-render whenever a file changes. Combined with the browser reload script watching the output folder, it makes for a nice workflow.

The full script is available as a gist and requires babashka and xdotool to be installed. I ended up also making a macOS version that makes use of AppleScript to trigger the reload instead. If you're reading this, I hope you find it useful.

1. Well, there's two.↩
2. I got some advice on how to improve it from the clojurians slack, some of which I even applied, though I can't apply it all now because of a current limitation in babashka. I did learn about reset-vals! which is better than accessing the atom to cancel it and then calling reset!. Some also suggested an approach using core.async which sounds cool but maybe overkill for this particular hack.↩

I replaced a perfectly fine static-site generator with a custom one. I had been wanting to make some modifications to my site and whilst it was absolutely possible to do so previously, I never felt particularly inclined to do it. I don't love writing HTML, even less so writing django-style templates. I much prefer working with something like hiccup. I guess I'm easily influenced because a blog post by an author I've never come across before planted the seed.

I was always going to stick with Clojure and had been intending to look into Babashka, a subset of Clojure with precompiled built-in libraries intended for scripting. I recently saw that Michiel Borkent, the author of Babashka, had used it to replace his previous Octopress blog. I thought I'd see if I could do something similar, keeping open the option of switching back to Clojure if things didn't work out.

Babashka comes with a bunch of useful libraries built-in, but it doesn't include any markdown parsing. It does provide a mechanism for other utilities to expose their functionality as Clojure namespaces. I initially attempted to use one called bootleg. Whilst it uses the same markdown parser my site was using, it didn't expose the footnotes option that my existing posts rely on. I opened a PR addressing the issue, but the library isn't actively maintained and I'm still not sure if or when I'll get a reply ¹.

Raising the issue, however, prompted Michiel to wonder whether Babashka could run markdown-clj directly from source. Amazingly, although there were a couple of minor issues stopping it from working initially, within less than day he had fixed the issues, got them merged in upstream and had written all about it! I now had all the tools I needed to recreate my site.

The Outcome

At the time of writing, the code for the site now consists of:

• ~170 lines parsing and rendering code
• ~170 lines hiccup templates
• ~50 lines RSS feed template
• ~70 lines local development server to preview the site
• ~20 lines babashka project and tasks definitions
• 4 lines bash script to get Netlify to install babashka and build the site

I replicated the layout and design of my site almost exactly. I kept the same CSS files and the hiccup templates are equivalent to the original ones. I used my new found custom-code-freedom to make a new home page, rather than just display the latest post as it previously did. My intention is to now expand on this and find better ways to share some of my work than just via blog posts.

1. This isn't a complaint or a criticism - I don't think we're owed anything from free software maintainers, especially so when they're small one-person projects they created to scratch their own itch.↩

This is it, the end of my thirty-five day challenge. I didn't really know where it would take me, but about halfway through I decided I to aim for a single program that would capture, and ultimately help me explore, some of the ideas and decisions I'd been playing with at the start. Getting a balance between surprise and interest across outputs while maintaining some degree of consistent quality is not something I'd achieved before.

To put this to the test, I generated 100 images and selected 35 which you can see below - you can click on them to see a larger version. I think it showcases the range but also the consistency of the output. More importantly, by doing this for thirty-five days, I've pushed myself to explore ideas more widely and deeply, and share my process and work in public.

As planned, I added a few restrictions to the code so that a few particular combinations of parameters that consistently lead to bad outputs now simply can't happen. With one more day to go to complete my challenge, the process is very much one of curation, but unlike nine days ago, the number of interesting outputs is much higher and and I'm able to refine them a bit if required (though I haven't felt the need to do so for a few days now).

I've refined, biased and restricted the colour code so that it mostly generates a pleasing colour scheme with a somewhat consistent style, whilst also keeping a good degree of variation.

I've started to identify combinations of features that tend to lead disappointing results and I'm hoping to spend some time tomorrow putting a few more restrictions to stop these from happening. I'm actually fairly hopeful that I might end the challenge on Monday with a program that somewhat reliably outputs interesting results.

I've been exploring the kind of colour palettes I can generate dynamically using a technique I came across yesterday. Although it's still difficult to get varied but consistently attractive palettes, it is indeed a good way to get exposed to a wide range of options. I can select either a colour palette or the composition that I like and then continue exploring possibilities from there. Today's piece however, came out of the code fully formed.

I did a couple of minor tweaks (multiple colours within the large shapes and drawing them over the rest rather than behind) and I coerced some of the parameters to refine the output, but otherwise it's the same program as the last few days. Overall, I'm happy with the variety I'm getting out of this code and I feel I have mostly achieved what I set out to do when I re-evaluated my goal halfway through the project. The quality of the output isn't as consistent as I thought I'd get to, but in return I get more variety and surprises.

This is going to be the last piece in the series with the bubblegum colour palette, though I am still loving it! With four days to go, I've decided to revisit my conclusion that generating a colour palette isn't realistic. I've come across a promising technique that seems to allow for the creation of consistently workable palettes. At the very least it may be a good tool for discovery.

I added one small tweak to the algorithm that has opened up new interesting variations and that enabled today's piece. I'm enjoying the bubblegum aesthetic of yesterday and so have kept the colour scheme, adjusting it slightly.

Different day, different colours. This is a colour palette I actually stumbled upon yesterday when trying to find a generic way of creating a pleasing palette - probably not one I would have initially aimed for but it has caught my attention.

It's not exactly a newfound revelation that using colour well is difficult, perhaps even more so in generative works. I've been playing around with alternative colour spaces in the hope, perhaps rather naively, of being able to find operations that consistently generate great combinations from a base randomly selected colour. It hasn't been going particularly well! Today's colours were the outcome of manual trial and error.

Whilst a little bit of randomness for small colour variations can add texture and depth and the exact location of each colour can be left to the whims of the algorithm, I think I'm ready to accept that selecting the colour palette of a piece is something I'll need to do the old fashion way and continue working at.

I spent today trying out different ways of picking colours programatically, with mixed results. The piece I chose today has a nice tone but also the composition turned out better than most.

After generating a few drawings, I picked the most interesting one and tweaked the code to refine one of the aspects of the piece - namely, the circles at the top of the piece are now of varied size and warped to not be perfect circle, giving it a more organic and balanced feel.

Depending on the structure of the program, refining a particular aspect of a piece can be tricky as there are so many random elements. Changing in which order those random decisions are made can completely change the piece. Over the last couple of days I've purposefully rearranged the code so that decisions that affect the overall composition happen before decisions that affect the details, making it more likely I can target just the part of the program I want to modify without completely altering the result.

My process today has consisted mostly of generating a bunch of pieces and choosing my favourite - one that feels more like curation than creation at this point. Whilst the range of outputs is now quite varied, it's also incredibly inconsistent and difficult to refine when something interesting pops up. I think it's a constant tension with generative art.

I see a couple of directions to take for the remaining 10 days this project. Now that I can capture some of the high level parameters that led to a particular drawing, I could either try and figure out what combinations tend to lead to better outcomes and make these more likely, or I could use it as a way to freeze a particular combination to then refine until I'm satisfied.

Of course another possibility is to try and incorporate colour again, which feels rather daunting when there's already so many variables. Let' see where tomorrow takes me.

Today's output is from essentially unchanged code - at least none of the possible outcomes have changed, no new feature and no tweaking of the parameters.

What I have started to do is centralise some of they key decision points into a structure that I then use throughout the code. This will help me make sense of which properties are the most impactful and what combinations of parameters create the most interesting outputs.

Today, some minor refinements to the code, this time to expand the range of possible values and combinations.

Today brings in another of the main elements used during the first half of the project - the horizontal wavy lines. Depending on how they are cropped, to the inside or outside of the various shapes, they play a very different part in the composition. Their addition opens up the range of possible outputs, and with it the potential for surprise, even more.

Some minor tweaks to the code today, trying to reign in the possibilities just a bit to get a higher proportion of results I like. The output I chose is much more minimal than most in this series but has a lovely feel to it and fits nicely with the type of plotter art I generally like to make. I feel like I'm at another crossroad between looking to bring in more colours and layered textures, or continue expanding on the possibilities within the constraint of line drawings.

I spent some time profiling and optimising my code again today, with some really great improvements, making continued development much smoother.

I brought in another key feature used throughout the series - the flow lines. There's multiple ways the starting points are selected and the length can vary quite a lot. I've also added the possibility of sub-dividing the small circles into groups so that they are treated differently.

I'm already getting a lot of interesting variation in the output, which is making it harder to choose one for the day - a nice problem to have. I've selected this one in part because it showcases some of the new possible features.

Today I gave the code the option of warping the circles and/or replacing the circle with parallel lines. The large and small circles are treated separately, with the inclusion of the large circles being randomised. I'm already getting quite a bit of variation - some good, some bad, some surprising. My choice for today neatly showcases some of the new possibilities.

The last few days have been a struggle, and as I pass the halfway point it is time for some reflection. I've shown to myself that I can produce something every day. I've been able to both refine an idea and take leaps to explore alternatives, and have found that the most interesting result don't always come when I'm feeling inspired. And crucially I've posted something online each day, even on days I've been disappointed with my efforts.

One thing I've been missing is that I'm rarely surprised by the output of my code - I've been trying to coerce something "good" out of it every day, reducing the variance too much. Part of the reason for this is that pure randomness is easy to implement, but the output rarely pleasing or interesting to look at, particularly when it comes to the overall composition of piece (it can still be quite useful for detail and texture).

I've decided to take the "same evolving codebase" of my original plan more literally. I've looked back at what I've created so far and I want to increase the variance between each run of the program, but bake in some of the kinds of decisions I've been making.

Today I went back to basics and started with placing circles, which all the pieces have relied on in some way. There's between 1 and 4 large circles, which can then influence the placement of the smaller circles (or not). The smaller circles themselves can be spread evenly or layered as first introduced in day four. For today's piece I then decided to only draw the small circles, using the large one as negative space.

I plan to build on this for the rest of the challenge, incorporating some elements from the first half as possibilities for the program to select. My hope is that by the end I have a single program that generates a variety of consistently pleasing and/or interesting outputs.

I got today's output within 15 minutes of starting then spent over an hour trying different variations, only to return to this one. Even though it is using essentially the same background as yesterday's, it has a very different feel.

I took the perpendicular lines from yesterday's and did something a bit different with them, looking for a more flowing feel. The key change at the end was to dramatically increase the number of lines and reduce the opacity - a trick which I find can be quite effective at generating pleasing textures¹, but for some reason often feels like cheating. I think it's because a lot of my work is intended to be plotted, limiting me mostly to solid lines², a restriction I'm not bound to for this project.

1. The background uses a similar technique, as so do many of the previous pieces in the series.↩
2. Though depending on the pen used, some interesting layering effects can be achieved.↩

I started playing with the colours of yesterday's piece, and although I liked some of the results, it didn't feel like much of a step forward, so I tried to play with the composition of the piece. I don't think I really know how I feel about it yet, but it should offer me a different avenue for exploration tomorrow.

I started off tonight feeling completely uninspired and aimless - without the challenge in place I would have not produced anything today. And yet I've managed to create what might be my favourite of the series so far. Once again I've reused many of the elements from previous pieces but reworked and combined them in different ways. Many of the previous days have evoked the physical world - clouds, flowers, stars, planets - but to me today's piece doesn't do any of that, it stands on its own.

Today is a refinement of yesterday's piece, improving the composition (but still without fully specifying the various elements' location) and changing the background colors.

I haven't generally worried about the performance of my code as I produce mostly static images, but I've been getting frustrated by just how long it can take to render some drawings. I went digging into my library's circle packing code, which I've been making heavy use of. I found some rather naive things I'd done that I've started to optimise, with some already significant improvements. I just need to resist the temptation to spend too long tinkering and focus on the art!

I combined most aspects of day eight with the patterns of days nine and ten to create something that feels a bit like outer space (which kind of fits with yesterday's rushed effort). I also tried to add a few more colours, which is not something I'm yet comfortable with - most of my previous work has been in black and white.

In previous days I applied a lot of constraints to the placement of the main elements, going as far as just specifying their location. Today I decided to leave it to randomness (within the constraints of the circle packing algorithm) and it's been quite frustrating. So far I've found that manually specifying the overall composition whilst using randomness for the detail to be the most successful approach, with the caveat that any particular result is very rarely surprising.

This daily challenge is really putting my latest workflow to the test and I'm rather happy with it. I'm able to freely modify my code without fear of losing track of a good idea and can easily revisit previous versions and pull out specific aspects I want to incorporate.

Life gets in the way! I spent this evening playing Mothership, a horror-in-space tabletop RPG that involved spooky floating hair and emergency lighting, so I hacked at my code whilst playing and tried to channel that. Not my most thought-through piece, but something a bit different again using similar techniques.

Not a lot of time today, but combining aspects of day 9 and day 7 to get something out - this challenge is all about that consistency of output and removing the fear of sharing my work. So here's to double digits, and another 25 days.

A bit of a reset today, starting with a different way of utilising a flow field by warping a series of horizontal lines along the y axis. A few of the pieces in this challenge have evoked the sky and I leaned into this theme with the circle crop when the colour gradient reminded me of a setting sun.

This is actually very similar code to yesterday's piece, exactly the same structure but with some different values for a variety of parameters. Even though I'm not entirely happy with today's piece, this is one of the things I love about generative art - how quickly you can explore quite a wide possibility space.

Today's is a refinement of day 5, focusing on the light and texture of the background.

Some further exploration of the blossoms vibes from yesterday, finding new ways to combine the circle packing, flow fields and layering techniques that all the pieces have used so far.

Today was a tricky day. The smaller shapes in yesterday's piece reminded me of leaves so I started to explore this idea of falling leaves, which turned into falling blossoms. I like the sense of movement but have been feeling like something is missing and I've run out of time for today.

Today, experimenting with colours and leaning even more into the variable circle packing for placing the various shapes throughout the canvas. As with yesterday's drawing, a few of the larger shapes' locations are hard-coded (though the actual shape is dictated by the flow field) - a trade-off between the ability for the code to surprise me and my ability to consciously shape the output.

I kept yesterday's idea of having two variations, tried to give the overall piece more structure by doing multiple passes of circle packing, and cranked up the noisiness of the flow field. I'm quite happy with some of the detail and the overall texture of the piece.

After a few false starts this evening, I revisited one of the outputs from a few days ago, but decided to only apply the shorter flow lines to the three largest circles and only warp the rest. That separation gives the piece a certain structure that my work often lacks.

After the long Easter weekend and another day off ahead of me, I was feeling rather at peace this morning and so for day one of my challenge I channelled the beautiful skies outside my window.

I'd been feeling the pressure of doing something "good" from the start, so I started developing the code a couple of days ago. I combined a couple of common generative art techniques which I've experimented with before - circle packing and flow fields - using points around the circles as launch point for flow lines. I didn't really have a sense of what I wanted to achieve but enjoyed tweaking various parameters to get quite varied results.

I took things in a different direction today, making use of much longer, semi-transparent white lines over a blue background and warping the circles so that they blend into the overall shape. The result feels like a cohesive whole with a satisfying sense of movement.

When it comes to personal projects, I've often struggled with consistency and taking things through to completion. For that reason, it felt like a huge achievement when I released my game at the end of last year. I kept the scope small and didn't let perfect get in the way of done; it's out and has found a small set of players with whom it has resonated.

When it comes to creating generative art, I often hit what feels like a local maximum with an idea and struggle to either fully refine it or explore another direction altogether, leaving the work in a sort of limbo state where I neither see it as complete and worth sharing, nor ripe for further exploration.

I'm going to try something to change that. Tomorrow I am turning 35 years old. I intend to post one piece a day for 35 days, all from the same evolving codebase. I'm not putting any other restrictions on myself - the goal is simply quantity and consistency. Let's see where it takes me.

Context

I've been making generative artwork in Clojure using Quil for just over 2 years now. Over time I've evolved a workflow that enables me to experiment quickly whilst reducing the risk of losing interesting results and avenues for exploration.

Most of the artwork I make is static images, usually with the intention of plotting them using an AxiDraw. I usually export images as both png for previewing (and sometimes printing) and svg for plotting. I am also gradually developing a small library with a focus on manipulating shapes and lines.

I work in Emacs connected to a repl using CIDER, which means that evaluating the current buffer generates a new sketch.

It's often useful to be able to reproduce a particular output, and the way I've been approaching this is to replace Clojure's random functions with an implementation where the seed can be set, as well as setting the seed for Quil's own random and noise functions.

I'd been exporting images with the random seed in the filename for a while, but as I tend to continually tweak the code, it often isn't enough to recreate that exact output. I wanted a simple way to save the state of the source code as well.

Solution

So far I've settled on something like this¹:

(ns sketch
  (:require
	[quil.core :as q]
	[clojure.java.io :as io]
	[random-seed.core :refer :all])
  (:refer-clojure :exclude
	[rand rand-int rand-nth shuffle]))
  
...

(defn export []
  (let [name (str sketch-name "-" seed)
        src (:file (meta #'export))
        dest (str "output/code/" name ".clj")
        png (str "output/png/" name ".png")
        svg (str "output/svg/" name ".svg")
        gr (q/create-graphics
		(q/width) (q/height) :svg svg)]
    ;; Save source
    (io/make-parents dest)
    (io/copy (io/file src) (io/file dest))
    ;; Save png
    (set-random-seed! seed)
    (draw)
    (q/save png)
    ;; Save svg
    (set-random-seed! seed)
    (q/with-graphics gr
      (draw)
      (.dispose gr)))
  (q/exit))

Exporting a sketch, including copying the source, now means replacing the draw function in the sketch with this export function, without the need for extra infrastructure and setup. It does require that a) there is a single file we want to save a snapshot of and b) the export function is within that file (as it uses the metadata of the export function itself) - but that suits me well at this point.

1. I initially worked with Quil's functional-mode middleware (because Clojure), but moved away from it as I do all the rendering in a single draw call anyway.↩

The Wallslider is my attempt at the kind of mobile game I've loved the most. Difficult but fair, short repeatable play sessions, bonus points if playable with one hand so I can hold on when on a moving train. Something that seems impossible at first but can be mastered over time. Something from an age before "free-to-play" and endless micro transactions.

It's essentially an endless runner except rather than just reacting to obstacles, you propel yourself upwards and will slide back if you stop, so it requires more constant input but it also maybe requires a bit more deliberation and planning than just pure reactions.

A couple of friends' first reactions were "it's the next Flappy Birds", which is flattering despite my reservations about that game. I understand, it has that endless tapping energy, but I like to think The Wallslider is a bit more subtle than that. You've got control over your jump height, your sliding speed and a grappling-hook you can bail out, all by varying the rhythm and length of your presses. Also Flappy Bird was free, early and made people feel that Nintendo warmth, so I'm not exactly expecting that kind of cultural relevance.

Other things people have said include "it's a really fun game" and "I hate you", and one friend got so good at it he obliterated my high scores throughout the beta, all of which makes me feel warm and fuzzy and like I've achieved my goal.

Another common reaction is "I love the music", and if that's yours, I'm right there with you! I knew my colleague Adam had done some chip tunes so I asked him about his music, but when I heard his track Sentry, I was blown away. It feels to me now like it was written especially for The Wallslider, though it predates it by 7 years. I'm so grateful he let me use it.

My favourite games in this space include Canabalt, Alone and the masterpiece that is Super Hexagon. All of them have a strong identity, great gameplay and awesome sound and music. If you like them too and you enjoy a retro aesthetic paired with some 8-bit inspired drum and bass, I like to think you'll get something out of The Wallslider.

A budding generative artist will, sooner or later, play with vector fields¹.

Tyler Hobbs, one of my favourite generative artists, recently wrote a good introduction that prompted me to make that time be now. All the images in this post are created using roughly the same program based on a field populated with perlin/simplex noise and tweaking a dozen or so parameters.

By restricting the starting point of the flow lines and letting them run long in a chaotic flow field we get structured yet dynamic images:

Maintaining the high step-size through the noise field but ensuring the field still flows in roughly one direction leads to long lines quickly converging into the main paths through the field. Combine with highly saturated colors for some 80s sci-fi vibes:

Swap for filled shapes defined by short lines for some winding vine-like effects:

Extend the length of the lines defining some heavily layered shapes for some dynamic dreamscapes:

Pairing flow lines at random and layering resulting shapes can create some interesting texture with a sense of light peering through, almost like stained glass, though here using random short lines and pairing them may achieve a similar effect more simply:

Different combinations of layered semi-transparent shapes from grouping multiple flow-lines create interesting watercolor paint-like effects:

Lots more to explore, but some exciting and varied initial results from a fairly straightforward system.

1. Also, apparently start with black and white images and eventually "discover colors" then talk or write about how hard it is to use well. Which, considering some of the choices made here, is a fair point.↩

Unable or unwilling to commit to Javascript based tools, struggling to focus on learning Clojure without an obvious goal in mind, I eventually came across Quil¹ and realised I could work towards two goals at once. It's turned out to be an incredibly rewarding and somewhat successful endeavour. Below are a few of the things I've made this year.

I first started with laying out grids of shape and playing around with scaling and rotating such repeated shapes, which made for some quite attractive birthday cards.

One of the first times I went from idea to execution in the space of an evening, I created this drawing inspired by the inkblot patterns on my wife's wedding dress.

At one point, just throwing random curves at the canvas, I found myself creating images that I couldn't plot because I'd accidentally kept the fill color. I played around with converting the bitmap output to vectors and playing with Inkscape's tools and got some fairly interesting results quite far from the original, though I don't see myself going down this manual route again any time soon.

I played around with growing a drawing using perpendicular offshoots off existing lines, an idea I might go back to once I can get over the fact it's already been done to near perfection.

I'd been wanting the option to fill shapes or crop a drawing to a shape and finally did it to produce this. I have begun growing a small library for those kinds of operations.

Although not generative, it was fun to come up with an idea for my brother's Christmas gift and have the tools and the skills to be able to produce it.

1. Tyler Hobb's talk at Clojure/conj is worth a watch.↩

1. defines a shape by generating a random set of lines within a small grid
2. repeats that shape in a larger grid, randomly varying its scale and rotation

The grids and repetition create a pleasing sense of regularity whilst the randomness leaves just enough room for some surprises. I find myself looking for extra patterns, even in the aspects I know to be random.

Every time you load this page you'll get a different image below:

(It may take a while to load because it's on a free heroku instance and spins down after 30min of inactivity)

XML Generation

Having deployed this site for the first time, I pointed my RSS reader to my new feed and then... saw an empty title. Looking at the raw feed revealed a potential cause: lots of new lines, including before the content of the tags. Digging through the code lead me to clj-rss, which in turn relies on Clojure's own clojure.xml. So why the issue?

The great thing about Clojure being open source, is you can look at it¹. Looking at emit reveals what can only have been intended as a debugging helper - it uses print rather than returning a string or writing to a file. It does none of what would be required for proper xml support like escaping strings. It also adds new lines everywhere (via println), including in tags containing text. There's our issue! It's changing the content of the tag: it now starts and ends with an extra new line.

There's better alternatives, of course, most notably data.xml², but I'm confused as to why something like emit would ship in Clojure's core libraries. It might be that using access-control is less typical in Clojure code and doc strings are what's primarily used to communicate intent. Regardless, my proposed change to using data.xml in Cryogen was promptly accepted, deployed and bubbled up through to Cryogen itself.

Markdown Parsing

Like with many static site generators, posts for this site are written in Markdown. You may have already noticed I enjoy peppering my writing with plenty of links and asides via footnotes³. A previous draft of a similar post quickly put markdown-clj through its paces and surfaced issues with multiple types of links in the same paragraph.

Not much to expand upon here, but it was a useful exercise in figuring out somebody else's Clojure code and another opportunity to contribute back. It has also raised some questions in my mind around Clojure and testing. Part of the language's appeal for me has been its underlying philosophy and it's going to be interesting to see which parts continue to resonate.

Future Contributions

My interactions with the maintainers of Cryogen and its dependencies have been a delight so far, and so I've decided to take on one of the previously raised issues. Fixing and expanding a static site generator is not exactly what I'd planned to spend these couple of weeks on, but it's been both educational and rewarding.

1. As an iOS developer, being able to look at source code is still a relative novelty.↩
2. It is at version 0.2.0-alpha6 at the time of writing, but seems stable enough. I'm under the impression Clojure libs have a tendency to stay sub 1.0 for a long time.↩
3. I've never had an idea I couldn't expand on or wander away from.↩

About me

I'm an iOS developer by day, so I'd expect some related topics. I've been toying with Clojure for a little while now. I use Quil to generate line drawings for a pen plotter. Through Clojure I started using Emacs which has kind of become a hobby in itself. I'm also quite into games, board and video. I sometimes play around making them in Lua using LÖVE or PICO-8.

This site

This site is generated using Cryogen, a nifty static site generator written in Clojure. It ships as a Leiningen template, so it was easy to get started. I didn't use Jekyll or Hugo or something else you've heard of because I'm a hipster, and it's more likely I'll tinker with it.

The template for the site is lovingly hand-crafted by me in a minimalist style. That's to say, I created an empty folder and added files until Cryogen stopped giving me errors. I copied over bits of the existing templates until the content I wanted appeared, then added just enough CSS to make my eyes stop hurting. It's unlikely to work with a different config.