Deck editor & Deck save format

All projects that somehow make usage of code.
Post Reply
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:
Deck editor & Deck save format

Post by snowdrop » Wed Jul 11, 2012 23:29

This is a general thought that could be implemented wherever:

A client/server will somehow allow the players to build and save their decks. In most (all?) programs I've seen the save files are very simple and readble. Readability is a feature and should be kept intact. What has been poorly handled are two things:

1. Meta-data
Usually there is no meta-data gathering going on. For example it would be good to know for the patch-creators how many times a card occurs in the decks that are beeing built, which x y z cards that usually tend to end up in the same deck(s), what the average amount of creatures cards of faction y is in a deck and so on. The possibities are many and the info can be of great assitance for a game developer for example balancing reasons, as well as the community of players in general.

Meta-data also allows "global" deck registration via for example hashes where a user that is first to "invent" and register a deck will always be given credit for that deck online within the community. This stimulates deck pubic building, which in return stimulates competitive play as well as casual.

(In addition deck derivatives can also be followed up. If I for example am the first to register a deck with cards x y z in it and we then see an almost identic deck that has x y z-2 w in it, it is clearly a derivative (regardless if the author really derived it or not from the previous deck). )


2. Revision handling
What happens in many games/patches is that people build a deck, put some cards in it, and six months later the card(s) they put in it have, to some degree, changed. So if I would have "4 x Darth Vader" in my deck and the only info about which card I put in the deck is that teh card name is "Darth Vader", there is no easy way of knowing of the deck is still doing what it was intended to, or if it has, due to some balancing from the game devs or some card bans etc, become obsolote or ineffective. To handle that I suggest that the deck-save files also have info about exactly which version of the card that was actually used when building the deck. When you then load a deck where the cards have changed you would be warned for the potential danger of surprise that awaits you, and it would point out which cards have changed since you built the deck. Youi are then either expected to fix that on your own in whatever deck editor, or, the program can update your deck-save-file if you just "accept" the changes and mark them as "reviewed" or "accepted".
aspidites
Posts:101
Joined:Mon Apr 11, 2011 22:39

Re: Deck editor & Deck save format

Post by aspidites » Fri Jul 13, 2012 00:10

Meta-Data
At first glance, I thought you meant things like deck creator, deck type (burn, mill, etc). After reading more closely, it seems you mean statistics. That is, a way to register the deck somewhere that keeps statistics on the deck, and then can later compare that deck with others. For ViCE, I'm thinking an INI file using python's configparser would suffice. Different scenarios:

user just wants a deck
The format would be simply "<Number of Cards> <Unique Identifier or Title>":
Elvish Druid = 2
GAI-001 = 1 # made up, use your imagination
user wants a deck and credit
In this case, user information can be specified

Code: Select all

[metadata]
Creator = Aspidites
Tags = burn, gaian

[main]
Elvish Druid = 2
GAI-001 = 1
In this case, metadata isn't inferred, but specified. For games with a side deck, it would be something like this:

Code: Select all

[main]
Elvish Druid = 2
GAI-001 = 1
[side]
...
As for how metadata (in the sense that you defined it) would be collected, I suspect it would be collected when a player joins a server. Hopefully, server maintainers will give users a chance to opt-out (think a la google analytics)

For your revision system, i think putting that stuff directly in a deck format is ugly (who wants to see a bunch of diff info). Instead, I think I'm going to allow vcs integration. I'll start a vcs branch here soon, which will allow various things to be kept track of. I'm imagining that for the user, they'd just have to supply an option to vice in order to keep track:

Code: Select all

vice track <filename>
Not sure yet. Being that it just uses regular vcs's under the hood, you could simply init your favorite repository if you'd rather. I totally just came up with this 5 minutes ago after reading your post, so it might be absurd. I'm also in a hurry to head to work, so it might take me a while to flesh this out. What i do know, is that I'd use anyvc, which supports bzr, darcs, git, mercurial, monotone, and subversion.

