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

Re: PHP script: card db

Post by Ravenchild » Wed Sep 15, 2010 23:52

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
A very good reason indeed :)
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.
I have subscribed myself to WTactics so maybe you can add me from the subscription list?
I'm a huge fan of config via text-file
Me too. So the decision is made.
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
I'm always striving for the easy and yet efficient solutions. So don't worry that much. Additionally, everything will be commented in Doxygen-style.
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.
It is important to agree on the kind of images that will be used for card art. So far all cards use one single object/person on a standard background. Or to put it differently: The is no colored pixel at (1,1) in the images used so far. In fact, the area around (1,1) should be reserved for text anyway.
So all that needs to be done, is set the color at (1,1) to transparency (on the fly) so that the background shines through.

What are your plans for card art? Will there be only objects/persons standing in front of the standard background or will there also be images that fill the area completely?

What about overlapping graphics like in this card?:
Image
The existing cards overlap the bottom area in all cases. There are some cards with an overlap at the right side. This looks nice and can probably even achieved with automatically generated cards if the following strategy is applied:
  • All images need a transparent background
  • At first a blank card with the standard background is taken
  • The image is placed onto the blank card so that its right bottom corner touches the right border of the physical card and is just above the golden line on the bottom.
So all images have a strong tendency to appear in the right bottom corner.

Any Agreements, Suggestions?


Besides, how would you distribute longer text on this image?:
Image
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.
I'm not entirely satisfied with my solution and I appreciate further ideas. And besides I only have a rough idea what may work well and what could cause serious problems. What I'm certain of, is, that card generation needs to be fast if the user needs to see ~25 cards as search results.
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.
In that case I have no objection to allow .psd files.
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?
That would be great.

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....
Good point. The png format itself uses a compression algorithm so the same effect may occur without an archive container.
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...
Checking out the repo already does take a significant amount of time without any old revisions to speak of. Well, you can at least browse the files in the launchpad web interface so that you don't have to download the whole thing.
I have been looking at Sparkleshare (which uses GIT?) and think it answers a lot, but maybe not this particular problem.
Well, it's worth a try. I haven't worked with it yet.

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".

I see.
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.
It indeed looks a little odd and there are many "Linked image not found" errors.
Even WotC doesn't do that [always same text card size]: 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.
I see your point.
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.
I like this compromise. It will be done that way :)
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.
So if we need to fix an official card, all the development is done in the dev table and once we agree on a better version of a card, the new version will be copied from the dev table to the official cards table?
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).
I don't get your point. What does this have to do with translations? And I don't think we will revise official cards that heavily because those cards have been discussed and tested before and therefore should really be good and balanced in most cases.
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).
I really like browsing magiccards.info and looking for cards that are conceptually related. Let's consider the card Dark Ritual. As someone who does not play a black deck, you probably want to know if there is a similar card for your color (well, there isn't). And there are also epic/legendary cards that are part of a background story. For example it would be cool to get all cards that are part of the Weatherlight crew. This may not be that important for deckbuiding but for fun.
And I don't think we should encourage people to "copy" MtG cards to WT. There certainly will be similar cards in both games by accident or by real inspiration but I think it will do more harm than good if a card is officially taken from MtG.
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.
I never intended it to be the main purpose. But it is relatively easy to implement.
We now have agreed that we will have 2 tables for cards. The draft table will support a non-linear development and the official table will only allow linear development with revision numbers.
I intend to attach discussion threads to each draft/revision so that everyone can see what considerations were made for the improved card. Or would you like having a compact comparison like the following?

Code: Select all

-increased defense by 1
-removed spelling error: teh -> the
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? ;)
It all depends on the information you already have. An ID guarantees that you get exactly the card you want. But most of the time you don't have the ID but some other information of the card.
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.
Agreed.
So, why can't we make it the other way around with WT? [...] 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)?
If I understand correctly, then each official card ID maps to one unique card name? And whenever a new card with the same ID (and therefore the same name) is released, its rules override the rules of the older card with that ID?
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: PHP script: card db

