[TODO] Deck Builder

[Bratah123]

Abstract

This is the scene that users will see when they choose the 'modify' option from the Deck Viewer or Deck Manger, and the 'create' option from the Deck Manager.

Details

The Deck Builder should allow for:

• Assigning cards to a new deck
• Modifying existing decks
• Sends user to Deck Manager upon save/exit
• Allow entry of other attribute fields
  • E.g.: Description field, for distinguishing between decks whilst avoiding long names
  • E.g.: Tags/labels, to allow for ease of searching in Deck Manager

The primary input method for cards will be the GUI interface, which provides the following features:

• Searching for cards by name in part
• Filtering of cards by various attributes (TBD)

The secondary input method is a serialisable deck list. The Deck Builder system should provide:

• An 'import' button, which brings up a scene for input of deck list string (our own format)

The list should also be rendered "Human Read-able" once the list is imported.
Whether this be showing image of the entire deck, or just the name of the cards.

Example

These are Examples of what it could look like.

Image of when you paste in a deck list.

Image of the result of submitting/saving that decklist

Once you click submit it generates an image of a human readable decklist

Tasks

Planning Phase

• [TODO] Use-case Mock-up for Deck Builder #65
• [TODO] State Machine Mock-up for Deck Builder #66

Moment 1

• Prototype layout
• Link Import button to respective scene
• Prototype logic for deck list string parsing (and communication to/fro the server since this is offloaded)
• Prototype logic for displaying the selected cards
• Prototype logic for Save button (requires DB/oauth to be completed)
• Handle post-Save action's exit sequence (to Deck Manager)
• Post dev-log tweet

Moment 2

• Prototype UI logic for search field
• Prototype UI logic for filter field (drop-down menu? Or check box for multiple filters)
• Decide whether to handle search/filter business logic on the client or server side
• Prototype business logic for rudimentary search
• Prototype business logic for rudimentary filter
• Post dev-log tweet

Moment 3

• Prototype fuzzy logic for search (in case of typos)
• Refine UX if needed
• Check for deck list legality
• Post dev-log tweet

[Bratah123]

Leaving more examples from other online card games about how our deck builder could look like:

[KOOKIIEStudios]

Are we still using the fansite's exported text format as our primary input method?
Or is this now a second-class citizen, with our own GUI deck builder being the primary input method?

Does the fansite offer a parser for their formatting? Or do we have to implement our own parser?
As for the parsing, do we want this to happen on the client side? Or should it just be fed back to the server directly, and having the decoding and saving to DB done entirely on server side?

[Bratah123]

Are we still using the fansite's exported text format as our primary input method? Or is this now a second-class citizen, with our own GUI deck builder being the primary input method?

Does the fansite offer a parser for their formatting? Or do we have to implement our own parser? As for the parsing, do we want this to happen on the client side? Or should it just be fed back to the server directly, and having the decoding and saving to DB done entirely on server side?

I think after more consideration, we will be using our own decklist format and our own parser for it.
Everything related to deck lists saving/writing should be handled by the server.