Clade by Mark Budz

I have built up a SF book review backlog that’s dangerously close to going into double digits, so I need to start knocking them down. First up on the chopping block is Clade by Mark Budz which is a book I feel like I read before under a different title and written by a different author.

About a year ago I wrote a gigantic 3 part review of Jacek Dukaj’s mega-anthology King of Pain. It was a huge, encyclopedic size collection of short stories and novellas, chief among which was The King of Pain and the Grasshopper. I wrote about it in part 2 of my review and while it was not my favorite story in the set, I genuinely enjoyed it. I’m bringing it up because at the core it is had the same basic premise and Budz’s novel: it also depicted a world in which a cutting edge biotechnology allowed our species to self-segregate into distinct, non-compatible biological clades hyper-adopted to artificial environments. Dukaj took this idea and kept winding it up until he produced a story about a sort of bio-warfare waste accidentally jump-starting a brand new, fast evolving, hyper adaptive alien life and eventually a kind of biological singularity. Budz on the other hand is more interested in writing a Bio-punk techno-thriller.

Clade: book cover

Clade: book cover

Both authors however start with the same idea: a chain of man made eco-disasters makes the planet near inhabitable forcing humanity to use aggressive bio-engineering to create brand new versions crops and livestock that can survive on a planet ravished by pollution, corporate chemical warfare, and fast mutating rogue commercial retro-viruses. Come to think of it, Paolo Bacigalupi also started with this premise in his Windup Girl but he allowed the civilization to fall, and then wrote about the survivors. Dukaj and Budz both assume human ingenuity can not as much save the planet, but re-make the nature to the point where it can be reigned in and controlled narrowly avoiding apocalypse. The former, explored a setting in which the exponential progress curve is not tapered by the ecological near-apocalypse and new disruptive technologies keep pushing the environment towards another collapse. In Clade the ecological collapse is a wakeup call which results in heavy regulation and tight corporate control yielding a return to stable ecology at the cost of social upheaval.

Dukaj is a bit old school in that he believes that the only entities with enough resources to survive global biosphere collapse are heavily industrialized first world nations. The major superpowers seal themselves against the outside world and employ a kind of genomic frequency hopping to protect themselves from rampant, inexpensive bio-terrorism. Budz, much like Bacigalupi does not believe that the traditional nation state notion can survive in a post-ecology world. He sees old power structures fold and the factual power rests on the corporate backbone that underpinned and financed them. It is corporations that re-shape and re-make their environment, and it is human greed (rather than fear, nationalism and xenophobia as in King of Pain) that shapes the new social landscape.

Your clade is determined not by citizenship, but by your class. You are claded for the job you do, and the neighborhood you live in. Unlike Dukaj’s post-apocalyptic vision of sequence-hopping biospheres, Budz’s Earth is still a global village. As long as you have the money you can travel and go as you please. If you are a blue collar worker, or an unemployed slum dweller however, the “nice neighborhoods” are off limits to you – your body is simply won’t survive there. Don’t even think about stepping into a high end Gucci or Armani boutique unless you want to be coughing and pissing blood for the next few months (provided security guards can drag you out before you go into anaphylactic shock). In fact, even loitering outside the store will probably give you a bad rash. Need to go to a rich neighborhood for work? Don’t worry, they’ll temporarily re-clad you. Just remember not to kiss your wife because she might have a bad reaction and die. As visions of future go, this one is pretty grim, but not hopeless.

Out of the three post-ecology I mentioned, Burdz’s is possibly the most optimistic one. The environment, though far from healthy is stable. The economy is booming. The protagonist is a low wage latino bio-tech support worker cum gardener whose task is to take care of special vegetation genegineered to be used by orbital mining and research colonies. This job was his big break, and he hopes to use it to escape the slums where he grew up. He is an ordinary guy with big dreams and a lot of ambition, and eagerness to impress his supervisors which makes him a perfect pawn in a game of corporate espionage and sabotage.

Budz borrows heavily from the old-school Cyber-punk tradition but makes it feel fresh by imbuing it with modern sensibilities, and replacing clunky and ostentatious plastic and chrome with subtle bio-tech and nano-machines. Instead of Gibsonian cyberspace he describes ubiquitous social networks, and idiosyncratic, self learning, personal assistant AI’s whose buggy programming has them grow neurotic and ever more capricious as they get closer to approximating human personalities.

Unlike Dukaj who chases after the big ideas big payoffs, Budz takes time to flesh out his characters, explore their world, and touch upon the social and racial tensions in a world where social mobility is biologically impossible and the clade system is used as a tool in class warfare. Highlighting these tensions is not his focus though. He is more interested in creating a high-stakes techno-thriller adventure in which the little guy sticks it to the man and gets rich at the end. And it’s a pity, because his version of post-eco-collapse world could have been used for some much deeper and heart-felt exploration of the contemporary social issues. If you’re looking for that, then Bacigalupi is your man. If you want high-concept unrestrained singularity-edge SF go with Dukaj. What Budz delivers is a fun, entertaining adventure with likable characters and couple of memorable set pieces.

