PHP script: card db
Posted: 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
And GPLv2 is okay. Maybe I'll even pick AGPLv2.
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"
For each card the predecessor and the successors are always listed.
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)
Very good point. Currently the search uses POST but I can change that of course.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.
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.Nice.- card creation
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 =)
And GPLv2 is okay. Maybe I'll even pick AGPLv2.
It's already done that way. Relational database mentalityExcellent. Use a simple integer numbering system for the revisions.- card revision (with keeping and linking to the old card)
Already implemented.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".)
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.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.
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"
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.Hash + configurable salt passwords.- login (so you find your own cards again), not required for visitors.
will be included in version 0.2 as it is not a core feature. But shouldn't be hard to do.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.)
One thread for each revision.Sounds cool. Q: What's best - to have one thread for each rev. of the card
That would be problematic because one card may have more than one successor., or one single thread per card?
For each card the predecessor and the successors are always listed.
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 booksHrm, tricky. You decide. However, maybe we should use re-captcha for anonymous posters? *sees bots crapping all over*
notedAdd: rejected, playtested- different states for cards: draft, discussed, accepted and banned.
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.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? ; )
Okay, I'll see what I can do without making the application prone to SQL injections.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, that should be possible. We could have a deck-table and JOIN it with the cards table.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,
Yes, later on. But first we need to fill the DB with cardsand 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)
I don't know what kind of file formats they use but It's probably nothing insaneAlso, 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.
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.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.
At the moment the login-system is very liberal. I think a voting system would be prone to abuse.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.
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)