While Conclave was technically released in October of 2011, we didn’t really start talking about it until mid-February.  Since then, traffic to Conclave has quadrupled, thanks in large part to players spreading the word.  As we hoped, all those new players gave us a lot more information to work with in identifying good and bad parts of the game; not only could we see, numerically, where players were getting hung up, but our fabulous players also gave (and continue to give) us tons of helpful feedback through UserVoice.

Mid-February also saw a major feature release for Conclave.  Some of the biggest changes:

• Players could join parties mid-quest for the first time, instead of having to wait for the party to finish their quest to do so.
• We opened all quests up to solo play, not just the very first.
• We added new ways to invite other players, like posted links and Facebook.
• We updated quest selection from a simple list of available quests to our new map-based approach.

And so on; you can find the full changelog here.

As our traffic picked up and we began to gather more feedback, we used it to guide additional changes to the game:

• We launched our first gameplay video to help new players more quickly understand the game.
• We added new email controls that give players the option to turn off unwanted email notifications (eliminating many spam reports!).
• Clickable terrain graphics were introduced, providing advance warning of hurtful (and helpful) terrain.
• We added many performance improvements, including a 3x reduction in lag time between one player acting and the next seeing the result.

So what about the future?  Per Yoda, “Difficult to see. Always in motion is the future.”  But here are some things we expect to do soon:

• Show you who in your party is currently online while you are playing or chatting.
• Provide a better system for finding other people to play with.  Specifically, we want to be able to find players in similar time zones, and/or with similar expectations for how often they’ll play.
• Loot!  You want it, we want it, you’ll get it.

It’s been a big couple of months, and we plan to keep that momentum going in months to come.  Let us know if you have any questions, and we’ll do our best to answer them!

To help with that, we’ve created Bones, a dice-rolling app for Google+ Hangouts. If you’ve never tried one before, a Hangout is a group video chat that supports extra features like screen sharing. With Bones, now you can roll dice and share the results with gamers no matter where they live:

To play with Bones, you’ll need a Google+ profile. Then click this button to kick off a Hangout with the app:

After that, you’ll be able to select Bones from any Hangout you kick off; you won’t have to keep using the button. Check it out and let us know what you think!

p.s. Hangouts are also handy for playing our web-based RPG Conclave face-to-face.

1. In the beginning …

Our very first prototype of Conclave had no graphics. We were too busy trying out ideas for gameplay, but even at this early stage you can see that we quickly settled on a tile-based battlemap for the combat part of the game:

2. You ought to be in pictures

It didn’t take long for us to get sick of looking at a text-based interface. We grabbed some placeholder graphics, came up with a preliminary layout, and switched to the default “fantasy” font, which on many browsers is the overused Papyrus:

3. Things start getting real

As you can see, we tested a few different dimensions for the battlemap. We started with 8×12, briefly went as small as 5×7, and finally settled on 7×9. We also made and commissioned some real graphics, replaced Papyrus with other typefaces, and began to experiment with different layouts:

4. The ninety-degree turn

One of our first conclusions from these experiments was that we needed to switch the orientation of the battlemap to make better use of the horizontal screen estate afforded by most monitors:

5. Bigger, better, brighter

Up to this point, our iterations had been fairly incremental and straightforward to implement. Our next one was not. We decided to:

• upgrade the quality and size of the battlemap backgrounds so that they could cover pretty much the whole user interface
• switch from a straight grid to a staggered one that behaves more like a hex map, which had some profound implications for our code and mechanics
• cap the party size at four rather than six
• add more effects to the battlemap: inaccessible squares would be darkened, the token of a character hiding in shadows would be made slightly translucent, and so on

The result:

6. What condition my condition was in

We haven’t made major changes to the battlemap itself since then, but the other interface elements have changed quite a bit as we’ve improved the game. We added persistent conditions like burning, bleeding, and off balance, and we made it possible to review prior events in combat. Both those features required us to rejigger the interface a bit:

7. Good things come to those who give feedback

Since the start of Conclave’s public beta, we’ve made some tweaks based on the feedback we’ve received. We added timestamps to chat messages and an icon to indicate party leadership. We also made it easier to find and manage the party’s settings:

