After playing around a bit with some different kinds of interactive fiction/narrative games, there seems to be a couple of different kinds of games/stories where the tool used to make the game in effect becomes the genre. Four types of stories/games stuck out to me as being commonly made:
Ren'py is built on top of Python, and in fact, Python code can be used in conjunction with the "Ren'py scripting language." Programs written for use with Ren'py often look something like this (from this example in the documentation):
# Declare characters used by this game.
define s = Character(_("Sylvie"), color="#c8ffc8")
define m = Character(_("Me"), color="#c8c8ff")
# This is a variable that is True if you've compared a VN to a book, and False
# otherwise.
default book = False
# The game starts here.
label start:
# Start by playing some music.
play music "illurock.opus"
scene bg lecturehall
with fade
"It's only when I hear the sounds of shuffling feet and supplies being put away that I realize that the lecture's over."
"Professor Eileen's lectures are usually interesting, but today I just couldn't concentrate on it."
"I've had a lot of other thoughts on my mind...thoughts that culminate in a question."
"It's a question that I've been meaning to ask a certain someone."
scene bg uni
with fade
"When we come out of the university, I spot her right away."
show sylvie green normal
with dissolve
"I've known Sylvie since we were kids. She's got a big heart and she's always been a good friend to me."
"But recently... I've felt that I want something more."
"More than just talking, more than just walking home together when our classes end."
menu:
"As soon as she catches my eye, I decide..."
"To ask her right away.":
jump rightaway
"To ask her later.":
jump later
Thoughts about renpy code:
There are probably other tools out there for visual novels but Ren'py is definitely the most used.
Text based choose your own adventure games are a more general version than the visual novel. Right now, it seems that twine is the most popular tool for making these. Twine is largely manipulated using a GUI, but is transcompiled to javascript. There are a couple of different scripting languages that work with Twine, mainly Harlowe and Sugarcube. A typical chunk of Twine written in the GUI looks like this:
(track: "squeeze", "stop")
(track:"call", "loop", true)
(track: "call", "playwhenpossible")
<div class="messages">
<div class="left-message">the men wild with lust will grind you down
and reap abundant crop relentlessly</div>
<div class="right-message">but what about you and your violence?
in hunting for a satiating meal</div>
<div class="left-message">until the fertile essence of the soil
disintegrates into a desert sprawl</div>
<div class = "right-message">poised with poison arrow at the bow
driving death blow toward an orphaned fawn?</div>
<div class = "left-message">hysteric bitch come suddenly unhinged
have you no shame? no love in recompense?
no one will look upon your fallow field
and think to sow seeds in the early spring
</div>
<div class = "right-message">but fall’s chill will keep you returning here
for [[nourishment->squeezing]] 'fore snow accumulates</div>
</div>
Thoughts on twine:
I've worked with Twine quite a bit, but I often find myself frustrated with the scripting languages that come built in. Often, the built in commands have to be finagled in order to accomplish what I think of as simple tasks.
The nice thing about twine is that it produces a single html file which can then be hosted pretty simply without having to dive in to any other code. When you export something from twine, it's ready to be hosted. (it can be done pretty easily using free tools like Github Sites, too)
I think I would be more satisfied with Twine if it were easier to work directly with the file. There is some file on my system somewhere that has the Twine story before it's been published to html, but it's impossible to find and modify. Stylesheets and accessory javascript seem ok and easy enough to edit and add, but sometimes require solutions that encourage bad habits. It's hard to write anything that looks really clean when you're stuck with the built in languages, though.
And, as you can see above, the amount of HTML required to make anything look decent/well designed is far more than I expected for a tool marketed to writers.
Another text based version of interactive fiction, this time the more traditional style of parsing a player's input. Versions of this kind of game have existed since the creation of Colossal Cave Adventure in the 70s (This was the game that inspired the Infocom folks to create Zork, before they were technically Infocom). From my own playthrough of adventure, here's what the game looks like to the average player.
You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.
> enter building
You are inside a building, a well house for a large spring.
There are some keys on the ground here.
There is a shiny brass lamp nearby.
There is food here.
There is a bottle of water here.
> take keys
OK
> take lamp
OK
> take food
OK
> take water
OK
> look
Sorry, but I am not allowed to give more detail. I will repeat the
long description of your location.
You are inside a building, a well house for a large spring.
> go outside
You're in front of building.
> look
Sorry, but I am not allowed to give more detail. I will repeat the
long description of your location.
You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.
> verbose
Sorry, I don't know the word "verbose".
As you can see, there is little guidance about what input might be acceptable, and the player usually figures out what they can and can't do with experimentation. In these early games, the commands were limited to one to two words, usually written
You're in bird chamber.
A cheerful little bird is sitting here singing.
> cage bird
The bird seemed unafraid at first, but as you approach it becomes
disturbed and you cannot catch it.
> feed bird
It's not hungry (it's merely pinin' for the fjords). Besides, you
have no bird seed.
> look
You are in a splendid chamber thirty feet high. The walls are frozen
rivers of orange stone. An awkward canyon and a good passage exit
from east and west sides of the chamber.
A cheerful little bird is sitting here singing.
> take bird
The bird seemed unafraid at first, but as you approach it becomes
disturbed and you cannot catch it.
Are you trying to catch the bird?
> catch bird
Please answer the question.
Are you trying to catch the bird?
> yes
I am prepared to give you a hint, but it will cost you 2 points.
Do you want the hint?
> no
OK
Which, to me, seemed an awkward way of adressing the problem at hand.
Since the 70's, these types of games have continued to advance, and so have the technologies used to create them. For example, the AI driven game Facade takes any sentence that the player types as input and interprets it as dialogue, thanks to the power of natural language processing. The interaction between the player and the two non playable characters, Grace and Tripp, is mediated by an artificial intelligence algorithm created by Michael Mateas and Andrew Stern which is based on the book "Games People Play" by Eric Berne. It is one of the few examples of recent text "adventure" games which improves upon the original concept with new technologies.
Of course, not every text adventure game created recently uses such complex computation techniques. Plenty of programmers stick to the basic model and write these games without any advanced tools. However, a few tools exist for the creation of these games, one of the most powerful ones being a programming language/IDE called Inform. Inform is open source and was created specifically for designing interactive fictions like Zork/Adventure/etc. The programming language follows Knuth's literate programming practices, and is written like natural language:
"Pages"
The Library is a room. The sinister book is carried by the player. The sinister book has a number called the last page read. The sinister book has a number called the length. The length of the sinister book is 50.
Understand the command "read" as something new.
Understand "read [something]" or "consult [something]" or "read in/from [something]" as reading. Reading is an action applying to one thing, requiring light.
Understand "read [number] in/from/of [something]" or "read page [number] in/from/of [something]" or "look up page [number] in/from/of [something]" or "consult page [number] in/from/of [something]" as reading it in. Reading it in is an action applying to one number and one thing, requiring light.
Named page is a kind of value. The named pages are first page, last page, next page, previous page.
To decide what number is the effective value of (L - last page):
decide on the length of the book.
To decide what number is the effective value of (F - first page):
decide on 1.
To decide what number is the effective value of (N - next page):
let X be the last page read of the book plus 1;
decide on X.
To decide what number is the effective value of (P - previous page):
let X be the last page read of the book minus 1;
decide on X.
Understand "read [named page] in/from/of [something]" or "read the [named page] in/from/of [something]" as reading it relatively in. Reading it relatively in is an action applying to one named page and one thing, requiring light.
Does the player mean reading something in the sinister book: it is very likely.
This is the sort of design choice I was thinking of making for my own language, but reading this as a computing person, it feels kind of verbose. Maybe there is a better way to encode natural language into a programming language? There are also examples of literate programming where the code itself doesn't read like natural language, but the documentation ability is considerably more fleshed out than other programming languages, like Eve. While the page linked is an .eve file, it is capable of running in browser, and displays much more like a doc page than source code. Perhaps the declarative style is not ideal? I personally think it's a bit ambiguous.
Of course, there are also creators using game engines like Unreal and Unity to create their interactive fictions. Night in the Woods is a good example of a choose your own adventure game built in a game engine, but there are plenty others: Life is Strange, Horizon Zero Dawn, The Walking Dead, etc. These kinds of engines are probably outside of the scope of a Plan project (I know next to nothing about 3D graphics, let alone graphics in general).
Some creative programmers out there have custom built game engines to be small, easy to learn, and capable of creating interactive fiction games. For example, Bitsy is a browser based game engine which takes full advantage of the concept of a bit, allowing creators to quickly put together low-bit creations, and is currently gaining a community of dedicated users.
Given the case studies above, I would like to try something unique that doesn't necessarily require reinventing the wheel.
I'd like to create a language which allows developers to use both parsing and choice-based interaction in their storygames. I haven't seen an example of a storygame which combines both parsing and choice-based interaction; I think it might be interesting from a player's standpoint to be given different options depending on the scenario, and from the programmer's perspective, the most difficult part would be writing a parser mechanism.
The multiple choice mechanism should be much simpler to make... I think it makes sense for these two input modes to exist in the same game, but probably not at the same time. So, there'd have to be some switching back and forth, but totally doable.
I like the idea of having an Game Object class built in to the language so that there is an easy way to create characters, rooms, and items (these could all be subclasses to the Game Object class). "Rooms" here being any particular setting in space or time; I think the concept of a "map" in an adventure game can still apply well to pages in a book, or moments in time, as they can all be abstracted to connected nodes.
I also think that the language should have some sort of data markup language which it takes as input. This could be as simple as building on existing XML, but I think it might be useful to have something that's easy to work with for writers.
For now, I would like to keep the capabilites to text only, with the possibility of adding sound/images in the future.
As far as the language itself goes, I don't think I'd like the code to fully resemble natural language in the way that Inform does, but I would like to make the syntax as readable as possible without getting too verbose. I think following literate programming practices would be useful.
Finally, I think designing with the intent to integrate with the web would be good; Many of the case studies allow developers to export their file to a single HTML page, which can then be easily hosted somewhere without too much knowledge of web design. Having that kind of powerful capability would be a huge selling point for those less technically inclined.