Some time ago I and Jim Munroe released an authoring system called Texture. The system was under development for several years as we spent a couple of hours here and there whenever we had the time.
I use a time tracking tool called Toggl to keep track of how long I've been doing various things, so I have relatively accurate statistics for how much time I've really spent working on Texture. The system has three major parts: the Writer that authors can use to create Texture games, the Reader which is the "engine" that plays those games, and the Public Library which is the repository of public works made with the system.
In total I've spent about 326 hours on the project. The summary is below:
Time (hours)
% of total
Writer
141
43%
Public Library
73
22%
Prototyping
50
15%
Reader
42
13%
Project management
20
6%
326
Some notes about those figures:
Prototyping is time spent on planning and making mockups and initial throwaway versions before deciding on the final design. We did a lot of trial-and-error iterations and test versions before starting to work on what became the final product.
Project management is mainly emails and Skypeing with Jim to discuss and plan the project.
Because of reusable code there's some overlap in many areas. Working on something that was needed for multiple areas is marked down somewhat arbitrarily in the statistics.
I didn't start tracking time right at the beginning, so the prototyping figure is the most uncertain one. A total of 300-350 hours for the entire project should be about right.
Additionally, while I did all the programming work, these figures don't include Jim's contributions that total to about 250 hours. He did most of the system design and spent a lot of time on the community outreach, managing beta testers and writing demo games.
For me the main takeaway from these figures is that it takes a relatively short time to make a new system, but a lot of time to make a user-friendly tool for authoring games in that system. For example, two of my custom-engine games (Ex Nihilo and Ex Materia) were both practically one weekend projects from scratch, but building an editor for others to make similar games would take at least a month or two of full-time work.
Finally here's some statistics about the lines of code in each part of the system, excluding third party libraries. "Other" includes mostly helper scripts and server setup.
A couple of years back I and Jim Munroe released an alpha version of Texture, a touchscreen optimized interactive fiction authoring system in which you drag and drop words on top of story text. We've worked on the release version ever since and earlier this week it was published at texturewriter.com.
There are too many new features to list them all, but here are the highlights:
New layout, user interface and typography. Page text adapts to available screen space automatically.
State tracking through flags and behaviors: actions can toggle flags on and off, which in turn lets the author trigger alternative behavior based on which flags have been set.
The action's name (which is displayed when the command is dragged over its target) doesn't have to be strictly verb-noun anymore. The most common use case is adding prepositions ("sit under tree" instead of "sit tree") but it can be changed to anything at all ("sit" + "tree" → "rest under the redwood").
Command targets can consist of more than one word by using underscores which are shown as spaces in the final story (e.g. "oak_tree" would be printed as "oak tree" but both words would be targeted at the same time.)
A command target can be reused after an action has replaced it with new text by enclosing a word in the new text in [brackets].
Basic text formatting options (bold and italic text).
Cover page and cover art; the cover page also acts as a tutorial for people who are playing a Texture game for the first time. Clicking or tapping the play button shows a "ghost" of the button being dragged to demonstrate how interaction works, and clicking again pops up explicit instructions.
Preview right in the editor, with a debugging console for manually toggling flags and following internal behaviors and flag changes.
Exporting and importing project backups.
An interactive tutorial that guides you through the basic features.
In addition to new editor features, stories can be published online at texturewriter.com without needing to download the project and host it on your own web site.
Logging in to the web site will automatically save your projects to the server, so they'll be safe even if you clear the browser's cache and you can access them on any device by logging in. You can still use the system as a guest, in which case the projects will be saved locally to the browser (and nothing is sent to the server), but then you'll have to back up the projects manually.
The flag system makes Texture a "real" system with state tracking instead of just simple tree-like branching. In terms of story logic we're unlikely to add features to the online IDE because it's starting to approach the limit where the visual interface can't represent more complexity in a way that wouldn't make writing stories cumbersome and error-prone. We're planning to release the Texture Reader (analogous to parser game interpreters) as a JavaScript library which would allow writing story logic of any complexity using JavaScript.
Other new features are possible though, and the next major feature under development is story-specific layout options (color and font choice.)
Questions about organizing Inform 7 code tend to pop up regularly. Here's the method I use, which is of course not the official or the only way to do it.
Taking a ready-made header structure and trying to adapt your own code to it by filling in the blanks would be too inflexible, so I build the structure dynamically as I go along. A new project starts with no headers at all. New headers are added when code gets diverse enough to justify a new classification.
Include Rideable Vehicles by Graham Nelson.
The Front Yard is a room.
In this example the extension and the room definition don't have anything in common, so they're split into different headings.
Volume 1 — Extensions
Include Rideable Vehicles by Graham Nelson.
Volume 2 — Rooms
The Front Yard is a room.
When we add a new room, there's another split (although in real life the split would come only after they have a bit more content, we'll come back to that soon).
Volume 1 — Extensions
Include Rideable Vehicles by Graham Nelson.
Volume 2 — Rooms
Book 1 — Front Yard
The Front Yard is a room.
Book 2 — Driveway
The Driveway is a room. The Driveway is west of Front Yard.
Notice how the two similar headers are grouped together with a common parent header.
The general rule of thumb is that when something has at least two paragraphs of code, it gets its own header. For example, assuming we have the following code:
Chapter 1 — Engine room
The Engine room is south of Cable-car platform. The description is
"The wooden shack houses a large diesel generator that moves the cableway.
The shack's walls are rotten and patchy. The exit leads back out to the north."
The diesel generator is a device in the Engine room.
"The diesel generator [if switched on]is running loudly,
turning the cableway.[otherwise]looks like it hasn't been
used in quite some while." The diesel generator is fixed in place.
The shack walls are scenery in the Engine room. The description is
"Light is shining through the wall boards."
Each thing in this room (including the room itself) has only one paragraph of code, so they'd all stay under the same heading for now. Later when the code gets some meat around the bones, some things get more paragraphs and it's time to split them under more headings.
Chapter 1 — Engine room
The Engine room is south of Cable-car platform. The description is
"The wooden shack houses a large diesel generator that moves the cableway.
The shack's walls are rotten and patchy. The exit leads back out to the north."
Section 1 — Diesel generator
The diesel generator is a device in the Engine room.
"The diesel generator [if switched on]is running loudly,
turning the cableway.[otherwise]looks like it hasn't been
used in quite some while." The diesel generator is fixed in place.
After switching on the diesel generator:
say "The generator makes some suspicious noises but then comes to life.
The cableway starts moving again."
After switching off the diesel generator:
say "The generator shuts down and the cableway stops."
Section 2 — Shack walls
The shack walls are scenery in the Engine room. The description is
"Light is shining through the wall boards."
The two-paragraphs rule is not absolute; sometimes it makes more sense to keep everything under one header when the code is not that important, like decorative scenery. Inform has only five header levels which also limits the size of the pieces into which you can split the code.
The five header levels are volume, book, part, chapter and section. I haven't really attached any specific fixed meaning to different header levels. Volumes contain top-level abstractions ("Metadata", "World", "Debugging") and any subheaders just use the next immediate type (volumes contain only books, books contain only parts etc.) This means that header levels in different parts of the source text aren't comparable: an NPC in one place might be under "part" level and another NPC could be under "section" level somewhere else, with neither being necessarily more important than the other.
The header structure is generally best arranged into a tree shape so that subheaders have a logical relationship with their parent headers, and headers on the same level under the same parent header belong to the same group. In other words, the diesel generator is a subheader under the Engine room because that's where the generator is. That much should be obvious, but subheaders under the the same parent header should also share a "theme" between each other: in the above example, if one of the subheaders is a new room-specific action, it's then better to group the objects under a new parent header so that the new action is not on the same level with the objects.
The important thing here is to not get hung up on getting it right the first time. The structure is allowed to live, and I tend to move parts of code around constantly while writing. The time it takes to keep the code organized is more than generously paid back later when navigating the code is fast and intuitive.
All that said, in the end the general top-level structure tends to usually be more or less something like this:
Meta
License
Changelog
Extensions
Bibliographical information
Releasing
Mechanics (any of these headers could get promoted to their own volume if there's a lot of content)
Commands
Modifications to standard commands
New commands
Out of world commands
Credits
Instructions
Hints
Default messages
Modifications to standard rules
New kinds
Scenes
Gameplay logic
Conversation system
Special mechanics
World
Rooms
Room 1
Thing in room
Misc scenery
Backdrops
Major NPCs
Debugging
But, as said, this is not a rigid structure but something that tends to form as a result of the dynamic method.
Sam Barlow's (of Aisle fame) Her Story has already sweeped most of the GOTY awards, and rightfully so.
The gameplay consists solely of searching a database for interrogation film clips and piecing together the full story. It's something that shouldn't work but it does, and it works so well. Even though you could in theory stumble upon the clips in any order, the game manages to direct the player's attention well enough that the whole plot unravels in coherent chunks. I'm hoping this will spawn a whole genre of games with similar gameplay.
Book of the Year: Stand Still. Stay Silent
This year's book is the print edition of Minna Sundberg's webcomic Stand Still. Stay Silent. The setting is a post-apocalyptic world where a virus has wiped out most of the planet's population. Humanity survives only in isolated locations in the Nordic countries; 80% of known survivors live in Iceland that closed its borders before the outbreak reached it.
At times the comic's weak point is the writing, but the setting and stunningly beautiful artwork more than makes up for it. The physical book was crowdfunded and might be hard to come by, but the whole comic can be read at the web site.
Movie of the Year: Star Wars: The Force Awakens
After the disastrous prequels, The Force Awakens is the first real Star Wars movie in 30 years. The plot is a rehash from the original films, but with some clever reversals of some of the tropes.
What makes the film special is that it's replicating the scavenged technology mood of the original films. In the originals everything looks like it's been hand-built from spare parts. In the prequels this angle is completely forgotten and you get aberrations like this silver-plated spaceship:
In The Force Awakens the scavenging theme is back: you can even see dents and scratches in Kylo Ren's mask. My theory is that paradoxically technology at the turn of the millennium wasn't yet advanced enough to replicate what they did in the 70s with the originals. Similar to how videogame graphics quality took a nosedive in the 90s when the industry started the transition to 3D graphics, there was a period of time when film industry was making use of CGI but it wasn't quite up to the task yet and everything looked plastic and fake. The prequels were made right in the middle of this transition.
Now CGI is good enough to make virtual things that look (almost) indistinguishable from the real things. That allows the filmmakers for example to show both CGI and physical props in the same scene and have both of them look natural. This is, among many other things, a key thing in what makes The Force Awakens a real Star Wars film.
Blog of the Year: Sibyl Moon Games
Carolyn VanEseltine's Sibyl Moon Games covers a variety of topics associated with IF and game design. It is, above anything, practical: it's immensely interesting to read about real life game design instead of just the theory of it.
Many blogs tend to be aimed at either beginners or experts, but there aren't many that focus on the intermediate level. Sibyl Moon hits this sweet spot. The articles are written in a way that anyone with basic background knowledge can understand them, but the topics are usually general enough that they're relevant to a large reader base.
Festival of the Year: Spring Thing 2014
Moving away from IFComp-style judged competition, Spring Thing is now a festival: entries aren't judged (apart from "best of" ribbons), and there's a "back garden" category that lets authors showcase their work, even if it doesn't quite fit the criteria in the main category. By taking a radically different approach than other traditional competitions, Spring Thing fills a niche that has largely been missing from the community: unjudged game jam type events that encourage experimentation and have a more relaxed feel than strict competitions.
Last week I attended the ICIDS 2015 conference in Copenhagen. The conference was about academic research on Interactive Digital Storytelling (IDS) which is very close to what we call Interactive Fiction, with some key differences. The topics revolved mostly around making computer-generated story content, emergent gameplay, and autonomous non-player characters. In a nutshell you could say that while IF is about using computers to tell stories, IDS is more about making computers tell stories.
The IDS people seem to be well aware and at least superficially following the IF scene. People like Emily Short, Squinky and Porpentine were mentioned several times. Inklewriter was used to build a game in one study. The interest is naturally in things that are close to the areas of research, so games that have something to do with computer-assisted content generation are the ones that get most attention.
All conference papers can be downloaded here. The ebook download is available for free for an unspecified time so it's best to grab it while it's there. Once the offer expires the download will cost more than 50 €.
The defining dilemma with IDS seems to be that computer-generated content is often random and incoherent in contrast to human-written narrative. On the other side of the scale you have generated content that's random but allows for emergent stories, and on the other side there's human authored content that's coherent but restricts the story to the pre-written plot. A lot of effort is going into bridging this gap so that generated narrative would have the best of both worlds: highly emergent plot that's still a coherent whole.
One of the suggested approaches (Ryan et al) was detecting sensible plots from a story world where many players or autonomous NPCs interact with each other and create emergent content. Dwarf Fortress was used as an example of such world. The method was to analyze things like when individual events happened and what kind of narrative tension the events had. This was a just a theoretical idea at this point so there wasn't yet any actual algorithm that could do this.
Hartmut Koenitz has taught interactive narrative classes using his own ASAPS system which seems to be one of the more mature projects, although it's available on request only. He has identified some tendencies that his students have when writing interactive stories:
Tendency to build strictly non-convening branches: the story branches but there's always only one path to a given passage (traditional CYOA book style)
Strong binary choices ("do you a) give your money to charity or b) become a crime lord") instead of more nuanced options
Mechanistic pacing: each passage ends in a choice
Narcissistic content: the students want every reader to see all content the game has
Koenitz also talked about how effective temporary removal of control can be for an interactive story. If you sometimes take away control from players, the control they are left with becomes more precious to them.
Alex Mitchell analyzed reflective rereading of digital narrative, and presented three types of motivations for rereadings:
Partial rereading: rereading because you can piece together more of the story after you've seen the whole thing (e.g. Memento)
Simple or unreflective rereading: you want to recapture the experience you had the first time
Reflective rereading: having seen the work before, you know what it's about and want to view the work with that extra information, for example to identify details that might have been missed the first time (e.g. 6th Sense)
He also identified three types of experiences from generated or highly varying interactive narratives:
Eliza effect: The system looks complex but is actually simple. Telltale's games were used as an example of this: at first playthrough they seem to offer a large degree of choice, and the games do their best to reinforce this interpretation (periodical "They will remember this" notifications for example), but on replay it becomes evident that the plot is actually largely predetermined.
Tale-Spin effect: The system looks simple but is actually complex, and the player may never become aware of the underlying complexity.
SimCity effect: The system is complex and works with the player to build up understanding of the complexity. Emily Short's Blood and Laurels was used as an example of this type of game.
New Dimensions in Testimony is a project that has filmed interviews of a holocaust survivor. A holographic projector shows him in 3D and you can ask questions that are interpreted with voice recognition software. The aim is to replicate a face-to-face conversation as accurately as possible so that people can have that experience even after it's not physically possible anymore.
The end result looks like something out of Star Trek, and the numbers are impressive: the system has 1700 different responses and testing showed that there was an appropriate answer 95% of museum visitors' questions in the database, although due to speech recognition and language parsing issues the system replied correctly only two thirds of the time. They were confident that question understanding can be further improved.
Kate Compton talked about her generative text tool, Tracery, and announced a new IDE for it at tracery.io. It basically takes a certain data structure and generates variations based on the list of text strings given:
{
"origin": [
"#location# you can see a #landmark#."
],
"location": [
"Behind the #building#",
"Far ahead",
"Somewhere in the distance",
"Nearby"
],
"building": [
"house",
"shack",
"gazebo",
"garage"
],
"landmark": [
"river",
"forest",
"beach",
"hill",
"lake",
"swamp",
"mountain range"
]
}
The placeholders (#location#, #landmark#, #building#) would be replaced with random items in the lists, resulting in e.g. "Behind the gazebo you can see a beach" or "Far ahead you can see a swamp."
Tracery is probably best known as the main component of Cheap Bots Done Quick which is a Twitter bot making service. I tried it out and made a couple of Twitter bots, and it really lives up to its name: it took less than an hour in total and most of that time went in trying to find suitable word lists.
Here's to the costive ones. The fencings. The Barrymores. The middle ages. The echoic schoolbags in the colorful art class.
— Here's To Bot Ones (@HeresToBotOnes) 13 Dec 2015
Elizaveta Shkirando from Ubisoft talked about "betatesting" story elements in games. Usually in AAA game development narrative elements have low priority and story writers are brought in at a late stage when it's practically too late to get feedback. Ubisoft has tried to change this by making it possible for writers to get narrative feedback much earlier.
The writers made a 5-10 page long summary of the script (which was not too big and not too vague) that was given to two groups. The first group was writers not involved in that particular project, and the second group the game's designers who weren't directly involved with writing the script. The groups were able to make notes to the script, ask questions from the writers, and then answer a questionnaire that had evaluations like:
Appreciation: "I enjoyed this section of the script."
Comprehension: "I understood what was happening in this section of the script."
Interest: "I want to know what happens next in the story."
Character motivation: "I understand the protagonists motivations in this part of the story"
Character progression: "I understand what the protagonist must do next."
The questionnaire repeated after every section of the script, and at the end there was a final questionnaire that had questions about overall likes and dislikes, most memorable moments, satisfaction with the story's ending and so on. Afterwards the testers who gave the most interesting and insightful comments were invited to a group discussion with the writers.
Shkirando also stressed that it's important to ask and receive positive feedback as well instead of just lists of problematic issues. This helps the writers to not lose the good parts when they're fixing the problem areas.
Melissa Roemmele showed a story writing assistant that could help alleviate writer's block by adding a new sentence to the story on demand. The corpus is about 20 million stories collected from blogs, consisting of in total about 700 million sentences. The software analyzes the story that's being written and picks a sentence that seems to be the best fit for the context.
It's uncertain how well the tool would work in practice, but it would be at least a cool toy to play with. Unfortunately it's not publicly available.
In addition to the presentations, there were posters and game demonstrations. Some of the games were more traditional and not necessarily about interactive narrative, at least in the traditional sense. Here are a couple of picks:
An "interactive documentary game" that lets you make a documentary about a crime organization. The material for it is real and they're filming it right now. The release is set to next year but the feature list seemed so ambitious that it seems likely that 2016 is an overly optimistic target.
Blue Behold by Karleen Groupierre is a physical setpiece that's "painted" by a video projector. It comes with glasses that track eye movements: a spotlight follows the player's gaze and interacts with the environment. It's really beautiful and fun to play. Too bad the set's physical size and special equipment mean you need access to the original work to be able to play it.
Don't Let Them Die by Rob Homewood is equal parts artwork and game. The game consists of a flock of birds flying around a pretty landscape. It pulls stock data from the Internet every minute, and if it detects a massive drop in stock prices in a short period of time, the birds die. Therefore you play the game by preventing stock market from crashing: by being part of society and consuming.
It could of course be debated whether the humankind can play a game like this, or whether it's a game at all. As an art piece it's multifaceted and thought-provoking; easily the most interesting demo in the conference.
The problem with a lot of academic software projects is that they're built for the purposes of a single, often very narrow, research project. It might be about, for example, a single aspect of autonomous NPC behavior, and a game is made focusing on that only. The end result is either a short demo that looks very interesting but isn't complete, or a system that does that one thing they're studying but isn't really usable in real world applications. It seems very similar to what happens with IntroComp games: when asked about it, every single author says that afterwards they're going to expand and release the game or tool they've created, but in real life that happens about as often as an IntroComp game gets a full release.
One project from Reykjavik University looked very promising: it aims to combine all these small projects into one complete system that could be used to make real games. It includes five different technologies that are way beyond my understanding, but apparently the end result would be a tool to make complete simulated story worlds.
…I didn't have time to build it to scale or paint it.
To end the Back to the Future theme week, here's a concept of a time travel game I've toyed with on and off for the past five years. It's remarkable because the core mechanics can't be implemented in any of the existing parser IF interpreters, so the Vorple project was started just to make something that could run it.
The demo is completely artificial. It doesn't run on any game engine, only basic JavaScript that animates the elements. While viewing the demo click anywhere to trigger the next turn.
There are at least 6 or 7 projects in the pipeline before this one, so it's not realistically going to see the light of day in some while if ever. It also turns out that designing and implementing something like this is really hard in just about every aspect. But it's thematically appropriate, and a neat concept, so here you go.
This game would require you to think fourth dimensionally.
Feel free to draw inspiration from it as much as you want. Or, in other words, it would be cool if someone else made this because I just really want to play it.
This concludes the Back to the Future theme week. Thanks for reading!
Remove everything that has no relevance to the story. If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it's not going to be fired, it shouldn't be hanging there.
The idea is to remove anything that's not going to be relevant to the story, or in other words, don't add too many red herrings.
A real life example: my very first work of IF was about a hard-boiled detective who, as I first assumed, has to carry a handgun as the genre trope dictates. The problem was that there was no actual use for the gun at any point in the story. It was just inventory filler for the sake of "realism." It wasn't until a beta tester brought the subject up when the gun had to go.
Let's take another practical example. A story features a bedroom. There you have a bed and a nightstand. On the nightstand there's a ballerina-shaped porcelain clock. As per the Chekhov's gun principle, we ask ourselves what purpose do these items have. The bed is there because it's an essential part of a bedroom; there would have to be a good reason for not having one there. The night stand is there to support the clock.
That leaves the porcelain clock. Why is it there? Does it play a part in the plot later on? Does it tell something important about its owner? Whatever its purpose, owning such a tacky thing is notable enough that it would have to be explained. It can't just spontaneously exist without a reason.
If it turns out that the clock is not a Checkhov's gun, i.e. it doesn't have a relevance to the story, then it should go. And since the only purpose of the nightstand was to provide a place to put the clock on, it shouldn't be mentioned either.
Note that, in the context of text-based narrative, not mentioning something doesn't mean that it doesn't exist in the story world. It just means that it's not significant enough to mention (or implement). Every location has tens or even hundreds of things that could be realistically expected to exist but have no relevance and therefore aren't mentioned or implemented.
The reverse Chekhov
Here's a transcript of an interview from the documentary Tales from the Future: In the Beginning... where Back to the Future writer and producer Bob Gale talks about writing the script.
We use the index card method of plotting. So we would have a big bulletin board in our office, and we would say "ok, we know, for example, Marty goes back in time." So, an index card goes up, says "Marty goes back in time." And then, towards the end "Marty goes back to the future," that's another card.
So we said ok, wouldn't it be cool if he invented rock 'n' roll. So we put up a card saying "Marty invents rock 'n' roll." Well, we need to establish that he can play rock 'n' roll. And that he wants to play rock 'n' roll. So that means that somewhere on the bulletin board before the card that says "he goes back in time": "establish Marty's desire and ability to play rock 'n' roll."
Same thing with the skateboard. If he's going to invent the skateboard, show him on a skateboard. So these pairs of index cards would come up.
In light of this technique I'd like to turn the Chekhov's gun principle around:
If a rifle goes off in the second or third chapter, in the first chapter you must say that there is one hanging on the wall.
This is perhaps even more useful than the standard Chekhov's rule, at least in the early stages when you're designing the overall plot of the story. Working backwards by taking things you want the story to feature and adding things that support that feature to earlier points in the story will add a nice dose of authenticity to the setting and characters.
Common writing advice is to always avoid clichés, but that's too simplistic to accept as a universal rule. Clichés and sterotypes serve to support another advice: Show, don't tell.
The main purpose of stereotypes in narrative is to establish character archetypes that are already familiar to the readers or viewers. Take, for example, the character of Doc Brown from the Back to the Future films. The "crazy wild eyed scientist" look immediately communicates a lot of information about the role of this character. We can expect some advanced, perhaps slightly humorous, and possibly dangerous inventions.
At the beginning of the first film, Marty's father George is portrayed as a stereotypical loser. He has a bad posture, a greasy haircut, and a pocket protector. At the end of the film, when Marty returns to his own time, he notices that his actions in the past have inadvertently changed his family. George is no longer the pushover he used to be. Beating Biff in the past gave him a boost in confidence which changed the course of his life permanently. He wears stylish clothing and a neat haircut. The slouch is gone.
Left: "I'm just not very good at confrontations." Right: "Now Biff, don't con me!"
The scene when Marty returns home and discovers the change in his family is almost purely show-don't-tell. At no point is it explained what's happened, the viewers are given more than enough clues to come to the right conclusion themselves.
The portrayal of new George wasn't completely successful, though. Outside USA George's appearance wasn't as easily recognized as the stereotype of a successful person. In mid-80s the yuppie stereotype had just reached its peak in popular culture but it was largely America-specific at that point. While the change of appearance of Marty's home and family members can't easily be misinterpreted, some nuances were lost to audiences in other cultures. Especially confusing to European viewers was why Marty's parents are carrying tennis rackets: the "rich people play tennis" stereotype is distinctly anglospheric.
This shows that stereotypes are culture-specific and that they change over time. They apply only for a relatively short period. In Back to the Future part III the 1955 version of Doc Brown chooses clothes for Marty to wear for his trip to 1885. Doc's perception of cowboy clothing seems to be colored by rodeos and early westerns, and even the 30 years older version of himself recognizes the outdated cliché.
"I dunno, are you sure this stuff is authentic?"
Drawing conclusions from these precedences, good use for clichés and stereotypes is when you want to establish a well known archetype. It's still good to remember that stereotypes are dependent on culture and time, so their meaning might be lost on some of the audience. Bad use of stereotypes is if the reason for applying them is "for laughs" or because "that's how they all are". When they're done well, clichés can be used as a powerful authorial tool.
The action's name (which is displayed when the command is dragged over its target) doesn't have to be strictly verb-noun anymore. The most common use case is adding prepositions ("sit under tree" instead of "sit tree") but it can be changed to anything at all ("sit" + "tree" → "rest under the redwood"). 
Cover page and cover art; the cover page also acts as a tutorial for people who are playing a Texture game for the first time. Clicking or tapping the play button shows a "ghost" of the button being dragged to demonstrate how interaction works, and clicking again pops up explicit instructions.
…I didn't have time to build it to scale or paint it.
Common writing advice is to always avoid clichés, but that's too simplistic to accept as a universal rule. Clichés and sterotypes serve to support another advice: Show, don't tell. 
