TIFT - A tool for pseudo parser games for touch screen devices

Technical Development Development Systems
1

If anyone is interested, I’ve been working on a IF development system for creating parser style games that work well on touch screen devices, specifically small screen devices such as phones.

Project is here: https://github.com/tomjefferys/tift, you can also view the (not quite complete) documentation.

Features:

  • Runs in a browser
  • Designed to function ergonomically on phones in portrait orientation.
  • Buttons for selecting individual words, but also allows limited typing.
  • YAML based syntax for authoring games.
  • Multilevel undo/redo
  • Dark/Light colour schemes
  • Written in Typescript and React

As a demonstration, I’ve ported Cloak of Darkness to the system.
https://github.com/tomjefferys/CloakOfDarkness (Playable here)

I’m currently working on a longer game to prove this is a practical system.

Would be interested in anyone’s thoughts/feedback!

9 Likes
2

The tap-to-play parser here is well thought out - nice work. It’s reminiscent of the old CellarDoor Z-code interpreter for PalmOS, with its stylus-friendly shortcuts, mixed with some of the more grammatically-complicated graphical adventures from the 1990s.

The problem of how to merge the discovery and lateral thinking possible in parser games with the accessibility of hyperlinks is a noble one, and remains incompletely solved. In my opinion, the type of approach used here (tap-to-build-a-sentence, with relevant verbs and nouns appearing only when grammatically applicable) is one of the better lines of attack. However, most previous attempts I have seen still suffer from encouraging the player to “lawnmower” through every available combination of verb and noun, playing by exhaustion rather than by intent. This system felt better than some, mainly because many of the available actions were buried several layers deep.

One way through this might be to implement a relatively large set of verbs - more than can be lawnmowered through - but only show a physically-coherent subset of them at any given point in time, filtered by the selected objects. (E.g. “burn” might only appear for flame sources, but “throw” for anything portable.) This is similar to the approach TIFT follows, just with more verbs. But this risks the opposite problem, picking-from-lists-fatigue.

In this general vein, one idea you might borrow from CellarDoor is having nouns be tappable as hyperlinks within the game text itself, as if the whole game world were the Inventory tab. Currently interactions with the inventory are noun-first, while interactions with the game world are verb-first; this could probably be standardized so both are noun-first.

Another question: does this need to be a fully custom development system at all? Could it be implemented as essentially a fancy web interpreter for (e.g.) Glulx games written in Inform, with some special extensions to allow the author to better control the web UI?

1 Like
3

@prevtenet thank you for your thoughtful reply.

It’s reminiscent of the old CellarDoor Z-code interpreter for PalmOS, with its stylus-friendly shortcuts

I was not aware of CellarDoor, I’ll take a look at that.

The problem of how to merge the discovery and lateral thinking possible in parser games with the accessibility of hyperlinks is a noble one, and remains incompletely solved.

Agree this is tricky. I’m working on a longer game, which will hopefully have some interesting puzzles, but will have to wait and see if I can pull it off. Maybe I’m doomed to failure! :rofl:

I don’t think “lawnmowering” can be completely avoided, but I think the game state can be made complicated enough that it is impractical. (Ie items can be used in different ways, in different locations, at different times. You soon end up with a lot of combinations).

In this general vein, one idea you might borrow from CellarDoor is having nouns be tappable as hyperlinks within the game text itself, as if the whole game world were the Inventory tab

I thought about this, but one of my design aims for this system was to allow games to be played one handed on portrait orientated devices. Having to reach into the text higher up is uncomfortable.

However maybe the solution here is a separate “game world” nouns tab, it’s something to think about, thanks!

Ultimately my intention was that TIFT games will be slightly more “casual” than a pure parser style game, but also more accessible (no guess-the-verb type problems, comfortable to play on phones etc), trying to find a sweet spot between parser, and choice based games.

Another question: does this need to be a fully custom development system at all?

I also toyed with this. Maybe it would have been a more sensible direction to go it, but it had some issues, such as how to you present the almost limitless options that parser games allow, on a small touchscreen device. (And if I’m completely honest, part of me just wanted to have a go at writing my own system from scratch).

2 Likes
4

Very nice. I spent a minute or two with your CoD on my desktop PC and Firefox.

The interface looks very clean and approachable. I think you could achieve a great deal with this framework.

YAML is a sensible choice for the structure of the passages. Do you plan to use other features, eg: anchors, aliases, tags? I think some authors might expect some tooling for visualization, syntax checking, etc.

Good luck with your exemplar project! I’m working on something similar for my own (Python) framework. It’s taking waaay longer than I expected :rofl: .

1 Like
5

Congratulations on your TIFT system! I read the docs and It looks really quite comprehensive. I also think the IF world needs more mobile-ready systems.

Some feedback;

Someone already mentioned considering clickable words in the text. This would help to save space and add convenience. Even if clicking only ever performed “examine thing”, this could be useful.

I don’t know how possible this is in your implementation, but it might help later to have item inheritance. As things scale up, it will help to have a set of useful parent types that are not part of the core runtime. These parent types can have bodies of behavior that essentially work as refactored patterns. Of course any given object could override parent where necessary.

NPCs will need dialogue and this means having some sort of choice menu. How this will bode with the “pseudo parser” I’m not sure. Obviously, ask and tell could be accommodated in the existing layout, but if you want more, there will need to be interactive dialogue somehow.

If there are a lot of things at the bottom, then it will either need to scroll or the main text area will shrink. If you scroll, then some options will not be initially visible and this might mean the player doesn’t know they are available. If you shrink the text area, you will increasingly run into a text pagination problem, where you may wish to avoid unread text from scrolling off the top.

