Yu-Gi-Oh! Deck Building and Card Inventory Management web interface written in Common Lisp, utilizing HTMX.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

workflow.md 2.5KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950
  1. # Workflow Design Doc
  2. ## Overview
  3. The workflow for constructing decks is as follows:
  4. 1. Create deck of cards. Currently we select from all cards. Maybe we
  5. should just select cards from inventory. The majority of this
  6. functionality in place and isn't expected to change. A deck will
  7. always just be a list of cards plus metadata.
  8. 2. The deck of cards has metadata about author, name of deck, time of
  9. creation. The main content of the deck is three lists, comprising
  10. the main, extra, and side decks. This information is not expected
  11. to change in the future. Decks created by a particular user for
  12. example. The underlying metadata representation is what's being
  13. worked on. Currently each item in the database has all information
  14. duplicated from the rest of the database. Changing the price for
  15. one card changes the price for only that one card matching that row
  16. in the database. There will be additional tables to store pricing
  17. information in the next step.
  18. 3. On the Deck Overview page, selecting "Pull Deck" will decrease the
  19. inventory of the lowest priced card in inventory by one for every
  20. card in the deck. This is like "add to cart" in an online shopping
  21. platform, with additional inventory keeping. This is analagous to
  22. the deck construction step, except instead of selecting cards to be
  23. put into a deck, that information is provided a priori, and we use
  24. that list of information to construct secondary lists.
  25. 4. On the pulled deck page, for every card in the deck, you will be
  26. able to select cards by edition, condition, and rarity of every
  27. card in the inventory matching that card's passcode. I can
  28. conceive a very simple concept where you attempt to check out, and
  29. then are returned with error messages saying which items had
  30. errors. This is the current approach.
  31. 5. There will be an intermediate stage. Once there is enough inventory
  32. and the deck is "pulled" it will enter an area where each
  33. individual card will be selected. e.g. selecting the rarity or set
  34. of a particular card in each deck.
  35. 6. Once all "errors" are resolved (banlists, constraings, etc), the
  36. "pulled" deck will allow you to "construct" it, which will finalize
  37. the state of this pulled deck in the database, moving it to another
  38. table, the list of decks for sale.
  39. 7. The list of decks for sale is just pulled, constructed decks with
  40. pricing information attached and whether or not it was sold and
  41. what price it was sold at and when.