Link Between Worlds


I finished playing A Link Between Worlds this morning. It’s a beautifully crafted installment in one of my favorite franchises. I tore through it. I enjoyed every moment. I also don’t remember much of it.

Spoilers… Continue reading

Sublime Editors

I’ve been hunting for an IDE for a while now. I’m using IntelliJ IDEA for work and I love it, but it’s definitely more complex (and more expensive) than my personal projects will allow. I’ve used lightweight editors for a long time (Notepad++, Crimson) and they’re great for some things, but I’ve found myself more and more impressed by the power of an IDE with really good navigation tools.

Recently I’ve been learning vim commands using (which is worth the money just for being a good puzzle adventure game if nothing else) and I’ve been trying out vim itself as well as popular IDEs that have vim plugins – Emacs, Eclipse, Netbeans. Unfortunately, nothing has been an easy fit. I’m sure I could get accustomed to any of them over time, but I kept looking in case there was something better out there.

That’s how I stumbled across Sublime Text last night. How has nobody told me about this before?

  1. It’s fast, like the lightweight editors I used to love.
  2. It’s pretty, especially in fullscreen or distraction-free mode.
  3. It has an integrated VIM mode.
  4. It’s got excellent navigation tools built in (the “Go to anything” command is awesome).
  5. It’s got a great plugin community and plugin management tools.

My total time for setup was probably an hour – that’s download, install, finding and installing three or four helpful plugins, configuring vintage mode, and importing my current project. I’m going to give it another couple days of trial first, but I think I’ll end up dropping $70 on this editor.

In the process of looking for IDEs I also stumbled across WriteRoom, a little $10 text editor that’s equally pretty. I used its distraction-free mode to write a blog post on the train this morning.

I’m usually pretty gung-ho about free software, but I have to admit a significant leap in the aesthetic quality of these paid (but affordable) editors. I might be a convert.

Dominion: Intense

Writing about Yu-Gi-Oh got me thinking about Dominion, and how it’s about the only board game that my wife actually enjoys.

As a thought experiment, I considered how Dominion would change if you took all the randomness out of the game. It wouldn’t be hard to do. Here are my rule changes:

  1. When setting up the game, each player may stack their deck.
  2. When you discard multiple cards at once, you may put them on top of your discard pile in any order.
  3. When you have to draw and your draw pile has run out, you flip your discard pile over and turn it into your draw pile without shuffling it.

There you go, deterministic Dominion. I haven’t tried this yet. I’m going to, but I wanted to write down my hypothesis first. I predict that making Dominion deterministic will significantly increase the intensity of the game, which in turn will make it more fun for a few of my competitive gamer friends, but at the cost of alienating more casual players (e.g. my wife).

At GDC I attended a great talk by Luke Muscat from Halfbrick, where he discussed a prototype he created that made people at the office into mean backstabbing jerks. His hypothesis was that three mechanical characteristics of his prototype led to this behavior, together creating a game with an extremely high level of “intensity.”

  • No Randomness – It was a pure strategy game, based on skill alone.
  • Duration – It was a long game (weeks) with a high time investment.
  • Chaining – This one’s harder to describe. There was a mechanic that let connected groups of players get very powerful, but only if every player in the chain participated. This led to the formation of teams, but also lots of backstabbing since there could only be one winner.

This Dominion variant is based on the first of his points, and on some of Greg Costikyan’s work on the role of randomness in games. Taking randomness out of a game places the blame for failure squarely on the player. If the ideal family game gives you that “win because of skill, lose because of luck” feeling, deterministic games are missing the second half of that equation.

It’s possible that Muscat’s second point will come into play as well, but I’m not sure yet. I think for less skilled players, the game may go longer as they struggle to stack up the right cards and create winning combinations, and it’s hard to be saved by a lucky shuffle. On the other hand, very skilled players may be able to close the game faster, reducing the stakes of a given game and therefore its overall intensity.

This all reminds me of playing Egyptian Rat (also known as…) in high school, with friends who were trying to count not only the cards in their own deck, but in their opponent’s deck as well. Our version of that game evolved a series of rules designed to preserve its deterministic nature because the high intensity was a major feature – the “slap” mechanic being the primary point of intensity, suggesting that games requiring constant attention or concentration also have a high level of intensity. We were able to pull casual players into Rat though because games were often short, again lowering the stakes.

I’m sure the designer considered a non-deterministic game when creating Dominion – I wonder how quickly it was thrown out. I’ll give this a shot, and if anyone else tries it I’d love to hear about your experience.

The Cutting Room Floor