I'll give a more point-by-point review of your original post when I get the chance, snowdrop (like addressing review/accepted)
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Deck editor & Deck save format

Post by snowdrop » Fri Jul 13, 2012 02:08

....deck type (burn, mill, etc).
Deck description both in the form of tags AND some standardized ways that are defined by the game/patch creator like drop drown menus or whatever with (example) options such as "aggro" "control" "weenie" would be cool and make it easier to grab statistics over what types of decks are built. If you just go with a free-form tag system that won't be possible in a decent way. That said, tags are still cool.
Elvish Druid = 2
GAI-001 = 1 # made up, use your imagination
Yups. Would work. Convention is that the equal is a "x" instead, but I don't see any reason for that really Would also be cool to have he ability to comment in file, as you did in your example.

Random Sidenote/idea:
Would be cool to be able to create "livedecks" (TM), something which I haven't ever seen in any other software.

Livedecks are "generated/finalized" when you load the deck. You have stil pre-built them, but they add some cool surprises and variations which you can fine tune.

Imagine:

Code: Select all

Elvish Druid = (1, 3), ===

Would mean that your deck will always have a number of 1 up to 3 Elvish Druids in it, and that there s a chance of 1/3 that you get 1,2 or 3 Elvish Druids in your deck. Compared with:

Code: Select all

Elvish Druid = (1, 3), 5/80/15
..which means the same, but makes it so that there is only a 5% chance that you get just a single Elvish Druid in deck, an 80% chance that you get 2 of them, and a 15% chance that you get 3.

As presented this is of course not fully usable yet, but behold >>

Code: Select all

Elvish Druids = (0,3), ===
0: Wose = 3
1: Elvish Marksman = 1 & Elvish Swordsman = 2
2: Elvish Swordsman = 2, $someVarUsedForCheck++
3: Deck subtitle = "Druids Return"
...meaning that you get between 0 to 3 Druids, and that it's a 25% chance that any one of the scenarios will happen as shown by the "equal chance for any of the outcones sign === a line 1)

If you get 0 Druids then you get 3 wose instead. If you get 1 Druid you also get 1 Marksman and 2 Swordsmen, and if you get 3 Druids you get no other "substitute" cards (at least not in this entry) but we tell ViCE to change the name of the deck so it has a subtopic/title that marks it as themed in a certain way, for example, indicating directly to the player what he has in front of him.

Also, when we get 2 Druids we also get 2 swordsmen, however we also set a variable and raise it with one. So for example if I build a livedeck that can come out in 3-4 different versions, I can use the variable to keep track of which version it is heading at and I can then use a check, like for instance

Code: Select all

IF ($someVarUsedForCheck == 3) then {
Deck subtitle = "Warriors Theme"
Cardback = "/BloodyGore.jpg"
}

In any case, you ge the point. What this would allow is something that is somewhat tedious to achieve in reality with real cards, and also:
  • Such a system can be piggybacked in order to create/emulate how boosters work and eventually even collecting. A patch creator could just set some variable and tell ViCE that what the player is opennig up is not a deck, it's a pack of newly "purchased" cards, a booster pack or a tournament deck or whatever it's called.
  • It allows variation without it being random and braindead, letting players create a deck that can easily transform itself into different "paths", either at random or simply by selection from a deck menu after having loaded the deck.
  • It presents yet another way to play both casual but also competetive games and saves an hour or so for those that want to play drafts but rather have more control and spend more time on playing than drafting.
I'm not saying LiveDecks is a top priority here, but I really think it would set ViCE apart in what it can achieve and also bring some very creative stuff/formats to competitive play. (For example a tourney where each deck must have 3 paths, with equal odds of happening, and where only 20 cards differ in total from the other 2 paths). Furthermore LiveDecks can also be used by anyone who wants to plugin an AI eventually...
As for how metadata (in the sense that you defined it) would be collected, I suspect it would be collected when a player joins a server. Hopefully, server maintainers will give users a chance to opt-out (think a la google analytics)
Yups. But I also think that server admins should be able to _enforce_ the stats gathering and simply not allow a player to use the server if he opts out. I mean, a player should of course _know_ that it is done before joining the server, and could just choose not to join it if it is an issue. And then there is the mode where server admins try to collect it, but where players opt out, but are still able to use the server, and lastly, the servers where nothing is harvested. Again, it's all about giving people the choices and tools. Enfotcing people to give up privacy though is always a total fail = P
For your revision system, i think putting that stuff directly in a deck format is ugly (who wants to see a bunch of diff info). Instead, I think I'm going to allow vcs integration
It is ugly, indeed, but nothng says that the info needs to be in the same file or in chaotic fashion ;)

