It is currently 19 Apr 2024, 20:05
   
Text Size

UI roadmap - discussion of recent and future changes

Post MTG Forge Related Programming Questions Here

Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins

Re: UI roadmap - discussion of recent and future changes

Postby Diogenes » 06 Jan 2014, 08:44

Thank you for making "randomize card art" the default behavior, I was going to request exactly that. :)

The default setting didn't only affect basic lands, it always displayed the most recent printing of every card that wasn't a basic land. Beyond the lack of variety, this actually maximized the chances of running into missing (or low-res, if the user had taken the time,) images. Cards with multiple supported images would revert to displaying a silhouette as soon they were reprinted in a new set. Very positive feedback from me on the change.

On the issue of the different basic lands being treated as unique cards, I'd love to see this happen someday and I do think it's worth it. I can think of three big benefits.

First, users would be able to create exactly the deck they want. People have preferences, and it would be nice to recreate paper decks exactly as they are in RL.

Second, it would help with theme decks, especially faction decks from Alara or Ravnica. It's just a detail, but it would be great for making flavorful gauntlets.

Third, it would make it possible to add Arena and MPS lands to Forge as sets, and get some use out of them. Unlike other promo land sets, rather than being a cohesive collection these were released as a set of five basics each year, in several cases as an "extra" land for that year's expansion. Some of these are absolutely gorgeous.

With Forge's focus on accuracy I'd be surprised if unique basics and collector numbers weren't implemented eventually. That said, I'm a big fan of the art of Magic and even I don't think this is a priority. In my opinion (granted, as a non-contributor) randomized art is enough for now (although I'll applaud and encourage from the sidelines if you want to take this on.)

Anyway, sorry for the long post. I'm not personally a fan of foils, but I'll understand if it becomes impossible to turn them off if the alternative is others not having them at all. Good luck with that project as well, and thanks for pushing this forward.
Diogenes
 
Posts: 201
Joined: 12 Jul 2012, 00:54
Has thanked: 39 times
Been thanked: 23 times

Re: UI roadmap - discussion of recent and future changes

Postby Agetian » 06 Jan 2014, 09:14

@ Diogenes: Thanks for your input on the question! Speaking of foils, I think it might be possible to implement a switch that allows you to decide whether you want foils or not when a deck is being generated or when a new quest is started (for instance, a switch in the Quest Mode window, and a switch or even a simple yes/no dialog ("Would you like to generate foils?") when starting a sealed deck tournament or a booster draft - that way it won't have to be a global option but it can be turned on/off individually when each quest, sealed deck, or booster draft is started. At least I hope it's going to be possible/viable...

- Agetian
Agetian
Programmer
 
Posts: 3471
Joined: 14 Mar 2011, 05:58
Has thanked: 676 times
Been thanked: 561 times

Re: UI roadmap - discussion of recent and future changes

Postby drdev » 06 Jan 2014, 16:22

Agetian, I'd be happy to help out with this effort. I actually had an idea to enhance the Workshop to allow you to pick the card art to use for any cards you want. Working off what you've done, I'd propose we allow the user to configure the default card art to use for specific cards, with one choice for each art, along with a choice to pick randomly and a choice to use the most recent printing. If the setting isn't specified, it would fall back to a global preference of whether to use a random or the most recent printing (only if you had the image though). I could also add an additional setting to always use the foil version of a specific card.

In addition, I could add support to the Deck Editor for overriding the art and specifying foils for each card in the deck, though I'll probably wait on that until after I implement card view.

How does all that sound? I'm not sure when I'll get to any of this, as I still want to shift gears back to designing the Android version at some point, but I'll definitely see what I can do.

Thanks.
-Dan
drdev
Programmer
 
Posts: 1958
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 565 times

Re: UI roadmap - discussion of recent and future changes

Postby Agetian » 06 Jan 2014, 16:31

@ drdev: These sound like very interesting options indeed! The deck editor should already be able to load and display foil cards from deck files (foils are marked with an asterisk - e.g. Fireball* if I recall correctly), but there's no way to specify in the deck editor that you want a foil card or a non-foil card (or visually distinguish between foil and non-foil cards in the card list). Different card art would be very interesting to implement (such that it's possible to purposefully add lands with different art in whatever amounts you want). And your suggestions for the workshop sound very interesting, too! Feel free to get to it whenever you feel it may fit in your list of priorities. I'd be happy to join in on this effort as well should the time permit me to do so!

- Agetian
Agetian
Programmer
 
Posts: 3471
Joined: 14 Mar 2011, 05:58
Has thanked: 676 times
Been thanked: 561 times

Re: UI roadmap - discussion of recent and future changes

Postby Max mtg » 06 Jan 2014, 16:46

