PHP script: card db

Development of our card database & card dev. tool. Used as the Gatherer & to empower the community to create new cards. Lead dev: Knitter
User avatar
Ravenchild
developer
Posts: 131
Joined: Sat Sep 04, 2010 19:21
Location: Germany

PHP script: card db

Post by Ravenchild » Tue Sep 07, 2010 21:18

The development advances. I hope to finish this in a couple of days to have it in usable state. That does not include a fancy CSS design :lol:
snowdrop wrote: Please make the result (actually, almost everything that has to do with the script) have the relevant variables outputted in the URL itself. Using PHP $_GET Function? That way people can bookmark the URL and instantly reach that specific searchresult, and in the same manner they will be able to bookmark cards, certain revisions of them etc, without having to go through the web interface time and time again if they already have done so once.
Very good point. Currently the search uses POST but I can change that of course.
- card creation
Nice.

Since you'll release it using GPL2 or later (if that's fine with you - I would prefer it, but in the end you decide yourself.) there could be a point in making it more general/customizable by writing an interface that allows the admins to use the script for virtually any CCG. To do that they would have to edit/add/name fields that are associated with a card. That would be very cool, but, it's not necessary in any way for our use within WT. It would however make the script future and game revision proof. Do as you wish =)
I'm trying to be modular so that changes to the script will not cause much headache. But for the moment I think an adaptive system for all TCG would be an overkill.
And GPLv2 is okay. Maybe I'll even pick AGPLv2.
- card revision (with keeping and linking to the old card)
Excellent. Use a simple integer numbering system for the revisions.
It's already done that way. Relational database mentality 8-)
Also keep track of the name of who did the revision, date etc when it was done. Maybe also even add a field where the revisor can add some info on why the revision was made and what happened. (I.e. "Card was too cheap compared to x y, thus I made it 1 gold more expensive".)
Already implemented.
Lastly, if the card image has changed in the later revisions, showing an old revision of the card should also display it's old associated card image.
My current vision is the following: There is a 255 char field for the image. An anonymous user may use this field for descriptive text or may even write the URL to an image.
Once the card has the state 'accepted', any URL in this field will automatically be rendered as an image. So the image itself lives outside the database and my be changed by accident.
It would be possible to load the images as BLOBs into the database but it's not something I would consider "clean" ;)
- login (so you find your own cards again), not required for visitors.
Hash + configurable salt passwords.
Already on my TODO list. By the way: Does this server support HTTPS? It doesn't seem so. I have no problems with self signed certificates. It's the encryption that matters.
I think all users should be able to do a search for cards created by author x, or for cards rejected (not same as banned - a banned card has been in play but banned later, a rejected card never made it into playtesting even.)
will be included in version 0.2 as it is not a core feature. But shouldn't be hard to do.
Sounds cool. Q: What's best - to have one thread for each rev. of the card
One thread for each revision.
, or one single thread per card?
That would be problematic because one card may have more than one successor.

For each card the predecessor and the successors are always listed.
Hrm, tricky. You decide. However, maybe we should use re-captcha for anonymous posters? *sees bots crapping all over*
I haven't used reCaptcha for my own projects yet so that I need to do some learning. But on the other hand I'd be happy to help Google with digitalizing books :)
- different states for cards: draft, discussed, accepted and banned.
Add: rejected, playtested
noted
Btw, what's the diff between draft & discussed? When would discussed be used? (Maybe gives the wrong impression here given there's a discussion thread associated with each card. Rename? ; )
a draft is a new card (usually proposed by external users). A discussed card is a card that we are aware of and want to decide upon in the near future. But I really agree, that we need another word for that.
I think a powerful card search is important, so one can really mix all kinds of criteria and use IS or IS NOT combos etc. After all, that's a database main function - to store and find/show the info to the user. So, whatever is in the gatherer should be in ours as well I think. At least that.
Okay, I'll see what I can do without making the application prone to SQL injections.
Beyond that I think you had the basics covered pretty solid. I envision a way for players to actually build decks online and have them associated with their profile etc,
Okay, that should be possible. We could have a deck-table and JOIN it with the cards table.
and also an easy way to rate, discuss decks, keep track of revisions of them and so on, and even some kind of breakdown of decks (so called deck analysis, in the MtG world that would be info like 23 lands, 10 creatures, mana curve etc etc)
Yes, later on. But first we need to fill the DB with cards ;)
Also, maybe by pressing a button the players would easily be able to export the decks to deck-text files that can be loaded into i.e. LackeyCGG / OCTGN2 etc. Would also be cool with various top x lists over decks, and stats of most used cards in decks etc.
I don't know what kind of file formats they use but It's probably nothing insane :twisted:
Oh, while at it: It would be nice if there is a card category called "public suggestion" or somehing. It is just like "draft", but, anyone that is registered (not only admins/mods) can actually suggest a card.
That's the way my current implementation works. Anyone can submit cards. With or without registration. And registration is itself just a choice of a username and a password and you are done.
Also, there would be a way for anyone registered to actually cast a vote on the card from 1 to 5. That way top lists over the most popular suggestions etc can be generated. :)
At the moment the login-system is very liberal. I think a voting system would be prone to abuse.
In my system there are 3 ranks: guest (no distinction between logged in or not), moderator and administrator. I think it would be a good idea to have the moderators and the admin(s) vote on the cards and not the guests.
If a guest submits a good card, we may ask him if he wants to become a moderator because he has a good taste. (Note to self: implement simple messaging system)
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: Trunk

Post by snowdrop » Wed Sep 08, 2010 20:18

I hope to finish this in a couple of days to have it in usable state.
Sounds like lightning speed. :P
That does not include a fancy CSS design
Doesn't matter, styling stuff is usually added at the end anyways, unless of course working with a template engine or something that needs complex styling.
My current vision is the following: There is a 255 char field for the image. An anonymous user may use this field for descriptive text or may even write the URL to an image.
Once the card has the state 'accepted', any URL in this field will automatically be rendered as an image. So the image itself lives outside the database and my be changed by accident.
It would be possible to load the images as BLOBs into the database but it's not something I would consider "clean"
Agree that BLOB is a bad choice - we should avoid storing files in the db itself - it just clogs up the db and makes it harder to backup / load etc. I only have bad experience of that...

Why not allow the user to upload the picture to the server, in a designated dir? (i.e. /images)? Or even better, allow the user to select to either enter a url that leads to a an image, OR to upload one to the site.

What's bad with the external URL:s is that the image could go offline, be removed etc whenever. Different images on different hosts by different people will often just lead to trouble with the image availability in the end. Thus, offering the local upload seems like a good option.

Also, once created, a card should not be able to become edited / revised by an anonymous user.

And while on the subject: While normal edits will lead to the card being marked as one revision number higher, there might be an actual point with having the ability to edit the _latest_ revision without letting it get an increased revision number. The typical scenario would be if one just happened to type the wrong number or have a small spelling error and one discovers it immediately - then the revision number shouldn't jump up one additional step just because of a "minor/correctional edit". So, maybe a checkbox called "minor edit" or something that, when checked, actually edits a revision without altering it's rev number?
Does this server support HTTPS? It doesn't seem so. I have no problems with self signed certificates. It's the encryption that matters.
Don't think it does. Even if it did, it might be an idea to keep it to just http since people would be able to use the script on more server setups then - most common and budget hosts don't support https.
I haven't used reCaptcha for my own projects yet so that I need to do some learning. But on the other hand I'd be happy to help Google with digitalizing books

Neither have I. but I believe it should be easy. If it's not, then you could design some home-made bot check yourself. :)

Btw, while on it, check out Gravatar - adding support for that when commenting etc is super-easy, will take you like 15 min total since the php addon is already available from them - it just needs a line to be added into the discussion code.
Okay, that should be possible. We could have a deck-table and JOIN it with the cards table.
I suck at SQL, but from what I have seen when working with it MySQL is half-sucky when it comes to JOINS and doing many and complex ones, at least when handling huge chunks of data, it is slow. When testing things, use a database with 50 000 fake cards or something like it, if it performs well then, it should perform well forever since we'll never amass that amount of cards anyway.

Hrm.. also, a feature for an admin&mod to actually totally nuke/wipe away a card from the db should be available. "Deleted" cards are a placed in a totally other table, specifically designed to just contain them. When deleting a card it should also be stated why it was deleted.
I don't know what kind of file formats they use but It's probably nothing insane
Nah, it's very very easy stuff. Almost no info at all in those files, and often just pure text, very understandable.Will be very easy to fix.
At the moment the login-system is very liberal. I think a voting system would be prone to abuse.
In my system there are 3 ranks: guest (no distinction between logged in or not), moderator and administrator. I think it would be a good idea to have the moderators and the admin(s) vote on the cards and not the guests.
Why not make all that are not loggged in = guest. Logged in normal user = user. Rest logged in = mod or admin.

Problem with only letting admin & mods to vote is that there will, on most sites, be very few admin and mods around. Thus the votes will not say much, especially the average of them will be meaningless. Instead they will function like some "editors review" if done the way you suggest. if so, then the voting should't only be numerical 1 to 5 - instead an (or each) admin/mod should also be able to review the card in a admin/mod-review section associated with it.

Then again, letting voting be open for registered logged in users shouldn't be prone to abuse if voting from them requires recaptcha or something. Why would anyone want to "cheat" the vote system to begin with? In the end all that will matter is the admin/mod review anyway. The star system is just for fun and showing public opinion.
If a guest submits a good card, we may ask him if he wants to become a moderator because he has a good taste. (Note to self: implement simple messaging system)
Agreed.
User avatar
Ravenchild
developer
Posts: 131
Joined: Sat Sep 04, 2010 19:21
Location: Germany

