Making interactive fiction

0 users browsing Discussion. | 1 guest | 43 bots

Main » Discussion » Making interactive fiction

Pages: 1 2 Next Last

Screwtape

Posted on 19-10-22, 12:35

Full mod

Post: #356 of 443
Since: 10-30-18

Last post: 1101 days
Last view: 172 days

I think just about every thread on this board is complaining about *some* kind of technology, but what the heck, let's add another to the pile.

Recently I got a hankerin' to write a bunch of room descriptions, and so I thought I'd play with some interactive fiction (i.e. text-adventure) tools. My first thought was good ol' Inform for the classic STAB TROLL WITH SWORD adventuring, but Inform 7 is still in rewrite-limbo and Inform 6 is kind of intimidating. Since I didn't want to faff about too much with Tech just to write a few paragraphs, I decided to go with the darling of the "everyone can make games" movement, Twine.

I started by downloading the Official Twine App and poking around, but it turns out to just be the website packaged in Electron, which is cool, but not *quite* my preferred environment. Also, the format used for storing games on-disk appears to be the same as the published format, minified embedded JS and all, which isn't great for source-control. Luckily I found a thing called Tweego, which is a command-line tool that takes plain-text source in a reasonable format, combines it with the Twine engine and a stylesheet to produce a distributable HTML file. The source file format has an actual specification, although Tweego is the only tool I've found that reads or writes it — Twine certainly doesn't.

But this is a rant thread, so of course I'm still not quite happy.

Twine has a strange idea of story formats, which appear to control everything above the level of "a game is a collection of passages". That is, how markup is parsed, what effects you can do, how scripting works, what graphical effects are available and the user-interface presented to the player. The docs suggest that the "Harlowe" format is designed to be easy to get started with, so that's what I picked. Unfortunately, it's kind of infuriating for a bunch of reasons.

- The markup syntax is almost like Markdown, but not identical.

- It seems to be based on the formatting model half-assed forum software uses, that just translates newlines to <br> tags instead of making actual paragraphs. That means I can't hard-wrap my source file to a convenient width, and it means any markup/scripting I use has to be contorted to use minimal whitespace, lest a newline get through and screw up the spacing of the resulting HTML.

- It also seems to be based on the easiest possible scripting model, where script instructions in the markup cause JS code to execute when each passage is displayed, and so things like "what variables exist" and "how are they updated" get scattered across the game in the most spaghetti-code style imaginable. It's fundamentally designed to mix logic and presentation in the most annoying way.

A while ago I played with writing a web app in Elm, and it was almost the exact opposite, with a beautiful separation of logic and presentation. Unfortunately, Elm doesn't provide Markdown or any other lightweight prose-friendly markup, and it definitely doesn't automatically provide the kind of user-interface affordances people expect a game to have, like undo, redo, saving and loading.

It seems to me like there's a niche for an interactive-fiction tool that's easy to get started with *and* easy to extend, but maybe I'm failing to take Worse Is Better fully into account, and Twine really is the optimal solution.

The ending of the words is ALMSIVI.

Kawaoneechan	Posted on 19-10-22, 13:12 Hi.
YEEEEAAAAH~! Post: #428 of 599 Since: 10-29-18 Last post: 195 days Last view: 4 hours	I prefer Inform 7 myself, really. I believe Trizbort can be used to map out the foundations.

wertigon

Posted on 19-10-23, 11:51

Post: #100 of 205
Since: 11-24-18

Last post: 155 days
Last view: 27 days

Oooh, interactive fiction.

Been toying with the idea about making my own IF web engine that accepts plain old HTML files, image files and CSS, with some way to pick up "locks and keys" with JavaScript, cookies and some minor PHP engine that writes a game session to a file.

That way, if you want a Zork style adventure, you can have it... But the main idea would be something like a point-and-click game like Curse of Monkey Island, with dialogue labyrinths and other cool stuff.

Would be interesting to see how far you could take it with a stateless IF machine.

Screwtape

Posted on 19-10-24, 10:00

Full mod

Post: #357 of 443
Since: 10-30-18

Last post: 1101 days
Last view: 172 days

I hope you mean picking up keys to be used in locks, not picking up the locks themselves - that would make authoring puzzles quite difficult. :P

