…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.

Click here for the Ripple concept demo

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!

My entry to the fair is Vorple, an interface layer to be integrated with existing web interpreters and an accompanying UI library. It would work together with Parchment, Quixe, Undum, or some other web interpreter or system that would provide the engine running the actual game.

Vorple has two main features: giving games access to JavaScript and Vorple's library, and providing ready-made functions and features that could be easily added to games. For example, an Inform 7 author could do something like this:

To players it would be just like any other web interpreter, but for authors Vorple would provide means to break free from the virtual machine into what is admittedly another sandbox, but one with a lot more possibilities. Authors who want total control could insert JavaScript commands that control the user interface or add whatever JavaScript/HTML elements they wish. People who don't want to mess around with JavaScript could use the ready-made elements and functions like shown above.

The players would benefit of an independent UI layer even if the game author wouldn't use any of Vorple's features. You could use independent JavaScript widgets like notepad or (auto)mapping that would work with every game.

An interesting side effect would be that if Vorple were made to work together with Parchment and Quixe it could act as a general-purpose interpreter like Gargoyle or Zoom, making the difference between Z-machine and Glulx even more invisible to the player.

The features demonstrated at PAX will be:

• Keeping the transcript clean: hiding error messages and UI hints the next turn, showing meta information (about, credits) in popups
• Changing the content of previous turns. In the demo you can change temperature and speed units between metric and imperial. Doing so will change the previously displayed units as well.
• Bubble popup hints, as seen in the screenshot
• Linking to Twitter
• Sending commands to the parser from the user interface, either as normal commands, silently, or as partial commands (for example clicking on the word "examine" fills the input line with that word and lets the player to add the noun)
• Images in different layouts and popups
• Playing videos (local videos for now because internet access at the demo event might be difficult to come by, but YouTube videos would work just as well)
• Accessing and displaying the system time (although it's not that amazing anymore now that Glulx supports this)
• An interactive version of the How to play IF card!
• + more

This is just a taste of what the library will include. The best part of course is that because the user interface and the game could communicate between each other the author would be free to come up with all sorts of interesting new interfaces and game mechanics outside the standard set of features. For example I had an idea of a time travel game where travelling into the past would actually change the content of previous turns that happened in the future—this would be impossible in any of the current interpreters, but perfectly doable with Vorple.

As said Vorple will be presented at the demo fair at PAX East in Boston this Saturday starting at 8 pm. If you're around come take a look; you won't need a PAX badge. The demo will be posted online later, but I'm travelling during March so it might take a couple of weeks.

Vorple won't be out for some while as it's currently just a bunch of stuff thrown together to demonstrate the basic concept. In the meanwhile you can follow @VorpleIF on Twitter for release announcements and updates on the progress.

If you're interested in helping or seeing how it looks like right now you can head to the alpha testing information page and take a look. The project schedule has been pushed forward about a month and I'm hoping to release something in time for PAX Prime at the beginning of September.

We're aiming to release at the beginning of September, in time for PAX Prime and before IFcomp starts to avoid being overshadowed.

For my part the project progresses roughly according to following plan:

1. Sketching the general theme, plot structure and characters.
2. Writing more accurate character bios, rough but complete plot from start to finish and details of the fictional world where the game takes place.
3. Plot map, similar to the puzzle map used in Escapade! (although the game is essentially linear so it's just an overview of puzzles and plot events.)
4. Mock transcript of a complete playthrough of the game. When we start coding we'll use the mock transcript as a model with which to craft the game.
5. Alpha testing where other people read through the mock transcript and other design documents and offer their opinions. The purpose is to find large-scale problems at this point (changes to plot or puzzles, map structure, character voices) that can be fixed before they are coded. When a project reaches beta-testing stage it's usually too late to do anything other than relatively minor changes to the game structure.
6. Coding the game. Unlike previously announced, this will be done in Inform 7 for two reasons: the main reason is that you can't play TADS games online yet, which is a major factor if you want the barrier to entry to be as low as possible. The other reason is that I'm more familiar with I7 so I don't have to spend the relatively short implementation time learning the system. I'll set up a project at Google Code where anyone can follow how the coding progresses and contribute to the issue tracker.
7. Beta testing. This is the phase where bugs, typos and minor design problems are ironed out.
8. Release at the beginning of September if everything goes as planned.

Right now I've just started with #4. The schedule is such that approximately 1/3 of the time is used for preparations, 1/3 for coding and the rest 1/3 for testing. This seems like a reasonable divide, especially if the thorough planning speeds up the coding phase.

If you have any ideas regarding the project you can leave your comments here, on the wiki, or by e-mail (juhana.if @ this blog's address.) We'll be needing people during alpha and beta testing so keep that in mind if you have extra time later this month and during August.

TADS's learning curve is very steep at the beginning but I have a feeling that once you get a decent grasp of the language you can do advanced stuff quite easily. With Inform 7 the learning curve is almost the opposite: you can get in with no effort at all, but when you get to the advanced stuff you hit a brick wall.

This is the third time I've started trying to learn TADS. The first two times the library was just too overwhelming and I didn't get very far before just becoming tired. Now I've picked it up again and it's going better than before. While I've never had as much fun programming as I have when working with Inform, TADS is also fun but in a different way: the feeling of harnessing its raw power is what makes TADS a pleasure to work with.

Just to tame this beast I'm going to do my next project in TADS. An old acquaintance is about to return...

Apparently making speed-IFs isn't my forte because the end result was something more the size of an average IFcomp game than a speed-if. It's large enough to consider a proper game, so I'm having it tested before it's released to the general public. If you have some extra time in the next couple of weeks (the planned release is sometime in February), it would be great if you'd see the call and blurb here. I can be contacted by e-mail, juhana dot if at nitku dot net.