Re: Trunk

Post by Ravenchild » Thu Sep 09, 2010 06:45

snowdrop wrote: Or even better, allow the user to select to either enter a url that leads to a an image, OR to upload one to the site.
That's possible. The only problem is that we need to make sure that all material is under a liberal license.
What's bad with the external URL:s is that the image could go offline, be removed etc whenever. Different images on different hosts by different people will often just lead to trouble with the image availability in the end. Thus, offering the local upload seems like a good option.
It's absolutely mandatory to have a copy of all images that are used in official cards. And concerning unofficial cards, do you really think that broken URLs will be that common?
Also, once created, a card should not be able to become edited / revised by an anonymous user.
Of course not. The user may (if at all) only create a new revision of the card.
And while on the subject: While normal edits will lead to the card being marked as one revision number higher,
The card's revisions aren't 1,2,3 but the card's revision numbers are identical to their IDs. Each card has an INT field that is identical to the ID of it's predecessor.
That way it is easier (and faster) to get predecessors and successors of cards. And it allows changing the name of a revised card.
Besides, it allows forking of cards.
there might be an actual point with having the ability to edit the _latest_ revision without letting it get an increased revision number. The typical scenario would be if one just happened to type the wrong number or have a small spelling error and one discovers it immediately - then the revision number shouldn't jump up one additional step just because of a "minor/correctional edit". So, maybe a checkbox called "minor edit" or something that, when checked, actually edits a revision without altering it's rev number?
Not a bad idea, indeed.
Don't think it does [support HTTPS]. Even if it did, it might be an idea to keep it to just http since people would be able to use the script on more server setups then - most common and budget hosts don't support https.
Why should it matter for the PHP script whether HTTPS is used for the communication?
I mean, having salted passwords in the DB is one thing but it is only helps when the database leaks data. A relatively more likely danger are password sniffers on the user's connection.
Btw, while on it, check out Gravatar - adding support for that when commenting etc is super-easy, will take you like 15 min total since the php addon is already available from them - it just needs a line to be added into the discussion code.
Wow, that's indeed a cool plugin. I always wondered how some blog comments had shown profile images.
I suck at SQL, but from what I have seen when working with it MySQL is half-sucky when it comes to JOINS and doing many and complex ones, at least when handling huge chunks of data, it is slow
We will see. If it is really that bad we may as well distribute plaintext files with all the information relevant to the deck.
. When testing things, use a database with 50 000 fake cards or something like it, if it performs well then, it should perform well forever since we'll never amass that amount of cards anyway.
Yeah, 64k cards should be enough for everyone :mrgreen:
Hrm.. also, a feature for an admin&mod to actually totally nuke/wipe away a card from the db should be available. "Deleted" cards are a placed in a totally other table, specifically designed to just contain them. When deleting a card it should also be stated why it was deleted.
Okay, will be implemented in a later version.
Why not make all that are not loggged in = guest. Logged in normal user = user. Rest logged in = mod or admin.
My current model is slightly simpler. But I don't mind doing it as you proposed as it really doesn't change much.
Problem with only letting admin & mods to vote is that there will, on most sites, be very few admin and mods around.
I'm pretty sure that this will not be much of a problem in any case. If there are more submissions than the current team can handle, then there will also be enough users in the community who can be invited to join the team.
Thus the votes will not say much, especially the average of them will be meaningless. Instead they will function like some "editors review" if done the way you suggest. if so, then the voting should't only be numerical 1 to 5 - instead an (or each) admin/mod should also be able to review the card in a admin/mod-review section associated with it.
Each card revision has a discussion thread associated with it, where everyone can share his thoughts on a revision.
I don't know yet how the voting will be look like. It may even be fully integrated into the discussion thread and the change itself will only be a boolean that any admin can set:
A: I think the card should be included into the official set, because…
B: I agree
C: Me too
A: Card is now official
Then again, letting voting be open for registered logged in users shouldn't be prone to abuse if voting from them requires recaptcha or something.
Why would anyone want to "cheat" the vote system to begin with? In the end all that will matter is the admin/mod review anyway. The star system is just for fun and showing public opinion.
If it is for the fun, then it will be implemented (sooner or later).


Okay, I need to do some refactoring. It will definitely not be ready this week as I'll be busy with other stuff on the weekend.
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: Trunk

Post by snowdrop » Thu Sep 09, 2010 18:12

Ravenchild wrote:
snowdrop wrote: Or even better, allow the user to select to either enter a url that leads to a an image, OR to upload one to the site.
That's possible. The only problem is that we need to make sure that all material is under a liberal license.
Yes, indeed, we want to avoid copyright infringements and other legal issues. Legally I do think it would be easiest and wisest to just add a checkbox á la "By submitting the content I agree that I own the copyright to the submitted image and have read, understood and accept all terms, licensing the content under the GPL2 or later." and a link to the all the legal info.

That way we avoid responsibility (and we would still take it if somebody tells us that illegal material is hosted, then we'd remove it of course) and put all focus on the user, the person actually uploading the stuff.

Besides, is this really a problem? I imagine like 99% of what will ever be uploaded/linked to won't be of good enough quality OR a stylistic match to the art we already have, making it a very bad idea to incorporate it into the official part of the game: I want a game that looks somewhat coherent visually / stylistically, and in best case scneario only one single artist will create all the art. (I.e. I have all intentions in the world to keep the current artist until he leaves or a better one shows up for the same price.)

Also, what do you mean that they would upload: A finished card, or, just the card art image that we/something then have to place on the template, and also fill in the text etc, and generate a finished card?

To be honest, I don't think automagical card generation can ever be made to look as good as hand-made cards using the template in Inkscape. It would take plenty of programming to make a decent auto-generation, and even then it would fail from time to time. Unless of course, one does it semi-auto, and codes an app that's online and that loads the template online and lets the user assemble and adjust the card online within that app - that could be made to work quite well, but it sure seems like a lot of work for something that can already be done perfectly well today already in Inkscape.

What I imagined is that we see the actual and finished card, with artwork (if available), template and all correct values & text, assembled in Inkscape and uploaded as the "image" associated with the revision / post. People could ofc be allowed to create cards without having all this in place and not upload a finished card image - instead, and in such cases, a default "placeholder card" would be shown, and each card type would have it's own place holder card.
It's absolutely mandatory to have a copy of all images that are used in official cards. And concerning unofficial cards, do you really think that broken URLs will be that common?
Card art and images of completed official cards wont be a problem: The problem is that if we don't allow images to be uploaded to the server even we as the admins would have to first leave the site and use FTP or whatever to upload the images somewhere (i.e. the WT webserver) and then specify the url to them. It's not a huge issue, but it isn't smooth.

The card's revisions aren't 1,2,3 but the card's revision numbers are identical to their IDs. Each card has an INT field that is identical to the ID of it's predecessor.
That way it is easier (and faster) to get predecessors and successors of cards. And it allows changing the name of a revised card.
Besides, it allows forking of cards.
Now I'm confused (maybe because I'm tired): Each card gets an integer as it's ID in the db. I got that much. Now, exactly what "number" is auto-changed when a new revision is done?

If I have the card called "The Raven" in front of me, and it has ID = 10, and I now revise it, it would still have ID = 10, right? If so, where and what tracks the "revision number" - the ID is not it (nor should it be, so I agree about using the ID..)

Is there an additional column that holds the revision number, i.e. "REVISION"? So, ID could be 10, and all posts where ID = 10 is the same card, but, all those posts could/would have different REVISION number?

*confuses himself*

Don't think it does [support HTTPS]. Even if it did, it might be an idea to keep it to just http since people would be able to use the script on more server setups then - most common and budget hosts don't support https.
Why should it matter for the PHP script whether HTTPS is used for the communication?
I mean, having salted passwords in the DB is one thing but it is only helps when the database leaks data. A relatively more likely danger are password sniffers on the user's connection.
I wouldn't know - hence my stupid remark ;) I haven't worked with HTTPS and PHP and don't know if the HTTPS would require anything special or HTTPS-only specific code. If it would, then it would be a bad idea to use such code since most "normal" cheap webhosts support https. (Here I take for granted that we want as many as possible to be able to pickup your script and re-use it of course. I speak of common people, not industry people or programmers etc)

Agree on the sniffing part and all.

Wow, that's indeed a cool plugin. I always wondered how some blog comments had shown profile images.
It's a good concept and it works well. :)


I'm pretty sure that this will not be much of a problem in any case. If there are more submissions than the current team can handle, then there will also be enough users in the community who can be invited to join the team.
True.
If it [the star system / general voting] is for the fun, then it will be implemented (sooner or later).
:) You're the boss on this one - do it like you wish, after all, you're coding it. I try to chip in with some ideas though, sometimes good, sometimes bad - in the end you should however only code what you feel comfortable with.
Okay, I need to do some refactoring. It will definitely not be ready this week as I'll be busy with other stuff on the weekend.
It's cool and there's no rush. Actually the projects motto, among others, is that IRL is prioritized first. Important thing is that we get stuff done and done well, instead of a zillion things done in a short time span and semi-crappy. ;)
User avatar
Ravenchild
developer
Posts: 131
Joined: Sat Sep 04, 2010 19:21
Location: Germany

Re: Trunk

Post by Ravenchild » Sun Sep 12, 2010 13:10

