So I made a tutorial about writing a broughlike in JavaScript from scratch. I'm really proud of it. I've watched several people follow it to completion and the feedback has been unbelievably positive. It was even used by Zack Johnson (creator of Kingdom of Loathing) while doing a game jam. Whoa!

The idea of this project came about because I was super frustrated trying to learn Unity. I guess I'm just a big dummy, but struggling to learn something new after some 20 years of programming (and constantly learning new things every day) was hard to deal with. And the whole time all I could think was: this would be so much easier in JavaScript.

Now at least I have an appreciation for both the difficulty of learning Unity and the difficulty of writing a tutorial. :D

It's amusing how every language I have used professionally has received such widespread hate. People hate CSS for being utterly confusing, PHP for its terrible design, Java for being too verbose and enterprisey, ColdFusion for being a joke, and JavaScript for... well they blame everything that was ever wrong with the web on JavaScript.

Despite that, I love JavaScript and I hope that shines through in the tutorial. JavaScript feels so natural, so fluid to me. I know it lacks types and it has dangerous constructs and weird parts, but that stuff is really really useful too! I really can't imagine a better lanugage for going fast.

If you have any interest in learning game development or JavaScript or both, please check it out.

Let's make 3 things crystal clear before we start:

• Yes, the title is 100% true
• Yes, I'll explain
• Yes, I am an absolute bastard

Twenty sixteen was a terrible year for celebrity deaths. Or... a really good year depending on your perspective. Famous people were dropping like flies. You could feel it in the air. Musicians, actors, novelists, astronauts, dictators; 2016 claimed all. David Bowie, Harper Lee, Prince, Muhammad Ali, Gene Wilder, Leonard Cohen, Fidel Castro, and John Glenn to name a few. Later analyses would show that 2016 actually was a statistical anomaly in regards to dying celebs. Things were so bad that a GoFundMe was launched called Help protect Betty White from 2016.

A very important squirrel

My project to predict celebrity deaths started in the fall of 2016, as the United States was preparing to elect a reality TV show host as president. It was clear that people couldn't get enough celebrity news, especially when it was an obituary. It was the first discussion in the office. It was on the front page of every magazine and newspaper. Scrolling across every ticker on every 24 hour news show. It's in your face all the time. Things happen to people we've never met and never knew we existed that have no material impact on us and yet we can't look away. Never mind the 150,000+ "normal" people that die every day on this planet.

In the timeless words of our next celebrity president Mark Zuckerberg:

And I thought, "If people saw that these celebrity deaths were prophesied, they would lose their damn minds."

I made my predictions on a twitter account called Ghastly Omens. Not only did I predict 23 celebrities would die in 2017, but I predicted the exact day each of them would die. You can go see for yourself. Tweets made in 2016. Deaths happening in 2017. Every single tweet spot on. It's all very spooky!

So what's the trick?

A lie of omission

It's all rather simple. In addition to 23 accurate predictions, I also made about 250,000 that were false. I kept the hits and deleted the misses. Prophecy and prediction is easy if you can sweep your misses under the rug.

I later found out that mine wasn't the first project to attempt such predictions. The most well known was beyoncefan666, who predicted Trump getting elected, Britain leaving the EU, and Beyonce having twins. The whole idea is explained very well by How to Flawlessly Predict Anything on the Internet.

Believe it or not, I wasn't aware of any of this when I started Ghastly Omens. BeyonceFan666 hadn't been made public yet, though when it did it instantly went viral gaining over 30,000 followers. Having seen that, with my plans already in motion, I figured my project would scare the pants off of people. Trump? Brexit? That's small potatoes compared to the exact day on which people die. As it turns out, nobody would end up caring. More on that later.

SECRET TWITTER PROJECT

It's not easy making or deleting 250,000 tweets, so let me explain how it all worked. First, it helps to know a few important facts about Twitter that make this all possible:

• All tweets have an easily viewable timestamp
• Editing tweets is not allowed
• Tweets can be deleted without any public trace
• Twitter accounts can be switched to be completely private and then back

I would make my account private, accepting no followers. With no one watching, I could post tweets that no one would ever see and would not be cached by search engines. When the project was wrapped up, I could delete all but the 23 hits and then turn my account public again.

But there is also a practical limitation. Access to the Twitter API is rate limited, equating to a maximum of roughly 100 tweets per hour. I would have to spread my posts over 4 months, September to December 2016. Some of my predictions were already proving false during this time period. Carrier Fisher passed away on December, 27 2016. Her mother, Debbie Reynolds, died the next day.

Casting

Have you ever wondered: how many famous people are in your head? While you might personally know a few hundred acquaintances, the number of actors, musicians, writers, directors, athletes, and politicians you are aware of probably totals in the thousands.

With time for only 250,000 predictions and 365 required per celebrity, I was restricted to a list of about 700 people. My list would be far from exhaustive. I compiled it mostly by trawling IMDB's celebrities ranked by their "STARmeter", whatever the hell that means, then tacking on names from a few other random lists of famous musicians, novelists, etc.

Only the popular die young

Inclusion onto the list was a tradeoff between popularity and age. I obviously preferred popular celebrities, but I also needed a good number of accurate predictions. This is where the cold hard math of actuarial tables comes into play. At age 20, your chance of dying in the next year is about 1 in 1000. At age 90, it's 1 in 6.

If I filled my list up with the hottest actors (who tend to be 20 or 30 somethings), I'd risk not having any hits.

If the list was only centenarians (good luck compiling such a large list), I'd have some nice predictions but few would recognize the names.

The end result was a focus mostly on celebrities age 60-80. For this reason, my predictions completely missed younger souls like Charlie Murphy (57) and Chester Bennington (41). The youngest person to die on the list was Bill Paxton (61) and the oldest Irwin Corey (102).

I settled on a simple format for the tweets much like a gravestone: name followed by birth and death date. I wrote a PhantomJS script to iterate over my list and try to grab birthdays off of IMDB, but I had to fill in some gaps by hand.

I loaded up a MySQL database with the full list of predictions, then set up a cron job to run every 5 minutes for about 4 months. This job pulled a handful of random prediction records and posted a tweet for each using the Twitter API.

And then I waited.

Separating the living from the dead

This project required quite a bit of patience before seeing any payoff. I was hoping to reveal Ghastly Omens at the end of 2017 to coincide with end of year lists being compiled and shared. I couldn't wait until December to start deleting because deletions are also rated limited, so I had to do it in batches throughout the year. Without any automated to way actually find who died on my list, I simply checked IMDB and news sites periodically. Once I knew someone on the list had died, I flagged them in the database so that a subsequent deletion script would avoid deleting the associated tweets. There wasn't much room for error here. Deleting a tweet is nonreversible.

The moderately sized reveal

When I finally switched my Twitter account from private to public, I ran into two big problems.

Even though my deletion script had marked all but 23 tweets as deleted, my total tweet count displayed over 50. Something was wrong. I assumed at first that it was some eventually consistent nonsense, you know, the way reddit upvote counts fluctuate wildly up and down upon refreshing the page. That wasn't it. The Twitter API had failed to delete some of my 250,000 tweets, but I didn't know which ones! Talk about needles in haystacks....

You might assume this was as simple as going onto the Twitter client and manually clicking "delete" a few dozen times. Nope. I couldn't even see these phantom tweets. I soon learned that Twitter only shows your most recent 3000 tweets. Somehow other people were seeing the tweets that I could not see on my own timeline. This was a tad infuriating, but I found a third party app that somehow provided links to all of my old tweets and I deleted them. Luckily those extra tweets hadn't doomed the poject because pretty much no one knew about it yet...

I have absolutely no idea how to market anything

The second problem was not as easily resolved. Long story short, no one cared.

I didn't have a great plan for marketing the account, but I assumed that it wouldn't take much to go viral. I followed over 1900 people and, by hand, liked over 700 tweets (mostly to do with celebrity deaths which I had predicted).

• I had one person ask when they themselves would die.
• And another ask me when the President of Turkey, Recep Tayyip ErdoÄŸan, would be dead.
• And I even had one rando DM me believing my account was part of some grand criminal conspiracy involving the game Eve Online. Yea...

But overall, it was radio silence. Fewer than 200 followers, most of which were bots. I'm sort of used to it at this point. I have two Twitter bots with a combined followership of 32.

I do wonder if my project itself is flawed. Was I too subtle with the presentation? I don't go outright and say HEY I MADE THESE TWEETS IN THE PAST. It's more up to the reader to connect the dots and look at the timestamp. Did it fly over their heads? Or maybe Twitter is just too skeptical these days and saw right through the gimmick, though I really doubt it.

My last guess is the most dismal. Twenty seventeen wasn't an outlier for celebrity deaths like 2016 was. Perhaps the celebrities on my list are just too old to get the attention of influencers. Because eventually even celebrities are forgotten. Even Batman. Even James Bond. It happens to everyone.

Memento mori: remember that you will die.

The Castle Doctrine is a robbery MMO. With a bizarre mix of simulation and roguelike elements, it's a game about building a house to protect your family and your money, robbing others, and eventually experiencing the inevitable: having others destroy everything. My experiences in this game were unlike anything else I've ever felt in a videogame.

I used to rave about this game. In fact, it was the very first thing I wrote about on this blog:

• Part 1
• Part 2
• Part 3
• Part 4

I kept recommending TCD until shortly after it came out in early 2014. It had a really good run, but then interest faded. The player base dwindled from hundreds to dozens to almost nothing. And it's not at all a single player game. It was fundamentally broken without a large player base. Content was removed from the game rapidly because a single skilled player could wipe out multiple houses. A lack of houses presented two problems: nothing to do and no way to learn. The small handful of houses remaining at any given point were impenetrable mansions built by expert players with YEARS of experience. The "learning curve" in the game was a brick wall.

I kept talking about the game with such excitement, but in an academic way. Always with the caveat "it's probably not worth buying though."

Four years later, out of the blue, things have changed!

In an attempt to fix player base issues, the developer recently revisited the game's logic, first by reducing chill timers and then bringing back abandoned houses. Log in today and you'll be guaranteed to see 100 houses on the list. The game no longer lacks content and the learning curve is actually reasonable. I believe these two changes alone make the game worth recommending once again.

So if you've been curious... go buy it!

After writing several blog posts about why TCD fascinated me, there's not much left to say. However, I did want to revisit my favorite houses one last time for nostalgia (and to show how fun this game can be despite its brutal nature).

1) The leap of faith

It isn't anything remarkable today, but I played early in TCD's alpha and might have been the first to discover this "leap of faith" puzzle. To get past the trapdoor and electric floor tiles safely, you must find a pitbull elsewhere in the house, get it to follow you at the correct distance, and use the dog to carefully unlock the final traps.

2) Clock House #1

I had a lot of fun with clocks (they can power traps on alternating turns). The great part about using clocks is they can discourage tool use. Using a tool advances the electronics timestep, instantly turning a deactivated trap deadly.

The most memorable thing about this house is not its design, but how it was beaten. One of the best TCD players invaded me with SEVENTY NINE SAWS, which is a delightful and absurd yet crushing thing to have to repeat. :)

3) Clock House #2

From a "thinking outside the box" perspective, this one is probably my favorite. It's a clock house again. But unlike most high-defense houses that hide the safe behind layers upon layers of obfuscation, this one has the safe practically in "plain sight". Defeating it without tools requires an arduous journey all the way through the house and back again, finally ending up in a spot where the pitbulls can be neutralized.

4) The Exploit House

OK, this one is just a gag. In version 32, a wireless transmission bug was discovered wherein unconnected circuits could affect each other at a distance. I realized that, between the bug and the upcoming fix for the bug, there was a narrow window to pull off a prank.

First I made a house that had broken trapdoors (effectively short circuited by wireless transmission) and then when version 33 came around, the long hallway of powered doors turned on again... with no way to beat the house without tools.

5) Redface

The Steal Real Money contest was insanely fun and dreadfully tense. For me, it was an all-out TCD marathon for a whole week. I got near "the top" (close enough for a physical prize) about 5 times in that week and lost it all repeatedly. Those deaths were PAINFUL. Real money (and a tiny bit of notoriety) was on the line, so take your most painful roguelike death and multiply it by 100.

The most gut wrenching death during that week was when I brashly stumbled into an apparently easy house with no tools. I saw a row of doors and what seemed to be a rookie mistake: paying careful attention to the fog of war, I could just barely tell all but one of the doors was a dead end. The safe would be right behind the other door. 'What an idiot' I thought! I stepped over an electric trap, through the "correct" door, and instantly realized my mistake: the door opened up into a sprawling maze and a huge number of additional traps. I was the idiot.

After so many failures, here's what I finally ended up with. It wasn't the best, but it was enough to net me 6th place in the contest.

6) The Gauntlet

Shortly after getting hit by the 79 saws, I tried to climb the neighborhood ladder again. The local kingpin was one Mr. Wallace. Wallace was in the #1 spot with over $320,000 and he was wiping out any possible competition (anybody with over $30k). I was barely shy of that with $24k...

I made a desperate attempt on Wallace's house, taking a guess on its weakness, and unbelievably it worked! I wrote a silly "acceptance speech" to mark the occasion:

Let me assure you I'm going to keep all the promises I made during my campaign. Lowering crime against myself. Supporting the fine arts. Getting our economy started again with trickle down economics. Family values. Well, I don't have a family anymore... they were taken from me in three horrific incidents. Anyway, I promise not to take out your children unless I absolutely have to. Now that I've removed General Wallace from power, things around here are going to change. Rest assured that the new king won't be like the old king. At least for today because I'm pretty busy. I'm Charles Jeffrey Penn and I approve this message.

Then with hundreds of thousands of dollars to spare, I built the most elaborate house that I could imagine:

And here it is annotated because even I can't remember how the hell it worked:

Interested?

Don't just throw this game on your wishlist for later. The Castle Doctrine is never going on sale. With the recent changes, now might just be the best time to join the neighborhood.

Twenty sixteen. What a year, right?

New city, new jobs

In June, my wife was accepted into a 1 year program at UNC. Since we lived 120 miles away, we knew right then that life was going to get hectic quick. I was terrified of going back on the job market. But I did find a new gig and it was a big learning experience. I got exposed to a slew of technologies I had barely touched (Git, Grunt, Jasmine) and learned a ton about ones I thought I knew.

I decided the most cost effective thing for me to do was spend weekdays living with my mother who lives close by. As a millennial, it is of course my God-given right.

Fucking millennials

— Jeremiah (@humbit) October 24, 2016

Fortunately, my wife just this month got a part-time job offer and we found an apartment near the new jobs. We've been wanting to make this move back "to the city" for years. After 5 months of living with my mother (and watching hundreds of hours of Fox News), we made it! ☺️

My diet and exercise took a hit over the last few months, as I lost access to a gym and had little time, but I hope to correct that going forward. At least I did start rock climbing again, something I haven't done since college.