Post by snowdrop » Thu Sep 16, 2010 22:29

Ravenchild wrote: I have subscribed myself to WTactics so maybe you can add me from the subscription list?
Ok, this is going to sound lame, but I just wasted 30 min without any success: I can't find where/what you subscribe to or any trace of you at all anywhere (what's your username in there anyway?) I also haven't understood how people get right to commit. I even get the impression it doesn't work like SVN and that all trunks are personal, until one "merges" them into a new "common" trunk...

Will read up on that.

It is important to agree on the kind of images that will be used for card art. So far all cards use one single object/person on a standard background.
Actually, the background is never there and never will be: It is transparent on purpose (both aesthetics and economicial reasons). What we see in the background is the template, not the cardart.

What are your plans for card art? Will there be only objects/persons standing in front of the standard background or will there also be images that fill the area completely?
Forgiv me, but I don't follow: What do you mean with "standing in front of the standard background"? (Show some example, of anything.) All cards are "in front" of the background, as the background is in the back... ;) and is the template. ClarificatioN: With background I mean the map-textured stuff on the template.

Card art will always be "cut outs", like all the ones you see now: Focus will stay on whatever we want to show, minus background. Card art background is always transparent. Thus, the background on the finished card is always the template.


What about overlapping graphics like in this card?:
Image
That is overlapping on purpose, and imho looks pretty good. (Then again, this is just subjective aestehtics, I don't claim my taste is universal ;) )

I'd say that some card art does indeed look really nice when it overlaps one or more of the template borders. It all depends on the card art and what overlaps what where. It won't always be used, but whenever it looks better with an overlap I believe it should. This far I'm quite fond of the ones that do overlap the way they do it.

Coding for the overlap should however be easy: Just add an option what borders would be overlapped and the image would be differently placed on the template.
The existing cards overlap the bottom area in all cases.
Yes, if the bottom area = the green one at the bottom, most cards will have that overlapped somewhere, I think. Exactly where would depend on the picture, as seen in the example above.

  • All images need a transparent background
  • At first a blank card with the standard background is taken
  • The image is placed onto the blank card so that its right bottom corner touches the right border of the physical card and is just above the golden line on the bottom.
So all images have a strong tendency to appear in the right bottom corner.

Any Agreements, Suggestions?
Agreed, but, I think the user should have the option to influence the placement of the art more - in teh above all is placed in the right bottom corner.. We need the user to be able to choose between the following "modes"/layouts:

http://chaosrealm.net/wtactics/files/pics/mjau.png

In the picture you can see an example (1) that overlaps all 3 borders. Next to it, another card that only overlaps the bottom border (2) and lastly, a card that shows how the overlap borders are defined, and where you'll notice I set the bottom border "higher up" and treat it slightly different than the left and right borders.

What I think needs to be done is to allow the user to create any combo of the 3 overlaps, and also a zero-overlap.

Besides, how would you distribute longer text on this image?:
Image
You wouldn't. :) That image only has it's size because the text is short. And even now I believe it's overdimensioned and should be shrunk somewhat. In essence, such images would be rare. Most cards will never have that much estate for the card art. When you code, don't pay any attention to this image - treat it as any other. I see no reason to treat it differently or code extra features for it?

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?
That would be great.
On it once I finisih the story first. :) WIll announce when it has been done.

Checking out the repo already does take a significant amount of time without any old revisions to speak of. Well, you can at least browse the files in the launchpad web interface so that you don't have to download the whole thing.
Hrm. When one checks it out, surely it doesn't also check out all previous images of each individual revision? If it did, then we would indeed have an issue pretty soon. It's my understanding that if you only checkout the latest revision, then you only get those files. Not the whole .hidden history of them (although they are available from Bazaar upon request from the user). *scratches head*

It indeed looks a little odd and there are many "Linked image not found" errors.
Do a search and replace in a text editor in the SVG file. The errors are not "dangerous" and a resut of me forgetting to use relative paths to the raster images that I have imported "into" the inkscape SVG. All image paths should look like "WT/something" or "BfW/something etc and not "/home/snowdrop/trunk/WT". Once you have corrected that all will look fine. =)
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.
So if we need to fix an official card, all the development is done in the dev table and once we agree on a better version of a card, the new version will be copied from the dev table to the official cards table?