snowdrop wrote: That way we avoid responsibility (and we would still take it if somebody tells us that illegal material is hosted, then we'd remove it of course) and put all focus on the user, the person actually uploading the stuff.
That's true. But still we need to verify that each upload/link is really under a liberal license. This is easier if we know where an image comes from.
My main concern here is not users who want to create trouble but users who simply haven't a clue what liberal/free licenses are.
Also, what do you mean that they would upload: A finished card, or, just the card art image that we/something then have to place on the template, and also fill in the text etc, and generate a finished card?
Just the image. Not the complete card with text and borders.
To be honest, I don't think automagical card generation can ever be made to look as good as hand-made cards [...]
Well, I understand that it is difficult to produce a card like this:
Image
But still, it would be a great advantage to autogenerate the cards. It is worth a try once we have settled on all the possible symbols that may appear on a card.
Card art and images of completed official cards wont be a problem: The problem is that if we don't allow images to be uploaded to the server even we as the admins would have to first leave the site and use FTP or whatever to upload the images somewhere (i.e. the WT webserver) and then specify the url to them. It's not a huge issue, but it isn't smooth.
Then I propose a compromise: The user may either upload a file or he may link to a file on the internet. This file will be downloaded automatically. We can save the url where the image comes from and may later investigate whether the image is really under a free license.
The card's revisions aren't 1,2,3 but the card's revision numbers are identical to their IDs.[...]
Now I'm confused (maybe because I'm tired): Each card gets an integer as it's ID in the db. I got that much. Now, exactly what "number" is auto-changed when a new revision is done?
When a new (major) revision of a card is created, a new row is inserted into the database. This row has it's own id and has a field that is identical to the original card's id.

Code: Select all

/* pseudocode */
//create a card named foo
{id = 1, name = "foo", ancestor=0 }
//then create a card named bar
{id = 2, name = "bar", ancestor=0 }
//now someone decides to create a derivative of foo. A new database entry is made:
{ id = 3, name = "foo, oh lovely foo", ancestor = 1 }
//the initial foo may have any number of derivatives in the database:
{ id = 4, name = "foo, the card you always wanted", ancestor = 1 }
By the way: The id field has the AUTO_INCREMENT and PRIMARY KEY properties set.
I wouldn't know - hence my stupid remark ;) I haven't worked with HTTPS and PHP
PHP has some HTTP capabilities but all it does is ask apache to do the dirty work. So HTTP and HTTPS requests look the same to PHP (but you can still check if the request is secure or not).
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: PHP script: card db

Post by snowdrop » Sun Sep 12, 2010 15:38

That's true. But still we need to verify that each upload/link is really under a liberal license. This is easier if we know where an image comes from.
My main concern here is not users who want to create trouble but users who simply haven't a clue what liberal/free licenses are.
Without a direct link to a written and somehow verified (however we would ever be able to tell that) statement from the content's creator it is virtually impossible for us to know what license the work is placed under. The cases where it will be apparent enough will probably be few, and in a vast majority of the time we would need to spend time hunting down the source, reading through documents etc to really confirm the art is genuinely placed under a liberal license (or, why not go as far as to state "an open source license" as defined by the open source initiative?)

What I'm getting at here is that it will be very hard to ever actually know for sure if a work is placed under an acceptable license, and that it will take loads of time in the long run. Hence, I don't see us doing that kind of detective work - instead of chasing people around the world we could focus on other things. And even of we had "helpers" that for some reason wanted to do this kind of tasks - how are they ever accountable in scenarios where they do a bad job? On whom would we rely? Why/not? Legally, and in the end, if we don't put the ball and the responsibility in the users hands, we will end up carrying all the load and legal troubles ourself.

What would perhaps be enough is the following:
  • Checkbox "I agree to bla bla bla..." with a link to a lengthy version of whatever the user agrees to by submitting anything at all to us. If the box is not checked, nothing is submitted. All info is just reloaded and a screen shows the user that she hasn't accepted the agreement.
  • Name of author and direct link to his site/and or e-mail.
  • A drop down menu where the user can pick what kind of license the art is under, listing the most common licensens + "other license, see link"
  • If "other is selected, the user has to input a link to the license
  • Custom text: A field where the user can input any additional commentary to the uploaded art?
In the footer of that page we would also have info text saying that WT.org doesn't take any responsibility for the users uploaded content etc. Maybe we should even put stuff in a moderation queue? At least that's one way, maybe the safest, of doing it.

Again, let's not forget that we will probably end up getting very very few pieces of art submitted to us that a) are under a legit license and b) match the style and c) match the quality of the already existing artwork.
Just the image. Not the complete card with text and borders.
Hrm...

Okey, so, the db will fill at least two basic purposes: 1) Work as a database of all real cards. 2) Work as a tool to develop cards.

While cards are in some dev mode I guess it doesn't matter much if it's the finished card with text and all or only the card art that is shown.

However, whenever a player is just interested of browsing finished and officially approved cards (which maybe should be the default view/mode? Btw, maybe the viewing-mode should be tracked with a cookie, so it's remembered inbetween sessons and a player doesn't have to change it all the time?) they should be shown with an image of their completed card,m with correct text on it and so on, just like the Gatherer works. I honestly think we want to avoid a default mode where every single card, no matter what status it has, is shown...


Or, what are your thoughts on that?
But still, it would be a great advantage to autogenerate the cards. It is worth a try once we have settled on all the possible symbols that may appear on a card.
Symbols that will be around are:

a) mark symbol ("tap") - this is a rectangle with it's long side on the ground and a number in it in some cases. (Which would mean, mark N others, while a numberless rectangle means "mark me")
b) faction logos
c) maybe a gold symbol

Other than those three, I don't really think more will show up, at least not the way I imagine it. Several months ago I was opting for using symbols for all kinds of stuff like abilities etc, but I think it's a mistake or at least something we should hold off for a while (unless of course one uses text and symbols for ability names instead of just symbols.)

Image

The pic above: Wouldn't it be able to use imagemagick or something else that's decent to plot the red border in the image above? If there is only a way to read the colour of each pixel in the image and check it for transparency or not, one should be able to plot a "border" on the piciture with a margin. While it won't be idiotproof without much efforts, it would typically show nice results. All those pixels can then be converted into coordinates for where the text boundries should. End result = autogened card that looks pretty decent and "understands" where the text should be placed or not.

However, I still think a built in app in the browser would be superior: A card web based creator. The user would start with selecting what kind of template it is, then what faction. He'd get an empty base. Then he'd layout the uploaded artpiece, and lastly the text, and then hit "save".

i think imagemagick could generate the text on the image, using whatever font we give it. Or maybe there are some smoother ways?

On the while issue with autogenerated cards vs handmade ones: Why would we want autogenerated ones if they can't really compete or hold the same quality as the "hand made" ones? Where and how and to what purpose would the "badly" autogened card pictures be used? Because, if they're not used in patches for online play, nor for playing the game on the kitchen table, then what's left?

I think you should do it the way you think it will work out the best when done by you. :) The only thing I really want to have there is the ability for us to override whatever is autogened with a "hand-made" pic of the finished card. So, whenever an autogened exists and a handmade exists, if both are connected to the same revision, then the handmade is auto-picked as the "correct" one. If however another revision is created and it lacks a handmade then it should use whatever us autogenned. (If so, maybe there should be an easy way for people to see a list of all cards that are the most recent revision and that lack a hand-made pic? That way somebody would easily be able to fix it and upload the hand-made pic. Else it would be hell tracking stuff like that.)
Then I propose a compromise: The user may either upload a file or he may link to a file on the internet. This file will be downloaded automatically. We can save the url where the image comes
Sounds smooth. :)
When a new (major) revision of a card is created, a new row is inserted into the database. This row has it's own id and has a field that is identical to the original card's id.
Problem I see with that layout is that there is no decent way to inform the player of what revision he's viewing: ID of the first revision could be 1, and ID of the second revision could end up being 100. If that's the case, what revision number do you show the user? My guess is your reply is "none" of the ID:s and none of the ANCESTOR-fields. Instead, you would use SQL to count number of rows from x to y and then display the currently viewed revision as "revsion z", where z is whatever you counted before. Am I right?

We must, in a very easy way, show people what "version", or rather, revision, of a card they are looking at. Each rev. should get it's own chronological number. First revision is the original card. Every other is one rev higher.

This is also connected with how we probably should identify cards in the game. Let's also keep in mind the cards will exist in more than the English language. So easiest way to actually idenitfy a card globally across languages and all, and the fastes way without using real words, is to give each card a unique identity number, just like most CCG:s already do (although they do it within respective set/expansion. I on the other hand suggest we do it globally, so there is only one card that has the number "1" and so on, so the numbering/identity doesn't re-set with a new expansion being released).

So, "Goblin against Wind" is the name of a card in English, but, it's card ID = INT set by us. That card ID is also a constant once it's set and can/may never change, no matter if the cards name, stats and so on changes. Now, on the bottom of each card, next to "copyright" info. the player should be able to see this unique ID number of each card. After that he would also be able to see the revision of it. So, for example: 1.13 would mean we deal with card number one, and revision 13 of card number 1. Only thing that changes is the rev number: IF ($edit == TRUE) {$rev_number++}

This would all solve several problems that will arise sooner or later due to us lacking a global and easy ID system printed on the cards. Players must be able to easily know which card they have in their possession and if it's up to date or not by looking at it's revision number.

I myself can't figure out a better way than the above one, but if you have a simpler solution I'm all (elf) ears. :)
User avatar
Ravenchild
developer
Posts: 131
Joined: Sat Sep 04, 2010 19:21
Location: Germany

