Wednesday, May 16, 2012

A Shaking-Loose

Ha ha ha... saw a cool-looking tabletop RPG project on Kickstarter ( this one ) and was getting kind of excited, but then the narrator was like "book and book and pages and book and pages".

I thought "book?"

Okay, there's definitely nothing wrong with books. But as a tabletop RPG, I think it may not be the wisest choice due to high cost and restrictive layout.

I've talked about this before, the slow shaking-loose of tabletop games from the confine of the page. I've mentioned web-based technologies, I've mentioned that there might be other business models that leave everyone happier, I've mentioned a lot of things.

I'd like to try to spell some of them out in a bit more detail.

Let's talk about publishing.

In the end, everything comes down to getting your content to your audience (players and GMs, or whatever distinction you make). Classically, this has been a paper book delivered to the local game store. That hasn't been the best way in decades, but it stuck around because a paper book is easy to reference when you're eating cheetos with four other guys shouting about the length of their swords.

But these days, even that's being replaced. Modern gamers have laptops, smart phones, iPads, and epaper tablets. All of these can be brought to the table and used to display rules. A simple wiki could have quick reference links on the side and content in the middle - click and you shall receive. A giant stack of paper and dice, with a slender wafer of electronics reminding you of the rules and putting up pictures of the nameless monsters your players are struggling with today.

Today, the easiest way to get content into the hands of your audience is to simply give it to them, straight over the pipes they use to read their email and watch their cat videos. Free for everyone.

And, if it's a wiki or some other web site, it's not simply a matter of cracking some DRM and distributing a PDF. You would have to clone the whole site - which can be done, but it's not as straightforward. Moreover, the site can be updated - it can be a living thing.

Let's talk about types of play.

In a classic tabletop game, there are two kinds of play.

One is the kind you're probably thinking of, when a bunch of goons sit around a table (or, as is becoming steadily more common, a video chat hangout) and roll dice all night.

The other is the kind you may not be consciously thinking about: one person sitting and reading your book, thinking about the cool character build she wants to try, imagining what monsters would pop up, maybe even designing an adventure or a dungeon. Solo play. Not playing the "same game" as a bunch of people crowding a table, but still playing your game.

Solo play is important for a lot of reasons. First and foremost, it's what takes a player from "newb" to "fan". Unless people can have some solo play, nobody is going to be able to GM your game because nobody is going to know enough about it to build an adventure.

Solo play is the "traction" of the game. Too much, the car gets stuck in the mud. Too little, the car wheels skate across ice. Either way, the car can't get anywhere it wants to go.

You probably already design your games with solo play in mind, although you may not think of it like that. All the flavor text, all the content, that's mostly solo stuff. It's never going to come up when there's guys sitting around a table, it only comes up when there's guys sitting alone in their room.

So, why not talk about making the two entirely distinct?

You don't need "a book". Instead, you need a reference section full of hit tables or whatever, you need a content section for finding cool stuff, and you need a tutorial section for learning more as easily as possible.

Okay, I split it in three, because "solo play" is actually split into "learning the game" and "combing the content" in this model.

Any way you slice it, it makes more sense to have completely different publications for each of these. And I don't mean "GM's guide" vs "player's guide". Use the technology we have!

How about a wiki for content. Cruise the monster list. A plug-in which generates random starships? Cue it up. Maybe some or all of it is restricted. Maybe there's a forum for people to post their own content - or maybe it's an open wiki and people can add their content right in!

A simple reference page for reference material. Add stuff from the wiki to it, maybe, depending on what you need. This is definitely free: character sheets, combat progression tables, etc.

As for learning to play...

Youtube videos.

Why are you teaching people how to play your game using a still screen? They won't be playing on a still screen! Teach them using a video, because they'll be playing in a moving world with audio and dice. So teach them using a video.

Not just a video of three human beings rolling dice, although that's a good start, but also introduce them into the content of the game using music and video images. IE GM says "you run into a dragon" - video cuts to a picture of a dragon and swelling music. GM begins narrating with the music about the majesty of the dragon and -zwwwwk- cut back to the players, one going "I stab it in the face!"

"But" you say "but how will I make money?"

For a lot of indie tabletop devs, it's taboo to talk about money. So you just go with the old standby and hope people donate to your store for their invisible stack of bits rather than steal it from somewhere.

Let's talk about money, instead.

