Cockatrice on Android / iOS / mobile / phone / tablet

[isleep2late]

I spoke with some people, including ZeldaZach and Daenyth, about getting Cockatrice to work on mobile. Originally I wanted to be able to open the chat on my iPhone and just ask people questions/talk, but it appears getting all aspects of Cockatrice onto iOS would be a more high demand project. I'll leave here a preliminary to-do list for the hypothetical case in which some of us would be interested to pick up this project, along with some follow-up points/ideas/concerns.

1. GUI - Some sort of user interface/framework would have to be fashioned, and this first step I'm guessing will be the hardest to get through because it requires some original code.
2. Transcribe the original C++ code to compile on Xcode - At least one source claims Xcode (the program used to develop/compile iOS apps for Macintosh), accepts not only Objective-C but most other C-oriented languages including C++. I've tried copy-pasting some of your Cockatrice source code onto the relevant portions of where it would belong to an iOS app, and surprisingly most of it was readable, with the exception of minor syntax/the obvious unrecognized objects/variables. My hope is that this is all true, and once a GUI is made all that is required is to tweak the C++ code to an acceptable format for Xcode.
3. Compiling/Debugging/Proofreading/Editing - I really don't see this as a one-man job, and this step is really crucial. We'd need multiple people with access to an iPhone 5/6/6+ and iPad to confirm that this will work on their device. We need someone else other than me to have Xcode on a Mac or some means by which to compile the code on an iOS emulator. We'll need other members of the community who'd be willing to help look over any diagnostic issues. Which segues to my next point...
4. Seek help for any problems from #1-3: This part of the checklist is also my opportunity to stress the need for this to be a teamwork effort. I believe in the past people have fantasized over this idea individually without any collective effort to act on it. I'm not saying this will happen, or that it should happen, but that IF this would ever happen in the future, these are some of the steps that we would need to take.

Follow-up concerns:

• Clearly this would get wrecked from a legal standpoint, so I would recommend the app be developed for Cydia rather than the App Store. There's tons of apps that make it to iOS via Cydia with variable success that would otherwise not be publishable to the App Store for logistical reasons. This would severely limit the scope of audience however...
• Perhaps publish to App Store at an obviously free cost without advertisements or profit (I'd recommend the same even if this went to Cydia). Advertise this as a "Sandbox" program [which it is] independent of all ties to MtG, but enable users access to certain card databases for download, such as Magic, or any other card game.
• I don't know how high the demand for this would be, so I guess I'll just leave this here and assume the demand is proportional to how much contribution there is to the project.
• This would be a free, open-source project so it really would take a lot of time if this ever happens. I go to school with a bunch of other priorities I need to worry about and I'm sure the rest of us have very busy lives. At most I can probably delegate, contribute a couple hours on weekends to code, and offer design concepts or ideas for improvement.
• These are all ideas that one person is just throwing out there, so it's perfectly fine if this ends up not amounting to anything, but some people have asked for something like this in the past and it wouldn't hurt to at least gather some interest for developers. So please, take all of this for a grain of salt if you don't see this happening.

[ctrlaltca]

I currently have a private branch with cockatrice running on android, and easily portable to ios.
I said "running" and not "working" because there are a lot of UI problems that needs to be solved, but the code is running fine.
I currently wanted to keep the branch private to avoid getting under the eye of sauron..

[Daenyth]

Honestly I think the best bet is to start from scratch with the .proto files and make a fully native UI.

[isleep2late]

@ctrlaltca thanks for the heads up! Glad to know that people have worked on something like this before, and to know that it is in fact possible. I am more or less mainly interested in an iOS build, but let us know if you'd ever feel comfortable making your private android branch public.

@Daenyth Starting from scratch is also a possibility, and would probably yield a better finish. It would be harder though, so I'm hoping that there are people who use cockatrice who happen to be familiar with iOS development who are looking at this post

[ZeldaZach]

You can always ask around in the main chat @isleep2late

[Kayoscape]

I don't know if this project is still happening, but if it is then I'd love to be a part of it. I have object oriented programming experience, but I haven't used Xcode before, nor have I written anything in Objective-C. Still, I hope I can be of some help. Please let me know what I can do.

[Daenyth]

I think the only way to do this sanely would be to start from scratch. Take
the proto files and make a native ui. The client itself doesn't have much
logic in it, mostly just ui and how to update visuals based on game actions

On Tue, Aug 11, 2015, 5:47 AM Kayoscape [email protected] wrote:

I don't know if this project is still happening, but if it is then I'd
love to be a part of it. I have object oriented programming experience, but
I haven't used Xcode before, nor have I written anything in Objective-C.
Still, I hope I can be of some help. Please let me know what I can do.

—
Reply to this email directly or view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-129794032
.

[LordKahra]

Hello, I'm an Android developer and while I was learning to code I did a lot of work on a playtesting app. It's not finished, and it's very rough due to my newness to code while I was working on it, but I'd be willing to go through it and see if a rough draft could be made to work with Cockatrice. I loosely followed MVC, so if nothing else I think a workable (if ugly) UI could be pulled from it.

I've never really contributed to an open source project before, is there someone I should consult before making a fork/adding a folder for Android related development/etc?

[Daenyth]

It would be best to make a new github project and load in the protobuf
files via git submodule

On Sun, Jan 24, 2016, 6:21 PM Lane Flores [email protected] wrote:

Hello, I'm an Android developer and while I was learning to code I did a
lot of work on a playtesting app. It's not finished, and it's very rough
due to my newness to code while I was working on it, but I'd be willing to
go through it and see if a rough draft could be made to work with
Cockatrice. I loosely followed MVC, so if nothing else I think a workable
(if ugly) UI could be pulled from it.

I've never really contributed to an open source project before, is there
someone I should consult before making a fork/adding a folder for Android
related development/etc?

—
Reply to this email directly or view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-174351731
.

[alexchandel]

1. You don't need to make this a Cydia app. Apple no longer prohibits side-loading apps: you can download, compile, and install third party apps for free. There are no legal consequences to this.
2. Xcode is just an IDE. It's a front-end to the compilers, clang and swift, which can compile C, C++, Objective-C, Objective-C++, OpenMP, OpenCL, CUDA, and other C-derived languages, and of course Swift.
3. If your deck management/server communication/game-finding/game state code is all already in C++, and your networking library supports iOS, then I'd recommend keeping it. If there's truly nothing on the client though, and you can generate Swift implementations of these protocols, then use Swift.
4. The UI should be written specifically for iOS, but this shouldn't be too hard. Objective-C is under-appreciated—far better than Java/C#/other nightmares—but since you're writing a brand new UI I'd recommend using Swift.

[ClintFrancis]

This could be ported for both iOS and Android using Xamarin.
The UI could be done using CocosSharp or SkiaSharp

[Daenyth]

It's open source, go for it.

On Sun, Sep 25, 2016 at 8:51 PM ClintFrancis [email protected]
wrote:

This could be ported for both iOS and Android using Xamarin.
The UI could be done using CocosSharp or SkiaSharp

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-249458079,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5NPlmyfGkL7DcPKnNjQtuHyBPyO0Lks5qtxcDgaJpZM4DZT7E
.

[alexchandel]

Xamarin's Cocoa support is meager unless you're willing to pay for the developer's license. And building Cocoa interfaces programmatically is a pain compared to laying them out on XCode. And the UI code would have to be specific to iOS anyway, since CocosSharp doesn't port to Android.

It's (substantially) easier to make the iOS UI in Xcode, which has a GUI layout tool for iOS and can compile C and C++ code.

[ClintFrancis]

Full disclaimer: I work for Xamarin and have been developing using the tools for five years.

Xamarin has full support for using layouts created in XCode. You can either edit / create them directly in XCode or within Xamarin studio. We also offer the same workflow with Android using Android Studio.

CocosSharp has full support for both Android and IOS. You can check out some of the samples here.
https://developer.xamarin.com/samples/mobile/BouncingGame/

As for the price of tooling Xamarin wad made free for community development and also available as part of an msdn subscription.

[Daenyth]

I feel like this is getting a bit off topic. Let's focus on what we can for
Cockatrice on mobile

On Mon, Sep 26, 2016 at 7:28 PM ClintFrancis [email protected]
wrote:

Full disclaimer: I work for Xamarin and have been developing using the
tools for five years.

Xamarin has full support for using layouts created in XCode. You can
either edit / create them directly in XCode or within Xamarin studio. We
also offer the same workflow with Android using Android Studio.

CocosSharp has full support for both Android and IOS. You can check out
some of the samples here.
https://developer.xamarin.com/samples/mobile/BouncingGame/

As for the price of tooling Xamarin wad made free for community
development and also available as part of an msdn subscription.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-249727031,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5NDVez784PqNenxnSt8r9ve8DI4gKks5quFUjgaJpZM4DZT7E
.

[alexchandel]

@ClintFrancis support for nib files isn't the same as storyboard integration. And I'm not saying Xamarin Studio isn't free, but last time I checked the newest iOS and OSX cocoa bindings required payment. Has this changed?

But in any case I'd recommend native code. There's a speed, memory, and power usage advantage, and Swift is an excellent language. The Android team is currently considering making it a first class language on Android now that it's open-sourced.

@Daenyth Is the deck/network/game logic of Cockatrice relatively disjoint from the GUI? As in the Model-View-Controller pattern? Because if so, it should be possible to write a very thin GUI wrapper, like a .storyboard and single .swift file, which are controlled by the existing game model & game controller logic.

[ctrlaltca]

I'd use Emacs. Oh sorry, i meant to say Vi. 🔥
Please have a look at what's in the code before arguing what's easier and what's better for cockatrice.

I already got trice running on Android, and since the code is based on Qt, the obvious choice was Qt creator; it was just a matter of fixing the build files to get it running.
The desktop UI is obviously far from being usable on a phone, i had a few games on a tablet but imho the "right-click-menu" and "keyboard shortcut" based interface of cockatrice can't be fixed for a touch interface.
Maybe a QML / Qt quick interface would be the easiest to glue with the current code.

Is the deck/network/game logic of Cockatrice relatively disjoint from the GUI?

Most of the low-level stuff (decks, game zones, etc) is shared between the client and the server, so it has no dependencies on the UI widgets.
All the IO (both file and networking) stuff has dependencies on Qt libraries, most of the data structs are Qt based.

As in the Model-View-Controller pattern?

Qt itself uses MVC, but their implementation is so tight to their own classes that i can't really think of easily plug them to something else.

Because if so, it should be possible to write a very thin GUI wrapper, like a .storyboard and single .swift file, which are controlled by the existing game model & game controller logic.

Developing a solution specific for apple devices would cut out android users.

At the end of my experiments with porting the code to mobile, i'd changed my mind and started creating a webapp. The app is currently able to connect, lets you join rooms and chat with users.
Implementing all the game-related procedures is still a long task anyway..

[alexchandel]

@ctrlaltca

Developing a solution specific for apple devices would cut out android users.

The point is that there may exist a simple, specific solution for each.

Most of the low-level stuff (decks, game zones, etc) is shared between the client and the server, so it has no dependencies on the UI widgets.
All the IO (both file and networking) stuff has dependencies on Qt libraries, most of the data structs are Qt based.

They look very reusable.

Qt itself uses MVC, but their implementation is so tight to their own classes that i can't really think of easily plug them to something else.

That's reassuring enough, since Qt provides mobile widgets.

The desktop UI is obviously far from being usable on a phone, i had a few games on a tablet but imho the "right-click-menu" and "keyboard shortcut" based interface of cockatrice can't be fixed for a touch interface.
Maybe a QML / Qt quick interface would be the easiest to glue with the current code.

I'd imagine keyboard shortcuts have no replacement without an external keyboard, but the "right-click-menu" interface can be replaced with mobile UI pattern like "long-press"->"modal-dropdown". In the end it may come down to a separate, slightly modified mobile GUI.

[Daenyth]

@alexchandel long press for dropdown would make a UX nightmare. The majority of game actions period are right click or keyboard based. This is not tenable as a solution.

I'm quite honestly getting pretty tired of this issue. It's come up repeatedly over the past 5-6 years, and every time it does, I've asked for people to show some kind of UI concept that isn't painful; mockups, even a text description of how a game would play out with a touch based interface. Not a single person has replied to any of these, and as you can see, one of the few people who has actually _tried_ to port the codebase over has also not been able to see a path to making a usable touch UI.

We'd all be extremely happy to accept PRs adding any necessary foundation for this. We'd be happy to provide assistance, guidance on how the codebase works, or the protocol, etc.

What I'm damn tired of is more bikeshedding about how to hypothetically do it. I'd like the rest of the conversation on this ticket to cover:

• Discussion of UX workflows
• Mockups
• Specific technical discussion of specific code changes needed to support native porting
• Links to actual attempts to do the porting, or specific blockers that need to be resolved to support such an attempt.

In the interest of not wasting everyone's time, I'll have little choice but to lock the discussion on this if it doesn't get productive.

[Daenyth]

To get the ball rolling on that more productive conversation;

Every app I've seen on mobile for card games has the main interaction being context-sensitive drag actions. This requires a rules-aware game engine. Given that cockatrice's goal is to be a rules-unaware sandbox, this poses a problem.

I also think there's a problem with information density. Compare the board state at a glance between Ascension (works really really well on mobile) vs MtG. Consider the number of cards. Attributes per player. Imagine a 4-person EDH game shown on a 5" screen. Visible enough that you can realistically play against someone on a computer and be able to interject in the chat when you need to respond instead of passing priority. These are the challenges I'm talking about. Not framework, IDE, or compiler. Those are small problems and easily solved. UX is always the hardest part.

[Kayoscape]

Not sure if this is helpful, but I have a few UX ideas.

Drag actions do not necessarily need to be context-sensitive. Dragging in Cockatrice merely represents moving a card, which can be done with any card at any time to any destination on the desktop app, so I don't see a reason to change that behavior. Dragging can be triggered by holding a card for at least one (two?) seconds.

As for the space issue, I propose that the user can only see one player's side of the battlefield at a time, and can switch to a different one using buttons on the sides of the screen. Cards can also be small (take advantage of high resolution on mobile) and perhaps don't need all information at a glance. A tap on a card can open a detailed view with a context menu for actions. I also recommend that cards be auto-alligned into a reorder-able grid to prevent issues with movement on small screens.

Thoughts?

On Sep 27, 2016 at 1:06 PM,

To get the ball rolling on that more productive conversation;

Every app I've seen on mobile for card games has the main interaction being context-sensitive drag actions. This requires a rules-aware game engine. Given that cockatrice's goal is to be a rules-unaware sandbox, this poses a problem.

I also think there's a problem with information density. Compare the board state at a glance between Ascension (works really really well on mobile) vs MtG. Consider the number of cards. Attributes per player. Imagine a 4-person EDH game shown on a 5" screen. Visible enough that you can realistically play against someone on a computer and be able to interject in the chat when you need to respond instead of passing priority. These are the challenges I'm talking about. Not framework, IDE, or compiler. Those are small problems and easily solved. UX is always the hardest part.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-249930252), or mute the thread (https://github.com/notifications/unsubscribe-auth/AIzKkzAFA3VGoorgwUJeYPeUIt3jpHr_ks5quU0GgaJpZM4DZT7E).

[skwerlman]

Instead of using real estate for buttons to switch sides of the board, you could instead use left/right swiping motions to slide between different players. An upward swipe would return you to your side, and a downward swipe would open a context menu for the currently selected card(s).

[Daenyth]

@Kayoscape I think some kind of reduced view will be necessary, but we need to make sure that you can see everything going on so that you can, for example, respond to instants - your opponent might be on a desktop with fast mouse movement and not waiting long for you on priority

There are a few different workflows which may have different needs.

• Playing 1v1
• Spec 1v1
• Playing MP
• Spec MP

I'm OK with optimizing mobile for play 1v1 first and spec 1v1 second, even choices we make there are actively bad for MP.

I think targeting tablet-size devices before handheld-size is also fine.

[spookyyy]

As much as I don't like taking away control from the user, if we decide to stick to having only the user's side of the board on the screen it could switch to the opponent's board if anything on their side updates (i.e. tapping a card, playing a card).

If we decide that maybe having both sides on the board on the screen at the same time is the better path to take, then perhaps making the opponent's board smaller than the user's board is a more efficient use of space.

Building upon @skwerlman 's idea, I think perhaps we have 3 different views:

1. both sides of the board and the user's hand

2. user's side of the board and hand

3. opponent's side of the board

Additionally, the space on the phone is rather limited, but considering the amount of vertical space required to show all of the information, perhaps a vertically oriented UX might be more intuitive here than a horizontally oriented one?

Alternatively, we could use both and design each view around one or the other.

Consider the first view (which might be our default view), it could be designed with a more vertical orientation in mind, allowing more board to be displayed on the screen, but less detail. If such is the case, then it may be a good idea to design views 2 and 3 with a horizontal orientation so that we may show more detail on either side of the board.

In terms of accessing these views, I think that if the user has their phone oriented vertically, it'll remain in view 1. If the user has their phone oriented horizontally, they can switch between view 2 and 3 by swiping down and up respectively.

[Daenyth]

What do you think about explicitly targeting tablet size screens first
before trying to fit it all in a phone size? It would let us get some feel
for what works and what doesn't

On Tue, Dec 20, 2016, 9:08 PM spooky-san [e-mail] wrote:

As much as I don't like taking away control from the user, if we decide to
stick to having only the user's side of the board on the screen it could
switch to the opponent's board if anything on their side updates (i.e.
tapping a card, playing a card).

