tiny adventures: female character choices
One of the goals of the small strike team that created Tiny Adventures was to remain completely free of outside dependencies. Digital projects at Wizards had shown a tendency to get bogged down because they relied on other departments or contractors for various critical components, and since our goal was to create a game a month, we had to keep that to an absolute minimum. On the team we had two designers, a programmer, two producers, a quarter of an art director and a third of an editor (a lot of people at Wizards split their time between multiple projects). Like I mentioned in yesterday's post, we also utilized some contract writers for Tiny Adventures, but that was directly controlled by us and Brandon Bozzi did a great job of keeping everything moving.
Because of the restricted time schedule and insular nature of the team, we had zero ability to generate new art assets. One feature that we wanted to have was male and female versions of all of the character classes. While it would've been trivial from the technical side, it turned out that almost all of the decent D&D art that we had at our disposal showed off male heroes. We had three options: delay the app, put up subpar art, or only give one gender option for each class (with something like 6 male characters and 2 female characters). We chose the latter, foolishly thinking it wouldn't be that big of a deal.
Well, it ended up being probably the number one requested feature, and annoyed people to no end. Because you couldn't choose race and class separately, or choose how to spend your stat points, even players who didn't care about the gender of their character wanted the extra options. To the players who did, the imbalance implied sexism, since players tend not to think about production difficulties, and even if they did, it's hard to imagine a company like Wizards having trouble creating a few small pieces of art.
(As an aside, it's very clever that almost every app puts Alpha or Beta on the end of their title these days. It makes players be a little bit more forgiving, they feel like they're getting in early, and it costs you nothing, especially since it's become accepted to allow purchases during beta.)
Fortunately, the team that was tasked with maintaining the app eventually fixed the imbalance by digging through the archives and finding some quasi-reasonable options, so every class had both a male and a female option. As a bonus, this meant that a lot more races got to share in the spotlight as well, which meant that it was a lot easier for everyone to find a combination that they liked.
Takeaway: If at all possible, have gender balanced character choices. It's easy to underestimate how important this is to a lot of your players. Also, players don't care what hurdles you had to overcome or what prevented you from putting in a feature. They only care about what they're interacting with, which is the end result.
Next topic: The Adventure System, or "How do you tell a story without telling the same one every time?"
tiny adventures: the end game
Tiny Adventures was a content-based game, which was a risky decision for such a small team on such a short schedule. In Nik Davidson's original pitch, the adventurer was sending back postcards to let the player know how she was faring. We all thought this was an evocative way of letting the player interact with their character, especially given the strength of D&D and other tabletop RPGs in telling compelling stories. In the end, it required a creative coordinator, an editor, and a small stable of contract writers (plus other members of the team pitching in heavily) but we managed to create almost a novel's worth of stories that accommodated the hero's gender, class and weapon.
Of course, the scourge of all content based games was still a factor. We needed a plan for the end game. No matter how efficiently you create new content, players will devour it more quickly, even in a game with built in delays like Tiny Adventures. What do players do once they reach maximum level? Fortunately I had been playing a game recently where the player retired his adventurers and each one passed on a single item to the next generation (can't remember the specific game, unfortunately). This seemed like a perfect fit, and thus we sidestepped the classic end game problem by removing it in favor of repeat playthroughs of the main game.
There was only one remaining question, and it concerned me greatly: why should players keep playing?
- To see all of the content. We had two plans here. First, we tuned the leveling curve so that we had more adventures, encounters, and items than a player could see in a single playthrough. Second, we added rare encounters and rare artifacts so that even once a player had seen all of the common content, there was still more out there.
- To try out the different classes. The classes were decidedly similar at this point, but they did differ in terms of their primary stat and weapon/armor proficiencies, which made them want different equipment. We also added some differentiation with a system that I'll talk about below.
- To try to get a high score. More on the scoring system later in the week.
Yet, this still didn't seem like enough. We wanted to add rewards that would stack up as the player retired more and more characters. The simplest solution would be to allow people to take an additional item each time they retired, but this would've quickly made most of the content trivial and would've diminished one of the most exciting aspects of the game (item upgrades). Any system that reduces the number of times a player can find an upgrade has a high bar to cross before it should be added.
The proverbial ace up our sleeve was the generations system, a series of unlocks that were linked to the number of retirements. We added a page that showed the unlocked bonuses and the points at which you'd receive your future unlocks, so that players were always anticipating something. We then designed two abilities for each class that would unlock at the 3rd and 6th generation. The first one was usually a simple attribute boost or heal, and the second could change the game somewhat and allow you to take advantage of advanced knowledge.
The original plan was for the unlocks to extend up to generation 25 (with significant gaps in between), but we never found the time to implement a couple of the later ones. Still, the system seemed to be a success, and was a strong contributing factor to players sticking around through many different characters. The sense of overall progression that it gave was perfect for ameliorating the potential negative feelings from forced character retirement.
Takeaway: With a small team, don't build a content based game if you can help it, but if you do, give the game a definite ending and give players compelling reasons to play through again and again.
Next topic: Female character options.
kinship and the great designer search
If you follow Magic closely, you're probably aware that The Great Designer Search 2 has just announced its eight finalists. If not, you're probably wondering what The Great Designer Search is. Essentially, it's an online "reality show" design competition that Wizards of the Coast runs when they're light on designers. When the first one completed, all four of the top contestants went on to be hired full time by WotC:
Mark Globus – It was a pleasure to work with him on Uncivilized, and he’s a great manager as well. It’s my understanding that he manages a lot of the Magic designers and developers these days, which frees up Aaron Forsythe for work that he finds more interesting.
Graeme Hopkins – A lot of credit for the success of Tiny Adventures belongs to Graeme. He not only coded most of the app singlehandedly, but was invaluable for making little tweaks to the UI that made the player experience better.
Ken Nagle – By the time that Mark Rosewater finally moves on from his head designer position (I'd guess this is at least five years out), I’ll be surprised if Ken isn’t high on the list to take over. It's clear that this man loves Magic.
Alexis Janson – Out of the four, I’ve worked the least with the winner, Alexis, but she’s a competent Magic player and programmer as well.
So, it’s fair to say that the first GDS was a huge success for WotC, and all eight of the new contestants have a good shot at finding employment as a result of this.
The first round was a series of essays, and since I can’t imagine WotC wanted to read all of them, I’m assuming this was mostly to weed out the people who weren’t serious about the whole thing. This was so that they didn’t pollute the next round, which was a multiple choice test that was automatically graded, with some percentage of the top scores moving on. I question the validity of that test in terms of finding strong designers (and there’ve been plenty of complaints about specific questions), but it did weed out people who don’t know Magic well, and some concessions have to be made to make the whole process realistic.
Now, Wizards has posted the essays for the finalists, and while I haven’t read them all, it did catch my eye that Jonathan Woodward’s answer for “worst mechanic in Extended” was kinship. As the designer of kinship and the lead designer of Morningtide (the set where it premiered), this piqued my interest. I’ve always had a soft spot for kinship and thought it was a reasonably successful mechanic for the “class matters” set that Morningtide was. Anyway, here was Jonathan’s reasoning:
"Of all of the mechanics currently in Extended, kinship is one of the worst. If the top card of the controller's library matches a creature type with the kinship creature, the controller gets a beneficial effect. In theory, this is exciting! In practice, however, there are two problems. The first problem is that the mechanic is very linear; instead of playing cards because they're fun, or good, a player needs to play them because they share a creature type with his or her kinship cards."
To me, this seems akin to saying that kicker is a bad mechanic because it’s very modular and therefore doesn’t give deckbuilders any guidance. Linear versus modular is a spectrum where both sides have their place, depending on the goal of that mechanic within the set. Both have advantages and both have disadvantages, but claiming that a mechanic’s linearity is an inherent problem requires either some specific context or the conclusion that all linear mechanics are bad.
"The second problem with kinship is that the card checked is the same card the controller is about to draw. Assuming that the controller has accepted the linear nature of the mechanic, most of the cards in his or her deck that don't share the kinship creature type are likely to be lands. Therefore, once the player has enough lands, failing to have kinship trigger is likely to be followed by failing to draw a useful spell. This leads to players feeling bad; they see the lands they are about to draw, but can't do anything about it."
While it’s absolutely true that kinship makes the highs a little higher and the lows a little lower when you draw your card for the turn, in my experience, the situation that Jonathan describes doesn’t really happen. Because we intentionally moved the trigger to upkeep, players naturally resolve kinship almost as a side effect of their draw. You look at your card, and either reveal it for kinship, or simply put it into your hand if your Kinship triggers missed. If the trigger was during, say, the attack step (as it was for awhile in development), there would be a lot of time to think about the upcoming land, but with it during upkeep I think it works out nicely.
And, for completeness, here’s a bit of history on kinship since I don’t think I wrote about it while at WotC. Sometime during Lorwyn design, we were looking for a way to separate Lorwyn and Morningtide so that each would have a compelling hook. The fact that most Magic creatures had both a race and a class was fairly new at that point, and I suggested that Lorwyn should focus on race interactions and Morningtide should focus on class. Everyone thought this had potential, so we went forward with that plan, and agreed that we would save themes like “sharing a creature type” for Morningtide. Triggering off of sharing a creature type was a great way to make it suddenly matter that your Goblin is also a Warrior, since it shares a type with that Elf Warrior that you also happen to have.
Kinship was originally designed as something like this:
Synergy – CARDNAME gets +1/+1 until end of turn. (Whenever this creature attacks, reveal the top card of your library. The synergy effect triggers once for each creature type it shares with this creature.)
There were quite a few problems:
- The templating for the mechanic didn’t really work, and if I remember correctly, it wasn’t entirely easy to fix.
- In order to trigger synergy, you had to attack, but in order to be able to attack, you needed the synergy to work. This often led to players just not attacking since they couldn’t be sure.
- It was cool that it rewarded you for matching both type and class, but this was at odds with something that I mentioned in passing above, which is that we wanted you to feel just as good about matching up Warriors as you would with matching up Elves. This made it twice as good to match up both race and class, which took the emphasis away from class sharing across races.
- At first I thought that Changelings revealing other Changelings was awesome, but it became clear that it was awkward that players didn’t really know exactly how many triggers that created (it was equal to the total number of supported creature types, but few people know that number offhand). It also would’ve been an issue for MTGO when that many triggers suddenly popped onto the stack.
- The aforementioned problem of seeing a land during your attack step and then having to “look forward” to drawing it during your opponent’s turn.
We played with this for awhile, and eventually realized that we needed to simplify the mechanic down to more of an all or nothing based on whether or not you shared any creature types at all. This was a lot better, but of course it didn’t solve everything. The next major breakthrough was to move the trigger to upkeep (I have a vivid memory of discussing this with Forsythe in the parking lot of an IHOP…not sure why I remember that), which put the mechanic into a satisfying place. Finally, the name was changed to the much more appropriate kinship, as synergy was flavorless and could describe hundreds of other mechanics. (I’m mediocre at best at naming. My only success at naming a mechanic that I designed was ripple, which somehow remained unchanged in both effect and name throughout development. Of course, that one deservedly gets some hate as well.)
The final interesting point about kinship was that it was one of those mechanics where I ended up pushing for it despite opposition at various points. I know that Rosewater always has epic stories about how he was the only believer in something, and everyone else hated it, and then it all worked out in the end, but this wasn't really like that. There was just some skepticism amongst the team at various points about whether or not the mechanic would end up working out. I always do my best to be objective in these situations, and there were definitely times that I was worried I was clinging to something that wasn't going anywhere, but once everything fell into place I was glad that I did.
Of course, sometimes you have to give up on something even when you still believe in it. My old article The Color Purple is a good example of that happening during Planar Chaos design.
Well, I know I promised more on Tiny Adventures, but life got in the way and then I wanted to comment on the Great Designer Search. Tiny Adventures part two is still coming soon. Oh, and I don’t mean to hate on Jonathan, he’s just the one whose answers I happened to read. I wish him and the rest of the competitors the best of luck. Can’t wait to follow along!
the social mechanics of d&d: tiny adventures
Towards the end of my tenure at Wizards of the Coast, I had the pleasure of being the lead designer on a Facebook app called Dungeons & Dragons: Tiny Adventures. The game was made by a small strike team that had set out to make a game every month. While we didn't quite hit that on D&D:TA, it only took eight weeks for a team of around six core contributors to bring the game from conception to launch.
With no advertising whatsoever, the game rapidly reached numbers of over 350,000 players, exceeding our wildest expectations given the relative lack of mass market appeal of the D&D brand. It was one of the top ten most engaging apps on Facebook (where engagement is defined as daily users divided by monthly users) as 40% of players came back every day to check on their adventurer. Sadly, due to legal issues surrounding the D&D digital rights, the app is currently not available.
In sharp contrast to many digital game efforts, there were so many things that went right with this project. I'd like to talk about the social mechanics, because I think they were unique and interesting in ways that I haven't seen since. Let me note that I can't take full credit for these; I don't think any of us realized all of the strengths of the system until after the fact, and honestly this was a team effort. We had a playable game up and running in a matter of a couple weeks and we tweaked the mechanics until they felt good.
The social mechanics in Tiny Adventures were fairly simple. Whenever you were on an adventure, you could be buffed by any number of friends. Each buff gave you a +1 to your roll for the next three encounters - however, there was a maximum bonus of +2 on a given encounter (in a d20 based game, this meant a 10% bonus that was significant but not gamebreaking). Between each of your adventures, you could be healed by each of your friends once. Normally players would have to wait to recover their hit points over time, but friends could circumvent that and with enough heals you could head out again immediately.
Having more friends playing Tiny Adventures was always good.
In some social games, you'll eventually find yourself in a position where there's no reason to add more friends, because you've already unlocked all the necessary rewards. In Tiny Adventures, even though only two friends could profitably buff you at once, it was always useful to have more active friends because it increased the percentage of the time that you were at the buff cap. For example, with only two friends who played, you could probably expect to have two buffs on you maybe 10% of the time. Add another friend and that percentage increases significantly, but you'll still need 10 or maybe even 20 friends playing actively before you can expect to be at +2 most of the time. Even once you have a ton of active friends, adding more always increases the uptime just a little bit more, especially when you consider that adventures often run overnight, and it's tough to find people who are awake to buff during those periods.
The buffs were frequent but not too frequent.
Since buffs only lasted for three encounters, and encounters were around 10 minutes apart, players could buff each other about twice an hour. This is often enough that there were usually buffs to refresh if you're checking in frequently, and it contributed to the need to have a lot of friends in order to maintain maximum buff uptime. At the same time, it wasn't frequent enough to be overly annoying, like single encounter buffs would have been.
Players couldn't see how many buffs their friend already had.
The reason this worked well was that it removed a potential source of discouragement. If you could see that your friend already had five active buffs, you might not bother adding another one, since you'd know it wouldn't do anything. But since you couldn't, players got in the habit of buffing all of their friends.
However, players could see who had buffed and healed them rather easily.
The recipients of these actions feel great because they see how many of their friends have taken the time to help them out. This led to feelings of jen being commonplace in the game. Jen is a Confucian concept that Jane McGonigal brought up in a GDC microtalk, meaning "a mixture of humanity, benevolence, and kindness not well captured by any word or phrase in the English language." Designing mechanics and interactions that encourage it (like Left 4 Dead's reliance on your friends to save you from special infected) is a great way to make players come away from your game feeling better about the world.
We intentionally didn't add "buff all" or "heal all" buttons.
Even though this was a frequently requested feature, we chose not to implement it. Instead, we made it incredibly simple to buff each one of your friends, but still made you do it individually. We felt that this was important for making it feel like a directed act of kindness rather than a mechanical action that everyone would ritually click without thinking about it, which would in turn cause them to expect it from others without thinking of it as something special. Additionally, the individual buffs and heals meant that you spent more time on your friends page, which showed information like the name of your friend's hero, their level, their current adventure, and their current score, and kept you invested in their progress.
It was important to keep your friends playing actively.
In some popular social games, all that matters is the number of friends you have who have accepted your friend request inside the game. Once that happens, it's irrelevant if they continue to play or not. It worked in Tiny Adventure's favor that you needed people to be playing actively in order for them to help you. When someone messaged you to ask for a buff, and you log in to give it to them, it's easy at that point to just go on another adventure and get right back into the game.
You didn't have to have any friends at all.
In the early days of games like Mafia Wars, you had to convince friends to play or you literally couldn't progress in the game at all. Thankfully, games have moved past that, but it's still common to cripple a player pretty heavily if they don't feel like spamming their friends with invites. I think we struck a nice balance in Tiny Adventures, where players weren't forced to have friends who played but it did add convenience and a meaningful amount of power.
When you failed an encounter because of lacking buffs, you tended to blame your friends, not the game.
In many social games, when you are penalized due to not having enough friends, it's easy to become angry at the designers or the company for putting in the requirements and/or friend bonuses. But in Tiny Adventures, when you fail an encounter by 1 and you were missing a buff, you didn't tend to hate the game for that. Instead, you were annoyed at your friends for not buffing you, and you would make sure to remind them to keep the buffs coming.
There were distinct reasons to ask friends to help you out right now.
When players had a tough encounter coming up and they saw that they only had a single buff, they would often message a friend and ask to be buffed. Or, when players finished a tough adventure and needed some extra health to start the next one, they could message others and ask for heals. Rather than the app spamming their newsfeeds with posts about how their friends could get a little bit of gold by clicking, Tiny Adventures players were invested enough in the bonuses to ask for help personally. All it took was one or two encounters that were failed because of a missing buff, and everyone understood the importance of helping out.
That ended up being way longer than I intended, but that's my take on the success of the social mechanics in Tiny Adventures. Thanks for reading! There's so much to say about this game, so I'm sure I'll do another blog on this topic at some point in the near future.