So you want to make a blog...

“Make a blog, they said… It will be easy, they said…" – Nobody

This blog is about everything Terra Diem but this post is not really about the game. This certainly was not my plan for a first post. However, this was where I spent my time over the last week and a half for the game, and it turned out to be quite a journey. I’ll go more into what the game is about in a future post. This post is about the trials and tribulations of getting this blog off the ground.

Why make this blog?

I’ve never been one to put myself “out there”. For one, I never felt I really had anything interesting to say, nor did I have unique insights or experience that wasn’t already better represented elsewhere. The internet is a vast place, and there is always someone doing a better version of whatever you think you’re good at. Looking around the internet, this clearly doesn’t stop a lot of people, but it definitely stopped me.

What changed? Well, a few things…

  • I’ve been working on this game on and off (really just a tech playground up to this point) for about the last year and a half. I realized earlier this month that I really wanted to make a go of it. I wanted to actually self-publish an indie game of my own making.

  • As I read more about how to go about this, one thing became crystal clear. Making an indie game that gets any visibility at all requires building an audience up front. You just can’t do that without putting yourself out there. Every game, and especially an indie game, has a story – and people want to know and connect with that story.

  • Friends and collegues were quite interested in the project and wanted to follow along. Many of them are not game developers, and they are interested in how a game gets made. There were at least some people who wanted to read what I had to say, and that’s enough.

  • I let go of the anxiety about doing things “the best way” or being derivative. There definitely is a much better way to do things (for one, I do not recommend building a game engine from scratch). And in all honesty, Terra Diem is not breaking new ground in tech or design. It is just something I want to make and play.

  • Finally, putting a blog out there is motivation for me to finish and publish this game. You, dear reader, are a big reason for me to keep designing, programming, and writing about this game!

Editing and hosting

Whenever I start a hobby project, I nearly always spend the effort to reserve the appropriate domain names for the project. Terra Diem was no different, and I already had terradiem.dev, terradiem.com, etc. I use Google Domains to manage nearly all my domains. Why Google Domains? For a very long time, I’ve been a heavy user of Google products, and when I actually started working there as a software engineer, this tendency only increased. This reduces my own cognitive load as well as getting useful experience with my employer’s stuff.

I am not a web developer. I’ve had some sporadic experience here and there over my career, but mainly I tend to spend my time at the other end of the spectrum (C++ libraries, game engines, tools, etc.) I absolutely did not want to spend time and effort maintaining the guts of a blog or mucking about in HTML and CSS. I want to focus on the content and style and let the software do the work.

WordPress

Google Domains has this handy “Build a new website” section for your domain, and that seemed like the obvious place to go. After all, the options presented were selected by Google and the integration should be trivial. The options it gave me were:

I immediately rejected everything but Squarespace and WordPress as it either was not what I was trying to make (Shopify), or from the description seemed too minimal or simplistic. I don’t want to be forced into nuts and bolts, but I do want the capability to dig in if desired.

Reading up on the two, it seemed WordPress had more flexibility and although it was perhaps a bit more of a learning curve than Squarespace, I was ok with that. So I created an account with bluehost.com, linked everything up and went to work.

To be fair, getting the site up was indeed trivial. However, it was also quite unpleasant to work in. The interface was super clunky and slow. For example, the page edting wasn’t WYSIWYG but it seemed it was trying to be. This resulted in some truly mismatched features like using the page text’s font color but not using the page’s background color. I was experimenting with a dark theme, and that made all the text in the editor practically invisible (off-white on white).

I’m reasonably sure a workflow could be resolved with WordPress, but clearly this was going to be spending time and effort precisely where I didn’t want to spend my time. This was going to be a problem.

Hugo

When I showed that first site to a very good friend and complained about the user interface issues, he told me about static website generators.

The concept here is you create a bunch of static content (generally in Markdown), and you use the static site generator to process this and generate HTML. Then you can just upload it to any hosting platform you like (like the “Static hosting powered by Firebase” option I had carelessly rejected earlier). What this means in practice, is that every user visiting your website will see the same thing (instead of something like Twitter where every user sees something different). This is kind of perfect for a blog. All visitors are the same and see the same things.