Again, I got caught in a diferent country with a small tablet to expess my ideas, so won't be able to type a lot of text.

We do support the true art indices for cards since the inception of PaperCard (formerly CardPrinted). The problem is deckeditors usually save decks packed up with lands with the first picture, imported decks also come with a single picture of all lands.

Match should act straightly in this regard - the art indices and foil flags from the deck received shall be used to materialize ingame cards. The deck is obtained from the RegisteredPlayer instance, which is created by a factory method or directtly constructed (don't remember exactly) from a deck. If the gui app applies the desired changes (changes art indicesfor a copied deck) before the reg.player is built, we reach the target.
Last edited by Max mtg on 06 Jan 2014, 16:50, edited 1 time in total.
Single class for single responsibility.
Max mtg
Programmer
 
Posts: 1997
Joined: 02 Jul 2011, 14:26
Has thanked: 173 times
Been thanked: 334 times

Re: UI roadmap - discussion of recent and future changes

Postby Max mtg » 06 Jan 2014, 16:49

@drdev, sounds great as long as no core.* or game.* modules are changed. All manipulations on a deck are supposed to be performed before you create the RegisteredPlayer instance.
Single class for single responsibility.
Max mtg
Programmer
 
Posts: 1997
Joined: 02 Jul 2011, 14:26
Has thanked: 173 times
Been thanked: 334 times

Re: UI roadmap - discussion of recent and future changes

Postby Agetian » 06 Jan 2014, 16:52

Thanks for the explanations, Max! I wasn't aware that art indices are now supported in deck files, that's a very interesting and useful bit of information! In that case, I believe we can change the "randomize card art" functionality as soon as deck editors are implemented in a way that can save and load the card art index information properly - it'll probably be necessary to change it in a way that randomization is not applied if the card art information is present in the deck and loaded from it, and there should be randomization if there was no information present in the deck. Ditto the foils and the random foiling.

- Agetian
Agetian
Programmer
 
Posts: 3471
Joined: 14 Mar 2011, 05:58
Has thanked: 676 times
Been thanked: 561 times

Re: UI roadmap - discussion of recent and future changes

Postby Diogenes » 13 Jan 2014, 17:25

Hey drdev, it's nice to see the deck manager used for draft/sealed! I didn't know of the deck manager until today, as my editor preferences were ancient and I didn't have the "All Decks" tab, so some of this might apply more towards the manager itself than to its new implementation. Also, I had written a long (and lovely, I might say,) post about all this... and the forum ate it. Sorry if I now sound a bit rushed. :)

The first thing I noticed is that the color-detection doesn't currently work well with limited decks, as all sealed decks will show up as five-color and many draft decks will have picked up off-color cards. Either ignoring or dimming sideboard-only colors for limited decks would be great.

You said that the columns were a work in progress, and I don't know if you're going to touch the deck manager code itself, but format legality is unnecessary for limited decks. In its place, it would be handy to see what sets were drafted/opened (and if that were done, it would then become useful to be able to rename decks from within the editor.)

I'm also excited about the ability to sort decks, but at the moment the sortable characteristics aren't what I would use for constructed decks (legality for previous standard environments,) and the deck manager isn't able to detect decks in sub-folders. Is the plan to replace the constructed deck selector with the deck manager?

Sorry for sounding clipped, your work is a definite upgrade, thank you! Thanks also to whomever made the deck manager!
Diogenes
 
Posts: 201
Joined: 12 Jul 2012, 00:54
Has thanked: 39 times
Been thanked: 23 times

Re: UI roadmap - discussion of recent and future changes

Postby drdev » 13 Jan 2014, 18:03

Diogenes wrote:Hey drdev, it's nice to see the deck manager used for draft/sealed! I didn't know of the deck manager until today, as my editor preferences were ancient and I didn't have the "All Decks" tab, so some of this might apply more towards the manager itself than to its new implementation. Also, I had written a long (and lovely, I might say,) post about all this... and the forum ate it. Sorry if I now sound a bit rushed. :)

The first thing I noticed is that the color-detection doesn't currently work well with limited decks, as all sealed decks will show up as five-color and many draft decks will have picked up off-color cards. Either ignoring or dimming sideboard-only colors for limited decks would be great.

You said that the columns were a work in progress, and I don't know if you're going to touch the deck manager code itself, but format legality is unnecessary for limited decks. In its place, it would be handy to see what sets were drafted/opened (and if that were done, it would then become useful to be able to rename decks from within the editor.)

I'm also excited about the ability to sort decks, but at the moment the sortable characteristics aren't what I would use for constructed decks (legality for previous standard environments,) and the deck manager isn't able to detect decks in sub-folders. Is the plan to replace the constructed deck selector with the deck manager?

Sorry for sounding clipped, your work is a definite upgrade, thank you! Thanks also to whomever made the deck manager!
I made the DeckManager as part of this project, though I built it off the ItemManager control that I've been perfecting for deck building for some time now. Before yesterday's commit, the DeckLister control was used instead, which was just a makeshift table displaying decks without the color or format columns, or any sort/filter ability. Thank you for the compliments at any rate.

I can certainly tweak what columns display in Limited deck managers, which will be much easier after this latest refactoring. I can also easily update the color determination logic to ignore sideboard for limited decks.

If you want to be able to sort on previous standard environments, you could define custom formats for them. The Deck Manager is set up to iterate through all loaded formats and list any formats for each deck that it meets the requirements of. You can also add a Sets filter using the Filter button to filter out decks that use cards outside a given collection of sets/block. You can also filter by Format and Quest Worlds.

As for subfolders, I was already planning to add support for collapsible groups, which I could use to support expanding and collapsing subfolders within the table. I could then make it so, when naming the deck, if you specify a path, it creates the subfolder for you (such as "Alara Block\3 Color Control"). How does that sound?

Finally, I do plan to make the DeckManager part of the new Constructed deck selector that's being worked on, though I'm not sure when that will be ready as it's being started up by moomarc at the moment. He could comment more on it.

Thanks.
-Dan
drdev
Programmer
 
Posts: 1958
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 565 times

Re: UI roadmap - discussion of recent and future changes

Postby Diogenes » 13 Jan 2014, 18:51

Hey Dan, thanks for the quick reply.

drdev wrote:If you want to be able to sort on previous standard environments, you could define custom formats for them. The Deck Manager is set up to iterate through all loaded formats and list any formats for each deck that it meets the requirements of.
I didn't realize I could just edit formats.txt. You're right, that's an easy way to do it. I'll post my result once the DeckManager is in place for constructed, in case anyone else is interested. I just have to figure out the proper level of granularity (pre-and-post bannings, by set or by block, etc.)

drdev wrote:As for subfolders, I was already planning to add support for collapsible groups, which I could use to support expanding and collapsing subfolders within the table. I could then make it so, when naming the deck, if you specify a path, it creates the subfolder for you (such as "Alara Block\3 Color Control"). How does that sound?
That sounds perfect. If I sounded hesitant it's because that's exactly how I've organized my decks\constructed folder (although it does go several folders deep,) and I didn't know if it would be possible to maintain the current structure.

drdev wrote:Finally, I do plan to make the DeckManager part of the new Constructed deck selector that's being worked on, though I'm not sure when that will be ready as it's being started up by moomarc at the moment. He could comment more on it.
I'm looking forward to it!

Anyway, sorry if I sounded snarky or critical. I assumed the DeckManager had been in place longer, as I had to delete my preferences to get it to show up in the editor. Thanks again!
Diogenes
 
Posts: 201
Joined: 12 Jul 2012, 00:54
Has thanked: 39 times
Been thanked: 23 times

Re: UI roadmap - discussion of recent and future changes

Postby drdev » 13 Jan 2014, 19:33

Diogenes wrote:...
Anyway, sorry if I sounded snarky or critical. I assumed the DeckManager had been in place longer, as I had to delete my preferences to get it to show up in the editor. Thanks again!
Don't worry, it didn't come off that way to me. To clarify, the All Decks tab has been around for as long as I've been working on Forge, it just used to use DeckLister like Draft/Sealed/Quest Decks on the home screen.

The reason you haven't had it for some time is it has a nasty habit of being lost the minute you go to another Deck Editor type screen that hides it by default (such as Spell Shop) and make any change to your layout while on that screen. I hope to fix that bug this release by making each Deck Editor screen have its own layout file.
drdev
Programmer
 
Posts: 1958
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 565 times

Re: UI roadmap - discussion of recent and future changes

Postby moomarc » 13 Jan 2014, 21:02

drdev wrote:Finally, I do plan to make the DeckManager part of the new Constructed deck selector that's being worked on, though I'm not sure when that will be ready as it's being started up by moomarc at the moment. He could comment more on it.
First progress report available with screen shot and patch in the new constructed match setup screen thread.
-Marc
User avatar
moomarc
Pixel Commander
 
Posts: 2091
Joined: 04 Jun 2010, 15:22
Location: Johannesburg, South Africa
Has thanked: 371 times
Been thanked: 372 times

Re: UI roadmap - discussion of recent and future changes

Postby Diogenes » 20 Jan 2014, 08:45

This post is a bit long, sorry about that.

There's been discussion recently in the feature requests thread about supporting historical formats (a question I've raised as well,) and I've been thinking about the concerns raised in response. I think I've found an elegant solution that would please everybody, but since it's so connected to the new constructed lobby and deck manager I don't want to post in the general forum.