If we decide that maybe having both sides on the board on the screen at
the same time is the better path to take, then perhaps making the
opponent's board smaller than the user's board is a more efficient use of
space.

Building upon @skwerlman https://github.com/skwerlman 's idea, I think
perhaps we have 3 different views:

1.

both sides of the board and the user's hand
2.

user's side of the board and hand
3.

opponent's side of the board

Additionally, the space on the phone is rather limited, but considering
the amount of vertical space required to show all of the information,
perhaps a vertically oriented UX might be more intuitive here than a
horizontally oriented one?

Alternatively, we could use both and design each view around one or the
other.

Consider the first view (which might be our default view), it could be
designed with a more vertical orientation in mind, allowing more board to
be displayed on the screen, but less detail. If such is the case, then it
may be a good idea to design views 2 and 3 with a horizontal orientation so
that we may show more detail on either side of the board.

In terms of accessing these views, I think that if the user has their
phone oriented vertically, it'll remain in view 1. If the user has their
phone oriented horizontally, they can switch between view 2 and 3 by
swiping down and up respectively.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-268414656,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5NHa1Cao1a8g1Bfn0LMO2MxedwOR1ks5rKIo0gaJpZM4DZT7E
.

[spookyyy]

Oh, yeah we could definitely target tablet sizes. However, I think we'd have to develop different UX's for each device due to screen sizes.