Even better for me, I could host and automate publishing the blog on GitHub with GitHub Pages (https://pages.github.com/), which also happens to be free (although I chose to host from a private repository, which does cost money).

There are lots and lots of static site generators out there, but I went with Hugo (https://gohugo.io/) as it is really fast, has a live local preview, very flexible, and has good templating, layout, and theme support.

Publishing to my domain

I quickly got a site up and running via the excellent Hugo Quick Start and Host on GitHub guides. However, getting my custom https://www.terradiem.dev domain hooked up (instead of https://jpursey.github.io/terradiem-dev/ – which now just redirects) took a bit of fiddling.

As part of the flow, the GitHub instructions state to “Navigate to your DNS provider and create a CNAME record…”. Well, this didn’t work. When using Google Domains you have to create DNS records for both the CNAME (aka www.terradiem.dev) and the apex domain (aka terradiem.dev – no “www”) for anything to work. Redirecting the apex domain requires the IPv4 (and optionally IPv6) addresses for GitHub (found in this section of GitHub’s docs). Once configured in Google Domains, it looks like this:

After this, the rest of the steps in GitHub worked as advertised. The only caveat being that actually accessing the blog via the apex domain didn’t work until the next day. It just takes time for DNS changes to propagate.

Blogging with style

One of the things that attracted me to Hugo was the large set of themes available for free. In theory, these make life very easy as you can let the theme organize and style the website, and all you need to do is make the content in the exceedingly more friendly markdown format. After looking through a bunch of themes, I ended up going with the Ananke Gohugo Theme, which is used in the quickstart guide.

The blog looked really great already, but the font seemed too big, and I didn’t like all my text being centered in a very narrow column. These must be tweakable parameters… I just need to configure the theme, right?

Not quite.

It is exceedingly theme-specific what can be tweaked and what can’t. Hugo provides both site parameters and page parameters which a theme can choose to read in its layouts. In the case of the Ananke theme, you can set the parameters body_classes and post_content_classes which should be able to tweak the font and any other CSS you want for page content. However, other than the font and color, it was not possible to override other stlyes like alignment and justification. After a lot of fiddling, I ended up forking the theme and adding a bunch more overrides to the layout (for the details, see the change here).

I can also change anything locally in my site without needing to edit the theme itself. All of the theme files are just Hugo files placed in a themes folder, and you can override anything just by putting a file with the same relative path in the site’s root folder. I’ve done this now for a few things, as the built-in custom CSS support the theme provides doesn’t seem to work. This just required copying the theme’s site-style.html file and making local edits to include my own CSS file.

Feedback and subscriptions

Ok, so everything looked great and I had a nice looking blog hosted on my own domain. Yay! But something was nagging at me… I wanted a way to interact with my thousands of readers (gotta be optimistic!). What if they have comments or suggestions? How do I know I even have readers? Taking time out of someone’s day to specifically go to some blog just in case there is content also seems unhelpful.

And thus was born the Contact page.

Adding a feedback form

Adding a feedback form was actually quite simple. There are a lot of options here, and I somewhat arbitrarily went with Formspree. It is completely free with less than 50 form submissions a month, and is an incredibly lightweight integration that doesn’t require cookies or other user tracking (which I really wanted to avoid). It also has some nice features like reCAPTCHA (which I don’t use yet), and automatic spam filtering.

All that is required is to set up the form on Formspree, and have it send the submissions to your email. To put the form on a website, just embed some trivial HTML (which Formspree generates) into the site somewhere. There are no external scripts, it is just a simple form with a POST action.

Form responses are retained in Formspree for 30 days as well being forwarded to your email. This is within the time period of privacy deletion requirements – although I can and would delete them myself as well on any request.

To use in Hugo, I put the form into a “shortcode”. Shortcodes are basically little parameterized HTML snippets you can drop into your markdown where you want.

Creating a mailing list

To create a mailing list, I went with one of the the biggest players in automated email, Mailchimp. The main reasons being that it definitely has everything I need (actually way way more), and also has a completely free tier. It recently was bought by Intuit, so things could change, but it is a solid choice for now.

Using Mailchimp was (and is) a bit of a bumpy experience however. They made some very unusual and non-standard user interface choices. Everything seems really easy to use, but they tend to hide really critical bits of configuration in random places.

I also found it was very hard to not track things about subscribers. Clearly, I need to store and use email addresses, but Mailchimp tracks pretty much all interactions with the site and emails and gives me reports and such. This is because it really is focused on being a business marketing tool (and pretty much every Mailchimp competitor is as well). I considered hobbling something together with Formspree and a database of some sort myself, but this is very dangerous territory (see Privacy laws below).

One thing I was surprised to learn was that Mailchimp can detect when subscribers open their mail. This is of course very useful information to have (for good or evil), but it is now something I am hyper aware of for all the marketing emails I get. The way this works is they embed a per-email invisible image link in the HTML body of the email. When the email is renderered for the first time, the image is fetched from their servers which counts the email as being opened by the email recipient. This doesn’t always work, both counting false opens and missing opens depending on the email client or if the user does something like forward the email to someone else. The way to defeat this as a subscriber is to request “text” instead of “HTML” email (something I allow at sign-up for my blog).

The next unwelcome surprise came when I sent my first test email out. It included my personal physical mailing address. This cannot be fully removed, because Mailchimp is forcing compliance with anti-spam laws like CAN-SPAM. As far as I can tell (and I am not a lawyer), this doesn’t really apply unless I’m a business and my messages are marketing or ads – but regardless, Mailchimp requires an address be sent out. Using a fake address is legally dangerous for many reasons, so my solution to this was to get a second real address I can use. It turns out there are some great online alternatives to a physical P.O. Box. I went with iPostal1 which is a “digital mailbox” service. They provide a suite number at a real physical address, and then will handle all my mail to that address. Unfortunately, this is not a free service, and costs $9.99/month for the cheapest plan (this covers up to 30 mail items per month). However, this was worth it to me to avoid exposing my home address.

Mailchimp has some super useful features as well, though. The main one I use is the automatic translation from an RSS feed (which Hugo automatically generates for sites) to a periodic email to subscribers. Now that it is set up, it is completely hands-off for me and I can just write blog posts.

Privacy laws

I really want a light touch as far as tracking and cookies go. There are several reasons for this:

  1. I want visitors to feel safe and not used by me for anything they don’t consent to. This is of course the point of privacy laws – to force companies and websites to do exactly this. User data is a commodity, and users should have control over it.

  2. Complying with privacy laws is a serious and difficult thing to do. For instance (and I am not a lawyer), there seems to be no carve outs for individual bloggers in the EU’s GDPR law. For “less severe infringements”, the fine could be up to €10 million or 2% of worldwide annual revenue, whichever is higher. That is terrifying.

Ultimately, if I wanted any sort of interaction with my readers (which I really do), I had no choice but to do my best at complying. This required doing a lot of reading about others that have gone through the same thing, finding templates for privacy notices, and just looking at a lot of them. Unfortunately, most sites (even blogs) are trying to track a lot more than I am, so there was no easy solution.

Ultimately, you can see the result on my Privacy Policy page, which accessible on every page (bottom right).