I am using the stock android keyboard. looking it up, it seems to have something to do with autocomplete (which I don’t use)
I lately play Parser games exclusively on my phone. That’s because I do it in “bite-sized” manner, and I usually have something work related on my main computer.
My parser IF experience was painful. I actually lamented the fact that I enjoyed the experience more on Palm PDA using stylus (Graffiti) than on my phone.
Regarding custom on screen keyboard or default, it’s a toss up. My preference is that of custom UI, but I’ve seen arguments that prefer OS keyboard. Didn’t they do that on new Infocom implementation? I think I remember the new HHGTTG uses custom design.
Maybe one of these days, I’d pair a BT keyboard to my phone, but until then … painful. If the game is good enough, I persevere, but it does lower my enjoyment quite a bit, so much that I refuse to play long games nowadays.
I can recommend getting a BT keyboard for your phone. I have one that folds up and i was amazed how much more useful work i can do on the phone with it.
Was going to say BT keyboard. I have one that folds down to not huge size when not used. And the cover folds to a holder for the phone. Combined with termux my phone does an ok job pretending it is a small Linux laptop, running almost all the software I am used to on my desktops and laptops.
I have used a Palm Tungsten and some HP ipaq 1945 for decades. Sometimes I take them, refresh their batteries and play some game. This is an awesome experience.
About BT keyboard, this is a good adquisition in order to play in a phone, tablet or ipad at home. Nevertheless I don’t use this keyboard when traveling.
Essential – absolutely essential. I very rarely (I might even say never) play games on my desktop computer; it’s always on my phone or tablet (an Amazon Fire HD10+).
So… yeah, essential – absolutely essential.
(And – hint, hint – it’s important for non-parser (e.g., Twine) games, too.
One theoretical way of dealing with the large keyboard on a small screen would be to embed the keyboard on the bottom so it scrolls with the page.
Nice idea, but it would have to be only with a custom game keyboard and not with the system keyboard.
I can think of at least one hack that an Android app could do to approximate this - show the keyboard when at the bottom and hide it when you scroll up.
Mobile-friendly is a must for me. I come from a MUD background and the biggest thing killing that genre is lack of decent mobile clients.
I’ve been experimenting with the concept of giving a parser feel through clickable UI. Some things I’ve played with:
-
nested button menus which shift. For example, I made a bottom bar and each room will display buttons for navigation, item interaction, etc. When you click on one of those, the buttons update to relevant commands.
-
combining commands. For example, instead of taste, turn, examine for an item, I use interact which opens a popup about the item. The skill system is built with passive abilities so the player’s skills determine what information and/or quests happen upon interaction.
-
clickable UI menus to handle things like changing a title or reading a book
-
contextual choices. Relevant options get added to the potential choices - for example, if a character has a special item and they find the right room to use it in, using it automatically is displayed as one of the game choices.
It’s been fun to experiment with melding the two genres - choice or click based makes certain aspects much easier, so I need to also think about ways to make the gameplay lean into that, such as adding complexity in other areas like social relationships.
Some MUD mobile clients - the layouts will probably be good inspiration:
- Blowtorch
- Iron Realms Entertainment Nexus app
- Written Realms
I’ve always wrestled with the allure of a parser game being an infinite world of possibilities. Usually, it’s a very limited experience, but sometimes there are gems of interactivity that make the whole experience greater than the sum of it’s parts. It’s fun to explore the boundaries of interaction. When I see clear choices, I lose that sense of anything is possible; the exploration feels diminished. I feel a bit like I’m ticking things off on a checklist. Parser games tend to scratch that exploration/adventure itch and choice-based tend to scratch the simulation/strategy itch.
What’s your favourite choice-based interface that promotes that parser exploration/adventure aspect best?
I don’t like choicescript games, I like parser based games.
This. In a game where the choices are clear and fully-realized, you should make it a choice-based game. In a game where you’re trying to explore the possibilities through mystery, discovery, and failure, parser is best.
Trying to implement one kind of game in another’s interface creates some really awkward situations for the player while trying to get through the game at all. The interface is part of the game design and not just a bridge to access the game.
I just started getting into MUDs, and was really surprised that I needed to install a mobile version of Arch Linux, and install TinTin++ on that, just to connect to ifMUD. None of the other clients run on my phone. (Although, I do most of my MUD stuff on a desktop, but the option to use a phone while I’m in a panic room is really nice…!)
Mobile clients are really scarce out there, lol.
I feel like a lot of IF’s history has existed before the invention of the smart phone, so the people deep in the scene see a smartphone as a secondary accessory, while a desktop computer is the main machine.
What’s your favorite choice-based interface that promotes that parser exploration/adventure aspect best?
I haven’t seen it done yet from a choice-based perspective, which is part of why I like experimenting with the idea and analyzing design. I’ve seen the reverse become very common in MUDs, though, with clickable MXP content for navigation, dialogue, skill use, etc. GMCP (APIs for the mud) also lets people bypass most of the typing through coding automated reactions to text. There is a lot of typing which doesn’t need to be typed, especially in complex MUDs.
In my experiments, I’ve been trying to capture a feeling of surprise when you choose something unexpected to try to replicate that feeling of exploration and discovery you get in parsers. For example, when giving your name, there’s a yes/no confirmation. If you say no too many times, the NPC just assigns you a silly nickname. The goal is to tuck something unexpected which creates story into what is typically a mechanical experience.
I don’t think the result is going to be the same as a parser game, but I think it won’t feel the same as a typical choice-based game either. I’m just curious to see what kind of hybrid I can build.
I’ve been playing with a few engines, such as QuestJS, Twine and ChoiceScript.
Never truer words spoken.
Yeah, I’m bagging what you’re mowing. With a new interface, a new type of game is basically achieved. If you make any headway, please share!
Curious, is there already a speech-to-text for mobile parser games? Like, could you say “go north” to your phone and it would execute the command in a parser game without a hitch?
iOS and Android both have built-in speech-to-text, so this would logically be a matter of making an interpreter compatible with what’s already there rather than something that people would have to make from scratch.
Have you taken a look at :
- games made in dialog (eg: The Impossible Bottle)
- games made in GrueScript
- and I should add my latest experiment trying to make a choice-based game a little more “parser-y” : Palazzo Heist (made in ink + some javacript on top)
The GrueScript games are not great on a mobile screen though
I think something like Stardew Valley kinda is this, with the choices obfuscated by the graphical interface. Holding your trigger right is basically the same as selecting walk east or go to town center, when it comes to core gameplay. We see an established, persistent world that we’re moving among and trying stuff out in - this to me is one core concept of MUDs (which is where the majority of my parser experience is).
I think text-focused allows for deeper story and more unique mechanics which graphical games can’t easily create; I want to build text worlds people can easily feel like they are living in.
No, and thanks, I will check all that out! I am a QA professional, so learning coding in different systems is a great way to build my technical knowledge. For example, making something in ChoiceScript has taught me about whitespace coding and what issues look like when caused by errors specific to that type of coding, while building in twine has improved my webdev error analysis.