Collectible Card Game Headquarters

Many thanks, Chris! I'll get my patches checked in when the privileges sync.

Did Doublestrike have a TODO list I can reference to see if I can pick up anything?

Here are some additional ideas I had (well, at least the ones I think I can handle at this stage):

Deck editor

• better default column widths for tables
• save deck editor filter settings between program invocations (perhaps save the settings per deck)
• bold NEW cards until they are selected and viewed (NEW column remains, just unbolded after view)
• cards are labeled NEW compared to last time deck was edited, not just for the last booster pack acquired; implementation options:
  
  1. maintain NEW list per deck
     
  2. cards have a lastAcquired timestamp, decks have lastModified, compare at display time
     
  (I suspect (2) will be cleaner, but needs discussion)
• combine filter widgets with stats header widgets
• some way to get cards directly from catalog into the deck sidebar

Match

• when '>'ing an item in the simultaneous spell abilities dialog, autofocus on the next ability instead of leaving focus on the button so the relevant card appears in the card viewer
• keep focus on the ok button in the match window so <enter> always works to click the ok button
• when tapping mana, reevaluate cursor hover so multiple lands can be tapped without moving the mouse
• allow You Win quest duel screen to scroll when the random rare widget pushes the boost pack widget off the bottom of the screen

I haven't read through all the forum topics, but have there been any popular requests for the UI that I should consider? I am trying to keep the changes relatively simple until I have a better understanding of the codebase, though. Also, considering my newbieness, would it be alright if I did my work in a side branch (sync'd regularly from trunk, of course) and requested periodic code reviews?

edit: it seems the permissions have synched already, so I got the patches checked in. Should I update CHANGES.txt, or is that done automatically? Also, could someone close issues 653, 657, and 652 on cardforge?

myk wrote:Did Doublestrike have a TODO list I can reference to see if I can pick up anything?

 
I seem to remember finding some notes/todos located in the contents of the comments that are found in the UI classes. He did the best that he could in developing a basic UI. There are a number of areas where some tweaks and improvements could be made to the UI.

You have discovered for yourself some of the deck editor improvements that Doublestrike and others wanted to see implemented. The Properties still look a little too busy with both the icon and the checkbox visible.

Ideally, the checkboxes would be replaced with the icon which would darken/lighten as the icon based checkbox became checked or unchecked. We had this feature in the old deck editor prior to the new UI and this feature is missed by the old timers.

It might be possible to improve the layout of the Card Text filter. Some people might have a good idea about how to improve this portion. I remember someone stating that searching for Text containing "First Strike" would return all cards containing either of the two words or both words.

Oh, Doublestrike did some work to the view titles in an effort to provide an interesting effect but this panel is drawn offscreen. This may be a difficult one to fix.

myk wrote:I haven't read through all the forum topics, but have there been any popular requests for the UI that I should consider? I am trying to keep the changes relatively simple until I have a better understanding of the codebase, though. Also, considering my newbieness, would it be alright if I did my work in a side branch (sync'd regularly from trunk, of course) and requested periodic code reviews?

edit: it seems the permissions have synched already, so I got the patches checked in. Should I update CHANGES.txt, or is that done automatically?

 
You can set up a branch if you want to. I can not promise that devs will find the time to do periodic code reviews. We do tend to discuss our end of the project at times and i do try to encourage this type of conversation.

Doublestrike set up a couple of topics that were used to discuss his UI work, you may find a few good ideas lurking in these topics.

I add the commit logs to the changes.txt file right before I release a beta or a snapshot and I try to remember to add a few interesting fluff pieces that follow the text " cards in total." near the start of this file.

All of the devs are welcome to add in some easy to read info to this text file as it gives the user base something to read that is not too technical.

myk wrote:allow You Win quest duel screen to scroll when the random rare widget pushes the boost pack widget off the bottom of the screen

Also, could someone close issues 653, 657, and 652 on cardforge?

I'm pretty sure the duel screen does scroll, I'm always able to look at all of the Quest stuff I win, even if I have random extra things that I won.

I can close those bugs.

Welcome to the group, myk!

I sometimes make code review pointing out at some obviously bad code (like mixed up model fields and some GUI invocations in a single class) but cannot handle 100% of commits anyway.

You told about per-deck sorting options in editor - It's OK as long as no extra extra fields (to hold that options) are added into the deck class and files backing decks.


As for pets - it would be nice to make them part of quest decks, as it was suggested long ago. Yet, that would mean a notable piece work (make a subclass from Deck to add pet slots, make changes to Quest deck editor, make sure old saves still work)

Chris H. wrote:I seem to remember finding some notes/todos located in the contents of the comments that are found in the UI classes. He did the best that he could in developing a basic UI.

