Strange Eons

A Case Book Primer

Send Feedback      Home Page > Strange Eons >Miriam's Basement > Case Book Tutorial

Getting Started with the Case Book Editor

Of all of the tools that Strange Eons provides, the case book editor has perhaps the steepest learning curve. While most components consist of just a front and a back, case books are composed of hundreds of little bits of text that link to each other in a graph, much like pages on the web. The case book editor is correspondingly more complicated. This tutorial will guide you through the creation of your first few case paragraphs and set you on the path to crafting your first rousing Arkham adventure.

Fire up Strange Eons and create a new case book. Use Edit | Clear to blank everything out. In our tutorial, we will be working up a small set of encounters centered around Miskatonic University. The investigator's goal is to get into the records section of the registrar's office in order to discover the real reasons behind the recent expulsion of a student.

If you are not already familiar with Arkham Investigations, you should at least read the rules before continuing with this tutorial.

The Back Story

Tongues are still wagging over the recent death of Irving Sanders, eldest son of retired shipping magnate Mycroft Sanders. The <i>Advertiser</i> has hinted darkly about the gruesome condition in which his body was discovered, but the police are not letting out any details, even to the family. The most recent revelation to hit the papers was that Irving, who was an anthropology major at Miskatonic University, had recently been expelled under the school's rarely invoked moral conduct rules. The Sanders family has hired you and your associates to find out what you can without attracting the ire of local authorities.

The Special Rules tab is normally used to set up any details of the initial game state (for example, unlocking some initial vignettes) and to describe any departures from the usual Arkham Horror and Arkham Investigations rules. Since we mentioned that the investigators were hired to look into the case, lets add the following for flavour:

At the start of each turn, the first player receives $1 in per diem fees from Mycroft Sanders. Unlock <^mu-reception>.

Noticed the weird bit I added at the end, did you? You'll see what that's about shortly. Let's see what we've got so far. Click on the Preview Draft tab and in a moment a preview version will appear. Not bad so far, but notice the red text at the top that tells us that there are errors. Follow its advice and go to the Publish tab and click Publish Case Book. Publishing prepares your case book to be printed or exported and checks it for problems. You will see that it lists some warnings (in yellow) and errors (in red). Normally you would not want any warnings or errors in your case book, but errors are especially serious because you cannot print or export a case book that has errors in it.

The error message that is displayed tells us that we have referred to part of the case book that we haven't written yet. In this case, we have told the player to unlock a Vignette that doesn't exist. That's because of the <^mu-reception> we added to the end of the special rules.

Events: Let's Make Things Happen

Strange Eons collectively refers to all of the little snippets of text in a case book as events. There are three basic kinds of events:

1. Timeline Events: These go in the case's timeline to replace mythos cards and drive the plot.
2. Paragraph Events: These become numbered paragraphs in the case book.
3. Index Events: These appear in either the Locations Index or Vignette Index near the front of the book and  usually direct a player to read a paragraph event.

Timeline events are less complicated than index and location events, so even though their tab comes later in the editor, we'll work with them first.

The Timeline

Timeline events are used to move the plot forward and convey a sense of urgency. Unless they finish the investigation sooner, the players will be sent to the endgame once all of the events on the timeline run out. Usually, this means that they will lose the game. Timeline events are similar to mythos cards, but they happen in a specific order and do not normally open any gates. A typical case book will have between 10 and 20 timeline events, depending on how quickly the events progress and how long the story is.

The Event field is where you will write the actual event text. In a case book, you are not limited to staying within the size of a Mythos card, so your events can be as elaborate as you want them to be. Keep in mind, though, that the more complicated you make the event, the harder it will be for the players to keep track of the effects that are in play.

For our example case book, let's create an appropriate opening timeline event. Reasonable investigators will head to the University to start their investigation, so let's add a small challenge for them. For the headline, type Record MU Registration Expected to Cause Delays. Make it an urban environment, then fill in the event text:

An unusually large influx of new students has clogged the streets
around the campus. Investigators who enter the Miskatonic University
streets must make a <b>Will (-1)</b> check. If they fail, they are
reduced to 0 movement points and cannot proceed until next turn.

