Hello and welcome!

This guide will take you through everything you need to know in order to make your own Ord. story and how to share it with others.

Ord. is is a collection of tiny text adventures that only use three words at a time to tell an interactive story.

By using a limited number of words, stories in Ord. encourage players to use their own imagination to create vivid worlds and exciting experiences without the need for lengthy paragraphs.

We created Ord. in the summer of 2019 and then all went our separate ways. Now we have come together once more to make our little story-telling tool available to everyone!

We hope that the explanations and examples in this guide can help you make your own interactive story without having to write a single line of code!

We do recommend reading the whole of this guide before starting to make your own story. However, if you're still having any difficulties, please feel free to leave a comment below or make a post in the Community Hub - we'll get back to you as soon as we can!

Enjoy,

Fynn, Joni, Josh, and Pedro

Ord. started as a little idea. We wanted to make our own text adventures, but we didn't want to write a lot of words. Always keen on cutting corners, Fynn suggested the idea of trying to write the story one word at a time and before we knew it, Ord. was born!

An important element of Ord. is that its stories often rely heavily on randomness. A story does not play out in a fixed structure, but instead is randomly generated and influenced by the player's actions.

This helps us create replayable, alive, and responsive worlds!

...but this also means that writing stories for Ord. can seem a bit complicated at first.

But fear not! This guide is here to help!

A metaphor that helped us a lot during development was describing an Ord. story as a deck of cards.

---

An individual card is known as an 'Event'. This is the smallest building block of Ord. and you can imagine a bunch of these getting shuffled together to create a full deck of events for each story. To progress, the player draws an event (or card) at random and the story can begin to unfold.

While this is pretty cool, telling a coherent story with this completely random method is almost impossible. One can never know for sure what event will get drawn next!

---

Because of this, we wanted writers to have more control over the events a player would "draw" from the deck of cards/events. One way we did this was by giving events the ability to trigger a specific event based on the player's choice, allowing us to chain events together. This meant we could create small pockets of linearity in the random sea of Ord.

---

So, now we could have stories that were still mostly random but could have sections of rigid linearity. In order to give ourselves something more flexible to work with, we created groups: a concept that lies somewhere between the two extremes of completely random and completely linear. A group can be imagined as a unique suit within your deck that some of your events may belong to.

If, for example, you wanted to write a story that starts in a forest but later moves into some caves, you could create two groups - one for forest related events, and one for cave related events. While the player is "inside" one of the groups, they can't see/draw any events from the other group. This method of organising cards allowed us to start controlling the random nature of an Ord. story in more specific (and interesting) ways.

---

As a final cherry on top, we added the ability to manipulate individual events themselves! In short, this allowed us to add and remove specific events from the deck based on the player's choices. This meant we could finally start creating stories that adapted on the fly and have choices that lead to real consequences.

---

Okay! We've run down all of the key concepts that are needed to make a story in Ord. We'll go through each of these ideas step by step and go into much greater detail throughout the guide.

To the player it will seem like every story is purely made up of events - it is all they see while playing.

In reality, there is a lot more to these seemingly simple events than meets the eye. Before we can get into the more advanced elements of events, we first have to talk about what a single event is made up of.

Every event consists of FIVE ELEMENTS:

• ELEMENT 1) The event ID. This is a unique, non-negative integer assigned to every event. The player will never see the event ID, but they are important for more complex manipulation of events (something we'll get into shortly).
  
• ELEMENT 2) The event name, the first word a player sees at the top of an event.
  
• ELEMENT 3) Two actions, the player can pick between either of these.
  
• ELEMENT 4) Two reactions, the outcome words which show the player the consequence of their choice.
  
• ELEMENT 5) Every event can have commands attached to it. These commands are never shown to the player directly, but their effects influence the future of the story in hidden ways that we will talk about in the next chapter.

These are the elements visible to the player in-game:
This is how you will see the different elements when making your own story:


As you can see from the images above, an Ord. story is made with the use of a spreadsheet. This spreadsheet uses a specific format so that the story can be put into the game. You can find a link to a template of the Ord. spreadsheet here: Google Sheets Story Template[docs.google.com]

Each row in the spreadsheet will contain all the information needed for a single event.

We'll cover what all the columns in the spreadsheet do over the course of the guide, but for now we're going to focus on these six columns:

