Anyone But Harper

You've probably seen this already, or something like it, but it's important enough to keep passing around:

Anyone But Harper

That is all.

Them Bitey Jaws

I've been playtesting a variety of rules for the DINO-PIRATES OF NINJA ISLAND game, and they're starting to settle down into a pretty cohesive whole. The process has been interesting on a lot of levels, but one in particular struck me -- the ability to adjust one's die roll AFTER one knows if that roll was successful.

Virtually every system that allows such adjustments (through some sort of point mechanic that allows the player to add to their roll or to re-roll a given die) requires the player to apply the adjustment before they know the outcome of the roll. The player is asked to gamble that A) the adjustment enabled by the resource will increase their result sufficiently to succeed, and B) that their original result was insufficient in the first place.

When I started working up the Stunt mechanic for DPoNI, which I originally got from iwatt, I used the same thinking. You could apply bonuses to your checks based on your skill ranks, if you got creative and gave me a good description. But folks didn't use the stunt rules all that often. Usually they'd forget in the heat of battle, or just shrug and hope for a good roll without the bonus.

I hadn't gotten the rules right. This was a cool idea, something very much in line with the feel I want for DPoNI, but my players weren't naturally gravitating to it. I took out a few of the other optional rules I'd implemented, but stunts remained a little-used feature.

It turned out the best way to get players to consider stunts was for me to suggest them -- and this started happening AFTER the die roll. If somebody had missed by only a little bit, there'd be a scramble to look over the character sheet and find some over-looked bonus that might apply. Stunts fit the bill admirably. Because they work as a static bonus, rather than a re-roll, they represent sort of that little extra effort that a character makes, using their existing skills, to just do a little better. And because you can apply them after discovering your roll wasn't quite enough, you don't need to keep track of every possibility while making your decisions -- you can discover possibilities afterwards, when you know you need them.

It means characters in DPoNI are a little tougher than standard True20 characters. They'll make successful rolls some 10% more often, depending on their level. And that's okay. DPoNI is meant to be more about coming up with cool stuff to do rather than managing resources and surviving (once again, like ALWAYS) by the skin of your teeth.

I tend to play more of a style where a player says what they want to TRY and do, and then makes a roll, the result of which tells us how WELL they did. So the actual narration of the event simulated by the die roll naturally comes after the roll is made and success is determined. The Stunt bonus, in this context, is more a function of the narration than the attempt. It works like this:

Player: "I attack! I get a... 14."
DM: "Oh, dear. You need at least a 16 to hit this guy."
(player looks over character sheet and notes she can get a +2 stunt bonus from her Acrobatics skill)
Player: "Okay, but I'm using my Acrobatics."
DM: "Okay, you'll just barely hit if you can do that. How are you using Acrobatics here?"
Player: "I run up the side of the cavern, somersaulting backwards and landing behind him, catching him just off-guard enough to skewer him before he knows I'm there."
DM: "Sold."

When a player rolls well, often the satisfaction of the roll is reward enough -- not all players feel a need to narrate something cool at that point. And likewise when a player completely botches a roll -- they're cranky and frustrated and not inclined to jump in with a bunch of creativity.

But nothing spurs creativity like the knowledge that if you can come up with something, you can snatch victory from them bitey jaws of defeat. So what do you think? Is this a reasonable way to run things? Does it require too much adjudication on the DM's part? Should NPCs get the same benefits?

Fish photo: Gavin Mills

The SLAVE QUEEN Arriveth!

She's been promised for months, but at last here she is. THE SLAVE QUEEN OF THE RUINED CITY is the first official DINO-PIRATES OF NINJA ISLAND product available anywhere! On sale now at YourGamesNow.com for the low price of $6.00!

With a fantastic cover from Claudio Pozas (who also provided a number of full-colour character illustrations), this True20 adventure provides plenty of thrills and chills, along with seven sample PCs, two 1"-scale maps of key encounters, new monsters, and handy NPC stat charts, all designed to make the job of turning these 32 pages into an evening's entertainment as painless as possible.

