[Ardanet-developers] collection inventory management / deck editing

[Ris M. <rm...@ne...>]

Hi Team,

 

WARNING: disorganized brainstorming rambling follows.

 

I was very briefly talking with Josh B and he got me thinking about features
for Ardanet related to inventory management for my collection of real
physical cards.

 

My only prior concept of card collection features or anything that would
allow Ardanet to represent the collecting aspect of the game was centered
around the GCCG model of giving you virtual money and a limited starting
collection and then allowing players to trade from that collection, in
effect recreating the entire collecting aspect of the game in the online
world.  My opinion about that approach is like, sure OK I'm bet that's
appealing to other people, but IMO it defeats part of the point of playing
online, which is partly about letting you play with those special rare cards
that you don't own.  For Ardanet, since I don't personally care about using
those features, I didn't want to go there, so no such features are designed,
and I think I even documented it in a few places that we have no intention
to support the collecting aspect of the game in any way.

 

However, I never thought about crossing the line between the virtual game
and the real world, and I was never too particular about my own collection
of real cards in terms of trying to collect all the cards - I just tried to
get the cards I needed for the decks I wanted.  Now that Josh and I have
both been checking the inventory on our collections, talking about it, and
thinking about it, I'm realizing how nice it would be to have some software
assistance to keep track of the inventory of my collection.

 

Josh B put it well the other day when he mentioned the simple feature idea
(paraphrased): it would be nice if the Ardanet deck builder could tell me
whether the deck I designed is possible with the cards I really own, or
whether I'm missing some of those cards.  Ya know. BEFORE I go digging
through my thousands of cards.

 

Of course you'd have to enter in how many of each card you own and keep it
up to date, but you're probably doing this in a spreadsheet or word document
anyway. such as the docs I committed to SVN the other day. I figure we've
got a database of all the cards as it is to support the features we need in
Ardanet, and a deck is not far off from a collection of cards, so it's not a
very big stretch to recycle the deck editing code into a collection editing
tool and add some features along these lines.

 

I think that is precisely the best way to implement it: as a deck document.
There would be modified UI features for editing your collection vs. editing
a deck.

 

The normal deck building features ignore the site deck.  The movement path
interface we've designed creates the assumption that everyone has a complete
site deck.  Arg, this plan is flawed, and I keep forgetting.  It should be
possible, but optional, to create a site deck for your deck, to enable our
special movement path interface to suggest sites from a "short list" of
preferred sites that you selected when building your deck.  You would pick
this from a checkbox or it would be one of the search options.  Every site
will be available for every movement/hazard (indicated as tapped as
applicable) but you could restrict the search filter based on your deck's
preferred list, which is that deck's site deck.  The purpose of adding site
cards when building your deck in Ardanet is to serve as a reminder of which
sites are good for you with this resource strategy, as opposed to my site
deck for tournaments which is a complete collection of every legal site card
just in case I need to go somewhere I didn't plan on.

 

Anyway, that implies some difference between the collection management UI
and the deck building UI in terms of managing site cards.  For example, you
would never include more than 1 of any site card in your deck, but you would
want to list any number for your entire collection.

 

That goes for every card.  In general the collection UI would disable all
the deck building restriction checks of the deck editor UI in terms of
warning you that you used more than 3 of any given card, or that you have
more than 1 of the same site, or more than 1 of any unique cards, etc.  All
those features should be hidden from the collection UI.

 

There's also a difference in terms of how you edit a collection vs. how you
edit a deck.  When editing a collection you're going to look up cards
primarily by name, set, rarity.  When editing a deck you're going to look up
cards mostly by card type (hazard vs. resource, etc) and other stats,
sometimes by name, and almost never by set or rarity.  So the most visible
search options may change, unless all the search options are equally visible
in a common interface for card database search engine used by both the deck
editor and collection editor.

 

Some feature ideas.

 

-          Deck builder warning: this deck uses the following cards that are
not in your collection, so you can't make this deck in real life

-          Collection comparer.  Let Ardanet compare 2 Ardanet collection
files to suggest trades or sales.

o        We could add trader and seller info to the player profile info such
as shipping and billing info, a working hyperlink to your paypal account,
etc.  Then when connected to another player online, you could easily see
their rules for shipping cards, and how to pay them with paypal, etc.

-          Generate reports

o        Need list or Extras list

*         Based on 1 of each

*         Based on ability to make every legal deck (seeking 3 of each
non-unique)