Steam

Holy shit, I released a game on Steam Early Access! Even if releasing on Steam doesn't mean what it did a few years ago, it's still unbelievable to me. One reason this is such a big accomplishment is that I don't have a great track record of finishing big projects. Game jams I can deal with, but I've never stuck with a game for years. It's a challenge sometimes. There's a lot of self doubt, but I'm staying with it. I've already released the first post-release update and am working on a second.

The feedback has been awesome. Golden Krone Hotel is currently sitting at 19 reviews, all positive. If I'm being honest though, I do worry about the depth of the game. It's an intentionally streamlined roguelike experience and I try to be honest about that. I see a few people have put in 20+ hours, but is it engaging for most people? I have no idea! The feedback I hear is certainly positive (getting a write up on Rock Paper Shotgun was more than I could have hoped for).

But it's the people that bounce off of it that I wonder about. Maybe players are wary to engage fully because it's in Early Access? Who knows. I plan to make the game deeper and more engaging in 2017.

Tiny projects

Waifu Showdown A bit of weird one this, but lots of fun to make. My friend Calico had a silly project going on where people voted for their favorite characters through Twitter. I made a bracket website for it and added twitter integration.

Who Dis Pokemans Equally weird I guess. When Pokemon Go came out, I played the crap out of it. I burned out quickly, but for a few weeks it sure was magical to walk into a public park and see dozens of people playing the same game. From that I was inspired to make a twitter bot that combined Pokemon and photos from the British Library collection.

Trash Tree I've admired procjam from afar but never joined until this year. Inspiration struck when I saw this nifty pseudo-3D technique. I'm still in shock at how 3D and (sometimes) realistic the trees turned out.

Time travel

I entered the Seven Day Roguelike Challenge for the 4th time with The Only Shadow That The Desert Knows, a time travel game about hunting down ancient artifacts.

I wrote a blog post about the development and it hit #3 most popular post of all time on /r/roguelikedev.

I turned that post into a talk, which I gave at IRDC this year.

Whether or not the game succeeded as entertainment, based on the feedback I've received, I can say it turned out to be an interesting game. The time travel theme seems to have struck a nerve. This is definitely fertile ground that others should explore...

Miscellaneous

I very rarely write blog posts, but I think I came up with a few good ones this year:

The Simulation Hypothesis Is Nonsense

Making a Title Screen

7 Reasons Save Systems Are Garbage

Finally, I worked on a SECRET-TWITTER-PROJECT which has finished producing its 250,000 tweets. More on that in 2017.

Here's my recap of the 2016 International Roguelike Development Conference in Brooklyn, though really it's mostly an excuse for me to test out my new bespoke RSS feed. I was thinking I didn't post enough to warrant a feed, but in hindsight that's exactly when one should provide a feed.

Last year was the first IRDC in the US and the first time I had met anyone from the roguelike community. I decided to go again and to give a talk this time, even though I'm still totally freaked out about public speaking. It was once again amazing to meet people across the whole spectrum: veteran developers, roguelike enthusiasts, and some just getting their feet wet.

Huge thanks to Kawa for organizing the conference this time! The exhaustion was definitely palpable, yet things ran quite smoothly. Also, thanks to Mark R Johnson for visiting us from across the pond and justifying the "I" in IRDC (I noted last year that Mark's rumored involvement resulted in a real stone soup). Check out the postmortems from Mark and Kawa. The latter goes into depth about the details of running a conference.

Roguelike Time Traveling

My talk went a lot better than expected. I adapted it from a blog post I had a written earlier this year called Time Travel Is ******* Hard, so it was pretty easy to write the slides. There were a couple hiccups because of converting to Google Slides, but deciding to demo the game on the fly was even better than the gifs I had planned. I received several mind expanding questions after the talk and we all took turns being rather confused. I got some super positive feedback (you people are too nice) and some encouragement to keep working on the game. I really hope I can in the near future...

Markov by Candlelight: Toward a Procedural Library in Caves of Qud by Jason Grinblat

Probably my favorite talk of the conference. We've all seen Markov text before and it's usually quite incoherent/hilarious. However, I am impressed by the clever techniques on display here such as hooking secrets into procedural books and feeding Cave of Qud's own help text into the corpus for delightful results.

Writing better code by Thom Robertson

It's clear Thom has seen things over his programming career. He offers a good number of lessons learned, all aimed at making your life easier. This is a great talk for novice programmers.

Applications of Dijkstra Maps in Roguelikes by Brett Gildersleeve & Patrick Kenney

I keep reading about Dijkstra Maps, but am always left a bit confused. This talk helps a lot and demonstrates some really cool behavior that you can wring out (e.g. monsters with flanking behavior).

Surprises! by Sheridan Rathbun

In the same vein as last year, Sheridan talks passionately about the ups and downs of following your dreams in game development. Plus we get to see some exciting early work on his next game.

Procedural Dialect Generation by Dr Mark R Johnson

Procedural dialects, procedural names of all varieties, procedural questions with procedural responses. Oh my! You'll be blown away as usual.

Real-Time Synchronous Turn Systems in Roguelikes by Brett Gildersleeve

Brett returns to his previous 7DRL, Rogue Space Marine, to dissect what makes it special. It's interesting how a constraint (being unable to properly code a turn based system) turned into a huge boon in the end.

Artificial Intelligence In Caves of Qud and Sproggiwood by Brian Bucklew

It's always fascinating to see the inner workings of the Cud universe. This talk is going to help me refactor all the spaghetti code that currently drives my enemy AI.

A Personal Hell: My 7DRL 2016 Experience by Adam Boyd

Huge props to Adam. He gave his whole talk before realizing that we couldn't hear any of it and then immediately gave the same talk again. This is another heartfelt exploration of the emotional rollercoaster that is game programming, but this time from the perspective of a total beginner. I pestered Adam to try his hand at a 7DRL last year and damn if he didn't follow through.

Demos & Lightning Talks

We got some unexpected bonuses with discussions on enjoying your craft, nifty tools, and even Markov-generated karaoke! During the demo time, I had a blast playing (and nearly beating) Billiard Dungeon and I even saw some serendipitous events occur in my own game.

There were mentions of the next IRDC taking place on the east coast again (maybe DC?). I hope to see you there. And don't forget about the upcoming Roguelike Celebration, which has a totally ridiculous speaker list.

There, I said it.

Last week Elon Musk told us that there is a 1 in billions chances that we're not living in a simulation. Musk is a smart dude and I don't think he actually believes the argument. It seems more like the kind of trolling argument you have with your contrarian college roommate about Zeno's paradox or .9 repeating. You can see what I mean when Musk asks "is there a flaw in that argument?"

A little back-of-the-napkin math shows the flaw right away.

Before we get to the math, I have to disagree about games being photorealistic. They're often breathtakingly beautiful, but stare at any part of them and the gap between the game and reality is painfully obvious.

Everything in a videogame is a facade

Musk's argument makes me wonder how much he understands videogames. Most objects in games are not simulated in any interesting way. They're hollow shells, incredibly detailed, but hollow nonetheless. Like us, videogame characters have skin but they don't typically have muscles or organs or blood or nervous systems or trillions of bacteria.

Imagine you walk into a VR game today and pick up a simple orange. You can't slice the orange in half. You can't rip up the rind into a thousand pieces. You can't squeeze the orange and watch the juice drip out. It's just an orange ball (maybe with some interesting tricks to make it look OK as long as you're looking at it from several feet away).

That's why Minecraft is so interesting. You actually can poke into the world and slice things up and explore forever. But remember that the atomic particle in Minecraft is a 1 meter block. And at the most extreme graphics settings, it simulates less than a square kilometer of those blocks at a time. That's the resolution we're at now. One meter.

That doesn't impress me. Not in the way I need to be impressed for this argument.

Based Reality

Musk makes a handwavy arugment that we'll have billions of set-top boxes capable of games/simulations indistinguishable from reality. And we'll get them in 10,000 years EVEN IF our current rate of technological advancement slows by 1000 fold. It's an off the cuff remark, but a specific claim and a demonstrably silly one.

What's our current rate of advancement? Let's assume Moore's Law is still going strong (I don't necessarily believe that, but let's assume it). Then our processing power increases at a rate of 2^t/2 where t is measured in years.

You can interpret "a thousandth" our current rate in one of two ways: reduce the base or reduce the exponent. That leaves you with either

1.001^10,000/2 = 148

OR

2^10,000/2,000 = 32

Let's take the higher number. A 148x improvement is about 15 years of steady Moore's Law progress. I don't think that's what Musk had in mind.

You can think about it like this: what did videogames look like in 2001, what do they look like today, and what will they look like in 2031 (assuming Moore's law doesn't slow down).

2001:

2015:

2031?

Who knows. Maybe 2031 graphics will look photorealistic, but I still don't think they'll be realistic. I have no reason to think in 2031 I'll be able to cut up an orange in a realistic way. And I'm only talking about a macroscopic object!

Don't Simulate My Consciousness and Tell Me It's Raining

Maybe I'm being unfair, so let's break down what it takes to simulate everything. We'll ask the question "how fast do computers have to be to simulate the universe?"

This is very rough and I'll address objections later, but here goes. The number of calculations per second required for a universe simulation is something like:

The numerator is squared because each particle affects each other particle in an N-body simulation (and, well, in reality too). There are ways to optimize a simulation to reduce this dramatically, but only at the cost of reduced accuracy. Even without the square, the numbers are ridiculous. More on this later.

How many particles?

What are we simulating here? The universe right? Well, there are about 10⁸⁰ particles in the observable universe.

What timestep?

One obvious guess would be the Planck time (5.3x10^-44s), but not being a physicist, I can't say if that number has any particular significance to our simulation.

At least it's got to be smaller than the smallest time we can currently measure: 1.2x10^-17s.

The final calculation:

So all we need is a computer that can run about this many calculations per second:

1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

That's a big number, innit?

Our most powerful supercomputer, Tianhe-2, can do this many calculations per second:

33,000,000,000,000,000

And that computer cost $400 million! In Musk's scenario we're running universe simulators in every home. Oh and assuming we did get that 148x improvement described earlier, the fastest supercomputer in the world could now do this many calculations per second:

5,000,000,000,000,000,000

One more time for emphasis. This is what we need instead:

1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

Of course I hear you screaming "exponential growth will get us there eventually!" Moore's law indeed gives you another "zero" every 7 years. There's only 177 zeros up there, so we're really only a millenia of solid growth away. No problem, right?

Here's the fly in the ointment though: there's no proof we're going to have exponential growth in processing power forever. There's no proof that any sort of advancement over the long run is guaranteed. Five decades of Moore's law is surely impressive, but there's no reason to believe the party will continue forever. Last year Gordon Moore himself said "I see Moore's law dying here in the next decade or so."

For a moment, let's ignore the fact that Moore's Law has already seen some slowdown in recent years.

Let's ignore the fact that we're already making transistors that are only 100 times bigger than single atoms.

The one thing we can't ignore is the speed of light. Bremermann's limit is a speed limit on how fast computers can ever be made. Turn the entire Earth into a computer running at that limit and you're only able to achieve 10⁷⁵ calculations per second.

Notice that's over a hundred orders of magnitude (a googol) below what we calculated above.

So even if each of our post-human descendants has their own set-top box (each as massive as Earth) and they've overclocked them to Bremermann's limit (no reason to think we'd ever get anywhere close) and billions of them work together, they still won't be able to simulate a single timestep of the simulation after trillions of years.

On to the objections....

Our descendants only have to simulate human brains. Much easier.

Sorry, no. You're still missing an entire world. That leaves everyone in a sensory deprivation tank. If instead you neglect to do a proper simulation and poorly approximate the physical world, the simulation will fall apart (i.e. stop making sense) as soon as the beings inside started doing science.

Our descendants could alter the simulation on the fly to meet our expectations.

Maybe you're thinking of a puppet show instead of a simulation.

That's not how videogames work anyway. Dungeons and Dragons maybe.

Per Musk's arguments, there are billions of simulated beings per real being. It doesn't make sense in the slightest that the base reality would have the time to manage each of us individually.

Well, our descendants don't have to simulate the entire universe. Only Earth.

Really? What happens when humans land on the moon or we send a probe to Mars? Or humans detect gravitational waves from two motherfucking black holes colliding? Or when our spacecraft exit the solar system? Or when we look anywhere at the night sky?

Even if this argument was granted, the Earth has 10⁵⁰ particles of its own. Run the calculation again and you still wind up with absurd numbers.

Ok, but our descendants don't have to simulate in real time.

True, but as I said earlier the math doesn't seem to allow for even a single timestep to be processed in trillions of years. Anyway, who wants to run their videogame in anything less than real time?!?!

Even if you have some massive optimization that makes the thing run in real time, you have more problems....

Are you going to patiently simulate 13.8 billion years of solar and biological evolution before humans arrive? If you do, then your futuristic society has to wait until your real sun dies out before you can see the simulated Earth being formed.

And if you don't wait, how are you going to get the initial conditions? Are you going to scan the entire universe as it stands, all its matter, and its electromagnetic waves? If not, how do you guarantee every piece of the physical universe has internal consistency and a plausible origin?

Come on, at least the timestep can be longer. No faster than human perception!

How is your simulation going to handle simulated computers that run faster than your timestep?

Funny thing that.

The entire simulation argument rests on computers getting faster, but the faster they get, the harder it will be to simulate them!

Well, the outer reality doesn't have Bremermann's limit. The laws of physics there are completely different and alien.

And now you've really jumped the shark. Instead of the argument being an extrapolation of current technological trends, you're just positing new fantasy universes while having absolutely zero evidence of them existing.

I mean, it's not impossible. No more so than solipsism being true. Or a tiny teapot floating between Earth and Mars.

Trilemma me once

Elon Musk got many of these ideas from Nick Bostrom, one of the popularizers of the idea that the universe might be a simulation. While all very interesting, I don't find Bostrom's argument totally coherent. Granted, I haven't read Bostrom's books, so perhaps I'm missing some nuance there. But the summary certainly doesn't seem airtight. In a nutshell, Bostrom argues that one of the following three possibilities is true:

1. "The fraction of human-level civilizations that reach a posthuman stage (that is, one capable of running high-fidelity ancestor simulations) is very close to zero" OR
2. "The fraction of posthuman civilizations that are interested in running ancestor-simulations is very close to zero" OR
3. "The fraction of all people with our kind of experiences that are living in a simulation is very close to one"

It's a bit like saying if our civilization can go to Mars (we can), and some people are interested in going to Mars (they are), then almost everyone now lives on Mars.

There's a lot wrong with this reasoning. It misses the point that the enthusiasts of any given subject (whether that's manned space travel, computer simulations, or civil war reenactment) don't usually control the entire world's economy. Maybe our descendants, most of them anyway, will have more interesting shit to do.

Beyond that, it ignores a fourth possibility: that a civilization might be able to just barely run a single simulation, but not necessarily a plethora of them.

Interestingly, even Bostrom says it's less than 50% likely that we're actually in a simulation.

Odd how that turns into a greater than 99.9999999% likelihood for Musk.

In 2008, Satoshi Nakamoto introduced the world to Bitcoin.

In 2016, Craig Wright introduced the world to Craig Wright. Oh, and also claimed to be Satoshi, which implies he owns half a billion dollars in BTC.

You probably already know this is a load of bunk, but I've yet to see a concise article on how Wright managed to trick several news organizations and even Gavin Andresen. We already know how Wright tried to pull a digital magic trick on the whole internet (but again very few easy to understand summaries). I want to explain it as simply as I can^[1]. After that, knowing the formula for the online trick, I think it's pretty clear how he managed to pull off his tricks in person.

In this blog post, Wright strongly implies that he has multiple private keys that were only known to Satoshi. If so, he probably is Satoshi. To prove it's true, he just has to sign a message as shown above. It's actually simple. Here's how it should go:

1. Wright hashes a message^[2].
2. Wright signs the hash.
3. You verify his signature.

Notice that the only part possibly involving human readable text is the Message. The rest of the data will just look like a bunch of meaningless junk to a lay person. And importantly, the hashing algorithm only works in one direction. You can't get the original Message from the Hash.

Getting you to stare at a bunch of meaningless junk is the crux of the trick.

Now, for what actually happened.

1. Wright shows you a picture of a message, part of it at least. Maybe it's a letter by a famous author, maybe it's a message of your choosing (pick a card, any card).
2. ...
3. Wright hands you a hash, which is supposed to correspond to the message. Trust him.
4. Wright hands you a signature.
5. Wright hands you a public key, which is clearly only associated with Satoshi.
6. You verify the signature.

Guess what? The verification works. Don't get confused here. There's nothing broken with the verification algorithm. And Wright doesn't have to tinker with it at all. Some have pointed out that there is a typo (signiture) in some of Wright's scripts. Considering he copied the script from a gist that doesn't contain that error, I think it's possibly a clever misdirection.

What Wright pulled was a replay attack. Meaning he copied/pasted existing, publicly available data (including hash, signature, and key) and then just showed it to you again. It was valid data then and it's still valid now. He copied them from the blockchain, Bitcoin's historical ledger.

Is it a weird coincidence that he found all 3 on the blockchain? No, because digital signatures are a good chunk of what makes Bitcoin possible.

Craig Wright can't actually do the part scribbled out above, the signing. If he had that capability, he could do it in a few minutes from the comfort of his own home. That would settle the matter almost definitively, but he can't and won't.

Witnessing this and still thinking that Wright is Satoshi is like catching God in the act of faking his own miracles. If that doesn't make sense to you, welcome to the club.

Now, how does Wright trick someone sitting in the same room? Someone technical. Someone like Gavin Andresen?

I have to say first that I'm very sympathetic towards Gavin. If you listen to what he's saying, you can clearly tell that he's probably more desperate to meet Satoshi Nakamoto than anyone else on the planet. Think about that for a minute. Think about what it would be like to form your career and your identity around an invention, to have only exchanged a few technical notes with the inventor, to worry about whether they're even alive for years, and then finally to get the chance to meet them face to face. To shake their hand!

I hope that hand you're shaking isn't the hand of a skilled conman. Suffice it to say, there's some baggage here. Read Gavin's post on the meeting (emphasis mine):

Part of that time was spent on a careful cryptographic verification of messages signed with keys that only Satoshi should possess. But even before I witnessed the keys signed and then verified on a clean computer that could not have been tampered with, I was reasonably certain I was sitting next to the Father of Bitcoin.

And later:

It was a mistake to agree to publish my post before I saw his- I assumed his post would simply be a signed message anybody could easily verify. And it was probably a mistake to even start to play the Find Satoshi game, but I DO feel grateful to Satoshi.

So here's what we know for sure (assuming Gavin Andresen is being truthful, which I don't doubt):

• Andresen is flown to London to meet Wright and associates
• Andresen brings his own USB stick
• Andresen supplies a message shown below
• Wright appends something to the message (possibly important!)
• Wright has his own computer
• Wright demonstrates a "signing" associated with Satoshi's keys
• Wright also supplies a "factory sealed" computer for verification purposes

If you followed along earlier, you know what's coming. On his own computer, Wright can demonstrate whatever sort of fakery he wants. He can type any series of commands into a terminal and get exactly what he wants.

For their test, Andresen chose the message "Gavin's favorite number is eleven." Wright added his initials, "CSW," and signed the message on his own computer.

He can appear to be "hashing" Andresen's message and instead outputting a predetermined hash. The original message is irrelevant.

Likewise, he can then type commands that appear to be digitally signing Andresen's message and are actually just outputting a signature.

That's just his own machine though. The next step, where Andresen verifies the signature, is the real mystery. But I don't think you have to grant Wright supervillain powers to understand how it could be done. There's no need to hack the wifi or perform some MITM attack.

I think there are three possibilities in decreasing order of likelihood:

1. The hashing was done on Wright's machine and copied to Gavin's USB stick

A mistake, but an understandable one considering Gavin was already convinced and certainly not expecting this kind of replay attack. The verification seemed like the important part, after all, not the hashing.

2. A hashing utility was compromised on the "fresh" laptop

First, understand that even if the fresh laptop really was "factory sealed" that means nothing.

Wright could have been shipped a Windows laptop with an image that replaced a built-in hashing utility like CertUtil. This is slightly more far fetched, but not at all difficult for a wealthy businessman.

3. The laptop somehow opened a compromised version of Electrum

I find this really hard to believe for several reasons. But there is an interesting point.

At first, the Electrum software's verification of the signature mysteriously failed. But then Andresen noticed that they'd accidentally left off Wright's initials from the message they were testing, and checked again: The signature was valid.^[3]

Another clever misdirection? Maybe! But if I'm going to wildly speculate, I'm gonna go big.

If Electrum was compromised, Wright would need a way to get verification to fail on junk messages in case Gavin tried to get it to fail intentionally. You wouldn't want Electrum just saying OK VERIFIED on every input. But if it was simply waiting to see the letters CSW, Wright was able to get Electrum to both fail and succeed at the appropriate times without knowing what message Andresen would choose. Yes, it's Andresen who spots the error, but he's a talented programmer looking at a short string. Who wouldn't?

Option 1 or 2 seem the most likely, but I'm aware that Andresen could dispute those claims easily (I emailed him, but I don't expect a response). If it was something like #3, we'll never know.