First, we have to set the Event ID. Every event needs to have its own unique ID:

If multiple events have the same ID by mistake, only the event that is highest in your spreadsheet will be interpreted by the game. The others will be ignored.

Next, we decide the Event Name. This is the first word of an event. It sets the stage and gives context for the rest of the event to the player:


Now we can fill out the two options that a player has in interacting with the event:


And finally, we can choose what happens when the player picks our options:

And that's it! We have just made our first event! Congrats! :D
To a player the event will look like this:

Using single words means that Ord. can be a very evocative game in which we can depict almost anything we want. To describe a concrete situation for example, we can write an everyday object and typical interactions you may have with it:

But we can also create more figurative events by leaving the literal behind:

There is really no limit on what you can portray in Ord.

Now that we know the basics of events, let’s explore some more advanced concepts...

While Ord. thrives on the dynamics made possible by randomness, sometimes we want specific control over what event a player will see.

If Ord. was completely random, then a player could choose to enter a house and then be really confused when the next event describes a forest or a cave.

To react directly to the actions of players, we can trigger events.

In the last chapter we discussed how every event has 2 reactions, each of which lead to a specific outcome. We can use these outcomes for more than just descriptions and jokes - we can use them to trigger specific events.

Triggering events allows us to tell more nuanced stories. You’ll also be pleased to know that making it work in the spreadsheet is pretty easy!

Remember the unique ID that every event has? All we have to do to trigger an event is write an '*' in the ChangeCards column followed by the ID of the event we want to trigger:

Now, when the player selects the choice 'Inspect' they will always see the event with ID 6002 afterwards.

This technique is great for creating more authored parts of your story, or for creating a story that uses a decision tree with pre-defined results!

Now let's look at some of the ways in which we used this technique when making Ord.

Linear Stories With Branching
You can write text adventures that feature zero randomness by using this technique!

For now, events that are only meant to be part of a linear sequence can still be randomly selected when we start playing our story. Players could accidentally draw a card that is in the middle of a linear sequence, potentially leading to more than a little confusion! Don’t worry about this for now, we will learn how to deal with this problem in Chapter 5.

Loops
You can also trigger the same event again and again!
Just write '*' followed by the ID of the current event in the 'ChangeCards' field:


Endings
Most stories will also have at least one ending (although it is common for Ord. stories to have more than one).

In Ord. this is a special type of trigger that will display the word ‘End.’ after a choice has been made and then restart the story from the beginning.


This is the only time that players will see 4 words on their screen!

Endings can be used to indicate a range of things like the death of the player character, a happy end, or simply that the story is now over.
How you use the 'End' function is 100% up to you. All it does is tell the player that they have reached an end, before restarting the whole story.

Let’s create an ending now. In every story, an ending is triggered by writing ‘*1’ in the ChangeCards column, using any other ID will be treated as a normal trigger event.
In this example, when the second choice is picked, the game will show the outcome name, followed by ‘End.’ and then restart the game from the event ID 1.

This means that it is important that all your stories have an event with ID 1. This is the starting point that the game will always pick when the story is beginning.

So far we have only talked about how to directly trigger specific events, which allows us to build linear sequences, loops, and endings.

There are more ways that we can control randomness in an Ord. story and one of the most common ways of doing so is by organizing events into groups.

Groups are collections of events. It’s best to think of them as suits for the deck of cards that is your story - or mini decks of cards that live within the larger whole. Instead of just drawing any of the cards at random, we tell the game which specific group of events the next card should be drawn from.

Groups help us with structuring our story into different sections. Just like events, every group has a unique ID number.

We can assign an event to a Group by writing the group ID in the ‘Group’ column of the event:


Here, we can see that the top two events are part of group 1 and the bottom three events are part of group 2.

While the player is in group 1 they will only see events in group 1 and when the player is in group 2 they will only see events in group 2. The player’s starting group will be the group that event ID 1 is part of, as this is the starting point of any story.

Once an event has been shown to a player, it will not be shown to them again until they leave the group and re-enter it. There is one situation where this is not the case, but we will cover the specifics of this later in this chapter.

Every Ord. story must contain a group 0. Your event that has ID 1 must be part of this group. Unlike other groups, group 0 also does not allow an Ending to be triggered (by writing *1), it will simply take you to that event without showing the player the word 'End'. It is best to think of group 0 as the launch-off group, generally it should only contain one or two events that you use to set up your story.

