Forge Android App

[drdev]

So are you suggesting we create a symbolic link that pulls the forge-gui/res/ folder into the assets folder of forge-m-gui? Will that work when running the app on a phone or when doing a release build to install on the phone?

[drdev]

So I finally decided to take a short break from the desktop application and attempt to get the projects setup for a mobile Forge app. After looking into it, I decided to use libgdx, as its documentation is really good and it will allow making an IOS app in the future without too much trouble. It also allows developing using a desktop window for testing and debugging without the need for a separate emulator, which should speed up development and testing.

I've created 3 new modules for this: forge-m-base, forge-m-desktop, and forge-m-android ("m" for mobile). Most of the gui logic for the mobile game will live in forge-m-base, which will eventually reference the same core projects as forge-gui.

Since I'd need a Mac to work on an IOS app, I didn't create a forge-m-ios project at this time, though somebody with a Mac can certainly feel free to attempt it after looking through the libgdx wiki. I'm not sure how users would be able to install an IOS version without going through the App Store, but I suppose we can always figure that out later.

One thing quickly became apparent as a concern when starting this up, which is how we're going to share assets (everything in forge-gui/res/) between forge-gui and forge-m-base. In order for the Android app to work, all of that needs to live in forge-m-android/assets/. I really don't want us to have to maintain two separate copies of all the images and card script files. Since forge-m-desktop was able to be set up to link in the assets folder from forge-m-android, would it be possible to do the same for forge-gui? Or does anyone know a trick that will allow pulling the files in forge-gui/res/ into forge-m-android/assets/ automatically?

An issue related to that is that libgdx requires all images have width and height that are powers of 2 (like 256x256), which isn't the case for most if not all of our images. Once loaded we can use what's called a TextureRegion to render only what part of each image we need (utilizing the SkinProp coordinates), but the full Texture needs to have width and height that are powers of 2. If we share assets between the two as I'd like, any objection to just increasing the width and height of each image to the next power of 2 and letting that all be empty alpha space? Or does anyone have a better idea?

Another thing I'm not sure of is how to deal with Maven integration and eventually handling snapshot and beta release builds. There is some documentation on the wiki, but if somebody more familiar with Maven could help out, that would be much appreciated.

Thanks.
-Dan

Bumping this since I have received any feedback on my questions regarding Maven and image resizing, and I haven't heard back about symbolically linking assets. Any input is appreciated.

[Chris H.]

An IOS version would likely require that the iPhone to be jail broken.

Dave is our resident Mac and Maven expert but he tends to get very busy with other things but he does drop by on occasion.

[moomarc]

I have no idea about the maven side or anything else you asked about except for the image assets. That change means all 13000+ images need to be reprocessed and uploaded. Then every single user has to download them again, or, if they use HQ images, they will need to process all their own card images. A lot of our users won't know how to do that, especially when it comes to working with such large batches. Is there no other way to do this?

[Agetian]

I have no idea about the maven side or anything else you asked about except for the image assets. That change means all 13000+ images need to be reprocessed and uploaded. Then every single user has to download them again, or, if they use HQ images, they will need to process all their own card images. A lot of our users won't know how to do that, especially when it comes to working with such large batches. Is there no other way to do this?

I agree. Not only will this be a one-time nightmare for the end users (especially the ones with HQ or otherwise customized card images), it will also become a permanent issue that comes up every time CCGHQ releases their scans or a new set is available for download from MTG Gatherer, because every single version of every single set will have to be hand-adapted for Forge (*and* the process will be unique compared to every single other Magic app out there that is able to use images). The only way I see this potentially working is if the desktop version of Forge is equipped with an automatic conversion tool that will automatically detect and convert all pictures that need converting into the format the game recognizes without any manual labor on the user's behalf.

Another way to go with this is not do anything with the images themselves (which would definitely be preferable) but automate the necessary permutations inside the mobile Forge code base (so that if mobile Forge detects that a picture is not of the right size it automatically adapts it for its needs by placing it on a bigger canvas and filling the relevant surrounding area with the alpha transparency). Not sure if this might be too much computational work for a mobile app though (it might as well be). But if so, we still need to discuss other options - something less radical should be suggested if at all possible.

- Agetian

[drdev]

I think there's some confusion. When I was referring to images, I meant images for the different skins (files in forge-gui\res\). Card images aren't stored in assets, rather they are downloaded separate and stored in AppData. The concern here is avoiding having to maintain two copies of all the skin and script files.

As I see it, downloading card images to the mobile app will just need to be done separately from within the app to the equivalent of AppData for the mobile OS. As an alternative, we could also consider offering a tool to export images and certain preferences from the desktop to the mobile app if a user has both.

[Max mtg]

So are you suggesting we create a symbolic link that pulls the forge-gui/res/ folder into the assets folder of forge-m-gui?

Yes, for cardscripts, editions and blocks at least.

Will that work when running the app on a phone or when doing a release build to install on the phone?

No minor idea.

[moomarc]

I think there's some confusion. When I was referring to images, I meant images for the different skins (files in forge-gui\res\). Card images aren't stored in assets, rather they are downloaded separate and stored in AppData. The concern here is avoiding having to maintain two copies of all the skin and script files.