Re: PHP script: card db

Post by Ravenchild » Sun Sep 12, 2010 21:59

snowdrop wrote:
  • Checkbox "I agree to bla bla bla..." with a link to a lengthy version of whatever the user agrees to by submitting anything at all to us. If the box is not checked, nothing is submitted. All info is just reloaded and a screen shows the user that she hasn't accepted the agreement.
  • Name of author and direct link to his site/and or e-mail.
  • A drop down menu where the user can pick what kind of license the art is under, listing the most common licensens + "other license, see link"
  • If "other is selected, the user has to input a link to the license
  • Custom text: A field where the user can input any additional commentary to the uploaded art?


In the footer of that page we would also have info text saying that WT.org doesn't take any responsibility for the users uploaded content etc.
Sounds sensible. Of course we should not hunt every new image down on the internet. But in case of single cards an URL is a good thing to start with.
Maybe we should even put stuff in a moderation queue? At least that's one way, maybe the safest, of doing it.
Yes. That's probably the best way for a relatively low volume of new images.
Okey, so, the db will fill at least two basic purposes: 1) Work as a database of all real cards. 2) Work as a tool to develop cards.
Correct.
However, whenever a player is just interested of browsing finished and officially approved cards (which maybe should be the default view/mode? Btw, maybe the viewing-mode should be tracked with a cookie, so it's remembered inbetween sessons and a player doesn't have to change it all the time?) they should be shown with an image of their completed card,m with correct text on it and so on, just like the Gatherer works. I honestly think we want to avoid a default mode where every single card, no matter what status it has, is shown...
The default search will only search for cards with the status 'accepted' so the user will not see unfinished cards if not explicitly requested.
Symbols that will be around are:

a) mark symbol ("tap") - this is a rectangle with its long side on the ground and a number in it in some cases. (Which would mean, mark N others, while a numberless rectangle means "mark me")

b) faction logos

c) maybe a gold symbol
You forgot the threshold bars ;)

By the way: Will it be possible for a card to have more than one faction as default? When I think about the big faction symbol, probably not.
Image
The pic above: Wouldn't it be able to use imagemagick or something else that's decent to plot the red border in the image above? If there is only a way to read the colour of each pixel in the image and check it for transparency or not, one should be able to plot a "border" on the piciture with a margin. While it won't be idiotproof without much efforts, it would typically show nice results. All those pixels can then be converted into coordinates for where the text boundries should. End result = autogened card that looks pretty decent and "understands" where the text should be placed or not.
That's possible, but I have a better idea: Before the user submits the image to our server, he should use his paint program to draw a 1 pixel thin border on the image. A human is much more reliable when it comes to visual separation and this step should cost the user not more than 2 minutes. And in relation to the preparation of the image itself, this is nothing.

But by the way: What kind of filetypes should be uploaded? png is fine for perfect images that do not need to be updated, but for later changes it would be advantageous to have the individual layers of the image.
However, I still think a built in app in the browser would be superior: A card web based creator. The user would start with selecting what kind of template it is, then what faction. He'd get an empty base. Then he'd layout the uploaded artpiece, and lastly the text, and then hit "save".
What kind of "layout" options do you wish to have?
i think imagemagick could generate the text on the image, using whatever font we give it. Or maybe there are some smoother ways?
I was rather thinking of the gd library with PHP.
On the while issue with autogenerated cards vs handmade ones: Why would we want autogenerated ones if they can't really compete or hold the same quality as the "hand made" ones? Where and how and to what purpose would the "badly" autogened card pictures be used? Because, if they're not used in patches for online play, nor for playing the game on the kitchen table, then what's left?
Consistency. If you change the cards text but not the cards image then you are (more or less) in trouble. People are lazy and this will happen.
And translations of a card can be quickly made without the need to run Inkscape. By the way, where are the card templates in the Bazaar?
I think you should do it the way you think it will work out the best when done by you. :) The only thing I really want to have there is the ability for us to override whatever is autogened with a "hand-made" pic of the finished card. So, whenever an autogened exists and a handmade exists, if both are connected to the same revision, then the handmade is auto-picked as the "correct" one. If however another revision is created and it lacks a handmade then it should use whatever us autogenned. (If so, maybe there should be an easy way for people to see a list of all cards that are the most recent revision and that lack a hand-made pic? That way somebody would easily be able to fix it and upload the hand-made pic. Else it would be hell tracking stuff like that.)
Could be easily done.

Which things do you consider, when creating an image of a card? The layout of the text, the background image, ... what else?
When a new (major) revision of a card is created, a new row is inserted into the database. This row has its own id and has a field that is identical to the original cards id.
Problem I see with that layout is that there is no decent way to inform the player of what revision he's viewing: ID of the first revision could be 1, and ID of the second revision could end up being 100. If that's the case, what revision number do you show the user? My guess is your reply is "none" of the ID:s and none of the ANCESTOR-fields. Instead, you would use SQL to count number of rows from x to y and then display the currently viewed revision as "revsion z", where z is whatever you counted before. Am I right?
Honestly, I don't think that revision numbers make that much sense in this context. What does it tell me, if a cards revision is 8? That there has been a lot of debate? Or that someone just played around a lot and always revised the card? What matters more is the state of the card which can be one of 'draft','discussed', 'playtested', 'rejected', 'accepted' and 'banned'. You can always check out the ancestor of a card if you are interested in its history. And if you really need to refer to a specific revision, you may as well use the cards id (which is accesible in the URL but I could also display it directly if neccessary).

There is a possibility to change a card without creating a new revision, but this should only be done for minor corrections.
We must, in a very easy way, show people what "version", or rather, revision, of a card they are looking at. Each rev. should get it's own chronological number. First revision is the original card. Every other is one rev higher.
I don't see much of an advantage to have subsequent revision numbers. The current implementation of my database lists the predecessor and all successors of a card along with the card. The status of each card is shown so that one can easily see which cards are official. To go forwards or backwards in time, just click on the ancestor or one of the successors. That should be straightforward.
This is also connected with how we probably should identify cards in the game. Let's also keep in mind the cards will exist in more than the English language. So easiest way to actually idenitfy a card globally across languages and all, and the fastes way without using real words, is to give each card a unique identity number, just like most CCG:s already do (although they do it within respective set/expansion. I on the other hand suggest we do it globally, so there is only one card that has the number "1" and so on, so the numbering/identity doesn't re-set with a new expansion being released).
We could just use the cards-table id entries.
For other languages we could use a separate table with only the rule- and flavortext and the id of the english card as the foreign key.
[...]on the bottom of each card, next to "copyright" info. the player should be able to see this unique ID number of each card. After that he would also be able to see the revision of it. So, for example: 1.13 would mean we deal with card number one, and revision 13 of card number 1. Only thing that changes is the rev number: IF ($edit == TRUE) {$rev_number++}
I agree with that in principle. But I don't see much of a point in using incremental revsion numbers.
This would all solve several problems that will arise sooner or later due to us lacking a global and easy ID system printed on the cards.
We should agree on the following: Each name for an official card is unique. Any older cards with the same name as a newer card are to be treated like the newest card.
Players must be able to easily know which card they have in their possession and if it's up to date or not by looking at it's revision number.
They may as well look at the id of the card. If another card with a higher ID and the same name exists, then this card is not up to date.
Granted, IDs are much more likely to be longer than revision numbers and therefore harder to compare, but it would work.

edit:
If you really insist on revision numbers I will implement them. But as for official cards I don't think there will be many revisions because each card is discussed and tested before it becomes 'accepted'.

Besides I would like to see cards with the status 'concept' to serve as a conceptual ancestor of several cards. In MtG there are often cards from the same edition which are similar to each other but which do not share the same colors.
I think we will have such cards as well and therefore it would be advantageous to link those cards to a common ancestor.
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: PHP script: card db

Post by snowdrop » Mon Sep 13, 2010 20:01

Oh, I forgot to mention it earlier: Make sure to comment the code in a basic way, so others can easily follow what you're doing, thus enabling the world to build up on it / release patches.

Ravenchild wrote:
Maybe we should even put stuff in a moderation queue? At least that's one way, maybe the safest, of doing it.
Yes. That's probably the best way for a relatively low volume of new images.
Make it configurable, so there's an option to turn it to auto-approve as well, so it can run mod/admin.-less. Maybe if you used a simple text file, i.e. config.var.php, that held all configuration for the script? (Unless ofc you want no config options at all or rather do it more "clean" and store config stuff in db... that said, some config stuff, about the db, can't be stored there anyway...)

Config file would have variables/constants in it, one per line and option, followed by // commenting what they actually config. Just an idea though, you can ignore all of this if it doesn't catch your eye.
The default search will only search for cards with the status 'accepted' so the user will not see unfinished cards if not explicitly requested.
Nice.


You forgot the threshold bars ;)
Ah,. Yes, I did: My bad, They should ofc also be around.
By the way: Will it be possible for a card to have more than one faction as default? When I think about the big faction symbol, probably not.
No, in the original rules concept (ORC) there won't exist multi-factioned creatures, at least not ones that have several faction icons printed on their cards. (There will exist cards that remove or change faction belonging (and abilities) though, but that's besides the point.)
That's possible, but I have a better idea: Before the user submits the image to our server, he should use his paint program to draw a 1 pixel thin border on the image. A human is much more reliable when it comes to visual separation and this step should cost the user not more than 2 minutes. And in relation to the preparation of the image itself, this is nothing.
Agreed.