(I think a version of Zork had a bug where you could take compass directions and put them in your inventory - in order to allow the player to GO NORTH there had to be a thing called "NORTH" in each room, and if it didn't have the "immovable object" flag set you could take it with you and cause havoc.)

Something that requires a PHP backend might make it easier to for people to run on older, simpler devices without JS, but I feel like these days there's a lot more people without reliable network connectivity than without JS support, and I really like the idea of sticking a static HTML site on a webserver that people can save and run offline, or even make it a progressive web app so people can install it on their phones without me having to package it separately for each OS and device.

> I prefer Inform 7 myself, really.

I did play with Inform 7 back when it was still getting regular updates, and it was quite fun, but right now there's only pre-built binaries for the command-line tools, and the Linux GUI is old enough it doesn't install on my system.

The ending of the words is ALMSIVI.

Duck Penis

Posted on 19-10-24, 18:26

Stirrer of Shit
Post: #655 of 717
Since: 01-26-19

Last post: 1763 days
Last view: 1761 days

If you're making a compiler, why not support both? If you're intending to support cookies, you'll need to serialize the state anyway. Then all you need to do is to settle on a standard format for it, and Bob's your uncle. And those who don't want it just omit the .php file.

What do you need the JS for anyway? If you're making a point-and-click game, I think good ol' CSS can do anything. Failing that, there's always image maps.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

CaptainJistuce	Posted on 19-10-25, 05:29 Hi.
Custom title here Post: #745 of 1164 Since: 10-30-18 Last post: 63 days Last view: 9 hours	What's wrong with using BASIC? 'S all just PRINTs and GOTOs. --- In UTF-16, where available. ---

wertigon

Posted on 19-10-25, 09:58 (revision 1)

Post: #101 of 205
Since: 11-24-18

Last post: 155 days
Last view: 27 days

Posted by Screwtape
Something that requires a PHP backend might make it easier to for people to run on older, simpler devices without JS, but I feel like these days there's a lot more people without reliable network connectivity than without JS support, and I really like the idea of sticking a static HTML site on a webserver that people can save and run offline, or even make it a progressive web app so people can install it on their phones without me having to package it separately for each OS and device.

Yeah, that was the basic idea - a plain old HTML site. JavaScript would be required for variable holding with inventory, and either a multi-page-in-single-doc layout or cookies for moving around with said inventory (basically, just a 64-bit or 128-bit number with flags and keys). Good for PWAs as well.

Posted by sureanem
What do you need the JS for anyway? If you're making a point-and-click game, I think good ol' CSS can do anything. Failing that, there's always image maps.

Like I said - HTML and CSS can do a lot of things, but you cannot implement a key-and-locks system in them (if use key on door show open_door.png; else show closed_door.png), since you need some sort of variable storage. If you can I dare you to do a CSSZenGarden design for it. ;) A lock does not have to need a key, either, you could simply alter something in the environment (like flooding a chamber to raise a floating platform). The "key" then becomes the button that activates this chamber.

However, it is possible to make the JS completely transparent so you only author CSS and HTML using certain key classes. It would be a bit limited for sure, but doable, and the JS would be simple checks. Like I said, aiming for a more Myst / CoMI experience than Zork.

CaptainJistuce

Posted on 19-10-25, 10:05

Custom title here

Post: #746 of 1164
Since: 10-30-18

Last post: 63 days
Last view: 9 hours

Posted by Screwtape
I hope you mean picking up keys to be used in locks, not picking up the locks themselves - that would make authoring puzzles quite difficult. :P