We're not talking about vast sums of cash. We're talking about being able to make a living doing a tabletop game.

Right now, players can pay for a digital or physical copy of your game. Of course, those are pretty freely available in pirated form if your game has a following, and if your game doesn't have a following, you aren't making any money like that anyway.

So, screw that.

Give away your content. If your players can get it for free anyway, give it to them for free.

What other kinds of revenue can you get?

Donations: Obviously, you can allow people to just give you money.

Swag: Have a store which sells things that people want, but are status symbols not game content. For example, shirts, mugs, titles for the forum account names, mentions on the credits page...

Kick-in Content: Allow people to buy content that doesn't exist, causing it to exist. "If people donate $10,000 through this button, we'll release the Dark Sky update to everyone everywhere, for free! This button over here, same thing, but the Mars Forever update. Of course, if both hit $10k, we'll do both!"

At a lesser level, allow people to buy official NPCs with their name and face, corporations, legendary weapons - any kind of in-game content that can be branded without compromising the integrity of the game world.

Creator Access: Allow people to pay for more advanced content access. For example, access to the sketches and notes the authors create as they work out new content. Access to the content when it is in beta or a week or so before actual release. Alternately, the ability to contribute content to the public content wiki.

Advanced Content: There is some content which can be gated. For example, you could create a database of several hundred thousand random citizens and allow people to access that database. Or an app which generates random starships/nations/monsters/whatever. "Only people who pay $30 a year get full access to this app/data. Otherwise, you only get ten searches per month..."

Attached Game: Although not feasible for every game, it is possible to build a kind of metagame or secondary game which happens on-line. For example, a simple social game where you can fight monsters, using a simplified version of the game rules. Anyone can play, of course, but people who pay can stick in their personal avatars and character sheets.

....

And so on.

Let's do it something like this, instead of doing it in a horribly obsolete way that didn't work very well even in its prime.

Tuesday, May 15, 2012

An IPHI post

To the surprise of nobody, I read a lot of articles about the nature of narrative and story in games. There's a lot of perspectives - the idea that narrative is core to immersion, or perhaps it is something that is built post-hoc and retroactively makes the game seem interesting or whatever. People also endlessly argue over when the term "narrative" applies, as opposed to "story" or "plot".

Let me fog up the air even more by discussing "immediate post-hoc impulses". (IPHI)

So, you're playing Saints Row. You see a crazy pink van. What do you do?

Some people won't care. The pink van doesn't perform any better than any other van, and you can always paint a normal van pink in the customization screen.

But some people feel the impulse to steal the van. It's just an impulse: "Oh, interesting! Let's go see what's up!" What they do with it afterwards is not important right now. It's that initial impulse.

How interesting is a particular part of the game? It's a judgment you make very shortly after seeing the particular part of the game.

Can you try to make your game have interesting tidbits that draw the player in like that? Sure. It's especially important in open-world games, where you need the world to be interesting on its own.

IPHI: you see something unusual, you want to investigate. That's the first, most basic level.

However, if you've ever watched people playing a game like Saints Row cooperatively, you've definitely seen them egg each other on. "Oh, a pink van." "DOOD, steal it!" "Hey, it's a piece of crap!" "Drive it into the hotel, man, there's a jump..."

What I'm saying is that there is a fundamental difference in how multiplayer games are perceived by the players, and it has nothing to do with the game.

One player perceives an interesting thing and interacts with it. But he cannot chain into the next interesting thing, because he has to stop and search his environment for it. Not necessarily consciously - but he has to stop paying attention to his current interesting thing in order to pay attention to the world enough to find the next interesting thing, and there's a gap while that all processes.

If there's a second player, while the first player is interacting with interesting thing A, the second player is processing what else is interesting. He can present a ready-made package. He can say, "hey, player one, this is a cool thing over here!" and player one can drive cool thing A over to cool thing B and chain them together. This leads to a man with a shark on his head surfing a pink van while it launches off the top of a car park into the tenth floor window of a hotel honeymoon suite.

Each player can latch onto the suggestions of the others, thinking "oh, he's already seen it and processed it, I'll just take his labels and thoughts." No gap in the experience where you have to stop and look around and think.

This is a fundamentally different experience for both players.