I think it’s safe to say we’ve come along way since that first text-based prototype. I expect we’ll continue making changes, both big and small, as the game evolves.

Who else remembers these?

RPG designers haven’t always looked at the role of probability in action-taking in the same way.  In fact, over time, those designers have made it more and more likely that players will succeed at their actions.

What’s the most common thing players do in RPGs?  They try to whack a baddie on the head.  So let’s start from there and see how likely, historically, you’ve been to successfully whack that baddie.  And let’s narrow it further and look at fantasy RPGs:  what happens when a fighter-type tries to smack a goblin with a sword?  How often does he hit?

If we jump in the Wayback Machine and head to the days of 1st Edition Advanced Dungeons and Dragons, said fighter’s chances ain’t looking so good.  A 1st-level human fighter with Strength 16 – average for a fighter using the recommended method for rolling character attributes – has only a 30% chance of hitting a lowly goblin with his sword.  That’s right:  just 30%.  Now, there were a lot of quirks to AD&D’s system are worth exploring in their own right, as they show other ways in which the genre has evolved; for example, all 1st-level characters had exactly the same chance to hit our poor goblin, but fighters were vastly more effective at higher levels, which is very different from how most modern games handle level progression.  Still, for now, we’ll just stick with our simple number.

In other words, back then, a character could be expected to fail at this core action over and over.  Fast forward to AD&D’s 3rd Edition, and the picture looks somewhat different.  Take the 1st-level human fighter again, still with Strength 16.  He’s got +4 to hit – +1 from having a level of fighter, +3 more from Strength – and he’s facing a goblin with an AC of 15.  This gives him exactly a 50% chance to hit.

Now look at the 1st-level human fighter of today.  He has a Strength of 18 if we use the standard score array and assign his +2 racial bonus to Strength.  This gives him +4 to hit from his strength, +3 more from using a long sword.  We presume he chose the one-handed combat style, for +1 more.  We assume no other bonuses from feats, and that he’s just using his basic attack, instead of a power like Sure Strike.  There’s not just a single goblin for him to face, but most goblins have an AC of 16.  Now he has a 65% chance to hit.

What we see in these numbers is a direct and dramatic climb in the chances of success over the years.  This change can’t have been accidental:  just take a look at the notes on variant rules in the 3rd Edition Dungeon Masters Guide to understand how sensitive the D&D game design team was to the impact of much more minor rules changes than than these.  The designers made a conscious decision to have players succeed more and more often at their actions.

Okay then:  why has the number changed so much over time?  I think there are four interrelated answers:

1. Success is fun.  While letting players succeed with their characters’ actions all the time takes away the benefits of dice-rolling, players will nevertheless have more fun if they succeed more often than they fail.
2. Inaction is boring.  Failure usually results in nothing happening; a miss in combat, or a failed skill check, is usually wasted time.
3. Wasting limited resources feels frustrating.  If I can only cast a certain number of spells each combat, or can only use my special power twice per day, I’m going to save it up for when it matters; when the time comes, I want it to be likely to count for something.  (You can see 4th Edition D&D take this a step further by introducing a number of daily powers that are guaranteed to have at least some effect, albeit a reduced one, even if they fail.)
4. Failing takes time.  Assuming that the rate of foe failure is similar to that of characters (not always true, but close enough), introducing more failures means that the time it takes to resolve a conflict in a game is directly lengthened by the chance of failure, without changing the eventual outcome.

Now, you can have too much of a good thing.  The previous post already explored a bit of why succeeding all the time isn’t necessarily good.  Consider also what happens if the time allotted to a conflict is compressed by a very high rate of success:  that leaves fewer opportunities for player decisions, fewer chances for tactics and dramatic roleplaying, fewer moments where a gamemaster or computer can spring a surprise on the players.

But the point is that the people in the know – the Dungeons & Dragons designers, reacting to ever increasing amounts of data – steadily hiked up the chance of success, because they saw reasons such changes would improve their game.

Now, another factor started to appear in the ’80s, and has proceeded to become ever more significant, which is the rise of computer RPGs – games which began as followers in the trends set by paper and pencil RPGs, but have since switched roles to become leaders.  More on the impact of CRPGs, and the evolution of Conclave’s own use of probability to decide the results of actions, in the next post.

