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
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?:
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.
Any Agreements, Suggestions?
Besides, how would you distribute longer text on this 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".
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.
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?