Investigatin'

Index events and paragraph events are both edited on the Investigations tab. Go there now. In the top half of the tab are lists that represent the two indices and the entries that they can contain. Clicking an item in one of these lists will allow you to edit all of the events related to that entry. For example, clicking "Black Cave" will let you edit the index entry and paragraph events for encounters that take place at the Black Cave.

Let's create a simple encounter. We expect the investigator to go to the Administration Building to find out about Irving's expulsion. What if they go to the Science Building instead? Let's make a "nothing happens" encounter to deal with this. Select Science Building in the Location Index. It shows up in the event tree in the bottom-left of the tab, but right now there are no events attached to it. Click on the Add Subevent icon . A new event is created which you can edit in the lower-right section of the tab. This is the first event under the Science Building, so it is an index event. The editor indicates this by putting a star next to it in the tree. This event will appear in the Location Index under "Science Building" instead of as a numbered paragraph. The editor reminds us of this by printing the name of the index entry in square brackets.

You don't normally reveal what takes place at a location in the Index entry. Otherwise, the players would accidentally gain information when scanning down the index. So we will make this event link to a numbered paragraph that unveils that nothing happens. In the event editing fields, you will see that the event has been given a label ("science-building") and some default text ("..."). All location and index events have a label. The label gives you a way to talk about an event without knowing where it will end up in the final case book. Since the paragraphs are in random order, we can't just say "Read paragraph 6." We don't know what paragraph that will be. So instead we give the events labels, which are little names that succinctly describe what the event is for. Then when we are writing, we can write <#xxx> (where xxx is a label) to refer to the place where the label ends up in the book. Let's see how this works:

For the text of this event, type in Read paragraph <#science-building-par>. Now we need to create a new event with the label science-building-par. Logically, the new event should be a subevent of this one because you go to it by "passing through" this event. Click on Add Subevent again, and for the new event, fill in the label as science-building-par and then give it the event text Nothing happens. The result should look like this:

Writing some event text that uses labels and creating subevents for those labels is a very common task, and there is a short cut. If you press Add Subevents for New Labels in this Paragraph (or press Alt+S on most platforms), then Strange Eons will scan the event's text  and then create new subevents for any labels it finds that are not already in the case book.

Go to the preview draft again to see the results. The Location Index now has an entry for Science Building that tells you to "Read paragraph 1." If you click the link to jump to paragraph 1, you will find that it says "Nothing happens."

So far so good. Let's keep going. Go back to the Investigations tab and pick the Administration Building in the Location Index. Create a first subevent. In the event text area, type:

If <^mu-reception> is unlocked, move to <#mu-reception>. Otherwise, nothing happens.

This will allow investigators to enter into a vignette that represents the offices within the Administration Building. As you may guess, <#mu-reception> will point the player to the event with that label. But unlike science-building-par, which is a numbered paragraph, mu-reception is going to be listed in the Vignette index. Instead of printing a number, it will print the location of the event in the index (in this case, [A1]).

The other notation, <^mu-reception>, prints the name of the "root" location of an event. It is mostly used with labels for events in a vignette, because it will print the more general "Vignette A" instead of "[A1]". You may recall that the Special Rules section ended with the sentence "Unlock <^mu-reception>". So we unlocked this vignette at the start of the game, and players will be able to enter the vignette immediately. Later on, an event may mark the vignette as succeeded or failed, which would prevent players from entering the vignette again (as it is no longer "unlocked").

Click on A in the Vignette Index and create a subevent. Give it the label "mu-reception," so that the references to that event will point here. As with the Science Building, we don't want to give anything away in the index, so add the following event text:

Read <#mu-reception-par>.

This time try the Add Subevents for New Labels in this Paragraph button to create the named subparagraph. In this new event, enter the following event text:

You make your way to the Office of the Registrar, where any records regarding Irving Sanders's expulsion are likely to be kept. When you get there, you find a long ling of students running out of the door and down the hallway. It is start of semester, and they are all waiting in line to register. Make an assisted <b>Luck (-1)</b> check. If you succeed, read <#mu-rec-luck-S>. Otherwise, read <#mu-rec-luck-F>.

In this paragraph, the story branches and can go one of two different ways depending on the outcome of the skill check. We will use two subevent branches under this event to represent the two possible outcomes. When the story branches this way, I like to put -S on the label of the success branch, and -F on the failure branch. Doing this consistently makes the case book easier to edit. To make the subevents, we will once again use the Add Subevents command (Alt+S). Then we can fill in the text. For mu-rec-luck-S, write:

You realize that the staff out front are so busy that you might be able to slip by them without being noticed and get to the records room. If you want to try to sneak in, read <#mu-sneakin>. Otherwise, you'll have to wait in line. Move to <#mu-rec-waitinline> and read <#mu-rec-waitinline-par>.

For mu-rec-luck-F, write:

There is nothing for it but to wait in line. Move to <#mu-rec-waitinline> and read <#mu-rec-waitinline-par>.

The event mu-rec-waitinline, representing the reception line, will be the A2 location. When the player first moves there, we tell him or her to read the paragraph for the location right away. Otherwise, their encounter would have ended and they would not read this paragraph until the next turn (when they followed the directions under the A2 index entry, which we will write momentarily). To simulate standing in line, the player will stay trapped on A2, possibly for several turns, until they pass a skill check. First, we need to create the A2 index entry. Click on the mu-reception event to select, and then add a sibling with the New Event button (). Set the label to mu-rec-waitinline and then add the usual text:

Read <#mu-rec-waitinline-par>.

Do the Add Subevents trick, and for mu-rec-waitinline-par, enter the following:

The line nudges forward at a snail's pace. If you give up on waiting, you can return to Arkham. Otherwise, make a <b>Will (-2)</b> check. If you pass, move to <#mu-rec-frontofline>. In either case, your encounter ends.

This will keep the player queued up for at least one turn, and it provides an out in case the investigator cannot possibly pass the skill check.

Now it's your turn. Try your hand at creating the mu-rec-frontofline as [A3]. Give them a choice of either bribing (discard money) or fast talking (skill check) their way into the records room, which you can add as [A4]. Then go back and complete the mu-sneakin branch, perhaps having the player perform a Sneak check to slip past reception and get back to the records room. Kick them out of the vignette and arrest them if they fail, but don't fail the vignette, as the player will need to get to the records room in order to move forward in the investigation. The result should look something like this:

Completing the Investigation

Where does the story go from here? I am going to leave that as an exercise and instead go on to cover some of the other features of the editor. But I do recommend that you try your hand at completing this encounter. If you need some inspiration, I have heard rumours that one of the late Sanders's professors is also a member of a certain social club in the French Hills district. Could he have taken a special interest in his star pupil? What was the nature of Irving's moral misconduct? Don't forget to have the players put a success or failure token on the vignette so that they can't enter the vignette again once it plays out.

Deepening Your Understanding

The Event Tree

The case book editor links events up into a tree (like a family tree), where one event can be the "parent" of many "child" subevents, and each subevent can in turn have subevent children of its own. This is a useful organizational structure, because it lets you relate events at a given location according to a cause and effect ordering. For example, the events that represent the outcomes of the skill check must logically happen after the skill check is performed, so they are made subevents of the event where the skill check takes place.

The editor allows you to organize your events this way, but it does not require you to do so. There is only one restriction on how you organize events into parents and children, and it has to do with how events are added to the case book indices. When you start a new investigation by adding a subevent to a location (such as "French Hill Streets"), that first event will be marked by a special star icon instead of a bullet. It is marked that way because it is the event that will appear in the location index for that location. The other events you place (the ones with bullets) will appear in the event paragraphs section as numbered paragraphs, and the indexed event will normally refer to one or more of these events. Vignettes are a bit different because a vignette is itself made up of one or more locations (such as [A1], [A2], and so on). Every immediate subevent of a vignette location will be marked with a star, and each one is listed in the vignette index. The order that they are listed in determines which number the space it will occupy on the vignette track: for Vignette A, the first child will be [A1], its immediately following sibling will be [A2], and so on.