The text scrolling off the top is an increased problem for mobiles. Every mobile has a different amount of space. Some people will want to increase the font size and many passages of text - especially at crucial story beats tend to be quite long.

Finally, i would like to suggest, at least thinking about, adding support for pictures at some stage. I think a mobile IF system ought to support graphics (and sound) especially if it is considered a parser alternative.

Best of luck.

2 Likes
6

This is very cool! I successfully played through the game on my phone. Just two things—you mentioned typing being a possibility, but I couldn’t figure out how to initiate typing (maybe it isn’t enabled in this game?). And I’d suggest upping the contrast for the “about” text in dark mode:

IMG_7312
IMG_7312640×1136 88.3 KB

Oh, and I echo the clickable nouns idea!

For me, the convenience of being able to click on nouns in the text would outweigh the inconvenience of reaching.

3 Likes
7

Do you plan to use other features, eg: anchors, aliases, tags?

I’m using an off the shelf YAML parser, so these should already be supported, although I’ve not tested using them, or given much thought to how they could be exploited.

I think some authors might expect some tooling for visualization, syntax checking, etc.

On my todo list. There is some error checking when the game is first loaded, but I would like to ultimately provide for a better author experience, ie maybe a custom editor etc. Probably quite a lot of work though, so my priority for now is to get a longer example game working.

Thanks for the feedback!

8

Thanks, part of my motivation for this, was that I want to play these sorts of games on my phone, and I wasn’t satisfied with any of the existing solutions.

On my todo list, should be straight forward to add javascript style prototypical inheritance at least.

At least initially, I was going to go with ask and tell style. This can already be supported with the current engine. Definitely something to think about some more though.

This is definitely a challenge, ideally there would be no scrolling. This problem was partly what led to the separate inventory tab, I was ending up with far too many verbs on the main game tab. I’m leaning towards more tabs as way of solving this, as I think it’s more discoverable. I’m not entirely sure how this will work though.

So, it is scrollable, so you can always go back and see what you missed. The problem is for large dumps of text. I’ve experimented with displaying it section by section, with a continue/more button. This is something I’ll need to revisit.

Also on my todo list. :grinning:

Thanks @jkj_yuio for all he feedback!

1 Like
9

Thanks for testing it :grinning:
Typing needs a keyboard, you can’t initiate it directly on mobile. If you play from a browser on a desktop/laptop you can type. Typing is a bit of a second class citizen though, and functions as a way to easily choose the words, it doesn’t open up any other options.

Yeah, I need to revisit that info display, it’s mainly to show debugging info, and it needs to be differentiable from the main game text. I’ll definitely look at upping the contrast.

1 Like
10

Thanks everyone for all your suggestions. Given me lots to think about.

Looks like you’re all fans of clickable in-text nouns :laughing: , I’ll definitely give that some consideration.

For now my next step is to get a more solid demo game together. I’ll let you know how it goes.

3 Likes
11

I am for this approach

3 Likes
12

This is exactly why I’m designing my interface in a similar way for IF-Octane. A fear of lawnmower methods only holds up if you’ve made a parser puzzle game. If hunting for the right command is not part of the gameplay, then this doesn’t matter, and it’s far more important for the UI to stay out of the way.

3 Likes
13

This is a good point, but I think only part of the picture. Lawnmowering is also a problem for dialogue, naturally (probably the problem for dialogue, as much for parser systems as for choice systems). But there’s a broader problem here that hasn’t been fully solved: how to capture the immersive, tactile feeling of being able to interact with the game world as if it were real, performing actions you think of yourself rather than simply clicking through a list of options provided by the author. This isn’t a feeling restricted to puzzle games, although puzzle games certainly make use of it as a core mechanic.

This feeling is an illusion, of course. A great deal of IF theory has gone into making the illusion as convincing as possible, but ultimately the author has to have thought of and implemented whatever responses you provoke. (Often, finding all the juicy the-author-thought-of-everything responses is half the fun: it’s a momentary telepathic connection, as if they player and author were winking at each others’ cleverness through the ether. “See what I did there, eh? We had the same idea.”) Not all parser IF aims for this kind of immersion, but parser IF does it better than any other medium.

But parsers also suck. Like Unix command-lines, it’s an amazing world once you get sucked in, but no amount of grammatical sophistication is going to convince the average person to type a lot of tiny text commands into their phone. So, we still need to figure out how to capture the immersive freedom of the parser in a format people are actually willing to use.

Of course, you can avoid the whole problem by just writing games that don’t prioritize immersive freedom. But if you do want to write an immersively free game without a parser, there aren’t currently many good options.

1 Like
14

If dialogue is a major part of your game design, sure. However, this quirk seems to be embraced as an intentional feature of choice-based games and visual novels, so this seems to be very subjective.

However, since my planned games won’t have much dialogue, this is a non-issue.

This is only valuable if you are strictly looking to stay within the box of a parser puzzler adventure. In games where mechanics become deeply advanced, beyond standard lateral puzzle solving, this kind of interaction can quickly become burdensome, both for the player and for the design of mechanics.

Again, this does not fit the designs I have in mind for my projects, so it’s a non-issue, and I do well without.

Exactly.

15

I disagree; I value this type of immersion even in strictly story-driven games. The illusion of freedom given by the parser helps me feel like I am inhabiting my character to a degree I don’t feel in a choice-based interface, and I know I’m not alone in this.

As you say, this is less relevant to your own projects. But there’s a different group of people for whom “don’t do that, then” isn’t the solution they’re looking for.

2 Likes