(I think a version of Zork had a bug where you could take compass directions and put them in your inventory - in order to allow the player to GO NORTH there had to be a thing called "NORTH" in each room, and if it didn't have the "immovable object" flag set you could take it with you and cause havoc.)

That's hilarious.

>TAKE SCREWTAPE

--- In UTF-16, where available. ---

Screwtape

Posted on 19-10-25, 14:13 (revision 1)

Full mod

Post: #358 of 443
Since: 10-30-18

Last post: 1101 days
Last view: 172 days

Posted by wertigon
Yeah, that was the basic idea - a plain old HTML site. JavaScript would be required for variable holding with inventory, and either a multi-page-in-single-doc layout or cookies for moving around with said inventory (basically, just a 64-bit or 128-bit number with flags and keys). Good for PWAs as well.

Back in the day when iPods were a thing — I mean the iPods with the spinny wheel on the front, not the iPod Touch that was just an iPhone without a SIM card, or the iPod Nano that was just a USB stick with a headphone jack and a play button — it had a "Notes" feature, where you could stick a bunch of text-files in a directory and they'd show up in the "Notes" folder so you could browse them while you were out and about. And in fact, they supported a limited amount of HTML markup - basically just hyperlinks.

I started writing an app that would take a config file of rooms and exits, and write out all the notes required to represent that as a text adventure. For example, here's an excerpt from one of my test files:


[foreshoreChamber]
title=Foreshore Chamber
description=The sound of the sea grows dim as you climb down a short flight of 
 stairs, and you enter a small chamber. Although it’s too regular to be
 anything but man-made, the chamber is in no way crude: the floor is smooth
 and carpeted, the roof (although low) is gently dome-shaped, and six
 generous alcoves line the walls, empty but for dim yellowish lights whose
 glow somehow complements the cool, quiet solitude of this place. In the
 centre of the room sits a squat black cauldron that appears to be bubbling
 away merrily - except that you can see no flames, feel no heat, and hear no
 noise. 
exits=fromChamberToPassage

(for the heck of it, I put up the full output of this unfinished, half-assed project)

Although I never quite got that far, my intention was to let the author define a bunch of binary flags, and declare that particular passages set or cleared them. For example, a passage named "takeKey" might set the "hasKey" flag. A passage could have different content depending on what flags were set, and the compiler would generate a copy of each passage for every possible combination of flags, and make sure each copy linked to the correct places.

For example, let's say you have 16 passages, so we can number them in hexadecimal 0-F. Let's also say we can have four binary flags, so every possible state of every possible room can be represented by a number 00-FF. If you're in the Key Room (passage C) and the hasKey flag is not set, you're looking at 0C.html. The "take key" link in that room points at a version of the room where hasKey is true, perhaps 1C.html, and all the links in that version of the Key Room need to keep the hasKey bit set (unless one of them is "drop key").

The big problem with such a scheme is the combinatorial explosion of versions of a room. Even a basic hallway that never changes its description needs to have a bunch of different versions so that the player can pass through without the game forgetting any state. I had some ideas to limit the explosion by having the compiler only generate pages that were actually *reachable*, but I lost interest before I actually tried anything out.

The ending of the words is ALMSIVI.

creaothceann

Posted on 19-10-25, 14:37

Post: #208 of 456
Since: 10-29-18

Last post: 44 days
Last view: 1 day

Posted by CaptainJistuce

Posted by Screwtape
I hope you mean picking up keys to be used in locks, not picking up the locks themselves - that would make authoring puzzles quite difficult. :P

(I think a version of Zork had a bug where you could take compass directions and put them in your inventory - in order to allow the player to GO NORTH there had to be a thing called "NORTH" in each room, and if it didn't have the "immovable object" flag set you could take it with you and cause havoc.)

That's hilarious.

>TAKE SCREWTAPE

relevant

My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Duck Penis

Posted on 19-10-26, 03:04

Stirrer of Shit
Post: #657 of 717
Since: 01-26-19

Last post: 1763 days
Last view: 1761 days

Posted by wertigon

Posted by sureanem
What do you need the JS for anyway? If you're making a point-and-click game, I think good ol' CSS can do anything. Failing that, there's always image maps.

Like I said - HTML and CSS can do a lot of things, but you cannot implement a key-and-locks system in them (if use key on door show open_door.png; else show closed_door.png), since you need some sort of variable storage. If you can I dare you to do a CSSZenGarden design for it. ;) A lock does not have to need a key, either, you could simply alter something in the environment (like flooding a chamber to raise a floating platform). The "key" then becomes the button that activates this chamber.

However, it is possible to make the JS completely transparent so you only author CSS and HTML using certain key classes. It would be a bit limited for sure, but doable, and the JS would be simple checks. Like I said, aiming for a more Myst / CoMI experience than Zork.

Well, that's where the PHP comes in. Click the key, the key gets attached to the cursor (or just marked with an asterisk as "held"), click the door, door opens.
(You could maybe also do it with pure CSS using hidden checkboxes, which is genuinely useful for implementing non-JS spoiler tags, but it's definitely overkill for this application)

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.

Kawaoneechan

Posted on 19-10-26, 11:30

Better with Chocolate

Post: #429 of 599
Since: 10-29-18

Last post: 195 days
Last view: 4 hours

Posted by wertigon
Like I said - HTML and CSS can do a lot of things, but you cannot implement a key-and-locks system in them

Posted by strfry
Well, that's where the PHP comes in

The main issue, I think, is that something has to handle the actual game logic. It's the logic that makes the game, after all. Just HTML and CSS can't implement that¹, you'll need some form of scripting. Be it client-side (JS) or server-side (PHP et al), you'll no longer have just HTML and CSS.

By saying that's where the PHP comes in, you only hurt your own argument.

CaptainJistuce

Posted on 19-10-26, 11:45

Custom title here

Post: #748 of 1164
Since: 10-30-18

Last post: 63 days
Last view: 9 hours

Posted by Kawa

Posted by wertigon
Like I said - HTML and CSS can do a lot of things, but you cannot implement a key-and-locks system in them

Posted by strfry
Well, that's where the PHP comes in

The main issue, I think, is that something has to handle the actual game logic. It's the logic that makes the game, after all. Just HTML and CSS can't implement that¹, you'll need some form of scripting. Be it client-side (JS) or server-side (PHP et al), you'll no longer have just HTML and CSS.

By saying that's where the PHP comes in, you only hurt your own argument.

You could use HTML5.
...
Or something sane.

--- In UTF-16, where available. ---

Kawaoneechan	Posted on 19-10-26, 12:00 Hi.
Natural Selection's gift to womankind Post: #430 of 599 Since: 10-29-18 Last post: 195 days Last view: 4 hours	Does HTML5 have its own logic allowing lock-and-key mechanics and state? Don't answer that or we'll never get back to actual interactive fiction solutions that have actual practical implementations.

CaptainJistuce

Posted on 19-10-26, 12:26

Custom title here

Post: #749 of 1164
Since: 10-30-18

Last post: 63 days
Last view: 9 hours

Posted by Kawa
Does HTML5 have its own logic allowing lock-and-key mechanics and state?

Don't answer that or we'll never get back to actual interactive fiction solutions that have actual practical implementations.

I thought it did. If it doesn't, it will soon because "living standard". God forbid they ever have to change the number or define an actual standard.

I still say BASIC is nice for this.

--- In UTF-16, where available. ---

Kawaoneechan	Posted on 19-10-26, 12:48 Hi.
Better with Chocolate Post: #431 of 599 Since: 10-29-18 Last post: 195 days Last view: 4 hours	For interactive fiction? Certainly you can at least get a reasonable Cloak of Darkness rendition in BASIC. I'll bet there already is.

CaptainJistuce	Posted on 19-10-26, 13:08 Hi.
Custom title here Post: #750 of 1164 Since: 10-30-18 Last post: 63 days Last view: 9 hours	I saw a functional 10-line text adventure the other night. It was a simple game, and the code was as illegible as BASIC gets, but... --- In UTF-16, where available. ---

Kawaoneechan	Posted on 19-10-26, 13:42 Hi.
Ties the room together Post: #432 of 599 Since: 10-29-18 Last post: 195 days Last view: 4 hours	Hardly author-friendly though. Nor user-friendly in this day and age.

funkyass	Posted on 19-10-26, 17:17 Hi.
Post: #102 of 202 Since: 11-01-18 Last post: 660 days Last view: 15 days	HTML5 gives you custom attributes and tags. You'd still need javascript to handle the logic if you want something more complex than a choose your own adventure.

Screwtape

Posted on 19-10-29, 00:41

Full mod

Post: #361 of 443
Since: 10-30-18

Last post: 1101 days
Last view: 172 days

So, after wishing for a choice-based IF engine with Markdown syntax, today I stumbled across Ficdown, which is exactly that. Write some Markdown, put special URL-like syntax into link targets to set or test flags, and off you go.

Now I actually see the thing in action, though, I'm not as big a fan as I expected - in particular, it seems strange that one can only ever *set* flags, not *clear* them. Also, trying to fit a bespoke query syntax into a URL-like syntax, alongside actual links, seems a bit intricate. I'd rather have some new, separate syntax for annotating flag-requirements on text-blocks.

The ending of the words is ALMSIVI.

Pages: 1 2 Next Last

Main » Discussion » Making interactive fiction

bboard