Primary Faculty Advisor
Sandra M. Leonard
Presentation Types
Individual Presentation
Description
Shepherding will technically be the second creation in a greater project of mine I’ve been calling Project Bleak. The first creation is unfinished and still a WIP, but is meant to be an anomalous NES-style game called Bleak. The story behind it is that evidence of an obscure game development team from the late era of NES games has resurfaced, and a community of lost media gurus, classic game experts, and similar people (plus anyone else who wants to help) has formed to hopefully unravel the mystery of who they were.
Bleak is really just meant to be an odd game played on a fake emulator made by a few people in this community, but through playing it, players may gain access to more background on the community and their work. Shepherding has the player learn about the community in a more direct way- by putting them in the shoes of someone involved. It takes place before Bleak and is meant to introduce them to the idea of the hunt. The mystery company is known as Blacksheep Ltd., seemingly a British development team from around 1990.
As may be pretty clear, fans of lost media hunts, unsolved gaming mysteries, and ARGs (alternate reality games) such as Petscop and Crow 64 (also known as Catastrophe Crow) are the intended audience. While much of Shepherding is lore and buildup, the proper gameplay lets them try and dive into the complicated process of searching for lost media. In terms of purpose, that is likely the closest thing to it: to let the player feel like they have a hand in uncovering aspects of a bigger mystery. Speaking of which, the genre is primarily Mystery, albeit with some Horror involved. The game is meant to sometimes feel unsettling and will explore blatantly (and often disturbingly) ambiguous material.
Petscop and Crow 64 have very similar atmospheres, suffused with mystery, ambiguity, and a notable lack of feeling comfortable. They also utilize small, easily missed details to convey hidden story elements, as well as puzzles, ciphers, and other material to essentially guard story elements. I’ve planned to incorporate all of thesesince the beginning, and through doing so hope to appeal to the intended audience (both ARGs also present themselves as Lost Media and forgotten classic games). Next to other interactive fiction games, Shepherding will likely be considerably different when it comes to content. In certain sections, the game will utilize user input through prompts and terminals, though it will primarily use hyperlinks. It also aims to immerse the player as best it can through means such as “logging in”, the game acknowledging the player’s selected username, and attempts to replicate the general feel of a Reddit-like discussion board. Shepherding will probably be closest to The Uncle who works for Nintendo, if anything, since not only is it Horror-ish and odd, but it’s themed around games and also takes place within a small collection of passages for most of the game. One ending may also be reminiscent of some of those from TUWWFN. Shepherding will also take place primarily within “w/flockfinders” which is a fake discussion board of threads and chat rooms created through interlinked passages.
Before moving on, I wanted to explain an obstacle I ran into. When planning out the game, I wanted to have different gameplay for each section of the game. Specifically, I wanted a Reddit-style board, a chat room, a search engine, and a more traditional IF map with a Horror twist (and Hide & Seek-like gameplay). However, the chat room and search engine both relied on the same mechanic: a user input console, like those seen in games like Zork. However, Twine lacks this functionality by default, so I had to figure out workarounds. Though simple, finding these took a few hours of experimentation and reading through Harlowe documentation, and I took two approaches, one for the chat room, the other for the search engine.
The chat room was originally meant to allow any input, and appear as an actual live feed that would react to input. Now, the player is presented with a dropdown list of a few possible messages they could send. After selecting a message, they can then type this message into the input box. No matter what keys they press, it will always type out the selected message. This allows the user’s input to be accurately predicted, and also helps salvage the illusion of being in a real chat room. The search engine, on the other hand, is a little flimsier, but it still works. The player can type in whatever they want, and it is intended that they recall any lore they discovered on the “Wroddyt” board to use as search terms. Unfortunately, Twine’s input boxes also lack functionality with the Enter key, jumping to a new line like a text editor instead of “submitting” its contents. As a workaround, I added a “Search” button just below it. When clicked, it reads whatever was typed into the search box, and compares it to hard coded search terms stored in an array. If it’s a match, it increases the player’s search progress. It also remembers all terms attempted, so the player can’t enter the same successful search term over and over again. The player also gets three free attempts before searching presents a risk.
I’m going to choose to be intentionally vague about the other big part of the game, that being the monster, as most of the fear surrounding it, I feel, comes from lack of description. As the writer, I do have some idea of what I think it looks like, but I decided to leave that out. It’s far more fun to let the player decide what it looks like, having nothing more then exceedingly vague context clues to go off of. The monster also presents itself differently in different parts of the game. In the beginning, it’s simply a bizarre Wroddyt user (where the numbers of each herdsman account come into play, I won’t say). It also tries to trap the player through personal messages, baiting them with the password to the chat room. But should the player make it far enough to get close to either of the good endings, it takes a more physical approach. In the Search ending, it’s implied it breaks into the player character’s home should they fail. In the “Ohio” ending, it literally tracks the player character down and toys with them like a cat. Both programming the behavior of and writing the “descriptions” for the monster was by far the most enjoyable part of making the game.
In the “Ohio” ending, the player gets a short while to explore the building with no immediate danger present (side note: how long this lasts is actually tied to how many run-ins the player had with herdsmen). After this point, the monster enters the building. If the player used the door or fire escape instead of breaking the window, the monster breaks through, alerting the player. Otherwise, it silently shows up. The monster’s behaviour is relatively simple: it uses an array containing the names of the buildings’ rooms. Whenever the player enters a room, the monster will move to a different one, and the passage will see if it is inside itself or in an adjacent passage. If it is in an adjacent passage, the player is warned, the link will jitter, and the player will die if they go through this link. If it is in the current passage, the player is presented with a short timer where they must run or hide. This was accomplished using the meter macro, which was also used for the search engine’s load bar ending. Failure to run or hide on time results in death. Running is as simple as leaving the room, whereas Hiding is its own mechanic. The player must keep their noise down until the monster leaves, making for a stressful button mashing contest to slow the noise meter down as it races towards 100. Whenever the button is pressed, it sets back the meter’s progress a bit. The player will die if the noise meter reaches 100. The monster was planned to be a bit more active and intelligent, but for time’s sake this was cut. As a result, a player could theoretically go through the first half of the “Ohio” ending without encountering it.
In total, the game has five endings, two good and two bad, plus an easy neutral one that’s more of a joke ending. It’s definitely easier to get bad endings than good, but this is by design both for the challenge and to add value to getting the good endings. A last minute addition as a precaution to potential frustration was a Try Again button that will show up if the player dies during the Search or “Ohio” ending, letting them start at their beginnings rather than the start of the whole game. My hope is that, in its final state, it presents an interesting experience with multiple different playstyle depending on the paths a player takes.
Recommended Citation
Rainer, Alexander, "Twine 1: Shepherding" (2022). KUCC -- Kutztown University Composition Conference. 1.
https://research.library.kutztown.edu/compconf/2022/presentations/1
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
Twine 1: Shepherding
Shepherding will technically be the second creation in a greater project of mine I’ve been calling Project Bleak. The first creation is unfinished and still a WIP, but is meant to be an anomalous NES-style game called Bleak. The story behind it is that evidence of an obscure game development team from the late era of NES games has resurfaced, and a community of lost media gurus, classic game experts, and similar people (plus anyone else who wants to help) has formed to hopefully unravel the mystery of who they were.
Bleak is really just meant to be an odd game played on a fake emulator made by a few people in this community, but through playing it, players may gain access to more background on the community and their work. Shepherding has the player learn about the community in a more direct way- by putting them in the shoes of someone involved. It takes place before Bleak and is meant to introduce them to the idea of the hunt. The mystery company is known as Blacksheep Ltd., seemingly a British development team from around 1990.
As may be pretty clear, fans of lost media hunts, unsolved gaming mysteries, and ARGs (alternate reality games) such as Petscop and Crow 64 (also known as Catastrophe Crow) are the intended audience. While much of Shepherding is lore and buildup, the proper gameplay lets them try and dive into the complicated process of searching for lost media. In terms of purpose, that is likely the closest thing to it: to let the player feel like they have a hand in uncovering aspects of a bigger mystery. Speaking of which, the genre is primarily Mystery, albeit with some Horror involved. The game is meant to sometimes feel unsettling and will explore blatantly (and often disturbingly) ambiguous material.
Petscop and Crow 64 have very similar atmospheres, suffused with mystery, ambiguity, and a notable lack of feeling comfortable. They also utilize small, easily missed details to convey hidden story elements, as well as puzzles, ciphers, and other material to essentially guard story elements. I’ve planned to incorporate all of thesesince the beginning, and through doing so hope to appeal to the intended audience (both ARGs also present themselves as Lost Media and forgotten classic games). Next to other interactive fiction games, Shepherding will likely be considerably different when it comes to content. In certain sections, the game will utilize user input through prompts and terminals, though it will primarily use hyperlinks. It also aims to immerse the player as best it can through means such as “logging in”, the game acknowledging the player’s selected username, and attempts to replicate the general feel of a Reddit-like discussion board. Shepherding will probably be closest to The Uncle who works for Nintendo, if anything, since not only is it Horror-ish and odd, but it’s themed around games and also takes place within a small collection of passages for most of the game. One ending may also be reminiscent of some of those from TUWWFN. Shepherding will also take place primarily within “w/flockfinders” which is a fake discussion board of threads and chat rooms created through interlinked passages.
Before moving on, I wanted to explain an obstacle I ran into. When planning out the game, I wanted to have different gameplay for each section of the game. Specifically, I wanted a Reddit-style board, a chat room, a search engine, and a more traditional IF map with a Horror twist (and Hide & Seek-like gameplay). However, the chat room and search engine both relied on the same mechanic: a user input console, like those seen in games like Zork. However, Twine lacks this functionality by default, so I had to figure out workarounds. Though simple, finding these took a few hours of experimentation and reading through Harlowe documentation, and I took two approaches, one for the chat room, the other for the search engine.
The chat room was originally meant to allow any input, and appear as an actual live feed that would react to input. Now, the player is presented with a dropdown list of a few possible messages they could send. After selecting a message, they can then type this message into the input box. No matter what keys they press, it will always type out the selected message. This allows the user’s input to be accurately predicted, and also helps salvage the illusion of being in a real chat room. The search engine, on the other hand, is a little flimsier, but it still works. The player can type in whatever they want, and it is intended that they recall any lore they discovered on the “Wroddyt” board to use as search terms. Unfortunately, Twine’s input boxes also lack functionality with the Enter key, jumping to a new line like a text editor instead of “submitting” its contents. As a workaround, I added a “Search” button just below it. When clicked, it reads whatever was typed into the search box, and compares it to hard coded search terms stored in an array. If it’s a match, it increases the player’s search progress. It also remembers all terms attempted, so the player can’t enter the same successful search term over and over again. The player also gets three free attempts before searching presents a risk.
I’m going to choose to be intentionally vague about the other big part of the game, that being the monster, as most of the fear surrounding it, I feel, comes from lack of description. As the writer, I do have some idea of what I think it looks like, but I decided to leave that out. It’s far more fun to let the player decide what it looks like, having nothing more then exceedingly vague context clues to go off of. The monster also presents itself differently in different parts of the game. In the beginning, it’s simply a bizarre Wroddyt user (where the numbers of each herdsman account come into play, I won’t say). It also tries to trap the player through personal messages, baiting them with the password to the chat room. But should the player make it far enough to get close to either of the good endings, it takes a more physical approach. In the Search ending, it’s implied it breaks into the player character’s home should they fail. In the “Ohio” ending, it literally tracks the player character down and toys with them like a cat. Both programming the behavior of and writing the “descriptions” for the monster was by far the most enjoyable part of making the game.
In the “Ohio” ending, the player gets a short while to explore the building with no immediate danger present (side note: how long this lasts is actually tied to how many run-ins the player had with herdsmen). After this point, the monster enters the building. If the player used the door or fire escape instead of breaking the window, the monster breaks through, alerting the player. Otherwise, it silently shows up. The monster’s behaviour is relatively simple: it uses an array containing the names of the buildings’ rooms. Whenever the player enters a room, the monster will move to a different one, and the passage will see if it is inside itself or in an adjacent passage. If it is in an adjacent passage, the player is warned, the link will jitter, and the player will die if they go through this link. If it is in the current passage, the player is presented with a short timer where they must run or hide. This was accomplished using the meter macro, which was also used for the search engine’s load bar ending. Failure to run or hide on time results in death. Running is as simple as leaving the room, whereas Hiding is its own mechanic. The player must keep their noise down until the monster leaves, making for a stressful button mashing contest to slow the noise meter down as it races towards 100. Whenever the button is pressed, it sets back the meter’s progress a bit. The player will die if the noise meter reaches 100. The monster was planned to be a bit more active and intelligent, but for time’s sake this was cut. As a result, a player could theoretically go through the first half of the “Ohio” ending without encountering it.
In total, the game has five endings, two good and two bad, plus an easy neutral one that’s more of a joke ending. It’s definitely easier to get bad endings than good, but this is by design both for the challenge and to add value to getting the good endings. A last minute addition as a precaution to potential frustration was a Try Again button that will show up if the player dies during the Search or “Ohio” ending, letting them start at their beginnings rather than the start of the whole game. My hope is that, in its final state, it presents an interesting experience with multiple different playstyle depending on the paths a player takes.
