Month: August 2014

A Catchier Song

My work on Song at the moment is about outlining. I have a story and characters with interesting nooks and crannies but I am working both on figuring out how to layer the story so that it is sufficiently interesting, and how to render that story so that the reader will be as engaged and excited by the story as I am.

I often find that reading craft books helps me during these kinds of activities, not necessarily by telling me what to do or how to write, but by reminding me of the kinds of things I want to be looking for. Maybe one day “reading craft books” will no longer be part of my process, but right now it certainly is – particularly when my actual writing practice may not be as consistent as I would like.

The book I am reading at the moment is called Wired for Story. I will write up a proper review once I have finished and digested it, but it is interesting and constructive in its presentation of the components of story. It gives me a lot to think about, and at the very least reminds me of just how much there is to wire together when building a story of any complexity.

So, that’s what I am doing right now – layering and wiring and complexifying. Soon there will be writing.

Leave a Comment

Fantasy Defense

The Savage Worlds fantasy sourcebook that I mentioned last time turned up*. I haven’t had time to really dig into it but I will post more about the content and how it fits into my plans for a fantasy game for my boys at some later date. In the meantime, I wanted to write a bit more about fantasy gaming.

Dungeons and the Crawling Thereof

What is a dungeon in a roleplaying context?

Well, it’s not really much to do with the real-world definition, which is an underground cell or “close, dark prison” as Chambers puts it. A roleplaying dungeon is a complex of interconnected rooms in which there are monsters to fight, traps to avoid, and treasure to collect. They are classically situated underground, but that is not mandatory: a castle complex, a tree city, or a sinking ship could all be treated as dungeons with rooms to explore and adversaries to overcome.

The AD&D GM materials included a random dungeon generator, tables which you roll dice against so that you get random rooms and their contents – obviously these tend towards the arbitrary, but they can be a diverting way to spend time hacking and slashing your way through them. One of the funniest roleplaying sessions I engaged in at Uni was a random dungeon played for laughs, where the rolls were taken at face value no matter how absurd, along with some very silly set pieces. However, it’s not really roleplaying: the characters are only considered as tactical units, not as people.

One of the reasons I have resisted this kind of arbitrary dungeon delving with my kids is because there is usually so little story. The games I’ve run have been concentrating on storytelling while minimising combat – going to action rounds** for fiddly bits where inter-character timing is important, but mostly just letting the description of action and reaction tell the story. I am going to try to retain as much of that flavour as I can, but there will inevitably be more fighting because the boys have now had a few games of Munchkin.


Munchkin is very silly, entirely by design. It takes many of the roleplaying game concepts popularised in Dungeons & Dragons (D&D) and turns the dial all the way over. It’s a game which specifically encourages undermining other players in combat, focusses on the loot collected during a dungeon crawl while utterly ignoring the geography of the dungeon, and it doesn’t have any story at all.

It’s also enormous fun. Terrible and wonderful things happen to the characters in more or less equal measure, and the game can completely flip in only a couple of turns. One game we played had my oldest’s character*** suffer some deep indignities and then die rather messily at the feet of a stomping dragon, but he ended up winning. It’s chaotic and hilarious.

Playing Munchkin helped lodge a few fantasy game staples in the boys’ heads: class, race and level are basic concepts in D&D, especially the trade-offs inherent in what you choose for your character. So now the boys know that a wizard might be able to control coruscating arcane energies but can’t pick up a sword, or that a dwarf can see in the near dark and lug around twice the amount of gear of any other race but can only run half as fast****. Savage Worlds doesn’t impose quite the same constraints of class that D&D does (or did) but many of the same trade-offs are present.

And so now we’re ready to dive into a dungeon.

Before we do so, however, I do need talk to the boys about the portrayal of women in fantasy.

Women In Fantasy

Fantasy, even more than science fiction, has historically appealed to and been targetted at young adult males, and part of that targetting has led to the pervasive portrayal of women as scantily clad, pneumatic objects: women in fantasy are often shown as fantasies.

Most games (at least the ones I am willing to play) don’t discriminate in the abilities of the characters based on gender: female characters are just as capable as male characters, and even in Munchkin the sex change curse only gives a penalty for one round because of the sudden confusion over how your body works.