THE SLAVE QUEEN OF THE RUINED CITY promises pulpy goodness from start to finish. This adventure includes all five of the necessary elements for any DPoNI adventure:

• Dinosaurs


• Pirates


• Ninjas


• Monkeys


• Robots

We're awfully excited about this release, and it's only the first in what promises to be a long line of thrill-laden products from Scratch Factory Productions. This release of THE SLAVE QUEEN OF THE RUINED CITY uses the standard True20 rules, but soon we'll be making the official DPoNI rules available and when that happens, you'll see a revision to this adventure to use those.

Just read the opening paragraphs and if they don't grab you, then what are you hanging around here for, you snot-nosed brat?

Hidden amongst the tangled archipelago off the coast of the Empire, the cliff-ringed haunt of the legendary SLAVE QUEEN is one of the most feared and storied of all. Legend says she lives in barbaric splendour amongst her pathetic thralls, always seeking more captives to bend to her will. Night and day, hellish screams echo out from the high cliff-side caverns. Even in the thrashing midst of a storm like the one you're sailing through, you can hear those screams.

Even over the crash of your ship running aground on the knife-like rocks beneath her cliffs. Your ship is taking on water. The captain just fell overboard. Things don't look good.

Huh? If that doesn't sound like the right way to start an adventure, I don't know what to tell you. I mean, either I had you at SLAVE QUEEN or I didn't, is pretty much my thinking.

The New Big Problem

At a table during last week's Business of Software conference, I met a fellow whose name escapes me now. Hardly a new occurrence for me, but I do recall the topic we were discussing.

His company does big data migrations for big government agencies. So for example if you're in charge of running the standardized health insurance across Ohio, you need data from every hospital in the state. And of course, each of these hospitals has been storing their data in some insane scheme that was cobbled together by the Pascal programmer who wrote the original record-keeping software back in 1975. It probably wasn't insane, actually. It probably made perfect sense. At the time.

The real problem isn't that this particular Pascal programmer was insane. The problem is that there was more than one Pascal programmer in Ohio in 1975 (I'm guessing, here, but give me a pass on that one). And so the solution that Pascal Programmer A chose for Hospital I was different (perhaps very different, perhaps a little different, doesn't matter) than the solution that Pascal Programmer B chose for Hospital II. Even if the SAME PATIENT was recorded in both hospitals, the data would look subtly different. Pascal Programmer A recorded First_Name and Last_Name as separate columns in a Patient_Data table, while Programmer B made sure NameF and NameL were stored as columns in a Personal_Info table. That's a trivial problem to solve, of course, if you're only worrying about these two databases. It gets more substantial if you're dealing with thousands of databases.

And not all problems in this space are trivial. The same data (or same types of data) can be stored in literally an infinite number of ways, and given the oft-frustrating creativity and ingenuity of people, you can bet that there will be as many variations as there were people involved in the varying.

So this gentleman I met obviously has his work cut out for him, and from what I could tell appears to be doing a roaring business handling this sort of thing. Because if you do want this sort of work done, there's really no solution other than to get a bunch of people to go through all your varied databases and manually map one set of data to the other, then perform whatever complicated trickery is required to do whatever conversion you've decided to implement so that at the end of the whole process, you have ONE dataset that includes everything all the originating databases contained.

And I thought to myself, "Wouldn't it be amazing if somebody figured out how to automate this process? If all the data in the world could just be connected to all the other data in the world? You'd never have to transfer information around, you wouldn't have to keep track of things in various places and forget to update it here after you've updated it there. It would be a transformative thing for the world, if every piece of information we had could talk to every other piece."

I used to think the big problem right now was latency. That the next big innovation was going to appear as some way to accelerate our ability to transfer information from one place to the next. But data normalization on a global scale is BIGGER.

I don't know how it can be done. Just thinking about it, it seems like the most tedious manual process of trivial decision-making imaginable, and yet, how can you derive a process that can look through the masses of databases around the world and understand how they connect to each other? But once you'd done it, well, that would be a world-sized oyster facing you, right there.

I wish I were smarter.

And that's hardly a new occurrence for me, either.

Photo: "network spheres" by gerard79.