Collectible Card Game Headquarters

I'm looking forward to work further on quest mode. That is set up some custom starting sets (take starter precons and and event decks), add boosters to card shop, add some kind of achievents and stats into game so that quest challenges could give some rewards for that, add rewards for completing some conditions in a quest battle/challenge.

I heard Rob is coding something related to new quest window, there are also some sketches for new game screen in the parent forum. Doublestrike was improving quest loading system. And I would love not to have code collisions and merge problems with other developers.


So what are doing now and planning to do next? And who is going to implement innistrad double-sided cards?

My new home screen Gui would at the moemnt, just launch the quest gui. IF someone could work out a way to have multiple characters in quest mode, that would be a neat thing to add to the home screen. As it is now, you select Quest mode, and nothing really happens until you press start, so it's kinda visually dull....

I didn't have any particular plans for the quest screens, though I did do a bunch of work before The Great Transition on enforcing the entire quest data card pools to particular Formats (Standard, Extended and Legacy) along with the gui work on the new quest screen to select such options. Not sure any of it will work with all the new architecture.. As it was I was having trouble dealing with not being able to filter CardLists due to Braids' work. It's in my original local Google SVN archive.

Laying some groundwork for stats is a good plan. At some point I would like to link the Forge client with some sort of leader board scripts on cardforge.org.. We could begin with adding a user name setting in Forge, so the quest stats could reference a particular person, with their particular deck/cardpool.

Rob Cashwalker wrote:Laying some groundwork for stats is a good plan. At some point I would like to link the Forge client with some sort of leader board scripts on cardforge.org.. We could begin with adding a user name setting in Forge, so the quest stats could reference a particular person, with their particular deck/cardpool.

I like this plan, but we need to make sure the "Ladder" or whatever we want to call it does not use the quest.preferences file at all, and disables things like importing into quests, so everyone has the same restrictions.

Rob Cashwalker wrote:My new home screen Gui would at the moemnt, just launch the quest gui. IF someone could work out a way to have multiple characters in quest mode, that would be a neat thing to add to the home screen. As it is now, you select Quest mode, and nothing really happens until you press start, so it's kinda visually dull....

I don't see any trouble adding several saves for quest mode, can do that as well. We may decide to have some... three slots for quest. To fill the listbox custom list-item-render can be developed to show not only the save name, but also some simple stats, like wins, losses, credits, brief summary on cardpool and decks.

Rob Cashwalker wrote:I didn't have any particular plans for the quest screens, though I did do a bunch of work before The Great Transition on enforcing the entire quest data card pools to particular Formats (Standard, Extended and Legacy) along with the gui work on the new quest screen to select such options. Not sure any of it will work with all the new architecture.. As it was I was having trouble dealing with not being able to filter CardLists due to Braids' work. It's in my original local Google SVN archive.

My cardpools or the way quest data is stored don't enforce any format, it's up to player to choose which booster he wants. The only restriction for now is that a card has to be present in our db, that is there should be a cardname.txt for it.

As for filtering cards, I found the way CardLists and thier filters were too slow and implemented a different filtering system. Firstly you compose a predicate for cards you want to select using methods from CardPrinted.Predicate and CardRules.Predicate class (each class contains a subclass with commonly used and thus already preset predicates). It's like a logical expression

Code: Select all

Predicate<CardPrinted> myFilter = Predicate.and(CardPrinted.Predicates.Presets.isRare, CardPrinted.Predicates.wasPrintedInSet("SOM"));
List<CardPrinted> myRequestedCards = myFilter.select(CardDb.instance().getAllCards());

Then you make a call to select or maybe some other method - like random() or first() - and recieve the filtered lis or single. It makes only one iteration over the list of cards and does not copy cards or their lists over and over.

I think your work can be powered by the new architecture. May I have a look at the features you've implemented?

Rob Cashwalker wrote:Laying some groundwork for stats is a good plan. At some point I would like to link the Forge client with some sort of leader board scripts on cardforge.org.. We could begin with adding a user name setting in Forge, so the quest stats could reference a particular person, with their particular deck/cardpool.

Yes, that is the what I would love to see in Forge sometime.

The bulk of filtering for sets was actually implemented in the BoosterGenerator, which you probably already had to modify in order to function with the new Card objects.

The only changes I had been making were in the quest data. At the time, the feature desired was to actually restrict the card pools to a given format chosen when you begin the quest. (requiring a few new options in the New Quest screen.) I moved the card shop card pool generation over to the QuestData, out of the card shop gui. I changed the starting pool to actually pull entire booster packs of one set at a time, instead of across all legal sets. That was about as far as I got.

