a series of interesting choices thoughts on game design from paul sottosanti

tiny adventures: depth

Though accessibility is key to social games on Facebook, you can't neglect depth, because you want to keep your players interested in the long run. On the surface, accessibility and depth are at odds with one another, but you can have both if you build your systems carefully. A simple example of how we did this with Tiny Adventures was in giving primary stats to the terrains.

If you recall the way the adventure system worked, each adventure pulled from a set listing of terrains in a specified order. So, we knew that players who had seen an adventure before could figure out what terrains they'd be traveling through. We also knew that with a fully random system, this knowledge wouldn't help players out at all.

To make the terrain types matter, we assigned two primary stats to each terrain. Encounters for those stats would be twice as likely as encounters for any other stat. Savvy players who realized this could pick adventures that were well suited to their character. For example, I would tend to favor adventures with a lot of Dungeon encounters when I played a Wizard, because Dungeons favored Attack Bonus and Intelligence. Within adventures, players could also switch up their equipment based on the upcoming terrain.

A couple reasons why the primary terrain stats worked well:

1. It cost us literally no development time. All we had to do was skew the distribution of encounters that we were writing. So, rather than ask a writer to make five encounters for each stat, we'd ask them to write eight for Attack Bonus and Intelligence and four for each of the others. Then we just threw them all into a random pool with equal selection chance and everything worked out automatically. (If we'd written an equal number of each and just skewed the probabilities, the primary stat encounters would have come up twice as often, and we'd have more frequent repeats.)
2. Players who didn't want additional depth could completely ignore it. Many systems that add depth also add complexity. While on many platforms that can be fine, in the social space you want to be careful about overloading players who aren't ready for it. The best methods for adding depth are often under the surface in a way that will only be found by players who dig for it.
3. It gave players something to discover. There's a lot to be said for straight randomness, but I'm a fan of building in patterns for players to discover over time. I would have been sad if the players had gone through all the trouble to create a stats versus terrains matrix if there hadn't been anything to find. Uncovering the secrets of a system can be incredibly satisfying.
4. It gave players who were going for high scores a subtle way to improve their odds. I'll be talking about the scoring system later, but taking advantage of the terrain knowledge was one of the ways that hardcore players could improve their scores.

I recognize that this system only added something for a small percentage of players, but those are the types of players that will come back day after day, and spread the word about your game.

What else did we do? We had the generations system, which added character skills to the game, but only for players who'd already retired a couple characters (and therefore were ready for additional complexity). We had the scoring system and leaderboards, which gave players incentive to optimize their characters and show off their skills. We had the fixed story encounters, which were a more obvious way for players to optimize, since the actual encounter was the same each time. I think this functioned nicely as a bridge to the primary terrain stats, in that players would quickly realize they could take advantage of the story encounter knowledge, and then start digging more deeply for other opportunities to get ahead.

Little touches like these helped Tiny Adventures become the eighth most engaging app on Facebook when it was released (and the second most engaging game, pretty much).

Takeaway: Don't neglect depth even when you're building for a more casual platform. Look for systems that add depth in a way that players who don't want the added complexity can safely ignore. If the system is too visible, players will feel compelled to explore it, even if they aren't ready.

Next topic: The scoring system and leaderboards.

tiny adventures: accessibility

Even though a game with the Dungeons & Dragons IP is unlikely to break into the mainstream, any game on the Facebook platform needs to have accessibility as a huge priority. People generally aren't looking for hardcore gaming experiences on Facebook. They want something they can ease into, with low time commitment and a gradual learning curve. And since Facebook games are free, it doesn't take much for a player to quit. When a player hasn't invested anything into the game (with a traditional purchased game, they've invested money up front), it's far easier for them to give up on it quickly. On the other hand, social mechanics work in your favor and encourage players to persist through difficulties.

Character creation, something that seems natural to include in any RPG, can actually be a large barrier to accessibility. It asks you to make hugely important decisions at a point when you understand the game the least. That said, it works fairly well for pen and paper D&D, because the DM or other players in the party will often help a new player through the process. But for a single player experience like Tiny Adventures, we decided to just give people a selection of reasonably balanced premade characters that they could choose between. This way, few players ended up making a choice that they later come to regret.

We kept adventuring simple as well. Players just had to choose an adventure and then return in a few hours and read the results. While there was a definite advantage to knowing D&D rules, it wasn't at all necessary. Players weren't asked to choose what skill to use, or choose which enemy to target, or anything along those lines. We were aided by the new 4th edition rules, where characters each focus on a single stat for their abilities, so we just gave every character a single primary stat that increased their attack bonus. Finally, we added tooltips to everything in the character screen that explained how the various bonuses worked.

You're probably thinking right about now that it sounds like we made the game too simple, but there's almost no such thing when it comes to Facebook, as long as you also have depth. I'll be talking about that soon.

Takeaway: Accessibility is key when it comes to Facebook games, and free games in general. Strong accessibility plus solid social mechanics will create the growth that you want.

Next topic: Adding depth while still preserving accessibility.

tiny adventures: the adventure system

With Tiny Adventures we were faced with a question: how do we tell stories, but not tell the exact same ones every time? While we could have simply thrown an endless series of random encounters at the players, part of what makes the D&D experience memorable is the campaign storyline that ties everything together. Yet, we clearly didn't have the resources to emulate a human Dungeon Master.