o        Export the list to HTML or text format

*         HTML would use a template file that the end-user could edit

o        View just the cards you're missing from a given set, or just the
rares, etc.  There's more we can do here.

-          Add a data field for card price.  Now Ardanet is managing your
sales for you.

o        We could store a card price in the master card database,
representing the "book value" of that card

o        The player profile could have a standard deviation from the book
value in terms of x% so that cards in your collection would default to 95%
of the book value when you generate your extras list

o        This allows Ardanet to calculate the book value or user-specified
value of your collection.  This also lets you calculate an estimated outlay
you'd have to spend to complete your collection.

o        It would be interesting to calculate the estimated value of a
sealed box of boosters by using Ardanet to generate random booster packs *
36 * the price of the cards selected, to see if it's worth buying that box
of MELE that just showed up for sale on eBay.  You'd have to generate a
bunch of these to see how the results fall out to find the mean, median,
etc.

o        As Ardanet connects to other players and finds non-zero prices set
for various cards, it could automatically record the prices it sees in order
to track a more valid "book value" for every card, based on the average
price you saw people selling their cards.

 

We have the detailed rarity info for our database.  We should be good there.

 

The player profile document should contain the card collection, rather than
make it a separate document.  This would share some data from a deck
document and recycle code from the deck editor and other GUIs, but would
technically be part of the player profile document, so the views would be
associated with CplayerProfileDoc rather than CdeckDoc.

 

I have been puzzling over how to implement a deck document when it comes to
multiple copies of the same card.  Should it be N objects of the
CcardInstance class used for game documents?  Or should it be 1 object a new
class derived from CcardTemplate called, let's say, CcardInDeck, indicating
a data member CcardInDeck::m_nNumCopies = N.

 

Considering the idea of recycling a lot of these Uis and data structures for
both decks and a much larger collection inventory, it remains as puzzling.

 

I'd like to make another class, that's for sure.  The CcardInstance class
includes a lot of in-game information like tapped status (and a lot more)
that doesn't apply for a card in a deck.

 

The deck will not be merely a list of card template IDs because that creates
too much of a binding between the card database document and all your decks.
I want copies of all the card template information in the deck files so you
can get an upgrade warning if you've updated your card database since the
last time you opened this deck, so it can tell you exactly what changed.
This would be particularly useful for finding the errata changes that have
an impact on a given deck, or telling you the net book value change of your
deck.

 

So we'll have a new class for a card in a collection of cards.
CcardInstance will be used exclusively for cards in a game, while
CcardInCollection objects will be used for cards in a deck or your
collection.  This will add a data member for how many copies of that card in
the collection, CcardInCollection::m_nNumCopies.

 

Normally if you have 100x Doors of Night, it's not reasonable to have 100
array entries for "Doors of Night."  There should be 1 array entry with
"Doors of Night x100."  This should be the general rule.  The same applies
for deck editing.

 

As an advanced feature, I figure the pricing, sales, and advanced trade
features are for ersion 3+ or whatever.  Later on, I think we can make it so
you can optionally add another instance of that CcardInCollection object
instead of incrementing the m_nNumCopies number, to have independent
m_nNumCopies values probably both set to 1, in order to track additional
info about the multiple different copies of your cards.  I'm thinking about
using your collection management for card sales and you have a pristine The
One Ring Limited for $55 and a "well played" but near mint Unlimited The One
Ring for $35 - you want two instances of The One Ring in your collection,
but you need two separate CcardInCollection::m_nPrice values, so in this
case, instead of making a single instance of the CcardInCollection object
with CcardInCollection::m_nNumCopies = 2, you make two separate
CcardInCollection objects in the array, each with m_nNumCopies = 1.  You
enter the notes in the card errata field.  This doesn't really apply to deck
editing because you always want to see Doors of Night x3 instead of Doors of
Night, Doors of Night, Doors of Night in your deck editor.

 

Would be nice to use the collection manager to help me find which of my real
decks I left a certain card in from my collection, if I know I own that card
because I entered it in Ardanet. I suppose what I would do is enter all my
real decks into Ardanet as well, and store them in the same subfolder
together . if I had so many decks constructed that I needed this feature. I
could run a Search all Files kind of operation to search all my decks in
this folder for a given card.

 

That's all I got for now.  Overkill, I know, sorry.  Just trying to think
ahead to make sure the data structures will be extensible into all the
features we'll ever want.

 

-- Ris