At its heart, you can say that this is similar to the role of a plot or in-game story progression. It presents you with the next interesting thing. But the in-game story is really pretty bad at it. It's good at other things - sense of scale, of emotional depth, creating emotional investment in new characters, and so on. But for being interesting and entertaining, another player who keeps bantering with you is heads and shoulders better.

Obviously, this has methods where it works better or worse. For example, six players is not better than two players. The pacing generally gets too rocky, as player 1 can't participate in five interesting things at the same time, especially when some of the players are halfway across the map.

Also, players are not all equal at this skill. Some players are poor at judging random pieces of a chaotic environment as "interesting" (I am not very good at it). Others are too aggressive about spreading their judgements around ("HEY GUYS COME LOOK AT THIS HEY COME ON THIS OVER HERE COME ON"). Some discard interesting things too fast for the other player to chain into it. Some can't keep track of the other players very well and therefore provide poorly chosen content for this moment in time.

That said, this is a powerful mechanic that doesn't get discussed much.

The next level in the discussion is also fun:

Can you put an NPC into the game which does the same thing?

Sunday, May 13, 2012

Simple Physics Games

So, I've seen a number of simple physics mechanics used in fairly interesting games, recently. Both before and after Angry Birds - I don't know that Angry Birds really changed how common that mechanic is.

Most of them use some form of gravity + bounce - for example, the dozen or so pirate games where you shoot your cannon, or the million or so "fire as far as you can" games. But don't let that fool you into thinking they are the same kind of game as one another - I'll get to that in a minute.

I've also seen a few gravity-less throw-and-bounce things, which work out similar to billiards, except usually with stats and hit points.

Fundamentally, these games are all about taking your best shot and seeing how well it goes. Well, with the exception of certain pirateship games, where once you understand the arc you just spam the angle of attack and don't worry too much about the particularrrrrs of what ye be hittin'.

The "fire as far as you can" games usually feature no real skill or tactical decision. Some do allow you to affect the flight of the projectile after you release it (jet packs, shoot it, etc), but the level moves by much too fast for the player to register the situation he's in, so they boil down to heuristics and can be considered to have "optimal" solutions, at least for the limits of the player's reaction speed. I consider them like a slot machine where you have the ability to shout "NO" and pound the machine to get it to spin one more time. Which, you know, doesn't make the result any less random, but at least you get two plays for one coin.

I'm not a fan of the "fire as far as you can" games. Instead, I prefer the two other subsets I can think of: the "combo" games and the "accuracy" games.

Combo games usually feature no real control over your initial strike, but you are allowed to build the room in which the projectile(s) bounces. This makes it a fun, if extremely easily solved and short-lived, tactical base-building challenge. I also like combo games because of the long length of time that the projectile remains in flight, but simultaneously remains affected by your choices (of how to lay out the room).

Accuracy games, like Angry Birds, lie on an axis running from "the cascade" to "the pinpoint". Angry Birds is quite far on the pinpoint side of things: there are specific "best shots" and they frequently have specific results. The birds rarely do a whole lot of damage after the initial bounce, unless you've carefully aimed it so that the initial bounce wasn't the point and it's the next impact that matters.

On the other hand, most of the pirateship games steer more towards cascade, where any given good shot will generally hit several targets - several sails, or bouncing from cannons into the deckhand and then up into the sails, or whatever. This complexity means that, while there is still probably an ideal shot, it's not humanly feasible to find it and instead you should fire in at an angle that seems likely to hit all the things you want to damage.

Of course, things aren't cemented into their role - Angry Birds does have some cascade moments, and the pirateship games may have some moments where you really want to hit a particular tiny part of the enemy ship. Also, some games fall midway between the two, such as most of the billiards-style games with no gravity, where you can often wrangle the rebound into something useful, or at least have to worry about the rebound turning out disastrous.

Most of the games are against stationary enemies, and your real enemy is either the timer, limited shots, or both. Some have enemies which fire back, but they usually serve as a complicated timer, where you can knock off the front rank to buy a little more time.

I've been thinking about new styles of gameplay you might be able to pull out of this system. This has led me to think about the core draw.

I think the core draw of the gameplay is watching your play pan out. You make a shot, and then you just watch it. You watch your calculations and instincts play out. That's certainly what I like about those games, and why I'm not a fan of the "fire as far as you can" style games.

