Mojang recently released an April Fools version of Minecraft: Java Edition. The April Fools releases are special and strange variations of Minecraft that are developed with a low budget and explore ideas that are too outrageous to be in the main game. This year’s concept was to have in-game voting where players could enable and disable different rules on their server, with many of the rules having unexpected twists.

A core group within Mojang built the voting system and managed the release. Everyone else at the studio was invited to add some individual rules that players could vote on.

I wanted to participate but did not have much time available for side-project shenenanigns. I decided to come up with some simple rules that I could code quickly and that would hopefully be memorable and fun for players. Maximum impact, minimum effort! Here’s what I came up with:

“Prevent floating trees”

In Minecraft, gravity does not apply to most blocks. One of the first actions a player takes in a new world is to collect wood by breaking a block from a tree trunk. This leaves the top of the tree floating in the air.

Many players consider floating trees ugly and communities often make it a rule that players must remove the floating parts before they move on. It’s a hot topic!

The comedy in this rule comes from wondering how it’s going to work and then being surprised when you find out. You could imagine the floating part of the tree falling down – that would be fancy! Or perhaps the floating part would automatically break. But here’s what actually happens:

Ulraf breaks a tree trunk

This was about 20 lines of code.

“Buff fishing”

Fishing is popular in the game and there’s a lot of discussion around how much loot it should give. Is fishing overpowered? Should we let players fish AFK? The buff fishing rule promises to make fishing more rewarding. You might expect it to improve the loot table or tweak the timing, but no: it turns your fishing bobber into an infinite fountain of ocean loot.

Warning: flashing lights

Pixlriffs goes fishing with Ulraf and Bruno

This one was basically 1 line of code. I think it works pretty well!

In the video above, the players have also enabled the rule polluted oceans (not created by me) which changes the fishing rewards to include all possible items. It’s a fun rule, and it synergizes very well with buff fishing! But if we had had a bit more time to coordinate I would have suggested nerfing this combo because it’s a little too good. Having a quick source of every possible item can spoil content from some of the other game rules. (And I think we could have nerfed it in a way that let us include another good joke.)

Overall, I was happy that I was able to make some people laugh with just a few lines of code and a few minutes of work.

Going cheap isn’t always the right approach, and it was important that other devs added rules with a lot more depth than my ones. But… jokes are good too! It’s useful to think about all the tools we have to make a feature interesting and not overuse complexity. These two rules used popular community topics to set up the players’ expectations and then did something unexpected to surprise them.

You can see the official page for the April Fools snapshot at minecraft.net.

Imagine you are a developer whose job is to work on a large software project. In this case ‘large’ means that there are so many bugs that it’s impossible to fix them all.

Different bugs impact different amounts of users. Some bugs affect one person, while others affect 100 or even 1000. Of course bugs also have different severity – some bugs are minor annoyances while others cause serious problems – but let’s consider a group of bugs that all have similar severity (and similar cost-to-fix) and the only major difference is how many users are affected by them.

Here are two ways to work in this environment:

Option 1: You spend every day fixing a bug that affects one user. At the end of the year, you have fixed about 200 bugs and made life a little better for about 200 users.

Option 2: You spend one day fixing a bug that affects 1000 users, and then spend the rest of the year goofing off, watching TV at work, and rearranging your desktop icons.

The second choice is better. In fact, a developer who chooses the second choice is five times more productive than a developer who chooses the first. They have five times the impact because five times as many users are affected by their work.

Of course there are more choices than the two options above, but I’m comparing these two specific options to make a point:

‘Option 1’ is not a good choice. It is not useful or noble or heroic to come to work every day and do work that doesn’t matter. It doesn’t make you a good developer or even above average. It is a waste of company time.

In my experience, in large companies, a lot of developers choose something like option 1.

These companies end up moving very slowly. Users feel like bugs never get fixed, because the same frustrating bugs remain year after year – despite hundreds of users asking for improvements. These companies grow, hiring more developers to increase speed, but the speed never comes. The additional developers are working hard, fixing issues every day, but the users don’t seem to notice any difference.

To create real impact, we must focus on work that matters.

How do we do that?

1. Spend more time understanding the users and the product. Get to know what people are asking for and why. This leaves less time for actually fixing bugs and that’s OK. Remember that it’s better to fix one high-impact bug than 200 low-impact bugs.
2. Be wary of metrics. It’s easy to attach importance to a number – “I fixed 200 bugs this year! Cool!” Making that number go up might not represent actual benefit for the product or its users. If you must track a number, find a number that your customers think is important.
3. Be transparent. If it’s possible to tell your users what you are working on each week, do so. They will tell you when you’re wasting your time on low-impact work. If it’s not possible to be that open, you can use your imagination instead. Ask yourself: if our users knew what I was working on today, would they be happy? Or would they suggest something else?

Learning about the product and the users’ needs lets a developer be more effective. Working hard on unimportant tasks is no better than goofing off. By focussing on what matters, we can delight our users and move much faster than we could before.

A few years ago I read an article about the NBC TV series “Timeless”. I don’t remember anything else from the article but the term “Story Engine” stuck in my brain.

The “Story Engine” was the thing that made it easy for writers to come up with a new story for each episode each week. In a medical drama, this could be a new patient arriving. In a “moster of the week” format this would be a new supernatural monster. In any case, it gives the writers’ room an easy way to start writing each episode.

I used to fantasize about writing my own time travel story.

Most time-travel stories don’t work when you think about it. They have themes and morals and work as stories, but when you actually think about what’s happening on a physical level it always breaks down.

One example is a Star Trek movie where a character takes a pair of antique glasses back in time and leaves them behind. It’s implied that the glasses will stay in that timeline and that they become the same glasses that the character had at the start of the story. It’s a loop, see? This doesn’t make physical sense because objects age over time. A pair of 100-year-old glasses that is left on a planet for 100 more years becomes a pair of 200-year-old glasses. These can no longer be the 100-year-old glasses we saw at the start of the story because they are not 100 years old.

If it was a baby left for 100 years instead of a pair of glasses, it would be easy for the viewer to see how silly the concept is. But we’re not as good at judging the age of a pair of glasses, so the idea of immortal glasses makes “story sense” and the viewer accepts it.

But Not Me!

My Time Travel Story was going to be hard sci-fi, with time travel that didn’t rely on authorial tricks. It would follow consistent rules in an uncaring world.

But the problem was this: once I gave my characters a time machine, I didn’t have anything for them to do. There was the mystery of figuring out how time travel worked, but that could be solved by making a few 5-minute jumps into the past and future inside a lab. I didn’t know what my characters would do after that.

So

The concept of a “story engine” blew my mind. Timeless was designed so that it would be easy to come up with new adventures. From memory, the premise is that the villian time-travels to a Major Historical Event every week and the heros go there and try to stop them. And they meet a famous historical figure and save the day. Easy! And then in Season 2 the premise very slightly changes, to keep things fresh. Cool!

So yeah. Everything I know about writing network TV shows, I learned from that one article about the story engine in Timeless.