Posted in literature | Tagged , | Leave a comment

Non Mechanical Info on Character Sheets

Let’s talk about character sheets for a second. About a year ago I stumbled about a short and interesting blog post in which Jeff Rients asked his readers what “non-mechanical” information they like to put on their character sheets. I found it a pretty interesting conversation back then, and made a note to circle back to it one day on my own blog… And that time is now apparently. This, ladies and gentlemen is how deep my draft queue goes.

Most character sheets in standard, more simulationist games typically have something like this on the back:

Character Sheet

Character Sheet

There are empty spaces on the back for the players to fill out with “backstory” or “character traits”. Unless you are playing a more narrativist type game these will often get ignored. The players will either leave them blank, or scribble down some very basic stuff (like name of their father, so they can go the whole “Gimli, son of Gloin” thing). Every once in a while a player will bring a 6 page backstory which is essentially a bad novel that the GM does not want to read. So everyone just ignores that part of the character sheet and pretends it does not exist.

But it does not have to be that way. I think it is sometimes nice to borrow tools from the narrativist toolbox and spend a little bit of time adding non-mechanical details to the characters. And not just for fluff and flavor. I think these details can be useful for both players and GM’s alike.

Looking at the list Jeff compiled in his post I identified several functional categories that can be used in different, creative ways.

Likes and Dislikes

These can be used as role playing aides for people who don’t usually role play much. Or rather they role play by latching onto the standard tropes for their class or race. So they are the elf who wood elf who grumbles about going underground, a dwarf who complains about stupid elves, a barbarian who lives by a code of honor and etc… But what about things that are not related to their race, or class?

It is sometimes hard to come up with an interesting character concept, but if you as a GM give the player some options they could end up with some interesting combinations.

  • Favorite expletive, intoxicant, prized possession, food, color
  • Ordinary food/smell that you find revolting
  • Ordinary animal that gives you the willies
  • A monster you heard stories about as a child and would love to encounter
  • A city you always wanted to visit
  • Your favorite place (tavern, glade, village)
  • A type of place you hate (graveyards, posh, high class banquets, shady taverns)
  • Your greatest fear (heights, closed spaces, the undead)
  • Favorite song / dance
  • Personal hero or idol
  • Favorite folk story (or book if you can read)
  • A non-combat hobby (fishing, gardening, needlepoint, etc..)

So for example, you could have a Dwarf Fighter who hates snakes, despises rabbit stew, is partial to elven blueberry wine (in addition to a proper Dwarven ale of course) and dreams that one day he will get to fight against a powerful Necromancer like the legendary hero Skalf Blackhammer whom he idolizes. It’s almost a fully realized character, and all you had to do was to pick three or four likes/dislikes from the list.

The benefit of setting these things up with the group at the character creation is that it also allows the GM to set up comic relief moments and other party members to play of each others traits. For example, there might be a running joke of every visited tavern having a rabbit stew special or something like that.

Friends and Foes

These are perfect adventure hooks or freebie NPC’s the GM can use during the campaign. In my experience as a player and GM I noticed that it is often necessary for players to encounter someone from their past as part of an unfolding plot. In such circumstances the GM usually just invents an NPC on the spot. But if each player spends 5-10 minutes coming up with two or three people “they once knew” at character creation the GM may actually have a nifty list of people he can utilize that way. Players on the other hand will feel like their characters are actually more involved in the game world.

It’s usually best to keep these entries somewhat vague so that they can be filled out during actual game play if needed. On the other hand you typically want a wide variety of different characters to choose from to avid the usual “parent #1 and parent #2 plus sibling” trap. Here are some relationships players may want to jot down in their backstory section:

  • An old friend you could call on int the time of need.
  • Your childhood rival
  • One day you’re going to get this person for what they did
  • The parent/guardian who is deeply disappointed in you
  • The parent guardian who is proud of you
  • The sibling who is ashamed of what you have become
  • The sibling or cousins you no longer speak to
  • That one relative you hate who seems to really like you
  • That one person who saved your life or whose life you saved
  • Former business partner who owes you money or you owe money to
  • You were best friends, but then something happened and it was never the same afterwards…
  • Mentor or teacher you have always looked up to
  • Person who forged your (first or current) armor, wrote your spellbook, etc..
  • A friend in high places with a shameful secret you know all about
  • A criminal connection that’s as much useful as it is a liability

Each character will only need maybe one or two of these, and each person should aim to use a different one so you have a wide variety of back stories.

Quirks and Features

