Tom used to be a lawyer. Now he's a game designer. The two have more in common than you think.
Sorry for the late update–a business dinner ran into the evening.
Jay’s comment on the last post combines with offline polling to put the baby dragon theme in a dead heat with the ancient dragon concept. At this early prototype stage those two are mechanically identical, so playing as a dragon it is!
Of course, just over 24 hours into this new prototype you play as a Unity primitive carefully avoiding another Unity primitive. So it goes in the realm of rapid iteration. 😉
Getting tired of vicious campaigning and elections that might change the fate of the post-war order? Take a break by voting on this low-stakes thesis prototype theme!
Which of these do you like best?
When I first started learning about game design, it seemed like there were new revelations every day. By now, the low-hanging fruit is gone. I still learn things every day–but the lessons are narrower.
It’s possible to do a double-sided single 3D plane in Unity, but it requires writing a custom shader, or at least customizing an existing one with the “Cull Off” command.
Git and SVN offer much the same basic functionality, albeit under different names. Many of the best practices for using each are the same.
Adobe has a great collection of color swatches here.
So much of doing good work, in the law or in game design, is in the details. These lessons aren’t as sweeping as the early ones, but these smaller building blocks are valuable–they fill in gaps that could otherwise show through in a final product.
I was happy to learn that Mark Herman, an award-winning designer with decades of industry experience, has a blog over at GMT Games. Some of the posts are play-by-plays that will probably be of most interest to those with experience of the games in question, but others take a broader look at design issues. Read his posts through when you get a chance; Mr. Herman’s knowledge is an invaluable asset to the game design field.
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.
Some small percentage of interesting decisions are always going to be fun. Some interesting decisions never are. Most, though, are fun only when given a context in which they can shine. It’s vital to understand what situation a decision needs, and to test your game accordingly.
Many well-known, big-budget games have decisions that work as gameplay specifically because of how they’re presented. Choosing where on the screen to click with a mouse, for example, is completely trivial in a turn-based environment that allows the player to take as much time as she wants. Yet, that activity supports the entire FPS genre, because it’s not at all easy to click just the right spot under extreme time pressure.
Fighting games are of the same ilk. Lots of fighting game decisions are easy once the player understands the game (“I should parry this projectile, that’s strictly better for me than blocking or jumping”). Others are more-or-less math problems: there are two options, with the first having a higher expected value than the second. On paper, the player alway makes the right choice. When one has to find the right move in a sixth of a second, doing the math or executing the correct action is a lot harder—and the difficulty helps turn what would otherwise be a trivial exercise into a tense journey through donkeyspace.
Both of those examples rely on time limits, but there are other contexts that can affect whether a decision is interesting. While in school, for example, I worked on a game loosely based on regattas. Players formed teams, and then teams rowed against each other to win a race. We were to discover the hard way that that has the potential to be interesting . . . so long as the game isn’t an entirely cooperative game about rowing in tandem.
If you’ve ever been out on a boat yourself, this probably doesn’t surprise you. Rowing can lead to beautiful scenery, it can be a kind of moving meditation, one can use it as a social event. It’s unusual, though, for the actual act of rowing to be intellectually challenging. We struggled for weeks to build a system that would make coordinating a team of rowers fun in and of itself. Two weeks went by with the team rowing boats using different systems, just by ourselves without any opposition, searching for a way to turn that into a fun puzzle.
Mercifully, that process ended (as is so often the case with design problems) when we gritted our teeth and took our not-really-working game out to playtest. The results were dramatic—it was great fun! Players enjoyed it, we enjoyed watching them play, everyone had a good time. What had happened, to bring about such a remarkable change?
All we did was change the context in which the same decisions were made. Throughout our internal design work we played a cooperative slice of our cooperate-to-compete game. In doing so we put all the weight on the puzzle, and the puzzle couldn’t bear the load. It wasn’t deep enough to be a game unto itself.
A competitive environment, on the other hand, made the relatively simple puzzle we had built deeply rewarding. It was hard enough that players sometimes made mistakes, and those mistakes now existed in a context where they mattered. At the same time, it was easy enough to allow for successful cooperation more often than not, and players enjoyed solving each turn’s puzzle in order to progress in the race. Competition made the exact same mechanics fun.
Our game didn’t have the wrong decisions; we’d just been testing those decisions in the wrong context. If you can predict that your game will work best when certain things obtain, be sure to test in that context. It’s worth saving those two weeks of heartache!
I’m currently assisting in the development of a game that edges into the realm of augmented reality. That experience has made me curious about the technology, which I must admit I have up to this point done very little with.
Are there AR games, apps, or activities that have particularly impressed you? I’m familiar with AR applications that, for example, make a 3D model appear when the camera focuses on a particular image. What else have you seen AR do? How have you seen games incorporate AR into their mechanics?
I would’ve liked to put up the latest thesis concept, but in testing it proved . . . unsatisfactory. As a result, I’ve scrapped it, with a few more lessons learned noted down.
Fortunately, in talking with a recent Game Center graduate I’ve come up with something new that I think has promise. It takes some of the things I’ve discovered about, for example, the “juice” thrill of powering up, and puts them into a context that I expect will be more workable. We’ll see how it goes.
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);
sw.WriteLine(content);
sw.Close();
}
}
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:
Here’s hoping this saves someone out there a little time and heartache. 🙂
This article is interesting, for two reasons. First, it has some Kickstarter-related advice that might be of interest. Second, and perhaps more importantly, it has this to say about good design:
“Pro Tip: Play a f*** ton of games before you try to design one.”
While I wouldn’t put it in those terms, I think the message is spot-on. Having a broad familiarity with games helps one avoid reinventing the wheel, and all the struggles along that path.
We’ve been down this road before
A lot of people have made a lot of games. That means that someone has probably at least attempted something similar to what you’re looking to do. In some cases, they discovered something your game would greatly benefit from knowing.
The current mousetrap
In some cases this might be a mechanical innovation that you could put to use. Magic: the Gathering, for example, left-right-left pattern of drafting to a huge new audience.*
(For those unfamiliar with Magic drafts, each player opens a pack, chooses a card from it for her deck, and then passes the remaining cards to the left. Everyone keeps choosing one card and passing until all the cards from all the opened packs are gone. Everyone then opens another pack, but passes to the right for this second round. Finally players go through a third round, passing to the left once again.)
The left-right-left approach makes card picking decisions much trickier than they would be in a left-left-left draft. For example, in a Magic draft a player might intentionally pass cards of a color he doesn’t want to play to the player on his left in round one. Hopefully the player to the left will focus on that color–and will therefore pass cards in some other, more desirable color to the right in round two. Since the left-right-left pattern makes “signaling” in this fashion important, and since signaling makes weighing one’s pick choices quite a bit more interesting, the left-right-left system has been widely adopted (see, e.g., 7 Wonders). If you’re making a card-drafting game, it’s far better to know about that pattern–whether you adopt it or react to it–than to spend hours upon hours figuring it out from scratch, just so you can get to the design stage that someone who’s drafted Magic cards would’ve reached immediately.
The dark paths
It might also be that your idea has been tried before . . . and didn’t work out quite as planned. Learning from past mistakes can save a lot of time and heartache.
One sees this at play every time someone says they want to create a new CCG. Immediately someone points to the endless ranks of failed trading card games. Each of them sought to recapture Magic‘s lightning in a bottle, but were brought low by some combination of complex packaging requirements, enormous distribution costs, overwhelming design challenges, and an inability to develop a player base large enough to generate useful network effects. Better to redirect the design early to a model that’s going to be more workable.
There are warnings to be found in the digital realm as well. Online multiplayer, for example, is exceptionally hard to implement. AAA studios have made it seem like a de rigeur inclusion–but of course, they have AAA resources. Smaller studios and independent designers have run into trouble after promising it, and might want to focus on single-player games while they build up money and expertise. Playing games with shaky online play, or where the “multiplayer” button has been greyed out since release, or even very successful games that have struggled with rocky launches (which is to say, just about every multiplayer game, even those with the backing of huge enterprises) might help developers realize that they should think carefully about whether and when they’ll commit to online play.
On the Shoulders of Giants
Playing lots of games doesn’t mean that one has to go back over old ground endlessly. Nor does it mean the accepted ways of doing things become constraints. Rather, knowing what’s out there makes innovation easier, by enabling one to know which design approaches are actually innovative–and which are well-trod paths, or worse, are rife with land mines. Don’t use play-for-research as a substitute for progress on your own work, but recognize the importance of that research, and make time for it.
*I’m not sure if the pattern originated there, but it may well have.
The Law of Game Design 