Bamboozled

You might argue that the offline trick could be totally different from the online one. True, but why waste a good magic trick?

In recent sessions, I have used a total of 10 private keys are associated with bitcoin addresses. These were loaded into Electrum, an SPV wallet. In one of the exercises, I signed messages that I will not detail on this post for a number of individuals. These were not messages that I personally selected, but rather ones that other people had selected. In some instances, we ensure the integrity of the process by downloading a new version of the electrum program, installing it on a fresh laptop that has just been unboxed having been purchased that afternoon and validating the signed messages on the new machine.

The version of electrum that I run is on Centos Linux v7 and runs via Python. For the exercise I noted above we used Windows 7 and Windows 10 on different occurrences.

That strongly implies to me the demos are nearly the same, only with a few necessary details changed. You can even see him happily describing which operating systems he has tested his trick on. Amazing!

The sniff test

Many will say that the only thing that matters in this situation is math. Move coins or GTFO. Sign with genesis block or GTFO.

I agree, but I would also pay attention to what Wright is saying and doing. What if we hadn't figured this particular trick out? I will argue that we already had plenty of evidence suggesting Wright was a fraud:

• Wright tried to edit old blogposts to suggest he was involved in bitcoin (God faking his own miracles again)
• Wright has lied about his degrees
• Wright makes fundamental errors describing the core algorithms in Bitcoin

Just look at his attitude. Satoshi spent years in hiding (and practically disappeared from all communication in 2011). Wright says he wants to be left alone and gives interview after demo after interview. Going to conferences and subtly hinting that you invented Bitcoin is not an attempt to hide.

What's amazing to me is that many folks are convinced just on the basis of Wright being vaguely connected to Bitcoin since around 2014 or Wright giving a few winks and smiles in 2015. FFS, people. I was mining in 2011. I actually do have a Masters degree in computer science. That doesn't make me Satoshi. If that "evidence" is convincing anyone, well, it's no wonder that religions only a few decades old can be so sacrosanct...

It was obvious to me that Dorian Nakamoto was just a confused, old man.

It's obvious now that Craig Wright is just a confidence man. You don't need math for that, but it doesn't hurt either.

For my fourth entry into the Seven Day Roguelike Challenge, I decided to go big. Time travel. Hundreds of years of procedural history. Procedural maps and biographies. Someone described the idea as "Dwarf Fortress Lite." In other words, I was trying to develop a simplified version of a game that's been in development for 14 years in a week. And I wanted to add time travel to it.

It was a bit tougher than I expected. I came up with something cool, but failed in many ways. This post explains what happened.

Design

I got an idea after hearing Mark Johnson talk about his plans for Ultima Ratio Regum. He described a scenario in which you would try to hunt down an heirloom by figuring out who owned it and where they were buried.

Then Lord of the Rings came to mind. In LOTR, the one ring itself has a pretty convoluted story:

Wouldn't it be cool if you were tasked with tracking down the ring yourself? That's the idea: hunting down several legendary artifacts and using time travel to do it. That and simulating civilizations at war and NPCs living and dying and a bunch of other stuff.

The competition

Of course there are a boatload of time travel games, but most are extremely limited in their design.

