Let's think about how to make buttons bigger and more finger-friendly

[NomadicVoxel]

Problem Description

The problem is simple: we're adapting a GUI that was designed for a mouse.

Good job on making the UI more compact to fit, but there's still the issue of buttons being sized for a mouse. My fingerprint covers like three or four entries on the job board, for example.

Related Issue Links

Text scaling is kinda a relevant issue, and I think patching that might help this somewhat, but not all the way.
#30

Desired Solution

Here's a few simpler ideas:

• Bigger margins on buttons
• Bigger line height on lists
• On the map screen, panels can overlap. Maybe move the panels around. Give the job board the entire height of the left side.
• For lists with collapsible sections (like the Outfitter shops), maybe collapse the sections by default. And perhaps put a green asterisk on ones with items the player can afford, and a blue one on items the player had never seen before.

Alternative Approaches

More complex ideas:

• Do what Chrome Mobile does when it receives an ambiguous tap: screenshot the area around your fingerprint, and magnify it, and have the player try again.
• No room for several big buttons? Replace several with one that hides and reveals them! Such as moving the Job Board's sorting buttons to a row under the title line, and where they were before, add a button to hide/reveal that row.
• Collapsible sidebars: Make large panels the entire height or width of the screen, but just shove them off screen until someone selects the relevant menu button.
• Screen panning: Move the entire frame of view so the element the user is focused on is centered vertically.(Particularly renaming a new ship, or typing the Captain's name to confirm you want to delete a game. My keyboard covers it.)

Additional Context

No response

[thewierdnut]

Every change I make to the mobile fork is a change I usually have to re-implement when I rebase on the upstream project. My preference is to push changes like these upstream if possible, and I am working on these issues already, but the upstream project has a slow pace of development for UI changes.

These changes are coming. Stay tuned.

[sere3925sere]

...Let's start small. Let's make it so the click on a star map will select the closest star to the click. It is very easy to miss on mobile overwise. Maybe we can make it an option in the main game?

After that, I think a game pause button would be nice, so I can give orders at my pace. I want a button to the left of everything that would pause/unpause things, and maybe even pause the game whenever an enemy ship is spotted or fire received, or even whenever I leave the planet. I kinda want to have a button that would run the game as long as the button is pressed, but pause as soon as the button is released.

When it comes to quests, maybe having buttons [1] [2] [3] at the bottom is a good idea? So that text itself stays small, but you have big buttons you can press below all text.

Whenever I type anything, keyboard hides the text field below the keyboard, so I have to type blindly. Would be good to fix.

Ship info doesn't fit on mobile screen right now, need to make it scrollable.

When looking through shop, and item description is visible, game doesn't see the difference between a click and attempt to drag, so whenever I try to drag through it, it minimizes the entire thing.

[thewierdnut]

...Let's start small. Let's make it so the click on a star map will select the closest star to the click.

This should be trivial. We just need to make that hitbox bigger.

I think a game pause button would be nice...

The game engine is designed using input polling, and is not event driven. This means that if we pause the gameplay, then none of game controls work anymore (only the ui buttons). This is something that would require rewriting the game to address.

When it comes to quests, maybe having buttons [1] [2] [3] at the bottom is a good idea? So that text itself stays small, but you have big buttons you can press below all text.

It shouldn't be that hard to just give the options some more spacing, perhaps put them in button containers. I'll have to give it some thought.

Whenever I type anything, keyboard hides the text field below the keyboard, so I have to type blindly.

I can't really infer the position of the keyboard, and SDL doesn't tell me. On my device the keyboard is floating in landscape mode, and I can move and resize it. About the best I could do is just scroll the inputs to the top half of the screen when they are present.

Ship info doesn't fit on mobile screen right now, need to make it scrollable.

I have scrollable panels implemented now, so hopefully this will be fixed soon.

When looking through shop, and item description is visible, game doesn't see the difference between a click and attempt to drag, so whenever I try to drag through it, it minimizes the entire thing.

This should be trivial enough to fix (use mouseup instead of mousedown to trigger).

Each item you have noted here (except the game pause thing, that is unlikely to happen) would be great individual issues.

[BurntVoxel]

On the keyboard thing: every app seems to have the issue of not detecting where a floating keyboard is, actually. I think that one's just Android's issue.

For "normal" keyboards that are docked at the bottom and the full screen-width... I found this part of the Android documentation on how to find the space available in the window. Ctrl-F for "WindowInsets.ime" (short for input method).

However, the option most fullscreen apps take is that when you touch the text box, a different native text field appears in a more suitable place. When submitted, that text is injected into the game. Idk if this is from Android itself or implemented by the apps though.

[thewierdnut]

this would be trivial if I was using android's sdk... but I'm using SDL's, which doesn't expose this information. I would have to hook it myself somehow (probably butchering a bunch of jni code in the process), or just Make Assumptions.

[sere3925sere]

The game engine is designed using input polling, and is not event driven. This means that if we pause the gameplay, then none of game controls work anymore (only the ui buttons). This is something that would require rewriting the game to address.

Can I get more info on that? Maybe I'll go and implement pause into the main game, or at least ask others to do that. Where is the code for input processing in the source code?

...Let's start small. Let's make it so the click on a star map will select the closest star to the click.

This should be trivial. We just need to make that hitbox bigger.

Not a good idea for planets that are too close to each other, hitbox of one can overlap with hitbox of another. Getting all stars that are close to click, and finding which one is the closest might be the best way here.

[thewierdnut]

Not a good idea for planets that are too close to each other, hitbox of one can overlap with hitbox of another. Getting all stars that are close to click, and finding which one is the closest might be the best way here.

The hitbox is scaled with the zoom level, and I think there is a minimum distance the planets are away from each other, which is much bigger than the hitbox size.

A "closest star" approach is also certainly doable, its how I handle the selection of stars when using a gamepad. Keep in mind though that you have to make some blank space available so that the user is unambiguously not selecting a star, so that they can do scroll and zoom operations.

[thewierdnut]

The game engine is designed using input polling, and is not event driven. This means that if we pause the gameplay, then none of game controls work anymore (only the ui buttons). This is something that would require rewriting the game to address.

Can I get more info on that? Maybe I'll go and implement pause into the main game, or at least ask others to do that. Where is the code for input processing in the source code?

Check out the Ai and Engine classes, specifically here, where the engine polls the keyboard state. There is a complex algorithm to determine which keys get persisted between frames, and whether their meaning changes on a long press vs a short one, and also what to do with modifier keys. Many of the endless-mobile enhancements work by using a command hook to simulate a keypress.

Keep in mind that this is the code that controls user input and npc flying, and is probably the most frequently modified code in the game. I usually have to re-implement endless-mobile specific features that use this code when I rebase on the upstream, and so I'm not inclined to accept patches that will make rebasing even harder in the future. If you have to make major changes to the code, you are better off trying to modify the upstream code instead, and they won't accept anything that doesn't add value to the base game.

[sere3925sere]

I looked at issues, and found out that one guy already made in flight pause a few months ago, it hasn't been merged yet though. endless-sky#10186 . I guess I'll wait for that to be done before continuing playing.

A "closest star" approach is also certainly doable, its how I handle the selection of stars when using a gamepad. Keep in mind though that you have to make some blank space available so that the user is unambiguously not selecting a star, so that they can do scroll and zoom operations.

I'd rather it work like this: If user does a short click, and mouse doesn't move too much, then the moment the user releases the mouse button, the game registers a click. But if user does a click and mouse moves a significant amount of pixels before being released, then the user drags. And if a user wants to deselect a selected system, he should either click the home system, or click far away from all star systems, somewhere where he hasn't explored yet. This is related to the issue of me constantly expanding/shrinking description whenever I just want to scroll, game should do that on mouse button up, not mouse button down.

Thinking of doing it like this: place all stars in a 2d array with a big enough grid, where it's possible for one cell to contain more than one planet. On click, select 4 grid cells closest to the place of the click, go through every planet in those cells and find the closest one. Don't have to do the precise distance = sqrt(xdistance^2 + ydistance^2), just distance = xdistance + ydistance will be enough. Maybe the first array will just have an offset to the second array, and second array will be the one containing (number of stars, star1, star2). It will probably be fast enough even with the most simple approach instead, no need for all of this, computers are fast anyway, right.

[derei]

From what I could understand doing some research (please correct me if I'm wrong), the UI for the game is not modular or flexible enough, and perhaps the entire interface should be rewritten in the main game to allow full control with plugins, but that csn very well be a big project.