But, due to pictures having very different colours in them, it might be an idea to let the user actually tell the site what colour he uses (i.e. #FFFFFF) for the border. Else, if we pre-define the border colour, we would sooner or later end up having problematic results perhaps.. hrm...

But by the way: What kind of filetypes should be uploaded? png is fine for perfect images that do not need to be updated, but for later changes it would be advantageous to have the individual layers of the image.
Good Q. PNG should be for all read-to-be-placed-on-template raster stuff, preferably as little compression as possible. (Dunno if that info can be ripped out of the PNG and we could even reject pictures that were too compressed? Maybe too strict, but it sure is tempting..)

JPG is pretty much useless since it doesn't support transparency and it's strength is the compresssion, which we don't want to use anyways. I don't know is BMP supports transparency or not, from what I can remember it doesn't, and files are immensly large, so might want to skip that as well. GIF = too low colour count, so, maybe we really should just stick to PNG? I mean, is there a good reason to use anything else really? It would also be nice since all the raster is PNG already (well, we could convert all, but then again . why so.)

Whatever we do, we really want to avoid using "exotic" and obscure file formats. If it was up to me we'd just stick with the PNG:s.

As for the layered original image, I think we should perhaps allow any and all formats, but recommend standard ones, i.e. Photoshop / Gimp etc. But, when uploading, it might maybe be an idea if people were forced to upload an archive, like rar, 7z, zip, tar, gz etc. That way people could also include a readme with info and what not and we would maybe end up saving server space? (I don't know how well Photoshop / GIMP-files can be compressed really, haven't done tests.) An option is of course to allow people to upload the files unarchived and let the server do so, I think it's easy accomplishing it with PHP. Don't know, whatever saves space on server is good. :P Especially as those files would actually all be moved to /trunk sooner or later anyhow...






However, I still think a built in app in the browser would be superior: A card web based creator. The user would start with selecting what kind of template it is, then what faction. He'd get an empty base. Then he'd layout the uploaded artpiece, and lastly the text, and then hit "save".
What kind of "layout" options do you wish to have?

User should be able to:
  • Pick template/card type (i.e. Creature, Event, Equipment, Magic...)
  • Name card freely, up to x amount of chars.
  • Input card subtype and/or select from a list of already existing types. (AJAX search while typing? Dunno..)
  • Select number of threshold bars shown. (0 to 4, where 0 is defult)
  • Place card art by selecting one of the following options for how the "app" places the image: Align card art picture to the left, to the right, center.
  • Needless to say, the creature card template differs from the other templates, thus the above will have a somewhat different implication on where the art is actually placed.
  • Fill in combat stats (Integers value accepted, 0 to 20, x and - )
  • If one would want to allow the users to upload an image of any resolution and then resize / crop it to create card art form it, there would need to be some ways to handle all of that and how the user specifies huge area the art would take on the card template. That said, I think this is cool, but overkill, and our finished autogenerated card images will probably be of a fixed size anyways so we could just demand that the user uploads the card art in the correct size to begin with. Totally up to you, I just see a lot of coding and a can of worms and little gain except coolness here.
  • Faction selection. (Then again, that could be selected when selecting what template to use - i.e. Elvish Magic, Orc Event etc etc, and that would have the correct factiobn logo in place...it's a dirty solution though. So, first the user clicks what type of card/template, then faction, and when that is done, an empty template with that faction is loaded and shown. Then the user starts filling in the rest... or in any order really...)
  • Font size?
  • Line breaks?
  • Italic? (I.e. I want to create a card with an ability, and te ability name should be in Italic)
Consistency. If you change the cards text but not the cards image then you are (more or less) in trouble. People are lazy and this will happen.
And translations of a card can be quickly made without the need to run Inkscape. By the way, where are the card templates in the Bazaar?
True.

Templates = Rebels.svg, should be in the root of the trunk I think. It's Inkscape SVG XML and as such it can totally be manipulated from PHP ;) (Yeah, there are a zillion possibilities here...)

If you download it make sure to do a search and replace in a text editor so all paths actually become relative to the raster stuff the template(s) point to in the trunk. Stupidly I think it has my real paths saved in it...





Which things do you consider, when creating an image of a card? The layout of the text, the background image, ... what else?
Background image, if that is the map-texture, I guess we should use a different map for every Faction, would be cool. This far we only have the Elvish-faction (Rebel + Merfolk + some humans = Gaia faction) template, but the other factions will look the same, just use different "border" colour (the green as seen now = Gaia, Red banner will have Red etc), logo and texture.

I think I covered it all in a previous paragraph. I hope. :P


Honestly, I don't think that revision numbers make that much sense in this context. What does it tell me, if a cards revision is 8? That there has been a lot of debate? Or that someone just played around a lot and always revised the card? What matters more is the state of the card which can be one of 'draft','discussed', 'playtested', 'rejected', 'accepted' and 'banned'.

It shows how many times a card has been revised. (In your suggestion only way to understand that it has been revised at all would be to go online and check history) It also keeps the numbers low, and, it keeps them in a logical order. Revision 7 is lower than revision 9, and we will know, by having only the revision 9 card in our hand, that there were 8 previous revisions, and by having the 7 one as well in our hand we know that there is one revision between 7 and 9 - rev. 8.

I agree 100% that what matters more is the state of the card, as you describe it. That put aside, there is no conflict of interest between the two priorities - the state of the card is one thing, the revision number (however it is expressed) another one.

There is a possibility to change a card without creating a new revision, but this should only be done for minor corrections.
Yups, we've agreed on that. Sounds good.
I don't see much of an advantage to have subsequent revision numbers. The current implementation of my database lists the predecessor and all successors of a card along with the card. The status of each card is shown so that one can easily see which cards are official. To go forwards or backwards in time, just click on the ancestor or one of the successors. That should be straightforward.

/../
snowdrop wrote:[...]on the bottom of each card, next to "copyright" info. the player should be able to see this unique ID number of each card. After that he would also be able to see the revision of it. So, for example: 1.13 would mean we deal with card number one, and revision 13 of card number 1. Only thing that changes is the rev number: IF ($edit == TRUE) {$rev_number++}
I agree with that in principle. But I don't see much of a point in using incremental revsion numbers.
Why this is needed at all

I imagine that the game will be both printed and played with by using real physical cards, as well as played with by using digital patches for online play for already existing virtual tables, i.e. OTCGN2 & LackeyCCG.

Sooner or later we as devs will revise a card that has been in use for a while and that for some reason craved love. This happens to all good CCG:s and is a sign of maintenance, us balancing the game as we or the players discover problems and issues with mechanics, rules, wording, art etc. That much we already know, that moment will come.

When it does most of the existing players will already have a copy of the card(s) that have been revised. Thus, they will, with us revising the cards, suddenly have an outdated copy of the card in their possession & in their decks. This will be true no matter if they play the digital or paper version of the game (unless of course, somebody also codes a digital version that is only played in a browser, in which case all cards would always be up to date, but that's off topic ...)

What the players need is a simple and easy way to properly identify if they have the most current version of a card. Why do they need that? And what do casual players care about all of this? Those are good questions.

I'd claim that most really casual players are not into this kind of stuff and they seldom read erratas, corrections etc released for their games after the game has been published.

That said, WT also targets players that are very competitive and that will stay up to date, read such documents and that will want the updated and most recent versions of the cards. WT strives to be a fully viable option for that target group and we want to insure that the 'pro' players get both the updates they need and also means of easily keeping track of them.

Please check out each cards bottom right corner:
http://chaosrealm.net/wtactics/files/pi ... olkrev.png

Top: The top two cards are identical, they just use different revision systems.
Bottom: The bottom cards are identical, they are just one revision newer than the above cards, and they still use different revision systems.

Left: The system I suggest can be illustrated by the cards to the left on the picture.
Righ: The system you suggest, if I indeed understand you correctly and with a reservation for my slowness ;) is represented by the cards on the right.

My suggestion
  • Each card gets a unique ID the day it's marked as accepted. (Meaning, that the card with the highest number shows how many official card there are in the game.)
  • ID:s are permanent constants - they never ever change. They are also the same no matter what language the card is in and no matter what card art is used. They are the most secure and definitive way to identify a card.
  • Each card gets a rev. number that's subsequent. That number shows (indirectly) how many previous revisions prior to that there have been.
  • For a player to easily check if his "Magic Sword of Urza'kai" is up to date, he just checks the "Magic Sword of Urza'kai"'s ID and rev number, which in this example is, 5.3, where 5 is the cards unique ID and the .3 is it's rev. number. He now compares that with the info online, which would show 5.5. Meaning, there have been two revisions since he last updated his card.
  • A player could of course use your system and by using the name of the card coupled with the unique ID each revision gets (2, 46, and maybe 300 if revised much later) he could do the very same thing. Fair enough, but, it isn't systematical, it's hard to follow, and, how do we do that cross-lingo anyways? Names will differ depending on language, that alone makes it a bad idea to depend on them. Furthermore, it is less smooth to search by names compared to searching by numbers - even in cases where the search is an input box on the web.
This would all solve several problems that will arise sooner or later due to us lacking a global and easy ID system printed on the cards.
We should agree on the following: Each name for an official card is unique. Any older cards with the same name as a newer card are to be treated like the newest card.
Yups, each name should indeed be unique. But, I don't agree on using names as the unique ID, nor as any hardcore way of identifying the cards really. Reason is, beyond what I argue in the above, that it seems very strange that a name change would equal to us actually having created a new card.

Let's play with the following thought: Pick a card in any CCG you happen to have around. Look at it. Now change only the name of it. Look at it again: Is it he same card?

Per many CCG definitions, it is not. However, I honestly believe we shouldn't take that path with WT. Reason is that a new card should be constituted by it's functions primarily. Not by it's flavour. Now, I'd define card art, and card name, and any and all text that has actually little to no relevance for the rules, as flavour (i.e. as I would with flavour text).

Without getting into philosophical topics (I'd actually love to do that but won't in here) I think we as devs should stay pragmatic. Surely if a card plays the very same way and even looks the same way, and the only difference is it's name, we have not really, functionally, created a new card? At least I would argue we have not done so.

If not, the card should also not be treated as such. it should keep it's unique ID (i.e. a constant number). It seems logical, and it also allows us to change/adjust names of cards without actually stating they're a new card.

Sidenote:

Now one might wonder how, if ever, we with my line or reasoning can actually create a new card by changing all functions of a card with ID 4. I'd agree that we would indeed create a new card, but, by doing so, we would kill of the original ID 4 card. And by doing so we would also act confusing. However, the option is there. Not that I'd recommend usage of it, but what is nice is that we'd still end up having a system with an "order" within.

The most proper way to express all of this is maybe that I want a system where a cards number corresponds to what SLOT that card has if we take all the cards in WT and put them in a long line next to each other. If we have 100 cards, then our first card would have ID number 1 and last one would have 100. No matter what we change or edit, no matter what card we kill or revise, it will always be somewhere on that line.

Players must be able to easily know which card they have in their possession and if it's up to date or not by looking at it's revision number.
They may as well look at the id of the card. If another card with a higher ID and the same name exists, then this card is not up to date.
Granted, IDs are much more likely to be longer than revision numbers and therefore harder to compare, but it would work.
[/quote]

Hrm. We have the cross-language problem, and we have the name-changing problem. But yeah, except for those, I agree that a player could very well compare two cards if he understood they were "the same card", and by seeing that one has a higher ID number than the other he would understand which one is newer. That I follow.

But, why have the problems at all? And, why have a numbering system that is less usable than what I suggest?

I claim that the original suggestion (unique constant ID dot rev.number, i.e. 1.4) is

a) easier to use (no name reading or comparing or translating needed)

b) also solves some problems (can't translate, wrong impression of a new card being created etc)

c) gives more info (what card slot, amount of cards in game, revisions between two select revisions, number of revisions done of a specific card). Add to that it gives this more info with less characters used, as name doesn't have to be a part of the equation.

