Thunk — an introduction

I’d like to talk for a moment about Thunk.

Actually, it might take a while.

But first, history!

Thunk is a tool for writing lore. Specifically, lore one would accumulate if one was to write a fantasy / sci fi novel. Its purpose is to make adding random thoughts to your large pile of thoughts easy, to keep your knowledge cohesive and consistent and to make it refactorable. More on these three in a later article.

Thunk originated from my frustration at translating a collection of story / plot / setting / theme / moral / etc ideas from my head onto paper. I felt like the only way of getting these ideas out was to actually write a story. From the start, till the end. Sure, you can do things like plan out major events chapter by chapter, but it was still not a process I was comfortable with. I wanted to get stuff out about a specific character, without having to tease bits out over chapters. Linear writing didn’t seem as.. efficent as software development.

The next step would be to take one character and write a ‘bio’ about that person. That sort of works, but it’s really just writing a small story about someone. The process was still not abstract enough! I felt like the ultimate approach would be to the rigididy of a data-entry type approach for actual fact-knowledge about characters, while the prose would be freely written as normal, drawing from the set of knowledge I had built up.

My original idea was simple, it would be XML with an editor that automatically generates a schema – thus providing tag completion and some validation – and an editor to take advantage of that schema. So, you could write:

  <name>James Taylor</name>

The next time you created a <person> element the editor could guess that you needed to fill out a name and hair colour.

However, not even coders like XML, and its legendary verbosity was going to be a problem. I looked a few other options: wiki format was nice (linking and what-not) but didn’t provide much in the way of structure; mind maps developed information in a similar fashion to what I wanted but don’t work for anything larger than a sentence and are always acyclic; knowledge maps may have been closer but I could make head nor tail of them.

After much agonising and wringing of hands I finally came up with something that I was comfortable with. Thunk was born.

There are three main parts to Thunk, one of which I’ve implemented the basic of in Java, another I’ve thought a bit about and a third I’ve barely thought about at all.

Since the last two parts are still pretty much only in my head I’m going to talk about the first part, the data model.

The data model

Thunk is, at a high level, a simple directed graph. The complicated aspect are the nodes themselves.

Introducing: the ‘Thing’

Each node represents a Thing. A Thing is exactly what it sounds like, it’s a character, a place, an artifact, a race etc.

Each Thing has at least two entries in it, a ThingType and an id. A ThingType is exactly what it sounds like, a type of Thing. So you could have a ThingType called ‘Character’ and all your characters would use that ThingType. They are what bind groups of things together, like the <person> tag from our earlier XML example.

An id is the slug, a unique name for that Thing. If you were creating a character that might be his or her full name, such as “James Taylor”. If you were link two nodes together this is the name you would use. Everything in Thunk has an id (a reference even, for those of you who realise I’m pretty much reimplementing the class / Object relationship).

For example, you could create a new ThingType called ‘Character’. You could then create a Thing:

  Type: Character
  ID: Rob Robinson

Introducing: Attributes!

So far there isn’t much information there. Attributes are where the meat of the information is stored. Things contain a bunch of Attributes. When a new Thing is created it is populated with a bunch of empty Attributes, taken from its ThingType. As you add extra Attributes they are added to the ThingType.

Attributes are, basically, trees, with the leaves being the actual data, and the other nodes being Perspectives, which we will discuss now.

Sidebar! Perspectives!

Perspectives, conceptually, are exactly like Things. They even have PerspectiveTypes. They can also contain attributes, although for simplicity they are name / value pairs as opposed to what’s described above.

The role of Perspectives are to provide a perspective into some data. Two easy examples of Perspectives are time and reality (i.e. alternate dimensions).

PerspectiveTypes, as well as possibly defining arbitrary attributes, define whether the created Perspectives are ordered or not. Time is an ordered perspective; things that happen yesterday affect the state of today. Realities are not ordered; things that happen in one reality do not spill over to another. When you create ordered Perspectives there is an additional attribute which is used to define the relationship it has with other Perspectives.

For example, you could create a new PerspectiveType called ‘Time’, and it would be ordered. You could then create some Perspectives:

  Type: Time
  Name: Yesterday
  Previous: <blank>
  Type: Time
  Name: Today
  Previous: Yesterday
  Type: Time
  Name: Tomorrow
  Previous: Today

The first Perspective has a blank previous because it was the first Perspective of that type.

Perspectives are losing favour with me and will probably be removed fairly soon, replaced by an upgraded Thing and.. something else. More on that at a later date.

Back to Attributes!

With the help of Perspectives, we can store more interesting information in our Attributes. As a simple example:

  Type: Character
  ID: Rob Robinson
    <default>: Black
    Today: Blue

The <default> is the default Perspective. There is always one for every type.

With this stored we could query Thunk, asking for the HairColour of Rob Robinson. By default that would return ‘Black’, but we if we gave it the Perspective Today or Tomorrow we would get Blue.

This allows you to have information about characters, places etc change based on situations, such as the time, reality, personal perspective or whatever else you can think of. It makes is possible to store fare more interesting and complete information.

That’s all I’m going to talk about for the moment. There are issues with this system that have not been resolved: PerspectiveTypes need to be ordered in some way to resolve conflicts; time travel is impossible (IRL as well!); there is no place for prose and I’m not happy with the current design of Perspectives.

The entire idea is also overly complicated and over engineered. My hope is that I can keep boiling it down, adding more features, boiling more, until it becomes a hearty and delicious stew of features. Users won’t be directly touching any of this (if it can be avoided) so I’m leaving it up to the actual UI app to hide complexity and provide sensible defaults.

Individual articles on these topics to follow.

This entry was posted in Thunk. Bookmark the permalink. Both comments and trackbacks are currently closed.