… they all passed the butter to each other too politely.
—Murder in Mesopotamia
… they all passed the butter to each other too politely.
—Murder in Mesopotamia
Blizzard advertised and pushed their new expansion for nearly a year. Blog posts, videos series about backstory, a major pre-launch patch that phased in partial changes to ease the transition. Then, launch day arrives, servers bit the dust, and those that remained standing had entrance queues six thousand people (and several hours) long.
A day and a half after launch, my brother still hadn’t been able to sign on to play his mains. So he, Pink and I decided to play toons from years ago that were sitting on near empty servers.
It was a fun night, but also weird to play the new content for the first time on old, forgotten toons.
So what was up with Blizzard? Well for now looks like a denial of service attack pushed Blizzard’s woefully insufficient hardware set-up over the edge. And when things held together long enough for people to actually get in the game, the introductory storyline piled them all in only a few zones, which caused the servers to crash.
Tech’s easy to get wrong I guess…
So I’m rereading Steven Brust‘s Vlad series and this novel’s ambition threw me for a loop. On one level, I was happy to realize how the series–which reads as episodic–is maintained by carefully planted seeds that bloom in later books, which means the series is being written and not just the books. But I was also astonished to see the attention to structure that went into this book’s incredibly intricate approach to narration. Which I have to describe for later.
There are three lines of action in this novel. Each set in a different time and each progresses at a different pace. They are:
Storyline A: Vlad’s Contract with Sethe
Storyline B: Vlad’s Childhood
Storyline C: Vlad Saves Morrolan
Each storyline progresses in each chapter, and each chapter follows a strict framework for advancing the three stories. Storylines A and B are each developed chronologically in alternating segments within every chapter. Unless I missed an exception, chapters always begin and end with fragments from Storyline A, and I’m pretty sure that most chapters had at least two fragments from Storyline B. This means most chapters divide their pages into at least five story fragments.
Storyline C opens each chapter and is always presented as an italicized epigraph. Read in isolation, these epigraphs narrate a single scene. Because Storyline C is an event in storyline A, there is necessarily a point where the two must intersect. This intersection occurs in the break between the last two chapters and is handled so as not to cause the last chapter to deviate from the established arrangement of story materials.
How is this done? The final lines of the second to last chapter (these lines belong to Storyline A) lead into the first lines of the epigraph of the first chapter (which belong to Storyline C). If you flip through the chapters reading only the epigraphs, they narrate the scene from Storyline A that occurs between the second-to-last and the last chapters of the book. The epigraph of the last chapter then recounts the final moments of Storyline C and concludes in turn with lines that lead directly into the fragment from Storyline A that opens the main text of the final chapter.
This is complicated, I know. (Trust me. I had to figure out how to describe it.) But this complication is not idle. It changes the most distinctive effect of the novel: its voice. This complication shifts the narrative point-of-view by “pushing” the first person narration of the earlier novels “inside” the book slightly, making it subordinate to the implied authorial voice that weaves Vlad’s three first person narratives into the book called Taltos.
This weaving is rich and can even feel self-reflexive (After all, Vlad isn’t the only one here casting a spell from disparate pieces of material.) But more important, it’s a sign of careful, skilled writing and it’s damned impressive.
I was shocked by how dark Steven Brust’s Yendi is. I had forgotten. Reading it now, I wish I could remember what I made of it when I was a teenager. I suspect I was completely confused by anything that didn’t involve Vlad “working.”
What I find most impressive is the way this book refuses to present moral or political disagreements as simply problems of knowledge or of framing. They are also problems of love.
In this novel, people believe things strongly, but the best of them decide what to do based on whom they love and on the ways they find to keep loving them even across substantive disagreements.
You wouldn’t know that’s what the book’s about from the blurb on the back cover but it is. Honest.
The beginning of things, of a world especially, is necessarily vague, tangled, chaotic, and exceedingly disturbing.
–Kate Chopin, The Awakening
Right off the bat I should say that I’m still learning how to use attributes. Outlines, map views, links, these I understand, and I see how they help me. Attributes feel very different to me, and I’m a bit intimidated by them. [note]Attributes remind me of databases. The problem is that to me databases seem like sticks of dynamite threatening to blow everything I know into pieces. They promise big returns, but I never trust I’ll be able to implement them in a way that delivers on their promise. Tinderbox substantially lowers the stakes of a database-based (!) approach by reducing the requirement to plan extensively in advance, but my anxieties remain. As a result, I actually find imagining and making attributes more challenging than writing the action scripts that affect and use those I already have.[/note] As a result, I think I tend to use them more casually than many people who use Tinderbox do.
For now, I mostly use attributes in two ways: as labels indicating stable information that I will use to identify notes visually; and as “tags” to temporarily keep track of time-sensitive information through an agent. The first use is straightforward. If I see “Organization A” in the key attributes of a note, I know the source of the information I’m looking at. The second is a bit more complicated.
Imagine a situation in which I’ve requested some information from a group, course preferences perhaps. To keep track of who has submitted the information and who has not, I would create an attribute called “CoursePreferences,” set it to boolian so I have a checkbox to work with, and then add the attribute to my key attributes. I would then create two simple agents. One would search for boxes that are checked (i.e. a value of “true”); the other, for those that are not (i.e. “false”). [note]I would also limit the agent search to the container with the group members’s notes or by prototype. Otherwise, my agent searching for unchecked boxes would be filled with aliases for every note in my project.[/note] As people submit their material, I would be able to check them off easily and my agents would move their notes automatically from my “checked” to “unchecked” lists. When my “unchecked” agent is empty, I’m done and delete both the attribute and the agents.
For this second situation to be worthwhile, I need to be able to create and delete a user attribute (and to set it as a key attribute) quickly. I give instructions for doing all three tasks below. These are followed by a video that shows what things look like in practice.
To create a new attribute:
Note: in the video you will see that when I type “Organization” the text goes red. This indicates that the attribute name is already in use or doesn’t conform to the naming rules. Adjust the text to something that shows black, and you are good to go.
Deleting an attribute is easy.
…and it’s gone. So again, be careful!
Tinderbox 6 has made managing key attributes ridiculously easy. To show an attribute at the top of the text window for a note, simply click the “+” button next to the note title. A pop-up shows all of the current key attributes of the note. Click somewhere in the list, begin typing the name of the attribute you want to add, select it from the menu that pops us, and you’re done.
Remember: If you change the key attributes for a prototype then all of the notes that it controls will inherit the change. That’s a good thing. If the prototype is selected while you create the attribute, you can tick the checkbox to add the new attribute to your key attributes automatically.
If ever you see that a note does not inherit new key attributes from it’s prototype and you would like it to, then you simply click the “+” button and then the “reset” button on the pop-up. This should fix the problem.
Next up: simple on-add actions.
(The next video will be the last in this series. Because I’m out of ideas for the moment. If anyone uses these and has suggestions of things they’d like to see, feel free to drop me an email or send me a tweet. I’ll see what I can do.)
Because I’d already reread Jhereg, I started rereading the Vlad novels with Yendi. The characters are trying to solve a series of interlocking mysteries and have to consider the evidence and imagine possible scenarios. So there’s a fair amount of “what if” talk. But these sections are interesting and never bog down, and they are interspersed with quickly paced and complicated sequences that deal with other major plot lines: Vlad’s young business, his turf war with a more established rival, and a romance that involves real danger.
The book is a whirlwind. I’m actually not sure how so much gets packed into so few pages. But it’s really fun and looking back now from the perspective of the volumes that follow, I think it was a great place to start rereading.
Years and years ago, I read all of Steven Brust‘s Vlad novels (or at least those that were available at that point), and I loved them. That in itself isn’t, unfortunately, the ringing endorsement I wish it was. I was a voracious reader and tended to have tastes of the same sort as Browning’s Last Duchess (who “liked whate’er/She looked on”).
Still Brust’s books were stand-outs. They were told by a protagonist/narrator with an amazingly distinctive voice that lodged in my mind’s ear and stuck with me. Years later, I could still “hear” it if I sat back and let myself remember.
Not long after starting this blog, I reread the first book in the series, Jhereg. Happily, it was as good then as I remembered it being in high school. In fact, it was better because, with more experienced eyes, I could see how cleverly written it was. So this summer, I decided to read the whole series in its order of publication, revisiting the books I knew and discovering the ones that had come along since I’d stopped keeping track.
It’s been fun, but my initial plan of reading right through the books one after the other has changed. The series is just too good rush through. (…really. It is that good.) So now I’m pacing myself and reading slowly to draw things out.
I read this years ago, but a couple months back, saw it on my shelf and decided to flip through it. A couple hours and a hundred pages later, I was caught up again in the scandal of it all. These characters play for keeps and are terribly seductive. It makes for a great, entertaining book.
Oddly enough (given how different the books are), I’ve come away from Laclos’s novel thinking of Matthew Lewis’s The Monk. Weird.
The merit of a work derives from its usefulness or from the pleasure it gives, or even from both when it has both to offer. But success, which is not always a proof of merit, depends more often on the choice of a subject than on its execution, on a certain combination of subjects rather than on the way in which they have been treated.
–Choderlos de Laclos, Les Liaisons Dangereuses
Outlines and maps are where I do most of my work in Tinderbox, but they function very differently from each other. Effective outlines use a hierarchy of container notes to structure information. Maps organize the notes in a single container using spatial relations drawn onto a flat surface.
Having both tools available to work with the same notes is powerful. Yet, in my early project files, I also found it was easy to wind up in a situation where work I put into organizing my outline limited what kind of work I could do with my maps. (cf. “Boxes within Boxes“)
But there’s a way to avoid this potential problem. Using prototypes and the inspector to adjust typography, you can easily create (or adjust) headings and subheadings that can be used to transform a “deep” outline into a “shallow” structured list that doesn’t limit the scope of the corresponding map view.
In the video below, I use the “Organization Prototype” I created in the last post and the “Events” prototype that is built into Tinderbox [note]You can install this prototype (and several others) by going to File=>Built in Prototypes… .[/note] to create headings in an outline. To do this:
Once your headings are created, you can use shift+Tab to “flatten” segments of your outline’s structure without eliminating its organization. [note]The thin lines in my outline are Separators. They are the outline view’s equivalent of Adornments and can be created using the contextual or Note menus. They can be named or unnamed and are a useful supplement to headings.[/note]
Next Post: Creating and Deleting Attributes
Prototypes are easy to make and manage. So much so that in my early projects I tried to use them for everything. That didn’t work out so well. These days I have fewer prototypes, but those that remain are one of my main tools for organizing material in my projects.
Making a prototype is as basic as basic can be. You simply:
In the video below, I show the process. Near the end, I also point out that the order in which prototypes are displayed in the contextual menu is controlled by the placement of prototypes in your project outline. In other words, you can very easily arrange the contextual menu to suit your needs.
Next post: using prototypes to format shallow outlines.
I’ve just finished recording four Tinderbox screencap videos and plan to present them as a series over the next week.
The videos start out with simple things but end up with something that can seem (but only seem!) complicated. All of them are about using the inspector, an essential but too easily overlooked tool for working with Tinderbox.
I hope they’re helpful. And if you find they are, then you should definitely check out Mark Anderson’s Tinderbox Reference File and the Tinderbox User Forum. They are where I go to figure out things that have me stumped.
(Links to the posts will be added to the bullets as they go live.)