There’ve been a couple of posts alluding to the current thesis prototype. Now it has a name:

Screen Shot 2016-07-15 at 11.24.01 PM

Playful is a game about hide-and-seek. Two little kids, who happen to be a dragon and a knight, are chasing each other through a forest. Since the dragon has some natural advantages (most notably the ability to breathe fire), they agree that the dragon can’t go for the win until the knight has spotted the dragon twice. If the dragon can avoid getting tagged in those moments of risk, it’ll be possible to breathe fire on the knight and win the game.

One of my goals with Playful was to explore a form of conflict that isn’t within the violent norm of video games. We as humans compete all the time, but only a very small number of those forms of competition appear in games. I’ve been enjoying bringing kids’ makeshift, balanced-on-the-fly competitions into video gaming.

Playful is also meant to capture the notion of engaging with the risk posed by an opponent rather than controlling the opponent to negate risk; a few of my classmates summarize the idea as “honorable competition,” and I think that’s a good way to put it. Again, this is something we routinely do, giving one player small advantages or imposing limitations to ensure that a game is fun for everyone. Capturing that negotiation has been a lot of fun.

I’ve enjoyed working on Playful enough to want to polish it into something releasable, even if just as an interesting proof of concept. That process is ongoing now. Look forward to it in the coming weeks . . . .

Theory: Don’t Get Captured by Game Feel

There’s an interesting difference in decisions in video games versus those in tabletop games—one with huge implications for designers. Choices on the tabletop are usually discrete; we can quickly identify the exact point where the choice is made, and so it’s relatively easy to ask whether that decision was complex, deep, etc.* By contrast, we emphasize the “feel” of video games because that’s a sensible way to evaluate the many little decisions that go into playing most digital titles. One of the challenges in designing video games is zooming out, locating the decisions that really matter and making sure that they’re as rich as those of a good board game.

We tend not to ask whether video game decisions are difficult or interesting. That’s not surprising, because most of the choices one makes when playing most video games aren’t. I want Mario to go left; to achieve that, I hold down the left button (or hold the joystick to the left, etc.). A huge number of decisions go into that movement, since I am constantly making a binary choice between holding or letting go, and it’s not always easy to be sure which decisions among the infinity of little ones are really impacting the player’s success.

Tabletop board games work differently. The moment-to-moment is abstracted away. Every decision the player makes is weighty. Choices are limited in number, and their import is clear.

Unfortunately, the challenge involved in figuring out just where the big, meaningful decisions are in video games sometimes means that we don’t ever get around to locating them. As a result, we never check on their quality. We get caught up in polishing the infinite tiny choices—an important thing to do, given how many there are!—and fail to ask which ones are the most meaningful, or how meaningful they really are.

I ran into this issue personally with my most recent thesis prototype. Many hours in, having carefully picked out suitable 3D models and hooked up animations and tuned the movement speeds, I realized that the game wasn’t any fun. Early on the player made one choice, and then spent a long time executing that choice through a bunch of movements that had great feel but weren’t significantly changing the game state. If the player’s single important choice had been made correctly, she was rewarded with a power-up which effectively reset the game. To put it directly: the player got to do one meaningful thing, and if she did it well, she was rewarded by having it invalidated!

Several playtests later, I think the problem is (mostly, hopefully) resolved. Alas, I could’ve been here sooner had I begun by considering, not game feel, but the number and quality of interesting decisions I wanted the player to make. Emphasize sifting out and evaluating the truly meaningful decisions in your video games; they’ll be better for it.


* Answering that question might, of course, be very hard!

Theory: Computerized Brainstorming

There’s something to RoboRosewater. It’s fair to say that this isn’t a great card:


Or that this one isn’t even coherent:


However, this automatically-generated creature is a cute idea:


This one might even have a valid role in some conceivable metagames:


While one clearly has to take the good with the bad, I think the interesting aspect of RoboRosewater is that it’s at least capable of putting together cards that are interesting. Its cards suggest weird possibilities that might be worth following up on. For example, I wouldn’t have thought of representing your creatures’ negative effects on opponents’ creatures with bonuses rather than penalties if RoboRosewater hadn’t tried it, with very thematically satisfying results.

I can imagine this sort of tool being useful for many games that use exception-based design. We humans can have trouble getting out of our own heads in order to find new and interesting exceptions. Computers, though, can do it easily. For a game that’s going to be around a while, it might be worth designing a script that can toss out new player powers and the like.

Unity: Debugging Infinite Loops

Unity’s Debug.Log has a singularly frustrating interaction with infinite loops: it stops working immediately upon entering the loop. My theory is that Debug.Log is designed only to output to the console at the end of a frame, so if the end of the frame is never reached messages never get written. Whatever the cause, this fundamental debugging tool is useless for working out what code is involved in the loop.

Fortunately, there’s an easy solution: write to a text file. Debug.Log messages won’t show during an infinite loop, but Unity will honor instructions to write to a file as it goes through code endlessly. By writing messages to a file instead of to the console, you can get the information you need.

Outputting text to a file is easy. Copy the following into a new script:

using UnityEngine;
using System.Collections;
using System.IO;

public class FileIO {

/// <summary>
/// Write a string to a file
/// </summary>
/// <param name=”fileName”>File to write to.</param>
/// <param name=”content”>String to write.</param>
/// <param name=”append”>If set to <c>true</c>, append. If set to <c>false<c>, overwrite file.</param>

public static void WriteStringToFile(string fileName, string content, bool append)

StreamWriter sw = new StreamWriter(fileName, append);





You can then use it as follows:

FileIO.WriteStringToFile(“debug.txt”, “Animation begins”, true);

Write as many messages as necessary to determine what’s happening.

A few usage notes:

  • Don’t forget “using System.IO;”
  • Note that this class doesn’t inherit from Monobehaviour, so it can’t be attached as a component. That’s fine; use the syntax above to call the function.
  • By default, the text file appears in the Assets folder.

Here’s hoping this saves someone out there a little time and heartache. 🙂

Notes from GDC 2016

A few things I’ve learned (or been reminded of) while at the Game Developers Conference:

1. Visual polish matters, all the more so in a crowded environment. It gets harder and harder to stand out when the number of games on display gets larger. Good visuals are a big help in getting people to stop and look at your game.

2. Style matters when it comes to visual design. A distinctive look can beat very finely wrought–but generic–visuals.

3. San Francisco trains don’t run early on weekends, so don’t plan to fly out too early. 😉

Board Games at GDC

Just mentioning again that there’s tabletop gaming at the Game Developer’s Conference! The great folks at Shut Up and Sit Down are running board games on the third floor of the west building every day of the conference from 10 to 6. Drop by if you’re there!