Yes, exactly. The official cards table is not used for dev at all. It just gets the "finished" candy from the dev table. (It does not howevere get every revision of card x from the dev table, as I showed earlier, It would only get a clone of whatever revision in the dev table that was marked as "accepted" )
I really like browsing magiccards.info and looking for cards that are conceptually related. Let's consider the card Dark Ritual. As someone who does not play a black deck, you probably want to know if there is a similar card for your color (well, there isn't). And there are also epic/legendary cards that are part of a background story. For example it would be cool to get all cards that are part of the Weatherlight crew.
What I wrote about that was intended as a question to what it had to do with your original ID-suggestion and ancestry concept. Now that that is resolved(?) (dual-table, one official "finished" system and one dev system exactly as you suggested it) I think we can leave it at that.

I do however think you could implement that sort of tracking/cool info in a very good way by just letting people suggest or create "link lists" shown in the sidebar or wherever when viewing the card. I.e. you could create a list with a custom name called "Siblings" and on that list there's a list with 3 items, numbered, and each is a link to a card in the db and the cards name. Pressing it would show creatures that are actually that cards brother or sister =)

If I understood you right, the above should capture any and all such cases as it is human-created and each list can be custom-named. I.e. "Other Legends" "More rats" etc etc... possibilities are infinite and rely only on our number of cards and players themselves. In the end, we are talking about a very easy yet efficient linkage-lists. Accuracy and versatility of them should be way bigger than what we both originally suggested for the goals you seem to aim at. Thus; I have no issues if you would want to implement these in some form (but I also have no grief if you don't - I don't see them as a primary function, but do recognize they are a solid addition and very good fluff.)
I intend to attach discussion threads to each draft/revision so that everyone can see what considerations were made for the improved card. Or would you like having a compact comparison like the following?
Agreed, sounds great. Make it support basic html like i, b, u, and auto-recognize linebreaks, so it isn't hell writing something there ;)

With discussion thread, how do you imagine it looks? Like a forum thread in here? I mean, do you imagine a thread with the possibility to post plenty of posts from different users, letting pretty much anyone discuss? (Btw, config option to only allow registered members to post would be nice, and/or use re-captcha for anonymous ones.)

I like the compact comparisson as well, but see them as two perhaps different things: A discussion thread opened to the public can pretty much be used to discuss anything related to the card (i.e. "Wow, this works so good in my deck woth 4 rats. Have you guys tried it out?"). It will not only be used by admins to explain revisions etc, while it could be used by them to do so as well if they wanted.

The compact thingie on the otehr hand is a very typical developers memo, as seen in all decent projects and which odds are both you and me are very accustomed to.

If it was up to me, I'd go with both. Somewhere there would be a link, when pressed, it would show this compact info with the tweaks done by the devs from a previous revision, as well as rationale behind it. Devs could ofc still use the thread to discuss the card with people if they wanted to.

Your call :) In a sense, there is also nothing that hinders the admins from always making the first post in the thread, and composing it in the compact form ;) It's a cheaper solution, but it sure seems to resolve the issue almost as well.
If I understand correctly, then each official card ID maps to one unique card name?
Yes, I think we really should avoid ever having more than one card with identical or very very similar name. Not because I have changed my mind about the official ID / name-discussion, but because that it is a) not needed and b) would only add confusion and c) we use different card art to help players memory and recognition of individual cards rules/functions - it is in the same sense counter-productive to not use the names in a very similar manner when possible.

So, each official card ID is associated with a name in the sense that that card has a name, and that when it was baptized we tried to pick a name that wasn't already in use or almost in use :P