Finding Events

Once a case book has several dozen events, locating a specific one by memory or visual search becomes difficult. To alleviate this, the bottom of the Investigations tab provides a search box. You can search either the full text of events, or only the labels. This second feature is more useful when activated from the Preview tab. The case book preview shows label names in grey between {braces}. If you double click on the label name, a search for that label will be created and executed automatically. This is especially useful for fixing typos that you discover while browsing in the preview window.

Macros

Macros are a bit of mark-up that gets replaced with a different bit of mark-up, and they can save you a lot of time when working on case books. You already used macros when you referred to an event using the "<#xxx>" and "<#xxx>" notations. The special tag that you typed will get replaced by "paragraph 6", or "Vignette A", or "[A1]", or whatever is appropriate for the event.

Besides these macros, which are created automatically from event labels, each case book has a library of predefined commands. This is shown on the Publish tab. Have a look through the list. One of the most useful macros is "check", which is used to perform skill checks. In fact, there is an entire family of check macros that can be used in different circumstances. For example:

All of these are used the same way, using three parameters: the type of check to perform, the label of an event to go to if the check succeeds, and the label of an event to go to if the check fails. Using a check macro, we could replace the following snippet (from the example case book above):

Make an assisted <b>Luck (-1)</b> check. If you succeed, read
<#mu-rec-luck-S>. Otherwise, read <#mu-rec-luck-F>.

With this:

<teamcheck. "Luck (-1)" #mu-rec-luck-S #mu-rec-luck-F>

Because it is an assisted check, we use the "teamcheck" version. If we used "check" instead of "teamcheck", we would have gotten a regular skill check instead of an assisted one. Because we used "teamcheck." (that is, with a trailing period), the result starts a new sentence ("Make" is capitalized). We would used the other (mid-sentence) version when writing text like this:

If you want to break the door open, <teamcheck "Fight (-3)" #break-S #break-F>

You can create your own macros using the "define" tag, and you can store a set of custom macros for your case book in the User Library field of the Publish tab. To learn more about defining macros, see the Tag Table page.

Refactoring Tools

Sometimes you'd like to change the order that events occur in, or insert a new event between two existing events, or change a label and update all of the references to it. To make this easier, SE provides some simple "refactoring tools". To access them, click the "Links..." button next to the event label you wish to modify. As an example, let us suppose that events A and B both direct the reader to event C, and we want to insert an extra event (X) that has to happen before C can occur. To do this we would select event C and then click on the "Links..." button. We would then select the "Divert" option and in the "New Label" field we would enter "X". After pressing "Change Links", all of the references to #C (or ^C) would instead point to #X (or ^X). Now we can add our new event, X, and in the text for X we will direct the reader to event C.

Shuffling Seeds

The shuffling seed is the basis for shuffling the paragraphs in a case book. As long as you do not change the seed or add or remove any event paragraphs, the paragraphs will be shuffled into the same order. This is useful when correcting minor errors such as spelling mistakes during play testing and maintenance, as it is possible to directly substitute the updated version. If you are unhappy with the way the events have been shuffled, simply click Reseed to generate a new seed so that the events will be shuffled differently. During testing and proofreading, it can also be useful to disable shuffling so that events are listed in order. The preview window does this by default, but you can prevent shuffling during exports and printing by setting the seed to 0.

Case Book Styles

Each case book includes a set of style hints to help control how the case is laid out when printing and exporting. Because these are only hints, they may or may not be obeyed. The hints that are obeyed depend on what makes sense for the kind of formatting being done. For example, the formatter used for printing obeys nearly all of the hints, while the "Arkham Nights" export format plug-in ignores the hints altogether (instead formatting the case book to look like an Arkham Nights booklet). To edit the style hints for a case book, use the Edit Style Properties... button in the Advanced panel of the Publish tab.

Return to Home Page    Send Feedback

November 07, 2007  — Updated April 20, 2010