Watching your shot play out has a little more depth than you might think. There's nothing wrong with the fast, highly repetitive loop of something like Angry Birds, where you replay the same level eight times before you get the shots just right. There's nothing wrong with the cascade style, either, where the results of each shot have a more complex and interesting result that takes longer to see.

Personally, I think there are two things that are often overlooked which could make an interesting game in this style.

One is level setup. Letting the player affect the level and then feeling great when his shot is accelerated by his booster or feeling irritated when it speeds on by. You would either need to have all the gameplay take place in the same confined map (so the player can hone his placement) or you would need to come up with some clever and interesting way for the player to quickly and meaningfully place level mods.

The other is disastrous rebounds. I really like the idea that a particularly bad shot doesn't just miss: it bounces back and hits you! You need to be careful!

I was thinking about what you could do with level setup and disastrous rebounds, and here's what I came up with:

Witches' Academy. The witches do battle by lobbing magic balls of energy at each other just like any other game. However, you're not going to hit your enemy directly. They are too far away and there is a shield above and in front of them.

When your shot hits the ground, it summons a spirit or monster, which marches in the direction it was going. If it reaches the magical energy pillar of a witch, it tears it down a notch (and then the pillar creates a shockwave that destroys all spirits).

The spirit your energy ball summons depends on how many times it has bounced.

So, if you summon a zombie with your level one spell, you can then bounce your next shot off your zombie's head, killing it, and when that shot lands it'll summon a skeleton. If you bounce your spell off your skeleton's head, it dies and your shot still just produces a skeleton. You need to bounce a lot, but there's no advantage to destroying your own high-level units to do so.

Of course, your enemy's units are also around to get destroyed and give your magic bounces. And it doesn't always work out ideally: if your magic ball is actually bounced back in your direction, your spirit will be summoned coming at you, not the enemy! Or, if you're clever, you could fire it such that it never lands, but bounces up from beneath the protective shield and hits the enemy witch directly.

The game is made more complicated by having somewhat complex interactions between the units, the levels, and the magic spells. For example, that witch's spells are all paper dolls. They don't bounce magic back up, so you can't use them to bounce! And neither can she! That giant crawling spiny centipede can take multiple hits and usually "captures" the shot, so it bounces against the spines several times and gives you a really strong creature! Which, knowing your luck, will be coming at you, not at the enemy.

This level has pits, or lava, or spikes, or traps that move on a timer, or a mechanism which pulls the witches steadily closer to each other... These spirits fly rather than crawl, these kick other spirits down, stunning them, etc, etc.

Another element I liked, but that isn't compatible with that game design, is the idea that you start at a given range from your enemy and it changes. You have to shoot them down before they escape, or before they get close enough to shoot you back. This has been done in a few games, and it's kind of interesting. I think an airship game using that mechanic could be quite fun, although I'm not entirely sure what the best specific design would be. Maybe a ball-on-a-long-chain mechanic, where you can reel the shot in after you fire it to recover it from the sky below you or drag a caught ship closer...

Monday, May 07, 2012

FIIIIGHT

I've been working on and off on a few tabletop games. One is called "FIGHT" and I thought I'd talk about it a bit, half to see if there are any opinions on it, half to clear my head.

If we say that most tabletop RPGs are like the computer RPG, then FIGHT is like Street Fighter: it is about beating people up, tag-team style.

The core idea of FIGHT is that you aren't choosing what to do every round. Instead, you choose which enemy you will fight, for how long, using which style.

I'm trying to keep the explanation pure and short, so here it is:

The style you choose will be a better or worse match against the enemy's style. It's a kind of rock-paper-scissors-esque situation. The key here is the sliding commitment.

See, if Anna decides to commit to three rounds of combat against Barry using a specific style, then she will keep using that style for three rounds. If Barry only committed to one round, in round 2 he can switch his style to a more effective one, taking into account the style Anna is using and will still be using for another two rounds.

Short commitments are a lot better for picking the best style and not getting pummeled... but long commitments earn you powerful momentum points, which can be spent to radically increase your power and do special moves. The first round of any sequence earns no momentum, and every round after that earns one, regardless of whether you're winning or losing.

So after three rounds, Anna will have 2 momentum, and Barry will have a maximum of 1, assuming he went for 1 round and then 2 rounds. Anna could use this momentum to launch a devastating assault on Barry in round 4. Is it worth letting Barry outmaneuver her in rounds 2 and 3?

