The Archivist

[chysn]

This is cruel

What do you mean?

[orion70]

Save file will no longer work...

[chysn]

Save file will no longer work...

Other than the data structure changes, the only real difference between the current version and the last is that going east from the Office no longer ends the game. If you can stop yourself from doing that, you might prefer to use the older version for the save file.

[thegg]

I've never got on very well with text adventures in the past, but I thought I would give this one a try. I was getting into and enjoying the game when I hit a problem.

I was on the prompt line and accidently hit backspace before starting to type my command. The backspace had moved the cursor to the previous text line so my command wrapped to the prompt line. When I hit return the cursor disappeared and the command did not execute. Hitting return again revealed the cursor in the middle of the game text and the user interface was broken.

[chysn]

I've never got on very well with text adventures in the past, but I thought I would give this one a try. I was getting into and enjoying the game when I hit a problem.

I was on the prompt line and accidently hit backspace before starting to type my command. The backspace had moved the cursor to the previous text line so my command wrapped to the prompt line. When I hit return the cursor disappeared and the command did not execute. Hitting return again revealed the cursor in the middle of the game text and the user interface was broken.

You can clear that condition with SHIFT/HOME.

Update: I did find the fix for this, which will be implemented in future games. Thanks for bringing it to my attention!

[JavaJack]

What's the authoring environment like for this system?

[chysn]

What's the authoring environment like for this system?

Each story (game) involves two assembly files. One is the VICfiction.asm file, which is the game engine. This file is designed to remain consistent from story to story. The other file is the story file, which contains the data necessary to describe rooms, verbs, items, timers, and actions.

An example of a VICfiction story file, for the short Marooned story, is here: https://github.com/Chysn/VICfiction/blo ... .story.asm

The VICfiction file is here: https://github.com/Chysn/VICfiction/blo ... iction.asm

I use the XA cross-assembler, so the entire executable is generated on the command line by specifying both the VICfiction and story file:

Code: Select all

xa -O PETSCII -M -o story_name.bin ./src/VICfiction.asm ./src/StoryName.story.asm

The .bin file is then transferred to an EEPROM for installation to a cartridge or loaded from the file directly to VIC or emulator.

The construction of a story file, and especially the design of puzzles, would be a pretty huge topic. It's documented pretty well in the Marooned story file, and I plan to document puzzle "recipes" at some point. But here are some of the salient features:

* Items are stateless. Apparent states are achieved by swapping items onto the map based on "actions"
* Actions are either executed by the player with verbs, or are triggered by various events.
* Timers can either be started or stopped by actions, or as a result of entering a room.
* Each action results in either success or failure. Actions can trigger other actions.
* Actions have various types of conditions based on inventory, or items in a room, or items NOT in inventory, or which room the player is in.
* Actions have various effects, like moving the player, moving inventory, triggering timers, ending the game.
* Items have various properties, like whether they can be moved, seen, acted upon. Items can follow a player (for example a character following you around, or an injury or illness). Items can also act as light sources for darkened rooms.

The design space for puzzles is pretty comprehensive based on a fairly small number of properties and interactions between them. Due to the item movement results and two-way behavior of timers*, interactions can be multi-layered. I'm particularly proud of the Thomas Jefferson interaction in The Archivist, whose solution weaves much of the game together.

* "Two-way" here meaning that actions can start timers and timers can trigger actions.

[JavaJack]

* Actions have various types of conditions based on inventory, or items in a room, or items NOT in inventory, or which room the player is in.
* Actions have various effects, like moving the player, moving inventory, triggering timers, ending the game.

I spent so many hours trying to think up a low-end noun-verb authoring system that was based around a spreadsheet or grid with nouns on rows and verbs on columns, but it always fell apart because there was no good way express conditionals in an overly-simplistic system like this.

[chysn]

* Actions have various types of conditions based on inventory, or items in a room, or items NOT in inventory, or which room the player is in.
* Actions have various effects, like moving the player, moving inventory, triggering timers, ending the game.

I spent so many hours trying to think up a low-end noun-verb authoring system that was based around a spreadsheet or grid with nouns on rows and verbs on columns, but it always fell apart because there was no good way express conditionals in an overly-simplistic system like this.

I think the problem with the grid model is that you have only one cell on the intersection, which implies a single result when the noun/verb combination is entered. At the very least, you need a multi-dimensional grid where the cell is a reference to another grid.

One result per combination is restrictive. With VICfiction, the same noun/verb combination can be in the database any number of times, with the results cascading from one instance to the next. Results are short-circuited on any failure, so the order does matter. It's also possible for a "no result" so that a cascade can continue if the combination doesn't apply for some reason (e.g., you're in the wrong room).