From what I've seen, Doublestrike has done some great stuff here. I will do my best to live up to his excellent example.

Doublestrike set up a couple of topics that were used to discuss his UI work, you may find a few good ideas lurking in these topics.

ok, I spent some time reading through those topics, and did a few searches through Doublestrike's posts. I'm getting a better idea of his vision.

friarsol wrote:

myk wrote:allow You Win quest duel screen to scroll when the random rare widget pushes the boost pack widget off the bottom of the screen

I'm pretty sure the duel screen does scroll, I'm always able to look at all of the Quest stuff I win, even if I have random extra things that I won.

Ah, I found the issue -- it depends on where the mouse cursor is when you scroll. If the mouse cursor is in the center, where the card itself is displayed, scrolling works fine. If the mouse cursor is a bit to the left, near where the list boxes are (but not hovering over the list box itself, of course), it doesn't seem to scroll.

Max mtg wrote:Welcome to the group, myk!

Thanks! I'm excited to join!

You told about per-deck sorting options in editor - It's OK as long as no extra extra fields (to hold that options) are added into the deck class and files backing decks.

Why this restriction? Of course it could be implemented (and stored) separately and associated with the decks with a map, but, just so I know, what is the concern about combining the data?

As for what I've been working on, I've started on moving the filters to the stats panel above the cards in the deck editor. This will probably take a while, so I'll do the work in a branch to avoid messing up trunk with interim commits.

So far, I've been able to use the existing functionality in FLabel to turn the stats labels into toggle buttons that control the filters, thus getting twice the functionality in the same amount of space. I have some ideas about moving the other filter controls up there too, and providing a mechanism that will allow quest world-based restrictions to be enforced, but let me do a mock-up and do some research before I spec it out in detail.

myk wrote:

You told about per-deck sorting options in editor - It's OK as long as no extra extra fields (to hold that options) are added into the deck class and files backing decks.

Why this restriction? Of course it could be implemented (and stored) separately and associated with the decks with a map, but, just so I know, what is the concern about combining the data?

As for what I've been working on, I've started on moving the filters to the stats panel above the cards in the deck editor. This will probably take a while, so I'll do the work in a branch to avoid messing up trunk with interim commits.

The view options MUST be stored aside from decks. A deck as an entity is a collection of cards, nothing more. Should you put anything else inside - that breaks the design.
Adding view options to DECK makes it dependent on current deck editor implementation. If someone has to modify deck editor he'll eventually find all existing decks incompatible with his new format and in need for conversion. That excess references make the code fragile, so that a small change in one system might ruin a couple of other dependants. It also affects interchangeability of modules. We cannot use a different AI now, although there came people willing to implement their own ai or some deck-specific ai hints. This is what happens when Single-responsibility principle gets voilated. Consider SpellAbility class that besides of resolving the very ability holds a bunch of ai methods, which already cannot be moved away (to develop just a different ai)
That restriction is in fact the 'S' out of SOLID design principles. http://codebetter.com/davelaribee/2008/ ... imme-an-s/