d) is easier to follow and appears to be less "random" - subsequent numbering is intuitive.

e) The players are already accustomed to a similar system: The "collectors numbering" that many CCG:s have, i.e. card number 120 / 300 would mean, in most CCG:s, that the card's number is 120 and there are 300 cards in that set. I'd argue people are already familiar with the slot system like this and that we could take advantage of that.
User avatar
Ravenchild
developer
Posts: 131
Joined: Sat Sep 04, 2010 19:21
Location: Germany

Re: PHP script: card db

Post by Ravenchild » Tue Sep 14, 2010 00:18

snowdrop wrote:Oh, I forgot to mention it earlier: Make sure to comment the code in a basic way, so others can easily follow what you're doing, thus enabling the world to build up on it / release patches.
Of course. This discussion has brought a couple of new requirements for the software so that I need restructure it. Once the skeleton stands I will check in the code into the bazaar repo. I suggest that the card database code should live at /code/database

Besides, it would be cool to have a name for the database software ;)
Ravenchild wrote: Make [moderation queue] configurable, so there's an option to turn it to auto-approve as well, so it can run mod/admin.-less. Maybe if you used a simple text file, i.e. config.var.php, that held all configuration for the script? (Unless ofc you want no config options at all or rather do it more "clean" and store config stuff in db... that said, some config stuff, about the db, can't be stored there anyway...)
I still haven't decided what the admin interface will be like. But some config variables need to be in a PHP file to establish a database connection with a username and a password.
But, due to pictures having very different colours in them, it might be an idea to let the user actually tell the site what colour he uses (i.e. #FFFFFF) for the border. Else, if we pre-define the border colour, we would sooner or later end up having problematic results perhaps.. hrm...
The most straightforward solution would be to let the user set the pixel at the position (1,1) to the border's color. But I don't know if modern image programs make it that easy to manipulate one single pixel :lol:
Good Q. PNG should be for all read-to-be-placed-on-template raster stuff, preferably as little compression as possible. (Dunno if that info can be ripped out of the PNG and we could even reject pictures that were too compressed? Maybe too strict, but it sure is tempting..)
Do not let computers rate art :lol: I don't think that a limit may be appropriate. Maybe someone just wants to upload a black and white image because he is really bad at coloring images? It would still be possible for someone else to improve the image further.
I don't know is BMP supports transparency or not, from what I can remember it doesn't,
Correct.
maybe we really should just stick to PNG?
yep.
As for the layered original image, I think we should perhaps allow any and all formats, but recommend standard ones, i.e. Photoshop / Gimp etc.
I'm not sure if we should allow proprietary formats. Idealy all files should be editible by everyone.
But, when uploading, it might maybe be an idea if people were forced to upload an archive, like rar, 7z, zip, tar, gz etc. That way people could also include a readme with info and what not and we would maybe end up saving server space?
That's a good idea. But we still need another way to distribute these files. The best way is probably to create a thumbnail of each image and make those thumbnails browsable on the web page. Any user may then select to download the original images.
You really don't want artists to check out the entire bazaar repo ;)
Especially as those files would actually all be moved to /trunk sooner or later anyhow...
If we compress the image files, every minor change in the archives contents will result in a mayor change in the binary structure of the archive itself. That means that the SCM will see a big change where only a minor change occurred. This leads to less binary redundancy and more bloat in the SCM.

[*]Needless to say, the creature card template differs from the other templates, thus the above will have a somewhat different implication on where the art is actually placed.
Where is the creature template located in the bazaar repository?
[*]Faction selection.
What factions will exists? Are they identical to the Wesnoth factions? Or will they be these factions?
[*]Font size?
Not really useful. All cards should have the same font size.
It shows how many times a card has been revised. (In your suggestion only way to understand that it has been revised at all would be to go online and check history) It also keeps the numbers low, and, it keeps them in a logical order. Revision 7 is lower than revision 9, and we will know, by having only the revision 9 card in our hand, that there were 8 previous revisions, and by having the 7 one as well in our hand we know that there is one revision between 7 and 9 - rev. 8.
I don't think that's valuable knowledge. But I will not argue on such a small matter.
Please check out each cards bottom right corner:

http://chaosrealm.net/wtactics/files/pi ... olkrev.png

Top: The top two cards are identical, they just use different revision systems.

Bottom: The bottom cards are identical, they are just one revision newer than the above cards, and they still use different revision systems.

Left: The system I suggest can be illustrated by the cards to the left on the picture.

Righ: The system you suggest, if I indeed understand you correctly and with a reservation for my slowness ;) is represented by the cards on the right.
Correct
[*]Each card gets a unique ID the day it's marked as accepted. (Meaning, that the card with the highest number shows how many official card there are in the game.)
That would probably mean separate tables for accepted and cards in development. I'm afraid that will break ancestor-relationships unless we only store the development IDs in the official database.
[*]ID:s are permanent constants - they never ever change. They are also the same no matter what language the card is in and no matter what card art is used. They are the most secure and definitive way to identify a card.
Agreed
[*]Each card gets a rev. number that's subsequent. That number shows (indirectly) how many previous revisions prior to that there have been.
Your system is linear. It only allows one direction of development. If we structure the relationships of the cards as a tree, people may fork cards as they like and the best proposed successor wins.
[*]A player could of course use your system and by using the name of the card coupled with the unique ID each revision gets (2, 46, and maybe 300 if revised much later) he could do the very same thing. Fair enough, but, it isn't systematical, it's hard to follow, and, how do we do that cross-lingo anyways? Names will differ depending on language, that alone makes it a bad idea to depend on them. Furthermore, it is less smooth to search by names compared to searching by numbers - even in cases where the search is an input box on the web.
This should not be a problem. I still don't understand why it should matter whether there are 3 newer revisions of the card or if there is just one. The card is outdated in any case (if the newer version of the card still has the same name).
Getting the latest revision of the card is easy as it is the last card in the DB with the same name.
For translations there will be a table like this:

Code: Select all

id INT AUTO_INCREMENT PRIMARY KEY,
card_id INT, -- foreign key to cards table
name VARCHAR(31),
rules VARCHAR(255),
flavor VARCHAR(255)
Every non-English card is easily linked to the English revision with the card_id field.
If someone creates a revision of a card, the user interface should ask the user if he wants to keep the name of the card. In that case a new entry for each translation will be created automatically with the old name and the rule- and flavortext set to "This card has not been translated yet"
We should agree on the following: Each name for an official card is unique. Any older cards with the same name as a newer card are to be treated like the newest card.
Yups, each name should indeed be unique. But, I don't agree on using names as the unique ID, nor as any hardcore way of identifying the cards really. Reason is, beyond what I argue in the above, that it seems very strange that a name change would equal to us actually having created a new card.
To my knowledge that's how MtG does it. Of course they do not change cards completely but fix errors or adjust the text to be less complicated. A classical example would be Gaea's Liege (note the "Leige" spelling mistake in the fourth edition).
Some cards inspire other cards. For example Uktabi Orangutan inspired Uktabi Kong. There are also a lot of lotus cards that are inspired by black lotus but are not as imbalanced as their predecessor.
Because of this inspiration, both, the card itself and its successor (with a different name) may be official cards.

