Untangle: allow full screen game area instead of cropped square

[berteh]

Describe the bug
When dragging a dot further away from centre in game 'untangle' it gets hidden and move cancelled.

To Reproduce

• Play untangle,
• drag any dot to screen corner, release
• move gets cancelled

Expected behavior
Allow to use full screen area, adapting to resolution and orientation. not just center square.

Screenshots
https://github.com/chrisboyle/sgtpuzzles/assets/36950/47b723ec-48b3-41a4-aea5-0da700d76bb9

Version info (optional, but sometimes helpful)

• Phone/tablet model: blackview bv6200
• Android version: 13
• App version : 2023-02-10-1537-bd5c0a37-fdroid

[berteh]

Update from Version 2023-11-15-2237-96d65e85:

The improved visibility of cropped zone makes the bug less annoying.

Still, would be much more intuitive+fun to be able to use full screen.

[JonnyTech]

+1 - it is really frustrating to have so much wasted space, and having big stubby fingers on my device's small screen makes it difficult to contain the dragged dots within the play limited area.

[chrisboyle]

The hard part of this is "adapting to resolution and orientation", since on many devices those can change during play, whether by rotation, by resizing a window (ChromeOS and non-Android platforms), or by adjusting a split-screen (on any Android device, in principle).

The current architecture is not well set-up for changing the aspect ratio of the playable area during play, rather than that of the viewable area. As with all the games, Untangle remembers an undoable chain of moves (look inside a save file to see this), and in Untangle's case those include the coordinates the point was moved to. Transforming all this information repeatedly while the user is dragging the edge of a window would cause problems, such as the accumulation of errors.

This problem is also not specific to Untangle, although Untangle is in principle more stretchable than most other games in the collection. It's also arguably a divergence from upstream / other platforms, in that it may change the dynamics of the game - but again less so for Untangle than for other games, I think.

A halfway-house to a solution would be for Untangle to fill the available screen area at time of game generation (similar to how other games will flip the orientation of their preset grid sizes for generation, by default, on Android). The trade-off is that, as with those other games, if you do resize/rotate the area during play, you will then be in a worse position than if I hadn't made such a change (e.g. tiny portrait rectangle within a landscape screen, vs a square currently). Perhaps a prompt (snackbar?) could appear suggesting that the user start a new game which will match the screen size, though that does feel a little ugly.

[JupiLogy]

Personally, I zoom in on untangle games anyway, making this a bit pointless in my case. But I see the appeal. Perhaps the game can be scaled to the size of the screen at time of game initialisation, and if the user zooms/rotates/[cuts their phone in half] then the coloured square will have to guide them? I don't know if many people change these things mid game.

[berteh]

Thanks for all this feedback

From all this I'd say: allowing full screen (no dead margins) usage combined with ability to zoom in/out using the classical 'pinch' move seems like a good compromise, and ability to 'move' the board with two fingers slide.

The absolute coordinates would still work, just in a much bigger (virtual) area. Screen rotation could be kept clean, either by keeping the current zoom level or resting the zoom to fit all elements in current game.

not many extra UI elements needed (evt a single 'center and fit view' button)... and it could be used for all games of the pack to remain consistent.. and bulky fingers friendly ;)

[chrisboyle]

The zoom feature is already there, so I guess this suggestion amounts to allowing the board size to match the initial screen aspect ratio and not resizing it when the screen/window changes size. The idea of zooming in at that point is potentially interesting, but it would need yet another toast to explain what had happened and avoid confusion, in case the user never knew that the app even supports zooming.

Meanwhile I have added the upstream tag, because this affects compatibility of saved games, which puts it into the category of changes I'm unwilling to make on Android unilaterally (it would have to be made upstream first).

[Chemicthyologist]

Makes me wonder if there could be a "0,0,0°" point randomly assigned to a node, with all other connected nodes updating their coordinates from that node (or even simpler/more complicated, tracking only the nodes they're connected to)

I'm sure this isn't how it was designed, and has already been considered by ChrisBoyle.

[nightgolfer]

I personally like the idea of sizing the play area to fill the screen at launch, and then adding a prompt with "New game?" and "Cancel" for screen size/rotation changes.

Question - when an issue is labeled "upstream", is it then best practice to try to raise it upstream instead? I mean, if I have an issue that I can see would probably be best handled "upstream", should I just go there to raise it instead?

[chrisboyle]

• When an issue here is labelled "upstream": it means conversation with Simon/others upstream is necessary. I don't have a separate tag indicating whether anyone has had that conversation; that info would only be in the text of the issue/comments.
  • In general it does not mean I am encouraging anyone to merely tell Simon/others about the issue: usually, if progress could be made that way, I would already have done so, and I think he looks at this repo occasionally anyway.
  • Usually when an issue sits here tagged "upstream" with no activity, it's because it's a feature request that's very similar to others I've already mentioned to him a few times and I don't want to nag when I'm not proposing to make the effort to build the feature myself - as opposed to a bug with an obvious idea of what the correct behaviour is, where I'm more likely to take the initiative and send a patch when I forward it.
• When you encounter an issue in the Android port that is likely to be upstream-relevant in some way and isn't already reported in this tracker, I would still appreciate an issue report here, so I know about it, and in case I can help. Whether you also report it upstream is up to you.
• The best source of information on reporting things to Simon is the Feedback section of his puzzles page.
  • If you're going to do that, I would suggest you check first that the bug exists on the non-Android platforms he publishes, e.g. Windows or web - in case it's a bug I've introduced on Android.

---

Having said all of that, for this specific issue, I haven't mentioned it to Simon yet because I have yet to form an opinion on what the specific implementation details of a sensible change might be, bearing in mind it wouldn't make sense to massively complicate the Untangle implementation upstream just for the benefit of Android.