A great roll... but why are we rolling in the first place?

One question a game designer must ask is how often players should be able to succeed at the actions they take.  In many games, success is automatic:  you can’t fail to use a capturing move in chess, say, or to buy a property in Monopoly.  In fact, the majority of non-electronic games are based off of automatic success.  This is not to say random elements – the roll of a die to determine movement, say, or the cards you draw from a shuffled deck – but most such games limit the actions you can take through randomness, rather than leaving up to chance whether or not you will be able to successfully take your actions.

RPGs are one major exception to this rule.  Another is wargaming, roleplaying’s ancestor: Dungeons & Dragons evolved out of Chainmail, which took the mechanics of wargaming and applied them to the swords and sorcery genre.  As part of its inheritance, Dungeons & Dragons relied heavily on dice to determine if player actions succeeded.  (In fact, early editions of Dungeons & Dragons offered options to use dice to handle almost anything you might want to do in the game, from creating dungeons to determining which of twenty forms of insanity a character might develop if rendered insane, to figuring out what might happen if you mixed a potion of invisibility with a philter of love.  More on this topic later in this series of posts.)

Later RPGs questioned the centrality of dice in the game, with many seeking to reduce randomness, and some eliminating it entirely in favor of some mix of gamemaster and player dictate.  Often this came from the desire for stronger storytelling:  both gamemasters and players rebelled at having a story shredded by a particularly ill-timed lucky (or unlucky) roll.  But most RPGs kept dice.  Why?

One reason is that dice can be exciting.  Randomness – uncertainty – creates tension and variety.  This is pretty obvious!

But a second reason is that randomness helps enhance the sense that the RPG is a simulation of reality.  RPGs inevitably seek, to varying degrees, to simulate some version of reality, some cosmos.  In the real world, we are used to the idea that our actions will not always succeed or have perfectly predictable results.  The abstraction of the die roll provides a simple path to creating the same situation for our characters and their foes.  It’s easier to imagine ourselves into the bodies of our characters when we can’t know if they will succeed or fail within the larger world.

Additionally, as simulations, RPGs must handle a huge variety of possible actions, situations, and outcomes.  The RPG must be able to provide appropriate results depending on whether your warrior is trying to hit a cowering kobold, a veteran swordsman, an ancient dragon, or a deity (!).  Probability is a great mechanism here, expanding success from a simple digital yes-no to an analog range.  Boardgames cover a vastly smaller set of situations; with a simple possibility space comes the possibility of using simpler tools for resolving actions.

So die rolling is good, right?  Hold on there, sparky!  If there’s one thing any game designer, in any genre, knows, it’s that too much randomness – too much of that uncertainty mentioned above – can spoil the game-playing aspect of a game.  Players want to have control, too; they want to feel that their skill has an effect on the outcome of the game.  RPGs are funny beasts in many ways, and one is the tension they experience between giving players the unpredictability and simulationism enabled by die-rolling, and the desire to exert control.  Mess up this equation, and your game will become less fun.

What’s more, dice rolling takes time.  Every die roll involves a wait, and potential distraction from the flow of the game as a player digs for dice, adds up the results, and the roll gets checked against various charts and sheets to produce an outcome.  Such is not a concern with computer games, but you can bet that card and board game designers worth their salt take this sort of thing into account.

Having looked at some theory behind randomness in RPGs, we can next look at how randomness has evolved in RPGs over time – and what it looks like for today’s CRPGs.  That will be the topic of the next post in this series.

If you’re not following @10×10Room on Twitter, you might not have heard our big news: Conclave is open to the public!

We’ve put a ton of work into the game, and we’re thrilled to finally be able to show it off. We don’t think anyone else has made a game quite like it. A multiplayer RPG set in an original fantasy world that you can play from any web-enabled PC, tablet, or phone? And that you can play whenever you have a few minutes of free time, even if you and your friends have different schedules? Sounds kind of crazy even to us, really.

Since we’re a three-person team and this is still a beta release, expect a few rough edges here and there. We’re opening up the game now because we’d like you to help shape it from here on out, and we need your feedback for that.

But enough talk. Go play, and tell us what you think!

Same game, new name