But still… the fantasy source books tend to be illustrated with cheesecake. The Savage Worlds book is no exception here, with the cover showing an unnecessarily lightly clad female warrior, even though no one sane would go into battle without some kind of covering over every inch of skin.

So, there is a conversation to be had there before we start the game proper, with possibly a strategically placed paper cover over the unavoidable cleavage.

But I’m looking forward to running a dungeon. There will be puzzles at least as much as fighting, but a dungeon will be fun.

[*] or rather the paper copy did. I already had the PDF, but I haven’t looked at that yet either.

[**] the less combat-focussed term for combat rounds that I suggested last time.

[***] the characters don’t even have names.

[****] the same speed limitations being true of halflings, the non-copyright encumbered version of the hobbit race, leading to the saying that you do not need to run faster than the dragon, you only need to run faster than the halfling.

One Response

NaNoWriMo Looms

A big question for me this year is whether or not I am going to do NaNoWriMo.

Last year was my tenth year participating in National Novel Writing Month. I ended up with a 100,000 word novel draft in hand, and it would be hard to top that. So why try?

I also don’t have anything new to work on. In point of fact, this year’s progress on A Turquoise Song has been slower than I wanted so what I should be doing is finishing the second draft for that rather than finding a new story to write.

On the other hand, November seems to be the only time of the year when I can successfully make writing a priority. The lack of words this summer feels like it was less disastrous than last year’s word drought because it was more conscious, but still – I continue to struggle to find a way to write consistently, and the energy of November’s literary frenzy is very helpful in getting things going again.

The downside to NaNoWriMo is burnout, though. The long work last year was actually less exhausting than other year’s efforts which were harder to get to the end of, but still – it wears you out. I hurried the ending of the 2013 book because I knew I could not continue to write in December.

These are the arguments and counter-arguments that are spinning around in my head at the moment.

But who am I kidding? Of course I am going to do NaNoWriMo. I will use the time to continue the second draft of Song.

The one constraint is that I am going to aim for only 50,000 words this year. The 75k, 80k and 100k splurges are pretty cool, but I have proved I can do that.

What I need to do now is prove that I can turn a splurge into a book.

2 Responses

Sharing Wiki, part 1

After last week’s post, Making Wiki, you may have a Twiki installation on your computer. But what if you have more than one computer and you want to use the wiki on all of them?

This is something I am still working on, especially since one of my machines has lost its wiki install after an OS upgrade.


Let’s look at how you are accessing the wiki: through a web browser, pointing at localhost. “localhost” is the shortcut address for “the machine this application is running on.”

The most reliable way of sharing the wiki between machines is to have one machine host the wiki, then others on the network access it by entering the address of the hosting machine into a web browser.

So if I had a machine ithaqua which was hosting the wiki, on another machine I would navigate to “http://ithaqua/twiki/bin/view/Main”. Or, if I don’t have name propagation setup, I might need to enter the IP address of ithaqua instead.

This method only works if the accessing machine can access the hosting machine, which is only likely be true when they are on the same network*. The accessing machine also needs to have network access when it is reading the wiki contents. Since much of the time I would be accessing the wiki is on the bus when I have no network access, I don’t use this solution.


The second way to share the wiki is to share the wiki data files.

Two approaches are viable here: putting the files into a revision control system, and using a cloud drive to backup the files.

Revision Control

Revision control systems are tools to keep a history of a group of files. They are used extensively in software development, but they are relevant to any task where many files change frequently. There are many such tools, but the one which is preferred for this application is git**.

TWiki has a plugin for storing its pages in git. Using git is preferable over other systems because it automates so much of the merge drama.

git needs a repository to hold the page store in, and this could either be on the host machine or on a separate server somewhere.

At this point I would usually start in on instructions about this approach, but I have had very poor luck in getting it to work. It seems to be a particular problem with version matching the git installation on one machine with the git installation on another. If you can get it working then it would be largely seamless, and it would allow editing offline.

Cloud Drive