I just discovered The Cutting Room Floor ( through the (also recently discovered) Watch Out For Fireballs podcast, which is from my hometown. TCRF documents cut assets, levels and features in videogames. There goes my free time.


It came down to this realization: When I won it felt like I was lucky, but when I lost it felt like I had played poorly.

Let me back up. Not long ago we were blessed with some visiting family, and my little brother (age 14) is going through a serious TCG (Trading Card Game) phase. He’s been playing Magic: The Gathering for more than a year, and recently picked up Yu-Gi-Oh again at the behest of his church friends. Naturally, knowing I was the #1 gaming geek in the family, he brought along his cards so we could play.

I’m not exactly a stranger to TCGs. I had a few years where I was completely taken with Decipher’s complex Star Wars CCG. I won’t claim I was ever any good, though – SW:CCG being what it was, I never had anyone to play with. I just liked the cards. I’d also played MTG a few times with my brother before, but Yu-Gi-Oh was completely new to me.

Now, playing a TCG with somebody else’s deck is already a half-baked experience. Much of the game consists of building your deck, finding the killer combinations and tweaking the odds that they’ll show up. Going into a match, you’re supposed to pretty much know what’s in your deck – and hopefully your opponent does not. So when playing Magic with my brother’s deck I felt like I was running an engine, but not necessarily making decisions. Honestly, this is fine – it’s like playing “War” or “Rock Paper Scissors.” You win some, you lose some, it’s mostly luck. At least, that’s the feeling that makes it tolerable.

But Yu-Gi-Oh with another player’s deck is a different experience. Oh boy is it a different experience. And now I hate Yu-Gi-Oh.

See, MTG has a lot of cards and a lot of rules, but most strategies are built on the same core engine: You need land and creatures. Lots of land and creatures, or good land and creatures,and there are a lot of ways to get land and creatures, but it all comes back to – say it with me – land and creatures. While playing with an unfamiliar deck wasn’t great, I could at least understand my moment-to-moment options and put up a fight.

In Yu-Gi-Oh, on the other hand, I never identified a true core mechanic. My brother would play tons of monsters, and every time it would be through a different method: summon, special summon, tune, fuse, morph, XYZ, crystal, repair, whatever. The cards all had such specific uses and requirements, often referring to totally different systems. Even worse, he had “extra decks” of 20-odd monsters just sitting face-up, that he could summon at any time if he met the special requirements on the card. That’s like having twenty extra cards in your hand. That’s twenty sets of special requirements and effects that he’d memorized, that were totally crucial to playing that deck. I’m going in totally blind – that deck is utterly unplayable for me. The particular scenario requires such intimate foreknowledge of the cards that it’s virtually unteachable. I couldn’t just “run the engine” in Yu-Gi-Oh; I was lucky when the engine didn’t fall apart entirely.

I understand that this is exactly the appeal of Yu-Gi-Oh to some. My brother openly admitted that he loved the fact that his decks were unique – that even if he gave his cards away to his friends they wouldn’t be able to run them, because they didn’t understand the way they interact.

There’s a special magic to that, a game that lets you carve out your own secret unique niche but still play against other people. Lots of games have this appeal to a degree; it’s the power of mechanical customization, and it can foster deep investment. But the tradeoff seems to be a steeper learning curve, and a seriousness that not everybody finds appealing; when your deck loses in Yu-Gi-Oh you kind of take it personally.

Which wasn’t my issue, of course – I just felt incompetent. Oh well, I guess I’ll go back to Dominion.

Thirty Flights

Should I be embarrassed that I did’t like Brendon Chung’s Thirty Flights of Loving?
Continue reading

Games as Rhetoric

I finally got around to reading this post on Raph Koster’s blog. It’s powerful, thoughtful, and emotional. I’m not sure I have anything to add yet, but I wanted to refer people to his post because it captures a lot about the current independent games scene that I hadn’t recognized or put into words yet. I’m also struck by his observation that a lot of recent games (both indie and AAA) are rhetoric rather than dialetic. It’s a distinction I’m going to have to put a lot of thought into.

Pumpkins 2012

Pumpkin carving with my wife and brother-in-law again this year! That’s my triforce on the left, Alleson’s tree on the right and our brother’s ghost in the middle. I feel like my carving quality is up a notch this year, but I’m still fond of my 2010 work.

Crossing Paths with C-3PO

"The first duty in life is to be as artificial as possible."

I love my school. I’ve had the pleasant occasion of meeting Anthony Daniels again! And this time I was asked to write a short report on our time with him.

Photo by JD Hancock on Flickr. Used under Creative Commons Attribution license.

The Collected Lessons of ETC Spring 2012

In preparation for a new project this Fall, I have been reading through the ETC project postmortems from Spring 2012 and looking for common themes that I can implement into my next effort to make it successful. This is my own summary lens on 14 postmortems. I believe the postmortems are internal to ETC so I won’t be linking to them or giving out too many details, but the general lessons may be valuable.

The Basics

A few points get hammered home over and over again when you read postmortems on student projects. Our professors remind us of these all the time and they seem so obvious, but in the heat of a 15-week development cycle it’s easy to get them wrong.

Limit your scope

Somebody – could be anybody – will ask for more than you can give. So estimate your work right away, and be very clear about how much you can do and why. This is hard, and certainly deserves its own book, but there are a few key principles that will help:

  • Accept that estimates are imperfect – it takes the pressure off. Round to days or half-days.
  • Involve everyone in estimation – they will be more invested, and you will get more accurate estimates.
  • Estimate frequently – you will get better at it.
  • Build in buffer time – you will need it.

Almost every team celebrated limiting their scope, and no team wished they had taken on more work.

Prototype early

Teams that get past talk and design and make something the fastest, seem to have the most success, while those that don’t always wish they had started earlier… probably because this is a prerequisite for the next couple of points, iteration and playtesting.

For tips on making this happen, see “Gold spike” below and Kyle Gabler on rapid prototyping.


The results are 100% consistent: Every team either says “We’re so glad we iterated so much,” or “We wish we had iterated more.” Build it, try it, discuss it, rinse and repeat. Of course, this goes hand-in-hand with the next point:


The most successful teams were consistently the ones that did lots of playtesting. Those that start playtesting earliest and do the most over the course of the semester always have a more polished, more impressive product in the end.

Of particular note, one team mentioned that they did a lot of playtesting but they didn’t reap the benefits because they didn’t take the time to discuss their playtest results and update their direction accordingly. So, don’t forget the do something about it step. I’m hoping our whole team can meet after each playtest to talk about the feedback and plan changes together.

Doing Better

Then there are good habits that only some of the teams get – usually the successful ones.


Very successful teams do a good job of specializing, with clear distinctions between roles for team members. “A lead for every task and every task has its lead.” This has a number of benefits – team members who feel solely responsible for an aspect of the project will be more invested and relish in their creative freedom. It helps keep aspects of the project from being overlooked. It looks good in presentations too, when for any given topic the team can point to their expert.

Foster interdependence

The flipside of specialization is interdependence and duplication of knowledge. Some teams reported that their members were so independent that they were not always on the same page. So while you have a lead on every task, you should also have at least two brains on every feature. It will build a team mindset, help team members get each other ‘unstuck’, and when crunch time hits you won’t have put the whole weight of the project on the shoulders of that lone programmer that knows how to deploy to the staging server.

Gold Spike

You have a brand-new team that’s never worked together before and you need to get started, but your client is out of reach and your design is up in the air. Early prototyping seems impossible. What to do? Why not make a tiny game together to get everybody rolling? The “gold spike” task (doesn’t even have to be a game) can be an icebreaker, lets the team get an early read on their group work style, and can be a first step in establishing your asset pipeline. I’m considering starting this semester with a quick “Asteroids” remake.

Low Latency Communication

A number of teams reported a new understanding of the value of face-to-face conversation when working through problems. It is tempting for some (like me) to write a long, detailed breakdown of a problem and its solution, and sometimes that is important. But drawings and diagrams are much more efficient than writing to communicate with a group, and if you can just walk over to someone and tell them about it, that is even faster. Documentation is an important tool, but it’s a slow one. Turn to better tools to communicate quickly within your team.

A Physical Task Board

A number of teams attempted to use Scrum or a related agile development style this last semester. Every single mention of Scrum in the postmortems said (paraphrased) “we started the semester using a digital task board, but it just fell apart. When we finally switched to a physical task board everything came together!” I’ve had the same experience on at least two different teams.

Above and Beyond

Then there are those outlier cases – times when a team did something different, and it really worked!

How to Pitch

One team told a great story about trying to help their client pick an idea. They had gone in with a number of good ideas, and explained the technical merits of each, but they were not getting the positive response they needed. So they sought assistance from the faculty, who recommended that they pitch just one or two ideas very well. They needed to show more excitement about the ideas they were pitching so that they could really sell them. They also needed to make the technical merit of the ideas secondary to an emotional hook. The team landed with their next pitch, and the project had a clear direction from then on.

On my own team I learned a lot about how important it is to be pitching your idea all the time. Even when the client comes to you with an idea, you have to ‘pitch’ it back to them with enough passion to make them your partners in the work. And practice makes… well, you know.

Unifying the Team

One team mentioned that they used improv games to get to know one another throughout the semester, and reported great camaraderie and unity as a result. That team worked some very long hours in order to produce a polished, finished product, and they credit their ability to cooperate at 3AM to how they developed their relationships early on.

Crazy Ideas

Humor me… some other things I want to try after reading the postmortems, though they weren’t directly mentioned.

The Mantra

It’s easy to get lost in the details when working on a project. Some of the strongest interactive works exhibit a unity of vision that can be hard to create with a team. I wonder, what would happen if, as soon as we had our vision hook/design pillars/theme song figured out, we repeated that as a group every day? It could take as little as one minute of a stand-up meeting. Would it help us create a more unified experience?


Try putting one team member in charge of the “juiciness” of the experience. This is one of those easy-to-forget things that has a big impact. Ideally a game designer is looking at this, but programmers have a huge impact on it too.

A Shared Vocabulary

I wonder if it wouldn’t be helpful to continue building a shared foundation of words and ideas within the team, via common reading. You could even make this a role, and put someone in charge of the “book” club, but you share articles and videos. We kind of do this naturally, so it might be real overkill – or it might be interesting to collect all shared theory.