These choices are made more complex by the variety of styles and style modifiers available and your skill in whichever ones you have, as well as things like terrain, heroes who are available to switch in or assist, enemies available to do those things...

When coordinating your commitments with other players, you get to start to have a bit of fun.

See, you don't have to always be fighting. All battles are one-on-one, but that doesn't mean all characters need to be in battle. As long as at least one player is fighting, everyone else can choose to go into reserve or fight as they prefer.

Units in reserve regenerate 1 HP every other round, but more importantly they are available to use their assist move or switch out. All of these things require that you understand when which characters are going to be in reserve or fighting, and against what enemies.

This may sound slightly familiar, and that's because it is. This is inspired by modern fighting games.

There are some old "fighting game" tabletops such as Street Fighter, but they have a lot of limitations. It's hard to engage multiple players simultaneously, they progress round-to-round, frequently have an extremely complicated move set to work around, and they're just bulky and clumsy in general.

Also, the modern fighting video game is quite different from the old fighting games. The modern fighting game almost always features a tag battle, where managing your tagging/assists is almost as important as actually fighting.

So this game aims to be a bit smoother and sleeker, better suited for teams of players and strategic conflicts.

Yeah, that's a lot clearer than the stack of mechanical details I was slogging through before writing this.

Sunday, May 06, 2012

The Pool Burning Mechanic

Burning a pool for an advantage is a very common mechanic. You can find it everywhere, this idea of spending from a limited pool of resources for a power-up.

For example, in Street Fighter you can use a super move if you spend part of your super bar. In FPS games, weapons with more limited ammo (pools) are more powerful than those with plenty of ammo. In oldschool D&D, your magicians burned spell slots to cast spells.

This mechanic needs to be carefully considered. Normally it is a supporting mechanic rather than a primary one. The reasons are easy to explain: it's the old "quadratic wizards" problem.

See, in D&D a wizard was useless unless he burned up a spell. Low level wizards had a very small pool, so unless the party was going to rest for eight hours every five minutes, the low level wizard was going to spend most of his time useless. However, as the wizard gains levels, he gains spell pool slots, and the whole pool always regenerates at the same speed. Eventually, the regeneration rate matches and then outpaces the burn rate, and you have a quadratic wizard that can burn pool in literally every encounter.

Similarly, an FPS with plenty of ammo, players can spend it like water and not worry about running out.

In a tabletop game, pools usually regenerate very slowly and are prized as resources you absolutely don't want to spend. Hit points are a pool. Health potions in your sack are a pool. Wands of lightning have a limited pool of shots. But if the players get very powerful, these pools become very easy to refill or switch out - someone with eight lightning wands will just go ahead and spam them against everything.

So, the heart of a pool burning mechanic is trying to balance the rate of burn and the rate of regeneration. If you make the pool burning mechanic a core mechanic, you're going to raise the rate of burn exponentially. Can you create a method of regeneration which matches that without regenerating so fast it makes spending pool essentially free?

Let's pretend we have a game where the players have several pools of resources they can burn, and that's their primary mechanic. However, the pool regeneration is slower the more of the pool they have spent.

This is a positive feedback cycle, and is generally an extremely bad call. In a multiplayer game, having the players that do better able to do more better while the players that are struggling have an even harder time... that's generally going to end up with a few gloating munchkins going "man, we have to stop to let you regenerate again?"

On the other hand, you could make it so that the pools regenerate at a specific rate, but if you're low, you can actually go out and refill them using some mechanic that produces role playing. For example, a heroic character might have to help someone to get a rapid pool recharge. A magician might have to uncover secrets that the bearers don't want revealed. You can even make the regeneration system so that the players have to help each other to regenerate pool, which would be fun.

By making the regeneration a core motivation rather than a core limit, you can make the game many times deeper.

Still, at heart, if the game is primarily about choosing how much of which pool to burn, you're going to have a very... fast game. That kind of mechanic isn't very amenable to long confrontations over dozens of turns. Instead, you're likely to have fewer, shorter confrontations. If you want your game to have few confrontations per adventure arc, that's fine.

But if you want to allow more conflicts, you need to either A) radically enhance the pool rules to allow for tons of give and take over the course of a fight or B) come up with another set of core rules to allow the players to act without every action being a worrying choice.

B) is, of course, the path to making your pool burning rules into support rules instead of core rules...

Anyway, that's my thoughts on that.