Absolutelly everything of what you've decribed is possible to do on the new architecutre.
Genereation of cards for shop has already moved from GUI.

I've been a little distracted this week with Day Job, and a few other excuses, but yeah, I'll be solidifying the quest files very soon (weekend?) and hopefully getting more work done on Forge in general, soon.

I joined this project to work on the GUI. I'm very passionate about having a clean, modern, usable frontend, and I've got years of coding website interfaces to draw from. I'm really excited about making an excellent GUI for this excellent codebase. I worked on the splash screen, for instance, which in my opinion is now looking smooth and has good user-software interaction.

My plan is to nab any GUI related tasks from the bug list, for example the "better targeting" one from a few months back. Been waiting on Rob's work to see what the framework looks like. Also looking forward to some better separation of view and model, and seeing some more of Moomarc's great graphics work.

Doublestrike wrote: I'm really excited about making an excellent GUI for this excellent codebase.

You meant: I'm really excited about making an excellent GUI for this excellent codebase rusty can of weasels fixed with tape.

Sloth wrote:

Doublestrike wrote: I'm really excited about making an excellent GUI for this excellent codebase.

You meant: I'm really excited about making an excellent GUI for this excellent codebase rusty can of weasels fixed with tape.

/agreed

Doublestrike wrote:I've been a little distracted this week with Day Job, and a few other excuses, but yeah, I'll be solidifying the quest files very soon (weekend?) and hopefully getting more work done on Forge in general, soon.

Also, please note that codebase... well.. it has somewhat changed again: this time the former CardPool became a parametrized ItemPool. That means, I'm going to lift the limitation which allowed only printed cards in decks and quest inventory.

The areas I've recently been working on are Cost & AF_Attach. A few things I want to do soon are revamping the Targeting system to allow for multiple Targets of a single AF (such as Gaea's Blessing) and adding full Cost objects to Unless. Both of which may take a while, since I've been pretty busy lately and I've already ran into some issues with the Cost Unless where we'll need some type of "callback" functionality in place.

I am planning to keep on grabbing all the newest enhancements and corrections and then trying to break them.

Seriously, I do enjoy testing software and contributing to the ever improving project that is Forge.

Also, please note that codebase... well.. it has somewhat changed again: this time the former CardPool became a parametrized ItemPool. That means, I'm going to lift the limitation which allowed only printed cards in decks and quest inventory.

OK thanks for the heads up. I found some time to work on the quest stuff which means I should have results in about 36 hours. It's a pretty big refactoring, since quest stuff was all over the board. Some reorganization was required.

So, if people could leave the quest/battle main screen (that is, stuff related to Quest_Assignment and ReadQuest_Assignment, etc.) alone for just a little while, it would be good.

I may as well explain some terminology while I'm here. When my changes go in, the word quest refers to the whole quest experience. In that experience are "events". These events used to be called battles and quests, but this led to variable names like "QuestQuest quest". So, they're now called duels and battles, which is more accurate anyway. Also, there'll be a definite separation between view and model, and all helper files (easy.txt, quests.txt, etc.) will not be necessary. Anyway, I'll hopefully have some time later this evening to keep working.

You meant: I'm really excited about making an excellent GUI for this rusty can of weasels fixed with tape.

Yeah...didn't want to hurt any feelings, but...yeah...

It's getting better though!

Not sure if "can" is accurate, maybe "sieve".

Doublestrike wrote:So, if people could leave the quest/battle main screen (that is, stuff related to Quest_Assignment and ReadQuest_Assignment, etc.) alone for just a little while, it would be good.

I may as well explain some terminology while I'm here. When my changes go in, the word quest refers to the whole quest experience. In that experience are "events". These events used to be called battles and quests, but this led to variable names like "QuestQuest quest". So, they're now called duels and battles, which is more accurate anyway. Also, there'll be a definite separation between view and model, and all helper files (easy.txt, quests.txt, etc.) will not be necessary. Anyway, I'll hopefully have some time later this evening to keep working.

I'm not going to work on that screens in the meantime. There is also Rob working on gui... I guess he is now focused on home screen.

Of course, the names like QuestQuest are awful. I would just suggest naming the former quest-quests challenges - because you are facing some non-common conditions in that event, and this is not as confusing as battles against duels.
Well, you are doing things this project really needs and I'm looking forward too see it all

Battles/Duels are a bit too similar in naming. Maybe "Challenge" or "Boss" or "Mission" for the event-previously-known-as-quests