Returning to


While writing about privacy, I found myself thinking about user support. Having a support database is pretty common, and I wasn’t super thrilled about creating one on FreshDesk. For one it’s yet another series of accounts, validations, and pages I would have to manage. Bringing people in to help would be a pain. It would be better if we could build a support database using something we already use.

I eventually realized a support database is just a static website, like this blog. Hey! Zola would be perfect for building a support database! Not only does it display content, but once the data is on GitHub, ANYONE can contribute! Now that’s more like it.

Okay, lets create a support website. Where does it go? What’s the URL?

Right now the FreshDesk support portal is on It’s a CNAME alias to the actual support website on FreshDesk. It’s not actually something we own.

Okay, we could replace with a Zola website. Cool.

What goes on the website? What are our frequently asked questions?

Ah… right… rules questions.

Okay, we could move the rules page to Side benefit: users could contribute fixes to the rules page. Awesome!

But, should Ludum Dare’s rules be buried on a support website? For that matter, should frequently asked questions? and

The reason we use for events is because at the time I couldn’t figure out a nice way to make the two websites coexist on the same domain. Frankly the legacy website shouldn’t exist, but until that data is migrated it needs to be there. today is a bit of a hack. It’s two websites, a simple static website built with Zola, and the decrepit remains of the WordPress blog at Until yesterday I didn’t even have the websites configured correctly ( wasn’t browsable).

As things are today, I don’t like how works. In essence it’s the legacy server running and hosting That’s fine since the legacy website isn’t being used, but I need to reboot and maintain that machine more often then I’d like. The last thing I want is broken WordPress to cripple, especially since static websites are prime candidates to be hosted on CDN edge nodes. No computations required. Just raw files flowing, sitting in caches for optimal performance.

My personal goal is to be free of before the end of the year. That means me and employee—whomever you are—we figure out how and what to extract from WordPress, import it, and finally sunset the /compo website by next April’s event.

So alright. If the /compo website is finally going away, we can start talking about overhauling all URL’s.

Today’s is the homepage. We’ve never done much with our homepages, we ran and instead. We should though. I threw together the homepage you see today basically to make sponsors happy. They didn’t exactly require it, but I thought it was important to have one. We seem more professional this way.

What should do is get you excited while quickly explain what we are, show you what you need to do, and where you need to go. Currently there’s a banner, a schedule, and a log of previous news posts.

It can be better.

I want a feed of commercialized Ludum Dare games on the homepage, just like we have with the (ahem) neglected Steam Curator page. Why? Because it’s cool! And because our source is on GitHub, users could contribute games to the list with a pull request. If done correctly, that’s a one click approval for me (merge). Easy!

If we move the rules to, not only is that URL sensible, it means anyone can contribute to the rules page. If we need a clarification, if I made a typo, whatever the case. And again, if done correctly, it’s a one click approval from me (merge). No need to write me an email explaining the problem, you can just fix it.

(Note to self: consider adding some styles to the page that link directly to their sources on github, to make it more obvious anyone can edit)

Finally if we setup and to recommend searching the faq, we can have a not shit way to find answers to questions, before final escalation to me. And same deal, it being on GitHub means anyone can contribute frequently asked questions as issues, or answers as pull requests.

And hooray, Ludum Dare support will suck less.

The event database

I’ll think of a better name for it later, but once the rules are extracted from, we can start thinking about the code and database ase their own entities. Obviously the database is useless without the code, but there’s a lot we cram into the experience of

My intention was to build a general game jamming website and database, but I didn’t have the resources or experience to pull it off. was going to be the “Ludum Dare” version of the data, while would be the general view. I have legacy data from not only previous Ludum Dare events, but several other jams that came and went. It’s a shame seeing things disappear without a trace, and I wanted our efforts to help preserve, like a Mobygames of jamming.

I’ve also had numerous companies approach me about running events on their behalf. If we could unify the data, let anyone with an existing account just use it, that would make those events more appealing to everyone.

As I went back and forth trying to decide how to structure everything, especially once we’ve migrated the old data, I’ve come to the conclusion that’s days are numbered.

For the sake of not breaking the internet, the domain will still exist. We’ll need a thing for as well, but soon they will exist solely to make old links point to their new home. I haven’t decided how to do this, but I have been fond of static websites lately.

A sensible way to structure things would be to put the static stuff on, and then make the event website a subdomain:

This is the goal.

Not this year, but in 2023 I would like to see us running events on, finally sun-setting after 7 years.