As for VCS, how would it work? _Somewhere_ there needs to be a record of what card you used when you built your deck. If that's not in the deck file itself then it is in a sister-file to the deckfile or in a db. If it later on gets the info from a VCS or relies on hashes on a site (like LackeyCCG does) is a matter of preference. Personally I think VCS seems kind of overkill since it will only need the md5 sum or whatver to figure out if something changed, and it raises the bar somewhat for the users/creators.
aspidites
Posts:101
Joined:Mon Apr 11, 2011 22:39

Re: Deck editor & Deck save format

Post by aspidites » Fri Jul 20, 2012 18:21

about tags
I'd probably have it so that the plugin designer could specify whether or not tags are predefined, specified by users, or both. I suspect it would be easy enough for popular tags to be given more weight as well.
re-built them, but they add some cool surprises and variations which you can fine tune.

about 'live deck's
The idea is interesting, but I hate the format. You're nearly scripting the file anyways, so why not use python? In such case, I'd modify the deck format slightly:

Code: Select all

from random import choice
meta = {
    'creator': 'Aspidites',
    'tags': ('burn', 'gaian'),
}

main = {
    'Bound by Love': 3,
    'Elvish Druid': choice(range(4))
}

if main['Elvish Druid'] == 0:
    main['Wose'] = 3
elif main['Elvish Druid'] == 1:
    main['Elvish Marksman'] = 1
    main['Elvish Swordsman'] = 2
elif main['Elvish Druid'] == 2:
    main['Elvish Swordsman'] = 2
elif main ['Elvish Druid'] == 3:
    meta['subtitle'] = 'Druid Return'

Using Dict instead of bracket notation would remove some brackets and change colons to equal signs if you prefer. As for the distribution, I suspect the random module could be leveraged. More than likely, I'd wrap that into a function to make it less complicated for users. I'll post again when I have a prototype for this.

edit:
Thought it might help to show what the raw python might look like for your live deck example, until I can come up with abstractions to make things less verbose.
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Deck editor & Deck save format

Post by snowdrop » Fri Jul 20, 2012 19:32

The python you wrote is understandable due to it's simplicity even if I don't know a single line of python myself. Distribution functions that you write should be elsewhere though, as I'm sure you'd plan on anyways.

It can still become way more natural for the average player to use though by doing away with as much coding stuff as possible. For example:

Code: Select all

elif main['Elvish Druid'] == 2:
    main['Elvish Swordsman'] = 2
..is too verbose for a player. I'd suggest just cleaning it up somewhat like:

Code: Select all

If "Elvish Druid" == 2 then "Elvish Swordsman" == 2
Then again how much cleaner is that? Not much. And if a player can understand that, then surely he can understand your original. Maybe real python is all fine, if it doesn't become crowded and too complex. A lot of predefined functions would help players with that and keep things easy and clean. What's most important is that there is a good set of them around from the start and that they're very well documented, with a couple of examples. I'd be happy to be your testbunny, if I don't understand it nobody that doesn't know python or coding would.