And about Doublestrike - he has finished a big job, but that implementation is far from being an excellent example. He made most of his classes singletons, that is an only instance of each may exist, but - what is worse - the instance of every class became a global variable.
The new deck editor by Doublestrike became more puzzled due to tabs, so that 'import deck' feature got hidden under a tab, newly created decks do not get into in-memory decks storage (and for this reason aren't displayed in UI), and live filter implemented in previous editor is no longer filtering cards as you type.

So, if you would love find some great examples, use world leading programmers' experience - people working at Google, Microsoft and so on. Their articles tell a lot about good and bad design. For instance, this one is about global variables - https://sites.google.com/site/michaelsa ... singletons
Yes, Forge actually has TONS of poorly designed classes, but that does not mean we have to develop new code in the same way.

myk wrote:From what I've seen, Doublestrike has done some great stuff here. I will do my best to live up to his excellent example.

ok, I spent some time reading through those topics, and did a few searches through Doublestrike's posts. I'm getting a better idea of his vision.

 
I am somewhat of a historian.

Rares as the original developer did the original work. His work was for the most part an early alpha stage as he attempted to add in the basic functionality. He rewrote several areas of code when he saw at the need and that part of the code became a latter alpha stage.

Various people over the last several years have added in new alpha stage code while others have improved certain pre-existing areas of the code base and these pre-existing areas advanced to a beta stage.

The Forge project moves forward. We appreciate everyone's efforts. Granted, some of the newer code is exploritory in nature and should not be considered as the best.

Forge has gone through a series of stages as people have stepped in and have attempted to move the project forward.

I saw your deckeditor branch, Myk. Best of luck! I was about to work on Variant additions to the deck editor but I havn't done much more than think about it. I'll wait for your work before starting in earnest, I've got other projects in the meantime.

Ok, let me report my progress so far:

I have a mockup of the UI elements and gave them some interactive functionality:
This is the new header area. The stats labels all act as toggle buttons now and control the filters. Clicking on the Total Cards stat in the upper left will toggle all filters on or off.
Clicking the "Filter by" button will bring up a menu of possible restrictions (explained in the third screenshot). Typing in the textbox will filter by string (updating as you type), restricted to Name, Type, and/or Text, depending on the toggle states of the three buttons to the left.


Here is an example of toggling some stats filters off. Now only red and green creatures are being allowed through the filter. The numbers in the labels are updated exactly as they were before.


This is the Add restriction menu. The "Current search string" and "Inverse of current search string" become enabled when there is something in the string filter textbox. Restricting by set brings up a dialog full of checkboxes so multiple sets can be selected. The others will be explained more in the next post.

This shows the result of adding a restriction. A description of the restriction appears below the search bar, and if the full description is too long to fit there, the full description will appear in a tooltip. You can remove the restriction by clicking the little 'x' in the upper right of the restriction box.


Just typing in the text box will apply a string filter. Here we're filtering by 'flying'


By stacking positive and negative string filters, we can whittle down the list to what we want. Here we're filtering by flying, but not human. The sequence to accomplish this was:

1. type human in the texbox
2. hit ctrl-shift-enter (cmd-shift-enter on osx) -- of course you could also do this by selecting the "Inverse of current search string" menu item
3. type flying

Here's a CMC range filter. The fields are editable even after the restriction is applied. The textboxes are actually spinners, so up/down arrow keys will work as well as entering numbers directly. There are similar filters for power and toughness.


World restrictions can be applied as a filter as well. This will show cards that are valid in both Shandalar and Jamuraa.


Thoughts? Suggestions? The code is currently just the UI elements, and currently don't actually do anything other than appear and disappear. If this looks good, though, I'll start on hooking up the plumbing and moving the code from its current jumble in the view to appropriate places in the controller.

myk wrote:[*]hit ctrl-shift-enter (cmd-shift-enter on osx) -- of course you could also do this by selecting the "Inverse of current search string" menu item

I think it would be better to have a button for opposite logic, similar to the other highlight buttons, labeled "not"

Xitax wrote:

myk wrote:[*]hit ctrl-shift-enter (cmd-shift-enter on osx) -- of course you could also do this by selecting the "Inverse of current search string" menu item

I think it would be better to have a button for opposite logic, similar to the other highlight buttons, labeled "not"

I had something like that in my original design, but the UI started to get cluttered. Let me toss some screenshots together with a couple options and tell me what you think.

with NOT toggle:



with mode combobox:



with duplicated fields for CONTAINS and NOT

myk wrote:

Xitax wrote:

myk wrote:[*]hit ctrl-shift-enter (cmd-shift-enter on osx) -- of course you could also do this by selecting the "Inverse of current search string" menu item

I think it would be better to have a button for opposite logic, similar to the other highlight buttons, labeled "not"

I had something like that in my original design, but the UI started to get cluttered. Let me toss some screenshots together with a couple options and tell me what you think.

I would suggest making three separate input fields for Name, Text, and Type so you can do more complex searches like "goblins with haste".

If you haven't played with the Advanced search mode of the Gatherer, you might want to look at it. I really like the way you can build up the logic for the search. I use the rules text search functionality all the time to find cards with similar effects when scripting new cards. I also like the way the types and subtypes are actually list boxes instead of free text.

ArsenalNut wrote:I would suggest making three separate input fields for Name, Text, and Type so you can do more complex searches like "goblins with haste".

If you haven't played with the Advanced search mode of the Gatherer, you might want to look at it. I really like the way you can build up the logic for the search. I use the rules text search functionality all the time to find cards with similar effects when scripting new cards. I also like the way the types and subtypes are actually list boxes instead of free text.

I just took a look at the advanced search page for Gatherer -- there definitely is some good functionality there. It would take a separate UI page to implement, though. Not to say it can't be done -- it could be implemented in a dialog that comes up when you select "Advanced search" from the "Filter by" popup menu. The advanced search would be added to the restriction list just like the other restrictions.

I'd like to point out, though, that in this design you /can/ search for goblins with haste: searches are stackable. Type in Goblin, check type and uncheck the others, hit ctrl-enter. this will add that restriction to the filter stack and clear the search textbox. Then type in haste, check text and uncheck type.