When it comes to the tablet, I think we could try maybe 3 views I described above, all horizontal, and see how it works out. Then, we try a vertical view for view 1 and test it a bit to see if it feels better than the horizontal on tablet. If it does, then we keep it vertical and see where we move from there. There is a possibility that we find that neither works all too well, we'll have to design a new default view.

When it comes to the contextual menus on tablet(and, really, on smartphones):

I think we should just make holding your finger on something the equivalent of right-clicking on PC. Say you tap and hold on your deck, it brings up a menu screen that'll let you "view top card", "view library", "shuffle".

I also think we should be utilizing the multi-touch capabilities of these devices, as it really expands our options. As for what to do, your guess is as good as mine. Maybe use hold with one finger and drag with the other to select cards?

Regardless of what happens, mobile controls will always be (at the very least), slower than the controls on desktop.

[DrKittens]

@ctrlaltca

@Daenyth

I've asked for people to show some kind of UI concept that isn't painful; mockups, even a text description of how a game would play out with a touch based interface. Not a single person has replied to any of these, and as you can see, one of the few people who has actually tried to port the codebase over has also not been able to see a path to making a usable touch UI.

Ideas for the GUI for a TWO PERSON GAME!!!

1. Phone orientation - We force landscape
2. Hand location - Bottom of the screen
3. Small card size, 3 rows above hand = field, colour code them
   Front row (creatures and shit) = red
   Middle row (enchants and other shit = blue
   Backrow (resources) = yellow
4. Ingame chat/log accessible via a tab, viewing card names functions by long pressing on the cards same as desktop.

5. The stack - Whenever a spell is played a beep is made and the card is popped up on the screen (since cockatrice isnt "smart" this wont include lands as cockatrice apparantly knows this rule cough) this card appears fullscreen for X seconds and after that expires the card hits the field and play continues. If the opponant wishes to read the card OR respond with a counter they can click a "wait" button under the card and then play something from hand or click a "nvm lol" button, if no card is played by the opponant after XX seconds the game continues (show a countdown at the top of the screen!?), if an opponant plays a card then this repeats til no-one plays a card then it lists the cards left-to-right last-to-first (aka how the stack fucking resolves)

6. There are 3 views toggleable by a button in a corner
   1-My board & hand (viewable)
   2-My opponants board & hand (backs of cards only)
   3-The front row of BOTH our boards + an icon that represents the opponant/the player.

7. The game steps (draw combat etc) are shown on the TOP of the screen, to draw a card DRAG the draw step to your hand (top of phone to bottom of phone) (can be done on any phase).

8. Advancing to battle/combat phase changes the view automagically to view 3 (both players front rows)

9. Pressing the "end turn" button step makes the opponants phone beep, they click on their "untap" button to untap and take the turn. Both players can still do stuff but the person who clicked "end turn" can no longer change the step back to something else.

THIS IS NICE AND ALL BUT HOW DO I PLAY GAEM??

First we must initialise the game....

0.1: deck select/roll for first turn/draw/mulligan interface.
Literally just the chat + buttons and the deck viewer/editer from the desktop make sideboards start unlocked by default perhaps!? Once decks are selected players click a "start" button somewhere.

Clicking start makes them roll d20, the game checks the highest number and makes that person the starting player so we dont have to fuck around with rolling once ingame unless the winner doesnt want to play firt, if doubleups occur silently roll them again (plz feature request for main game like holyshit the time saved would be amazing)

To view card info: Long click on ANY card opens it full screen, tapping anywhere on the screen leaves this view (this also works for cards in hand/opponants cards/cards shown in library/gy etc)
To "play" a card from hand to field, double tap it tapping a card in hand pops it out so you can see it but doesnt play it, so you can slow tap twice to play a card.
To "tap" a card: short single tap
To "move" a card: Cards can only move between rows, drag the card to a different row.
To "point" cards to other cards drag a card to another card/player icon.
To "add counters/make related card/SET power toughness/send to grave/duplicate card/send to exile/SET counters" double tap a card to open a context menu. set not add, we want an input option for numbers here for speed...

To "select multiple cards" button next to hand to get a "selection" tool. Single tap cards to select them the press the tool button again to confirm selection. All actions made (drag/double tap context menu etc) made to any of the "grouped" cards will be made to all of them.

Possibly allow users to make multiple groups of multiple cards, ie all creatures in 1 group, all lands in another etc...

DECK/GY/EXILE piles are shown somewhere (top of screen after phases!?)
To perform actions with them double tap the piles to open relevant context menus.
View/shuffle/scry/search etc...

Cards can also be dragged onto the "icon/image" showing the GY/EXILE/DECK piles from play to put them there.

Deck view = fullscreen, provide a search bar or make multiples of cards stack with like 4x in the corner.
autosort by card type and shuffle on close by default checked..
This will be cluttered as fuck tbh and it may be worth showing it portrait but thats probably bad design since the rest of the game is landscape?

HOW A SHORT GAME WOULD PLAY OUT

Both players load into the game from the generic lobby picker thing, cant be bothered designing this because its straightforward/no-one really cares/the desktop version should be fine tbh.

We get to deck selection, UI is basically 2 tabs
tab 1: load a deck and fix ur sideboard
tab 2: le chat tab.

Once sorted and both people are loaded they click start and the engine rolls for them and makes the highest roller the active player. Notify both players of the winner and show them their starting hands and give them a "keep" button and a "mulligan" button both should have obvious functionality.

When both players pick keep show the loser his scry 1 (optional since thats kind of a rule.. probably skip this bit!). And move to the main board screen...

now that we're ingame.....

I have my hand at the bottom of the screen, at the top of the screen are the phases, i tap the main phase, double tap a land from hand, it enters the resource zone. I tap once on my land to tap it and then double tap a Falkenrath Gorger in my hand to play it. Falkenrath gorger pops up in the middle of the screen, my opponant ignores it and it hits the field.

I tap the end phase button.

My opponant taps the untap button to take his turn. My opponant hates phases so he skips upkeep and goes straight to main. He realises he forgot to draw but its k and he drags the draw phase button from the top of the screen to his hand at the bottom of the screen to draw a card.

My opponant plays an island (the scoundrel) and taps the end turn phase button.

My untap phase button lights up and starts flashing and i tap it to take my turn.
I tap upkeep then tap draw phase, then drag draw phase into my hand to draw a card, i then double tap another mountain to play it from hand, then tap both mountains once to tap them and double tap an "infectious bloodlust" spell form my hand to play it, it pops up in the middle of the screen. My opponant taps the wait button increasing the delay from X seconds to XX seconds, taps his island and double taps a "swan song" from his hand to play it. I've got nothing i can do about that so i click the "pass" button (or wait). The game then shows the cards (left to right) Swan Song > Infection Bloodlust (with an arrow pointing from A to B!?) and waits for us to resolve the effects.

I double tap swan song and click "create related card" from the dropdown that appears and a 2/2 bird token appears on my field. I then drag "infectious bloodlust" into my graveyard stack/icon from the centre of the field. I click the combat phase button, the game advances to view 3 showing me my front line containing a "Falkenrath gorger" and a "bird" token, my opponants empty front line and an icon with his health and name on it, my opponant is also forced into this view.

I tap my falkenrath gorger once, then drag it onto the icon showing my opponant. It creates an arrow from it to him. My opponant taps a "minus" button next to his icon twice which reduces his health from 20 to 18.

I tap the Main 2 button to advance to main 2 i am taken back into view 1 (my field and hand), i realise im out of mana so i click end turn.

My opponant clicks the flashing "untap" button to take his turn, drags the draw card phase button to his hand, then clicks the chat tab on the far RIGHT of the screen and types something.

The chat button starts flashing for me so i tap it, hey look the game log showing what we did is here, ands my opponant has complained about been mana fucked. I press on the blank bar and type "gg ez" press send and then click the chat button which is now on the far LEFT of the screen to go back to the board game.

My opponant then presses the back button on his phone to open the main game menu and selects "surrender". The game ends.

Am i missing anything else!?

[Daenyth]

@DrKittens I recommend drawing it. Start with your text description and just mock out what a game state could look like. Maybe on paper with one-to-one sizes.

[DrKittens]

Detailed how a short game would play out, i'd draw it but its like 3am, probably come back to it later/when i dont have work in 6h lmao.. (probably later tonight..)

I think i was descriptive enough for functionality though!?

[arloft]

I know this is an old discussion, but I just saw it. I’m a UX / UI designer and would love to help out porting the visual design to mobile. I think this is a tough nut to crack but doable if we are willing to approach mobile as a legit branch of the app, as so much of the UI and UX would need redesigned. I dabble in code and actively work with a developer on my professional gig, so I’m accustomed to developer speak as well as prepping visual assets for the dev team.

Regarding installation to iOS devices, the App Store is out for obvious reasons. Also, I feel Cydia isn’t the best way either as it’s too reliant on a now unstable and irregular jailbreak pattern. However, I would suggest taking the approach used by GBA4iOS, using an enterprise install model that gets around the App Store.
http://www.gba4iosapp.com/download/
The source is linked on their site (resides on butbucket).

Long story short I guess the question I have is, are efforts toward a mobile port still active?

[Daenyth]

No. Mockups for some of the main interactions are a big next step

[arloft]

Is there any existing documentation or a collection of thoughts / proposals
about how to approach the limited screen size of a phone? I ask only so I
don’t needlessly retread anything that’s already been mentioned.

On Sun, Apr 1, 2018 at 3:52 PM Gavin Bisesi [e-mail]
wrote:

No. Mockups for some of the main interactions are a big next step

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-377812206,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACT6BqIpzGTgUAOLX6vXmUbSMvoFjxocks5tkTASgaJpZM4DZT7E
.

[Daenyth]

This page is about it

On Mon, Apr 2, 2018, 1:50 PM Aaron A [e-mail] wrote:

Is there any existing documentation or a collection of thoughts / proposals
about how to approach the limited screen size of a phone? I ask only so I
don’t needlessly retread anything that’s already been mentioned.

On Sun, Apr 1, 2018 at 3:52 PM Gavin Bisesi [e-mail]
wrote:

No. Mockups for some of the main interactions are a big next step

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-377812206
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ACT6BqIpzGTgUAOLX6vXmUbSMvoFjxocks5tkTASgaJpZM4DZT7E

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646#issuecomment-377992271,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5NEcvBdadzxtYVbSUZKns-U_LOFMGks5tkmTpgaJpZM4DZT7E
.

[Daenyth]

troll comments removed...

[arloft]

I’m still working on this, the main interactions. Trice doesn’t lend itself easily to a phone sized, no cursor, no hover kind of environment. Think I’m close to a basic gameplay field that works on a phone, hoping to put up some wireframes soon. What’s the preferred way to share those with developers? I can put them on google drive and link to the folder, allowing anyone to comment? Attaching them to this discussion seems like it would be tough to link discussion to their relative wires/mockups.

[Daenyth]

That sounds great! Drive is fine

[papb]

Is there anything I can help with? Ideally something that don't really need a lot of architecural understanding of cockatrice, some specific module?

[Rendroc]

Has any progress been made on this? I’d really like to be able to play on my iPad.

[ebbit1q]

Progress on this has been frozen for a year, this seems to be the only thing that was made: https://github.com/arloft/Mobitrice--cockatrice-mobile
Of course you can help, this is open source software after all, what we need is a port of the interface.

[arloft]

The github page linked above is mine, and it's mainly a UXUI concept (I
should add the concept images into this repo, I'm doing the design on
Figma.com) for how Cockatrice might function on a phone. It basically
involves new apps for iOS and Android, and a possible re-think of how the
server communicates game state to the client, but I'm trying to not suggest
changes to the server operation, and design solely within the confines of
the client app itself.
I have dropped the ball on furthering this design as I had some changes in
my personal which are now mostly settled. I should be able to pick this
project back up and get more design work to the dev team in the near future.

On Wed, Aug 21, 2019 at 3:11 AM ebbit1q [e-mail] wrote:

Progress on this has been frozen for a year, this seems to be the only
thing that was made:
https://github.com/arloft/Mobitrice--cockatrice-mobile
Of course you can help, this is open source software after all, what we
need is a port of the interface.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Cockatrice/Cockatrice/issues/646?email_source=notifications&email_token=AASPUBT3YCM5FHMAUCIHOT3QFUIFPA5CNFSM4A3FH3CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZFLOI#issuecomment-523392441,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASPUBQUBQVOFDVSA75TVT3QFUIFPANCNFSM4A3FH3CA
.

[tooomm]

For Cockatrice on Android check
https://github.com/Cockatrice/Cockatrice/wiki/Cockatrice-on-Android-(phone-tablet)

(Taken from https://github.com/Cockatrice/Cockatrice/issues/3899#issuecomment-601082273, thanks @vindicate7)

[ebbit1q]

Do note that this article is mainly a proof of concept rather than a recommendation.

[ctrlaltca]

Closing this issue. While it's been a nice discussion, it's really unrelated to the current development of Cockatrice.
If someone wants to work on this, we're willing to setup a new repository under the umbrella of the Cockatrice project and move all the discussion in there.