One trick I sometimes use when I start a new campaign is to ask players to come up with a Homeric Epithet for their characters. These used to be memetic devices used by the Greeks that helped them to memorize their complex epics, and were used to pad the content so that it rhymed or maintained the meter and timing. By their very nature however they were loaded descriptors that usually conveyed some crucial information about the character. Like Fleet Footed Achilles conveyed the heroes swiftness, power but also foreshadowed his fate.

The stuff players write down on their sheets does not need to be that loaded. Typically a single word adjective is fine. Stuff like: strong, wise, cunning, brooding, fast talking, etc.. For best results, ask players to pick an epithet that does not relate to their class. So you can get an interesting stuff like “cunning barbarian”, “roughneck wizard” and “wise rogue”.

Going even further with that trend, it might be a good idea to completely disconnect these “traits” and “quirks” from the character class, race and concept and simply treat them as fluff. Instead of an epithet each character may pick one or two physical or outward traits from this list:

  • Nervous tick
  • A “tell” when lying
  • One adjective a complete stranger could use to describe you (tall, fat, wealthy, skinny, loud, shady, etc..)
  • Most pronounced facial feature (large nose, bushy eyebrows, broken tooth, etc..)
  • Distinctive scars, piercings or tattoos
  • Accent or regional dialect
  • Meaningful mannerism or inflection that reveals something about you
  • Style of dress (plain, fancy, traditional, etc..)
  • Personal hygiene (is your hair unkempt or trimmed / slicked back? Is there dirt under your fingernails or are they manicured?)

All of these would be things that are obvious. It’s the kind of things a stable boy would use to describe your characters to the city guard investigating a recent burglary committed by your party.

I usually like to assure players that if they pick an “accent” or a “nervous tick” they don’t actually have to role-play it if they don’t feel comfortable doing so. Accents are considered automatic – the NPC’s will notice them, whereas involuntary ticks can be declared either by the GM (when appropriate) or by the player if they want to. Some tells or ticks can’t even be roll-played at all. For example how do you role play a “throbbing vein on your temple”?

Job Interview Questions

I like to call this category “job interview questions” because they include the kind of shit you might get asked by an interviewer who wants to see how you are going to squirm out of a question that has no good answers. But in this case you are not trying to get a job so you don’t need to make your character look good. It is an easy way to add “character flaws”: things your character regrets, seeks redemption for or wants to forget. Or these could be things that drive you – things you seek or want to achieve.

  • What is your biggest flaw? (greed, selfishness, zeal, laziness)
  • What was your most shameful failure?
  • What do you regret the most?
  • What is the one thing you are proud of?
  • What is the one thing you can never forget? (good or bad)
  • What is your #1 drive (wealth, fame, power, knowledge)?
  • What is your greatest ambition (become a real hero, save the kingdom, catch all pokemons)?

A lot of these can be used as potential adventure hooks. What if the potential quest given heard about your shameful failure? What if you have to overcome your biggest flaw?

Knowing what drives, ambitions or flaws each character has also allows the GM to create a relevant carrot and stick scenarios. For example, there is no point of offering mountains of gold to a party whose members don’t care much about wealth and are instead motivated by a desire to become famous heroes, or to redeem their past sins.

Loaded Questions

Finally, here are some “loaded questions” you can ask the party as a whole. These can be easily used as a “team building” exercise and an explanation why all these different characters became adventurers and how they become together.

  • Why can’t you never go back home?
  • Someone knows what you did last summer. What was it?
  • Where did you stash the loot?
  • What are you going to do when this is over?
  • How old were you when it all changed?
  • What did your parents want you to do instead of adventuring?

For example, all of them might have been banished from heir respective home lands for different individual reasons but the experience of being exiles is what binds them together. Or perhaps they are all survivors of the same cataclysm? Perhaps hey all were involved in something shady and it went bad?

What non-mechanical information would you put on your character sheet? What questions do you think are interesting to ask players about their characters during the first sessions? What helps? What is more trouble than it’s worth? Let me know in the comments.

Posted in rpg and tabletop | 1 Comment

Every time you touch the UI you break someone’s workflow

Let’s assume your app is currently in production, and has a non-trivial number of users. By non-trivial I mean a number that makes it impractical for you to write a personalized apology email to each and every single one of them when you lose their data. When you reach that sort of penetration, every time your developers touch the UI or anything directly adjacent to the UI it is bound to break someone’s workflow.

You might think you are fixing a long standing UI bug, or making the user interface more consistent and therefore user friendly, but it does not matter. At least one of your users probably worked the side-effects of said bug into the way they do things and it will appear broken to them afterwards.