Just to clarify, I'm not asking for this, I just think it's an idea worth proposing, no strings attached.

Currently there are five categories for decks in the drop down list ("Custom User Decks", "Preconstructed Decks", "Quest Opponent Decks", etc.) What if instead we had the following categories in the drop-down list:


All User Decks
Standard
Modern
Legacy
Vintage
Commander
Random Color Decks
Random Theme Decks
Preconstructed Decks
Quest Opponent Decks

There's room for all ten even at the minimum supported window size. For formats which have had multiple iterations, a second drop down list containing all of those in reverse chronological order would appear beneath the first. If a user picked "Standard", the following dropdown would contain:

Theros
M14
Dragon's Maze
etc.

The deck list would then simply populate with all decks that match the chosen settings. Anyway, since this is being discussed in another thread I'll quote the points to which I can respond in order.

friarsol wrote:That seems like a lot of overhead, and a lot of information we don't really have.
The information is out there, and it's something I could actually contribute. Rather than just one formats.txt, we could keep several lists (standard.txt, modern.txt, etc.) in res\blockdata or a new subfolder.

drdev wrote:Can't people just update formats.txt with such format definitions? Eventually it would be nice to add support for creating your own custom formats from a GUI screen, but in the meantime modifying the text file in Notepad or some such editor should work.
This is possible, but it has several downsides. The smallest is that the user would have to overwrite the file every time they update Forge. Maintaining a custom formats.txt would also be a chore, as it could grow unreasonably large. The most noticeable difficulty is that this method requires using a filter in the deck manager, and the amount of entries in "formats" would be quite long and include all iterations of all formats at once, which would be hard to navigate from a context menu.

