What exactly is of interest for you, Candy64? It’s more or less a couple of rows of buttons, that affects the input string. It interacts completely with an input-Element, for which I suppressed the system softkeyboard. Instead of the system stuff, I can integrate it in my layout and have full control how it behaves. A surprisingly simple thing (but probably only when you try to integrate it in a homebrew web-based system). It even switches to German layout, wenn you type “German”. 
I use the soft keyboard in my mobile app and it works great for me; all the issues I have had with it are solved, except one which I can live with. There are a number of design and layout issues that mobile apps inherit. The main issue being the keyboard going from visible to invisible. This causes excess work of the application in recalculating the layout. It causes the layout to “bounce” from off to on and off again when the input loses focus or “enter” is pressed. Then there are issues with spell check and text prediction characteristics built into these interfaces. I’ve solved the bounce problem which was the hardest but it comes with a tradeoff, landscape mode is nearly impossible. Spell check causes false positive red underlining of text. Text prediction causes an annoying extra bar to flicker on and off and float over the keyboard with what it thinks are helpful suggestions. Those two things are basically worked around. Spell check disabled, text prediction turned off, though it doesn’t always seem that way as it will flicker on and off. I use the soft keyboard from the MAUI community toolkit as it behaves better than the stock soft keyboard for the input controls.
edit: some of my problems are a result of the type of UI I want to present. I’ve tried to simulate the C64 experience where the text starts at the top and builds towards the bottom of the screen and then the top scrolls away. My only addition to this in preserving the scrolling.
Finally to my interest, I just would like to know if you made your own keyboard “from scratch” or used another premade solution. I’m not asking for any trade secrets.
This is a huge improvement! I played on mobile.
Firstly, the full screen mode and top bar tap are great. This mode gives significantly more space on small screens where every mm counts.
The keyboard is good . I’m glad you did this, it’s what I did and I haven’t looked back. The problem is solved!
For reference, my shift key doesn’t capitalize. Instead it shows the punctuation page. I figured, this is for IF input so caps aren’t needed. Perhaps later, I will put them on an alt shift or somewhere. I also do not have the digit row to save space, instead making the buttons slightly taller and put digits with shift page.
The scroll failure is gone. I did not get the problem of having to manually scroll to see the last output.
Spiffing!
I built the keyboard almost entirely from scratch, and since it’s a pretty simple implementation, it went very quickly. Integrating it into the somewhat convoluted HTML structure of the game screen was the most complicated part.
My project uses .NET Blazor, so my solution is based on CSS, HTML, and C#. You’re working with MAUI, right? In that case, the solution would look a little different, but probably not much more complicated. I’d be happy to provide you with source code and know-how, but in my experience, the most important thing was realizing that building a keyboard by myself is actually much easier than struggling with that monstrous system, which, when in doubt, behaves differently on every device.
The app is linked, after all. Just give it a try. I’ll add a few essential special characters, but other than that, I consider the whole thing finished.
You recommended that to me a while ago, I remember. You were absolutely right.
Since players might want to write comments in the transcript, my implementation keeps numbers and special characters.
I also implemented a few of your other suggestions, particularly text formatting. In this regard, I realized that I don’t share your opinion on this point. You wanted the text to be as compact as possible (which you can now set). I, on the other hand, get frustrated when the lines are too cramped together. My takeaway from this: There’s no single optimal default setting here. So the result: 3 new text formatting options, but I’ve left the default settings the same on mobile as well.
And this is the “correct” interface IMHO. Maybe it’s just me, but when I see a paragraph peppered with hypertext links, I feel like I have to click every. single. one. It turns into an interaction with a to-do list and distracts from what is actually supposed to be happening: me, the player, discovering something relevant. Some people shotgun examine every noun in a paragraph, but good fiction should subtly and meaningfully point the player to what is relevant and make it ok not to examine the head of every pin to see how many Angels are dancing there. There’s something different about the game action originating from my own mind vs it originating as a “helpful” UI prompt I see-and-click on the screen. I find that the attempts to make the medium easier for the player actually break the self-directed sense of presence by placing a visual bound on what things you should be considering to do next. I don’t know how to describe this exactly, but one way it shows up is how reading a transcript is way different than generating it yourself. The transcript boils everything down to a single train-track path. While one is playing however, that path is unknown, and the fact that there are many unspecified possible paths in front of you makes the process of landing on a meaningful/relevant one something more enjoyable. What would actually improve playability? Just like audiobooks open up the possibility to read books without being tied to a printed book, I think the best possible interface improvement alternative for IF would be smooth voice input and lifelike text-to-speech output that free one from the keyboard and screen while preserving the self-generated choice of next action.
Tzbits, a few comments on this:
The hyperlinks in the text don’t work as a to-do list simply because there are too many of them. If you systematically work through all the links, you’ll lose 1,000 brain cells. No one should do that.
Furthermore, you can make the hyperlinks invisible in the options.
However, especially on mobile platforms, nobody wants to spend forever typing long texts on the on-screen keyboard. For this reason, I’ve heavily emphasized the multiple-choice gameplay style and optimized it specifically for smartphones and tablets.
However, the philosophy behind my implementation isn’t to force my playstyle on players. I want as many playstyles as possible to be viable. That’s why the system is designed so that you can play it like a classic IF game using the keyboard or entirely via multiple-choice.
I’ve also added a voice input mode. Every smartphone can do that, and I just linked it to the text parser. I think it’s actually quite useful on mobile, but I can assure you: 90% of everyone here on the forum hates voice input.
I actually tried text-to-speech once. To be honest, the results were still very unsatisfactory. The intonation is just poor. Maybe, with an incredible amount of effort, you could manage to add voice acting to an IF game. But simply plugging in some text and getting excellent voice output - that’s still very, very far from reality. If I ever win the lottery, I’ll take all the money and go to a recording studio to have my games voiced by REAL voice actors. I really admire their craft.
This is where I am at. Trying to decide to commit to the work. I will likely mull this one over because I haven’t budgeted the time yet for the effort and what I have is not a problem (yet). There are many facets to consider. Your starting success with it is very motivating.
Indeed. That’s why I don’t like it Maybe it’s just me, but the fact that there is a hyperlink there triggers something in my brain that says they are all relevant and I will never be able to complete this todo list. It’s not really a conscious thing, but more of an unease of not having clicked a thing that could (should?) have been clicked. Good call in making the links optional.
Ooops, no, this like was wrong. Correct link: https://interactive-onions.io:5499
Thank you for letting me know!
The IFComp has now begun, and I can show you some things from the current version of the game. You can find it here: https://interactive-onions.io:5469.
After several testers of “Caribbean Nightmare” complained that there was no map in the game, I added one. It certainly has room for improvement. I’d love to hear your feedback.
Desktop:
Mobile:
Of course, the current map shows only a few locations and doesn’t really give away anything significant from “Caribbean Nightmare.”
Dan, thanks for the hint. I’ll check. It ran all the time, so it couldn’t be something too serious.
It took more than a minute to load on my Samsung Galaxy A15, just sitting there on the “Loading…” screen. I eventually force-quit Chrome and reopened it, and then it loaded.
It seems a bit odd to worry about “playability” on mobile when you’re using Blazor. You’re sending down 15MB of WASM. That’s unplayably large on mobile.
(Perhaps you could at least optimize the title image? The title image is a 1920x1080 PNG image, clocking in at 3.4MB, out of 20MB total just to load the page. Just converting it to JPG at reasonable lossiness brings it down to 400KB. On mobile, it’s going to render at around 300px. If you use a <picture> element, the browser can automatically download a smaller image. At 300px JPG, the image is 35KB.)
Eventually, I did get it to load. On mobile, the tab selector is hidden, so I can’t see how a user is supposed to figure out that the map exists. Eventually, I figured out that you can tap on the room name in the header bar to bring up a tab selector, but none of the tabs are labeled, so there’s no way of guessing what they’d do. What does the sign post do? What does the wrench+screwdriver do? Is the map marker icon a map? (No, it isn’t.)
Eventually, I figured out how to open the map, using the sign post, and then selecting “Map.” The map opened, but I can’t close it, because the close button is stuck behind the header. I can’t scroll up to the close button, because scrolling up just pans the map. As far as I can tell, the only way out of this is to refresh the page (or stop trying to play).
When showing menus at the bottom of the screen, there’s no bottom margin; the Cancel button is right up against the system navigation handle at the bottom of the screen.
When a bottom menu is visible, the menu gets a lock icon, and then, you can’t open the menu. (Why not?)
EDIT: Oh, hey, getting stuck on the loading screen wasn’t due to loading performance at all. I can reliably reproduce a hang loading the site in Chrome, just by opening https://interactive-onions.io:5469/ in an incognito window. It gets past the initial black “Loading…” screen and then gets stuck on the next “Loading…” screen, with no error on the console. If you then refresh the page in the incognito window, it will succeed on the next refresh, but if you close the incognito window and open a new one, it will hang again.
This is certainly the same bug.
Hey, Dan, thanks a lot for sharing!
The empty screen and the bugs in the console with Safari: Fixed. OMG, what a stupid bug.
Map was a bit too high for some resolutions. Should also be fixed.
Icons in the header line are (in that order):
- Walking (including map)
- Typical Game Actions
- Items in this location
- Inventory
- “Technical” Actions like load/save/restart.
The header line menu works rather fine, but I would agree that a bit more finetuning would not hurt.
General starting issue: I’m almost sure that I found it this time. It only can happen for the first time you start the game. But you can reproduce it with the stage version (link via PN), because every stage has it’s own data.
The missing bottom margin is not really a missing bottom margin, it’s just hard to see that you can swipe here. Fontsize etc. changes height here. There must be a more elegant solution than the current one, I’m sure.
When a bottom menu is visible, the menu gets a lock icon, and then, you can’t open the menu. (Why not?)
It has some internal reason why multiple choice blocks closing the menu. That might change in near future.
It seems a bit odd to worry about “playability” on mobile when you’re using Blazor. You’re sending down 15MB of WASM. That’s unplayably large on mobile.
I agree that 15 MB is a lot. I surely have to optimize that. But loading times in WIFI of 3 seconds are not really “unplayable”.
I also reduced the size of the much too big title picture.
If you can confirm that the changes in the stage version helped, that would be really great.
I’ll spend the stage version a bit more testing, then it goes live.
Again, thanks a lot, Dan!
I can now open the game in an incognito window, and it opens on iOS.
But now the map is really small, just half the size of the screen. I think the map should just be full screen, covering up the header rather than hiding under it.
Also, the map close button doesn’t work on iOS. (It works in macOS Safari.) I tap it, it flashes, and the map just doesn’t close.
I don’t think you can optimize Blazor down to a reasonable size, because Blazor inherently ships its entire standard library.
And it’s not just wifi performance to consider, but also CPU performance. Android mobile CPUs are designed to be cheap and very, very slow.
My point wasn’t for you to tell me what the buttons do, but to label the buttons in the UI, so users can figure out what they do.
On desktop, there’s a side pane, with three unlabeled tabs. I think they’re “Actions’” (??) “On Site” and “Inventory” but that’s confusing, because the primary “Actions” pane is divided into indented sections: Movement, On site, Inventory, and Other Actions.
But, I don’t think you need any tabs on the desktop side pane. The other tabs are just hiding stuff that you’re already showing in the Actions side pane.
On desktop and on mobile, you can also click on the room name in the header bar, which shows six unlabeled buttons:
- Sign Post: Movement
- Tools: Other Actions…? but just a short list…? Not the full “Actions” menu you see on desktop
- On Site
- Inventory (with a different icon; the header bar has a roller-bag icon, where the sidepane has a suitcase)
- Gear (Other Other actions, meta-game actions, but not Settings)
- Fullscreen
You can also click the “hamburger” menu with a list of buttons that are labeled, thankfully:
- Home (just shows the name of the game and a Play button… why is this here?)
- Play (this only exists to escape the other modes, but I think it’s not needed. Settings, Log, and About should have close/back buttons, instead.)
- Settings
- Log (transcript search)
- About
- Quit (this doesn’t work on the web; it just makes the window unusable, and should be removed from the web version)
I don’t think you need all this UI.
Comparing your UI to other systems
- This UI reminds me a lot of the UI of Quest by Alex Warren.
- The top-rated Quest game on IFDB is Whitefield Academy of Witchcraft, but it overrides Quest’s UI to disable verb suggestions.
- A more “pure” example of Quest UI might be Basilica de Sangre. (You’re a demon; clicking on people reveals a verb to
POSSESSthem.)
- It also reminds me a little bit of the UI of GrueScript by Robin Johnson.
- Play a little bit of Detectiveland on mobile and desktop to get a sense of what GrueScript is like. (Detectiveland is a great game; it was the first ever non-parser game to win IFComp in its year.)
- But note that Detectiveland has a highly customized UI. The sample game for GrueScript is The Party Line, which is more representative of what standard GrueScript games are like.
- For another game that does something similar, but that has no reusable “system” for it, look at The Colder Light.
Quest has a lot of side panes
Quest for a long time was available only on Windows and in a server-side renderer (which was extremely slow), but Quest Viva is a WASM-based Electron app. It works great on Windows, macOS, and Linux. It has a web player, too, but it’s Blazor based, so it’s also very, very slow to load, especially on mobile.
Quest’s whole deal is its side panes. It comes with a bunch built-in, and the author can customize them. Inventory, Status, Places (every place you’ve ever seen), Objects, Compass (exits). An on-screen map pinned to the top of the window. Click on an item in the side pane, and it reveals a list of plausible actions to perform on it. Quest has a parser, but it’s usually optional.
On mobile, side panes don’t really fit. There’s a mobile menu icon (too small for mobile, if you ask me; nothing here is designed for mobile tappability), and it pops open a “side pane” menu that covers up 2/3rds of the screen. (In my opinion, it might as well be a full-screen experience with a close button at that point.)
GrueScript pins panes to the bottom of the screen
By contrast, GrueScript was designed for mobile play. Read the Foreword to the GrueScript manual to get a sense of how Robin thought about the problem.
GrueScript games have no parser at all. Items reveal verbs that you can use on them. On mobile, GrueScript pins all of its panes to the bottom of the screen, ensuring that players can see them and access them at all times. The UI has a line identifying the current location, a list of exits, visible objects, a “wait” command, and two inventory panes (“I’m holding” “I’m also carrying”).
That’s very confining on mobile. It forces the text to be very brief.
Colder Light feels a little like GrueScript
I believe The Colder Light was originally written in a fork of Inform / GlkOte. It’s designed to make the UI reveal actions that perhaps wouldn’t occur to the player to type.
It has an inventory pane pinned to the bottom of the screen, grouped into categories (wearing, carrying, runes, beneath), which is interesting.
Above that, there’s a “suggested actions” pane. When you click on an object, suggested actions for that object appear in the “suggested actions” pane, with a back button to dismiss focusing on that object.
On the right side of the suggested actions pane, there are two out-of-world actions, “help” and “undo.” There’s no UI for save, restore, or restart.
Window panes are kinda problematic. Put stuff in the main scrollable transcript, instead?
The core approach that all of these systems share is to move the game UI out of the main scrollable transcript of the game and into window panes that don’t scroll away when you scroll the transcript. I used to be more enthusiastic about this approach, but I’ve since soured against it.
One reason I’m skeptical of it is screen-reader accessibility. When you click a button in a pane, and it causes something happen in the transcript and causes buttons to appear in the panes, it’s going to be difficult for a screen reader to figure out what to announce next.
Also, screen readers require users to “focus” a UI element, to read it or to interact with it. Where should the focus go when you push a button, but now the button is gone, and there’s some text in the transcript, and also some new buttons to push in the panes?
If the panes are mostly the same, but just one or two new buttons appeared while some new text appeared in the transcript, how do you announce that to the player in a way that works well?
On the other hand, if the buttons/hyperlinks appear in the scrollable transcript, if clicking on a button just makes more text appear in the transcript, including new hyperlinks, then it’s obvious where to focus the screen reader and what to announce: you focus the screen reader on the new text in the transcript.
And that solves another problem, too: the panes don’t need to tie up half the screen (or more than half the screen, as they sometimes do in GrueScript).
Your system could use the main scrollable transcript a lot more, and have way fewer buttons
What if your UI had just three on-screen buttons:
- Menu
- Other Actions would go here
- Look/Location: This would re-describe the current room and its exits into the main scrollable transcript. You wouldn’t have/need an “On Site” menu.
- Map
Inventory would show in a bottom pane (or a side pane, on the desktop), with a close X button. If the user closes the inventory, print in the transcript, “To view your inventory, type INVENTORY”, and it would add an “Inventory” command to the Menu.
When you tap on an object, instead of popping up a menu pane, the menu could appear in the transcript, too. (No need to “Cancel.” Just tap another item to get its menu.)
Hm, ONLY in an incognito window??
Your post deserves a much more detailed answer. It will take some time to go through all this stuff, but answer will come.
No, it works in a regular window, too. (Sorry I could have been clearer about that.)
15MB is huge, honestly. mobiles are not always on WiFi. Over the air, i mostly get the pathetic performance of around 100-200k/s. it’s awful. sometimes only just above dial-up. i mean, really?
over the last months I’ve been thinking of my web versions less of a game, and more of a content delivery system. I’ve been battling to get my WASM under 2MB. it goes on a diet, then more code is added.
2MB is still a lot. I’ve discovered that WASM can be compressed by servers. normally this is not enabled. if i gzip my binary, it reduces to < 1MB. Most servers don’t do this, which is annoying.
In terms of content delivery, i am streaming everything except the base WASM. so i actually cant put anything on the screen until i get (1) the story file! (2) the font (3) usually, the title picture.
the font? Yeah, for a while i displayed a provisional font, which updated once the game font had downloaded. Unfortunately, this was annoying. You start reading, and 1 second later, it re-draws and everything moves. It was worse than actually waiting. so that’s what i do now.
pictures are progressively streamed. like the old jpg days, except they’re not jpg.
good luck with your maps!