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
![Wink ;)](./images/smilies/icon_e_wink.gif)
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...
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
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.
![Smile :)](./images/smilies/icon_e_smile.gif)
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
![Wink ;)](./images/smilies/icon_e_wink.gif)
...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.
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
![Wink ;)](./images/smilies/icon_e_wink.gif)
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
![Wink ;)](./images/smilies/icon_e_wink.gif)
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
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"
![Wink ;)](./images/smilies/icon_e_wink.gif)
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.