The most proper way to express all of this is maybe that I want a system where a cards number corresponds to what SLOT that card has if we take all the cards in WT and put them in a long line next to each other. If we have 100 cards, then our first card would have ID number 1 and last one would have 100. No matter what we change or edit, no matter what card we kill or revise, it will always be somewhere on that line.[/i]
So if we ban a card without replacement, there will be a permanent hole in the line?
But, why have the problems at all? And, why have a numbering system that is less usable than what I suggest?
Because I see more creative freedom in a tree-like development line.
a) easier to use (no name reading or comparing or translating needed)
Now that confuses me. Reading names should be easier for humans than reading numbers.
b) also solves some problems (can't translate, wrong impression of a new card being created etc)
Translations are not a problem. The translation table uses the English cards ID as the foreign key. And I need to emphasize that successors of cards do not need to replace the old card. If they take up another name, they are considered as new cards that have been inspired by the old card.
c) gives more info (what card slot, amount of cards in game, revisions between two select revisions, number of revisions done of a specific card). Add to that it gives this more info with less characters used, as name doesn't have to be a part of the equation.
If we use the card slot concept, this would not tell us the amount of cards in the game, because some cards may be banned without replacement. And you know my opinion on "number of revisions" ;) Maybe you could give an example when such a number is useful.
d) is easier to follow and appears to be less "random" - subsequent numbering is intuitive.
I agree on that.
e) The players are already accustomed to a similar system: The "collectors numbering" that many CCG:s have, i.e. card number 120 / 300 would mean, in most CCG:s, that the card's number is 120 and there are 300 cards in that set. I'd argue people are already familiar with the slot system like this and that we could take advantage of that.
Are we planning to do anything like editions? I seem to recall that you wanted to release new cards when they are ready and not in big chunks. In this case, the 300 would soon be wrong, as new cards get released ;)


edit: I'd like to add one more thing: We have agreed on the possibility to make minor changes to a card in a database without changing the revision number (or the ID). This possibility should only exist for the author of the card and the database admins. If someone wants to improve a card, he must either write a note to the author or create his own version of the card.
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: PHP script: card db

Post by snowdrop » Wed Sep 15, 2010 20:52

Ravenchild wrote:This discussion has brought a couple of new requirements for the software so that I need restructure it. Once the skeleton stands I will check in the code into the bazaar repo. I suggest that the card database code should live at /code/database
Path seems fine, but as you suggest later on, we/you should find a better name than just "database" as it sounds not too shmexy ;) Maybe something like "CCG db" or whatever that's generic and functional, or even WT specific if there aren't plans on making it generic and ũbercustomziable. "Book of Cards" - "Cardbook"... "rooster"..."kingdom"...etc... :P

About the repo: This is my first time using Bazaar, and I went with it for not particular reason other than I wanted to try it out and see what it did better / differently than SVN that I worked with when in a project on sourceforge (wesnoth ladder, php).

I have no clue how to add you so you can commit to it and get full access and all, but I guess a start would be for you to sign up on launchpad perhaps. I'll check into it as soon as I get a chance and will give you full rights once I figure it out.

Or, maybe it should be a project of it's own? I don't know what the smoothest solution would be really. Both ideas have their appealing points. We'll do it however you think is best. GIven the small size of it, it wouldn't at all be a problem having it in the "main WT" one. :)

Ravenchild wrote: I still haven't decided what the admin interface will be like. But some config variables need to be in a PHP file to establish a database connection with a username and a password.
I'm a huge fan of config via text-file, but that said, most users aren't and expect a nice GUI / webform or whatever when configuring stuff, even if they are PHP. Your call. I'm happy as long as it is configurable and code and all is commented. Would love to add stuff to this next summer if I can grasp the code and it's easy to follow = P
The most straightforward solution would be to let the user set the pixel at the position (1,1) to the border's color. But I don't know if modern image programs make it that easy to manipulate one single pixel :lol:
But, that would mean that all pictures actually have a pixel that shouldn't be there at all, and, the odds it is visible maybe are higher given the fact that it must be a colour that is totally different from any/all other colours in the pic. Also, we have the issues with people placing the pixel slightly of coordinate etc.

I still think the best and simplest way is to just let the user specify #FFFFF etc in a field,it should be more foolsafe and faster, but, as I don't code, in the end I think it's your call. :) There's nothing worse than an idiot telling you what you should code or not on your spare time, especially if you happens to disagree ;) ...I've been in that situation myself and know the drill all too well.
maybe we really should just stick to PNG?
yep.
Agreed then. :geek:
As for the layered original image, I think we should perhaps allow any and all formats, but recommend standard ones, i.e. Photoshop / Gimp etc.
I'm not sure if we should allow proprietary formats. Idealy all files should be editible by everyone.
[/quote]

I'm a very huge fan and advocate of open source as it shows if you've read around the FAQ or in the Wiki (would never use anything but Linux unless forced to, always choose open source before closed etc), but that said, I am also a pragmatic and don't think plato's idea world or any similar concepts should effect us too much. In this case, my experience is that 99% of all pro artists that WT will ever deal with (mainly raster artists) use some version of Photoshop.

We simply must support the upload of any fileformat (within the archieve, if we use that at all). Very few pro artists, even though numbers grow steadily with time and intro of new good open source software, use software like GIMP: They simply don't care about open source nor do they, themself, see or understand the reasons that would make them invest countless of hours into a program that from their perspective is somewhat inferior to Photoshop, especially when they already are masters of PS.

Trust me, I have had this discussion with several artists, and even though I was paying them they would ofc still refuse to re-learn just for one client and lacked personal interest.

Sum of all fears: We must allow other formats, closed or not, and if we don't, we will end up getting close to no source files at all. That is counter productive for WT and hinders the project.

Btw: I actually do open all the WT photoshop files and toy with them in GIMP with good results. Not that it matters much, but could be worth knowing.

I do however feel we should strongly encourage people to use open source software etc, and maybe even urge them to transfer the original art from a closed source into an open source format by just copy & pasting layers ;) if possible...


That's a good idea. But we still need another way to distribute these files. The best way is probably to create a thumbnail of each image and make those thumbnails browsable on the web page. Any user may then select to download the original images.
You really don't want artists to check out the entire bazaar repo ;)
Yes, a gallery would make access easier to them. I'll set one up that's open source in a not too distant future. Most good galleries generate the thumbs themself. Agreed on that solution?
If we compress the image files, every minor change in the archives contents will result in a mayor change in the binary structure of the archive itself. That means that the SCM will see a big change where only a minor change occurred. This leads to less binary redundancy and more bloat in the SCM.
Not that it's a good reply, but isn't this true even when the image files are un-archieved? Aren't they treated as binary ones by Bazaar? Hrm....

Compared to the version control systems handling of changes in code I know and agree it looks stupid now, but, I still lack a better and easier system for us as devs. Besides - the bandwidth and size isn't much of an issue right now and will probably not become for a long time. When it does become an issue though, maybe there's an option to permanently zap super old revisions, to save space? I dunno...

I have been looking at Sparkleshare (which uses GIT?) and think it answers a lot, but maybe not this particular problem.



Where is the creature template located in the bazaar repository?
Same as the Event-template: Rebels.svg
That said, several (most old) versions of it exist side by side in that file. Only one or two are actually "current".

Will have to get back to you on which that is in the weekend and will also clean up that file so it gets rid of all the crap.
What factions will exists? Are they identical to the Wesnoth factions? Or will they be these factions?
The link you posted is pretty much correct. I still haven't finished that text but am currently doing the Elfs + Merfolk (Gaia) and will do the others as soon as possible (weekend in best case).

The cultures within the factions are based on the Wesnoth universe, and so are the species. The names of the factions, the surrounding story, the social/economical/enviornemental and darker tone though is totally not Wesnoth, but something I'm quite fond of and will keep for the ORC. Actually, now that I think of it, I would love it if WT could become a somewhat darker and grimmer fantasy world in contrast to the peachy generic fantasy theme. Personally I like the "dirt" found in cyberpunk and post-apocalyptic stuff and would fancy a stroke of that in WT, but in accordance to the setting of course.
Not really useful. All cards should have the same font size.
Even WotC doesn't do that: Much text requires smaller size, less text means we could use larger size and make life easier on the player. I.e. max size of card text = 12 and min size = 9. And it would pick font according to how many characters etc were in the text.

Many online CCG:s autogen their cards (it seems, or, I hope, since it actually seems they do so) and it strikes me how crappy layout they have: They can use small default fonts and have cards with an almost empty text area - why on earth is that? What is gained by that? Sure, text size stays consistent, but in that case it does so for a high cost.

This isn't an issue I'm willing to die for though, but it does beg the question why some games select the same (small) font on all cards when they clearly could have used a bigger and more easily read one on the cards with less text on them.
That would probably mean separate tables for accepted and cards in development. I'm afraid that will break ancestor-relationships unless we only store the development IDs in the official database.
Yes and no: I mean, is it a bad thing if there were two tables, one for cards in dev and one for cards declared official and "100% done", those that are part of the game, have art and all and are ready to be played with?

If we do indeed use 2 tables instead of one you don't have to break the ancestry system you suggest: Keep it, but, let's just use it in the dev-part of the app, and in the dev table. Once a card is mature enough one would set it do "accepted" or whatever in the dev table, and the revision that was marked as such would be cloned into the "finished table", where we use a totally different system - the one I suggest, or a version of it anyway.