(This does however still allow us to revise the name of the card if needed be. I.e. Urza's legend VS Urza's legends... or even a brand new name altogether (even though brand new names for the same card function seems like a stupid move most of the time...)



And whenever a new card with the same ID (and therefore the same name) is released, its rules override the rules of the older card with that ID?
No, a card with the same ID does not have to have an equated name as it did in a previous revision. I want to treat the name as any other element on the card, just like flavour text or whatever. It can be changed. However, since it's the name of it, and people would learn it pretty fast, it is in general a very bad idea to keep changing names of cards and such operations should really really be avoided if they can. They must not ever happen often, if at all, even if I in theory could imagine a case where it would be perfectly fine to do so.

Yes, it's rules override the rules of the older card with the same ID, no matter how the new rules look like and what the name is at this point: When the "accepted" status is set on a card in the beta-db, and that card is already living in the official-db, then the old version in the official.-db is instakilled and replaced with the latest "accepted" version in the beta-db.
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 19, 2010 18:42

snowdrop wrote:
Ravenchild wrote: I have subscribed myself to WTactics so maybe you can add me from the subscription list?
Ok, this is going to sound lame, but I just wasted 30 min without any success: I can't find where/what you subscribe to or any trace of you at all anywhere (what's your username in there anyway?) I also haven't understood how people get right to commit. I even get the impression it doesn't work like SVN and that all trunks are personal, until one "merges" them into a new "common" trunk...
It seems like you have succeeded in adding me to the group. :)
I'm still figuring out how I can commit to the repo at launchpad. My current commits are only applied to my local version of the repository.

I suggest that you create a dummy user for launchpad and try to let the dummy checkout and commit to launchpad. You are the admin of the repository and therefore you have better possibilities to debug this problem.

