Log in

No account? Create an account
Previous Entry Share Next Entry
Magic: The Obsession
twitch sigil
I'm tossing the idea around of making a database for managing Magic cards. I decided that, rather than start messing around with MySQL tables directly, I should write out some table schemes and lay out my thoughts on what design would work, and what other things I need to consider.

So, I'm going to do that here in my journal. I can see you're all pleased. Muahahahaha!

I'm looking at a three table-type design. First table is a master list of cards that exist in the game. Columns will be specific details of the card, casting cost, type, colour, etc, as well as game properties such as direct-damage, special ability requires tapping, deck twiddling, and so on and so forth, ad infinitum. The plan is to be able to add such game properties at run-time data-entry, since I don't expect to anticipate every important type of effect that I might want to search on.

The second table would represent the user's collection, and be the pool of cards actually available for deck building. This table would only contain references by index to the cards in the master table, so the only thing that needs storing is one record for each kind of card owned, and a count of how many of that card are owned. Possibly there will be multiple tables of this sort to allow for multiple users. Hrm... then I need to do something about access permissions and passwords...

Third table type would be the deck representation. Cards from the collection could be collected in a deck, and the client would theoretically be able to print off a card list for a given deck. Again, this would only contain references by index to records in the Collection table.

Notes and toughts:

It will be a pain to keep the Collection table sane wrt to the actual card collection as soon as trades are made. I should pay special attention to making updating the collection easy with this in mind, but the user will still need to keep accurate records of each trade so that the DB can be updated. This is non-ideal.

Cards that are essentially the same but have a different name should be linked together somehow, so that the client can offer an easy way to cross-reference like cards. Thought: a facility to search for cards that are only similar to the desired card might be useful. Differences of n between casting costs, toughness/power, etc, could be searched on.

Keeping the game properties list usable will be a challenge. Do I really need to be able to add columns on the fly since I will be able to change the schema directly? Eventually, might I manage to cover all the aspects, while keeping the categories sensical? Must ponder more. Idea: start small and just munge the table directly. Eventually it will be clear whether I need to make it run-time alterable or whether infrequent, direct changes are sufficient.

That's all for now.

Bloody hell, I've got a lot of projects on my plate.

  • 1

Oooh, I get to have fun with this!

Welcome to saxifrage00's nightmare, everyone :)

I'll start with the easy stuff. First of all, column classifications. I predict a "casting cost" and an "activation cost" column coming to be. Assuming this is true, we get: Casting cost B2 (blue, 2 colourless), buyback 3 colourless, tap and pay BB to activate.
Values are totally made up, but the point is there; this card will need some way of listing the buyback ability, and do you really want to list something as an ability or activation cost if it can only be used at casting time?

Further complicating matters are the cards like Phyrexian dreadnought. Casting cost isn't expressed in mana at all. Thus, the casting cost column cannot be restricted in values to merely mana identifiers.

Next are the optional feature cards (pay extra to give the creature +1/+1 at casting time or some such).

Finally, there are the "you may do this, instead" cards. I can't recall the specifics, but there was a blue counterspell, which could cause you to discard two lands, instead of paying the mana costs. Two mutually exclusive listings.

These are just some potential problems off the top of my head.

Re: Oooh, I get to have fun with this!

I have the advantage that many abilities in Magic are standardised. The "pay extra to give the creature +1/+1 at casting time or some such" is called a Kicker, and is common enough that it would be listed in it's own column. The effect of the kicker would be another column altogether.

Buyback, too, is a standard card feature. For all cards that have a buyback, and entry would be made in the buyback column. Similarly, all cards that have a cylcing cost would have an entry in the cycling_cost column, and some will have an entry in the cycling_affect column as well, since some cards do stuff when they're cycled.

There are going to be an ass-load of properties. That's why I was thinking of making columns add-able at run-time to avoid manual table munging every time I try to enter a record for a card with a standard ability I've forgotten.