Time travel is usually either limited to a narrative element (Bioshock Infinite), limited to a small time scale (3 days in Majora's Mask), limited to a VCR-like rewind mechanic (Braid), or limited to a small set of discrete time points (7 eras in Chrono Trigger).

I'm aware of very few, if any, big simulationist games featuring time travel.

The details

Now, how do we implement time travel? The simplest thing you could do is to save the entire game state whenever something changes. When you want to travel back in the time, simply load the appropriate game save. Going forward is even easier; just simulate the game for a given duration. Roguelikes are the perfect genre to implement time travel because the game only changes on discrete turns!

But even so, this naive approach falls down pretty quickly. By the time my game loads, it's already simulated 180,000 turns. Here's what the memory usage looks like if we assume a game save is only 1MB.

1 turn/day * 360 days/year * 500 years of simulation * 1MB save = 180GB

Uh oh. 180GB is nearly the size of my harddrive. Obviously, that isn't going to work. We need to prune the amount of data saved or compress it.

My solution was to only save variables when they changed and to track the changes individually rather than save the entire world at once. After all, I planned for most of the objects (monsters, NPCS, tiles, etc.) in the game to change only infrequently. Specifically, I used a stack for each variable. Each element on the stack has a time and a value. The current state of the world is represented by the top of each stack. Travelling to previous times just involves binary searching and truncating all stacks. For example, let's say you start fighting a monster at turn 1000. The monster's HP variable might look like this:

• {time:0, hp:100}
• {time:1000, hp:70}
• {time:1002, hp:50}
• {time:1003, hp:10}
• {time:1005, hp:0}

If we time travel to turn 1004, the stack only has 4 elements and we find that the monster has 10HP.

For another perspective, see this talk by Jonathan Blow on Braid's design. Blow stores the entire world state on every frame, with some clever optimizations akin to video encoding. I'm tempted to say they're similar approaches (at least compared to the alternatives), but I'll let you be the judge.

Honestly, this part of the time travel was rather easy to design and implement. There were more thorny challenges ahead...

Concessions

My game has a fairly large world consisting of about 1.5 million tiles, 1000+ monsters, and 500 NPCs in total. To simulate all of this over the course of 180,000 turns and do it in a reasonable time (15s on my machine) required some simplifications to the game world.

NPCs take up the bulk of the simulation, so I capped the total number of living NPCs to 100 at any given time. This solves one problem and creates another: with such small populations, it becomes harder to guarantee that each civilization in the game will survive for hundreds of years. More on that later.

Except for a dozen "bosses", I don't simulate monsters during time travel. Furthermore, the monsters never die of old age. You could imagine a game with monsters who reproduced, migrated, and died, but I didn't want to take the performance hit.

One optimization I considered was simulating at 5 year intervals instead of 1 day intervals. The idea was that events would still be slated to happen on specific days, but I'd only have to handle the simulation loop for 100 iterations instead of 180,000. Long story short: that idea was a total nightmare because it was nearly impossible to tell if planned events completed succesfully. I threw it out.

Paradoxes I could care less about

Perhaps the most mind bending part about time travel is the concept of paradoxes. There's the famous Grandfather paradox where you go back in time to kill your grandfather, but now you would never have been born and never able to travel back in time. Thus paradox.

I quickly decided that I didn't want to deal with paradoxes. I decided to use the Parallel Universes cop out and say whenever you travel it's always to another universe.

However, in a weird coincidence, there were two other time travel 7DRLs this year and they both focus on paradoxes: Chronomaniac and Timegame.

The week

Things were already off to a bad start as I woke up sick the first day. Ugh! It only lasted 24 hours, but I spent most of the day with severe brain fog.

ASCII: "It'll be so easy"

I've wasted a lot of time on pixel art in years past, so I thought making an ASCII roguelike would save time. Unfortunately, I was rather confused about how to proceed. I didn't even understand where I would find the glyphs common to ASCII games, but I was pointed to Code Page 437.

That sounded great, but I couldn't find a good web font for it. Some fonts had inconsistent sizes (totally defeating the purpose of a monospaced font). After finding a decent font, I realized Chrome was rendering the fonts blurry in the canvas. I finally gave up and decided to render images (stolen from the amazing REXPaint program). All told, I wasted more time on font rendering than I did on a time travel proof of concept!

At least my screw ups were beautiful in ASCII.

World generation

This part went swimmingly. I got my hands on some noise using rot.js. I quickly added a couple gradients, combined it with the noise, and used the resulting heightmap as my world map. World generation took a few short hours.

Random number generation

As I said earlier, the kernel of the time travel mechanic was pretty easy to implement. But the devil is in the details. I had a simple constraint in mind for time travel. If you travel from year 500 to year 400, leave no trace, and then travel back to 500, things should be exactly as you left them. I specifically wanted to avoid an inexplicable "butterfly effect", at least if the player didn't do anything substantial in the past. I needed to repeatedly run a simulation involving random numbers and have it turn out the same way. So I kept track of the RNG state on each turn and reloaded it upon time travel. And I had to keep separate random number generators on hand for different purposes (simulation, combat, and rendering).

Even after that, I was plagued by the dreaded butterfly effect throughout the challenge. It would go like this: I would code for a couple hours, then realize that I had somehow introduced the effect, and then spend the next 4 hours ripping my hair out trying to figure out how to fix it.

Sometimes I forgot to reset stack variables. Sometimes I, very stupidly, put some generation code before the RNG was first seeded. However, the most pernicious bug (one I saw many times) was not resetting temp arrays. You see, some of the variables in the game are too unwieldy to save in the same manner as other data (e.g. an array of living characters). In many cases, I was recalculating these arrays after time travel and still having a problem. The cause? The arrays didn't necessarily maintain the same order! Ugh! So I spent a lot of time tracking down variables that needed to be sorted after time travel.

One thing that really helped was a unit test that would perform the repeated time travels and check to see that the world state was the same both times. I coded it late into the project, but it was a big win.

The RNG woes didn't stop there. I also ran into a problem with a lazy loading of tiles. I didn't want to generate all 1.5 million tiles in the game at once, so I tried generating them only when you first see them. But that alters the RNG. To fix this, I pregenerated RNG state for each tile at the beginning of the game.

In hindsight, I probably should have let the "butterfly effect" requirement go. Despite annoying the hell out of me, I very seriously doubt anyone would notice.

Pathfinding surprises

Late on the 5th night, I ran into another big problem.

It helps to know that the crux of my game is about NPCs going on adventures. They travel from cities to dungeons hundreds of tiles away. They descend through the dungeon all the way to the bottom. At the bottom, they try to fight a boss. If victorious, they return all the way back to their city of origin.

I was using rot.js and its A* implementation for pathfinding. I've used it before without issue. That night, however, I was asking rot to pathfind a distance of ~1000 tiles and rot was visiting over 4 million tiles to do it.

WHAT

THE

FUCK

At the time, I decided to stay up until 3am writing my own pathfinding code. It was a really dumb idea, considering that I could have fixed the rot issue with a couple lines of code. In fact, after the challenge was over, I did just that and submitted my first pull request. And it was accepted! :D

I wrote more about the pathfinding issue and created a little demo here.

Civilization is also hard

Part of the world simulation involves 4 distinct races/civilizations. They fight each other for territory on the world map. Within each civilization, NPCs are born, get married, have children, wander around, go on adventures, and die. I had all sorts of hilarious problems with this.

• I didn't realize how much junk would get stacked up after 500 years of NPCs dropping items on death.
• I forgot to prevent NPCs from marrying the dead. No kidding.
• Civilizations kept dying out.

For that last one, I realized I had put too many restrictions on the NPCs. They had to be married to have children and I didn't feel like coding second marriages. Thus, the solution was a REFORMATION. No, seriously. I had to allow NPCs to get divorces and get remarried after their spouses died.

Aftermath

Because the end result was much less than what I imagined, I came close to calling this year a "failure." But I had a working game with a lot of stuff going on and so I submitted it. I polished it up over a few versions and have come up with something that I think is really fun and interesting. And yet...

While I did get a lot of positive feedback, most players could simply not figure out what the hell was going on. Almost every aspect of the game, especially the time travel, was misunderstood.

Part of that is me. I'm really bad at making intuitive games. I've failed at it time after time and it's been a consistent piece of feedback. Honestly, it pains me to have to spell things out for the player, but I'm not kidding myself here. I know I have to get better at making things that people can understand.

At least part of the confusion can be attributed to the fact that time travel is just really confusing. Anyone who has seen Primer knows that. Recently, I watched the latest GDC Experimental Gameplay Workshop. One of the developers was Chris Hazard. He's from my alma mater (go Wolfpack!) and made a crazy time travel RTS called Achron. Achron seems like one of the most interesting time travel games ever made and yet it has a 54 on Metacritic. The poor reception was due to incredibly confusing mechanics. During the GDC panel, Dr. Hazard shares a new game he's working on with the goal of "making time travel more simple." It's called "Plosh" and can be summarized as a time travel Bomberman. But despite the stated goal, I was struck by how confusing it still was. I had absolutely no clue what was going on. I hope I get to figure it all out one day.

So to summarize: time travel is fucking hard.

See for yourself by playing my 7drl entry, The Only Shadow That the Desert Knows.

It's easy to think, from moment to moment, that not much has happened recently. A moment of reflection disputes that notion! I did a lot in 2015 and I want to remember it. So here goes this post. Maybe you'll find it interesting too.

Game Development

I've participated in game jams every year since 2013, mostly focusing on the Seven Day Roguelike Challenge.

This year I wrote Dumuzid, a weird little roguelike about absorbing your enemies and become huge. Over a thousand people have played Dumuzid and it was well received (tied for 4th place out of 128 games in the review process).

Shortly after 7DRL, I drove to Atlanta for the first IRDC (International Roguelike Development Conference) to be held in the states. I had an absolute blast and did a little write up here.

Finally, I spent most of 2015 attempting to get my game, Golden Krone Hotel, approved on Steam Greenlight. At times, I was very pessimistic about my chances. There were tons of developers claiming that "they let anything in" or that the whole process is a cakewalk. It sure didn't feel like that when my campaign was getting barely a vote a day for months at a time. But 194 days after I launched the campaign, it was greenlit! This is a big deal to me. I never dreamed I would be able to put a game on Steam. Now I just have to finish the damn game. The plan is to launch into early access sometime in 2016.

Graduation

In December 2015, I completed a Master of Computer Science degree that I've been pursuing one course at a time for 4 and a half years. The icing on the cake is I somehow managed to keep my 4.0.

Phew.

The degree was nonthesis, so just advanced coursework. Highlights include:

• Artificial Intelligence My first course in Fall 2011. A great course and a great textbook. It inspired me to participate in several AI challenges.
• Performance Modeling (Markov Chains, Queueing theory): The hardest course I've ever taken by far, but I stuck with it. It assumed a whole lot of advanced probability knowledge that I don't recall learning anywhere. I took it over the summer too, so the pace was increased. I think this was the only time in grad school where the mean exam scores were in the 60s.
• Human Computer Interaction Very interesting course and I made a cool little prototype for a bizarre calendar app.
• Advanced Data Structures/Advanced Algorithms Two courses with huge breadth and excellent professors. The material was all very interesting (B-trees, bloom filters, etc.), but I find it somewhat funny that most of the advanced algorithms we covered were invented in the 1970s.
• Compilers/Operating Systems Just some courses that I missed out in undergrad because I did electrical/computer engineering instead of computer science. Now that I have these under my belt, I feel like a real computer scientist. I'm only half joking here...

Games

I won over $1,600 by playing a real money gambling game called Cordial Minuet (some of it was in last week of 2014 but who's counting?). I made a lot of content about the game:

• I wrote a post about my winnings.
• I made a twitter bot to track games and player profit
• I wrote a strategy guide
• I put together a rather unique split-screen video covering several rounds, so you can see the game from both sides.

Honestly, most of the intrigue in the game was inspired by a single player, JUDGE DOORMAN. That's where I got most of my money and where the vast majority of Cordial Minuet's in game economy came from (he put in over $10,000). It's fitting that, on one of the last days of 2015, DOORMAN entered into a gentleman's agreement to play an opponent until one of their accounts was emptied. DOORMAN lost.

Her Story came out and I was absolutely fascinated by it.

Mushroom 11 was pretty cool, but incredibly difficult. The art direction and setting were really top notch.

Regarding roguelikes: I played Caves of Qud and Sproggiwood (both by the same developer) for the first time. I highly recommend both. I also ascended for the second time in DCSS after 8 years of play.

And I put way too much time into League of Legends. I'm really bad at the game, but I just wanted to climb out of Bronze (the lowest tier). I practiced, played new champs, and got up to Silver II (a stone's throw from Gold!).

Miscellaneous

I typically don't go out of my way to see live music (having a bit of social anxiety), but I stepped out of character and went to a 3-day music festival called Hopscotch. I hadn't heard of hardly any of the bands there, but rather enjoyed Bully, Pusha T, Father, and Boulevards.

My wife and I went to Las Vegas for the first time! We went to see the Hoover Dam, got the Fat Burger, rode on the world's tallest ferris wheel, and my wife even painted with dolphins (I had no idea that was a thing).

I don't typically dress up for Halloween, but when I do I take it very seriously. I shaved my head (not the first time I've done so for a costume) and spent most of October on a 1700 calorie diet. All so I could be shiny and chrome for one night. Definitely worth it. On that note, Mad Max Fury Road was easily the best movie I saw in 2015.

What a year, what a lovely year!

Bzzt bzzt. It's 2am. Groggy and confused, I fumble around in the dark for my phone. On it is a single cryptic message:

BIRD GRADUATION whomps JUDGE DOORMAN for $19.

WTF? Who sent this message?

I did actually. A Twitter bot that I wrote is currently scanning leaderboards and letting me know that my prey is on the move. I sneak over to my computer. The bright light is blinding, but my eyes relax when I open the game client, a solid black 666x666 window. It's a portal into, as the game's designer says, endless riches.

Though my eyes are relaxed, my heart is pounding. I've already jumped into a game. It quickly becomes clear that JUDGE DOORMAN is not screwing around this time. I watch as coins fly across the screen over and over: a challenge that I reluctantly, but repeatedly accept.

It only takes a couple rounds before I decide to go all in. My hands are shaking as my mouse hovers over the "Commit" button. I think to myself, "This click could cost me $200."

What the hell was I doing?

Rock, Poker, Satan

Most games are invented, but some feel like they are simply discovered. I'm reminded of the following quote by Emaneul Lasker:

The rules of Go are so elegant, organic, and rigorously logical that if intelligent life forms exist elsewhere in the universe, they almost certainly play Go.

The game I described earlier is called Cordial Minuet and it seems to fit in the latter category. It's a real money gambling game with absolutely no element of luck. How is this possible?

Take the "mind reading" element of Rock, Paper, Scissors. Then take the betting elements of poker (betting here is similar to Hold'em). Mix them together and apply the result to a unique mathematical object called a magic square. That's Cordial Minuet. Explaining the rules in text is painful, but a 3 minute video will do the trick just fine.

The interesting mathematical properties of magic squares have a direct impact on the gameplay:

• All rows/columns have different variances, but the same sums/averages. This is good because your columns are analogous to your "hand" in poker.
• In the case of Cordial Minuet, its 6 rows and 6 columns each add up to 111, producing a total of 666. You can start to see where the game gets its occult theme from...

This means a level playing field for both players. There are no bad hands. Only bad plays. And since the game is not "subject to chance," Cordial Minuet's designer Jason Rohrer is confident that the game is perfectly legal. Better yet, since it's a 2 player game, Cordial Minuet is totally immune to collusion (a problem that poker sometimes suffers from).

All of this is packaged together in a bizarre occult/demonic theme (the game's title is, as you might have guessed, an anagram of Demonic Ritual). Your experience with the game ranges from a sketchy-as-hell teaser site to public leaderboards with aliases derived from two "evocative nouns" (that's where JUDGE DOORMAN and BIRD GRADUATION come from). And before you run off in terror, just note that: the game is open source, Rohrer ran a bug bounty, and payments go through Stripe. That's worth something, right?

I hope I've piqued your interest. Maybe you'll stick around to hear how I made a 15,000% profit over the past few months.

Up and to the right

Over Thanksgiving last year, I was vacationing in Asheville, NC. That's when I decided to type my credit card number into this weird game. I'd grab a BBQ sandwich from the nearby food truck and then walk back for some 1 cent games. Those games were UNBELIEVABLY TENSE. Beach bingo and the occasional slot machine don't prepare you for the pain of losing your hard earned money to another human being. Because you suck.

But I kept playing and I got better. So good that I won Cordial Minuet's first tournament a month later. By that time, I had already quadrupled my investment through regular games and a $200 prize didn't hurt either. I was so happy that I decided to write a strategy guide.

Now I had a problem. The other players were getting good too! It was becoming harder and harder to profit. I needed a newb. A fish. A whale. Enter Judge Doorman.

The player known as Judge Doorman arrived on the game's forums and claimed to have intentionally lost $500 in a single night. If only I could get my hands on that money! I posted on the forums that he should contact me if he wanted a game. He did.

Doorman's real name was Cayce Ullman (you can read the story of his encounters with another player here). Ullman was an interesting character: a programmer and a serial entrepreneur. He helped create the popular application Plex. This guy was no dummy. In fact, Ullman wasn't a fish at all. Yes, he was brand new to this game, but he was also a seasoned gambler. When he told me how much money he'd blow on a single poker hand in Vegas, my jaw dropped. In order to maintain his interest, I'd have to play larger stakes. First $10. Then $20. Up and up until I was playing hundreds of dollars at a time. Even then, he'd raise aggressively, increasing the pot from $2 to $20 whenever he could. And though he might have been intentionally losing at first, he wasn't anymore. It was nervewracking. Hello Loss Aversion, my old friend.

The way I won was simple. In the face of this aggressive betting, I would just fold until I got a good opening. This didn't guarantee a win, but it worked on average. It worked so well that after the first few games I felt guilty and explained exactly what I was doing. Things got harder then and Ullman got better over time (see a pattern here?). Even the rules changed to prevent such easy wins; now antes increase over time, making a conservative approach much more difficult.

Ullman and I kept playing, though I had a hard time following his hours. That's where my Twitter bot fits in. I used the data from that bot to not only track certain players, but also to create personalized profit graphs, and even to investigate the mysterious case of Cordial Minuet's first bot.

So that's my story. And if you're thinking that you missed the boat, you're wrong. Cordial Minuet was just released and thousands of dollars in cash, silver, and gold (seriously) are being handed out in the launch contest (not to mention all the money you'll win from other players, naturally).

If you found this interesting, also check out my piece on Rohrer's previous game The Castle Doctrine.

Oh, and one last thing. If you're wondering what happend with that $200 game against Ullman in the beginning, well, I lost it. :)

I've done 7drl twice now. Recently I saw something about js13k. A JavaScript competition in only 13 KB? Sweet! JavaScript is my preferred language for this stuff, so why not?

