“We had no code and no art assets,” Blizzard 3D Art Director Brian Sousa confirmed to Ars Technica. The 2017 project’s entire art pipeline was “eyeballed,” Sousa said, with recovered concept artwork, sketches, and original boxes and manuals used as reference materials. Not all code was missing, as Blizzard has been issuing patches to the original game’s code base for nearly 20 years. Also, a member of the sound team thankfully had backups of the original sound and voice recordings, which are now reprocessed in higher-fidelity 44,100Hz format.

I’d heard the majority of the original Starcraft code had been lost, years ago, but I figured it was just a rumour. Sounds like the team of Starcraft: Remastered had a big task to recreate the game in a way some of its biggest fans would appreciate.

External link: StarCraft Remastered devs unveil price, explain how much is being rebuilt

There’s some really good learning to be had here, even if the videos themselves are “old.”

External link: RailsCasts Pro episodes are now free!

I’ve listened to a lot of 40K podcasts over the last couple of years. Over that time I’ve slowly winnowed my subscriptions down to just a handful.

1. Forge The Narrative – my favourite 40K podcast of the last few years.
2. Chapter Tactics – from Frontline Gaming, but distinct enough from their other shows to merit its own subscription
3. Frontline Gaming – this is the main Frontline Gaming Podcast – the feed also includes Chapter Tactics and some other smaller shows
4. Ashes of the Imperium – this one is new, but it’s by the team behind the very good Bad Dice AoS Podcast

My biggest gripe with most 40K podcasts tends to be length. Sorry, but unless you’re very, very compelling to listen to, I am not going to listen to a Podcast episode which is 2-3 hours long (or more!). The Podcasts above tend to clock-in at around an hour to an hour and a half, which I find to be perfect to my listening habits.

Bonus: Podcasts I’m Evaluating:

8th Edition has brought about a few new Podcasts, some of which I’m still deciding if they’re going to stay in my subscriptions list.

• Legends of the Warp
• The Triumvirate

Bonus 2: Some Age of Sigmar podcasts

For a while I found the quality of the AOS podcasts to be in general higher than most 40K podcasts, with only a couple of exceptions. Sadly, my favourite AOS podcast — Heelanhammer — has recently gone on hiatus so I’m not including it here.

• Bad Dice
• Facehammer – can be a bit sweary, so proceed under advisory if that’s not your thing.

For various reasons I prefer to remove the www part from my personal-use domains. Setting up Caddy to serve the site from just domain.com is as simple as:

domain.com {
    root /path/to/site/files
    # other directives
}

But this set-up doesn’t provide any way to redirect from www to non-www, meaning anyone who types www.domain.com into the address bar is out of luck. So what to do? Well, Caddy provides a redir directive. Combine with a new site directive and a placeholder like this:

# Original non-WWW site:
domain.com {
    root /path/to/site/files
    # other directives
}
# New, additional "site", for doing the redir
www.domain.com {
    redir domain.com{uri}
}

An XML Sitemap can be useful for optimising your site with Google, particularly if you make use of their Webmaster Tools. Jekyll doesn’t come with one out-of-the-box, but it is easy to add one. There’s probably a plugin out there which will automate things, but I just used a normal Jekyll-generated file for mine, based on code found on Robert Birnie’s site.

The only modification I made was to exclude feed.xml from the sitemap. Because this is auto-generated by a plugin I couldn’t add any front-matter to a file to exclude it in the same way as other files.

Create a file called sitemap.xml in the root of your site, and paste the following code into it:

---
layout: null
sitemap:
  exclude: 'yes'