Xitax wrote:If formats.txt can be modified with any custom format, then surely someone will end up taking the trouble to define all the formats by year. The problem is, that say a standard deck from 2004 would show up as "standard 2004", but would also show up in multiple other extended or legacy or vintage years uselessly.
Actually, I'm willing to do that myself.

It's not useless if you're specifically filtering for only that format/year (you're getting exactly what you want,) it's only really troublesome if you're using the format column in the deck manager to sort rather than filter, as each deck will only appear in its earliest legal format and you'll still have your entire catalog to scroll through (and the column is not wide enough to show all formats in which a deck might be legal.)

Anyway, that's what I've come up with. I can't provide the code, but I can provide and maintain the lists.
Diogenes
 
Posts: 201
Joined: 12 Jul 2012, 00:54
Has thanked: 39 times
Been thanked: 23 times

Re: UI roadmap - discussion of recent and future changes

Postby drdev » 20 Jan 2014, 13:51

Rather than merge formats into the deck type combo box, I'd rather offer a format combo box filter that appears by default at the top of the deck manager (above the color filters). That way it's also available in the All Decks pane of the Deck Editor.

This would also allow removing the Format column by default, which will leave room for sub folder path when Max finishes his DeckProxy changes.
drdev
Programmer
 
Posts: 1958
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 565 times

Re: UI roadmap - discussion of recent and future changes

Postby Xitax » 21 Jan 2014, 01:38

What I meant was that an old standard deck is going to show up as being viable for extended, legacy, and maybe vintage of multiple years following, and that information is not useful since it's really a standard deck from ____ and not meant for use in another format where it wouldn't compete anyway. I think it's generally true that any one deck was most likely built for one single format therefore one format definition per deck seems reasonable.

One way to fix this is if a deck has a smaller definition, not to use a larger one. E.g. if it's a standard deck, don't define it in any extended etc... and if it's a extended don't define it in legacy etc... etc. I'd propose one deck format definition per deck, earliest date and smallest format where it fits. If that isn't enough you might as well just start putting tags in decks for format or writer's column, etc. and leave it to the person putting it together. Of course, with that you won't get the nice homogeneity of a good standardized definition set.

Also I think that cards defined as from MMA are going to be a pain as they are only legal if the original printings are legal so no set-wide definition for MMA is going to be possible. ... Ugh, this is going to be true of all sets that aren't core or advanced!
Xitax
 
Posts: 918
Joined: 16 May 2010, 17:19
Has thanked: 183 times
Been thanked: 133 times

PreviousNext

Return to Developer's Corner

Who is online

Users browsing this forum: No registered users and 102 guests


Who is online

In total there are 102 users online :: 0 registered, 0 hidden and 102 guests (based on users active over the past 10 minutes)
Most users ever online was 4143 on 23 Jan 2024, 08:21

Users browsing this forum: No registered users and 102 guests

Login Form