What I think is the most likely approach is to modify the wiki config to store its data on a cloud drive, such as Dropbox or Google Drive. In this case I suspect there are some permissions issues to address (ie the web server must be given write access to the user’s data directory) but this seems likely to be easier to set up than git.

However, this portion is still a work in progress since, as I mentioned at the top, I only have one machine with a working TWiki install on it, and that’s the one without most of the data (the data is safe).

Which Is Best?

Each approach has its pros and cons.

Publishing the TWiki from one central machine using the web server is the best for ensuring wiki integrity. Indeed, with more than one user I would say that it’s the only viable option because it’s the only way to be sure of handling editing conflicts. This approach utterly fails when you consider network visibility and offline editing.

My heart tells me to use the git approach, especially since I have the benefit of a public server I can use as a repository, but I have not been able to set it up successfully on either machine, so I can’t recommend it.

Which leaves the use of a cloud drive, which won’t handle merge conflicts as well as git would but has the benefit of using network storage that is already configured.

Now I just have to get both wikis working at the same time!

[*] this is less of a concern if the host is on the public internet, although that introduces many other challenges.

[**] I admire Linus Torvalds immensely, but I really dislike this name.

Leave a Comment

Fantasy Attack

I’ve mentioned the roleplaying I have done with my boys before, particularly the Animal Agents sessions that we played last year. Those sessions were intended to tell stories about the setting and to avoid physical confrontation. They were also using a simplified game system.

Well, the kids are ready for something different: a fantasy roleplaying dungeon crawl.

This has come on because of a couple of things:

  • broader awareness of fantasy elements in culture – they’re both pretty knowledgeable about goings on in The Hobbit and Harry Potter.
  • playing more games with fantasy combat in them – both video games (LEGO Batman, for example) and board games (Castle Panic, and Munchkin)

More about Munchkin another time.

The boys are old enough to deal with more complex rules, especially now that the younger one is reading fluently. Using a full ruleset seems like a plausible thing to do.

That ruleset won’t be D&D though.

Why I Don’t Like D&D

Dungeons & Dragons (D&D) is by far the most well known roleplaying game – it’s the first one I played, back when Advanced Dungeons & Dragons was a thing. I loved roleplaying from the start, but I was always uncomfortable with the opacity of the game system: determining whether a blow hit was a table lookup in a table only available to the GM (or Dungeon Master, in D&D parlance).

Then there were the systems of class, race and level: boxes the characters get put in which punish the player who wants to do something different. Want a fighter with some stealth abilities? You might have to multi-class with thief, which makes advancing in either class more expensive.

More recent editions of D&D have addressed some of these concerns, but they are still terrifically complex. When I joined my current roleplaying group we were playing D20 Modern, which is the D&D system with modern trappings. We had to use a computer program to manage the characters because of all the interactions of different class abilities and bonuses.

One of D&D’s great strengths is the combat system – there are rules, it seems, for everything, from charging into combat to firing spells into melee. This betrays D&D’s roots as a skirmish war game, and it’s not for nothing that there are players who will play arena combats using the system.

The problem for me is that all of this faffing about gets in the way of telling the story.

So, not D&D.

Savage Worlds

Savage Worlds is a much simpler system to learn and to administer. It’s a skill-based system akin to Runequest, but there is a unified mechanic for testing for success: each trait has a die to indicate its level, and you just roll that die type to try and exceed the target difficulty number. Traits are divided into skills and attributes: skills are learned and specific (Drive, Shoot, Persuade) while attributes are innate and general (Smarts, Agility).

Combat is faster and involves less bookkeeping than with D&D. It’s also cruder, but a single combat round* won’t take half an hour** which is the point of the simplification.

The Savage Worlds system itself is generic, that is there is a core rulebook and separate materials for particular settings. The most famous of these (and in fact where the system originated) is Deadlands – a Weird West setting of undead monsters, mad science, and gunslingers. There are many other settings from fantasy to pulp science fiction to horror (including a truly excellent Mythos setting called Realms of Cthulhu).

I now have the Fantasy Companion which includes fantasy races and some specialised rules for suitable magic systems. This should help me build some small dungeons for the boys’ characters to crawl around in.

Next time I will explain what a dungeon is for.