Thanks for the clarification Dan. I'm definitely fine with the skin sprites having extra alpha added. We're running low on room for new icons anyway

Edit:
So perhaps 1024 x 1024px? That's the closest power that fits everything. The splash sprite would also have to go on a 1024 sheet if we want to avoid changing coordinates and having to rework the layout. Moving the four colour swatches next to each other might allow us to use a 512 sheet instead though.

Edit2:
The biggest issue will be the texture files. They're built to tile and a square won't always work for the intended background. Can you just crop the blank are of an image to use the actual art area?

[Max mtg]

Have just found out that magic online client stores its pictures for card backgrounds in 256*256 PNG images.
And the crops they use to fill card artwork have a size of 256*188 pixels. Will mobile application benefit from using crops instead of full cards?

[Agetian]

I think there's some confusion. When I was referring to images, I meant images for the different skins (files in forge-gui\res\). Card images aren't stored in assets, rather they are downloaded separate and stored in AppData. The concern here is avoiding having to maintain two copies of all the skin and script files.

Thanks for the clarification Dan. I'm definitely fine with the skin sprites having extra alpha added. We're running low on room for new icons anyway

Yeah, that makes perfect sense to me too now and I'm absolutely OK with it!

- Agetian

[drdev]

While we're on the subject of card images, I suppose it's as good a time as any to bring up a potentially controversial topic. Due to the much more limited screen real-estate, I'm not sure it's going to work well to display full card images. Doing so would require potentially odd looking overlays to make card information visible and a card details pane separate from the image that there really isn't room for. There's also the concern of storage and memory usage on a mobile device, which even for the LQ images is quite significant.

What I'd like to propose is that we do something like MTGO does, which is to construct card images from a card frame texture, the card art, and properly positioned text and icon overlays. Doing so will allow us to display abbreviations and reduced information at smaller sizes and control font size rather than relying on font scaling well via image scaling, as well as display card details when zoomed in right inside the card's rules box instead of separate. In addition to potentially improving card readability at different sizes, this will also save a lot of storage space and memory usage in game over having full card pics stored on the hard drive or cached in memory.

My hope is that we can make the (at least zoomed in) card image look as good or better than the LQ scans. MTGO has struggled with that at times, but I plan to do better. Having the images look like real cards is very important to making this a quality game.

Now I realize even if people are ok with this, we'd need to be able to download just the card art and frame textures instead of full card pics. Do any of our sources offer such files? Ideally we could even package multiple card arts or frame textures in a single file (perhaps one file per set in the case of card art) and piece them out like we do for skins to save on storage and file access, particularly if we have the "powers of 2" restriction in place.

It's also worth noting if we go this route, we would be one step closer to being able to create pics for custom cards, and we could potentially utilize the new logic to improve the fallback pic for cards that you haven't downloaded the LQ or HQ pic for to actually be readable.

I'm very curious to hear people's thoughts on this. Please share.

Thanks.
-Dan

[Max mtg]

CCGHQ is known to offer crops along with full scans of cards

I have reversed MTGO client's card database (the old clients' one, known as v3) - can give you an application (with source codes of course, yet it's written in C#) So you'll be able to use their resources if we find no better source. Their database is nevertheless useful because it holds some extra data on each card, such as watermark id, artist's name, kinda collector's number, and some other bits whose purpose remains unknown for me.

[friarsol]

I think it would be a lot of work to combine each set into a single image though (of course, moomarc is probably the best judge of that on our team). I don't think card frames come separate but possibly they do, I've at least never noticed it as a release point when they mention things. Would you be going for full authentic (old cards use old frames, etc), or just close enough authentic?

I don't think I'm a fan of this idea for using it with desktop Forge though (I'd really need to see it in action before I could be fine with it), but for Mobile it certainly makes sense, since there is more space/memory concerns. Couldn't you just have a Crop on the battlefield, and long-clicking would popup a consolidated Image/CardDetailView of that card? What else would be needed to get the current state of a card?

[drdev]

The application of this idea for desktop Forge was only for handling generating pics for custom cards and for generating a pic for cards that you haven't download pics for. I never meant for us to stop using full card pics for desktop Forge.

For frames, it could just be a simple matter of photoshopping some card pics to remove all text and icons, then storing them in a few files such that they can be indexed by card color and set. That way you could have cards use the frame that best corresponds to the frame they were printed on, or theoritically have all cards use the same frame type (such as post 8th edition frames). We could even support creating custom frames someday.

It also just occurred to me that we'd need a file containing all the set icons for each rarity. Does that exist somewhere?

As for just doing cropping on the battlefield, that wouldn't help with overlay readability or storage/memory. But I can always start with using full card LQ images and see how big an issue it really is before we go another route. Maybe I can find space for card details on the Zoom view I'm planning.

[friarsol]

As for just doing cropping on the battlefield, that wouldn't help with overlay readability or storage/memory. But I can always start with using full card LQ images and see how big an issue it really is before we go another route. Maybe I can find space for card details on the Zoom view I'm planning.

I more meant like physical display space, on top of the memory gained from using smaller images in other aspects of the game.