Though not nearly as spartan as js1k (you're allowed to zip), the size restriction is still significant. Music, sounds, and sprites quickly push you out of the limit. And of course you're given only one month.

I ended up writing two games.

Mission

During the competition, I had seen this codepen. With a few tweaks, I figured it could be made more realistic and then decidely unrealistic, but awesome looking.

Basically, I had a planet generator and I needed to show it off. In MISSION, your goal is to find habitable planets and then convert the inhabitants to your religion. You're shown three planets at a time and you try to pick the one that looks the most habitable. I first imagined each planet having ratings next to them for four attributes:

• distance to star
• mass
• liquid water
• atmosphere

Then I realized I could represent each of those visually (e.g. you can see how big the planet is and you can see if it has water). You still see the ratings, but only after you've already selected.

The theme of the competition was the four elements and I tied the four attributes of each planet directly to those elements. Additionally, while reading about missionaries, I came across this thing called the Wordless Book and added in a reference to it (though hilariously I managed to misspell it). Hopefully, nobody is too freaked out by the overtly religious theme.

Once you stumble upon a planet with intelligent life, you still face a few challenges before you can start converting and you have to manage a few resources. The game is probably not well balanced. After all, I threw together the gameplay in a single night. But it certainly does its job of showing you a bunch of neat looking planets. And it's the first time I tried to target mobile devices (plus desktop), which appeared to work okay.

Particularism

Mission was sort of a throwaway. Instead, I spent most of the competition working on Particularism. Ostensibly, the game is a Tetris Attack clone. If you're not aware, Tetris Attack happens to be the best game evar!!! Totally unlike it's namesake, rows of blocks come up from the bottom of the screen. You swap blocks to make matches and try to chain them together to send gigantic "garbage" blocks to your opponent. Tetris Attack stars Yoshi and one of your opponents is a monkey that rides a dog. Yup.

In reality, Particularism is a rather serious game. I've wanted to make it for a while. The specific puzzle mechanic is a MacGuffin. It could be any mechanic, though Tetris Attack does hold a special place in my heart. As Particularism begins, the main character's father brings them a new game (Partic, as it were). You see, even though my dad was never really into games, when I was a kid we played a lot of Tetris Attack together and we kept playing it long after the SNES had been displaced by other consoles.

It's not even really about games per se. It's about trying to get good at something you care about, trying to stay focused on it in the short and long term, and the challenges and choices that naturally arise out of that.

Anyway, here's a few notes on hard to implement features:

AI

With a few simple behaviors (don't let blocks stack up on the right, try to make combos on the left), it puts up a decent fight. The AI is visibly dumb in a few cases, but makes up it for in raw speed.

Procedurally generated music

I thought for sure music was impossible, but this gist by Kevin Ennis was a life saver. Here's how I made it procedural:

• The tempo provides a lot of variety and simply increases each level to match a stronger AI.
• For each song, I select a handful of notes to use as a palette (with replacment, so that some can be more common). Silence is treated as a note too.
• I generate a couple bars of random notes and repeat those bars a few times.
• I repeat the above step like 5 times so you don't get bored, but keep the palette to maintain a consistent identity.

Not every song sounds great, but a surprising amount do. Hey, that's procedural generation for you. Plus the plodding square wave reminds me a lot of the 8 bit era. You can play with the generator here.

Pixel Art

There's different characters, levels, a set of 20+ emojis. I saved space by doing without animation, using small sprites, and keeping my number of colors extremely low. The majority of each level is painted using a floor tile, a wall tile, and some gradients on top.

Don't bring a drama to a comedy fight

I made a short film in college called Proxy. It was embarassingly bad, so I'm not going to link to it. It was made for a competition where you had to make a 5 minute film in 1 week (the similarity to a game jam has not dawned on me until this moment). At the end of the competition, dozens of films were shown back to back. This is the worst possible format to release a serious short film. We were all amateurs, so the sound on everything was awful and in my case they didn't turn it up loud enough to be audible. The start of one film was shown the second another ended, before any laughter or applause had subsided. That day made me understand why movies have opening credits. You need 5 minutes just to ease into the mood of a film. If you only have 5 minutes, just do a comedy.

Ok, so why am I rambling about this? I think I've decided a game jam is not a place to bring up a serious game. The audience, mostly other devs, and the judges have over a hundred games on display. It's like a stack of 100 resumes. Impress me quickly or you'll be in the trash. Hmm. Maybe I'm being cynical here. js13k was a hell of a lot of fun, but I think next year I'll do an action game.

It was 4:30am. I yawned as I climbed to the last level and conquered the final boss, FANE the EXILED VAMPIRE PRINCE. I didn't even know if the game was beatable until that exact moment. The game was Golden Krone Hotel and I had spent the last week making it for the Seven Day Roguelike Challenge of 2014.

Here are some numbers describing GKH:

• 10 floors
• 12 types of enemies
• 6 spells
• 5,612 lines of code

Lines of code can be a silly metric, but that number should give you a ballpark of how much I coded. It worked out to 800 lines per day or 1 line per waking minute. Wow!

What went right

1. Planning

Planning for the 7DRL challenge is immensely helpful. There's two areas that require planning: housekeeping and design.

This year, I didn't want to have to contend with work, so I took the week off. It sounds a bit extreme to take off a week of work from my programming job to program 10 times as much at home. But hey, I enjoyed it. I knocked out errands beforehand. I came to an agreement with my very understanding wife that I wouldn't be doing much. That week also turned out to be my spring break from school, which was a lucky coincidence. Blocking out an entire week from your life is strange; it kind of feels like "getting your affairs in order," but it works.

Planning the design of the game is worthwhile too. Some people prefer a tiny list of ideas, but I've always enjoyed making sprawling design docs. I usually open up a Google doc, brain dump everything I can imagine, and then conduct thought experiments about how certain mechanics will play out. The most important part though, usually written at the last minute, is a rough outline of features. I like to prioritize my list and group them into small "versions" so I feel like I'm making progress.

2. Graphics, sound, and music

My graphics last year were kind of ugly, mainly because I limited myself to 16x8 pixel tiles, chose a washed out palette, and refused to use outlines. This year, I went with 16x16 pixel tiles and was more liberal with the colors and outlines. The graphics have been the most praised feature, so I call that a success.

Making pixel art like this is easier than you might expect. I'm by no means "an artist" but I have tried my hand at pixel art before. My favorite tutorial to this day is still Tsugumo's So You Want To A Pixel Artist? series. Read it and you'll see that, rather than being an impenetrable mystery, there's actually a fairly straightforward process to making this stuff.

I made most of the sounds before the challenge using bfxr, which turned out to be pretty easy. There were some sounds I never could figure out how to produce (e.g. a door creaking), but what I did make sounded great to me. I debated about having music in game (music usually can't match the unpredictable pace in a turn based roguelike), but I was absolutely sure I wanted it on the title screen. I found incompetech.com to be a great resource and my mind was blown when I realized all the music there was made by one guy.

3. HTML5/JavaScript

Perhaps this is just a case of "use what you know." Not only do I feel comfortable with JavaScript, I can hack it together really quickly (please don't look under the hood though).

I'm not sure how performant the canvas is for complex real time games, but it's perfectly suitable for a 7drl. Getting to a character moving on screen takes very little code and the various APIs you need to do things like play sounds and save to local storage are unbelievably easy.

No downloads required and no fidgeting with missing DLLs or anything else. You have to deal with browser testing, but otherwise the web seems to be the option with the lowest amount of hassle. Compare this to, for instance, having to download python and pygame and then having to find the right command line arguments and then still having the game run unbearably slow because something was configured improperly; that was my experience with another 7drl released this year.

4. Fun mechanics

The most elusive component of creating a game is fun. The dust has settled and the mechanics in Golden Krone Hotel do appear to be fun.

As a foundation, simple roguelike gameplay is already pretty fun: bumping into enemies to attack, exploring, collecting items, etc. I was convinced of this while watching a video review of my game. As the reviewer starts to wrap up the video, he keeps commenting on how fun the game is while also repeatedly pausing his concluding statements to play for a few more seconds. All he was doing was bumping into enemies! So the idea here was not screwing up a good thing.

I found that adding a few simple twists didn't hurt as long as those things didn't become tedious. Burning vampires in sunlight is satisfying, but it only remains fun if you're not forced to do it. Switching between vampire and human is fun, but again I found that this was only fun for the player if they retain some control over the process. The game switches you automatically, but you're given resources that allow you to switch back. The game got a lot less fun when those resources were too scarce during testing.

What went wrong

1. The tutorial area

I thought I was being clever by making a little "tutorial" area. I'd educate players without slapping them in the face. I'd subtly hint at mechanics and let the player have the satisfaction of learning exactly how they worked.

Unfortunately, none of that happened. In the first iteration, I made a moderately sized tutorial section that required the player to use their starting spell to succeed. I watched an experienced roguelike player fail three times before I gave up on that idea.

I made a second iteration that was more obvious and only required the player to walk back and forth to succeed. But what I didn't consider was that the tutorial area was effectively on a timer. Since it involved directional sunlight, it was limited by the time of day. Players would turn a simple challenge into an unsolvable quagmire by loitering around for too long.

The final iteration was a tiny hallway with a single enemy and almost no way to mess up. It worked pretty well. The lesson? Apply Murphy's law to level design:

If the player is given the option to screw themselves, they will.

Don't get me wrong. Most players will still try to take on that one high level enemy hand-to-hand, even though they were told 10 seconds ago that vampires are highly susceptible to sunlight. But it doesn't matter: there's only one other thing to try! And when they do try it, they feel pretty clever.

Though I've received some positive feedback on the refined tutorial area, I'm still not sure it is worth keeping. Because that section is hand crafted, a large number of players assume the ENTIRE game is nonprocedural.... pretty much the worst outcome for entering into a challenge about procedural content.

2. Menus

I hate working on menus. I doubt I'm the only one. Frankly, every menu in the game is a big hack and the click handling logic is filled with bugs. Menus seem like a trivial detail, but when you watch someone spend 5 painful minutes trying to close a menu, you realize just how important it is.

Next time, I'll figure out a coherent system for managing menus and I'll do it much earlier.

3. Scope

Unless you have low ambitions, it's inevitable you'll have to cut features during a timed challenge. Not surprisingly, there were several features left out of Golden Krone Hotel. I had wanted to add potion crafting, super potions, themed dungeon branches, and mini-bosses. Of course, more enemies and spell would have been nice as well. I'm somewhat satisfied with the existing scope. The 10 levels and 12 monster types should keep someone occupied for quite a while. It even takes me around 45 minutes to beat the game (that's a single winning run).

But still I worry about the lack of variety in the existing mechanics and content.

4. Unclear mechanics

Bear with me. This final point requires a bit of unpacking.

The mechanics in Golden Krone Hotel are certainly fun once you learn them, but utterly confusing before that point. The thing is I genuinely thought the mechanics were clear.

The game is set in a tower. Stained glass windows on the outer wall of the tower normally block light, but they allow beams of light to pass through when broken. The direction of this light depends on the position of the sun. At 6am, the sun rises and shines on the east wall. At noon, it shines on the south wall. At 6pm, the sun shines on the west wall before finally setting. Think of it like a sundial that uses light instead of shadow. It seemed simple to me....

As time progresses, it should be clear the angle of light is changing deterministically. Not only that, but you're also given two UI elements that help describe what sunlight is doing:

1. The time of day
2. An icon that indicates which wall sunlight is currently shining on

In hindsight, there were several major obstacles to communicating all this.

Change blindness

I should have learned my lesson when players couldn't find out how to use the compass in my last game. They would pick up the compass, a cardinal direction would appear on the UI, and then.... nothing. They wouldn't see it at all. That UI element even changes as they turn around, but still they wouldn't see it. This is exactly what was happening in Golden Krone Hotel. Sure, information about sunlight was displayed, but users weren't paying attention to it. Or they paid attention to it occasionally, but didn't notice when it changed, so they didn't understand the significance.

Change blindness is a well studied phenomenon and, based on my experience, it should be one of the first things you consider when developing a user interface.

Mental models

People create mental models to navigate through the world (whether that's the real world or a game world). I need to accept that player's mental models don't necessarily match mine. When I plan out a drive, I often visualize an overhead map that runs north to south. The same goes for walking through buildings. Well, not everyone thinks like this. I once told a friend in college that I waiting outside the east entrance to his dorm; he had no clue what I was talking about.

I thought the overhead view of a level would map nicely to cardinal directions (down == south) and the movement of the sunlight would be easy to comprehend. But players probably aren't thinking about that. After all, most dungeon crawlers are just that: romps through subterranean caverns that never see daylight. Apparently, that model is deeply ingrained. The opening screen explains that game is set in a tower, but one player told me he first assumed the "pools of light" he was seeing were coming from overhead.

Miscellaneous thoughts

Be open to change. Sunlight was initially the entire core of this game, but it ended up being a relatively minor feature. That's OK! Instead of pushing that one feature on the player, I was able to add other interesting mechanics. In another case, I intended to use Zelda style dungeon walls (where you simultaneously see the sides of all walls). That turned out to be way too complicated to implement and the traditional perspective I went back to was perfectly fine.

Worse is better. Time constraints led to several features being implemented with hacky, flawed algorithms: sunlight rendering, field of view calculations, torch lighting. For example, I was planning on using "the right" approach, Bresenham's line algorithm, before I realized the example on wikipedia only covers one of SIXTEEN cases. I thought about going back and fixing this stuff, but guess what? Not one person has even mentioned any of it. It was far more valuable to spend time on polishing the game than to worry about whether each algorithm was 100% correct.

Overall, I'm very happy with my Golden Krone Hotel and I'd love to hear your feedback!

In a few days, the Seven Day Roguelike Challenge of 2014 (7drl) will begin. You might want to pay attention even if you have no interest in developing games. Because in a couple weeks there will be literally hundreds of neat little games popping into existence. All new. Some quite good and original.

You should really make your own game though!

Jams, huh?

To be honest, I used to think game jams were kind of worthless. They seemed to produce a lot of incomplete junk. When Jonathan Blow started talking about his distaste for game jams, I was further convinced there was nothing to see.

Then last year I decided to participate in 7drl on a whim and it was beyond awesome. For someone who has dreamed about making games for many years and yet never got past the fucking around with prototypes stage, it was immensely satisfying. I made a game that got a lot of positive feedback. One person said the "game's atmosphere and mechanics made it immensely compelling;" another said that "it strikes a perfect balance between survival sim and roguelike." I'm not trying to boast. I just never would have believed that I could go from nothing to creating a work that elicited that kind of feedback within a single week. Something about the short deadline and the knowledge that others were doing the same in parallel motivated me to do something I failed to do for years.

And of course I found plenty of fun games to play.

MVPs

The top rated games to come out of 7drl 2013 were great. What shocked me though was how some games made in the 7drl were later turned into polished products.

Hoplite is probably the best game I've ever played on Android.

868-HACK (originally 86856527) is brilliantly designed and has amazing replayability. After writing a bunch of critically acclaimed games and receiving lackluster sales, developer Michael Brough wrote this game for last year's challenge, later charged $6 on the app store, and sold over 6000 copies.

It sounds like one game that started in the 7drl, Quadropus Rampage, even saved a struggling two-person indie studio from bankruptcy.

Sure, these games were polished after the challenge, but the core was there within a week. The developers had minimum viable products that they could get tons of feedback on quickly.

Why roguelikes

Why should a programmer care about 7drl? First consider the history of Rogue and its descendants. Here's Jon Lane discussing Rogue's influence:

"Two things made me think that this game could be a commercial success. The first was that when I was running a network-wide analysis of system usage we found that Rogue was burning more CPU cycles than anything else. The second was that Dennis Richie, of UNIX fame, was quoted as saying that Rogue wasted more CPU time than anything in history."

Then consider that, by definition, roguelikes are a programmer's dream game. The bulk of effort that goes into most games has to do with asset creation: making art, making music, writing content.

For roguelikes, art is optional. You are practically encouraged to use ASCII. Music is optional. Sound is optional. Detailed text isn't usually present.

Content is made procedurally. Systems are front and center. The way you make a roguelike fun is through game mechanics. That means, among other things, clever algorithms, smart AI, and carefully balanced stochastic processes. Naturally, the replayability of fun mechanics makes it quite easy to outlast nice looking assets.

Now, about those excuses

You have no idea how to make such a complex game, right?

Wrong. Plenty of well received games from last year had unbelievably simple mechanics. One example is Nya Quest. It focused on a single directional facing gimmick and it looked like this:

And yet it was rightly praised for being fun. It was rated in the top 20% in fact.

Finally, you're going to say you don't have time. I understand.

"If we did all the things we are capable of, we would literally astound ourselves." -Thomas Edison

You'd be surprised at how easy it is to draw something on the screen that moves around. A simple game isn't far off from that.

You know, there's a 0 hour game jam (the 1 hour shift during DST) out there and people actually manage to make games during that. Surely with 30 hours (a dedicated weekend) or 100+ hours (a dedicated week) you can come up with something worth talking about.

I can't wait to talk about my game. :) It's going to be a ridiculous game about vampires. Here's a small teaser:

todo: make game

I'm going to vent on some personal stuff. Feel free to skip below if you want the technical bits.

Personal

Twenty twelve was a string of nerve-wracking events. The defining moment was in August: one of our dogs was finally recovering from a grapefruit-sized gash in his chest (he had cut himself on some scattered construction materials at a park). My wife and I were determined to buy a house so that would never happen again, but the seller was inexplicably delaying on agreed upon fixes; we weren't even sure if we could keeping staying in our apartment. A week before closing, I woke to a frantic phone call: "Your wife's hurt." Turns out, she had only broken a leg, but that would lead to even more horrors (always remember that a broken leg can kill you).

All that considered, 2013 nearly takes the cake. My wife was diagnosed with Cushing's disease this spring. Believe it or not, that diagnois was profoundly cathartic. We've been trying and failing to get someone to take her symptoms seriously for years. And yet you never want to have a conversation with a doctor that ends in the words "brain surgery." To make a long story short, the surgery was successful and she is recovering very well. I'm quite optimistic about the future.

Through the stress, I didn't always take care of myself. I've been self tracking for the past 5 months and noticed that my drinking has increased: an average of about 2 drinks per night. That average is actually within accepted dietary guidelines, but it doesn't consider outliers. And there were outliers. Between a few bad experiences and a general malaise caused by drinking, I'm making it a resolution to cut down drastically on the booze.

Having said all that, I was fairly productive in 2013. I reached the halfway point in my Masters degree, maintained a 4.0, and got to dabble in a little R. And I built a few things:

Vulgat Library

This was an enterprise media library I had initially written for Epic Games. It's useful if you want to let employees borrow books/games and you want to have a hope in hell of tracking them. The coolest part is that it integrated with Amazon's Product Advertising API. You scan a UPC and it loads an image and details instantly.

This year, I packaged it up and sold a license to Irrational Games. It was pretty cool receiving a check in the mail from Irrational the same week I received Bioshock Infinite. In the excitement, I probably added more formality then was necessary: I wrote my first EULA and started my own LLC.

The lingering question is: should I continue developing Vulgat Library? This is the only side project I've worked on that seemed to address pain points. However, I still wanted to make sure my two paying customers weren't flukes. So I did what everyone recommends: create a landing page to collect emails and gauge interest. With no other way to market it, I tried Adsense and.... my ads were promptly suspended. Huh? Apparently, Google has a lesser known policy:

Google allows sites that collect personally identifiable information from users as long as this is not the primary purpose of the site.

My landing page was dead in the water. This "collect emails with a landing page" advice is still thrown out nearly every day on Hacker News, yet I have no clue how anyone pulls it off. So far, I appear to have collected exactly one email address.

A False Saint, An Honest Rogue

Write a game in seven days? It sounded nuts. I had a lot going on (school, work, etc.) and I really didn't have the time. But when I decided on a whim to do it, I was giddy. I coded more in that week than I ever have. I coded in the car, in the bathroom, early, and late into the night. I wrote everything from scratch in JavaScript.

The result was a brutal, but beatable survival roguelike: A False Saint, An Honest Rogue.

It's a game about getting lost and freezing to death. The game included a day and night cycle, dozens of randomly generated items, and a robust layerable clothing system. Not everybody's cup of tea, but it did get coverage in Gameological, RPS, and two Let's Play videos. Free Indie Games even included it in their list "Best of 2013: Roguelike-likes." I couldn't be happier!

I have to say, roguelikes are a programmer's dream. Artwork is optional, content is randomly generated instead of tediously hand designed, and systems are front and center. 7DRL 2013 was an absolute blast. Don't miss the next one.

jere.in

Static site generators are all the rage and programming in the twenty-first century sold me:

The most unexpected comments have been about how quickly this site loads, that most pages involve only two requests--the HTML file and style sheet--for less than ten kilobytes in total, and that this is considered impressive.... I've also got a clear picture of how people interact with a blog: they read it. With the sole exception of myself, all people do with the prog21 site is grab files and read them. There's no magic to serving simple, static pages.

It's true. There is no magic! If blogs are humans, plain text files are their chimpanzee cousins, 98% similar. Markdown easily makes up the difference. So I wrote my own generator. The generator is a single ~300 line PHP file and that includes all of the shared HTML/CSS. It runs Markdown; creates the posts, pages, and archives; and assigns both short and pretty URLs. I use the AWS SDK to upload to S3. It's dirt cheap, fast as hell, and I love the minimal design.

Some notable posts this year include:

• Sneaking into Rohrer's Castle: A three piece article on the game The Castle Doctrine.
• Why You Should Play Fantasy Even If — Especially If — You Hate Football: surprisingly, this was the first thing I've written to hit the front page of HN.

Autumn.js

Autumn.js is a JavaScript library for hashing keys into colors. It's one of those things that seems like it should be two lines of codes (it initially was) and then a hundred wikipedia articles later you realize it's not so simple.

I've already found it helpful on several projects including...

LetsPaste

Here's a dumb idea. Create an image sharing site to compete with juggernauts like imgur. Don't create a plan for revenue. Don't have a plan for getting users. Enter LetsPaste. Well, it seemed smart at the time.

Here's what happened. I noticed there were no sites dedicated specifically to gaming screenshots. The places where developers were sharing screenshots had awful UX. Here's the clicks required to view an image on Twitter:

1. Click on the image. It's no longer cropped, but it isn't full sized yet either.
2. Click on the image again. You get the full sized image, but now you can't see any responses.
3. Click on the close button.

That sucks. The vision behind LetsPaste is a site that makes pixel art and gaming screenshots first class citizens. Full sized images right off the bat, inline comments, and image scaling with crisp edges (tomorrow starts 2014 and Chrome is still buggy on crisp edges).

Honestly though, it's not yet compelling enough. And there's no straightforward path to making it compelling. The response has basically been "how is it better than imgur?" Fair enough. If anything, I've learned that it's better to fail fast than trudge along pointlessly.

Minor projects

whereisedward.com When Edward Snowden seemed to be flying to a new country weekly, I thought this site would be hilarious. I didn't know he'd be in Russia for the next six months. Oh well, another dumb idea. BUT! It's OK because I entered the domain into the Web Domain White Elephant Exchange. In return I'm getting (and I'm not making this up) getwinky.com. I'll have to do something with it in 2014, but what?

johnareid.com and mammalia.us: Basically Wordpress tweaking, but I really like the way they turned out.

meaningless internet points: According to HN Karma Tracker, I recently broke into the top 1000 users by karma. Derp.

2014

Next year, I want to focus more on building things people actually need. I've gotten close this year (maybe closest with Autumn). The process of "cool idea"->"start hacking" has resulted in many bizarre projects. Good for learning, but I'd rather be helping people and/or making paper.

Also, I'd like to contribute to some open source projects. The thought kind of terrifies me, but that's why I need to it.

Happy New Year!

Honestly, I've never been much of a football fan. I couldn't even tell you all the rules. I only go to a football game if it involves first and foremost standing in a parking lot for hours (thus the walk to the stadium is best described as a vision quest).

The average person, however, seems to have a strange obsession with American football. Talking with these people becomes increasingly difficult as football season approaches. The solution? Enter a bizarre computer simulation called Fantasy Football. With very little effort (and absolutely zero time spent watching grown men throw around a dead animal), you'll be able to disguise yourself as a true fan. A sheep in wolf's clothing if you will. The icing on the cake is getting to kick everyone's ass. Doing it without knowing the first thing about football is the ultimate form of trolling.

For this post, I'm going to make a couple of simple, reasonable assumptions.

1. there exists only two types of people in this world: jocks and nerds
2. you're the latter

It's closer to Final Fantasy than it is to Football

You might think Fantasy Football is complicated and requires in depth knowledge of football. As it turns out, it's nothing but a simple video game. Min-maxing at its finest (maximize points; minimize everything else). And it's hilariously similar to some of the nerdiest games you've ever played. For example, read the following description of a game and tell me what X is.

• players collect X and form them into teams
• players progress through a series of battles in which their X fight against another player's X
• the X have "stats" which get better through experience
• the X can become injured and must be removed from battle
• the X can be traded between players

X could just as easily be football player as it could Pokémon.

Besides the name, Fantasy Football also has a lot in common with Final Fantasy. Both involve populating a roster with a limited number of participants. There are six position types in Fantasy Football and six classes in the original Final Fantasy. When I can't remember what a quarterback is supposed to do, I like to pretend my QB is a Black Mage. It makes things a lot more interesting.

It gives you just enough understanding to feign having a clue

You know that conversation. You're at the office minding your own business. A burly coworker walks by with a grin and says:

coworker: HOW 'BOUT THAT SAINTS GAME?

you: ...

You can try to ignore that awkward silence, maybe wait for the topic to change. But don't kid yourself. The time from preseason to the Super Bowl is 6 months out of the year. With Fantasy it's totally different:

coworker: HOW 'BOUT THAT SAINTS GAME?

(mental check: I have a Saints player, Drew Brees -> Brees has a very big number next to him -> Brees's performance must be a worthwhile talking point)

you: BREES BLEW IT UP... REALLY DOE

Seems ridiculous, but it's really that easy. See, there's something like 1500+ players in the NFL, but nobody cares about the bottom 95%. You only need to know a handful of names to avoid appearing completely clueless. It's kind of like learning a new language. Learn the names of a few super stars (most of them will be on your team after all) and you're ready to go.

Football is bad for you; fantasy isn't

I'm not making this up. Football is bad for you. It's bad if you're a player. Apparently, repeatedly smashing your head against and between 300lb men is bad for your brain. A recent book/documentary, League of Denial, explores the link between football and traumatic brain injury. The results are quite disturbing.

Things don't get much better for fans. Being a fan to a losing team makes you feel lousy and prevents you from making healthy eating choices. On average, denizens of cities with an NFL team eat 10% more calories on the day after a loss.

I highly doubt the same applies to playing Fantasy Football. You shouldn't have much of an attachment to a grab bag of virtual players. But even if losing at FF did affect you, it wouldn't matter because...

You're already good at it

Last year, I played FF for the first time and won.

I'm well on my way to winning a second time. Anything could happen, but I currently have the most points in my league. Why? Well, I drafted the best player (by projected points) in each of 4 position types. And there are only 6 types in total.

I started the season with:

• The best WR, Calvin Johnson aka MEGATRON
• The best TE, Jimmy Graham
• The best DST, Seattle Seahawks
• The best K, Blair Walsh
• Also, the 2nd best QB, Drew Brees

That should be impossible. I'm playing with 7 other people. Drafts occur in order and each person should have drafted, at most, one of the best players. But I got 4. How the hell did I get away with it?

To make a long story short: football fans have biases, developed and hardened over many years. If you don't have those biases, you're already ahead. Fans have favorite teams they root for and teams they hate with a fiery passion. They have biases against individual players too. Take Tony Romo for instance. I've heard for years that Romo is a bum. I've been told he has a tendency to often "choke" at the end of games. Here's Jim Norton:

Tony Romo is a bum. He's like the guy who drives well all day and then runs over a kid in his own driveway when he gets home.

I don't know if this choking thing has any basis in reality or, like clutch, is mostly superstition. All I know is the numbers. After several games, Romo is the #6 quarterback by points. That's pretty damn good for my backup QB! Which brings me to a related point: winning in football isn't the same as winning in Fantasy. Romo could lose all of his games, but it wouldn't necessarily matter. Sometimes players are mediocre in real life, but their actions translate to massive points in FF. Fans are going to watch games and end up focusing too much on real football.

As a nerd, you probably have a slew of other advantages: you're less susceptible to fallacies like sunk costs, you're good with numbers, and you like to geek out on things. Now don't get me wrong. If you wanted to, you could get by with checking your roster once a week.

But I know you. If you just try it once, I guarantee you'll be checking expert rankings, running stats, and obsessively refreshing espn.com in no time.

I wrote about Autumn in my last post. At the end, I mentioned jokingly that I had made Autumn into a bookmarklet. I call it Autumnify. All it does is call Autumn on every element (i.e: $("*")). The results are definitely silly and obnoxious. Autumnify turns the cleanest page into a a real horrowshow:

But after using it for a while, I noticed this thing has a few legitimate uses (skip to the end if you want to try it).

Structure

Autumnify immediately reveals the underlying structure of a page.

I bet there are other tools that do this (simply putting red borders around elements will get you halfway there), but Autumn is specifically designed to generate colors that are very distinguishable. So most of the time parent elements are going to stand out from children and siblings are going to stand out from each other.

Autumnify was a quick byproduct of something I already doing, but I do wonder if there is a simpler way. We know from the map coloring problem that only 4 colors would really be needed to distinguish all the elements on a page, but I have a hunch that's not a trivial problem.

Complexity

If the markup on a page is convoluted, you're going to know it. Simple markup, however, almost looks like an expressionist painting. It's nothing to write home about, but I tried making the HTML on this blog fairly simple:

Asynchronous content

Once you Autumnify the page, it's easy to point out newly loaded content. If the page uses hash-based navigation, it's easy to tell what's being preserved and what isn't. On Twitter, for instance, you can see how new tweets stand out, obviously. But less obvious is that while navigating between tabs most of the content is kept around, yet the "Trends" container always refreshes. All you have to do is look for white backgrounds:

It's ridiculous!

Frankly, it's just a lot fun making your favorite site look like the million dollar homepage.

You can try it out by clicking on the link below. If you like it, drag the link onto your bookmarks bar. For reasons I haven't figured out, it doesn't seem to work well in Firefox.

Autumnify

And here's a version that makes all text white for a little better readability:

Autumnify (white)

Just make sure you don't shoot your eye out.

According to Betteridge's law of headlines, the answer is clearly no.

But seriously. The front page of CNN groups most of its articles into topic bins with colored headers.

It's a common design pattern among news sites. The color acts as a visual cue. It helps readers jump directly to their favorite topics. You like Tech? No problem. Red->Tech.

On CNN, however, only half of the 20 topic bins have colored headers. The rest are the same dull grey. Why? If I happen to like Sports, don't I deserve a color too? I don't know how they arrived at this design, but here's one way it could have happened:

1. CNN brought in a top notch designer to handpick colors for each topic. Great choice.
2. Over time, new topics trended and old ones faded away. Wait... it's 2013 and Britney Spears is a still a thing‽
3. CNN didn't want to bring in the designer and and redeploy code every time Anderson Cooper giggled. That designer guy was a pretentious jerk, anyway. And they certainly couldn't let the devs choose colors. Thus, grey.
4. ...
5. Profit

I'm sure the reality was less dramatic. Perhaps CNN was perfectly happy with only 10 colors. Or maybe it has to do with the uncolored topics being mostly sponsored links (hilariously, there's a Bleacher Report bin even though the Sports bin points exclusively to Bleacher Report articles). On the other hand, it would probably be smart to make your sponsored content look identical to your real content.

Regardless, the above scenario could happen if you tried to design a similar UI. The ideal method of course would be to handpick colors, but when you're working with dynamic content (with no bounds on the number of records) that's just not feasible.

Autumn.js

To solve this kind of problem, I recently wrote Autumn.js. It's a small jQuery plugin that colors elements deterministically. It has a few advantages over handpicking colors:

• You don't need to store colors in code or in a database.
• You don't need to be a designer or color expert.
• You don't need to pick more colors when you add more elements.

Tangent: Autumn uses HUSL as one of the available (and recommended) color spaces; it helps make colors more consistent and enhances readability. I bring this up because HUSL is fricking amazing. If you take away nothing else from this post, check out HUSL.

Anyway, I attempted fixing CNN's headers with Autumn and this was my first try:

Autumn offers several configuration options, but I went with one of the basic color profiles: "dark." I used getGradientColors() to produce the background gradients. Even without tweaking, I think it's looking pretty good. A few colors appear similar, but for the most part they're easily distinguishable. The text is very readable (in some cases even more so than the original headers). For better or worse, the sponsored content looks like a normal part of the page. Here's the before and after side by side:

So I hope you find Autumn.js useful. It could be applied to a lot more than headers: icons, avatars, tags, categories, etc. Let me know what you think.

Now, maybe you disagree. Maybe you're thinking, Whoa, the above screenshot looks awful. Way too many colors.

Well, in that case, I've got an Autumn bookmarklet that's going to rock your world...

........

....

..

.

:)

Check out Autumn.js.

Between their ridiculous cost and the kickback shenanigans surrounding them, I've always hated buying textbooks. I've been buying college textbooks for 14 semesters now and every time I buy exactly what the professor tells me to buy. Only recently did I learn how stupid this is.

Last spring, I took a Software Engineering course. This was the required textbook.

The first warning sign was that the book had 1.5 stars on Amazon. You might initially blow that off and think that Amazon reviewers tend to give low ratings to dry reads like computer science textbooks. But in fact my last three textbooks all received more than 3.5 stars. Drilling down, I noticed the only 5 star reviews didn't mention the book's content at all (only that it was delivered promptly). The one 4 star review was from someone who had read an earlier version 20 years ago. The vast majority of reviews had 1 star.

What's worse is the book was over $100 and a used copy of the previous edition went for about $20. I'm lucky to have an employer that reimburses tuition, so textbooks end up being my only educational expense. What that means is buying the newest edition of a textbook instead of the previous edition raises the cost of my semester by 400%.

I explained my situation and the 1.5 stars to my professor. I wanted to make sure that the book was mandatory and we needed the 7th edition specifically. Instead of answering my questions, he simply responded, "The textbook is a great resource."

Screw it, I thought. Better not risk my grade over a few bucks. Anyway, the professor probably knows more than stupid internet people. Right?

I get the book and learn that the new edition is specifically "designed to consolidate and restructure the content introduced over the past two editions of the book." Okay, let me get this straight. I'm paying an arm and a leg for chapter shuffling?

I keep reading and get the sense that a lot of material is covered with a short-wikipedia-article level of depth (i.e. as opposed to the 17,000 words in Impalement). For instance, the chapter titled Process Models has about a page each on Waterfall, Incremental, Evolutionary, Spiral, Concurrent, Component-Based Development, and Formal Methods models. But I still have no clue how I'd use any of them.

I'm no expert on process models, however, so I try to find something I might know a little bit about: WebApps. Yea, styling web apps as WebApps is a bit strange, but I go with it. I then learn that Web 2.0 is an "emerging technology." Hmmm... really? "Web 2.0" was coined in 1999 and usage of the term started to dwindle a year or two before the book was published. I tell myself to stop nitpicking. And then I find the section called "Well-Designed Websites." It offers the following links:

• http://www.graphic-design.com/Web/feature/tips.html
• http://www.creativepro.com/designresource/home/787.html
• http://www.workbook.com
• http://www.pbs.org/riverofsong
• http://www.RKDINC.com
• http://www.creativehotlist.com/index.html
• http://www.btdnyc.com

Some of the links are dead. Others appear to have been neglected for about a decade. I laugh out loud when I click on the River of Song link.

I bet it was a mind blowing website. In 1998. Today, it's a great example of how not to design a website: tiny red on blue font, heavy image use in place of text, tables for layout, and a fixed 590px design.

The textbook was published in 2009. It's pretty obvious this stuff was added two editions ago.

Lesson learned

In the end, the course was great, but I barely used the textbook. There were no assigned problems. The assigned readings were pointless because exams were based mostly on class notes. Believe it or not, I actually enjoy reading textbooks (Artificial Intelligence: A Modern Approach was a joy to read!) and I usually keep them, but I'm not keeping this one. If you really want to read something by Roger Pressman, maybe check out his novel, The Aymara Bridge; it sounds pretty interesting.

I was often told by other students to never buy a textbook until you're absolutely sure it's needed for the course, even if you have to wait weeks to find out. They were right. The Amazon reviewers were right too. I'm going to start listening to their advice. I suggest you do the same.

I gave my thoughts on the The Castle Doctrine starting here. It's a difficult game and I appreciate that. But I don't like seeing people get too frusrated, so here's a guide to get you up and running.

Resources

• Wiki: Wikis are a great resource for this type of game. Things are changing quickly, so be warned that some information may be out of date.
• Forums: Hop on the forums to get help or to see what other people are working on.
• CastleFortify: This is tool is amazing. It lets you plan out your dream house when you don't yet have the money and enables easy sharing.

Protip

Here's the best advice I can give a new player: don't get emotionally invested in your first few houses. Do this exercise to see what I mean:

1. Look at your cute little family. Tell them everything is going to be OK.
2. Click the 'Done' button.
3. Tick the checkbox labeled with the tooltip 'Confirm Suicide.'
4. Click the 'Suicide' button.

Voilá! Now, you get to start the game over with a fresh $2k.

Many players have asked for a "sandbox" building mode, but in a way the game already has one. You can play around, test things out, build, and destroy. You especially need to learn all the ways in which a house can you kill you and there's actually only 5 tiles that can do it: Powered Doors, Electric Floors, Trapdoors, Pits, and Pit Bulls.

If you die or make a mistake, no problem. Simply start over. The key is not to say to yourself "I have to protect this house" until you're good and ready.

How to play

The basic idea is to build a house that lets you get to the safe, but perplexes and/or kills any pesky neighbors. Unfortunately, you'll have to bootstrap yourself with a measly $2k until you can bring in more through salary or robberies.

The simplest defense is of course a maze. It's self explanatory. Make a winding maze. Put pitbulls down the dead ends or even better put them right along the correct path.

Keep in mind that anything you build can be countered with enough money. When you build a long wooden hallway, a robber could cut through it for the low price of $100 (saw). If a pitbull is placed properly, it'll cost the robber $1k (gun) to kill it. But if they can get around the pitbull, they might just put it to sleep for $20 (drugged meat).

As you get more experienced and wealthy, you'll want to start building houses that rely more on powered security. The gold standard is the trapdoor. A long hallway of trapdoors powered by a complex, hidden circuit means a couple things:

• It can't be defeated by cutting the power. Trapdoor is the only house tile that is deadly when receiving no power.
• It's the most expensive thing to counter. Ladders are $600 a pop.

Safety drills

For every tile that can kill you, there's a safe alternative that you can use to test your house. For pitbulls, the safe alternative is chihuahuas. For anything powered, use indicator lights.

If you really want to avoid dying in your own house, I suggest that you do a safety drill every single time you make updates. Replace the deadly tiles with safe ones, get within 1 tile of your vault but don't step on it (house changes are locked in if you do), leave the house, and then finally do the real thing.

Protecting your family

You might also want to consider if and how you want to protect your family. They won't cross over any house objects other than pets. Therefore, the best protection is a long hallway filled with well spaced pitbulls and reinforced with thick walls (ideally concrete).

Remember, you don't necessarily have to protect your family, but your wife brings in significant income. And any unprotected family members are a liability because of a strange game mechanic: house damage is only saved when the vault is reached or a family member is killed.

Robbing

Try to go after the low hanging fruit. If you see a house that many people have died in, then ask yourself: "do I know something they didn't?"

You have to be a little more careful while robbing because dying in a house locks you out of that house for 1 hour. Still, it's a good idea to experiment with the various tools. It's vital knowledge for both offense and defense.

Wiring

Electronics might seem overwhelming, but don't worry. It's not that bad. I found it A LOT easier than redstone in Minecraft.

Generally speaking, use indicator lights to understand which part of your electronics are powered. You can use lights in place of all wires, except when you need to make circuits more compact. Always remove the lights when you're done testing.

Below are the most complex gates you'll usually need.

OR gate: on if either or both inputs are powered

AND gate: on if both inputs are powered

NOT gate: on if input is not powered

You can build all sorts of more complicated electronics: flip flops, counters, demultiplexers, etc. You can even generate a clock signal using cats.

Good luck!

There's plenty more to learn, but this should get you started. Any questions? Get on the forums or feel free to shoot me a message.

Check out Part 2. In this post, I discuss how the game is evolving.

HatchetCraft

On April 8, PC Gamer released their review of The Castle Doctrine. The game had been in public alpha for less than one month. The review was just over 600 words. It ended with the number 50, citing lack of tutorial and a "willfully obtuse design."

I was livid. Low review scores can have a dramatic impact on sales. A large company can offset low scores with huge marketing budgets, but a solo developer living on the equivalent of minimum wage? Forget it. Minecraft popularized the paid alpha and yet PC Gamer didn't write that review until the full release, over two years after Notch had started charging money. Besides, dooming an alpha game to failure because it lacks a tutorial is ludicrous. Two words: Mine. Craft. To top it all off, they didn't even get the price right.

PC Gamer changed course two days later. They apologized, took down the score, and claimed that they were creating a policy for reviewing preleases in order to "evolve along with" changing funding methods. I think they made the right call in the end, but what if they hadn't?

Imagine for a moment that in July 2009 a well known gaming magazine decided to review Minecraft; this would have been one month after its paid alpha began. At the time, there were no skeletons, zombies, or creepers. There was no redstone. No farming. No minecarts. Crafting wouldn't arrive for another 6 months. That's right: Minecraft had no crafting. This is what the game looked like:

Imagine if some rogue game critic wasn't impressed and decided to settle the matter, in July 2009, with a bad review. Personally, I'd be hesitant to buy a game with no demo and an abysmal score. If that review had happened, it's possible that Notch would still be working at Jalbum. Mojang would be a middling side project. The gaming world would be much, much different. I'd have gotten a lot more sleep. The thought is terrifying!

The PC Gamer score might not seem like a big deal, since it was only up for a few days. The issue is complicated, however, by Metacritic; it has a long standing policy to refuse to update scores, even when the information in the original review is widely known to be false. The only criteria for a game getting on Metacritic is that multiple publications have reviewed it. I wondered if Metacritic might have a policy against accepting alpha or beta reviews, so I posed the question to cofounder Marc Doyle. He responded cryptically, "Our critics have reviewed alpha and beta versions of games, but we want them to focus on the completed game." Translation: it's up to the reviewers to not screw things up. The Castle Doctrine was one more review away from a permanent 50.

In a world of Kickstarters, Early Access, and all manner of homebrew crowdfunding we need to think carefully about how we approach works in progress. After all, we're not just talking about crushing fledgling creative projects, but also people's livelihoods.

Ladders all the way down

One of the reasons why The Castle Doctrine isn't ready for a final review is that it's still being battle tested and balanced. Having said that, I don't expect many major features to be added. After playing 13 versions, I've only seen a single new tool. Rather, small tweaks are propelling the game forward in dramatic ways. The overriding theme of most changes has been to make home owners more vulnerable:

• ladders to get across pits, which previously had no counter
• free blueprints for all houses
• infinite backpacks, as opposed to only carrying up to 8 items

It's not all bad for home owners. Many changes have been added, for instance, to make pitbulls more effective (pitbulls happen to be the only real way to protect your family):

• tool use went from taking 1 turn to 0 turns
• pitbulls became immortal (but asleep) after consuming drugged meat
• living pitbulls started avoiding the tiles next to dead pitbulls

From the outside looking in, those changes might seem nitpicky or even nonsensical. Having played through those changes though, I can vouch for how desperately each was needed to combat player behavior and how impossible it would have been to foresee the need for those changes before testing. Take the 1 turn tool use for example. Pitbulls can be killed cheaply with a $100 crowbar, but the crowbar doesn't have the range of the $1,000 gun. If you're two spaces away from a pitbull, the crowbar is useless. What players would do is cut through a wall with a $100 saw, which kept them in position but let the dog move. In hindsight it makes sense, but I never would have predicted it. In software development, this is sometimes called a "wicked problem." You don't actually know what you have to build until you build it and find out if you were right.

Great artists steal

One of the most interesting bygone features was blueprints. Though they were removed, I'm still holding out hope that they might get added back in in some form or another. They were added because houses in version 5 were quickly becoming impossible to beat. The canonical example was a "combo lock," a series of switches that required a specific combination of ON and OFF (basically, a binary password). Blueprints were eventually removed because they had turned the game into a puzzle/wiring game. Rohrer explains in detail here.

After blueprints had ruined mazes and the like, the only thing left was diabolically hard puzzles. Some depended on the the idiosyncrasies of the pet behavior (i.e. some people were reading the source code to gain an edge). Others consisted of circuits so complex and obfuscated that they eluded hundreds of robbers for days, even though blueprints were freely available and they effectively served as detailed wiring diagrams.

You can obviously see why blueprints were later removed. For an electrical engineering nerd like myself, however, that puzzle aspect was delightful.

The blueprints strongly evoked scenes from your average heist film. The first thing the thieves always do in a heist film, of course, is build a life sized recreation of the vault (usually to practice slithering around laser beams). So that's exactly what I did. One Mr. Hayes had invented a complex wiring scheme, one that depended on a recently discovered sequential logic implementation. Long story short, the circuit didn't just depend on the current buttons being pressed, but also on the sequences of buttons previously pressed. I put in substantial effort, but couldn't decipher the entire circuit on paper. Instead, I stitched together several screenshots of the blueprint and recreated almost half of Mr. Hayes's setup in my own house. Then I began to test different components and how different button presses interacted. All the while, the clock was ticking; if anyone else beat me to the punch while I screwed around, I'd be left empty-handed. Finally, a breakthrough. Then another. All told, I spent several hours plotting the robbery against Mr. Hayes, but I was able to walk with over $50,000, an exorbitant amount of cash.

I can't stress enough how satisfying robberies are. In almost all other games, your victories mean only that you've overcome challenges designed to be beaten. Your victories in this game mean that you've beaten something not meant to be beaten at all.

Hard to be a man when there's a gun in your hand

You should play this game. Not because it's loads of fun, though it is. I think you should play The Castle Doctrine for two reasons.

First, because we gamers are spoiled. I'm not just talking about games being easy. I'm talking about games being so forgiving that your actions are ultimately meaningless. I already linked to a scene from Call of Duty where the player wins a level without shooting his gun. In a similar account, Mark Serrels discovers that not pressing buttons in Ryse has no visible effect on quick time events. You lose a great deal of tension when your controller is turned into a panel of placebo buttons. The Castle Doctrine is so intense, however, that a "safe movement" mode was added recently because players were dying frequently from shaking hands.

The second reason is that The Castle Doctrine tries, and often succeeds, at making one feel emotions that are rarely encountered in video games: vulnerability, impotence, worry, remorse. Violence and crime have always been important themes in storytelling and art. Blood is compulsory, dontcha know? But when games deal with violence, they do it in such a clichéd and childish manner. More often that not, violent games can be summed up as Adolescent Male Power Fantasies. Beat the baddies. Get the girl. Be the hero. Hell, MMOs are assembly lines for making players into heroes.

Not here. What Rohrer has done is craft a violation engine. A system that asks if would like to take away something real (time, effort, and hope) from a real person and then hands you the crowbar. Sure, there's fanciful elements sprinkled about, but it's not an adolescent power fantasy. It's the reverse: a Mundane Adult Nightmare.

You don't get the girl; you lose your family. You're certainly not the hero. The only choice you really have is whether to play the villain. In fact, most of the time you're nobody at all. You're just another name on a list until someone else decides — and trust me, they will, over and over — to make you the victim.

The Castle Doctrine is currently in public alpha. Check it out here.

If you need tips to get started, I wrote a short guide.

Check out Part 1. In this post, I discuss some peripheral issues surrounding the game, including addictiveness and politics.

Sex, guns, and flamewars

The Castle Doctrine has been attached to a surprising amount of controversy and I would hate for anyone to miss the game because of that.

First, the politics. In this interview, Rohrer demonstrates support for gun rights. The interviewer expresses shock and the comments section erupts into a firestorm about libertarianism and abortion. One commenter even calls Rohrer a "broken human being." What the hell, people?

I don't see the big deal about discussing such views. Now, maybe that's because I live in that backwards place called the United States. Or because several (sane) people I know own a large number of guns; hell, even my mother has a handgun.

While the game may be exploring these ideas, I don't think it's making any sort of political statement. I doubt the game's title is persuasive; if anything, it's descriptive and perhaps a bit opportunistic. Rohrer is the first to point out that The Castle Doctrine easily evokes the opposing viewpoint:

"Whenever you're testing all the stuff that you've put in your house, you're sort of the dummy going through a test track, but a vulnerable dummy who can die.... You're dealing with dangerous stuff, and the vast number of people who are bitten and killed by pitbulls are the pitbulls' owners. There's also the stuff about how you're much more likely to be shot by your own gun than to shoot somebody else and all that, which is a classic anti-gun argument."

Another concern expressed by commenters is violence. This is a nonstarter. The games industry is filled with AAA games about slaughtering hundreds of people without a second thought. The Castle Doctrine, however, deals mostly in specific violence: when you hurt someone, it has a real effect on another human being somewhere else in the world. Of course that's quite disturbing, but that's the point. Violence should be disturbing.

The final topic of controversy is gender (all player characters are men, while NPCs are either women or children) and there I am divided. There's no arguing that it would be extremely simple to implement female avatars. On the other hand, I've always thought that gamers who refused to play games with female protagonists were sexist pricks. One might argue that male only protagonists are no longer acceptable for most games simply because we need to counteract a long history of sexism in video games. I could buy that, but here are some other issues to consider:

• Customizing your character would be completely at odds with the game currently (e.g. random, anonymous names).
• The game is somewhat inspired by Rohrer's own experiences. I think people have a right to make art from their own perspective.
• It's a historical reality that the vast majority of violent crimes are committed by men.

That last one is crucial. It's no accident that the game is set in 1991. Violent crime in the United States peaked in 1991. The homicide rate then was about double what it is now. At the time, males committed about 90% of homicides and 90% of burglaries. The percentages haven't changed much. It seems disingenuous to create a world that obscures this sad fact. Besides, I'm not convinced making gender an option would be any sort of positive change. Here's Anita Sarkeesian (whose most recent work is Tropes vs Women in Video Games) discussing what she thinks qualifies as a feminist character:

"The feminism I subscribe to and work for involves more than women and our fictional representations simply acting like men. Or unquestionably replicating archetypal male values such as: being emotional inexpressive, the need for domination and competition, and using violence as a form of conflict resolution."

If anything, the more problematic behavior of The Castle Doctrine is that your NPC spouse is always female. The historical reasoning above doesn't apply (though the numbers are less skewed, most victims of assault and robbery are also male). The consequence is that the only adult females represented in the game are systematically objectified. The only thing your NPC wife can do is: be positioned by you or be killed (or spared) by another player.

Paying anything to roll the dice

The Castle Doctrine is addictive. When I started writing this post, "addictive" was clearly a plus (almost interchangeable with "fun"), but recent dissenting voices have made me reconsider.

Drew Dixon describes the results of his unhealthy relationship with Minecraft: sneaking into bed with his pregnant wife at 4am even though he had work in 4 hours. Unfortunately, I've experienced that same embarrassed crawl into bed because of both games.

David Sirlin frames the issue this way: some games we play because we "like" to play them and others we play because we "want" to play them, in the same way we might want a cup of coffee or a cigarette even if we don't really enjoy them. He gives Portal 2 and Diablo 3 as examples of like and want respectively:

"Diablo 3 is really all about the addiction... Diablo 3 really doubled down on "randomness." Random maps, random items. Random means new, new, new which is good for the seeking behavior that your dopamine-starved brain wants. It goes far beyond new though: we know full well that a "random rewards schedule" (look that up if you need to) is the maximally effective way to addict animals...

It's worth noting that Portal 2 is about as far from the Diablo 3 end of the spectrum as you can get though. There is no addiction involved at all. There are no external rewards at all. No leveling up, no XP. There are no random items to grind."

So what is The Castle Doctrine? Portal or Diablo? And if it's the latter, why do I find it so damn addictive?

This isn't an academic question for me. I made a small game recently and several reviewers complimented it on being addictive. Should I repent? Or should I celebrate and try to get even better at making addictive things?

I'd say The Castle Doctrine is a little bit of both. One huge problem is that your in-game fortune can change dramatically when you're not playing the game. If you're the kind of person who is often compelled to check email for no good reason, consider the parallel. At any given time of day, a thought can occur: maybe someone tried robbing my house since I last played. Maybe they died and left behind goodies. Maybe they took everything. I'll just get on real quick to check my security tapes... might as well tidy up the house for a few minutes. I'm embarrassed at how often I had that internal dialogue. Random rewards schedule? Check.

However, like Portal 2, there's no leveling or XP. No shiny collectibles except for money and getting it can be painful; there's no grinding on easy content. Rohrer even implemented a salary system that pays you for each hour you're not in game. Rewarding you for not playing the game is a commendable but risky move in a sea of games that do the opposite.

Trap me, can't get trapped again

I have another completely unscientific hunch about what makes a game compelling (and potentially addictive): it has to hook into innate human needs. I think we find certain survival activities, ones that humans have been doing for a very long time, deeply satisfying. Again, I'll take Minecraft as an example. What is the game about? Hunting, gathering, farming, exploring, building, and of course crafting. However, now the feedback loop is incredibly tight: you can chop down a tree in seconds and build a shelter in minutes. That's highly addictive, for me at least.

When I was a kid, I played with blocks a lot. I built forts and towers, but my favorite was building booby traps. You see, the blocks were organized nicely on a shelf, like stacks of gold bricks. I would create a facade of nicely organized blocks, but the space behind the facade would hold the best Rube Goldberg device I could muster. If one were to push in on the wrong block, it would set off a chain reaction involving rolling cylinders and ramps and BOOM: the whole thing would explode onto the floor. Cue maniacal 5 year old laugh. I know this sounds ridiculous, but when I lost access to those blocks, I was genuinely upset.

I found my blocks again years later in Minecraft. I could still build forts and towers, but the trap possibilities were mind blowing: landmines, bottomless pits, lava chutes. Cue maniacal 25 year old laugh. There was a problem though: I was still pretending that anyone cared at all.

The Castle Doctrine removes the need for pretending. It puts you in a scenario where building and sidestepping traps is a way of life. I've been waiting a long time for this game. And in some bizarre way, it's rather fulfilling. I have to ask then: is it possible that trapping and fortifying fall in the same category as hunting and gathering? Do some of us have a trapping instinct?

Maybe. Or maybe I just watched Indiana Jones and Home Alone too much as a kid.

Continued in Part 3.

The Castle Doctrine is Jason Rohrer's latest game, a home defense MMO. You can rob thousands of other players while they are away from their virtual homes. Of course, they can rob you too. The only thing preventing any of these robberies is elaborate, deadly traps created by homeowners. Sound like a neat concept for an MMO? It is.

I got into the pre-alpha and was absolutely blown away. Every single night for a week, The Castle Doctrine had me staying up into the late hours carefully tweaking my traps and eagerly waking up in the morning to see which unlucky souls had fallen for them. I died myself dozens of times, yet I kept coming back.

But then something strange happened. I noticed a stream of lukewarm articles coming from the gaming press. There was apprehension about the politics involved. There were complaints about lack of a tutorial. I was confused. Why was nobody talking about how fun this game is?

This is how you get got

Let's start with what The Castle Doctrine isn't.

It isn't an easy game. You always have one hit point. One misstep means death and when you die, you lose everything. There's undoubtedly a learning curve, but beyond that learning curve there is also a never ending arms race. As defenses get better, robbers get better. They get smarter, richer, and better equipped. Old tricks stop working. No matter how clever you are, no matter how convoluted your house becomes, it will eventually be solved or worse.... it will be copied.

It isn't a game you play with friends. Don't let "MMO" give you the wrong impression. There is no social aspect to the game: no chat, no guilds. When you want to rob someone, you select from a cold list of strangers (the website makes at least one reference to looking up names in a phone book). You're not even told your own (randomly generated) name. You can't make friends in The Castle Doctrine. But you can make enemies.

A confession

Now, I admit that I'm a big fan of Rohrer. I want to get that out of the way. He won the GDC Game Design Challenge not once, but twice. Besides consistently churning out thought provoking games, the guy has a damn interesting backstory: he lives with his family of five on a budget of about $14,500 a year. He once fought and won a court battle against the city of Potsdam, NY for the right to grow a meadow.

But here's my guilty confession: I never found a single one of Rohrer's games to be very fun. Passage was quite interesting, but it's hard to make memento mori fun. A friend bought Sleep is Death, but we never could get into it. Inside a Star-filled Sky was OK. I had accepted that I would continue to play Rohrer's games and that they would be clever and interesting, but not much fun and not very deep. This game, however, has proved me very wrong.

ROGUELIKE WILL NEVER DIE, BUT YOU WILL... a lot

The essence of The Castle Doctrine, the thing that makes it so frustrating at times and immensely satisfying at others, is that it is a roguelike. Here's a quick primer on roguelikes in case you've been living in a (non-randomly generated) cave. Roguelikes are games that feature elements of the 1980 game Rogue. There is no single definition, but randomness and permadeath are key elements. I'll reluctantly quote the Berlin Interpretation (but please don't tell Darren Grey):

"Random environment generation The game world is randomly generated in a way that increases replayability..."

Technically, The Castle Doctrine is pseudorandom, since other players create the environment. But many of the same ideas still apply.

Rogue was created partly because its authors were tired of games being predictable. What better way to avoid that problem than to create a system in which predictability is actively discouraged; after all, your best defensive tools in The Castle Doctrine are trickery and confusion. There's an additional benefit to user created "dungeons." With random generation, you either have to make random elements too easy or face the possibility of unfair and impossible situations. The Castle Doctrine avoids that issue by forcing you to navigate your own house and get to your own safe without dying before you can submit your house. It's the best of both worlds: players have an incentive to make their houses as deadly as possible, but those houses are guaranteed to be, at the very least, beatable.

"Permadeath You are not expected to win the game with your first character. You start over from the first level when you die... The random environment makes this enjoyable rather than punishing."

Read that again. Dying. Is. Enjoyable. Aye, there's the rub. In order to enjoy this game, you must enjoy dying a lot. Dying here means starting over from scratch: you lose your house, your items, and your money... potentially hours of hard work. High difficulty and permadeath are hard concepts for your average gamer to grok. It's no secret that gamers today are coddled. But in a game with no danger, there's no tension. Choices aren't meaningful if making a bad one has no effect. Roguelikes are incredibly riveting because you always face the real possibility of losing everything.

It's this possibility that makes validating houses in The Castle Doctrine one of the most intense experiences I have ever encountered in a video game. You're required to go through your house just like an intruder. Your traps will kill you. Your own pit bulls will maul you. The worst part is you're not even allowed to use offensive items, like crowbars, that would otherwise help get you out of a bind.

I once made a confusing maze that ended in a series of hallways filled with electric floors. Go down the wrong hallway and get swiftly electrocuted. I had developed a habit of validating the house "cold" (leaving extra exits or removing key components) before doing a live fire exercise. So I ran through a few times and everything worked flawlessly. I quickly added in several pit bulls that would chase close behind and closed up the extra exits. It was go time. I methodically selected the rights doors, navigated the maze, and got to the right hallway. But then I noticed something was wrong; I had miscalculated and added one pit bull too many. The last one toggled a switch behind me that electrified the floor and left me stranded on one safe tile. Your standard run, gun, and respawn-at-checkpoint game has never gotten close to creating the feeling I was experiencing at that moment, best described as "pit in stomach."

Continued in Part 2.