[*] games go to combat rounds whenever there is any activity where timing is important, not just combat. Maybe they should be called action rounds instead?

[**] unless there are a lot of combatants, but scaling combat is one of the harder things to deal with.

One Response

Delayed Wednesday Post

Another outbreak of day job interference this week. I have started Wednesday’s post, but it will not be ready until the evening (Pacific time) or possibly tomorrow.

OK, back to the bug hunting, or at least curation.

Leave a Comment

Gödel, Escher, Bach: An Eternal Golden Braid

In The Diamond Age, Neal Stephenson’s novel of a near future neo-Victorian era, there is a book: The Young Lady’s Illustrated Primer. It is an education in a self-guided story.

Gödel, Escher, Bach (or GEB) is a Young Geek’s Illustrated Primer – I would not be who I am if I had not read this book. There are so many threads of my life that start here.

I have always been fascinated by Escher’s art: the mix of realism and unrealism was mesmerising to me from an early age. So when I saw a book in a local bookshop which mentioned Escher on the cover and included prints of his art – much more than I’d seen before – I couldn’t help but be interested. At the time I was a sixteen-year-old proto-geek: I had a computer and had done a bit of programming but I was still figuring out a lot of things: I was still in the “fail often” stage of learning about computers.

Opening up GEB to read I was amused by the presentation, but I was thrilled by the discussions of symbolic logic, self-reference, recursion, and how they all relate to consciousness and levels of systems. It was not merely a formative text for me, it was foundational: it coloured my interests at University and ever since – it’s why I keep trying to learn Lisp; it’s why I am interested in theories of computability; it’s why I revere Alan Turing in addition to the principals.

But the main thing is that it shone as an involving book about computational and mathematical concepts. I was already interested in these things and I could well have gone on to my computer science degree and career in software without reading GEB, but I would have been less excited by it all and I would have understand less of the underpinnings. GEB is not a textbook in the traditional sense and it would properly be grouped with works of popular science, but there’s enough detail and rigour to be able to work through the arguments yourself. I spent a good deal of time tinkering with the predicate calculus, for example. It’s well-written, which for an even semi-technical book is much rarer than you’d like.

I reread GEB every now and then, because there are always things to learn from it. I still have the copy I had when I was sixteen, although it’s battered and worn so I usually crack open a newer edition, but this is a book that is still relevant thirty five years after its first publication. More people should read it.

You should read it. Go on.

One Response

Making Wiki

This post is about installing TWiki on OS X. It’s a pretty technical post, and rather longer than usual, but that is the price for accurate information.

These notes were tested on versions 10.6 and 10.7.


Wikis are great places to put research notes, and to make connected networks of pages on closely related topics. If you’re writing a novel, a wiki on the subject can turn into a comprehensive encyclopaedia or world book for your story.

You can create a wiki instance for your topic in cloud services like Wikia, but the information is going to be public there. So, you might find a wiki installed on your own computer may be helpful*.

Why TWiki?

TWiki is a lightweight wiki which is nonetheless powerful and flexible. There are many options for a wiki, but for personal use TWiki** has the following benefits:

  • file-based – many other wikis use a database to store the pages, which is one more layer of complexity that I at least don’t want to deal with on a day to day basis.
  • performs well – I used to recommend Kwiki because it was trivial to setup, but it was both much slower and lacked the features of TWiki. (Kwiki doesn’t seem to be maintained any more, anyway)
  • active – TWiki has an active community, so the software is still being updated. There are lots of options for additional feature modules if you want them.

So, that’s why you might want to install a wiki. On to what you need to install TWiki in particular.


You’re going to be doing some command line stuff, and some administrator stuff. You need to know –

  1. how to access Terminal, and how to type commands accurately. Command-line commands are precise and often rely on specific punctuation.
  2. what the admin password is on your machine (what you type when you do system updates)
  3. how to use a text editor – vim and emacs are powerful but we’re not doing anything complicated here so I’ll give the key presses for nano because it’s easy to navigate. If there is another text editor you feel comfortable with then feel free to use that instead.

These notes (which I first posted on Facebook, but I can’t find them anymore there) are effectively a targetted extract from these installation notes:

The changes should only affect the local web server on your Mac, but you’ll be using sudo on the command line which is a powerful tool: be sure you are typing commands correctly.

One last caveat: check the locations and contents of things. As noted in the header, these are notes on OS X 10.6 and 10.7 – older or newer versions may have things in different locations, and obviously other OSs will have things in completely different places***.

Command Line Commands

In these instructions you’re going to be using the command line. Commands you type are presented like this –

$> cd /tmp

… which means to type “cd /tmp” and then hit return.


  1. turn on web server
    • open System Preferences
    • select “Sharing” (last icon on the “Internet & Wireless” line)
    • make sure the “Web Sharing” checkbox is ticked.
    • let’s just check that worked:
      1. open a web browser
      2. type http://localhost in the address field
      3. you should see a page. Default may be just “It works!”.
  2. download package from
    1. you can enter your contact details or choose to skip the form
    2. download the “tgz” bundle
    3. expectation is that it will turn up in your Downloads directory
    4. eg Downloads/TWiki-6.0.0.tgz
  3. open Terminal – it’s in /Applications/Utilities, or type Cmd+Space to bring up Spotlight search and type “terminal”
  4. unpack the Twiki bundle in a sensible place. Let’s use /tmp
    $> cd /tmp
    $> tar -zxvf ~/Downloads/TWiki-6.0.0.tgz
    You should see lots of files being unpacked onto your system.
    $> ls
    You should see a directory called “twiki”
  5. move to web server directory
    You don’t want to run Twiki from /tmp, so we’re going to put it with the web server.
    $> cd /Library/WebServer/Documents
    $> ls
    You should see a few files including “index.html.en”.
    $> sudo mv /tmp/twiki .That ‘.’ on the end of the line means “here”, the current working directory. The “sudo” command will ask for your admin password.
  6. configure Twiki
    • fix directory permissions
      $> sudo chown -R www:www twiki
    • create Twiki config file
      $> cd twiki/bin
      $> sudo cp LocalLib.cfg.txt LocalLib.cfg
      $> sudo nano LocalLib.cfg
      Look for the line which starts “$twikiLibPath” and change it to read –
      $twikiLibPath = "/Library/WebServer/Documents/twiki/lib";
      Then type Ctrl+X, Y, and hit return to confirm the filename.
  7. configure web server
    TWiki is set up, but we need to tell the web server to load TWiki when asked to.First, get the config we need.

    • visit this page:
    • enter the following value in “Full file path to your twiki root directory” –
    • click “No PHP installed” on the “Prevent execution of attached files as PHP scripts” radio button
    • click “Update config file”
    • click “Highlight text”, then copy (Cmd+C)
    • Now, put the configuration somewhere the web server will find it.
      $> cd /etc/apache2
      $> sudo nano other/twiki.conf
      Paste the config text (Cmd+V)
      Save and exit: type Ctrl+X, Y, return.
      $> ls other
      You should see a file “twiki.conf”, amongst others.
    • Now we need to test the config, and restart the web server.$> /usr/sbin/apachectl configtest

      You may see a warning “Could not reliably determine the server’s fully qualified domain name”, but just ignore that. Fix any other errors though.

      $> sudo /usr/sbin/apachectl restart

      TWiki should now load

    • even though we’re not quite done with config, let’s test that TWiki is there. Put this address into a web browser –
      You should see “Welcome to TWiki” and some links.
  8. configure TWiki
    • in a web browser, go to: http://localhost/twiki/bin/configure
    • enter and confirm a password for administration of the TWiki
      • note: this is separate from your Mac OS password. Use something else.
    • click “next” button
    • click “next” on the following page too.
      • you may see some warnings in “General path settings” and it is worth reviewing the guesses that the TWiki installer makes, but it guesses right in my experience.
    • click “Save”
      That’s the initial config. There are still a couple of things to fix up.
    • enter the TWiki admin password you just created.
    • click on “Store settings”, which will probably have errors
      • where it says “Error: /bin/grep was not found on your path”, add “/usr” onto the front of the text field.
      • there are two of these grep paths. Don’t touch any of the other parts of the command string.
    • click next
    • click Save
    • click “go to twiki front page”
  9. setup Twiki user
    Nearly there!

    • your Twiki install is functional, but in order to create pages you need to create a Twiki user.
    • click “Register” next to the “Twiki users” control
    • fill in the form. TWiki names are usually in the form “FirstnameLastname”
    • hit Submit
    • click on your WikiName link to go to your profile page.