Let me give you a few examples from personal experience. This is not a project I am personally involved in at the development side. For once I am actually sitting at the user-end and watching the fireworks. Let me set the stage for you: we have been using a third party time tracking tool for ages now. When we first deployed it, it was a self hosted application that we had to maintain ourselves. This involved periodically rebooting the server due to memory leaks, and applying the infrequent patches and upgrades. Prior to every upgrade we would first test it on a dummy instance, and would have the folks who used the tool extensively to do scheduling and processing time and expenses give it a once-over before we deployed it to production. If there were issues we would work with the vendor to iron them out prior to the deployment. It worked well.

Unfortunately about a year ago they discontinued support and licensing for the self-hosted version and we had to upgrade to their “state of the art” cloud based service. This was nice for me because it meant we no longer had to expend time and resources to maintain the tool internally. The end users were also happy because they would be getting all kinds of new bells and whistles to play with. The vendor promised the cloud version is developed and improved very aggressively based on user suggestions and that their new agile development process can deploy fixes and custom patches much faster than before. It sounded great on paper, but it turned out to be a disaster.

User Reaction

Our users after switching to the cloud platform.

The vendor likes to push out minor updates and patches every other Monday, and like clockwork this results in our ticketing system getting clogged up with timesheet software related issues. We verify all of these and tag-team grouping and compiling them into support requests who get forwarded to the vendor support team, and cc’d to our account manager. This is our third account manager since the switch and I suspect our company single-handedly got the last two fired by maintaining an unstoppable barrage of open tickets and constant demands for discounts and downtime compensation.

Most of the problems we are having stem from trivial “fixes” that make perfect sense if you are on the development team. For example, recently someone noticed that the box you use to specify how many hours you worked can accept negative values. There was no validation so the system wouldn’t even blink if you entered say negative five hours on a Monday. So they went in, added input validation, and just to be on the save side they fixed it in their database. And by fixed, I mean they took an absolute value of the relevant column, and then they changed the datatype to unsigned integer. Because if there were negative values there, they had to be in by a mistake, right? Because who in their right mind would use negative time? Well, it turns out it was my team. Somehow they figured out a way to use this bug to easily fudge time balances on the admin site. For example, if someone was supposed to work five hours on a Monday, but had an emergency and left three hours early, the admin would just go in and add -3 work hours to the timesheet with a comment. It allowed them to have both the record of what the person was supposed to do, and what actually happened. Needless to say, after the “fix” all our reports were wrong.

Typical User Behavior

Ok, so you divide by zero here, put NULL in all these fields, put -1 here, and 1=1 in the date field, click through the segfault message and your report is ready.

More recently, they noticed that there were two ways for people to request time off in the system. You could create a time-off request ahead of time (which had to be approved by a supervisor) or you could submit it as a part your timesheet by putting in 8 hours as “personal day” or whatever. Someone on the vendor’s dev team decided to “streamline” the process and removed the ability to enter time off from the timesheet page. To them it made perfect sense to only have a single system pathway for entering time. Unfortunately my team relied on that functionality. We had a special use case for the hourly contractors which simply required them to record their downtime as “unpaid leave” (don’t ask me why – I did not come up with that). Before they could do that by simply filling out their time sheet. After the upgrade they had to go to the time off tab, and fill out a time of request for every partial day that week, then have that request approved by a supervisor before they could actually submit a timesheet. So their workflow went from clicking on a box and typing in a few numbers to going through 3-5 multi-stage dialog boxes and then waiting for an approval.

To the vendor’s credit, they are addressing most of these problems in a timely manner, and their rapid development cycle means we don’t have to wait long for the patches. They do however have serious issues with feature creep and each “fix” creates three new problems on average.

Pair Programming

Pictured here: pair programming as implemented by our vendor.

Majority of these stem from the fact that our users are not using the software the way the developers intended to. They are using the application wrong… But whose fault is that? Should paying customers be punished or even chastised for becoming power users and employing the software in new, emergent ways rather than using it as you imagined they would? Every botched, incomplete or ill conceived UI element or behavior in your software is either an exploit or a power user “feature” in waiting.

I guess the point I’m trying to say is that once you deploy your software into production, and make it available to a non-trivial amount of users, it is no longer yours. From that point on, any “bug fix” can an will affect entire teams of people who rely on it. A shitty feature you’ve been campaigning to remove is probably someone’s favorite thing about your software. A forgotten validation rule is probably some teams “productivity crutch” and they are hopeless without it.

Full test coverage may help to limit the amount of “holes” your users may creatively take advantage of, but it only takes you so far. There is no way to automate testing for something you never anticipated users doing. You won’t even discover these emergent, colorful “power user tricks” by dog-fooding your app, because your team will use it as intended, rather than randomly flail around until they find a sequence of bugs that triggers an interesting side-effect and then make it the core of their workflow. This is something you can only find out if you work with genuine end users that treat your software like a magical, sentient black box that they are a little scared off.

Posted in programming | 4 Comments