I'm not sure what I'll do for non-standard costs, however. I know there are some cards that have a mana cost that also say "you may pay n life to cast this card rather than the mana cost" and that will throw a wrench into my design. It's something to ponder.

When you read in reverse chronological order...

Ahhhh, I see.

What you need is a 'storage' table, it is not good db design, but its good programmer design, and maps well to OOP. In addition to your card table which would have as many standard things as possible (including standard undefined values) you could create a table that has the following cols:
card int
space varchar(15)
name varchar(15)
value varchar(255)

The 'card' is the card id from the first table.
The 'space' could be called 'property' and you can use it to store words like 'kicker'.
The 'name' is field is now space dependent, 'kicker' might have names like 'cost' and 'effect'.

For each new property you need to add a new space and fields, which can be done at run-time because its rows. Then you can write code that will output the stuff in a big table. To be fancy you can write an ouput class for each space, and only use the generic table when there is no class defined.

Also I would probably have a many to many mapping of cards to decks, a player can move cards between them.

Thanks for the tip. This looks like exactly what I need, and will be easily extensible at run-time to boot.

not only have many people already done this, they have formed a network and created a domain name. Save yourself some time and try out their free database stuff. All the cards *and* all the pictures already scanned in...


Re: download here...

Sweet! downloading...

Now, for saxifrage00, who is a bigger Linux nerd than I am... wonder if it will run in emulation or something...

A quick look at it reveals a few flaws:
  • It's Windows-only
  • It doesn't include many of the columns I want
  • It's not extensible so that I could add those columns
  • It's Windows-only
However, I've downloaded it and I'll be taking a look at the included db. It might be useful.

I'v always wanted to get into Magic Cards, but I don't think I'd be all that good at it. It looks like fun, though. *thinks*

Two things:

1) Magic isn't hard to learn, but the strategy does take time to get good at. When I first played (I haven't played for years and am just getting back into it), I didn't know the second thing about building a good deck, setting up decent card combinations, or play strategy. All I did was play with a deck of all my cards and just hope that I got cards whose colours matched the lands that came up to pay for them. Mind, that was fun in its own way, but it had little to do with skill.

2) Magic is damned expensive to get into. I dropped just over $35 on a couple packs of cards and one booster last weekend, and I only have 130 cards to show for it. Among that, I can only build one playable deck, and that's because one of the decks I bought was a pre-made theme deck. If I'd bought two random packs instead of one pre-made and one random, I still wouldn't have enough cards of any one colour to build even a bad deck. I figure I need to buy three or four more random packs, at $16 each, before I can build some reasonable decks out of them.

3) Okay, I lied, I have three things to say. :) The third thing is that you need opponents to play against. I wouldn't recommend people at school either, because school-mates make for really jerky opponents. That's the reason I got out of Magic originally and sold all my cards. (Aarrgh! I wish I hadn't sold them now.)

1) I agree. Delusions-Donate combo, anyone? :)

2) I agree even more. How many of us know people who've spent thousands of dollars on cards? How many of us *are* people who've spent thousand of dollars on cards? :)

However, you do know people who are heavy into Magic, and getting together with people who already play means two things: one is that they will have cards you can borrow to make a deck out of when you visit, and the second is that the cards that you borrow come with a built-in opponent. ;-)

You do not have to buy all your cards at random...
You can also trade cards you don't use for cards you will use.

btw, I made the Online Database with the 'decent search form'

You can also trade cards you don't use for cards you will use.

True, but one need to buy cards in order to trade in the first place. Trading does make it easier to construct a decent deck than it would be just buy cards and hoping to get the right ones, true.

btw, I made the Online Database with the 'decent search form'

I've played around with the interface you've got and I like it a lot. It has much of the abilities that I had in mind when I started thinking of this project, and I'm glad to have it as a resource to research cards I don't own. The only thing it doesn't do, of course, is allow me to store and manage lists of collections and decks.

I could make it possible of course.
But it would require a login procedure and a lot of extra work. And I'm not that eager to do it since I wouldn't use it myself...
But maybe one day I'll implement it...


  • 1