---
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  {% for post in site.posts %}
    {% unless post.published == false %}
    <url>
      <loc>{{ site.url }}{{ post.url }}</loc>
      {% if post.sitemap.lastmod %}
        <lastmod>{{ post.sitemap.lastmod | date: "%Y-%m-%d" }}</lastmod>
      {% elsif post.date %}
        <lastmod>{{ post.date | date_to_xmlschema }}</lastmod>
      {% else %}
        <lastmod>{{ site.time | date_to_xmlschema }}</lastmod>
      {% endif %}
      {% if post.sitemap.changefreq %}
        <changefreq>{{ post.sitemap.changefreq }}</changefreq>
      {% else %}
        <changefreq>monthly</changefreq>
      {% endif %}
      {% if post.sitemap.priority %}
        <priority>{{ post.sitemap.priority }}</priority>
      {% else %}
        <priority>0.5</priority>
      {% endif %}
    </url>
    {% endunless %}
  {% endfor %}
  {% for page in site.pages %}
    {% unless page.sitemap.exclude == "yes" or page.url=="/feed.xml" %}
    <url>
      <loc>{{ site.url }}{{ page.url | remove: "index.html" }}</loc>
      {% if page.sitemap.lastmod %}
        <lastmod>{{ page.sitemap.lastmod | date: "%Y-%m-%d" }}</lastmod>
      {% elsif page.date %}
        <lastmod>{{ page.date | date_to_xmlschema }}</lastmod>
      {% else %}
        <lastmod>{{ site.time | date_to_xmlschema }}</lastmod>
      {% endif %}
      {% if page.sitemap.changefreq %}
        <changefreq>{{ page.sitemap.changefreq }}</changefreq>
      {% else %}
        <changefreq>monthly</changefreq>
      {% endif %}
      {% if page.sitemap.priority %}
        <priority>{{ page.sitemap.priority }}</priority>
      {% else %}
        <priority>0.3</priority>
      {% endif %}
    </url>
    {% endunless %}
  {% endfor %}
</urlset>

If you want fine-control over what appears in the sitemap, you can use any of the following front-matter variables.

sitemap:
  lastmod: 2014-01-23
  priority: 0.7
  changefreq: 'monthly'
  exclude: 'yes'

As an example, I use this in my feed.json template to exclude the generated file from the sitemap:

sitemap:
  exclude: 'yes'

And this in my index/archive pages for a daily change frequency:

sitemap:
  changefreq: 'daily'

It’s super simple. Just include a push directive in your site definition. You can leave it as just that, and Caddy will use any Link HTTP headers to figure it out.

If you want more control, you can expand the directive and specify both the path and associated resources, like so:

example.com {
    root /var/www/example
    push / {
        /assets/css/site.min.css
        /assets/img/logo.png
        /assets/js/site.min.js
    }
}

What this block does is say “for every request with a base of / (i.e. every request), Push the following 3 files.” You can customise the base path if you want to, and add more files if you need, but a block like the one above is what I’m using for this site.

You can find out full details in the Caddy Push documentation.

Lately I’ve been feeling a pull to return to my Warhammer 40,000 Flesh Tearers army, which I started around 4 years ago (and promptly only completed one unit of). I had an idea of a small strike-force that was basically just a load of Jump Pack Assault Squads, supported by Land Speeders (with some Death Company elements thrown in). It wouldn’t have been very “competetive” but it would have been thematic and fun. I didn’t progress the idea very far, as the Blood Angels codex in 7th Edition was… very not good; it also took away the ability to field Assault Squads as a troops choice — rendering the entire idea invalid.

Now we’re in 8th Edition, I can build the army as I imagined it, using the new detachments in the rule book. By getting back to a small “passion project” of mine, I’m hoping I’ll be able to revive my motivation for hobby projects which has been worryingly low recently. Who knows — I might even add some Primaris Inceptors to the mix for some mobile firepower.

Apple have released the first public beta for the next version of iOS. I’ll probably hold off installing it on my iPhone for the time being, but I’m tempted to throw it onto my iPad Pro, to get some of those sweet new features I’ve seen some people raving about.

External link: Apple Beta Programme

Apple have released the first public beta for the next version of iOS. I’ll probably hold off installing it on my iPhone for the time being, but I’m tempted to throw it onto my iPad Pro, to get some of those sweet new features I’ve seen some people raving about.

External link: Apple Beta Programme

Shadowgate was a formative experience in my early youth. A brutally difficult NES RPG, it was the first time I played what was effectively a video game version of the Choose-Your-Own-Adventure books I’d been enjoying. When I say it was difficult, I mean it — it took me more than one sitting to get through the door at the very beginning of the game! I don’t think I ever managed to complete the game, despite my efforts.

I’d heard about the 2014 remake of the game, but never got round to playing it until a few days ago. The artwork is miles ahead of the original (obviously). It might not to be everyone’s tastes – it was very “concept art” style in many places. I found this led to many aspects of a room being missed at first inspection. The story is pretty much the same, perhaps with a few tweaks. There’s a little more “world building” than the original, I think?

The biggest departure was the difficulty. Despite the game retaining many of the same “frustratingly non-obvious solution” mechanics of the original, I managed to complete it in one sitting. I only died twice! (stupid Goblin…) Granted, it did extend into the early hours of the next morning, and I have over 20 years extra problem solving experience than I did when playing the original, but still…

At the current Steam price of <£3 for the edition that comes with all sorts of extras, it still gets a recommendation of worth your time if you’re nostalgic, or just fancy a new RPG game. I’m not sure I’d spend much more than that, given how short it turned out to be, but who am I to tell you what to do with your money?