The most obvious change, if not the most significant, is that it has a new name: Conclave. For the first year and a half of development its working name was Bastion, but you might have heard about the recent launch of another game by that name. Although we were using the name first, we didn’t think a legal battle would be in anyone’s interest, and it gave us a chance to come up with something better. The word “conclave” refers to an assembly or gathering, and we think that’s fitting for a game designed to bring friends together online. It also has an important in-game meaning, which you’ll hear more about in the future.

Besides the name change, our summer can be summed up in three words: development, development, development. We received a hugely positive response when we demoed the game at the “Made in MA” event on the eve of this year’s PAX East, and since then we’ve been working to complete everything that wasn’t ready then. To make sure we’re staying on the right track, we’ve also invited small groups to playtest our changes. If you haven’t received an invite, don’t worry; we expect to begin an open beta of the game soon.

The improvements we’ve made include:

• dozens of new character and foe abilities
• interactive terrain for our combat challenges
• forks in the story where party members can vote on a course of action based on their skills
• thoroughly revamped quests and challenges
• a more responsive and graphical interface

Each of those could be its own post, but right now it’s time to get back to work. It won’t be long before you’ll all be able to see the results.

We’ll also be demoing Bastion: Call to Arms at Made in MA on Thursday, the night before PAX East opens its doors. This is an event for Massachusetts-based game companies who want to show their wares and meet other folks in the Massachusetts gaming community. We attended last year, and liked the event a lot, and are now proud to be among the exhibitors.

At some point, I’ll make one of those schmancy brushset titles that shows the runes off in the best possible way, but for now, you get this simple image of each of the ten runes in the set. The runes were drawn by our one and only Derek Bruneau, then processed by me to make them appropriate for use as brushes. There are many more runes in the Bastion world than this, so there’s a good chance another brushset will eventually be in the offing.

We use the runes many ways in the game, all of which you’ll see soon. Runes make their way into quest images, battlemaps, and more. Soon, we’ll teach you what each one means (hint: if you download the brushset, each rune has a label). All are free for your noncommercial use. Attributions and linkbacks are much appreciated!

Unfortunately, the reality of the Chrome Web Store, as it stands, is a little disappointing. The core problem: it’s really hard to find anything beyond a top tier of featured apps. Say, for example, you are interested in finding a new game. You click on Games, and see something like this:

Okay, this looks familiar… very iTunes-like. I think I want an action game. Let’s look at the Arcade & Action section. Well, none the first five games in this section look interesting, so I’ll dig deeper.

Uhm. How do I dig deeper? Where’s the “more” link, or pagination to the next 5 of 322 apps that might be classified as Arcade & Action? The answer: you can’t. The UI will not let you browse.

It gets worse. Say somebody tells me about a game called Lockmaster, but by the time I get home, I can’t for the life of me remember more than that it was “Lock”-something. But hey, there’s a handy search box on the front page of the CWS. Google is good at search, right?

As it turns out, not always. If I type in “Lock”, I get a bunch of results, but none of them are Lockmaster. In fact, the Google folks have stated in the forums that search takes place on whole words only! It looks to see if the search term you entered is in the title of the app, or in the short or long description you supplied. Better hope your game’s name is both really memorable, and easy to spell.

Whatever else is good or bad about the Google Web Store – and there’s plenty more to say on both sides of this one – they made two fundamental errors with their merchandising, both of which are attributable to an odd decision to discount the long tail. First, they made it impossible to browse deep into their store. If we feel like wandering around the store, well, too bad: there are many aisles, but each one is about a foot long. Second, if we have an idea of what we are looking for, and decide to use the search function, it behaves like search from the 1.0 days, incapable of grasping remarkably basic stuff like partial word matches. If we ask an associate to look for something in the warehouse, we’d better have an exact name and spelling ready! These would be important gripes with any web buying experience, but they are difficult to understand coming from Google, given that helping users find what they are looking is Google’s core competency.

The good news is that fixing these problems is nearly trivial, so I have high hopes that we will see fixes soon. It’s a shame they weren’t dealt with before launch, though, as they not only hurt the chances of most games (and apps) getting noticed, but also leave the user with a sense that the store is very shallow, which is surely not what Google has in mind. I hope we see improvement soon.