Cut over to using the `unigame` client package with selective use of SwiftUI

[joshuaauerbachwatson]

I have separately been developing the unigame framework, which carries the "any" aspect of anyCards further (basically supporting any game that has players taking turns). This is made possible by the fact that the unigame client provides the UI for player management, chat, and help but just has dummy UIs for setup and playing. So, you can have a UI that has nothing to do with cards (e.g. chess, checkers, dominos, Mah Jongg ...).

Splitting responsibility for the text of the help view is an aspect of unigame that is not yet fully worked out. It could be as simple as pasting together pieces of HTML but that assumes that the help describing the player management and the fixed aspects of setup and playing (basically, the logic of turn taking) can be written in a way that can be included in almost any game. Not sure about that.

Currently, unigame assumes that Auth0 is used to acquire tokens (because unigame-server assumes that), but does not have an Auth0 dependency nor an Auth0.plist because each using app needs to declare its own Auth0 application identity with its own unique callbacks matching the Apple bundle ID. The management of that split is tentatively worked out.

Most of this is currently untested. So, the plan is to change anyCards so that it declares a dependency on unigame and becomes the first user of it. Since unigame owns the top content view, which is SwiftUI, and the top level shells of the Setup and Playing views are also SwiftUI, this means that anyCards needs to either use SwiftUI or make use of UIViewRepresentable to embed the existing UIKit material as needed. I will play that by ear as I go.

Logistically, since this is a huge sweeping change to anyCards I will develop the new limping version of it on a branch.

[joshuaauerbachwatson]

Something is limpingly working now with a playing view, no setup view, and no modal dialogs. There is a crash in the lead player when ending the setup phase because it is dummied out and the game handle code doesn't quite understand what to do. I think the setup view needs to be a lot like the playing view but with some extra controls.

Once we get rid of the crash (by creating a real setup view) and verify that some rudimentary play can occur, I will start restoring the modal dialogs. They will all be redone as SwiftUI popovers or alerts.

[joshuaauerbachwatson]

In developing the setup controls, a couple of sub-issues come up.

1. In saving the current setup, a name needs to be assigned. This will require a popup.
2. Similarly, we still need a deal dialog.
3. I it is unclear how you can delete a saved setup. Easiest is to have a button or other touchable action that operates on the currently displayed saved setup. We need a load button anyway. So, having both load and delete seems ok.

There is also other logic to be added as all the button actions are still TODO at this poin

[joshuaauerbachwatson]

The current layout of the setup view is a mess.

1. Controls for naming, selecting, saving, loading and deleting setups need to be grouped together.
2. The other controls (deck type selection, hand area toggle, deal button, and reset button) can form a separate group.
3. The PlayingSurface needs attention to get its aspect ratio correct, both when it is dominating the playing view, and when it is windowed (slightly smaller) into the setup view.
4. Related to the previous, we need to figure out how (or whether) to lock the orientation to match the playing surface's aspect ratio.

It would also be good to get solitaire mode cleaned up so I can make sure all the interactions in the PlayingSurface are actually working. There is some evidence that the view does not always update when it should.

[joshuaauerbachwatson]

This might be the way to do the orientation locking:

https://stackoverflow.com/questions/78829188/locking-rotation-to-portrait-on-swiftui-without-the-use-of-appdelegate-or-scened

[joshuaauerbachwatson]

This might be how you force a particular aspect ratio:

https://developer.apple.com/documentation/swiftui/view/aspectratio(_:contentmode:)-771ow

[joshuaauerbachwatson]

1. Controls for naming, selecting, saving, loading and deleting setups need to be grouped together.

The GameTokensView in unigame might provide a clue. It has a place where the current game token is displayed, a place where selectable game tokens of the past of displayed, and add and delete buttons. I don't want the saved setup control to occupy as much space, though, particularly vertical space. So, I would use a picker rather than a list for the saved tokens. The picker also takes the place of the "current" display, but we would need buttons to add, delete, and load.

The semantics of "add" would subsume "save" (the current setup is saved under the added name).

[joshuaauerbachwatson]

• Similarly, we still need a deal dialog.

I think we now have one, although the actual dealing is untested.

[joshuaauerbachwatson]

Setup view is now better. i'm trying to use solitaire mode to shake out bugs. Issues noted:

1. In solitaire mode, most of the rest of the players screen is useless and should be greyed out or replaced by some informative text.
2. In the setup screen, changing the deck type or hand area indicator does not seem to update the view.
   • But note that we should fix the playing area aspect ratio before seriously experimenting with the hand area.
     3. If you go to the playing phase (note that both setup and playing share the same playing surface instance) there seems to be two decks.

[joshuaauerbachwatson]

Another issues

• In solitaire mode there are no turns, so the end turn button should not be there.

[joshuaauerbachwatson]

3. The PlayingSurface needs attention to get its aspect ratio correct, both when it is dominating the playing view, and when it is windowed (slightly smaller) into the setup view.

I've done some layout tweaks to fix the aspect ratio, by using the .aspectRatio modifier as per the link posted above. Still no orientation locking, but I expect to return to that since it is part of the TODO material in PlayingSurface. Right now, the setup view layout looks good on iPad simulators but there are ugly overlaps when running directly on mac. I am not worrying too much about that.

I think the next step is to get solitaire mode fully smoothed out so I can then use it to debug all the interactions involving the PlayingSurface.

[joshuaauerbachwatson]

Solitaire mode seems more or less working. Issues with the setup screen remain pending.

[joshuaauerbachwatson]

The setup screen issues are mostly resolved. Time to exercise setup and playing more fully in solitaire mode and then test multiplayer scenarios.