It is important to agree on the kind of images that will be used for card art. So far all cards use one single object/person on a standard background.
Actually, the background is never there and never will be: It is transparent on purpose (both aesthetics and economicial reasons). What we see in the background is the template, not the cardart.
Yeah, that's what I meant with "standard background".
What are your plans for card art? Will there be only objects/persons standing in front of the standard background or will there also be images that fill the area completely?
Forgiv me, but I don't follow: What do you mean with "standing in front of the standard background"? (Show some example, of anything.) All cards are "in front" of the background, as the background is in the back... ;) and is the template. ClarificatioN: With background I mean the map-textured stuff on the template.
Okay. It's clear then.
That is overlapping on purpose, and imho looks pretty good. (Then again, this is just subjective aestehtics, I don't claim my taste is universal ;) )
I like overlaps like this.
Coding for the overlap should however be easy: Just add an option what borders would be overlapped and the image would be differently placed on the template.
Yes, that's one approach. Another would be to tell the artists where the card borders are so that they either leave a margin or draw some overlaps in these regions. The card will then be put onto the template.
Agreed, but, I think the user should have the option to influence the placement of the art more - in teh above all is placed in the right bottom corner.. We need the user to be able to choose between the following "modes"/layouts:

http://chaosrealm.net/wtactics/files/pics/mjau.png

In the picture you can see an example (1) that overlaps all 3 borders. Next to it, another card that only overlaps the bottom border (2) and lastly, a card that shows how the overlap borders are defined, and where you'll notice I set the bottom border "higher up" and treat it slightly different than the left and right borders.[/url]
I see. And you want to let the user choose whether the image should be bound to the left or right side of the card? I'm also thinking about the possibility to let the user flip an image vertically( left to right).
What I think needs to be done is to allow the user to create any combo of the 3 overlaps, and also a zero-overlap.
I'm not against this possibility but for simplicity's sake I'd say: If the user doesn't want overlaps he must leave a transparent border on the image.
Besides, how would you distribute longer text on this image?:

Image
You wouldn't. :) That image only has it's size because the text is short. And even now I believe it's overdimensioned and should be shrunk somewhat. In essence, such images would be rare. Most cards will never have that much estate for the card art. When you code, don't pay any attention to this image - treat it as any other. I see no reason to treat it differently or code extra features for it?
Slightly OT: I've made some further considerations on how the we avoid can avoid text over the main foreground of a card: It should be possible to let the user write onto the cards directly with JavaScript. If the text gets too close to the foreground the user simply puts in a line break.
Now, If we allow left-bottom-aligned foreground images, we also need the possibility to indent text. This can simply be achieved with <space>-characters. Not a clever solution but one that gives me less of a headache than the older one. The greatest difficulty will be to match the JavaScript preview with the image generated with PHP.
Checking out the repo already does take a significant amount of time without any old revisions to speak of. Well, you can at least browse the files in the launchpad web interface so that you don't have to download the whole thing.
Hrm. When one checks it out, surely it doesn't also check out all previous images of each individual revision? If it did, then we would indeed have an issue pretty soon. It's my understanding that if you only checkout the latest revision, then you only get those files. Not the whole .hidden history of them (although they are available from Bazaar upon request from the user). *scratches head*
I'm fairly new to bazaar so I'm not sure how it handles all this stuff. But another distributed RCS called git gives you the entire history of the project when you do a checkout.

edit: From the Bazaar manual:
Keep in mind that Bazaar is transferring the complete history of the branch, not just the latest snapshot. As a consequence, you can be off the network (or disconnected from the network share) after branch completes but you’ll still be able to log and diff the history of the branch as much as you want. Furthermore, these operations are quick as the history is stored locally.

Note that Bazaar uses smart compression technology to minimize the amount of disk space required to store version history. In many cases, the complete history of a project will take up less disk space than the working copy of the latest version.
And I don't know how well this compression works on images.
I do however think you could implement that sort of tracking/cool info in a very good way by just letting people suggest or create "link lists" shown in the sidebar or wherever when viewing the card. I.e. you could create a list with a custom name called "Siblings" and on that list there's a list with 3 items, numbered, and each is a link to a card in the db and the cards name. Pressing it would show creatures that are actually that cards brother or sister =)
While it is absolutely clear what an ancestor or successor of a card is, other relations may be far more complicated. I think it will be enough to let the players post in the card's threads and let them link to other cards with an arbitrary complex explanations.
With discussion thread, how do you imagine it looks? Like a forum thread in here? I mean, do you imagine a thread with the possibility to post plenty of posts from different users, letting pretty much anyone discuss? (Btw, config option to only allow registered members to post would be nice, and/or use re-captcha for anonymous ones.)
I want to implement linear discussions. I don't think we need branches in such a case. And yes, registration or reCaptcha is a good idea.
I like the compact comparisson as well, but see them as two perhaps different things: A discussion thread opened to the public can pretty much be used to discuss anything related to the card (i.e. "Wow, this works so good in my deck woth 4 rats. Have you guys tried it out?"). It will not only be used by admins to explain revisions etc, while it could be used by them to do so as well if they wanted.
Hm. Let's see how it will turn out. There will be separate discussion threads for the official card and the draft of the same card. But if things really get complicated, a nonlinear discussion will be implemented.
The compact thingie on the otehr hand is a very typical developers memo, as seen in all decent projects and which odds are both you and me are very accustomed to.
Okay. Not hard to implement. So it will be included. (I should really start taking notes on the features).
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 21, 2010 07:03

I have summarized the features of the card database in a LaTeX document that can be found in the wiki.

This thread has added several new aspects to the card database. It will therefore take longer to finish this project.

And it would really be cool if you could tell me how I can submit code to launchpad.
User avatar
snowdrop
developer
Posts: 794
Joined: Mon Feb 01, 2010 15:25
Location: Sweden
Contact:

Re: PHP script: card db

Post by snowdrop » Tue Sep 21, 2010 10:07

Ravenchild wrote: I'm still figuring out how I can commit to the repo at launchpad. My current commits are only applied to my local version of the repository.
http://doc.bazaar.canonical.com/latest/ ... -launchpad

Commit
does, as you wrote, only do so to the local copy. That's on purpose if I understood it right. You would probably use push instead.

Ravenchild wrote:
eyerouge wrote: That is overlapping on purpose, and imho looks pretty good. (Then again, this is just subjective aestehtics, I don't claim my taste is universal ;) )
I like this kind of overlapping as well.
Yups, it looks good when done properly and used only when it makes sense. I also think it maybe even looks better when not all cards use the overlap.

Ravenchild wrote: Yes, that's one approach. Another would be to tell the artists where the card borders are so that they either leave a margin or draw some overlaps in these regions. The card will then be put onto the template.
Ehrm.. haha... yeah, that's of course way more preferable than my initial suggestion: I think I imagined that the user would upload a picture that could be i.e,. 70% of the template's width, thus my idea to place it seemed like a good one. Forget all I wrote - you're apparently right - we'll demand the user to always upload the picture in a static width in pixels (which should equal the full width of the template). Then depending on where the art is placed within the picture and how much transparency there's around the borders the overlaps (if any) would appear in the proper place automagically.

Only issue I see with that solution is how exactly would a normal user do such a placement in an easy way when editing her PNG where only transparency and the card art itself is seen? Maybe easiest would be if we supplied the users with an empty copy of the template, let the user import it as a background layer into their art PNG, then adjust the art itself, and then just kill/hide the template layer. Result would be a properly placed PNG with proper transparency and margins etc. Or is there an easier way, short of my previous suggestion?
Ravenchild wrote:
Agreed, but, I think the user should have the option to influence the placement of the art more - in teh above all is placed in the right bottom corner.. We need the user to be able to choose between the following "modes"/layouts:

http://chaosrealm.net/wtactics/files/pics/mjau.png

In the picture you can see an example (1) that overlaps all 3 borders. Next to it, another card that only overlaps the bottom border (2) and lastly, a card that shows how the overlap borders are defined, and where you'll notice I set the bottom border "higher up" and treat it slightly different than the left and right borders.[/url]
I see. And you want to let the user choose whether the image should be bound to the left or right side of the card? I'm also thinking about the possibility to let the user flip a card vertically( left to right).
I thought so, yes, but it's really not needed (see above) if we do it the way you suggested(?) - then all fo this is excess and unnecessary.

Ravenchild wrote: Now, If we allow left-bottom-aligned foreground images, we also need the possibility to indent text. This can simply be achieved with <space>-characters. Not a clever solution but one that gives me less of a headache than the older one.
Interesting. I haven't decided yet if I believe having left-bottom-aligned card art is a good idea if at the same time have card text next to it (to the right of the picture). Right now I lean towards not creating any cards at all that look that way. Reason for that is simple: We read from the left to the right. I don't want the eye to have to pass plenty of graphical elements when the player tries to read. It's not a super huge issue given it's never much text on a card, but I think it's a bad design calkl to use it for that reason, and that it also becomes more apparent with more text on cards and when having several such cards next to each other - they'd all have different indentation.

But, and here's a big but: Not all languages are from left to right. If we want to be global and friendly towards translations, and I think we really should, we would end up with the inverted argument for some languages (i.e. arabic). Conclusion is that we probably want a feature to indent from both left/right.
The greatest difficulty will be to match the JavaScript preview with the image generated with PHP.
Maybe also let people press a button to see a preview of how PHP would render it, and then allow them to keep on adjusting? Hrm...
But another distributed RCS called git gives you the entire history of the project when you do a checkout.
'

I get the impression Bazaar Explorer gives the user the option of how to do it, and one of the alternatives seems to be a "quick" checkout that doesn't fetch the full history. Since BE is a front end for bzr, I assume it should be doable with bzr as well.

What you quoted does suggest the contrary though :D
I want to implement linear discussions. I don't think we need branches in such a case. And yes, registration or reCaptcha is a good idea.
Oki.. but, discussion of an official card in the official table (marked as accepted, or better yet, marked as "official" while "accepted" are cards that seem to work but not yet officially released as a part of the game by us?) are separated from discussion of "same" card in the dev-table, right? I believe they should be, since they will likely be used in different ways and have different audience.

This weekend I'll try to sort out and tame bazaar once and for all. I'll play around with it by creating the dummy user as you suggested and will then get back to you on that.

I'll try to view the latex-stuff youposted, just need to find a good viewer... haven't worked with latex before but seen it's glory in action at the university = P

Edit: dumped a link to a pdf in the wiki.
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 21, 2010 11:44

snowdrop wrote: http://doc.bazaar.canonical.com/latest/ ... -launchpad

Commit
does, as you wrote, only do so to the local copy. That's on purpose if I understood it right. You would probably use push instead.

Code: Select all

Using saved push location: sftp://ravenchild@bazaar.launchpad.net/~snowdrop/wtactics/trunk/
Enter passphrase for key '/home/ravenchild/.ssh/id_rsa': 
bzr: ERROR: Cannot lock LockDir(sftp://ravenchild@bazaar.launchpad.net/~snowdrop/wtactics/trunk/.bzr/branch/lock): Permission denied: "/~snowdrop/wtactics/trunk/.bzr/branch/lock/fafb7ody94.tmp": [Errno 13] mkdir failed
The only thing I did so far is the creation of the /code/cardscape directory. According to the Bazaar documentation using "mkdir" on the shell should be alright (in contrast to svn's mkdir command).
Maybe it's not even a problem with permissions any more. I need to do further research on this.
we'll demand the user to always upload the picture in a static width in pixels (which should equal the full width of the template). Then depending on where the art is placed within the picture and how much transparency there's around the borders the overlaps (if any) would appear in the proper place automagically.
I don't think the image (with transparent borders) needs to cover the full width of the template. There is no point in filling the right (or upper) side of the image with a big transparent border.
Maybe easiest would be if we supplied the users with an empty copy of the template, let the user import it as a background layer into their art PNG, then adjust the art itself, and then just kill/hide the template layer. Result would be a properly placed PNG with proper transparency and margins etc. Or is there an easier way, short of my previous suggestion?
No, that's an excellent idea!
Interesting. I haven't decided yet if I believe having left-bottom-aligned card art is a good idea if at the same time have card text next to it (to the right of the picture). Right now I lean towards not creating any cards at all that look that way. Reason for that is simple: We read from the left to the right. I don't want the eye to have to pass plenty of graphical elements when the player tries to read.
I fully agree.
But, and here's a big but: Not all languages are from left to right. If we want to be global and friendly towards translations, and I think we really should, we would end up with the inverted argument for some languages (i.e. arabic). Conclusion is that we probably want a feature to indent from both left/right.
Should be doable. And I think we should even flip the images on the cards for this purpose so that there is more place on the right side of the card. Normally all cards with the same ID should have the same image to make recognition easier. But a flipped image should still be OK.
The greatest difficulty will be to match the JavaScript preview with the image generated with PHP.
Maybe also let people press a button to see a preview of how PHP would render it, and then allow them to keep on adjusting? Hrm...
Yes. It will be done that way. There will be an enforced preview.
But another distributed RCS called git gives you the entire history of the project when you do a checkout.
'
I get the impression Bazaar Explorer gives the user the option of how to do it, and one of the alternatives seems to be a "quick" checkout that doesn't fetch the full history. Since BE is a front end for bzr, I assume it should be doable with bzr as well.

What you quoted does suggest the contrary though :D
I have read further and bazaar indeed offers this quick checkout. So you should add a note to the Download page.

Oki.. but, discussion of an official card in the official table (marked as accepted, or better yet, marked as "official" while "accepted" are cards that seem to work but not yet officially released as a part of the game by us?) are separated from discussion of "same" card in the dev-table, right? I believe they should be, since they will likely be used in different ways and have different audience.
Absolutely correct. And I'll change "accepted" to "official".
This weekend I'll try to sort out and tame bazaar once and for all. I'll play around with it by creating the dummy user as you suggested and will then get back to you on that.
Great. Take your time. I won't have regular Internet access for the next two weeks. Maybe you can also work further on your economy systems in the meantime.
I'll try to view the latex-stuff youposted, just need to find a good viewer... haven't worked with latex before but seen it's glory in action at the university = P

Edit: dumped a link to a pdf in the wiki.
Nice. After we have worked out how the repo works, I'll add it there as well.
Locked