If you do not assign an event to a group it will by default become part of group 0.

As players move through your story, they can move between groups!
They can, for example, encounter a cave and choose to enter it. They have now entered the 'Cave Group' and the next event will be drawn from that specific pile of events!

Just like with triggering events, we can assign group changing to a specific outcome.

We can make the player move between groups by putting the number of the group we want them to move to in the 'ChangeGroup' column that corresponds with a choice:

When a player enters a group, the game chooses a random event in the group and presents it to the player.

If we want the player to encounter a specific event from the group upon entering it, we simply also trigger that specific event, just as we learned in the last chapter:

We can also trigger events from a group that the player is not currently in. This does not move the player to a different group. After the triggered event (or sequence of events if they have been chained together with multiple triggers) has played out, the game will choose the next event from the group that the player is currently in.

How many groups you use in your stories is up to you. Really, you can have as many as you like!

Generally, having more groups allows us to create a more scripted story with well-defined sections, while using fewer groups will generally create a more random experience.

And with that, we now know what groups are, how they work, and how we can switch between them.

But, in order to switch from one group to another, we currently need to randomly find an event that has a 'ChangeGroup' outcome. Depending on the size of the group, this could take forever! Once again, the randomness of Ord. can be seen as a strength as well as a weakness - it’s important to find a balance.

Luckily, we have a process that allows us to exert more control over how long players spend in each group!

Exit Events
Every group must have a special type of event called an exit event. While it looks exactly like a normal event, the exit event can never be randomly drawn! We have control over when we show it to the player!

Let’s create an exit event now by writing a '*' in front of the group ID of the event:

While exit events do not have to force the player to switch to another group, we used them in this way to help us give our stories more structure and a better sense of pacing.

How many random events the player sees from their current group before the exit event is automatically drawn is determined by something called the Group’s Size.

For example, if you have a group size of 3, then the player will encounter 3 randomly drawn cards, before being shown the exit event.
If you have a group size of 1000, then the player could spend hours in that group before finally being able to move on!

We'll learn how to set the size of groups in Chapter 7.

It's important to note that events that are triggered (by using '*') will not add to the group size counter.

If a group does not have enough events for the exit event limit to be reached, the game will reshuffle the events in the group and start showing them again until the group size counter reaches the required number of seen events. This is the one case where it is possible for the player to see the same event more than once via random selection without leaving and re-entering the event's group.

Each group can have multiple exit events! If there is more than one, the game will pick one randomly.

If the exit event does not make the player change group and the group size limit has been reached, the game will randomly select another exit event from the player's current group. This means that if the group only has one exit event, the player will be stuck in a loop.

So, let’s recap:
Ord. consists of events. Each event represents a choice between two options. The outcome of an event can trigger other specific events. If the outcome does not trigger specific events, a new event is randomly selected from the group that the player is currently inside of. Outcomes can also move the player between groups. After a certain amount of events have been experienced in the same group, a special exit event is presented to the player.

Sometimes we don’t want all the events in a group to be accessible through random selection. The linear sequences we have learned to create in Chapter 3 are a good example of this!

For example, if you have created a linear sequence that depicts a conversation, you do not want the player to randomly see a part of that conversation without the proper context.

To control this, we have created active and inactive events.
Active events are in the pool of events that can be randomly selected, while inactive events are kept on the sidelines. Events are active by default, and we change them into inactive events to hide stuff that we don't want to be randomly drawn.

One way an inactive event can be shown to the player is if they directly trigger it. This allows us to hide the events that are part of linear sequences from being accessed without context.

To make an inactive event we simply put ‘-’ in front of the event's group ID. Let’s do this now


This means that the ‘Puddle’ event will never be drawn unless it becomes active or is triggered by an outcome.

You can trigger inactive events in the same way as active events - simply writing the ID with “*” will work. So in the case of this 'Puddle' event, you would trigger it by writing '*728'.

Whether an event is active or inactive is not a static thing. Similarly to how we can change groups or trigger events, we can also manipulate the state of an event through outcomes.
This allows us to respond to the player's actions in more nuanced ways.

We can make an inactive event active, and thereby add it to the pool of randomly drawable events through an outcome.
To do this write the ID of the event we wish to make active in the 'ChangeCards' column:

Now, if the player is in group 7 they can potentially see the 'Puddle' event.

When an event gets made active, it is 3 times more likely to be randomly selected than a normal event. This means that players are more likely to see events that are a consequence of their choices.

We can also make an active event inactive through an outcome, thereby keeping it from being randomly selected.

To do this, write ‘-’ and the ID of the event you want to deactivate in the ChangeCards column:

In this example, if the player decides to participate in the dance it will start raining, making rain-related events like ‘Puddle’ possible to appear while making non-rain-related events like ‘Sun’ disappear.

Events from different groups than the current one the player is in can be made inactive and active, allowing for decisions that don’t have repercussions until later on in the story.

Make sure that you design your story so that it is not possible for a player to try and select an event from a group that has nothing but inactive events - doing so will break the game and cause the player to be stuck in an infinite loop of the last event they could see.

As you may have noticed, multiple event ID commands can be written in the 'ChangeCards' column. To do so simply separate each ID with a comma. This allows choices to have multiple effects on the state of the deck.

Important: If you have multiple ID commands in the 'ChangeCards' column and one of those commands is to trigger an event, the trigger command must come first in the list:



So, to recap: there are a number of things that event outcomes can do - trigger events, change groups, and add or remove events!

Now that we have covered how to write the content for your story, let's discuss how to get your work ready for integration into Ord.

We wrote the stories for Ord. in Google Sheets. It’s free and multiple people can work at the same time - we found this pretty neat.

Here is a link to the spreadsheet template, feel free to copy it to your own drive to start making stories: Google Sheets Story Template[docs.google.com]

Each row in the sheet is an event. The first row names each column - do not change these names as the game needs these names exactly in order to read the spreadsheet. The data in each row needs to be correct but do not worry if you make a mistake, the Ord. Workshop tool will let you know if there is something wrong with your spreadsheet.

The game reads story data in the form of json. Google sheets by default does not allow you to export spreadsheets as json. The Ord. team uses a free add-on, creatively titled: “Export Sheet Data”, in order to export our stories for the game.

To download an add-on - click the “Add-ons” button in the toolbar in the top-left menu of Google Sheets, then “Get Add-ons”. Search for “Export Sheet Data”, and download the Add-on.



Once you have downloaded the add-on, navigate to the "Add-ons" menu once again, hover over "Export Sheet Data" and click "Open Sidebar". There are a lot options in this sidebar but the three you must have selected are:

• Force string values
  
• Export sheet arrays
  
• Export contents as array

(See the image below for reference).

Clicking the blue “Export” button should now create a json copy of your story. If the json is not working when you try to test it in the Workshop tool, make sure that these two things are true inside the json file:

• Square brackets should be surrounding all the data.
  
• Each data value should either be a string (each surrounded by quotation marks) or have a null value.

There is one last step in making a playable story. Unfortunately there is no way to define external data, such as the name of your story, the sizes of your groups, visual effects etc. This is where the setup.txt comes in:

The template for this file can be found here: Story Settings Template[drive.google.com]

Each piece of data you can edit in this file starts with a header e.g. “Description”, and then in the line directly below you can enter the data. Some data goes across multiple lines for each sub-category - such as Raining under Effects. Each header and corresponding data is as follows:

• Name: is the name of the story found in the menus.
  
• Description: is the description of the story found in the menus.
  
• AuthorName: is the name(s) of the author(s) of the story found in the menus.
  
• GroupSizes: is the size of each group in your story. Each line corresponds to a group. E.g. 1 = 5, means group 1 has a size of 5. If you want a group to have infinite size give it the value 0 e.g. 3 = 0, means group 3 has infinite size.
  
• Soundscapes: is the sound effect “colour” used for the corresponding group. There are 3 colours: Orange (0), Green (1), and Blue (2).
  
• Effects: allows you to add visual effects for groups. Each effect has its own line and you can add as many groups to an effect (or none) in a list format by separating each group with a comma “,”. You can have multiple effects active at once.
  
• Dungeon: is a dark effect, words are lit with a torch-like liking.
  
• Raining: adds a down-pour effect.
  
• RainingInverse: adds black rain-drops which can only be seen in the words, or during a lightning flash.
  
• Lightning: adds flashes of white at a semi-random interval.
  