(Sidenote: Would be cool to be able to even define a whole deck at random as well within given paramters , like for example "MyRandomWeenieDeck = (x Creatures with a gold cost lower than 4 and ability != FALSE and faction = Gaian OR Banner + minmum 2 of the creatures have the name "Darwin" in title and max 10 have the creature type "goblin") + (5 rnd gaian equip)"

On a different issue
..yet somewhat related even though it has nothing to do with automatic deckbuilding, is of vice could support scripts for reacting somehow on events while playing. So, if load a script I wrote that is called "soldier warning" and an opponent puts a soldier from hand on table, then when THAT happens the script would highlite the soldier in pink (until end of turn or whatever i set it to) or "send" a message to me in chat saying "Look! Soldier! Hideee!" on MY side of the screen. Same goes for example if I want to have other checks, for example if I have an instakilling card that mainly kills gobos on my hand, and SOMEWHERE on the table there is a creature that is a gobo, the I could have scripted the check so the card in my hand lights up and the other card as well, indicating to me that "look, a target". Trivial examples, i know, but it has far more potential... eventhough this is pretty overkill and far from anything that's needed in a basic release.
aspidites
Posts:101
Joined:Mon Apr 11, 2011 22:39

Re: Deck editor & Deck save format

Post by aspidites » Sat Jul 21, 2012 06:13

For your "offtopic" idea, seems that would be cheating in-so-far as aim-bots are cheating in FPSs. Event-driven plugins would be easy enough to support. The tricky part would be finding a way to disable them on tournament servers, etc. What immediately comes to mind is simply having a server config value that allows certain notifications to be disabled (so that no script could hook to them), or disable certain types of plugins. If you start a new topic or create an issue, I can look further into this later.

*back on topic*

Code: Select all

from random import choice

meta = {
    'creator': 'Aspidites',
    'tags': ('burn', 'gaian'),
}

main = {
    'Bound by Love': 3,
    'Elvish Druid': choice(range(4))
}

druids = main['Elvish Druid']
if not druids:
    main['Wose'] = 3
elif druids == 3:
    meta['subtitle'] = 'Druid Return'
else:
    main['Elvish Swordsman'] = 2
    if druids == 2: main['Elvish Marksman'] = 1
Still too verbose for you?
aspidites
Posts:101
Joined:Mon Apr 11, 2011 22:39

Re: Deck editor & Deck save format

Post by aspidites » Sat Jul 21, 2012 07:11

Even shorter:

Code: Select all

from random import choice

meta = {
    'creator': 'Aspidites',
    'tags': ('burn', 'gaian'),
}

main = {
    'Bound by Love': 3,
    'Elvish Druid': choice(range(4))
}

druids = main['Elvish Druid']
main['Wose'] = 3 if not druids else main['Elvish Swordsman'] = 2
if druids == 2: main['Elvish Marksman'] = 1
if druids == 3; meta['subtitle'] = 'Druid Return'
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Deck editor & Deck save format

Post by snowdrop » Sat Jul 21, 2012 10:37

Think both work. Eventually you'll hit a bump where too short will make readability suffer and make it less understandable than more verbose, but none of them are there yet.

It doesn't need to get shorter. People that will use it will have to learn the syntax anyways and read some good docu ;) or use a GUI to generate something for them to get started. What's important is it's flexibility and the functions/examples it comes with out of the box, so it isn't just a sandbox for hardcore devs that requires the reading of 100 pages and already knowing how to code, and at the same time, without restricting those that do know already.
aspidites
Posts:101
Joined:Mon Apr 11, 2011 22:39

Re: Deck editor & Deck save format

Post by aspidites » Mon Jul 23, 2012 18:11

snowdrop wrote:Think both work. Eventually you'll hit a bump where too short will make readability suffer and make it less understandable than more verbose, but none of them are there yet.

It doesn't need to get shorter. People that will use it will have to learn the syntax anyways and read some good docu ;) or use a GUI to generate something for them to get started. What's important is it's flexibility and the functions/examples it comes with out of the box, so it isn't just a sandbox for hardcore devs that requires the reading of 100 pages and already knowing how to code, and at the same time, without restricting those that do know already.

Beauty of it is that being pure python, length is largely irrelevant. In fact, since the deck code would only be loaded once, it wouldn't matter how inefficient the deck creator's code was. That said, There would of course be a deck editor and a cli tool to reduce some of the churn.
Post Reply