You can find Shadowgate on Steam, here

Nintendo have announced the (predicted) SNES version of their Classic Mini. I’ve already registered to be notified of the preorder. The list of 20 games included on the system has some of my facourite games of all time. There’s a previously unreleased Star Fox 2 too. Even if it hadn’t had 7 games I absolutely love, I’d have preordered based on how much fun we’ve had with last year’s NES version.

Hopefully it’s easier to get hold of one this time around.

External link: Nintendo announces the Nintendo Classic Mini: Super Nintendo Entertainment System

This blog is generated by Jekyll, running on Caddy HTTP/2 server, and hosted on the lowest-tier Digital Ocean “droplet” (virtual private server). Self-hosting isn’t for everyone, but if you’re the sort of person who wants complete control over your content and how it is delivered – and who might like to tinker every so often, then read on.

The basic steps to setting up are:

1. Prepare the Droplet
2. Install Caddy
3. Setup Jekyll and your workflow

Thankfully for me, other people have already written up their own guides for each of these steps!

To create the droplet that will host your blog, you’ll need a Digital Ocean account. If you don’t have one already, sign-up using my referral link to get $10 in credit.

1. Prepare the Droplet

Create a new Ubuntu 16.04 droplet through the Digital Ocean dashboard, then follow this guide to initial server setup. This should give you a nice base to work with. One thing I like to add to this initial setup is Fail2Ban, which will automatically ban the IPs of connections trying to login with wrong SSH credentials (which will be anyone but you):

$ sudo apt-get update
$ sudo apt-get install fail2ban
# Fail2Ban should automatically start. Check it with the line below:
$ systemctl status fail2ban

One more thing you can do (not neccesarily required, as you setup <code>ufw</code> firewall on the server) is enable a Digital Ocean firewall from the dashboard, and limit connections to just ports <code>22</code>, <code>80</code>, and <code>443</code>.

2. Install Caddy

Installation of Caddy is covered by this guide. I followed the steps pretty much as-is, with only minorr changes to match my setup (different username, etc). The biggest difference in my setup was I installed a couple of plugins as part of my Caddy installation. To do this, change the command in Step 1 to the following:

$ curl https://getcaddy.com | bash -s http.minify,tls.dns.cloudflare

This will install the Minify and Cloudflare plugins. Check out the Caddy home page for more plugins.

I set my site to use the Auto-HTTPS feature of Caddy, which gives the site a SSL certificate via Let’s Encrypt. I also wanted to use Cloudflare in front of my site, which isn’t covered in the guide above. After a bit of trial-and-error, the steps I used are below. If you don’t plan to do this, skip to Step 3.

2.1 Using Caddy Auto-HTTPS with Cloudflare

First off, you need to setup some environment variables. To do this for the Service you will have created using the guide above, run the following command:

$ sudo systemctl edit caddy

This will open up an editor for you to override or add to the main service file. In the editor, enter the following:

[Service]
Environment=CLOUDFLARE_EMAIL="<CloudFlare login>"
Environment=CLOUDFLARE_API_KEY="<your Cloudflare CA API key>"

Save the file and exit. Next, edit your Caddyfile:

$ sudo nano /etc/caddy/Caddyfile

Modify to something similar to this:

example.com {
    root /var/www
    tls you@example.com {
        dns cloudflare
    }
}

Finally, in the Crypto section of your Cloudflare control panel, make sure to set the SSL type to Strict. If you don’t, you’ll end up with redirection errors

You should be ready to start/restart Caddy:

$ systemctl restart caddy
$ #Enter your password when prompted

All being well, your site should be available, with HTTPS enabled.

3. Set-up Jekyll and your Workflow

I followed this guide to setup Jekyll on my Droplet, and create the necessary Git components. If your local machine is OSX or Linux, the guide is all you need. If you’re running on Windows (like me) things are a little more difficult. I tried setting everything up using the Linux Subsystem for Windows, like in this guide, which is the route recommended by the official Jekyll site — but for some reason it didn’t work correctly.

I ended up having to install both RubyInstaller and add the necessary DevKit as the last step of the installation. From there, it should just be a case of gem install jekyll bundler and creating the Jekyll site in the normal manner (follow the first part of the guide linked at the start of this section if you need to).

Hopefully, if you’ve followed along this far, you should now have your own shiny new blog, hosted on your own server! Setting this up took me a single evening – not including the time I spent creating my own Jekyll layouts. But those are a topic for another time…