Now you can go ahead and start creating pages:

  • type a wiki topic into the Jump field
  • create a topic home page
  • type in wiki links for things you want to turn into new pages, then click on them in the finished page.

[*] I will be talking about sharing wikis across multiple computers in a later post.

[**] and indeed Foswiki, which I had somehow missed and which is the spiritual successor to TWiki.

[***] Linux I might be able to help with depending on the distro; for Windows you’re on your own.

Leave a Comment

Secret Rooms

A Secret Treasure Room for a Birthday Present

When I was a young kid, I often dreamed of finding a secret room – especially one only I could get into. There was a section of wall in the house which always seemed like a good candidate for finding such a hidden room, right by the doors to my and my sisters’ rooms, never mind that my parents’ room was on the other side of it. It made sense in six-year-old dream logic.

I grew up in a Victorian terrace, which was in truth replete with nooks and crannies: a cupboard under the stairs akin to the one Harry Potter grew up in; an oddly-shaped attic; a huge cellar… another secret room seemed plausible. And the houses in books like The Lion, The Witch and the Wardrobe seemed very much like my childhood home* – just with older furniture in them than we had.

Then the belief in secret and hidden rooms was reinforced by visits to my grandparents’ houses. My mother’s parents lived in a bungalow** with hidden rooms in the cellar, and then my paternal grandparents lived in an old*** bakery in Oxfordshire which had started out as a complicated enough building (as conversions of industrial buildings often do) but had been added to and extended over the years so that everywhere you went there was another hidden room behind a narrow door and a vertiginous stair.

So it never seemed so improbable to have a hidden room, somehow – magical, perhaps, but a mundane magic rather than a wild fantasy.

Then it happened to me.

When I bought a house in Britain my then partner and I viewed the house and we believed that we’d seen all the rooms – three bedrooms, kitchen, a couple of reception rooms, and so on. It was about two weeks after taking possession that I closed the door between the scullery**** and kitchen and there it was: a door I had never seen before.

It was just a cupboard under the stairs, but still: it was a new room where none was expected and I felt that thrill of finding something unexpected and a glimmer of hope that it would be as wonderful as I had hoped.

That’s the kind of wonder you don’t get often in your life.

[*] which was of course wrong, because we didn’t live in a big house in the country, we lived in a narrow terrace in a small town. And I am pretty sure that the professor’s sprawling pile was built a lot earlier than 1890. But, again… six.

[**] in the British sense of being a single-level house, rather than the American sense of being an architectural style with as many floors as you like. I once viewed a house in Portland which was billed as bungalow but had four floors.

[***] as in actually old – 17th century, I think.

[****] too grand a word for a connecting hallway, but it was where the washing machine lived so it’s appropriate.

3 Responses

The Writer’s Notebook

Last year I wrote about The Writer’s Notebook II, an often-brilliant collection of essays from Tin House. I acquired the first book in the series at the end of last year.

I’m glad I have it.

The subjects are varied, from celebrating the form of fairy tales to writing about sex, and with a healthy dose of revision and structure to stop the whole thing flopping around.

The book opens with an essay on place – what it is, how to evoke it: the use of specific details to induce the feelings you instil into the story. It is a surprisingly chilling piece.

Another whose subject is the scene, that most fundamental unit of story, dissects the tension between showing and telling, and how the different modes intersect with advancing the story or the characterisation.

And so many of these essays, as I finish them, as I digest the words and the meaning of the author, I think to myself: I wish I wrote like that.

For that is what these essays are for me – not just instructive, but aspirational – indeed, inspirational. In a world where everyone knows that everyone else is pretty much making it up as they go, it is elevating for me to read these pieces and think that here, in these pages are the words of some people who maybe do actually know something.

Leave a Comment