We chose to create four adventures per level (we had chosen to focus on heroic tier characters only, i.e. level 1 through 10), for a total of forty adventures. Each adventure consisted of a series of encounters, some random and some story driven. To make the random ones feel like they belonged, we chose eight terrain types that essentially functioned as encounter pools. Then we wrote transition text that let the player know when their adventurer was crossing from one terrain type to another. For example, here's the layout for a level 1 adventure:

STRONGHOLD OF THE DROW
Difficulty: Level 1
NAME has heard reports of a cabal of dark elves robbing travelers in the nearby Coilspine Mountains. Because of the thick iron door and dangers inside their stronghold, no one has yet cleared them out of there.

The adventure begins: NAME hiked into the Coilspine Mountains to find the Stronghold of the Drow.
Encounter 1: Random level 1 Mountain encounter
Encounter 2: Random level 1 Mountain encounter
Encounter 3: Random level 1 Mountain encounter
The adventure continues: NAME found an enormous iron door set into a rocky cliff not far from the mountain pass where travelers reported the drow raiders. While watching from a safe distance, he/she saw one of the dark elves wriggle out from behind a small rock several meters to one side of the door. After the elf was gone, NAME snuck up to the rock and entered the Stronghold of the Drow using this secret entrance.
Encounter 4: Random level 1 Dungeon encounter
Encounter 5: Random level 1-2 Dungeon encounter
Encounter 6: Random level 1-2 Dungeon encounter
The adventure continues: Deep in the stronghold NAME heard elvish voices. He/She crept up to a door from which they were coming and peeked in through the small window in the top part of the door. Inside he/she saw several drow standing around a table. The tallest one had his back to the door, and he was gesturing while he talked, repeatedly pointing to a map laid out on the table.
Encounter 7: Final story encounter

This adventure consists of three fixed pieces of text, six random encounters with two possible outcomes each, and one final story encounter, also with two possible outcomes. We liked this because the fixed elements succeeded in telling a consistent tale, but the random encounters ensured that the tale would play out differently each time. The terrain types made it feel like the random encounters belonged to that adventure, when in fact they were part of a general terrain pool, because that was the only way we could possibly create enough content to get the variety that we wanted. I felt like we had succeeded with our goal of making the world and the adventures evocative when I saw that one player, Thomas Denagh, had drawn a map of the world based off of the locations that are mentioned in the game.

The final story encounter gave the player closure by wrapping up the story we had set up in the adventure description. In this case, the final story encounter was always an Attack Bonus check with a Magic subtype (there were items that gave bonuses in Magic encounters). If the adventurer succeeded on the check, this text would appear:

NAME ATTACKED the drow in his back with his/her WEAPON. Then he/she kicked the table over, knocking down the drow witch and disrupting her spell. NAME's surprise attack caught the rest of the dark elves flatfooted and he/she easily ATTACKED them with his/her WEAPONTYPE as well.

And if they failed:

NAME ATTACKED with his/her WEAPON but missed, damaging nothing but the map on the table. When the nearest drow stepped aside, he revealed the drow witch across the table from him. She cast a curse on NAME, bringing him/her to his/her knees writhing in agony. They tied NAME up and took him/her to a cell down the hall. After the drow left, NAME picked the lock and escaped. He/She checked the room where they had been meeting, but it was empty -- save for a few gold coins scattered in the corners.

As you can see, encounter text contained numerous variables so that it could be personalized to the adventurer. All gender-specific words had both forms handwritten inside brackets. Each weapon had a specific verb attached to it, as well as a short name because repeating the full name too many times tended to sound bad. The verbs gave us a chance to make the weapons feel distinct, and allowed us to make the powerful high level weapons feel even more powerful by giving them verbs like "decapitated". Finally, they allowed us to at least give a nod to spellcasting without having to branch a lot of the text; we simply used spell names as verbs (like "fireballed") for the weapons that wizards would tend to equip.

We flagged each encounter as a specific level and only pulled in encounters that were appropriate to the adventure (as you can see above, each random encounter was tagged with a specific level range). We could have built generic encounters and scaled them to the appropriate level, but we bit the bullet and went with fixed levels for three major reasons:

1. It would be lame to get an encounter early in your adventurer's career and then get it again, with the same text but a more difficult check, five levels later. Because we had safeguards against getting the same encounter twice in the same adventure, it was pretty rare to see the same encounter twice in the same playthrough.
2. We wanted to show character progression, and one of the most effective ways of doing that was having the character encounter goblins and kobolds early on, and storm giants and dragons in the later adventures.
3. We could write in specific rewards that were level appropriate. So, if the elf prince that your adventurer just saved was wielding a mithral dagger, he could give it to you at the end of the encounter because it's appropriate for that level. If we were scaling the encounter level we would've had to do away with specific rewards.

The hardest thing about writing all of this text? Figuring out how to work a reward into almost every block of text. Because rewards gained through encounters determined an adventurer's score, we needed all of the successes, as well as many failures, to give a reward of either gold and items. It felt disconnected to just hand out a reward if the story didn't mention it, so we had adventurers looting corpses, looking under rocks, grabbing items off of tables, and who knows what else to justify the payouts that we gave them. In the end, though, it was a blast to work on creating the stories, and one of the most gratifying threads on our boards was a huge collection of quotes that players posted that had made them laugh. I wish it were still around so that I could link to it.

Takeaway: With the right mixture of structure and randomness, you can create experiences that both tell a consistent story and still feel fresh when encountered multiple times.

Next topic: Accessibility

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?

1. 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.
2. 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.
3. 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.

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.