• Warped: makes the text bend and wobble.
  
• Aberration: adds chromatic aberration to the screen.
  
• HotColor: adds a warm orange tint to the screen
  
• ColdColor: adds a cold blue tint to the screen
  
• GreenColor: adds a green tint to the screen
  
• Finish Events: are events which kick the player back to the main menu upon reaching the end of the event. Each “Finish Event” must be added on a separate line.

Being a .txt file, formatting your settings correctly is important as there is no built-in error detection. Make sure that there is a space before and after each “=” and that each header has the exact spelling as seen in the template file.

Now you have everything you need to test your story in the Workshop tool. If you run Ord. in Steam, you will be given the option to open up the Workshop tool rather than the game.



In this tool, you can set up a name, description and image that will be seen on the Steam Workshop page of your story.



The first thing you must do is select ‘Create New Story’ in the bottom-left hand corner.

Next, click on the ‘New Story’ element in the left hand bar to make sure you have it selected.

Now you can add a preview image for your Workshop submission - the image must be under 1MB in size and have a 16:9 resolution (recommended size is 640x360 pixels). If the image does not fit these requirements, your story will not upload correctly!

Next you must select the content folder - this is a folder that must contain both your story json and setup.txt. Select either one of the files in the folder to assign the content folder. Avoid having any other files in this folder to avoid potential errors!

Next you can edit the title and description of your Workshop submission. Note that this is separate from the title and description that will appear in game.

You can also change the visibility of your item in the Workshop, this can be changed later once the story has been uploaded via the Steam interface.

Clicking ‘Save’ will save your story inside the Workshop tool. You should use this when you first create a new story in the tool and after you make changes. Not doing so will mean you will lose progress if you close the tool and come back to it later. Clicking ‘Test’ and ‘Submit’ will also automatically save your story.

Clicking ‘Test’ will run your story as if it is in game. If the story or any events in the json are incorrectly set up you will receive error messages letting you know what has gone wrong. You must test your story at least once before the tool will allow you to submit it to the Workshop.

We’d recommend testing your story and trying to play all the events it contains. The Ord. Workshop tool will find some problems on load, but some issues with events can only be found during the course of play.

Finally, you can click the ‘Submit’ button to publish the story onto the Steam Workshop.

Please be sure to accept the Steam Workshop’s terms of service before publishing any stories as it is necessary to upload content onto Steam’s servers. A link to the terms will appear at the bottom of the tool in red when your story is ready to publish.

In order to delete published stories from your computer, you must first delete them in the Workshop menus in Steam.

You can update an existing Workshop submission by selecting the story from the left hand bar, editing the necessary elements, and clicking 'Submit' again.

Congratulations! You now have everything you need to create, release and share your stories in Ord.

Here's a run-down of the most important things you need to remember when writing an Ord. story:

• Every event must have a unique ID.
  
  
• Trigger specific events by writing '*' followed by the ID of the event in one of the 'ChangeCards' columns.
  
  
• Make your story end by writing '*1' in one of the 'ChangeCards' columns. This will reset everything in your story (inactive events that were made active will revert to being inactive, etc.).
  
  
• Every event must be part of a group. Assign an event to a group by writing the group ID in the 'Group' column.
  
  
• Change the group a player is in by writing the group ID in one of the 'ChangeGroup' columns.
  
  
• Make an event inactive by writing '-' in front of the group ID in the 'Group' column.
  
  
• Make an inactive event active by writing the ID of the event in one of the 'ChangeCards' columns.
  
  
• Make an active event inactive by writing '-' followed by the ID of the event in one of the 'ChangeCards' columns.
  
  
• Every group must have an exit event, create one by writing '*' in front of the group ID of the event.
  
  
• Every story must have an event with ID 1 and a group 0. The event with ID 1 must be part of group 0.
  
  
• Triggering events (by writing '*') will not add to the group size counter.
  
  
• Multiple commands can be executed in the 'ChangeCards' columns, to do so separate each ID with ',' (a comma). Remember! If one of your commands is to trigger an event, this must appear first in the list!

Resources:
Story spreadsheet template: Google Sheets Story Template[docs.google.com]
Configuration .txt for story settings: Story Settings Template[drive.google.com]
Example of completed spreadsheet used for Quest: Quest Story Spreadsheet[docs.google.com]