So, in actuality, no card is ever edited in teh "finished table". There they are just for show. All real dev work is done in the dev. table, and there a player could fork etc and everything you suggested as it makes perfect sense.

Here's how it works:

In your system, card ID 220 is now marked as "accepted". It is then automagically cloned into the "finished table". There it gets a) a slot number b) a revision number. It's slot number never changes and is always the previous cards number + 1. Let's say the slot number is 321. When a new card is created this way, it always starts with revision number 0. So, the cards full ID number in my sys would be: 321.0

The revision number in my sys changes only whenever a new revision of your ID 220 is created (i.e. your ID 467) and that card is also set to "accepted". When that happens, my revision number would change to 1, thus the ID in my sys would automagically become 321.1

Now, the interesting part with this is not that it might be confusing to the normal player. The normal player is and will remain clueless about this process and "beta" and "official" ID:s. It is interesting as developer, because it retains all the pros with your suggestion and combines it with a logical slot system.

Even better, it makes the revision system on the "official" "accepted" card's ID actually reflect how many "acceptances" a card got instead of how many time it's entry was edited in the dev table. That in turn means that we could have a lengthy discussion about a card, make 27 revision in the beta-table, and still no sign of that stuff until we are ready for a sharp release in the official table. So far so good, I think.

The above is just an idea I just got. Even if one didn't want to use the specific revisioning system of the official accpeted card as I just described, I still think the right course could be to follow both of our ideas but to keep them in separate tables.


Your system is linear. It only allows one direction of development. If we structure the relationships of the cards as a tree, people may fork cards as they like and the best proposed successor wins.
Fixed above, I think. It should spur people to play even more now.
Every non-English card is easily linked to the English revision with the card_id field.
A thing just hit me: Say we have 300 cards in the core set. Say we input every sinlgle one of them now. Then we revise each card 10 to 20 times. That means the ID numbers become high pretty fast. I don't know what ranges we'd have in the end, but if we keep on a) releasing new stuff b) maintaining it and c) allow people to submitt their own stuff and others to fork, revise etc, then it surely will very fast be in the range of thousands, not hundreds, when looking at an ID. That is a strong argument against using such a system as the official system. (Here I also belive my own suggestion is bad enough, but, I'm afraid it can't be made any simpler than that, short of cutting away the revision number and just keeping the slot number).
Because of this inspiration, both, the card itself and its successor (with a different name) may be official cards.
I welcome cards that are inspired by others. The problem isn't how the idea came to be, if it was elvis that inspired the dev or another card from another dev. The problem is why we'd ever want to know or track such inspiration, especially since it many times will come from external sources (i.e. an MtG card, not another WT card).

Revision system and ancestry should, for that reason, not mainly be used as a genealogy instrument to track down influence. If the revision system can do that it is a fine and really impressive bonus, but, revision system itself should focus on keeping track of what changed, by whom and why etc, and present that info neatly and make it usable.

If the card itself contains info about it's revision printed on it (and I think it should, else there is no easy way for the player to know what's been updated or not, and that's a no-go) that info should be as easy as possible to compare with the info on the "same" card of another revision. To me, that translates to as low and as few revision numbers as possible. With the mixed system I suggest above, by using both ID systems, one for each table, we'd accomplish just that: Instead of a card exsisting as 436, 792, 888 and 1920 through it's revisional cycle, or 300.1, 300.2, 300.3 and 300.4, it could go through the same cycle and just officially exist as accepted 300.1 and 300.2, since beta-ID 798 and 888 were never "accepted" and needed tweaking, and it took until beta ID 1920 until we were ready to release official-ID 300 into it's 2:nd rev.




The most proper way to express all of this is maybe that I want a system where a cards number corresponds to what SLOT that card has if we take all the cards in WT and put them in a long line next to each other. If we have 100 cards, then our first card would have ID number 1 and last one would have 100. No matter what we change or edit, no matter what card we kill or revise, it will always be somewhere on that line.[/i]
So if we ban a card without replacement, there will be a permanent hole in the line?
I think my current suggestion is somewhat more clever than my initial one, thanks to your questions.

Now the answer is "No, there won't be a hole - we'd just replace the card in thats lot with a new card and fill the gap." That new card could be a heavily revised version of the banned card, or something that elates to it thematically to make the transition easier to the playerbase, but, it could in theory also be brand spanking new. IN any case, total banning is and should be a very rare deal, especially in a game that's developed as WT is. in case it happened though, this would be the way to go.

If I called the shots I would never declare a card as banned in WT. I'd even go as far as having a dev rule saying "Cards can not be banned. They can only be revised until made functional and balanced." That would of course mean heavy revision in some cases, but if so, then so be it. That's no problem. Problem is only there (ID wise) if one starts banning.

Again, to the playerbase the interesting stuff is that the cards "spirit" and "function" is still the same and the mechanics / theme / basic idea with the card is still on the same track as the flawed and first version of it. It's all about player's perception of what happens with a card, and they perceive banning as one thing, and revision as another (although they from a dev. standpoint many times overlap and can be equated in several regards.)


But, why have the problems at all? And, why have a numbering system that is less usable than what I suggest?
Because I see more creative freedom in a tree-like development line.
If so, it should be there in my latest suggestion as well. Unless I unintentionally killed something of :oops:
a) easier to use (no name reading or comparing or translating needed)
Now that confuses me. Reading names should be easier for humans than reading numbers.
Remembering 1 up to 3 numbers (the "official ID" ones, remembering the rev number is not necessary to ID the card, only necessary to get to know if it's the most recent update one has in his hand) seems way easier than remembering a name.

Even more so when names start to sound strange and fantasy-ish and are not always common words. Looking for a number in a list is also speedier, and add to that the "the" problem with the English (official language) cards that have names that start with "the" and you must jump over it to the second word to actually start comparing anything.

Also add that it's easier to search for a number than having to type the whole name (which ofc doesn't exclude the possibility that the search in the db should also allow search by name): Example is all sane stores that let the customers write short product ID:s/numbers and search for the specific product in the store, instead of inputting it's model name or brand etc. If names really are superior, don't you think that the powers of commerce IRL would abolish that system and force people to search on names instead? ;)



If we use the card slot concept, this would not tell us the amount of cards in the game, because some cards may be banned without replacement. And you know my opinion on "number of revisions" ;) Maybe you could give an example when such a number is useful.
I am still not against the "number of revisions" idea, but what I present in the above does not use it. That said, I will give you a case where that number does actually matter and can very well be useful: It tells us a) how problematic a card has been and/or b) how many times a person has failed in properly revising it. These two partly overlap each other, and I agree the info isn't vital, but it could be used to analyze questions like "which type of cards tend to be subject for more revisions than the average / what is the average / median etc". It makes such questions possible, although that kind of work isn't something I prioritize right now, and it also doesn't necessarily need my old revision system.

As for the banning issue: It's fixed above. There are no bans. Only revisions. I have a hard time imagining there could ever exist a card that's so broken and unfixable that a heavy revision wouldn't both keep some of it's spirit as well as make it at least "playable".



e) The players are already accustomed to a similar system: The "collectors numbering" that many CCG:s have, i.e. card number 120 / 300 would mean, in most CCG:s, that the card's number is 120 and there are 300 cards in that set. I'd argue people are already familiar with the slot system like this and that we could take advantage of that.
Are we planning to do anything like editions? I seem to recall that you wanted to release new cards when they are ready and not in big chunks. In this case, the 300 would soon be wrong, as new cards get released ;)
Here I explained myself badly and apologize for that:

I am against using a "collectors number" like 20 / 300, which would mean "This is card 20 of 300 cards in this set". As you point out, such a system would be outdated the second it was established in WT as we will keep on releasing cards and would also do it in mini-expansions instead of the casual 100- 200 card range per expansion. (All that has to do with economy and also strategy and signs of life etc... I think it's a very good move by us and that it will prove to be the correct one, but let's discuss that in another topic if needed)

What I meant to relay was that the playerbase is already accustomed to thinking in "slots". When she sees 20 / 300 she knows that the card in her hand is "card 20". Card 20 is the card's ID, at least in that set. Now, as you point out, many CCG:s use the names as ID:s. Reason for that is, I'd argue, not that name usage as ID is a good move. It's not. They do that because they use the slot system combined with the collectors touch - "card 20 of 300" - and they do so on a per set basis. Hence, card 20 / 320 of MtG could very well also exist, even though 20 / 300 exists. They are different cards, and they globally are mainly ID:d not by their slot number but by their name.

Since we won't care about the collectible shit and also can't offer the "of 300"-number ever in an accurate way we will omitt that number altogether. It lacks meaning in WT. So far, we agree, I think.

So, why can't we make it the other way around with WT? Instead of using name as global ID and numbering as local set ID (as MtG / all do), we will use number as global ID, and name as no ID at all since it's not actually needed (and still available to be used as such should one feel the urge)?

I don't want WT to have fragmented meaningless quasi-ID numbers like most CCG:s have. Again, they are more or less forced to stick with their crap system because they have the "of 300" number and release cards in sets, and each set resets the numbering. Conclusion from the commercial CCG:s - they use the numbering and slots mainly as a collectors gimmick, not for ID purposes. We should however do it the other way around, as suggested above.

edit: I'd like to add one more thing: We have agreed on the possibility to make minor changes to a card in a database without changing the revision number (or the ID). This possibility should only exist for the author of the card and the database admins. If someone wants to improve a card, he must either write a note to the author or create his own version of the card.
Agreed.
Locked